The FACE™ Consortium is a government and industry forum that defines standardized approaches for using open standards with avionic and defense systems in the effort to promote interoperability throughout large scale internet connected systems.
For designs that that require both airworthiness and global connectivity, does the adoption of standards fit for large scale systems such as FACE™ impose underlying complexities that make DO-178 certification efforts practically intractable?
Safety conscious advocates are unwilling to inherit design complexities that require too much software to develop and maintain that may result in system behavior states that are impossible to reason about and test.
Interoperability advocates are unwilling to accept stove pipe implementations that lack interoperability properties and the ability to recoup investments through design reuse. Both camps have legitimate concerns, with the debate escalating in the advent of multi-core designs where the inherent complexity of the system irrefutably increases while the certification design scrutiny also increases.
Therefore, resolving this conflict requires a platform capable of managing the complexities imposed by the abstraction layers of standard APIs while ensuring that side effects of these complex subsystems cannot interfere with environments classified at the highest assurance level.
As a platform provider, LYNX acknowledges the need to provide adaptive platforms that can be tuned by developers to manage complexity inheritance. Furthermore, the platforms must be internally comprehensible and transparent to allow regulatory authorities to trace and verify assurance claims down to implementation realized in silicon.
Lynx MOSA.icTM is a development framework that gives developers the ability to integrate complex components as needed, controlling the inherent complexities of their design with the understanding of how their designs are realized in hardware.
In the examples below, two multi-core FACE™ systems are implemented.
System A shows a design that minimizes abstraction layers and restricts dependencies to basic software components for running safety critical applications. The FACE™ portion of the design is limited in hardware access and is only used as a simple transport of packets to maintain network interoperability, while the safety critical applications run autonomously in bare-metal rooms.
The merit of the design gives architects and evaluators precise insight as to where critical applications are running and their dependencies. While at the same time evaluators can also measure the worst possible case of interference generated by a room. They are also given assurances that there are no internal software platform dependencies on complex abstractions such as Syscalls into SMP kernels, internal thread queues, global data locks, and coherency protocols that could make the interference analysis very difficult.
System B shows design where FACETM applications rely on deep abstraction layers implemented across multiple CPU cores. In this design the potential amount of interference that the FACETM guest can generate in the hardware alone will create a challenging analysis excise to ensure critical applications will meet there timing deadlines.
System B also shows the impracticality of hosting a critical application on deep abstraction layers that most both defend integrity analysis and timing analysis of a complex runtime environment that will inherit interference from both the hardware and the deep layers of abstraction concurrently accessed by co-hosted applications.