Why Modular Composability Matters for Today’s Safety-Critical Software Development

November 02, 2022

Story

Modularity and composability are popular buzzwords in software, for everything from enterprise computing down to bare metal applications. For safety-critical embedded systems, these concepts define goals for software reuse by enabling the use of existing software components in different combinations for different use cases.

While much of the push towards formal modular development has been from the aerospace and defence sector, the benefits it offers are relevant across the safety-critical sectors. Understanding why and how modular composability fits into safety-critical development is key to leveraging the benefits of software reuse while meeting the demanding objectives of today’s functional safety standards.

Overview and Challenges of Modular Composability

Modularity addresses the problem of designing subsystems (modules) with well-defined interfaces that are usable in a variety of contexts. Composability demands something of the relationships between modules so they can be combined in ways that solve multiple problems. Ansgar Fehnker of the University of Twente offers this definition of how the two concepts work together:

“A design method satisfies Modular Composability if it favours the production of software elements which may be freely combined with each other to produce new systems, possibly in environments quite different from the one in which they were initially developed.”

In short, modular composability implies portability and reusability across systems, like a Lego brick going from a street scene to a spacecraft.

Like Lego, there is a practical limit to modularity. Lego is a specific brand of construction toy that can’t easily interface with Stickle bricks or Meccano. The same applies to modular software, as once a component is in production, reusing it in different environments often comes with constraints and caveats.

A real and infamous example is the Ariane 5 launch failure. According to the European Space Agency’s report, the loss “was due to specification and design errors in the software of the inertial reference system. The extensive reviews and tests carried out during the Ariane 5 development programme did not include adequate analysis and testing of the inertial reference system or of the complete flight control system, which could have detected the potential failure.” While this software was practically the same as that used successfully in Ariane 4, it was compromised by the circumstances of a new environment.

How Safety-Critical Standards Reflect Modular Composability

Many industry standards reference processes and objectives that are relevant to safe reusability, as described in the following sections.

Segregation of software items: IEC 62304:2006+AMD1:2015

The International Electrotechnical Commission (IEC) 62304:2006+AMD1:2015 medical device standard permits the segregation of software items with the aim of placing as little of the system as possible in classes of higher safety criticality (e.g., Class C software that “can contribute to a hazardous situation which results in unacceptable risk after consideration of risk control measures external to the software system, and the resulting possible harm is death or serious injury”):

“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 1 illustrates the segregation of software items with fewer safety implications (item X) and those with high safety critical implications (items Y and Z). Due to the presence of highly safety critical items, the overall software system is designated Class C.

 

Figure 1: Example partitioning of software items according to IEC 62304:2006 +AMD1:2015 Figure B.18 (Source: IEC)

Increasing development efficiency: FAA AC 20-148

The Federal Aviation Authority (FAA) Advisory Circular AC 20-148 provides guidance for the development of Reusable Software Components (RSC), such as software libraries, operating systems, and communication protocols. An RSC differs from other components in that the documentation and guidance required goes well beyond the usual provision of software artifacts.

The Advisory Circular has clear guidelines to ensure that every interface – application code and target hardware included – is defined by the developer in exactly the way prescribed by the RSC provider. This highly specified modularity means that an RSC can largely be treated as a “black box” because no matter the purpose of the target application, the RSC can be assumed to behave in a well-defined manner.

This means deploying RSCs within a DO-178 compliant system can save significant hours of 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.

Fostering reuse: Open Group Future Airborne Capability Environment

The Open Group Future Airborne Capability Environment (FACE) Consortium establishes a path to software reuse in aviation through affordability, speed, agility, and excellence improvement goals. The FACE Technical Strategy and Standard outline several key principles, including:

• The establishment of a software environment that enables the repurposing of FACE applications from one DoD aircraft or war-fighting platform to another with minimal software revision.
• Embracing design principles that enhance software portability – for example, by providing a common set of interfaces to each portable FACE application.
• Coding standards that restrict the use of certain API calls and requiring others – for example, adhering to specific sections of the POSIX API to ensure that the function signatures of FACE Units of Portability (UoP) are syntactically correct and enforcing the proper use of critical language constructs.

The Value of Automation in Achieving Modular Composability Goals

Regardless of standard or approach, modular composability principles tend to have a tremendous impact on safety-critical development processes in terms of time and money. It may seem like an expensive proposition at first but today’s automated tools, where the reusable components can be used in a variety of tool chains, streamline different aspects of validation, as seen in Figure 2.

 

Figure 2: Example of automated requirements traceability and regression testing to support the confirmation of suitability of reused code (Source: LDRA)

Requirements traceability

Automation of the more labor-intensive and error-prone elements of the software lifecycle plays a key role in minimizing the development impacts of modular composability. Identifying requirements and demonstrating fulfillment can be a demanding process, especially when functional requirements must be validated alongside standards such as DO-178.

Automating traceability alleviates potential project management headaches. With automation, requirements can be managed and tracked using the same mechanism between initial module development and every future deployment in different environments. Confirmation of module requirements can be acheived through automated and linked regression testing, including unit tests, static analysis checks against coding standards, and other measures.

Unit testing                                           

Despite their collective name, automated tools referred to as “unit test” tools generally support both unit test and integration test. The value of these tools lies in using the same mechanism for testing a single reusable unit and several integrated units as a whole. The tests themselves need not change whether a function is tested in isolation or as the top of a call tree. In the former case, automatically generated stubs can handle code that is out of scope.

This approach to automation lends itself to the integration of modules into both the initial project and future projects. The original tests can simply be regressed whenever the module is called upon in new environments, such as when deploying to different target hardware. And by calling the API to the module from within the context of a new project, its fitness for purpose can be validated.

Bringing Modular Composability to Your Project

Reusability is something of a holy grail for safety critical application developers, but modular composability provides a viable, realistic mechanism towards its goals. While there are horror stories around software reuse and many standards that discuss principles of modularity and composability, automation offers an effective path to safe reuse for any project.

Automation reduces the time and effort it takes to manage, track, and test the reuse of components in different environments. Lifecycle platforms such as the LDRA Tool Suite ensure that reused modules are fit for purpose in their environments, with capabilities from requirements traceability to static analysis to unit and integration testing. These capabilities enable safety and security critical software development teams to achieve certification and approval of reusable components in accordance with rigorous industry standards.