Authors: Pablo Oliveira Antonino, David Santiago, Velasco Moncada, Thomas Kuhn, Daniel Schneider, Mario Trapp, Fraunhofer IESE<\/p>\n
Even in the age of computerization, safety engineering is still a matter of textual documents and even pen and paper. One major consequence of this are inconsistent and incomplete specifications of safety-critical systems, which are a core reason of catastrophic failures. To improve the completeness and consistency of safety-critical systems specifications, we present an integrated multi-analysis and multi-viewpoint safety engineering tool called I-SafE, which is a solution that supports general safety analysis as well as the specification and analysis of safety requirements traceability to architecture and failure models.<\/strong><\/p>\n Safety engineering artifacts still have been defined by means of natural text in documents, spreadsheets or databases. One major issue caused by that is inconsistency between safety requirements, failure models and architecture [1]. However, safety requirements often result from a safety analysis of the architecture and, lately, must be allocated to elements of the architecture[1]. In this regard, the existing inconsistencies and incompleteness lead to intense efforts required to update the artifacts impacted by the changes and, consequently, significantly decrease the efficiency of the safety assurance architecture [2].<\/p>\n To contribute to overcoming this challenge, this paper introduces I-SafE: Integrated Safety Engineering, an Enterprise Architect[1]<\/sup><\/a>\u00a0based tool that supports the specification of traceable safety requirements, failure models and architecture models, thus contributing to ensure safety-by-construction, as safety is considered early in the process of the system design.<\/p>\n The I-SafE features described in this paper will be illustrated using a simplified version of a fictitious electric motor drive (E-Drive) system, which is depicted in Fig. 1 (see\u00a0PDF<\/a>)<\/p>\n I-SafE supports the specification of functional, logical and technical aspects of the architecture which are based on the Embedded Modelling Profile [3]. Examples of the architecture modelling toolbox provided by I-SafE is depicted in Fig. 2 (see\u00a0PDF<\/a>).<\/p>\n I-SafE supports the creation of failure models of the types Component Fault Trees – CFTs, Failure Modes and Effects Analysis – FMEAs and Markov Chains that are associated to architecture elements. Due to space constraints, only the CFT and FMEA support are described in this paper.<\/p>\n Component Fault Trees (CFT) extend standard fault trees with the concept of modularity in component based specifications. For example, Fig. 3 (see\u00a0PDF<\/a>) depicts a CFT created with I-SafE for the emergency shut-off component of the E-Drive system illustrated in Fig. 1 (see\u00a0PDF<\/a>).<\/p>\n The I-SafE support regarding the specification of FMEA is based on interface-focused IF-FMEA [4] for each system component. For instance, Fig. 4 (see\u00a0PDF<\/a>) depicts an FMEA for the E-Drive’s Pedal Sensor shown in Fig. 1 (see\u00a0PDF<\/a>).<\/p>\n In order to conveniently support the creation of trace links, I-SafE provides an autocomplete mechanism that suggests elements that should be referenced in the safety requirement being specified. These suggestions are made when the text being written, having similarities with the names of elements present in the failure models or architecture models. For instance, as shown in Fig. 5 (see\u00a0PDF<\/a>), as soon as the user starts to type the text fragment\u00a0\u201cThe M\u201d<\/em>, the suggestions of the architecture component \u201cMicroController\u201d (cf. Fig. 1, see\u00a0PDF<\/a>), along with other elements that have similarities with this string, such as the MicroController CFT (cf. Fig. 2, see\u00a0PDF<\/a>), are shown in the suggestion list.<\/p>\n I-SafE provides a visual trace mechanism that allows engineers to visualize all elements related to each safety requirement specification. It allows visualization of (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.<\/p>\n In the example shown in Fig. 6 (see\u00a0PDF<\/a>), the safety requirement has an explicit trace to the MotorController element (cf. Fig. 1, see\u00a0PDF<\/a>). After activating the Visual Trace mode of I-SafE, whenever the user clicks on the safety requirement element, the diagram shown in Fig. 1 (see\u00a0PDF<\/a>) opens and only the referenced element MicroController is highlighted.<\/p>\n I-SafE supports the execution of completeness and consistency checks between safety requirements and architecture design, aiming at detecting and alerting engineers to existing incompleteness and inconsistencies.<\/p>\n 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 Fig. 7 (see\u00a0PDF<\/a>), where a list of safety requirements is displayed along with their types and the completeness violation.<\/p>\n With respect to consistency, one of the main checks offered by I-SafE is on Safety Integrity Level \u2013 SIL inconsistencies, which are caused when safety requirements and the safety-critical architecture elements that address them have incompatible safety integrity levels. For instance, Fig. 8 (see\u00a0PDF<\/a>) 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.<\/p>\n I-SafE provides a range of features that are rarely found in other tools. Among the features presented in this paper, we consider the aspects of integration and traceability as 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>\n [1]\u00a0\u00a0P. O. Antonino<\/a>,\u00a0M. Trapp,\u00a0P. Barbosa<\/a>,\u00a0E. C. Gurj\u00e4o<\/a>,\u00a0J. Ros\u00e1rio<\/a>: The Safety Requirements Decomposition Pattern.\u00a0SAFECOMP\u00a02015:\u00a0269-282<\/p>\n [2]\u00a0 J. Hatcliff et al., 2014. Certifiably safe software-dependent systems: challenges and directions. Hyderabad, India, s.n., pp. 182-200.<\/p>\n [3]\u00a0 T. Kuhn and P. O. Antonino. Model Driven Development of Embedded Systems. Proceedings of the Embedded Software Engineering Kongress 2014. Pages 47\u201353.<\/p>\n [4]\u00a0 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.<\/p>\n [5]\u00a0 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>\n [6]\u00a0 P. O. Antonino and M. Trapp. Automatic Detection of Incomplete and Inconsistent Safety Requirements. SAE 2015 World Congress and \u00a0Exhibition, Detroit, Michigan USA, 2015.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n [1]<\/a> https:\/\/www.sparxsystems.com<\/p>\n<\/div>\n<\/div>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema\u00a0Qualit\u00e4t, Safety & Security<\/strong>.<\/p>\n Hier<\/strong>\u00a0<\/a>finden Sie au\u00dferdem Schulungen zum Thema Software- und Vertragsrecht.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Qualit\u00e4t, Safety & Securitysteht\u00a0hier\u00a0<\/a><\/strong>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nRunning Example<\/h2>\n
Specifying Architecture Models with the Embedded Modeling Profile<\/h2>\n
Creation of Failure Models with I-SafE<\/h2>\n
Tracing Safety Requirements Specified with Natural Language to Failure Models and to The Architecture<\/h2>\n
I-Safe Visual Trace<\/h2>\n
Automated Completeness and Consistency Checks<\/h2>\n
Conclusion<\/h2>\n
References<\/h2>\n
\n
\nUnsere Trainings & Coachings<\/h2>\n
\nQualit\u00e4t, Safety & Security – Fachwissen<\/h2>\n