Approaches for modeling safety critical systems

Many model-based approaches have been proposed recently to support the development of software in the context of safety-critical systems. Although our research problem is particularly aimed at airborne software and their development according to DO-178C, we have explored a broader range of application domains for model-based approaches, extending the scope of our literature review to approaches pertaining to the development of safety-critical software in general. The reason behind this wide scope, is due to the fact that safety-critical software share similar properties and challenges independently from their domain of application such as railway, aerospace, energy and medical devices.

Domain-independent approaches

Generally, safety compliance is not based on just one standard but a corpus of regulatory standards. In this context, De la Vara et al. (2016) introduce the Reference Assurance Framework (RAF) metamodel. Its purpose is to express key concepts and relations used for demonstrating safety compliance that are extracted from multiple sources (i.e. safety standards, specific domain recommended practices, and company specific practices). The RAF meta-model provides an unified mean to create models used for safety assurance and certification.

fety standards rely on the traceability of safety evidence throughout the complete software life cycle to both demonstrate compliance with standard and support claims about the safety of the software product. Commonly required safety evidence includes: test cases, test results, and system specifications (requirements). Because suppliers must collect and maintain these evidence, the explicit specification of the traces between these artifacts is an important aspect to support the certification process of safety critical systems.

Work from Nair et al. (2014) introduces a Safety Evidence Traceability Information Model (SafeTIM). Its objective is to provide a broad overview of safety evidence traceability in the context of safety critical systems. The proposed model captures the traces and evidence information that must be created and maintained to show compliance with safety standards. SafeTIM was developed based on an extracted set of traces that are necessary for safety evidence.

Nejati et al. (2012) introduce a SysML based approach to address traceability between safety requirements and their design implementation. An algorithm that analyses the association between a requirement and its implementation is provided to extract design slices. Design slices provide a detailed view of the system from the perspective of a specific safety requirement. These are extracted from the overall design and capture the design aspects related to a target requirement. Such slice enables the analysis of the implementation of a safety requirement by removing the design elements that are irrelevant for the requirement under analysis.

Domain-specific approaches

UML profiles targeting various specific safety critical systems
Berkenkötter & Hannemann (2006) propose a domain specific language in the form of a UML profile for the railway control systems domain (RCSD). The RCSD profile enables the precise modeling of the static description of railway networks and their associated dynamic aspects. Networks are comprised of elements such as track segments, points, signals, and sensors. These elements are the physical entities that constitute a network of tracks on which trains are moving through pre-defined routes.

The profile models the domain using a combination of class diagrams and object diagrams. Class diagrams are used to represent problems of the railway domain (i.e. tramway and railroad models) whereas object diagrams capture instances of these problems (i.e. the explicit track layout). The object diagram uses either the UML notation or a notation introduced by the authors based on the symbology of the railway domain.

The dynamic aspect of the track network is defined as a timed state transition system (TSTS). The timed transitions are embedded locally in the profile’s elements. To ensure safety through the network, a controller is defined and added to the network model and remain independent from he physical elements captured in the model. The controller includes the safety conditions for running the systems. The controller model is defined using a strict mathematical model. This mathematical definition enables to prove the violation of the safety conditions for the running system by using bounded model checking techniques.

UML profiles for avionics software
Wu et al. (2015) have developed a methodology called Safety Oriented Architecture Modeling (SOAM). The method focuses on the design of a component centric architecture for avionic software in the context of DO-178C. More precisely this approach emphasizes on the notions related to the safety of software components. The method introduces an UML profile named SafetyProfile. Authors claim that the profile captures safety properties in accordance with DO-178C guidelines that apply to software components and their related interfaces.

Zoughbi et al. (2010) introduced SafeUML, a UML profile based on DO-178B. Its purpose is to capture the safety related requirements that are allocated to software and to monitor their implementation through the software design. Furthermore the profile intends to improve communication and collaboration between safety engineers, software engineers and the certification authorities. The profile is organized into packages, each package includes a set of related concepts. The concepts from which the profile is developed are grouped into five packages: 1) the Requirements package contains the concepts that are needed to express software requirements, their refinement as well as the traceability of the requirements to design artifacts, 2) the Characteristics package contains concepts to identify design elements having a direct impact on safety by specifying the software level that is attached to these elements along with the failure conditions that are associated to these elements, 3) the Event Management package that defines the concepts of events and the actions related to their capture, 4) the Configuration package that defines the concepts to capture elements related to software configuration, user modifiable software and change control, and 5) the Replication package containing concepts to address software redundancy.