Content
This is also published TechLetter 6, written by Eike Römer. Translated by me and published on the Rhapsody BLOG to allow more people to read it.
The development of safety-critical software is often associated with a certification process. Experiences from the certification environment are presented together with possible work steps.
The procedure is based on the V-model. This Tech-letter covers requirements management, implementation, testing, and end-to-end traceability.
The presented experiences can be adapted to own projects.
Practical experience and possible work steps
Creating software for embedded systems in safety-critical areas often requires certification as well. Standards such as IEC 61508 or industry-specific standards are intended to ensure functional safety for safety-critical application areas. In this Techletter practical experiences of the Willert Software Tools GmbH in the range of the software certification are presented.
Example RXF-Cert
Willert develops a so-called semi-finished product, that, being only a part of the software, is being built together with the application software of customers later to create a unit. This unit then must be certified as a whole.
In the specific case, it is the “RXF-Cert” [1], a framework on which the code generator can be based on the UML tool IBM Rational Rhapsody [2] (see Figure 1). In addition to the framework source code and UML model, a “Certification package” is delivered consisting of documents and test suites that facilitate certification in the overall context.
Figure 1 – RXF-Cert as semi-product in the context of the customers application
Management of Requirements
Probably the most important part of the accompanying documents are the requirements. In order to manage their relationships, versions and status changes, many tools have become established in the market. Such tools are, for example, IBM Rational DOORS® [3] and Polarion [4]. Willert has chosen Polarion for his own use as part of the RXF-Cert project.
Figure 2 – Specifications and their links in the V-Model
The organization of the requirements has been made in the following levels (see Figure 2)::
- Customer Requirements (Role of the Customer)
- System-specification (Role of the SW-Architect)
- (Software-)Module- and Operation-specification (Role of the developer).
The linking should be defined fixed from the lower level to the next highest level, as a “Satisfies” relationship.
A specification should always have one or more relationships with overlying specifications or requirements. Also links from the resulting software or the source code to the specifications are required here. This makes it clear which code section is used to implement which request (s).
The RXF-Cert comes with a Rhapsody UML model. In addition to the module specification and implementation with the associated code generation, this also contains visualizations of the architecture and of scenarios for more complex processes. In case of a certification diagrams bring the advantage that an auditor can more quickly grasp the construction and implementation of the software. Model elements should also have links to the specifications here.
To create representations for requests in UML tools, there are, for example, the IBM Rational Rhapsody Gateway tools [5] and the Willert ReqXChanger [6] tools. For the RXF-Cert the ReqXChanger, developed by Willert Software Tools, is used that connects e.g. Polarion via the standardized Requirements Interchange Format (ReqIF) and directly supports Rhapsody. Thus, representations for UML elements are also created in the requirements management tool and related to the associated requirements. The associated workflow is visualized later in the document in Figure 5
Ensuring functionality through Testing
Certification also requires proof that the functionality is being verified by testing. In a first RXF-Cert project, unit tests and code coverage analyzes were conducted on the basis of manually written C test cases and the gcov tool (from the gcc package) [7] in a test environment. Currently, the effort has been greatly reduced by using the model-based Test-tool BTC TestConductor [8]. In addition, these tests are also performed on the hardware of the target system instead of a PC environment. The results are returned to the test model from the target environment (see Figures 3 and 4).
The test case specification for the unit tests has been linked in the UML model with the implementations of the modules, so that also the test specifications from the model are mirrored in the requirements management tool and in conjunction with the specifications, herewith also a cover and Impact analysis up to the unit tests possible (see Figure 1).
Figure 3 – Test execution on the target with feedback of the test results into the test model.
Figure 4 – Results of the Code Coverage Analysis on the target environment
Cross-phase coverage and impact analysis
Coverage analyzes are important in order to determine, for example, whether all requirements have a test or whether all requirements are linked with software elements. In the approach presented above, coverage analyzes of the UML model can also be performed. From this documents can be generated that can be presented to an auditor.
Impact analyzes are necessary if, for example, requirements are changed during development. One goal is to be able to determine through all levels what needs to be adjusted as a requirement changes. The ReqXChanger can mark changed requests with stereotypes when retransferring requests to the UML tool (see Figure 6). For the certification process, it can be ensured that the software always takes into account the current state of the requirements.
Preparation of documents for certification
Figure 5 – Exchange between UML Model und requirement Management
Figure 6 – Changed Requirement / Specification obtains Stereotype “Changed” in the model
Creating Certification Documents
From the standard it can be extracted which documentation components are expected. However, combining these into suitable documents and maintaining them involves some work. It therefore makes sense to create an overview document of all delivered goods. Here are source texts, documents and other artifacts of the delivery described and clearly identified including the consistent version numbers. The basics also include adding structure elements to each document, such as a table of contents with page references, a version history, and a cover page with the unique identifier and version. Likewise, a page number indicating the total number of pages on each page in order to be able to verify the completeness.
When recording the requirements, it should be noted from the outset that the corresponding documents must be created for certification. Printing the documents from our internal requirements management with Polarion in an appropriate form requires a lot of effort. The documents managed in Polarion itself can not be used to print the specifications if the links and thus the traceability should also be printed. It is not possible to filter only for specific link types or links to desired targets in the view. One of the consequences of this is that requirements list a relation to the IDs of their chapter headings (these have a hierarchical relationship in the document to each other). A certifier will now stumble upon references that he can not find because headings in the references show the Polarion internal ID, but the header itself does not display an ID. It is therefore strongly recommended that when selecting a tool it is taken into account that it can generate the documents accordingly or how to configure it accordingly. Also with Polarion it is possible via wiki or info pages to prepare the documents for printing accordingly.
Conducting (internal) Reviews
The review of the specification and elements of the software should be done in the requirements management tool. It is helpful to specify that for a “review attribute” (here: “status”) of work items (eg requirements) certain values can only be set one after the other (see Figure 7).
For the “Specify action”, Polarion has been configured to invite specified users to “approve” the work items. Here are two responsible persons. Only when these persons have both given their “Approval”, a status transition to “Reviewed” is possible. This fact is explained in the supplied validation plan and thus ensures the four-eyes principle in the review process.
Also reviews of models can be managed with this mechanism. In addition, the module specifications specify which SVN revision number (of a checked-in model unit) a review was carried out for. For new revisions, new reviews must be made accordingly.
At the code level, we have had good experience with the Crucible tool [9] and have created a PDF export plugin there that can be used to create code review reports suitable for certification.
Evaluation by a certification consultant
In order to assess the described status independently, we have obtained an evaluation of our procedure by an external certification consultant. This has brought many valuable experience. Among other things, we understood better what content and documents are required by the standard. For example, A security officer must be named in the company, who of course also lives up to his task, and there must be a corporate policy statement on the handling of software security in a “Safety Policy” document.
We have received a lot of positive feedback on the approach and process in development, as well as the approach to meeting the standard. For us in the consultation also the large difference in the standard, whether something is certified as software or as a tool (tool), clear. When you certify a tool, you only have to deal with about one-tenth of the IEC 61508 requirements than with a complete software certification. Nevertheless, we strive to classify our RXF-Cert as software in general. This must also be clearly documented and the user should be made aware of the field of application. If our RXF-Cert were e.g. Not only supporting the development of software, but also the systems engineering, would be added to several other requirements.
In conclusion, we still see the effort associated with certifying software as considerable – but it also shows for us that the requirements of the standard are absolutely meaningful. The development process becomes more sophisticated, the software quality can improve significantly and almost as a by-product the software becomes certifiable.
Passed certifications
The RXF-Cert has now been deployed in several functional safety software projects along with the customer applications. The areas Railway, Automotive and Space are represented. Some of these projects have already successfully passed the certification with the RXF-Cert package, others are currently or will only be in the project status in which the certification will be carried out in the near future. Thus, it has already been shown that the general procedure, meaningful use of tools and careful work steps described in this Techletter make it possible to plan and implement certification according to a standard based on IEC 61508.
Referenced Tools
[1] Willert RXF-Cert, Framework for modeling and code-generation of safety-critical Software:
https://www.willert.de/uml-rxf-cert
[2] IBM Rational Rhapsody, UML-Tool:
https://www.willert.de/rhapsody
[3] IBM Rational DOORS®, Requirements Management:
https://www.willert.de/doors
[4] Siemens Polarion, Application Lifecycle Management:
https://www.willert.de/polarion/
[5] IBM Rational Rhapsody Gateway, Tool for the exchange and trace of Requirements:
https://www.willert.de/gateway
[6] Willert ReqXChanger, Tool for the exchange and trace of Requirements:
https://www.willert.de/reqxchanger
[7] gcov (from the gcc packet), Open Source Tool for Code Coverage Analysis:
https://gcc.gnu.org/onlinedocs/gcc/Gcov.html
[8] IBM Rational TestConductor, Model-based Testing:
http://www.willert.de/testconductor/
[9] Atlassian Crucible, Code Review Tool:
https://de.atlassian.com/software/crucible
Happy Modeling with Rhapsody!
Walter van der Heiden (wvdheiden@willert.de)
Eike Römer (eroemer@willert.de)
Leave a Reply