Safety and Security
Integrated Model-based Safety Engineering with I-SafE
Anbieter zum Thema
I-safe visual trace
I-SafE provides a visual trace mechanism that allows engineers to visualize all elements related to each safety requirement specification. It allows visualizing (i) architecture elements and elements of failure models that are explicitly referenced in textual safety requirements specifications; (ii) architecture elements that are not explicitly mentioned in safety requirements specifications, but that are related (over a series of indirections) to those that are explicitly referenced.; and (iii) Other specifications related to safety requirements being analyzed, such as Conditional Safety Certificate  of a given component related to a safety requirement.
In the example shown in Figure 6, the safety requirement has an explicit trace to the MotorController element (cf. Figure 1). After activating the Visual Trace mode of I-SafE, whenever the user clicks on the safety requirement element the diagram shown in Figure 1 opens and only the referenced element MicroController is highlighted.
Automated Completeness and Consistency Checks
I-SafE provides support for executing completeness and consistency checks between safety requirements and architecture design, aiming at detecting and alerting engineers to existing incompleteness and inconsistencies.
With respect to completeness, I-SafE checks whether (i) every safety requirement describes mitigation strategies for failures that are described in at least one failure propagation model; (ii) every failure propagation model describes the failures of at least one safety-critical architecture element; and (iii) every safety requirement describes failure mitigations referencing at least one safety-critical architecture element. The completeness checks are displayed to the user as shown in Figure 7, where a list of safety requirements is displayed along with their types and the completeness violation.
With respect to consistency, one of the main checks offered by I-.SafE is on Safety Integrity Level – SIL inconsistencies, which are caused when safety requirements and the safety-critical architecture elements that address them have incompatible safety integrity levels. For instance, Figure 8 shows a list of architecture elements that have ASIL incompatibility. The basis for these and for all the other completeness and consistency checks implemented in I-SafE is described in . The other consistency checks supported by I-SafE are not described due to space limitations.
I-SafE provides a range of features that can rarely be found in other tools. Among the features presented in this paper, we deem the aspects of integration and traceability particularly important. Integration between different (types of) modular analysis models in the context of a larger system and traceability between safety requirements and related artifacts along the safety engineering chains are features that are bound to ease the daily work of software and safety engineers.
 P. O. Antonino, M. Trapp, P. Barbosa, E. C. Gurjäo, J. Rosário: The Safety Requirements Decomposition Pattern. SAFECOMP 2015: 269-282
 J. Hatcliff et al., 2014. Certifiably safe software-dependent systems: challenges and directions. Hyderabad, India, s.n., pp. 182-200.
 T. Kuhn and P. O. Antonino. Model Driven Development of Embedded Systems. Proceedings of the Embedded Software Engineering Kongress 2014. Pages 47–53.
 Y. Papadopoulos, J. McDermid, R. Sasse, and G. Heiner, 2001. Analysis and synthesis of the behaviour of complex programmable electronic systems in conditions of failure. Reliability Engineering & System Safety, 71(3), pp. 229-247.
 D. Schneider and M. Trapp, 2013. Conditional Safety Certification of Open Adaptive Systems. ACM Transactions on Autonomous and Adaptive Systems (TAAS), 8(2), pp. 1-20.
 P. O. Antonino and M. Trapp. Automatic Detection of Incomplete and Inconsistent Safety Requirements. SAE 2015 World Congress and Exhibition, Detroit, Michigan USA, 2015.