FACE shows that the benefits of MOSA can be leveraged in practice.
By Stephen DiCamillo, Technical Marketing Manager, LDRA
Cost and deadlines are constant pressures for software developers. It’s not surprising then that software modularity (the reuse of software modules) has become an attractive approach to address both challenges. This concept has been embraced by the US Department of Defense (DoD) with the Modular Open Systems Approach (MOSA). This strategic standardization initiative highlights how interoperable modular components built by different companies across different programs or procurements can perform together.
One example of a MOSA- aligned standard—the Future Airborne Capability Environment (FACE) Technical Standard—fulfils the MOSA goals and principles as they relate to software development. It offers several lessons that can be applied to streamline development of processes and improve competitiveness.
Understanding FACE
The FACE Technical Standard focuses on application programming interfaces (APIs) rather than providing guidance on software design or development processes. However, in defining those interfaces, the standard establishes a path to software reuse that results in improved affordability, speed, agility, and excellence. The FACE approach enables the repurposing of FACE Conformant software components from one DoD aircraft or war- fighting platform to another. The FACE Reference Architecture, as detailed in the current edition 3.2 of the FACE Technical Standard, embraces design principles that enhance software portability.
The five segments of the FACE Reference Architecture are as follows (portable modules conformant to the FACE Technical Standard, known as Units of Conformance (UoCs), may reside in any segment of the FACE Reference Architecture):
- Operating System Segment (OSS)
- Portable Components Segment (PCS)
- Transport Services Segment (TSS)
- Platform-Specific Services Segment (PSSS)
- I/O Services Segment (IOSS)
Developing FACE conformant software
As an increasing number of programs embrace the interoperability promoted by MOSA and the FACE Technical Standard, economical and scalable conformance and verification practices help suppliers remain competitive. Automation of labor-intensive and error-prone elements of the lifecycle plays a key role.
The requirements to achieve FACE Conformance vary depending on the segment to which the application belongs. Identifying those requirements along with functional requirements and then providing evidential artifacts to show that they have been fulfilled can be demanding. This is further complicated in cases where other guidelines such as those provided by DO-178C may also be applicable. Automating requirements traceability can alleviate project management headaches.
The FACE Technical Standard restricts the use of certain API calls while requiring others. Static analysis can detect non- conformant calls listed in the FACE Technical Standard. For example, the checks for adherence to specific sections of the POSIX API ensure that the UoC function signatures are syntactically correct, enforcing the proper use of critical language constructs.
Learning the lessons of modularity The FACE approach provides a tangible example of the benefits of open standards and modularity and how those principles can be applied, but it is important to understand the principles behind the standard. The principles of composability and modularity are often related. Modular systems consist of subcomponents with well-defined interfaces and functions that can be consumed independently of each other. Composability is the degree to which these subcomponents can be combined to form more complex systems. The key to reusability, then, is not merely modularity; It is composable modularity.
Composable modularity has commonalities with the separation of software systems promoted by the functional safety standards such as DO-178C that underpin the development of safety-critical applications for civil aircraft.
This decomposition process is designed to reduce development overhead rather than deliver composable modularity in accordance with MOSA principles. However, this natural separation based on functionality and criticality lends itself to a useful level of modularity. Decomposition is not
an exact science. For example, decomposition for the purposes of composable modularity is likely to be less granular than that for decomposition based on levels of criticality.
Automating development processes
Software reuse offers opportunities for efficiency The LDRA tool suite automates adherence to coding standards benefits but can also increase risk. That is reflected in the Federal Aviation Authority’s (FAA) Advisory Circular AC 20-148, designed to provide guidance for the development of Reusable Software Components (RSC) such as software libraries, operating systems, and communication protocols.
From the document: “… an RSC developer may partially satisfy the applicable RTCA/ DO-178 … objectives, while the integrator or applicant completes and shows the compliance for the integrated software package, systems aspects, and aircraft certification…”
Deploying any such RSC within a DO-178C compliant system can save significant certification time. Without an RSC, the FAA requires that certification artifacts are regenerated, resubmitted, and re-reviewed for every reuse—including software changes made to an existing installation.
An RSC differs from other components in that the documentation and guidance required goes well beyond the provision of artifacts. In addition to the extra documentation, this also implies tests are required to exercise all possibilities, and not just those demanded by the requirements of a particular project. This places additional overhead on the development team who are under pressure to meet the initial project goals using the component, irrespective of the future potential for reuse. Under those circumstances, the more seamless help available from automation, the better.
For example, the automated tools commonly referred to as unit test tools generally support both unit test and integration test. The same mechanism is used whether testing a single unit or several integrated units. Those integrated units may constitute a reusable module.
Conclusions
As a MOSA-aligned standard designed to promote software portability, the FACE Technical Standard shows that the benefits of MOSA can be leveraged in practice. Automated tools, with which regression test can be automated as the same code is leveraged in a variety of tool chains, go a long way towards ensuring that reused modules are fit for purpose in their new environment, without taking that on trust.