Safety and Security

Integrated Model-based Safety Engineering with I-SafE

Seite: 2/2

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 [5] 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 [6]. The other consistency checks supported by I-SafE are not described due to space limitations.

Conclusion

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.

References

[1] P. O. Antonino, M. Trapp, P. Barbosa, E. C. Gurjäo, J. Rosário: The Safety Requirements Decomposition Pattern. SAFECOMP 2015: 269-282

[2] J. Hatcliff et al., 2014. Certifiably safe software-dependent systems: challenges and directions. Hyderabad, India, s.n., pp. 182-200.

[3] T. Kuhn and P. O. Antonino. Model Driven Development of Embedded Systems. Proceedings of the Embedded Software Engineering Kongress 2014. Pages 47–53.

[4] 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.

[5] 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.

[6] P. O. Antonino and M. Trapp. Automatic Detection of Incomplete and Inconsistent Safety Requirements. SAE 2015 World Congress and Exhibition, Detroit, Michigan USA, 2015.


* Pablo Oliveira Antonino has been working as a computer scientist at the Fraunhofer IESE since 2009. His work focuses on the construction and analysis of architectures of dependable systems.

* David Santiago Velasco Moncada obtained his M.Sc. degree in computer science from the University of Kaiserslautern in 2011. Since then he has been working in the Embedded Systems Quality Assurance department of Fraunhofer IESE. His research interests include safety and reliability of safety critical systems and software engineering.

* Dr. Thomas Kuhn received his PhD from the University of Kaiserslautern, Germany, in 2009. Since 2008, he has been working for the Fraunhofer IESE. Currently, he is head of the Embedded Software Development department and is responsible for architecture analysis approaches and virtual prototypes.

* Daniel Schneider is the Head of the Embedded Systems Quality Assurance department at Fraunhofer IESE. His research interests include runtime certification of safety critical systems. He has a doctorate in computer science from the University of Kaiserslautern.

* Mario Trapp is a division manager at the Fraunhofer IESE. His research interests include model-driven development of high-integrity embedded systems and safety-engineering techniques. He has a doctorate in computer science from the University of Kaiserslautern.

(ID:44294313)