Multicore operating system completes certification of conformance
Specialist in high-assurance operating systems, Green Hills Software, has announced that it has achieved certification of conformance of its INTEGRITY-178 Time-Variant Unified Multi Processing (tuMP) real-time operating system (RTOS) to the Future Airborne Capability Environment (FACE) Technical Standard edition 3.0. The certification covers both the Safety Base profile and the Security profile.
The INTEGRITY-178 tuMP RTOS is the first software component of any type to be certified conformant to edition 3.0, which underscores the commitment of Green Hills Software for certification to open standards.
Version 3.0 of the FACE Technical Standard represents a major improvement over the prior version 2.1.1 in that it addresses the use of multicore processors in safety-critical applications. The technical standard now requires any Operating System Segment (OSS) that claims support for multicore partitions to meet ARINC-653 Part one Supplement four, including the requirement for multicore operation as defined in Section two: ‘Multiple processes within a partition scheduled to execute concurrently on different processor cores’. In ARINC-653, each application is called a partition and has its own memory space.
Asymmetric Multi-Processing (AMP), the simplest software architecture in a multicore-based system, is not sufficient to meet the requirements of Supplement four. INTEGRITY-178 tuMP is the only certified FACE-compliant operating system to meet the requirements of ARINC-653 Supplement four, and it does so with the availability of Bound Multi-Processing (BMP) in addition to AMP and Symmetric Multi-Processing (SMP).
By definition, BMP is an enhanced and restricted form of SMP that can statically bind an application’s ARINC-653 processes to a specific set of cores, allowing the system architect to more tightly control the concurrent operation of multiple cores. INTEGRITY-178 tuMP allows the system developers to bind ARINC-653 processes within an application to a core using an API or using the system configuration file. In addition, INTEGRITY-178 tuMP meets the ARINC-653 Part two Supplement three requirements for SMP operation.
“The ability to execute an application across a user allocated core or group of cores in a bounded and time-partitioned manner is necessary for achieving maximum performance and minimum size, weight, and power for Integrated Modular Avionics (IMA),” said Dan O’Dowd, Founder and Chief executive officer of Green Hills Software. “Our INTEGRITY-178 tuMP multicore RTOS was designed specifically to provide full multiprocessing capability while still providing the mechanisms to ensure true modularity of the system and the deterministic operation needed to meet the highest design assurance level, DO-178C level A.”
INTEGRITY-178 tuMP supports all combinations of AMP, SMP, and BMP in a time-partitioned manner on a multicore processor. Meeting worst-case execution times (WCET) while multiple cores are executing concurrently can be very challenging no matter the choice of AMP, SMP, or BMP. Contention from multiple cores trying to access a given shared resource, such as memory or I/O, can create interference between cores. Certification authorities have emphasized their concerns about such interference by including objectives for interference identification, mitigation, and verification in the CAST-32A position paper.
As a true multicore IMA operating system with a proven over eight year service history, INTEGRITY-178 tuMP includes both a fully capable multicore scheduler and support for bandwidth allocation and management of shared processor resource access. The supported bandwidth management technique emulates a high-rate hardware-based approach to ensure continuous allocation enforcement.
These capabilities lower integration and certification risk, while also enabling the integrator to manage significant software retest costs that would occur when a software application changes or is added. Without operating system features and support for bandwidth management of the shared multicore resources, such software changes would require analysis and retest of all other potential concurrent applications.
