RSS
The INTEGRITY-178 tuMP RTOS is designed to be part of the Modular Open Systems Architecture (MOSA) solution. As such, it is designed to meet the critical high assurance standards and is certified for those listed in the table below that have a certification process (click on the links below to jump to that section.)
ARINC 653
The Aeronautical Radio, Inc. (ARINC) specification 653 series addresses the software operating environment for Integrated Modular (IMA), and can be applied to other safety-critical applications. The specification is a standard for time and space partitioning, which allows multiple applications of differing criticality to be run on the same hardware.
This provides a level of fault protection in that faults in one partition are not allowed to affect execution in other partitions. Green Hills Software is an active participant in the ARINC 653 technical committees.
ARINC 653 part 1 defines a general-purpose Application/Executive (APEX) software interface between the operating system of an avionics computer and the application software. The most recent updates, Supplements 4 and 5, add multicore processor service capabilities. Specifically, the standard requires “Concurrent use of multiple processor cores by processes within a partition” and “support for scheduling processes that can be run on one of the processor cores assigned to the partition.” Taken together, those require the task-core affinity of bound multi-processing (BMP). INTEGRITY-178 tuMP fully supports ARINC 653 part 1, including BMP mode and all of the required services.
AARINC 653 part 2 defines a set of optional services that, if implemented, may be used by an ARINC 653 compliant application. Green Hills Software offers five of the optional services: the file system, multiple module schedules, sampling port extensions, memory blocks, and multicore service extensions. See Layered Products for a description of each of those.
For non-ARINC 653 applications that need some access to ARINC 653 services, Green Hills Software provides the Port Subset (section 3.6) and the Health Monitor Subset (sections 2.4 and 3.8). These subsets are particularly useful for POSIX applications in a system adhering to the Future Airborne Capability Environment (FACE) technical standard, and for Ada applications using the GHS Safe-Tasking Ada Run-Time system (GSTART).
CAST-32A
The Certification Authority Software Team (CAST), including participants from the FAA, EASA, and TCCA, has published a position paper called CAST-32A that provides guidance on certification of software airborne systems executing on multicore processors (MCP). The main concern is interference between applications running on different cores due to delays in access to shared resources caused by contention from other cores. That interference could cause safety-critical applications to run in a non-deterministic or unsafe manner such that the application does not complete its safety-critical task in the time required.
As with most avionics safety standards, compliance to CAST-32A is the ultimate responsibility of the system integrator. That is a very challenging task, however, without significant support from the operating system to observe and mitigate the multicore interference.
In the same way that MMU support and partition schedules need to be implemented in the OS, the enforcement of the multicore interference mitigation needs to be in the OS in order to achieve robust multicore partitioning.
The INTEGRITY-178 tuMP multicore RTOS includes specific capabilities, tools, and libraries to directly address multicore interference and aid with CAST-32A compliance. Those capabilities provide multicore robust partitioning, which enabled INTEGRITY-178 tuMP to be the first and only RTOS to be part of a multicore certification to DO-178C and CAST-32A. INTEGRITY-178 tuMP includes a Bandwidth Allocation and Monitoring (BAM) capability to observe interference channels and mitigate them by controlling access to all shared resources. The system architect decides how much bandwidth to allocate to each core based on the functional requirements of the applications or design assurance levels. BAM enforces those allocations, thereby limiting the effect of any multicore interference not to exceed the maximum execution time for a given application. Green Hills Software also provides interference and DMA generating libraries to simulate interference beyond what is found in typical applications. Taken together, the interference and DMA generating libraries and the BAM runtime mechanism provide the tools necessary for a system integrator to determine multicore worst case execution times, mitigate interference, and minimize certification effort and risk for multicore systems.
For more details on CAST-32A objectives and how INTEGRITY-178 tuMP meets them, see our CAST-32A web page.
For more information, see our white paper "Solving Multicore Interference for Safety-Critical Applications."
DO-178B/C and ED-12B/C
DO-178 "Software Considerations in Airborne Systems and Equipment Certification" published by the Radio Technical Commission for Aeronautics (RTCA) is the primary standard for commercial avionics software development. Certification authorities such as the FAA, EASA, and Transport Canada all use DO-178 as an acceptable means for showing compliance with the applicable airworthiness regulations for the software aspects of airborne systems and equipment certification. The standard is a joint effort with EUROCAE and is referred to as ED-12 in Europe. Most certifications have been done with DO-178B/ED-12B, but now DO-178C/ED-12C is recommended for new efforts.
Different applications within an avionics system may have different levels of safety criticality, called Design Assurance Level (DAL). Levels range from DAL A, where a failure would be catastrophic, to DAL E, where a failure would have no safety impact. The requirements for higher levels are significantly greater in terms of number, difficulty, and amount of independence between development and verification.
INTEGRITY-178 tuMP has successfully met the DO-178B DAL A certification objectives multiple times, across several different multicore SOC architectures, each of which featured a different core design. Certification artifacts are now available for the latest revision, DO-178C, for multicore Intel, and Arm, and Power Architectures. Additionally, Green Hills Software has an FAA Designated Engineering Representative (DER) on staff and our customers can take advantage of this expertise to support certification of their own software.
DO-297
DO-297 “Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations,” published by RTCA, provides guidance on how to use high-performance computing platforms to host multiple applications on a single processor or a distributed network of processors. IMA enables increasing capabilities and complexity of avionics systems while reducing the size, weight, and power (SWaP) of those systems. Higher-level goals include providing cost-effective upgrade paths, introducing new operational capabilities, enabling fast and efficient maintenance, and avoiding premature obsolescence.
The primary duty of an IMA platform is to enforce robust partitioning that allows multiple applications to share a platform and its resources. Robust partitioning ensures any hosted application has no unintended effect on other hosted applications. As the main component at the IMA platform level, the operating system (OS) is responsible for implementing robust partitioning. In a multicore system, that includes mitigating multicore interference as described in CAST-32A.
The corresponding key characteristic of IMA applications running on the IMA platform is that applications are independently modifiable. This requires each application to be modifiable with little or no impact on other applications and the platform resources and modules. The capability to independently modify applications is necessary to meet the IMA goals of providing cost-effective upgrade paths and introducing new operational capabilities without retesting and reverifying the entire system. Multicore interference is a major obstacle to this goal because the interference from the modified application could cause an existing application not to execute correctly or vice versa. Therefore, to meet the objectives of DO-297, an operating system must implement a broad solution to mitigate multicore interference.
For more information, see our Tech Note “Multicore IMA Requires Multicore Interference Mitigation.”
DO-326 and DO-356
DO-326A/ED-202A “Airworthiness Security Process Specification” provides guidance on the processes to handle the threat of intentional unauthorized electronics interaction to aircraft safety. That unauthorized interaction includes threats such as the consequences of malware and forged data and the logical effects of external systems on aircraft systems. DO-356A/ED-203A “Airworthiness Security Methods and Considerations” is a companion document that provides one possible set of methods for complying with DO-326A/ED/202A guidance. It includes 14 principles at the aircraft level, system level, and item level ranging from “Defense in Depth” and “Prevent Bypass of Security Barriers” to “Independence & Isolation” and “Control Access to Connections.”
Unlike DO-178B/C, these documents provide guidance that is almost exclusively at the system level as opposed to the component level. As such, the main contribution by an operating system or hypervisor is to provide a secure base upon which the integrator can follow the guidance and meet the objectives. INTEGRITY-178 tuMP provides the most secure base of any operating system with its NAIP certification of NSA’s Separation Kernel Protection Profile (SKPP) to “HighRobustness”/EAL 6+. Because the SKPP directly addresses operating systems and includes penetration testing and analysis by the NSA, it is a proven path to providing the highest level of airworthiness security.
For more information, see our white paper “Creating a Trusted Embedded Platform for MLS Applications.”
FACE
The Future Airborne Capability Environment Consortium is a government and industry partnership to define an open avionics environment for all military airborne platform types. The FACE™ Technical Standard is the open avionics standard for making military computing operations more robust, interoperable, portable and secure. The standard defines five architectural segments, including the Operating Systems Segment.
The latest major update to the FACE Technical Standard, Edition 3.0, represents a significant 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 that claims support for multicore partitions to meet ARINC-653 Part 1 Supplement 4, including the requirement for multicore operation as defined in Section 2: “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.
As the only operating system supplier to be a founding member of the FACE Consortium, Green Hills Software is committed to certification of conformance to each update to the FACE Technical Standard. The INTEGRITY-178 tuMP RTOS was the first RTOS to be certified to Edition 3.0 as well as the previous Edition 2.1.1. In each case, certification includes:
- Both safety-base and security profiles
- Across Intel®, Arm®, and Power Architectures®
- With verified C, C++, and Ada support
Example deployments with INTEGRITY-178 tuMP that required FACE conformance include:
- U.S. Navy Tactical Combat Training System Increment II (TCTS II)
- Embedded GPS/INS-Modernization (EGI-M) program for Northrop Grumman
- U.S. Army Improved Data Modem (IDM-401) Multicore Software Upgrade
- Terma North America’s AN/ALQ-213(v5) Electronic Warfare Controller, deployed in the U.S. Air Force F-16
- CMC Electronics’ PU-3000 Avionics Computer, which is deployed in a military wide-body jet engine aircraft
MOSA
In January 2019, the Secretaries of the Army, Navy, and Air Force issued a joint memorandum on “Modular Open Systems Approaches for Our Weapons Systems is a Warfighting Imperative.” That memorandum states that MOSA supporting standards, such as the FACE Technical Standard, should be included in all requirements, programming, and development activities to the maximum extent possible. As the only founding member of the FACE Consortium from the RTOS community, Green Hills Software supports the MOSA concepts and approach and is committed to open systems architectures.
Through our hardware partners, Green Hills Software extends our MOSA ecosystem to include solutions that combine our FACE conformant operating system with SOSA aligned processor boards. For example, see:
"Raise the Bar" for Cross Domain Solutions
Raise the Bar (RTB) is a set of cybersecurity standards published by the National Cross Domain Strategy & Management Office (NCDSMO) in the National Security Agency (NSA). First published in 2018, the RTB standards are a set of security guidelines and requirements for cross domain solutions (CDS) deployed by the U.S. government to protect National Security Systems. The RTB standards go well beyond the National Institute of Standards and Technology’s (NIST) Risk Management Framework (RMF) controls that many government agencies implement. RTB standards ensure that CDS systems are at low risk of failing, even under persistent attack. RTB is designed to combat evolving threats by continually improving CDS effectiveness. CDS systems are a critical part of a multi-domain operational environment where warfighters need data at their fingertips to make real-time decisions.
INTEGRITY-178 tuMP is the first and only RTOS to be part of a successful certification to Raise the Bar standards. The ability of the RTOS to meet this evolving set of standards is directly rooted in the INTEGRITY-178 pedigree of achieving the NSA-defined Separation Kernel Protection Profile (SKPP) for “High Robustness” and Common Criteria EAL6+.
For more details on how INTEGRITY-178 tuMP was used in a system certified to the RTB standards, see our Raise the Bar web page.
POSIX
The INTEGRITY-178 tuMP RTOS is designed to support applications of various criticalities, including applications that do not require certification evidence for the COTS libraries linked directly with the applications. For such applications, INTEGRITY-178 tuMP provides two types of support for subsets of the Unix compatible Portable Operating System Interface (POSIX) run-time environment.
INTEGRITY-178 tuMP supports the SCA POSIX run-time environment, defined in Software Communications Architecture (SCA) Specification. The SCA POSIX profile is based upon the Real-time Controller System Profile (PSE52) as defined in IEEE Std 1003.13-1998, POSIX 1003.13: Standardized Application Environment Profile – POSIX Realtime Application Support (AEP). Within the context of support for the FACE techincal standard, INTEGRITY-178 tuMP supports the subset of POSIX (IEEE std 1003.1-2008) APIs defined in each supported FACE profile, namely the Security Profile and the Safety Base profile.
SKPP and Common Criteria
In 2007 the Information Assurance Directorate of the US National Security Agency (NSA) published the “U.S. Government Protection Profile for Separation Kernels in Environments Requiring High Robustness” Version 1.03. A separation kernel’s primary security function is to partition or separate the subjects and resources of a system into security policy-equivalence classes, and to enforce the rules for authorized information flows between and within partitions. A high robustness product is necessary protection for environments where the presence of both sophisticated threat agents and high-value resources makes the likelihood of an attempted compromise high.
That Separation Kernel Protection Profile (SKPP) is based on “Common Criteria for Information Technology Security Evaluations, Version 2.3.” The SKPP starts with the set of Common Criteria requirements for Evaluation Assurance Level 6 (EAL6) and then adds 17 more functional requirements and 19 more assurance requirements. In addition, numerous Common Criteria requirements were refined in the SKPP.
In 2008, the INTEGRITY-178 RTOS became the first and only commercially available operating system to be certified to the SKPP and to the Common Criteria for IT Security Evaluation (Version 2.3) to assurance level EAL 6+, High Assurance. The certification involved direct analysis and testing by the NSA. That included both covert channel testing by the NSA to demonstrate that the product satisfies covert channel mitigation metrics and vulnerability analysis and penetration testing by the NSA to demonstrate that the product is resistant to an attacker possessing a high attack potential.
In 2011, the NSA ceased general certification to the SKPP in favor of evaluating OSes and separation kernels as part of specific government systems in the context of specific programs. NSA continues to recommend the use of separation kernels and the requirements in the SKPP. Programs of record continue to use the requirements in the SKPP as a path for system certification to high robustness.
