Electronics Weekly Electronics Design & Components Tech News
Embedded software vendors 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.
The high-level benefits of open system standards, such as avoiding vendor lock-in, reducing licence and development costs and levelling market competition, sound logical and compelling. Vendors are obliged to adapt their products and to stay engaged with the community as requirements and technology evolve. The cost to participate may be steep, but it is clear that the lack of standardisation affects the supply chain.
Modular means reuse
Benefits of open system initiatives in the defence community – including the US Army Mosa Transformation Office, US Air Force OMS (Open Mission Systems) and the UK MoD Pyramid – hinge on engineers’ ability to effectively reuse system components across 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 behind modular open systems.
This becomes even more important with initiatives such as the Global Combat Air Programme announced in December 2022. The programme unites the Future Combat Air System project led by Britain and Italy (resulting in the Tempest jet) with the Japanese F-X programme.
Systems that are enhanced by capabilities that include crewless aircraft, advanced sensors and weapons are extremely complex. No one company, indeed no one nation, can deliver all of the functionality required, so teaming arrangements are created to integrate ‘best-of-breed’ system modules into airframes. The pressure on time to market is intense as countries look to deliver functionality that can maintain leadership. These expensive platforms are set to be in production for decades so there is a desire to avoid vendor lock-in and to reuse proven technology in other platforms.
There have been recent announcements from a number of European countries related to the adoption of the American F-35 Joint Strike Fighter and the reliance on another country/continent for defence equipment is a concern to some European governments.
Move to Mosa
All of this points to modular systems being a good idea. In the US, the modular open system approach initiative is being driven by the US Army. The challenge is the level at which that modularity is defined in this and in other standards and the impact on the mission critical elements of those systems. These are the ones that simply have to work in a deterministic way all of the time.
One of the weaknesses in modular standards is integration. Ideally, system integrators would insert a software component as easily as inserting a VPX card into a chassis. The current reality is that porting software across OS platforms is more akin to performing heart transplant surgery than it is like replacing a line card.
Standards like Face (Future Airborne Capability Environment) and Pyramid describe interfaces of libraries that applications can link to and use OS services. These interfaces, however, only include descriptions for software that can run in the user application space. The standards lack descriptions of expected behaviour and side effects that can inform real time and hazard analysis. They do not account for the system information that is 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 consisting of multiple companies, each contributing a subsystem component, such as a 1553 driver, GPU driver, Ethernet driver with network stack integration, boot security module, and continuous built in test modules.
Most of the software is written against non-standard 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.
Standardisation drive
The key to untangling this situation is to standardise the ability to compose and validate complete software stacks out of substitutable components while improving the mechanics of composing and validating systems. If a 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 (Figure 1).
Adopting two enabling technologies can improve the mechanics and feasibility of real-time composability. In this scenario hypervisors can be used to partition resources and allocate components as individual virtual machines and unikernels can be used as the runtime environment for each individual component, instead of traditional guest OS, to improve resource utilisation and timing properties.
Hypervisors
The key difference in the hypervisor approach vs the OS 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 which is highly portable. Conventional OS, where software components are incomplete in their ability to run without linking to OS libraries, imposes 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 OS.
Hypervisors add resource and computational overhead and safety concerns through 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
Unikernels allow 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 fulfil 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 behaviour is much easier to observe and characterise. This 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 would not be just a task or an application, it would constitute subsystems as well.
Combining unikernels with hypervisors allows architects to compose systems with a higher level of fidelity and 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.
As we suggest modelling 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, having 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 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 services. Much work remains to be done in standardisation efforts and refining the techniques of linking components with real-time constraints.
