FACE Technical Standard Offers MOSA Lessons for Safety-Critical Software in Any Sector

Developing embedded application software is an expensive business, especially when the software is to be used in a critical application. Composable modularity can streamline development through the reuse of software modules, making it a highly desirable attribute in the architecture of embedded software.

The U.S. Department of Defense (DoD) has embraced this concept 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. The Future Airborne Capability Environment (FACE™) Consortium, a collaboration between government and industry entities, has developed the FACE technical standard to fulfil the requirements of a MOSA for military aviation software development. However, there is nothing about the principles of the FACE technical standard and MOSA that makes them applicable only to military systems. They therefore serve as a practical example for the application of open systems in other safety-critical sectors as well.

Learning the Lessons of Modularity

Modularity seems to be an intuitive concept, but the specification of what exactly defines a module is less obvious, and potentially littered with pitfalls. The designers of the FACE reference architecture have largely taken those concerns away from projects that are compliant with it. For anyone looking to apply MOSA principles elsewhere, there are several important considerations.

Figure 1. Code modularity in a coordinate measuring machine application.

Consider a coordinate measuring machine (CMM), designed to measure mechanical components to see whether they are within tolerance. Suppose this system consists of a time-critical motion control application, and an application that calculates the required machine moves, measures the geometric shapes, and displays them for the user. The illustration suggests a highly modular architecture with four discrete codebases in use (Figure 1).

In such a heavily mathematically dependent application, the math library is likely to be exercised extensively with many system calls. Many math libraries exist but exchanging one for the other is unlikely to be a simple plug-and-play exercise. Similarly, there are many graphics libraries available to choose from, but as the application code is likely to be substantially interwoven, that too is difficult to replace.

The real time operating system (RTOS) also presents challenges as a module. An RTOS application might have 100 tasks running on a system with access to four cores. The developer mindset is that the application has control of execution in accordance with rules they are defining. But in fact, these tasks leverage countless interfaces to call system services. The much-vaunted portability of POSIX only offers a partial solution to that conundrum. On a practical level, portability is hindered by the necessity of auxiliary tools. Despite POSIX compliance across the board, if you have a series of software components that you’d like to combine to create a new application, it is not possible to use a set of tools from one vendor and link in components from others.

Figure 2. The LDRA tool suite monitors data and control coupling in source code.

What we are left with is a codebase that is highly coupled and does not represent the kind of modularity envisaged in a MOSA. Ultimately, developers want to be able to move their intellectual property elsewhere, and they can’t. Source code analysis tools can be used throughout software development to detect undesirable coupling early and restore modularity (Figure 2).

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’s composable modularity.

Composable Modularity and Decomposition

Composable modularity has much in common with the separation of software systems promoted by the functional safety standards underpinning the development of safety-critical applications such as medical devices (IEC 62304), automobiles (ISO 26262), and civil aircraft (DO-178C).

Adhering to functional safety standards is demanding in terms of both time and money. For an application to be compliant with the most-demanding safety classifications, the overhead can be considerable. These classifications are assigned proportionately to the criticality of the software to which they apply, and in turn that can have a tremendous impact on the code development process from planning, developing, testing, and verification through to release and beyond.

Figure 3. Example of partitioning of software items according to IEC 62304:2006 +AMD1:2015.

In common with many other functional safety standards, IEC 62304:2006 +AMD1:2015 helps to minimize development overhead by permitting the segregation of a software system into software items with the aim of placing as little of the system as possible into the more critical classes. In doing so, it requires that “the software ARCHITECTURE should promote segregation of software items that are required for safe operation and should describe the methods used to ensure effective segregation of those SOFTWARE ITEMS.” Figure 3 shows the example used in the standard. In it, a software system has been designated Class C.

The system can be segregated into one software item to deal with functionality with fewer safety implications (software item X), and another to handle highly safety-critical aspects of the system (software item Y).

That principle can be repeated in a hierarchical manner, such that software item Y can itself be segregated into software items W and Z, and so on – always on the basis that no segregated software item can negatively affect another. At the bottom of the hierarchy, software items such as X, W, and Z that are divided no further are defined as software units.

This decomposition process is designed to reduce development overhead, rather than deliver the composable modularity in accordance with MOSA principles. Nevertheless, this natural separation based on functionality and criticality lends itself to a useful level of modularity. In general, decomposition is not an exact science, and it can vary considerably depending on the architect’s viewpoint. For example, decomposition for the purposes of composable modularity is likely to be less granular than that for decomposition based on levels of criticality.

Development Processes

Efficiency benefits can be gained from software reuse, but care is needed to avoid increasing risk by doing so. That argument is reflected in the Federal Aviation Administration’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. According to 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-178 compliant system can save significant certification time. Without an RSC, the FAA will require 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.

Figure 4. Automating unit and integration test with the LDRA tool suite.

For example, consider the unit and integration testing required to develop a software module in accordance with functional safety standards. The automated tools commonly referred to as unit test tools generally support both unit test and integration test, as illustrated in Figure 4. The same mechanism is used whether testing a single unit or several integrated units. Those integrated units may constitute a reusable module.


Modularity is of little benefit without composability. Likewise, the granularity of software modularity and the perspective of the system architects defining those modules can have a significant effect on its usefulness. Granularity of decomposition based on safety classification is likely to be finer than that for modular composability, simply because different aspects of a composable module’s functionality may have different levels of criticality.

As a MOSA-aligned standard designed to promote software portability, the FACE Technical Standard has been very successful. Automated verification and validation techniques lend themselves well to the FACE conformance process. That said, the challenges surrounding the development of FACE-conformant, hard real-time systems demonstrate that the development of a perfect modularization scheme is far from easy.

Despite these limitations, 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.

This article was written by Stephen DiCamillo, Technical Marketing and Business Development Specialist, LDRA. For more information, visit here .