Integrated Modular Avionics: Less is More Approaches to IMA will save weight, improve reliability of A380 and B787 avionics James W. Ramsey The Integrated Modular Avionics (IMA) concept, which replaces numerous separate processors and line replaceable units (LRU) with fewer, more centralized processing units, is promising significant weight reduction and maintenance savings in the new generation of commercial airliners. Boeing said by using the IMA approach it was able to shave 2,000 pounds off the avionics suite of the new 787 Dreamliner, due to fly in August, versus previous comparable aircraft. Airbus said its IMA approach cuts in half the part numbers of processor units for the new A380 avionics suite. "It’s not just the IMA modules themselves, and reducing the number of LRUs. IMA brings a more efficient network for the aircraft," said Bryan Vester, vice president of commercial systems strategy development for Rockwell Collins, a supplier to both Boeing and Airbus. "From an airline standpoint, fewer types and varieties of spares should drive higher reliability, and therefore less maintenance." Some believe the IMA concept originated in the United States with the new F-22 and F-35 fighters and then migrated to the commercial jetliner arena. Others say the modular avionics concept, with less integration, has been used in business jets and regional airliners since the late 1980s or early 90s. The concept also is seen on the military side in the KC-135 and C-130 upgrades, as well as in the new Airbus A400M transport. But regardless of where it began, IMA is the trend of the future due to the economies in fuel savings derived from less weight and lower maintenance costs. It also offers an open architecture allowing for the use of common software, which makes upgrades and changes both cheaper and easier to accomplish. "An IMA operator can upgrade software without having to upgrade the hardware, and vice versa," said Jean Pierre Gillet, Airbus senior director of IMA support and services. Using elements common to different computer modules makes maintenance of the computer less expensive. Since the same part (or card) can be used in any of the IMA computers, inventory in the shop is smaller. The advantage is less expensive maintenance, Gillet said. While adapting the general concept of "shared resources," the Boeing 787 and the Airbus A380 approaches to IMA differ. Both aircraft have applications for specific LRUs that are on the plane and individual computers for certain systems.
Key to the B787 avionics suite, which Boeing developed with partners Smiths Aerospace, Rockwell Collins and Honeywell, is a central computing system Boeing calls the Common Core System (CCS), which eliminated more than 100 different LRUs.
‘Open IMA’ The A380 Super Jumbo, which touts 15 to 20 percent lower operating costs than previous airliners, applies the IMA concept with computers capable of hosting different functions and integrated modular avionics connected by a network. This approach differs from Boeing’s 787 central computing system in that it does not rely on a single (or dual) central processor to run most of the aircraft systems. Instead, the A380’s IMA approach relies on eight processing modules, some tailored for specific applications, but all tied together by a common Avionics Full-Duplex Switched Ethernet (AFDX), ARINC 664 standard network. Seven of the 3-MCU computers are core processing input/output modules (CPIOM); the eighth is an input/output module (IOM). "Even if all these computers are connected to the AFDX, and the majority of the communications is done through the network, there is some specificity on the module depending on which function they are in," Gillet said. "There is a slight difference in the input/output of the computers, which is why they have different part numbers." Although the Airbus IMA computers have eight different part numbers, memory and power supply cards are common to all the computers. It is only the input/output card that is different, depending on what type of system the computer interfaces with. Gillet emphasized that the use of a central processing system "is not exactly the way we have followed on the A380. There are seven CPIOMs doing different types of functions. We have preferred to develop what we call an open IMA — some computing resources on which we can have different functions hosted." Rockwell Collins is providing the AFDX network for the A380 along with overall network integration support to Airbus and to third-party suppliers that have network "end systems" embedded into products they are delivering for the A380, Vester said. The end system, a chip set, is required in a manufacturer’s box in order to have a network connection. Gillet described the three functional domains of IMA as: cockpit (electrical flight control, communications and warning); cabin (air conditioning and pneumatics); and utilities, including energy, fuel functions and landing gear functions. There are 30 line replaceable modules, all 3-MCU boxes, associated with the IMA platform, and 22 software functions hosted in the CPIOMs. France’s Thales and Airbus Avionique each are providing CPIOMs.
Some 11 suppliers provide software functions hosted within the IMA, ranging from communications to landing gear extension and retraction. They include Fairchild Controls (pneumatic), Parker Aerospace (fuel applications) and Hamilton Sundstrand (air conditioning). Rockwell Collins’ role on the A380 differs from the role it has on the Boeing 787, where it acts as network integrator for the latter’s Common Data Network. Rockwell Collins contracts directly with Airbus to provide the network on the A380, and Airbus is integrating the computing part of IMA with the network, said Joel Otto, Rockwell Collins’ program manager for Boeing programs. For the A380, Rockwell Collins provides data link applications software — a "router" for airline operational control (AOC) functions — hosted on the IMA platform and used for communications between the aircraft and the airline’s network operations center. "The AOC function is hosted on the IMA, but like in any ACARS (Aircraft Communications Addressing and Reporting System), we can tailor it for the airline’s specific application," Vester said. Suppliers also are providing systems not hosted on the IMA. Honeywell is providing the A380’s flight management software, which has its own computer, and Airborne Environment Surveillance System, combining the company’s RDR-4000 weather radar, transponder, Traffic Alert Collision Avoidance System (TCAS) and Enhanced Ground Proximity Warning System. The system represents a 50 percent volume and 40 percent weight reduction from previous federated surveillance equipment, said Robert Majure, platform systems product management director for Honeywell. Through its IMA Support and Services group, Airbus is "providing to the customer supplier-type support for the integrated platform," said Gillet, who heads the organization. "Like a supplier provides training on classical LRUs, we provide training that includes hardware as well as software that is hosted by the hardware." The support includes spares and a training program for repair technicians offering instruction in IMA familiarization, shop maintenance and engineering maintenance training.
B787 integration In a change of philosophy, Boeing is giving its first tier suppliers more integration responsibility for system packages on the 787 Dreamliner. They provide packages that may require subcontractors, and can include more than one of their products. Smiths provides the Common Core System, which is comprised of general processing modules and remote data concentrators that replace traditional wiring with I/O devices that concentrate analog and digital signals from the remote sensors and send them on the network to the processing modules.
A third IMA component, Rockwell Collins’ Common Data Network, is a fiberoptic Ethernet connecting all systems that need to communicate with the CCS. It consists of external switches using ARINC 664 standard protocol. The processors use an ARINC 653-compliant operating system supplied by Wind River Systems, Alameda, Calif. "We design the hardware, using their operating system, and then we layer other software services on top of it. Beneath it is a commercially available operating system," said Mike Madden, Smiths’ business director of platform computing systems. This open architecture "allows the whole IMA approach to go forward," Madden maintained. If changes or upgrades are needed, "Boeing, or the developer of the platform, can select other suppliers to provide functions and minimize the financial impact and complexity of integrating those applications." Smiths is delivering B787 hardware to Boeing, for use in its integration facilities, but also to suppliers Boeing selected to provide applications and functions using the IMA. The suppliers are integrating their applications onto Smiths’ hardware for delivery to Boeing. Smiths, along with other suppliers, planned to ship components to Boeing early this year for the first B787 flight. "We are certainly looking at taking products and technologies, the tools in particular — that we have developed on the 787 and other programs, like C-130 AMP (Avionics Modernization Program) and the Boeing 767 tanker, into next generation IMAs for a number of commercial customers as well as some military opportunities," Madden said. Rockwell Collins is supplying the B787 communications system and Configurable Integrated Surveillance System (CISS). CISS combines the company’s MultiScan automatic weather hazard detection system, Mode S transponders, TCAS and Terrain Awareness Warning System into a single system, which Rockwell Collins points out, uses 40 percent fewer parts than traditional federated aircraft systems. Rockwell Collins also is supplying the B787 cockpit display system, which includes its dual head-up displays as standard equipment. The company is providing the core network cabinet, a platform that provides for both cabin and flight deck applications and manages onboard information flow to improve airline operations efficiency. As supplier of the B787 pilot controls, Rockwell Collins delivered the first fully operational system to Boeing to develop an integrated test vehicle. The pilot controls include interfaces to the aircraft’s fly-by-wire flight control system. At this writing, Rockwell Collins had completed initial deliveries of pre-certification hardware to Boeing for its integration facilities, and began deliveries for the first B787 flight test aircraft.
A large amount of avionics integration work has been accomplished at the Rockwell Collins lab in Cedar Rapids, Iowa, including integrating functions from other suppliers. Honeywell provides the flight management system software that resides on the B787’s IMA system as part of its navigation component, which also includes its air data inertial reference unit and multimode GPS receiver. The Honeywell crew information/maintenance system evolved from the central maintenance computing and aircraft condition monitoring functions the company developed for the Boeing 777. "Boeing’s 777 AIMS (Aircraft Information Management System), from my point of view, was the first actual IMA implementation, in commercial aviation," Majure said. "The IMA concept is all about weight and power savings. With new aircraft getting more software-based functionalities, and computers becoming more powerful, it doesn’t make sense to add another box with its own computer every time you want to add a new feature or function. It makes a lot of sense to share computing resources." Honeywell also provides the flight control package for the B787’s fly-by-wire system. The company was in systems level integration, and deliveries had begun to support the first flight.
A380 Awarded Type Certificates FAA and the European Aviation Safety Agency (EASA) late last year issued type certificates for the Airbus A380, the first concurrent certification by the two agencies. "This is the first major leap in aircraft capacity in over 35 years," FAA Administrator Marion C. Blakey said at the hand over ceremony Dec. 12 in Toulouse, France. "... All of aviation, on an international scale, stepped up to the plate to ensure that we were ready to deal with the size of this airplane, especially in terms of airports and airspace. Frankly, we’d never had to deal with something this big." Airbus applied to FAA for certification of the A380 in August 1998. The French certification process began the same year and was taken over by EASA when the latter agency started operations in 2003. The size and complexity of the aircraft required FAA to extend its normal five-year certification period for a large airliner to seven years. Troubled by delays, the A380 program suffered a blow last November when FedEx Express canceled its order for 10 A380-800F freighter versions, replacing it with an order for 15 Boeing 777 freighters. The first, 555-seat passenger version is slated to be delivered to Singapore Airlines in October. With a takeoff weight of 1.2 million pounds, the A380 is the largest and heaviest commercial airplane ever built.
FAA said flight tests to approve A380 operations on 150-foot-wide runways were expected to be completed in the second quarter. Meanwhile, the International Civil Aviation Organization was considering minimum separation criteria for airplanes operating behind an A380 in all phases of flight to minimize wake vortex effects.
Integrated Modular Avionics IMA modularity simplifies the development process of avionics software : * As the structure of the modules network is unified, it is mandatory to use a common API to access the hardware and network resources, thus simplifying the hardware and software integration. * IMA concept also allows the Application developers to focus on the Application layer, reducing the risk of defaults in the lower-level software layers. * As modules often share an extensive part of their hardware and lower-level software architecture, maintenance of the modules is easier than with previous specific architectures. * Applications can be reconfigured on spare modules if the module that support them is detected faulty during operations, increasing the overall disponibility of the avionics functions. Communication between the modules can use an internal high speed Computer bus, or can share an external network, as of ARINC 429 or AFDX. It must be noted that there is no overall hardware or software standard that defines all the mandatory components used in an IMA architecture. However, parts of the API involved in an IMA network has been standardized, such as: * ARINC 653 for the software avionics partitioning constraints to the underlying Real-time operating system (RTOS), and the associated API * AFDX for the data network bus. Examples of IMA architecture Examples of aircraft avionics that uses IMA architecture : * Rafale : Thales IMA architecture is called MDPU (Modular Data Processing Unit) [4][5] * F-22 Raptor * Airbus A380 [2][6] * Boeing 787 : GE Aviation Systems (formerly Smiths Aerospace) IMA architecture is called Common Core System [2][7] * Dassault Falcon 900, Falcon 2000, and Falcon 7X : Honeywell’s IMA architecture is called MAU (Modular Avionics Units), and the overall platform is called EASy[8] * Sukhoi Superjet 100
* ATR 42 * ATR 72 * Airbus A350 Avionics software Avionics software is embedded software with legally-mandated safety and reliability concerns used in avionics. The main difference between avionic software and conventional embedded software is that the development process is required by law and is optimized for safety. Interestingly, some claim that the process described below is only slightly slower and more costly (perhaps 15 percent) than the normal ad-hoc processes used for commercial software. Since most software fails because of mistakes, eliminating the mistakes at the earliest possible step is also a relatively inexpensive, reliable way to produce software. In some projects, however, mistakes in the specifications may not be detected until deployment. At that point, they can be very expensive to fix. The basic idea of any software development model is that each step of the design process has outputs called “deliverables.” If the deliverables are tested for correctness and fixed, then normal human mistakes can’t easily grow into dangerous or expensive problems. Most manufacturers follow the waterfall model to coordinate the design product, but almost all explicitly permit earlier work to be revised. The result is more often closer to a spiral model. For an overview of embedded software see embedded system and software development models. The rest of this article assumes familiarity with that information, and discusses differences from commercial embedded systems and commercial development models. Development process The main difference between avionics software and other embedded systems is that the actual standards are often far more detailed and rigorous than commercial standards, usually described by documents with hundreds of pages. Since the process is legally required, most processes have documents or software to trace requirements from numbered paragraphs in the specifications and designs to exact pieces of code, with exact tests for each, and a box on the final certification checklist. This is specifically to prove conformance to the legally mandated standard. Deviations from a specific project to the processes described here can occur due to usage of alternative methods or low safety level requirements. Almost all software development standards describe how to perform and improve specifications, designs, coding, and testing (See software development model). However avionics software development standards add some steps to the development for safety and certification: Human interfaces
Projects with substantial human interfaces are usually prototyped or simulated. The video tape are usually retained, but the prototype retired immediately after testing, because otherwise senior management and customers can believe the system is complete. A major goal is to find humaninterface issues that can affect safety and usability Hazard analysis Safety-critical avionics usually have a hazard analysis. Very early in the project, there’s usually at least some vague idea of the main parts of the project. An engineer then takes each block of a block diagram and considers the things that could go wrong with that block. Then the severity and probability of the hazards are estimated. The problems then become requirements that feed into the design’s specifications. Projects involving military cryptographic security usually include a security analysis, using methods very like the hazard analysis. Maintenance manual As soon as the engineering specification is complete, writing the maintenance manual can start. A maintenance manual is essential to repairs, and of course, if the system can’t be fixed, it won’t be safe. There are several levels to most standards. A low-safety product such as an in-flight entertainment unit (a flying TV) may escape with a schematic and procedures for installation and adjustment. A navigation system, autopilot or engine may have thousands of pages of procedures, inspections and rigging instructions. Documents are now (2003) routinely delivered on CD-ROM, in standard formats that include text and pictures. One of the odder documentation requirements is that most commercial contracts require an assurance that system documentation will be available indefinitely. The normal commercial method of providing this assurance is to form and fund a small foundation or trust. The trust then maintains a mailbox and deposits copies (usually in ultrafiche) in a secure location, such as rented space in a university’s library (managed as a special collection), or (more rarely now) buried in a cave or a desert location. Design and specification documents These are usually much like those in other software development models. A crucial difference is that requirements are usually traced as described above. In large projects, requirementstraceability is such a large expensive task that it pays for large expensive computer programs to manage it. Code production and review The code is written, then usually reviewed by a programmer (or group of programmers) that didn’t write it originally (another legal requirement). Special organizations also usually conduct
code reviews with a checklist of possible mistakes. When a new type of mistake is found it’s added to the checklist, and fixed throughout the code. The code is also often examined by special programs that analyze correctness (Static code analysis), such as SPARK examiner for the SPARK (a subset of the Ada programming language) or lint for the C-family of programming languages (primarily C, though). The compilers or special checking programs like “lint” check to see if types of data are compatible with the operations on them, also such tools are regularly used to enforce strict usage of valid programming language subsets and programming styles. Another set of programs measure software metrics, to look for parts of the code that are likely to have mistakes. All the problems are fixed, or at least understood and double-checked. Some code, such as digital filters, graphical user interfaces and inertial navigation systems, are so well-understood that software tools have been developed to write the software. In these cases, specifications are developed and reliable software is produced automatically. Unit testing “Unit test” code is written to exercise every instruction of the code at least once to get 100% code coverage. A “coverage” tool is often used to verify that every instruction is executed, and then the test coverage is documented as well, for legal reasons. This test is among the most powerful. It forces detailed review of the program logic, and detects most coding, compiler and some design errors. Some organizations write the unit tests before writing the code, using the software design as a module specification. The unit test code is executed, and all the problems are fixed. Integration testing As pieces of code become available, they are added to a skeleton of code, and tested in place to make sure each interface works. Usually the built-in-tests of the electronics should be finished first, to begin burn-in and radio emissions tests of the electronics. Next, the most valuable features of the software are integrated. It is very convenient for the integrators to have a way to run small selected pieces of code, perhaps from a simple menu system. Some program managers try to arrange this integration process so that after some minimal level of function is achieved, the system becomes deliverable at any following date, with increasing amounts of features as time passes. Black box and acceptance testing Meanwhile, the test engineers usually begin assembling a test rig, and releasing preliminary tests for use by the software engineers. At some point, the tests cover all of the functions of the
engineering specification. At this point, testing of the entire avionic unit begins. The object of the acceptance testing is to prove that the unit is safe and reliable in operation. The first test of the software, and one of the most difficult to meet in a tight schedule, is a realistic test of the unit’s radio emissions. This usually must be started early in the project to assure that there is time to make any necessary changes to the design of the electronics. Certification Each step produces a deliverable, either a document, code, or a test report. When the software passes all of its tests (or enough to be sold safely), these are bound into a certification report, that can literally have thousands of pages. The designated engineering representative, who has been striving for completion, then decides if the result is acceptable. If it is, he signs it, and the avionic software is certified. At this point, the software is usually very good software by any measurement.
