Jump to main articles index
| By |
|
Though the avionics protocol establishes the baseline operation, and the application drives the feature requirements, the avionics data bus interface architecture sets the capability limits. Even for the same protocol, the capability and ease-of-use vary between implementations. Interfaces for basic communications, hardware test, and simulation applications share many common requirements, but also differentiate in character. For example, error injection is a useful feature in a tester interface, however, errors should never transmit through a flight application interface.
General considerations
The following are some general features to consider when selecting an avionics data bus interface:
- Host interface (PCI, CompactPCI, VMEbus, Ethernet bridge, custom, etc.)
- Number of channels and protocols
- Host involvement in protocol processing
- Host interaction with data
- Special features such as monitoring, time tagging, and error injection
- Processing power available for the protocol and user application
- Hardware and software development tools and support
- Development and production costs
Considering these features throughout the process will play an integral part in choosing just the right architecture.
Types of architectures
There are three basic architectures: protocol IC, single processor, and multiprocessor. In some cases, it may be difficult to categorize a particular interface, but an understanding of the different architectures helps to raise and address important issues during the selection process.
Protocol IC architecture
In this architecture, digital and analog circuit components are combined to provide at least basic communications. These circuits have evolved so there are now many available components with all the necessary functionality in a single IC, Multi-Chip Module (MCM), or hybrid circuit. Depending on the protocol and the complexity of the IC, it may be necessary for the host processor to execute higher-level protocol functions. Protocol ICs can be expensive, but circuits using protocol ICs are easy to implement and, therefore, make a good choice when developing hardware from scratch. Most protocol ICs were designed for flight (operational) applications where requirements are limited in functionality to basic communications. Since they do not provide special functions, such as error generation and time tagging, protocol ICs are less suited for use in test equipment. Extensive software development might be required to interact with the host, to run high-level protocol functions, and to handle data appropriately. Manufacturers of COTS interface cards using protocol ICs should provide driver functions and examples that help to simplify software development.
Single processor architecture
Adding a processor improves the power and flexibility of the interface. A protocol IC or custom gate array usually handles the low level encoding and decoding, while firmware running on the processor manages the high level protocol. The high speed of a DSP makes it a good choice for the processor. The task of developing a processor-based interface from scratch is considerably greater than it is for a simple protocol IC interface. However, COTS interface card manufacturers usually provide powerful, easy-to-use firmware and software driver functions with a broad range of inherent capability. Error injection, monitoring, time tagging, multi-terminal simulation, and special message handling are all possible with this architecture.
Multiprocessor architecture
The next logical progression is to add even more processing power. There is a growing need in the industry for more channels, mixed protocols, and the capability to run user code, all on a single interface card. High-density digital components and new ever-shrinking packaging techniques now make this possible. As the channel count increases, additional processing power is required to preclude an overload condition. DSPs work well for the protocol processors, but an on-card general-purpose processor, such as a PowerPC® processor, running a known operating system facilitates the development of user code.
The general-purpose user processor can offload the host or run user code. It can format, manipulate, and generate data in a way that is best suited to the host, and it provides the user with the flexibility to define the software interface between the host and the interface card. In some cases, a host processor is not necessary, as the user processor alone can run the entire application. For instance, protocol converter and data server software can run on the card without support from a host processor. A protocol converter takes messages received from one channel or protocol, does the necessary conversion, and re-transmits them on a different channel or protocol, such as MIL-STD-1553 to ARINC 429. A data server provides multiple users with controlled access to the data buses. It could even serve up the data as a web page over an Ethernet port.
Multiprocessor – the architecture of choice
An example of the multiprocessor architecture is Ballard Technology’s new OmniBus® family of avionics data bus interfaces, available for PCI, CompactPCI, VMEbus (Figures 1 and 2), and for USB and Ethernet in a standalone unit called the OmniBusBox™ (Figure 3). The Ethernet port on the OmniBus VME and OmniBusBox enable remote operation. The common architecture in the OmniBus family allows software applications to seamlessly re-host on different platforms. All OmniBus products provide a Linux PowerPC user processor and multiple DSP protocol processors. A complete software tool set is available for Omnibus. Users can develop their own programs or run CoPilot® software, a powerful, user-friendly graphical interface. OmniBus supports MIL-STD-1553, ARINC 429, 717, 708, and variations on these protocols, as well as discretes and serial ports. Each product is configurable to a high channel count for a single protocol or for a mixture of different protocols. For example, a 3U CompactPCI card could have 4 channels of 1553, 32 channels of 429, or 2 channels of 1553 combined with 16 channels of 429. An alternative for VME would be a 6U VME card with 8 channels of 1553, 64 channels of 429, or 4 channels of 1553 combined with 32 channels of 429.
|
|
|
Figure 1: (click graphic to zoom by 1.9x) |
|
|
|
Figure 2: (click graphic to zoom by 1.9x) |
|
|
|
Figure 3: (click graphic to zoom by 1.9x) |
Technological advances have expanded the choices in architectures available for avionics data buses. With its power and flexibility, engineers should seriously consider the new multiprocessor architecture. Ultimately, the tradeoff between economics and performance determines the best choice for a particular application. In making the best selection, engineers must factor hardware and software development and purchase costs against the protocol mix, channel count, and functional requirements.
