Integrated Modular Avionics and ARINC 653
What is ARINC 653?
ARINC Specification 653 is a specification for a computer hardware partitioned APEX (APplication/EXecutive) interface for Integrated Modular Avionics (IMA) systems and other safety-critical environments.
ARINC Specification 653 was defined by leading aerospace companies to create an industry standard for a time and space partitioning operating system. Applications are separated into discrete Memory Management Unit (MMU)-controlled partitions on a single processor. Each partition is guaranteed a slice of time for execution as specified by the system designer. Threads inside each MMU-controlled partition are scheduled on a priority-preemptive basis, like a standard real-time operating system (RTOS).
This specification is available from Aeronautical Radio, Inc. (ARINC)
Why was ARINC 653 invented?
For decades, hardware-centric federated compute architectures dominated both military and commercial aircraft systems, where capabilities were loosely networked together with a quite simple connectivity scheme. The automotive industry had the same architecture where the supply chain delivered components with pure mechanical, and sometimes, simple electro-mechanical capabilities. These were decades when the volume of software on aircraft (and automobiles) was small.
As aircraft designs advanced, the use of software increased, as did the demand for on-board computer systems. Each of these federated systems, usually delivered by different suppliers, typically included an enclosure, redundant power supplies, redundant compute systems with RTOSs, board support packages (BSPs), network/connectivity software and finally federated software applications. This is great for maintenance -- one simply swaps out the federated box and replaces it with another. But as the volume of software applications increases on an aircraft, basing things on individual federated systems becomes untenable due to concerns about size, weight, and power, and related costs (SWAP-C), which is a critical design criterion for aircraft.
Federated compute architectures typically include a hardware enclosure, redundant power supplies, redundant compute systems with RTOSs, board support packages (BSPs), network/connectivity software and finally federated software applications. This is great for maintenance -- one simply swaps out the federated box and replaces it with another. But as the volume of software applications increases on an aircraft, basing things on individual federated systems becomes untenable due to SWAP-C concerns.
ARINC 653 addresses these SWAP-C issues. ARINC 653 systems are typically a singular compute platform, supplied with triple redundant processors, power supplies and network connections. Most of the application software on the aircraft is hosted on a time-and-space partitioned environment with other application software (there still may be a few federated systems on the aircraft). This ARINC 653 environment removes the requirements for every software component to have its own heavyweight hardware, RTOS, power and network infrastructure -- only application software is delivered to the aircraft systems integrator.
In modern software-centric aircraft, this IMA architecture can save over one thousand pounds, opening the opportunity to fly further, as well as fly more passengers, cargo, or fuel, thanks to these SWAP-C savings.
For more information, see 1ARINC 653 Avionics Application Software Standard”, published by SAE International, August 2015, https://www.sae.org/standards/content/arinc653p1-4/
What is RTCA DO-297?
ARINC 653 changed the business model for software-defined avionics – instead of suppliers bringing their hardware-defined federated compute components to an aircraft systems integrator, each application software supplier only delivers the software and configuration data. Because dozens of software suppliers were now integrating and certifying their product on a single compute platforms, a new business process was developed, RTCA DO-297, “Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations”, that defines three supplier roles that contribute hardware and software on a shared IMA platform to manage the complexity and cost of merging and integrating mixed safety level software components on a flight-critical platform.
What are the 3 Supplier Roles of RTCA DO-297?
Effectively use of RTCA DO-297 guidance should result in Application Suppliers working independently work on their specific deliverable using only the IMA platform library supplied by the Platform Supplier, and not be exposed to unexpected responsibilities, cost, and risk. DO-297 provides clear guidance and separation of all IMA suppliers and subcontractors, allowing them to focus on delivering their contributions to the system, including the relevant RTCA DO-178C avionics safety certification artifacts.
The three DO-297 supplier roles are:
- IMA Platform Supplier: Prepares the hardware compute environment, OS/RTOS, board support package (BSP), aircraft platform capabilities, and the communication infrastructure for applications, as well as all related safety and security certification evidence.
- Multiple IMA Application Suppliers: Provide hosted software functions, with appropriate certification evidence, which execute in protected and separate ARINC 653 partitions.
- IMA System Integrator: Integrates software delivered from both the IMA Platform Supplier and the IMA Application Suppliers and supports the entire aircraft effort to achieve platform airworthiness.
What are the 3 Supplier Roles of RTCA DO-297?
Effectively use of RTCA DO-297 guidance should result in Application Suppliers working independently work on their specific deliverable using only the IMA platform library supplied by the Platform Supplier, and not be exposed to unexpected responsibilities, cost, and risk. DO-297 provides clear guidance and separation of all IMA suppliers and subcontractors, allowing them to focus on delivering their contributions to the system, including the relevant RTCA DO-178C avionics safety certification artifacts.
The three DO-297 supplier roles are:
- IMA Platform Supplier: Prepares the hardware compute environment, OS/RTOS, board support package (BSP), aircraft platform capabilities, and the communication infrastructure for applications, as well as all related safety and security certification evidence.
- Multiple IMA Application Suppliers: Provide hosted software functions, with appropriate certification evidence, which execute in protected and separate ARINC 653 partitions.
- IMA System Integrator: Integrates software delivered from both the IMA Platform Supplier and the IMA Application Suppliers and supports the entire aircraft effort to achieve platform airworthiness.
How does RTCA ARINC 653 and DO-297 increase efficiency and reduce costs?
There are three areas where ARINC 653 and DO-297 increase efficiency and reduce costs:
1. SWAP-C. By integrating the capabilities of dozens of federated avionics systems onto a shared ARINC 653 compute platform frees up aircraft space, reduces the footprint of the compute platform, drastically reduces power consumption, and eliminates federated systems wiring. On larger aircraft this can eliminate around 1,000 pounds, enabling increased performance and flight efficiency.
2. Development Tools. Instead of each supplier licensing their RTOS, development tools, application software libraries, and more, IMA platforms have a common, shared development environment. Only the IMA Platform Supplier needs to procure a full array of tooling to create an ARINC 653 RTOS, board support packages, application libraries, network drivers and more. The IMA software applications, many having different levels of safety criticality, only need to have enough tooling to compile/debug their software, create certification evidence, and link it to the IMA Platform binary. In the spirit of ARINC 653 platform consistency and cost containment, this IMA Platform binary is usually provided at no cost to all suppliers, driving both uniformity and cost efficiency throughout the DO-297 supply chain.
3. Single platform efficiency. Because all the suppliers use a common platform, and do not need to purchase independent hardware platforms and software tooling, the overall cost of an IMA environment is, by design, far more cost efficient.
What are the benefits of using MOSA?
The main benefits of using a MOSA are:
- The opportunity for significant cost-saving or avoidance
- Schedule reduction and faster deployment of innovative technology
- More opportunities for technical upgrades and refresh
- Greater interoperability, including the system-of-systems interoperability and integration of mission component
- Other benefits, including lower costs and faster deployment of the latest, more relevant defense technologies
Reference: https://www.dsp.dla.mil/Programs/MOSA/