Mondragon Unibertsitatea has participated in the Artemis SafeCer project during the last 4 years. Researchers from theSoftware Engineering and Web Engineering and Distributed Real Time Systems research teams of the embedded system research group have been working and they have been involved in the use cases and demonstrators of the Railway domain and also they have developed an Educational use case during the project with the objective of transfering the results and the generated knowledge to the new professional in this area and provide practical examples to students in order to acquire knowledge about the development of safety-critical embedded systems.
As the final objective of the project has been to do things easier and more efficient to certify safety critical systems, one of the main research topics has been the reusability of the SW components. For that, a Safety Process Model and Tool Framework have been designed and developed.
Regarding to the Process Model, different approaches has been considered and Mondragon Unibertsitatea has worked in the definition and demonstration of the Activity Patterns.
The approach adopted by the SafeCer project builds on a number of technical items which are developed within the project: component contracts, safety argumentation, formal verification techniques, proactive certification documentation, tool support for traceability. While tool support is something that is present throughout the development (i.e. found in every activity), the remaining technical items represent dedicated activities that need to be performed as part of the development process. Therefore, it makes sense to add explicit activities to the pattern to deal with these items.
In a reuse and component based context, the process model needs to deal with the joining of two development paradigms: system development and component development. If the process model is to be applied for both these development paradigms (and more) it should preferably contain the same main activities although possibly with slightly different concretization. In SafeCer the activities has been regrouped and a pattern identified; this is called Activity Pattern.
Figure 1: Generic SafeCer Activity Patterns
Regarding the tools, the Certification Tool Framework (CTF) is a framework collecting all the SafeCer consortium partners’ tools producing evidence within the process of certification. Each tool, able to produce or manage artifacts and needed to provide certification evidence, will return one or more artifacts as output. Some of these tools have been used in the Educational and Railway domain use cases.
Both the Educational use case and the Railway demonstrator, has been designed and modeled using the process defined with the Activity Patterns, but in the Educational use case we didn’t consider the Certificate Preparation and Argumentation phases because it was an academic exercise. Each of the systems had several SW components. Each of these components were designed and modeled by the process defined by the Activity Patterns (at Component Level) and then, the system has been generated with the composition of the components (Activity Patterns- System Level).
In the next figure we can see which are the considered Activity Patterns at Component Level and at System Level and they are linked with the tools considered in the use case.
Figure 2: SafeCer Activity Patterns and CTF Tools
Workflow Engine For Analysis, Certification and Test (WEFACT) is a tool developed by AIT (Austrian Institute of Technology) and it is one of the tools that has been used in the use case in order to represent the Generic Process Model. Using this tool, we have defined the requirements of the use case, the activities involved in the use case (based on the Activity Patterns) and the input and output artifacts of each of these activities.
Another tool that has been used in the use cases is the extended version of the CHESS tool (Composition with Guarantees for High-integrity Embedded Software Components Assembly) developed in the CHESS and SafeCer projects. All the modeling and contract definition of the use cases has been done using this tool. This tool has the option to define contracts for the system and it is possible to use a Contract Based Design approach.
There is also a tool called CHESS2OCRA that translates the model of the system defined in CHESS to the OCRA tool (contract based modeling). So in the use cases, first the system is modeled using CHESS and then it is translated from CHESS to OCRA using the CHESS2OCRA tool.
The design of the control system has been based on contracts. In order to assure that the system fits the contracts, a contract based design has been applied and the tool called NuSMV3/OCRA has been used to verify the contracts.