Model-driven development (MDD) is a growing trend within the embedded computing world including safety-critical industries such as defense and avionics. While some modeling work is often involved in the software development process, the key differences are that specialized modeling tools are used and that the resulting model directly determines how the code is implemented.
For our purposes, we will define MDD as a two-step process. Firstly, a graphical representation of the software and its functionality is created. From this model, source code is generated, either manually, automatically, or by a combination of the two.
In the past, MDD was unable to compete in either reliability or efficiency with manually generated code. However, advances in modeling tools have reduced, and in some cases eliminated, the gaps between hand-generated code and code generated from a model. In addition, supporters of MDD cite as advantages its visual approach, simplification of complex systems, potential for component reuse, and overall flexibility.
Despite MDD’s popularity in safety-critical industries, companies that use it often face challenges in achieving safety certification. In part, these challenges are due to the age of the most popular safety standards.
For instance, when DO-178B, the safety certification standard for the avionics industry, was written, few in the avionics industry had heard of MDD. Despite revisions present in DO-178C to address MDD processes, users still face unique challenges in verification, especially with regard to requirements traceability. These challenges pose several important questions: What are the current issues faced by developers who use model-based design but want to maintain requirements traceability for safety verification and how do modern requirements traceability tools assist in overcoming these challenges?
Requirements traceability has become a key part of the safety verification processes in a variety of markets developing critical software, such as aerospace, defense, transportation, nuclear, and medical, but it has taken a special importance in industries where a high risk is involved in software failure.
Requirements traceability connects the highest-level description of the project with lower-level implementation and design. From there the design can be linked to the implemented code and any associated testing. This enforces the idea that every requirement must be implemented and testable. In addition, for DO-178 and other standards, traceability must be bidirectional.
This type of traceability links the tests to the code they verify and the requirements that the code implements. If successful, bidirectional traceability provides a view into the many relationships between the requirements of a system, the code that implements those requirements, and the tests that prove the requirements are met.
The value of requirements traceability is that it provides the means whereby software producers can ‘prove’ to their client that the requirements have been understood; the product will fully comply with the requirements; and the product does not exhibit any unnecessary feature or functionality.
In the context of safety-critical software, requirements traceability takes on an added dimension of proving that software risks have been minimized and all necessary verification activities have been performed. For instance, software failure for an airplane flight controller or a missile launcher can have catastrophic effects. It is vital that implementation of the requirements be proven with concrete and verifiable evidence. For over two decades, requirements traceability has shown itself to be an important means of collecting, organizing and connecting that evidence.
The Challenge of Models and Requirements
Requirements traceability was originally envisioned for a traditional software lifecycle, involving either requirements database tools or textual documents, however. Integrating MDD into a traceability-based workflow is a relatively new challenge. Compounding these complications for safety-critical applications is the lack of guidance provided by safety certification standards.
For example, when DO-178B was developed for the avionics industry, MDD technologies were not a factor and no guidance was provided. Newer updates to these documents include directions designed specifically to address this issue. There were many lessons learned in the interim time about how MDD should be integrated with requirements traceability. The latest updates take these into account and provide guidance on avoiding some of the potential dangers of incorrect integration.