Traditionally, airplane systems have been designed and implemented in a federated fashion with each system providing for its own needs. A typical airplane system could be made up of one or more black boxes each having its own enclosure and providing for its own power conditioning and cooling needs. I/O signal conditioning and computational processing necessary to provide the intended function is also provided on a box-by-box basis. With each new generation of airplanes, the number of systems increased. Driven by market forces the need grew to reduce weight and electrical power to keep the airplane fuel efficient, cost-effective, and competitive. To address this contradiction, the Integrated Modular Avionics (IMA) concept was born. Within IMA architectures, avionics functions share common resources. Multiple black boxes are optimized to the minimum IMA resources necessary. This optimization provides the sought-after weight and power savings, and also provides for a much reduced number of parts to be maintained and controlled. These are all beneficial for the airplane manufacturer and airplane operator. However, IMA architectures present some unique challenges during their development and integration. This will explore some of the more significant of these integration challenges associated with IMA architectures, including: What is the system? For the supplier whose system has been selected to be hosted on the IMA platform, the boundaries can be unclear. What was once a box with circuit cards and substance has been abstracted to a software application. Connection to other systems or to sensors/effectors was via airplane wiring. Now, complex in-line electronics modules exist that the supplier knows little or nothing about. For the provider of the IMA platform, the system may be defined as a set of available resources (processing, communication, I/O, etc.) to be shared by the systems to be hosted. To the airplane manufacturer the system is a working suite of avionics. With the IMA approach: "Who is responsible for ensuring that boundaries and expectations are clearly defined and understood so that nothing gets overlooked?" Who is the system integrator? Within the IMA environment the answer changes depending on your perspective. The supplier of a hosted function may be considered responsible for the integration of their system components. The IMA platform provider may believe they are responsible for the platform elements. The airplane manufacturer wants an integrated solution. With the IMA approach: "Who is responsible for ensuring that the whole is equal to the sum of its parts?" How is the integration of an IMA architecture handled? As more and more of the hosted systems are brought together, IMA architectures can present challenges not seen with federated systems. The nature of IMA architectures requires more of the components to be available and working to allow seemingly simple tasks to take place. With the IMA approach: "Who is responsible for ensuring that this integration is planned and executed in the optimum sequence?"
