Realizing MOSA objectives: the developer’s role
StoryFebruary 15, 2023
Will Keegan
Lynx Software Technologies
Embedded software vendors for defense applications have a confession to make: There is more they can do to support customers adopting the modular open system approach (MOSA). Current platform components are not truly portable and hidden dependencies undercut real interoperability. There is, however, a path to improve developers’ ability to realize MOSA objectives.
The high-level benefits of open system standards all sound very logical and compelling. There’s avoiding vendor lock in, reductions in license and development costs and the benefit of leveling market competition. Vendors are obliged to adapt their products to the standards and to stay engaged with the community as requirements and technology evolves. The imposed cost to participate may be steep, but it’s clear that the lack of standardization costs more to the supply chain.
The complexities of MOSA
Nearly all the sought-after benefits of open system initiatives in the defense community – including the U.S. Army MOSA [Modular Open Systems Approach] Transformation Office, U.S. Air Force OMS, and the U.K. MoD Pyramid – hinge on engineers’ ability to effectively reuse system components across different software platforms and/or product lines. Progress has been made at the hardware line replaceable unit (LRU) level but for software, technical specifications lack coverage to meet the intent of MOSA. So, let’s dive in and discuss some of the weaknesses in our modular standards that prohibit customers from achieving those compelling benefits.
Ideally, we want to enable system integrators to insert a software component into a system as easily as inserting a VPX card into a chassis. The current reality is that porting software across operating system] platforms is more akin to performing heart transplant surgery than it is like replacing a line card!
Although standards like the Future Airborne Capability Environment (FACE) Technical Standard describe interfaces of libraries that applications can link into to use operating system services, these interfaces only include descriptions for software that can run in the user application space. The standards lack descriptions of expected behavior and side effects that can inform real-time and hazard analysis. They do not account for the system information that’s needed to build, integrate and configure a comprehensive system to behave correctly. They also do not cover software components that reside in the operating system itself, such as drivers and health monitors.
When building an LRU, it is common to have a software platform development team comprised of multiple companies each contributing a subsystem component: for example, MIL-STD 1553 driver, GPU driver, Ethernet driver with network stack integration, boot security modules, continuous built-in-test modules, and the like. The majority of the software is written against nonstandard kernel-level APIs and is packaged against proprietary configuration tools. The system integrator will integrate and qualify the complete system. This job can be incredibly inefficient if stakeholders have no common understanding of a component and how to qualify it before passing it on to the integrator. (Figure 1.)
[Figure 1 | A diagram shows portability factors.]
It’s also common to see huge investments in surrogate labs in which the entire mission system is loaned out to development teams to validate components against accuracy constraints. The project can easily reach into the hundreds of million dollars. A large portion of the software developed will be funded with taxpayer dollars, which means that the use and reuse rights are determined by the government. However, the software will not be easily transferable to another platform. As a result, once such an investment has been made in a specific software platform, that platform will have an extreme competitive advantage because it’s government-funded. (Figure 2.)
[Figure 2 | Shown: A diagram of the cost structure of different programs.]
Standardizing is the solution
The key to untangling this situation is to standardize the ability to compose and validate complete software stacks out of substitutable components while improving the mechanics of composing and validating systems. If the government funds the development of a driver, a prime integrator should be able to reuse the driver in a different operating system with little to no modification.
The solution is basically the adoption of two enabling technologies to improve the mechanics and feasibility of real-time composability, namely hypervisors, which are used to partition resources and allocate components as individual virtual machines; and unikernels, which can be used as the runtime environment for each individual components instead of traditional guest operating systems to improve resource utilization and timing properties.
Hypervisors: adding control
The key difference in the hypervisor approach versus the operating system approach is the hypervisor’s ability to give components the control to manage their own local set of resources. A hypervisor-hosted component is a complete software module that can run on its own and is highly portable. Conventional operating systems, where software components are incomplete in their ability to run without linking to operating system libraries, impose a codependency that limits reusability.
Hypervisors also provide more independence between components and enable more robust architectures for layering safety and security reference monitors. The attack surface of a hypervisor is also significantly smaller than that of an operating system.
Hypervisors add resource and computational overhead and safety concerns from inserting an additional layer of complexity to the software stack. However, a different deployment strategy can make them very effective in making systems simpler and more predictable. This is where unikernels come in.
Unikernels enable all operating systems
Unikernels enable programs to link in all operating system services in a single address space, obviating the need to switch into a special kernel mode to call a system service. Applications hosted by the operating systems impose barriers that force applications to exit their context and enter a common kernel space to fulfill the request of calling processes.
In the unikernel architecture, applications just link to the operating system features needed. The compiler will naturally omit unused features. Because unikernels are no longer context switching and subject to blocking by competing processes, unikernel execution behavior is much easier to observe and characterize. This reality reduces the burden of multicore timing analysis and makes the safety-certification process more manageable. The intrinsic independence and timing properties of a unikernel simply make it a better unit of integration to compose systems where the integrity and predictability of a system is simpler to verify.
Advancing the concept further, a unikernel wouldn’t just be a task or an application: it would constitute subsystems as well. Combining unikernels with hypervisors enables architects to compose systems with a higher level of fidelity and also gives them the option to explicitly create pipelines of software stacks out of individual unikernel components, where the components can assume roles of kernel services like network stacks and device drivers. (Figure 3.)
[Figure 3 | Unikernels plus hypervisors enable builders to compose more sophisticated systems.]
As we suggest modeling systems as an integration of software pipelines, it is absolutely critical to uphold the MOSA vision by ensuring components are linked via standard interfaces that exhibit the ability to interoperate in other pipelines for more than 10 years. Hypervisors are very well-suited to satisfy this concern, as they already have well-established standards to handle virtual machine-to-virtual machine interfaces via the OASIS VirtIO specification and virtual machine-to-physical machine interfaces reusing standard specifications such as PCI Express.
Hypervisors and unikernels are key to developing platform-level components without the dependency on proprietary kernel libraries. With the improved timing and performance properties of unikernel architecture, the performance and predictability of unikernel pipelines can easily match the real-time characteristics of RTOS [real-tiime operating system] services. Much work remains to be done in the areas of standardization efforts and refining the techniques of linking components with real-time constraints.
Will Keegan is the chief technology officer at Lynx Software Technologies. At Lynx, Will manages the safety and security platform product visions, interfaces with industry working groups and partners, and works with regulatory authorities for design review/risk mitigation.
Lynx Software Technologies https://www.lynx.com/
