Traceability Management Using Eclipse Capra for Safety and Security Assessments
Traceability between different development artifacts is an essential requirement in safety and security standards such as ISO 26262, ARP 4754, IEC 62304, IEC 62443, and the upcoming ISO/SAE 21434 standard.
Eclipse Capra helps engineers create, visualize, and manage trace links from an IDE. It supports many of the most common artifact types directly, and can use trace links that are annotated in code as well as those that it stores in its own database. The Eclipse Capra technology is one of the results of the ITEA-funded European research project, AMALTHEA4public.
In this article, we introduce Eclipse Capra and its capabilities, illustrating them with an example from the automotive domain. However, before we describe Eclipse Capra in more detail, here’s a closer look at the challenges associated with developing safety- and security-critical systems.
Safety- and Security-Critical Systems Are Complex, Multivendor Development Projects
Standards, such as those listed above, imply that:
- Requirements must be assigned to components from the functional architecture
- Dependencies between requirements must be tracked
- Safety- and security-relevant aspects must be tracked from hazard or threat identification through to implementation and verification of the safety or security mechanisms used
To create the final product in safety- and security-critical domains, such as automotive, avionics, and medical devices, heterogeneous embedded systems are built by different suppliers and integrated by original equipment manufacturers (OEMs). The collaborative systems engineering processes necessary for such products create new traceability challenges because each participant in this complex value chain uses different processes, methods, and tools.
These systems are already the subject of research projects, such as PANORAMA. In addition, organizations are working to create tooling and methods to address the need for traceability.
One recurring challenge is the need to connect artifacts from different tools, including commercial tools used for modeling, requirements management, and analysis, and the open source tools that complement these commercial tools.
Current approaches are often based on manually created documents that are time-consuming and error-prone to maintain. In contrast, Eclipse Capra offers customizable and extensible traceability management right in the IDE.
All Safety-Related Claims Must Be Proven With Evidence
When developing a safety-critical system, engineers must be able to demonstrate that all safety requirements have been fulfilled. That means a mitigation strategy must be defined for each identified hazard, or rather, for the safety requirements derived from it.
A safety or assurance case demonstrates there is evidence for every safety-related claim and that the mitigation strategies are effective in addressing the hazard. The evidence can be process-related, demonstrating, for example, that code reviews ensured code quality. Alternatively, the evidence can be artifact-related, demonstrating that all safety requirements have been tested. Artifact-related evidence can be collected using trace links between development artifacts.
Similar considerations are necessary in systems that are vulnerable to cybersecurity attacks. For example, the IEC 62443 standard requires security design and implementation reviews, among other requirements. Upcoming standards, such as ISO/SAE 21434 for cybersecurity engineering in road vehicles, demand the creation of cybersecurity cases, which are similar in structure to safety assurance cases.
Trace Links Support Safety and Security Claims
Trace links strongly support the argumentation of safety and security claims during engineering reviews and assessments.
A trace link connects two artifacts and denotes the relationship between them. Typical examples of trace links that are relevant for safety assurance cases are those between requirements and test cases.
For example, developers might leave issue identifiers in the test code, or they might create trace links between code and the corresponding tests using a specialized tool for storage in a model or database. In both cases, trace links should be accessible for analysis, or for visualization to show that all requirements are tested in a traceability matrix. Such matrices can be used in assurance cases as evidence that safety or security requirements have been validated.
In addition, when analyzing failures or security incidents during operation, trace links support impact analysis, such as identification of affected system components.
Eclipse Capra Simplifies Traceability
Out of the box, Eclipse Capra supports requirements in ReqIF, Microsoft Excel, and Google Spreadsheets. It can create trace links to Java, C, C++, and PHP code. It can also create and manage trace links to Eclipse Papyrus models, FeatureIDE feature models, Eclipse APP4MC models, and many others.
Generic handlers for Eclipse Modeling Framework (EMF) models and arbitrary files provide additional interoperability. Importantly, Eclipse Capra can easily be extended to support additional artifact types. Together, these capabilities mean Eclipse Capra can create and manage trace links between artifacts created and maintained in commercial and open source tools (Figure 1).
Figure 1: A Selection of Artifacts Eclipse Capra Can Trace to
In terms of visualizations, Eclipse Capra supports a variety of graph types as well as a matrix view. All visualizations are configurable to ensure engineers see the links that are relevant to them.
Eclipse Capra’s main strength is its customizability. Adding new handlers to support additional artifact types usually only requires a few lines of code. Creating custom traceability information models that define which trace types exist and how they relate to the artifacts is easily done with an Eclipse Xcore model. More advanced customizations, such as changing the way Eclipse Capra stores its trace model, are also possible.
Relationships Among Artifacts Are Illustrated
To illustrate Eclipse Capra’s capabilities, Figure 2 shows how the software is used to trace between the different artifacts in a demonstration we’re currently working on in the context of the PANORAMA European research project. In the demonstration, we’re using a realistic prototypical example of an automated driving application that includes a number of relevant artifacts for safety analysis, including:
- A set of functional requirements
- An initial component model
- A list of hazards, as well as a set of safety goals and requirements
Figure 2: Traceability Between Different Artifacts With Eclipse Capra
The traceability graph drawn by Eclipse Capra illustrates how artifacts created in different commercial and open source tools are connected by traces. In this case, a safety claim modeled in Open Dependability Exchange (ODE) is traced to a hazard described in Microsoft Excel and connected to a safety goal and a functional requirement, both in Microsoft Excel. The functional requirement is traced to a component modeled in Eclipse Papyrus and the component is traced to a Runnable in Eclipse APP4MC.
The system modeled in Eclipse APP4MC is intended to calculate proper throttle, steering, and brake signals to follow a map of predetermined waypoints. In addition, a high-priority task to brake and perform emergency maneuvers to avoid obstacles is included.
Based on the assumptions of operation in urban areas and implementation of level 3 automation, we performed a hazard analysis and risk assessment according to ISO 26262 to determine the corresponding automotive safety integrity levels. In addition, we performed an initial safety analysis that includes a failure modes and effects analysis (FMEA) based on the component model and the derived safety requirements.
We also created a custom traceability information model to support our goal of managing traces for model-based safety assessments.
We’re currently working on supporting engineers who are constructing safety and security assurance cases and semi-automatic execution of change impact analyses. This includes model-spanning assessments that enable integrating domain-specific models, such as the ODE meta-model.