Skip to the main content.

Did you know?

 

RTI is the world’s largest DDS supplier and Connext is the most trusted software framework for critical systems.

Tiered-Support-Plan-DatasheetTiered Support Plans

Our Professional Services team brings extensive experience to train, problem-solve, mentor, and accelerate customer success.

Learn more

Developers

From downloads to Hello World, we've got you covered. Find all of the tutorials, documentation, peer conversations and inspiration you need to get started using Connext today.

Try the Connectivity Selection Tool ⇢

Resources

RTI provides a broad range of technical and high-level resources designed to assist in understanding industry applications, the RTI Connext product line and its underlying data-centric technology.

Company

RTI is the largest software framework company for autonomous systems. The company’s RTI Connext product enables intelligent architecture by sharing information in real time, making large applications work together as one.

Contact Us

News & Events
Cooperation

5 min read

Why Don’t Airborne Systems Use Containers and Kubernetes?

Why Don’t Airborne Systems Use Containers and Kubernetes?


Part 14 of the RTI Military Avionics Blog Series

Life would be a lot easier if we simply could travel down the path of least resistance. However when creating highly competitive safety-critical avionics systems, this is not possible. The rigor of designing, developing and deploying with certified conformance to the RTCA DO-178C safety standard drives manufacturers down a path of high discipline, high investment and high commitment to achieve airworthiness. In today's commercial and military systems, this rigor is non-stop when it comes to creating highly compelling solutions that provide distinct competitive advantages over both fellow suppliers and military adversaries. 

These solutions need to be deployed in a wide range of trusted compute environments. A fairly recent innovation, Containers, are lightweight packages of application code coupled together with application dependencies, such as programming language runtimes and the operating system libraries required to run software services in enterprise or cloud environments. Containers share CPU, memory, storage and network resources at the operating systems level and offer a logical packaging mechanism where applications are abstracted from the environment in which they execute. Containers enable productivity by maximizing application compatibility to deployed operating system environments, while resulting in the fewest sacrifices in terms of performance and security properties. 

Container technology continues to evolve and mature,  and provides the following four advantages:

  1. Application Isolation. Containers virtualize CPU, memory, storage, and network resources at the operating system level, providing developers with a view of the OS logically isolated from other applications.  Whether deployed on hypervisors or natively on operating systems, containers maintain the property of isolation, where the container-deployed applications inherently have a strong level of independence between the host operating system and other containers deployed on the same compute platform.
  2. Application / Workload Portability. Containers can run virtually anywhere, on any operating system, including Linux, Windows, and Mac operating systems. Containers exist on most enterprise computer environments, including virtual machines or on physical servers, from developer workstations to on-premises servers to cloud platforms.
  3. Separation of Responsibility. Containerization provides a clear separation of responsibility, as developers focus on application logic and dependencies, while IT operations teams can focus on deployment and management instead of application details such as specific software versions and configurations.
  4. Manageability - The Open Container Initiative (OCI) community, an open governance structure for creating open industry standards around container formats and runtimes, has established a framework where the process of developing, testing, integrating, maintaining and fielding software components and APIs.  In a DevOPs environment, containers can be viewed as a standard unit of “work”, where the work will vary as the container’s role transitions throughout the major lifecycle phase. 

Containers in Enterprise and Mission Systems

Containers are not virtual machines (VMs). Containers are much more lightweight than VMs, because containers virtualize at the OS level, while VMs virtualize at the hardware level.  VMs are typically managed by a VM monitor, also known as a hypervisor, that creates and runs virtual machines (VMs), allowing host computers to support multiple guest VMs by virtually sharing their resources, such as memory and processing.   

How does one manage the deployment of containers? Today, most organizations use Kubernetes, an open-source container orchestration system, for dynamically automating software deployment, scaling, and management of containerized applications.

The name Kubernetes originates from Greek, meaning helmsman or pilot. Kubernetes is often abbreviated as K8s, counting the eight letters between the "K" and the "s", but either term is pronounced  “coo-be-net-ees”.  Google open-sourced the Kubernetes project in 2014 and the project is now maintained by the Cloud Native Computing Foundation (CNFC), which is part of the Linux Foundation.  

Kubernetes-1-1

What about Docker?

Docker is a commercial implementation of containers that is now supporting open source efforts for open standards for container technology.  In June 2015, Docker donated the container image specification and runtime code now known as runc, to the Open Container Initiative (OCI) to help establish standardization as the container ecosystem grows and matures. Furthermore, in 2017, Docker donated the containerd project to the CNCF;  containerd is the core container runtime of the Docker Engine.

Airborne Containers

Containers dynamically managed by Kubernetes can also run in airborne systems. The best fit for these environments is “back of the airplane” mission systems that do not have strict real-time performance, high security demands, and/or high levels of RTCA DO-178C safety certification requirements. In many cases these mission systems run on enterprise, non-rugged hardware.

Airborne systems also use container concepts in embedded edge devices in ruggedized airborne platforms that have more strict real-time requirements. Most of these systems are flight or mission critical systems that must support multiple levels of safety and security, requiring the development and deployment rigor to be much higher than enterprise compute systems. 

Safety-Critical Containers/Partitions

In this embedded edge airborne environment, containers are called partitions, and they strictly follow an open avionics standard titled ARINC 653, that is proven in well over 100 different commercial and military aircraft types, including the helicopters from Airbus, Bell, Boeing, and Lockheed Martin Sikorsky, and commercial fixed wing aircraft from Airbus, Boeing, Embraer and more. These aircraft have a robust ecosystem of Tier 1 platform suppliers including Collins Aerospace, Elbit Systems, GE Aerospace, Honeywell Aerospace and Thales Aerospace that have been supplying ARINC 653 solutions for over two decades with the highest level of safety certification evidence, RTCA DO-178C Design Assurance Level (DAL) A. These platforms are underpinned with proven real-time operating system (RTOS) suppliers including, DDC-I, Green Hills Software, Lynx Software, Blackberry QNX, Sysgo, Wind River and others that can supply both commercial DO-178C DAL A safety certification evidence and a wide range of security certification solutions.

Like enterprise containers, ARINC 653 partitions support application isolation, application workload portability, and separation of responsibility, and virtualize at the partition OS level, not at the computer hardware level, but do this statically, not dynamically, to meet strict safety requirements.  Due to the high cost and rigor associated with developing and deploying high multi-level safety and security certification evidence for airworthiness, the ARINC 653 supply chain follows another open industry standard, RTCA DO-297, that details the roles and responsibilities of each supplier in an ARINC 653 system, which reduces program development and operational costs and risks, driving efficiency throughout the entire platform life cycle. (See the RTI Military Avionics Series Blog 1 and Blog 2 for more information about ARINC 653 and DO-297.)

Unlike enterprise containers that use Kubernetes for orchestration, ARINC 653 partitions are statically defined and strictly managed by vendor-specific tools that integrate XML partition resource declarations into a file or binary that enables accelerated DO-178C certification. Most of these tools have RTCA DO-330 tool qualifications that optimizes many of the requirements for achieving airworthiness. DO-330 requires the same software development rigor as airborne software (at the cost of $100-$500 per line of code), so Kubernetes, with over a million lines of code, is not a good candidate for DO-330 tool qualification1.  

ARINC 653 is the open standard that is a fundamental component of the Open Group Future Airborne Capability Environment™ (FACE) Operating System Segment (OSS). Use of the FACE standard is required in all US Army Future Vertical Lift (FVL) programs including Future Attack Reconnaissance Aircraft (FARA) and Future Long Range Assault Aircraft (FLRAA) aircraft. In addition, airborne applications may use a shared data model for unambiguous data representation, and be deployed using shared security domains to increase efficiency and application management.

Safety-Critical Partitions Versus Mission-Critical Containers

 

Safety Critical

Mission Critical

Application Isolation

Yes

Yes

Workload Portability

Static

Dynamic

Partition Allocation Model

Static

Dynamic

Separation Capability 

ARINC 653 Partitions

Containers, VM

Partition Enforcement

Hardware Partitioning

Software Partitioning

Virtualization Level

OS Level

OS Level

Core Utilization

Asymmetric Multiprocessing (AMP)

Symmetric Multiprocessing (SMP)

Management

RTOS-specific tools

Open Container Initiative (OCI) tools

Airborne Safety

RTCA DO-178C (DAL A-E)

RTCA DO-178C (DAL D-E)

Supply Chain Management

RTCA DO-297, TSO C214

Enterprise, RTCA DO-297 Process

Supply Chain Diversity

Many

Many

Security Capabilities

Single-Level Security (SLS)

Multi-Level Security (MLS)

Multiple Independent Levels of Security (MILS)

Single-Level Security (SLS)

Multi-Level Security (MLS)

Supports RTI Connext

Yes

Yes

Supports RTI Connext Secure

Yes

Yes

Supports RTI Connext Micro

Yes

Yes

Supports RTI Connext Cert 

Yes

Yes, but outside its target use case

 

RTI, with its Connext product line coupled with its powerful partner ecosystem, runs in all these container and partition environments, from the connected edge to cloud environments.  Connext is transport agnostic, OS/RTOS agnostic, and hardware agnostic – we do not constrain your design environment. We enable the use of the most powerful execution and deployment solutions found in the industry. 

RTI is proud of the role we play in contributing to advanced solutions supporting data-centric applications for our global commercial and military avionics customer base.  

To read other installments in the RTI Military Avionics Blog Series, please click here.

1Not yet proven for RTCA DO-178C DAL D-E certification to date

 

About the author

Chip Author HeadshotChip Downing is Senior Market Development Director, Aerospace & Defense, Real-Time Innovations, Inc.

Chair, FACE Business Working Group Outreach Subcommittee