MoDELS'09 ACES-MB Workshop Proceedings SOPHIA: a Modeling Language for Model-Based Safety Engineering Daniela Cancila1 , Francois Terrier1 , Fabien Belmonte2 , Hubert Dubois1 , Huascar Espinoza1 , Sébastien Gérard1 , and Arnaud Cuccuru1 CEA LIST⋆ , ALSTOM⋆⋆ Abstract. Development of increasingly more sophisticated safety-critical embedded systems requires new paradigms, since manual approaches are reaching their limits. Experiences have shown that model-driven engi- neering is an approach that can overcome many of these limitations. Us- ing model-based approaches however lead to new challenges regarding the cohesive integration of both safety engineering and system design along the system development process. In this paper, we present SOPHIA, a modelling language that formalizes safety-related concepts and their relations with system modelling constructs. We particularly focus on ac- cident models and on how to achieve confidence that the frequency of possible accidents will be tolerable. In addition, we explore some strate- gies to implement SOPHIA as a complementary modelling language to SysML and reuse some useful constructs form the UML MARTE profile. 1 Introduction In order to cope with the increasing design complexity of safety-critical systems, safety assurance should be considered as early as possible in the design process. Among other goals, safety assurance allows achieving confidence that the fre- quency of accidents will be acceptable. For this purpose, safety engineers need to specify all possible safety parameters that directly impact the software archi- tecture design, and then to determine the probability rates of the deviation from fulfilling the system functions. The Safety Integrity Level (SIL) attribute is an example of such a parameter. The design of a given system and its subsystems changes according to the value of the SIL associated with each functionality of the system. Possible values range between “0” (less critical) and “4” (most critical) [19]. Thus, a system architecture including SIL4-functionalities must guarantee the maximum level of safety integrity, which would for example imply to add redundant hardware nodes. ⋆ CEA LIST, Laboratoire d’Ingénierie dirigée par les modèles pour les Systèmes Embarqués Point Courrier 94, Gif-sur-Yvette, F-91191 France {daniela.cancila, francois.terrier, hubert.dubois, huascar.espinoza, sebastien.gerard,arnaud.cuccuru}@cea.fr ⋆⋆ Alstom Transport Information Solution 48 rue Albert Dhalenne, 93482 Saint-Ouen Cedex fabien.belmonte@transport.alstom.com Denver, CO, USA, October 6, 2009 11 MoDELS'09 ACES-MB Workshop Proceedings Recently, the railway safety community has proposed a new methodological guidance to enhance safety evaluation. In this proposal, SIL-to-function alloca- tions exploit a new attribute named Tolerable Accident Rate (TAR). The TAR is defined as the “threshold between what is tolerable and what is undesirable with respect to the consequence of an accident” [8, 3]. In current industrial practice, the TAR is manually calculated, typically by using pre-defined tables. As the value of TAR influences the value of SIL, it may impact the architecture of a system. More precisely, the value of the TAR for a given accident (e.g. the head- on collision between trains) is used to calculate the value of the tolerable hazard for the same accident. Hence, we have a 1:1 correspondence between tolerable hazard and SIL. (We refer the reader interested in the technical details to [8, 3].) Most of current practices on system safety assurance rely mainly on manual processes. They are therefore very dependent of the skill and experience of the engineers. This problem is exacerbated by the fact that safety engineering and software design domains have developed their own techniques and methodolo- gies. Let us consider the example of the railway application domain. On the one hand, safety actors adopt standards that provide recommendations for safety as- sessment. Illustrative examples are fault tree analysis [22] and formal verification techniques, such as the B method [2]. On the other hand, actor from the soft- ware design and development community follow component-based techniques, such as [33, 9, 14]. In this context, defining the “right mapping” between safety models and models for software design/development is an essential challenge. In order to avoid error-prone processes and to integrate both safety engi- neering and system design, we adopt a model-based safety engineering process. Model-Driven Engineering (MDE) [30, 31] is being successfully adopted in several industrial research projects [21, 18, 32, 29]. Two kinds of approaches are actually put into practice. In the first case, safety engineers and system designers share the same model of the system while using different views of it. In the second case, they use different models with clearly and formally defined relationships (using for example model transformation descriptors). In both cases, the direct benefits of MDE concern the possibility of automating part of the process of safety assurance, e.g. by automatically calculating certain information such as TAR parameters from the input safety parameters. This capability does not only simplify the process. It also enables to save time and, more importantly, it makes safety assurance as explicit part of an iterative design process. Indeed, new re- sults can be more easily generated once the model has been changed. Moreover, the fact that models are more formally defined reduces the probability of in- troducing errors or omitting important details, since the analysis information is linked to the architectural model of the system. As a main contribution within this paper, we introduce for the first time SOPHIA, a modelling language for safety concerns. SOPHIA provides an an- swer to safety industrial concerns by allowing designers to specify the safety attributes in a software design model. Our paper focuses on the infrastructure of SOPHIA, which is similar to that of MARTE [25]: It is based on a metamodeling, a profiling and a modeling space. As a result, SOPHIA has an independent lan- guage specification that can complement more general-purpose languages such Denver, CO, USA, October 6, 2009 12 MoDELS'09 ACES-MB Workshop Proceedings as UML or SysML [24]. At the profile level, we propose to use some suitable concepts from MARTE, the OMG’s UML profile for real-time embedded sys- tems [25], in particular the Value Specification Language (MARTE::VSL). In Section 2, we discuss some related works and we identify fundamental criteria and principles for model-based safety engineering. In Section 3, we explain our indus- trial motivations. We also provide a rationale for SOPHIA as well as a description of its Fundamental Concepts. Moreover, we investigate the strategies regarding the inte- gration of safety and software design. Section 4 is the central part of the paper. For the first time, we discuss the whole structure of SOPHIA: from its Fundamental Concepts to the implementation. In Section 5, we compare our approach with those given in Section 2. Finally, conclusions and on-going works are presented. 2 Related Work Integrating safety concerns in general-purpose modelling process is a big challenge that has been explored in many directions. In this section, we focus on a few works which are receiving specific attention in the MDE community. In order to study dependability in AADL (Architecture Analysis & Design Lan- guage) [1], P. Feiler and al. introduce a framework to model the error state propagations in a hierarchical architecture [17]. Error propagation can occur at component level (by composition of the components), at the hardware level (by interconnecting processors) and between the hardware and the components (“due to their binding to the execution platform” [17]). In order to limit, or even avoid, the error propagation, the authors pro- vide suitable filters (guards), for example between the interconnection of components. In [17], P. Feiler and al. addresses error modelling as a complementary view to system architecture, which is an important topic related to safety. However, it does not cope with the problem of accident case modelling and the specification of safety attributes such as the SIL. In order to complement AUTOSAR (the European industrial standard to specify component-based software infrastructures in automotive applications [6]), some Euro- pean industries and academics have defined an architecture description language, so called EAST-ADL [5]. This includes requirements modelling, feature content at the level of a vehicle description, architecture variability, functional structure of applica- tions, middleware, plant (environment), abstract hardware architecture, and prelimi- nary functional allocation. In addition, EAST-ADL enables the modelling of system failure behaviour and allows analysis of that behaviour using safety analysis tools. In particular, EAST-ADL aimed at using a safety design flow compatible with that de- fined by the upcoming ISO 26262 standard, including support for concepts such as hazards, safety goals and requirements, and the representation of ASILs (Automotive SILs). Many of these concepts were represented in the first version of EAST-ADL, but there were many others not considered, e.g. accident and its consequences, or ASIL decomposition. FTA is one of the main safety analysis tools. In [10], Douglass introduces a UML safety profile defining notions such as fault, hazard, and traceability of requirements. Such notions allow us to create fault tree analysis (FTA) diagrams and, hence, to study how “conditions and faults combine to create hazard”. One of the main con- tributions of this approach is to adopt UML and its profiling mechanism to provide a common specification language to integrate safety and design activities. This facilitates the collaboration and common understanding between safety engineering teams and Denver, CO, USA, October 6, 2009 13 MoDELS'09 ACES-MB Workshop Proceedings system design teams. The underlying approach is the following. First, designers create a model with safety attributes, from which FTA is automatically generated. Engineers then study FTA and then they may manually change the model architecture. In other words, this approach does not deal with “safety reverse engineering”. As a result, safety analysis is made a posteriori. When we deal with real industrial cases, a model quickly increases in complexity and in number of components. Consequently, it also occurs in the related FTA. The study of FTA is then a very complex work. In order to reduce such a complexity, one possible way is to iteractivly integrate safety engineering into model-based engineering of an architectural system. The underlying process is to have an automatic propagation of safety attributes in the architectural model such that it is correct with respect to “given safety requirements”. In [15], de Miguel and al. propose an approach similar to work [10]. Therefore, it has similar advantages and drawbacks. Finally, in [26], the authors introduces the UML profile for quality of service and fault tolerance analysis, called QoS&FT profile. In this profile, some aspects of safety analysis are covered (such that fault, errors, fault, non desirable events, etc). Notions, such as accidents and SIL are however not here considered. 3 Safety Engineering This section provides some background information that have been taken into account for the definition of SOPHIA. Before describing the safety fundamental concepts, we want to discuss the high-level requirements for safety modelling from an industrial perspective. Standards EN 50126 [11], EN 50128 [12] and EN 50129 [13] define a safety process plan for programmable electronic signalling devices including risk evaluation, SIL to function mapping and the life cycle recommendations by SIL. In particular, these stan- dards recommend applying fully formal specification to ensure SIL 4. It means that engineers must provide mathematical proven demonstration for the safety properties of a given component. Typically, in industry there is a gap between formal methods and textual system specifications, as well as between subsystem specifications. The main reason for this gap is that there is no standard and common language can be used to capture the different aspects. Semi-formal modelling approaches can bring a common basis to interconnect these different specification aspects. This is the main motivation for formalizing safety attributes into system models, from the early phases of the development process. Therefore, SOPHIA has the following objectives: 1. enabling the specification of safety attributes in the architectural model of as sytem; 2. automating the calculation of some safety parameters in order to afford model- based engineering of safety; 3. providing an environment for system development in which coherence (compati- bility of all requirements at the same level of abstraction, i.e., horizontal develop- ment) and correction (“good” decomposition of parent requirements into children requirements abstraction, i.e., vertical development) properties can be guaranteed by construction and/or verified a posteriori. Provided these general needs, we present in the next section an excerpt of some fundamental concepts of SOPHIA related to accident case concerns Denver, CO, USA, October 6, 2009 14 MoDELS'09 ACES-MB Workshop Proceedings 3.1 SOPHIA Fundamental Concepts The concepts of SOPHIA (and their relationships) are based on Alstom Ontology [7] and on Alstom works such as [8, 3], which model their safety domain knowledge. In this section, we will use metamodels to describe the Fundamental Concepts of SOPHIA. They are organized into a set of packages and libraries. We use packages to introduce notions and their relationships, and we use libraries to specify data types. The package SOPHIA Fundamental Concepts contains two main subpackages, so called respectively SystemDesing and SafetyConcepts. Package SystemDesing specifies the relationships be- tween safety concepts and model elements of a system. Package SafetyConcepts contains the following packages: • package ACCIDENTS, which describes notions and relationships that are involved in an accident. • package MITIGATIONS, which describes notions and relationships about mecha- nisms (barriers) to mitigate an accident; • package FaultContainmentRegion, which describes notions and relationships that are involved in error propagations. In this paper, we focus on package ACCIDENTS. Our intent is to show the details of the whole language design chain, from the formalization of the TAR attribute in the SOPHIA Fundamental Concepts, to the language implementation details. The result of our work is a first, but firm step towards model-based safety engineering. Figure 1 shows some notions of package ACCIDENTS. Among them, we depict the TAR attribute. The notions are represented as metaclasses. Hazard is “an event observable at the system boundary, which has potential either directly or in combination with other factors (external to the system), for giving rise to an accident at railway system level” [3]. AccidentCase is an unintended event with undesirable outcomes. AccidentCase leads to AccidentConsequenques. An AccidentCase is identified by the following properties: a unique ID; an AccidentType chosen from a statically pre-defined list; AutomaticTolerableAccidentRate and TolerableAccidentRate. AutomaticTolerableAccidentRate is the maximum rate of occurrence that is tolerable for a likely Accident [3]. It is specified by a number of events per hour (real number) and it is derived from the frequency and the severity of an accident. TolerableAccidentRate and AutomaticTolerableAccidentRate are similar properties. The only difference is that TolerableAccidentRate is manually set by safety engineers when they have to deal with exceptional cases (i.e., for which a pre-defined table is not available). In Figure 5, Table “a:” identifies the Risk Tolerability of an accident. It is described with combinations of the following properties: severity of the conse- quences and frequency of the accident. TolerableAccidentRate is undefined by default. However, if TolerableAccidentRate is set to a different value than undefined, then it has a higher priority with respect to AutomaticTolerableAccidentRate. The importance of having both properties (i.e., one automatically specified and the other one manually set), is that: 1.) the modelling process can be automated in a correct way that respects table Risk Tolerability, 2.) we have traced to the computation, which is automatically derived from table Risk Tolerability. Furthermore, we can identify the divergence points specified by the exceptional cases. In case of divergence, designers must motivate their choices with respect to the value automatically calculated from table Risk Tolerabil- ity. From an implementation standpoint, designers could motivate their decisions in a suitable dialog box. The implementation of this latter is part of our ongoing work. Denver, CO, USA, October 6, 2009 15 MoDELS'09 ACES-MB Workshop Proceedings Fig. 1. SOPHIA : AccidentCase AccidentConsequences is the result of a given AccidentCase. It is defined by the severity of the consequences with respect to the given AccidentCase. Severity may take only one of the following four predefined values: Catastrophic, Critical, Marginal, or Insignificant. These values of severity are captured by an enumeration which is part of our SOPHIA Fundamental Model library. Next, we discuss the strategies to integrate the safety conceptual concepts defined above with a given general-purpose modelling language, in this case SysML. 3.2 Integration Strategies for SOPHIA and SysML SysML was chosen by Alstom since it is an OMG standard specification for modelling of complex systems. Although SysML provides a formalism to manage requirements and system design together, SysML is lacking of concepts for dealing with specific concerns of safety. We have three possible strategies to integrate SOPHIA and SysML. Strategy a defines SOPHIA as an extension to SysML. It has the advantage to be optimally tailored to the aimed integration with SysML. One of the main drawbacks of this strategy is that safety concepts will strongly depend on SysML. Then, any modifi- cation of SysML might lead to a modification in the SOPHIA extensions. In addition, safety concepts and SysML are conceptually disjoint, although complementary, and directly extending SysML does not make sense in our context. Denver, CO, USA, October 6, 2009 16 MoDELS'09 ACES-MB Workshop Proceedings Strategy b defines SOPHIA from scratch, i.e. as a pure domain-specific modeling specification language (DSML) (i.e. independently of UML) and then combining this metamodel with SysML. Consequently, Strategy b surmounts the drawbacks of Strat- egy a: safety concepts are independent not only of SysML but also of UML. It provides a framework that is fully dedicated to safety concepts and it is independent from other formalisms. As discussed in work [16], Strategy b has the following drawback: having safety models defined using two independent formalisms leads to strong difficulties for interfacing both types of models of the same system. This is particularly problematic for tracing safety information with the system architecture models. This problem is mainly reflected at tool level, since traceability always imply an important endeavour. Strategy c proposes to firstly introduce SOPHIA as a package of Fundamental Con- cepts via a metamodel, in a way that is independent of the UML formalism. In a second stage, this metamodel (also called domain model ) is implemented as a UML profile. In this way, we overcome the drawbacks of Stategies a and b, because the concepts are defined independently of UML, and, thereby, gain the benefits of a domain-specific ap- proach. Moreover, this approach improves tool interoperability and facilitates the inter- face and traceability between different modelling aspects of the same system. SOPHIA and SysML languages (which are both designed as UML profiles) may indeed be used jointly in the same UML tool. A successful example of this approach is MARTE [25]. Language Engeneering End User Domain Tool environment Domain Metamodel Profile One single Model One single Tool strategy a NO YES YES YES strategy b YES NO NO NO strategy c YES YES YES YES Fig. 2. Strategies to integrate safety modeling language in the system architecture 4 From SOPHIA Safety Concepts to Implementation 4.1 SOPHIA Architecture We adopt Strategy c and we develop it further. First af all, we strategically use the definition of profile, firstly introduced by S. Cook, and successfully adopted by other researchers: a profile is a family of related languages. It suggests the idea of exploiting the composition of pre-existing profiles. Indeed, our intent is not to define completely “new” metamodel and profile, covering all concepts from safety to architectural design. Our intend is indeed to reuse the existing work as much as possible, so that we can take advantage of pre-existing works and related tools. In spite of SysML role for requirements and system’s architecture (requirement and block diagrams), SysML lacks in the specification of temporal attributes [4]. Several European research projects are therefore willing to define a combined usage of both SysML and MARTE. Denver, CO, USA, October 6, 2009 17 MoDELS'09 ACES-MB Workshop Proceedings In the context of SOPHIA, we were particularly interested in MARTE to define non- functional properties (MARTE::NFP) and MARTE::VSL to valuate these properties. The MARTE::NFP package allows designers to annotate a UML model with non-functional properties. VSL stands for Value Specification Language and allows designers to specify “parameters/variables, constants, and expressions in textual form” [25]. Moreover, VSL supports arithmetic and logical expressions. Beyond the benefits of the SOPHIA align- ment with a recognized international standard, the main advantage of this integration is the ability to support a well-formed syntax and semantics for safety parameters and to consequently enable automated derivation of dependent safety variables (See Section 4.2). FUNDAMENTAL SOPHIA MARTE UML foundamental foundamental CONCEPT concepts concepts LANGUAGE LEVEL ENGINEERS DOMAIN <> <> <> <> PROFILE SysML SOPHIA MARTE LEVEL (subset) <> (subset) END <> USER MODELING DOMAIN USER LEVEL MODEL Fig. 3. Overall Structure Figure 3 shows the overall structure. We have two main domains: end user domain and language engineering domain, which is in turn subdivided in two levels, Profile and Fundamental Concept. End user domain corresponds to M1 level in the OMG four-level hierarchy [23]. Designers only work in the modeling level. The language engineering domain corresponds to M2 level in the OMG four-level hierarchy. In the Profile level, we specify namesake profiles. In the Fundamental Concept level, we have UML metamodel and data (Fundamental Concepts for safety and MARTE in the figure). In the following, we discuss the overall structure, as illustrated in Figure 3. At Modelling level, designers specify the model of a system. In order to specify the architecture of a system and associated requirements, designers need to apply SysML to their UML model. Next, designers annotate the model with safety attributes by applying the SOPHIA profile. In order to specify temporal attributes, designers exploit the MARTE stereotypes that are already imported by SOPHIA. At Profile level, we have suitable languages of (at least) three families (profiles): SysML, SOPHIA and MARTE. One of our on-going works is to identify the minimum subset of SysML and MARTE to specify the requirements given by Alstom. SysML is a UML profile. In Figure 3, UML stereotype “reference” shows such a relationship [27]. Note that SysML is only introduced as a UML extension and, then, SysML intentionally has not a fundamental concepts level. Denver, CO, USA, October 6, 2009 18 MoDELS'09 ACES-MB Workshop Proceedings SOPHIA is a UML profile for safety modelling modelling whose definition is based on SOPHIA Fundamental Concepts. In UML, there is not a specific symbol between a profile and its fundamental concepts. To explicitly capture this relationship, we use a dashed arrow annotated with the word “mapping”, following the OMG notation introduced in work [28]. Like SOPHIA, MARTE extends UML and it is based on MARTE Fundamental Concepts, so-called MARTE Domain Model. At fundamental concepts level, we have UML metamodels respectively denoting SOPHIA Fundamental Concepts and MARTE Fundamental Concepts. 4.2 SOPHIA, a UML profile for safety In this section, we describe the UML profile for SOPHIA. It consists of a set of UML extensions and libraries concretized through stereotypes and data types. They map to the SOPHIA Fundamental Concepts (see Figure 3 for a big picture). Similarly to the SOPHIA Fundamental Concepts packages, the corresponding UML profile the profile is designed following a modular approach by grouping language constructs into individual packages, with the ability to select only those packages that are of direct interest in a given model. Due to space limitations, it is not possible to provide details covering the all profile. Therefore, we will focus on the SOPHIA package ACCIDENTS described in Section 3.1. In the package ACCIDENTS every fundamental concept will directly result in a UML stereotype with its corresponding properties. In this case, there is a 1:1 map- ping between the Fundamental Concepts and the profile element. The bottom package in Figure 4 defines how the metaclasses of the UML metamodel are extended with SOPHIA concepts, while the top-hand package shows a subset of the SOPHIA library with some enumeration types of interest. Before describing the details of how SOPHIA exploits MARTE::VSL, let us introduce a real industrial railway example of risk assessment. Example Figure 5 shows a typical example of risk assessment tables used in the railway domain. Such tables are used to identify the tolerable accident rate (TAR) of a given accident case (stereotype AccidentCase in Figure 4) and the occurrence rates of the dif- ferent consequences of an accident case (stereotype AccidentConsequences in Figure 4). Typically, these tables are standardized by the territory authorities. For the sake of simplicity, we focus on the calculation of the TAR and the consequence occurrence rate parameters for a given country. Starting from “Table a:” of Figure 5, safety engineers define a severity level for every accident case. This information allows for identifying the threshold of the accident case risk. (annotated with “T” in the figure.) The threshold risk identifies the upper limit of a tolerable risk. For instance, let us consider a Critical severity level. The corresponding threshold risk can be identified in the fourth row of the Critical column. This corresponds to the Undesirable risk level. The obtained threshold risk level can then be used to identify a corresponding threshold frequency of the accident case. In our example, such frequency level is Remote. This yields an input value for “Table b:”. “Table b:” describes a mapping of frequencies of accident cases and numerical information about the magnitude order of such frequencies. This magnitude order is specified as an interval of real numbers. The lower bound value of this interval, corresponding to the threshold frequency level of a given accident case, represents the Denver, CO, USA, October 6, 2009 19 MoDELS'09 ACES-MB Workshop Proceedings LIBRARY <> <> <> SeverityKind FrequencyKind RiskKind Catastrophic Frequent Intolerable Critical Probable Undesiderable Marginal Occasional Tolerable Insignificant Remote Negligeable Improbable Incredible <> PARAMETERS <> MARTE (see fig. 5) (subset) <> ACCIDENTS (uml) (uml) ACTOR UseCase <> <> <> Hazard AccidentConsequences AccidentCase iD: Identification tolerableAccidentRate : THR severity: SeverityKind accidentType: AccidentTypeKind \ automaticTolerableAccidentRate : THR \ automaticOccurenceRate: FrequencyMagnitudoMap tolerableAccidentRate : TAR \ automaticTolerableAccidentRate \ : TAR Fig. 4. SOPHIA: focus on TAR TAR value for this accident case. In Figure 5, the TAR value the studied accident case is 1x10-8. Figure 6 shows the model representation of “Table a:”. In a:RiskTolerabilityAccident, each line of attribute RiskMapping represents a line of “Table a:”. Consider “Table a:”. We can read it as: we taken two values, one for colomn and one for row, then, we uniquely identify one cell, which contains the value of the risk. For example, for the colomn we select severity = critical and, for the row, frequency = Incredible Hence, we achieve a unique cell, which contains risk = N egligeable. The first line in Figure 6 repre- sents the list of these attributes and their values. In instance a:RiskTolerabilityAccident, each line is given by the above procedure. In order to model the threshold between what is tolerable and what is undesiderable (noted by “T” in Figure 5), we introduce the Boolean attribute isThreshold in Figure 6. Therefore, if severity = critical, then risk = U ndesiderable, because isThreshold = T rue. a:RiskTolerabilityAccident is an instance of class RiskTolerabilityAccident, which con- tains one attribute riskMapping of type RiskMappingType. We stereotype RiskMappingType with VSL::TupleType. As might be expected, the VSL package (which contains a set of stereotypes extending the data type of UML) is applied to some of the SOPHIA data types. By definition, a TupleType is a data type that combines different types into a single aggregated type [25]. This allows instances of these tuple types to be annotated as composite values following the textual syntax defined for VSL tuple specifications. Similarly to Table “a:”, we represents “Table b:” by Figure 7, where some pre- defined MARTE data types are imported and reused in SOPHIA constructs. For in- stance, RealInterval (a MARTE’s data type stereotyped VSL::IntervalType) is typing the magnitudoOrder property of FrequencyMapType. This allows instances of IntervalType to Denver, CO, USA, October 6, 2009 20 MoDELS'09 ACES-MB Workshop Proceedings a: (1) input designer severity frequency Insignificant Marginal Critical Catastrophic Frequent Intolerable Intolerable Intolerable Intolerable Probable TUndesiderable Undesiderable Intolerable Intolerable (3) Occasional Tolerable TUndesiderable Undesiderable Intolerable T (2) Remote Negligeable Tolerable Undesiderable Undesiderable Improbable Negligeable Negligeable Tolerable TUndesiderable Incredible Negligeable Negligeable Negligeable Tolerable frequency real interval (6) Frequent 1E−3 <= F AutomaticTolerableRateAccident Probable 1E−5 <= F < 1E−3 Occasional 1E−7 <= F < 1E−5 (4) Remote (5) 1E−8 <= F < 1E−7 Improbable 1E−9 <= F < 1E−8 b: Incredible F < 1E−9 Fig. 5. Table Risk Tolerability and Table Frequency Fig. 6. package PARAMETERS: SOPHIA and MARTE for “Table a:” be specified with the VSL syntax for interval values, as depicted in b:FrequencyMagnitudoMap. Algorithm to calculate the TAR parameter: In the sequel, we describes the algorithm used to derivate the TAR parameter. GLOBAL VAR RiskTolerableAccident : ARRAY[SEVERITY KIND][FREQUENCY KIND]: [risk:RISK KIND,IsThereshold:BOOLEAN]; GLOBAL VAR FrequencyMagnitudeMap: ARRAY[FREQUENCY KIND]: REAL INTERVAL; AutomaticTARCalculate (UserSeverityValue:SEVERITY KIND): TAR; VAR MyFrequency: FREQUENCY KIND; VAR MyInterval: REAL INTERVAL; VAR j: INTEGER; j := 0; Denver, CO, USA, October 6, 2009 21 MoDELS'09 ACES-MB Workshop Proceedings Fig. 7. package PARAMETERS: SOPHIA and MARTE for “Table b:” WHILE (RiskTolerableAccident [UserSeverityValue][j].IsThereshold hi TRUE) DO j := j+1; MyFrequency := FREQUENCY KIND[j]; MyInterval := FrequencyMagnitudeMap[MyFrequency]; RETURN AutomaticTARCalculate := MyInterval.LowerBound; Although it is written in pseudo-code, it can be implemented in Java code and easly introduced in a static profile implementation of SOPHIA. 5 Discussion In Section 2, we have discussed some works on safety that have a great impact in the MDE community. Most of them provide both a way to specify the safety attributes in the design model, and tool support for safety analysis. Often, we have faced on two different models: one for safety and another one for design modelling. The focus is then on the “right mapping” and in the a-posteriori verification of the safety attributes. SOPHIA is based on four capital pillars: – SOPHIA Fundamental Concepts; – reuse of pre-existing profiles (and then their tool support); – automation on the propagation of the safety attributes in the design model; – a-priori verification of the safety attributes in a correct way regarding to pre-defined risk tables. In the sequel, we discuss each SOPHIA pillar with respect to some of the works presented in Section 2. Altough SOPHIA is a UML profile, SOPHIA Fundamental Concepts have been created as free as possible from considerations related to specific solution technologies so as to not embody any premature decisions that may hamper later language use. This means that the fundamental concepts model can be concretized not only as a Denver, CO, USA, October 6, 2009 22 MoDELS'09 ACES-MB Workshop Proceedings UML profile, but also as an independent modelling language, possibly implemented as an Ecore metamodel or an XML schema, as well. Note that, although the SOPHIA Fundamental Concepts are specified in the form of a metamodel with a textual semantic description (like in MARTE), it represents only conceptualization entities synthesizing the “universe of discourse”. This pillar is similar to that presented in work [15] in which the authors first define a safety conceptual model of safety-aware component- based architectures and just then define a safety UML profile. The second pillar introduces SOPHIA as a UML profile, by adopting the definition of profile firstly given by S. Cook. As a result, SOPHIA profile strategically reuses some packages of MARTE and can be easily integrated in a SysML system architecture. The third pillar put the strength in improving the automation of the modelling process. In particular, SOPHIA provides a framework to automatically generate the value of TAR and the frequency of an accident, from the specification of only one attribute by users, which is the severity attribute of a consequence. This attribute is given by engineers by choosing one of four possible values. Finally, the fourth pillar’s objective is to enable safety ensurance calculation along the development process, in a way that is correct with respect to pre-defined tables. 6 Conclusions In this paper, we present for the fist time SOPHIA, a model-based safety engineering approach. SOPHIA responds to industrial needs regarding the integration of safety engineering and system design. SOPHIA provides a metamodeling and profiling infras- tructure to specify and propagate the safety information on design models. We have particularly focused on the TAR calculation, which is the first step of the risk evaluation of an accident. The result of some safety attributes, such as TAR, influences the SIL and, hence, changes the model architecture. Such safety information is a-priori correct regarding to pre-defined risk tables. Currently we are performing tests on industrial real cases. We are applying the same process (as discussed for TAR) to other safety attributes. We also intend to mathematically formalize correctness of the automatic propagation of the safety attributes in the design model. Acknowledgment This work has been performed in the context of the IMOFIS project of the System@tic Paris Région Cluster. It is sponsored by the ”Safe, reliable and adapted transportation” program (PREDIT) of the “Agence Nationale pour la Recherche”. The authors would like to thank the all member of the IMOFIS project [20] and the reviewers of ACESM B Workshop for their valuable suggestions. References 1. AADL. Architecture Analysis & Design Language. www.aadl.info/aadl/ currentsite/index.html. 2. J. R. Abrial. The B-book: assigning programs to meanings. Cambridge University Press, 1996. Denver, CO, USA, October 6, 2009 23 MoDELS'09 ACES-MB Workshop Proceedings 3. Alstom. Guidance for safety analysis. MODTRAIN, MODCONTROL Sub-Project, 2008. 4. C. André. Time Modeling in MARTE. In FDL’07 Forum on specification and Design Languages, Barcelona, Spain, 2007. 5. ATESST Project. Advancing Traffic Efficiency and Safety through Software Tech- nology. ATESST STREP - FP6 project. http://www.atesst.org. 6. AUT@SAR. Automotive Open System Architecture. www.autosar.org. 7. F. Belmonte. T1.1 guide de modélisation. Projet IMOFIS, Alstom Transport, System@tic, 2009. 8. A. Blas and J. L. Boulanger. Comment améliorer les méthodes d’analyse de risques et l’allocation des THR, SIL et autres objectifs de sécurité. In Lambda-Mu, 16e Congrès de Maı̂trise des Risques et de Sûreté de Fonctionnement, Avignon, France, 2008. 9. S. Bliudze and J. Sifakis. The Algebra of Connectors - Structuring Interaction in BIP. In Int. Conf. EMSOFT, pages 11–20, 2007. 10. B.P. Douglass. Build Safety-Critical Designs with UML-based Fault Tree Analysis- Defining a Profile. www.embedded.com/design/opensource/217200312?pgno=1. 11. CENELEC. EN-50126: Application ferroviaires -Spécification et démonstration de Fiabilité, Disponibilité, Maintenabilité et Sécurité (FMDS). Norme, CENELEC, 1999. 12. CENELEC. EN-50128: Applications ferroviaires - Système de signalisation, de télécommunication et de traitement - Logiciels pour systèmes de commande et de protection ferroviaire. Norme, CENELEC, 2001. 13. CENELEC. EN-50129: Application ferroviaires - système de signalisation, de télécommunication et de traitement - systèmes électroniques relatifs à la sécurité pour la signalisation. Norme, CENELEC, 2001. 14. L. de Alfaro and T. A. Henzinger. Interface automata. In Proceedings of the Ninth Annual Symposium on Foundations of Software Engineering, pages 109–120. ACM Press, 2001. 15. M. de Miguel, J. Briones, J. Silva, and A. Alonso. Integration of satety analysis in model-driven software development. 2008. 16. H. Espinoza, B. Selic, D. Cancila, and S. Gérard. Challenges in Combining SysML and MARTE for Model-Based Design of Embedded Systems. In In Proc. of Int. Conf. on Model Driven-Architecture Foundations and Applications (ECMDA 09), volume 5562. LNCS, 2009. 17. P. Feiler and A. Rugina. Dependability Modeling with the Architecture Analysis & Design Language (AADL). Technical report, Software Engineering Institute, Carnegie Mellon, 2007. 18. B. Hamid, A. Radermacher, A. Lanusse, C. Jouvray, S. Gerard, and F. Terrier. De- signing fault-tolerant component based applications with a model driven approach. In IFIP Workshop on Software Technologies for Future Embedded and Ubiquitos Systems (SEUS 2008), Springer LNCS. 19. IEC. 61508:1998 and 2000, part 1 to 7. Functional Safety of Electrical, Electronic and Programmable Electronic Systems., 2000. 20. IMOFIS Project. Ingénierie des MOdèle de FonctIons Sécuritaires. www.imofis. org/. 21. E. Jouenne and V. Normand. Tailoring IEEE 1471 for MDE Support. In UML Modeling Languages and Applications, LNCS, Springer, 2005. 22. N. Limnios. Fault trees. ISTE, 2007. 23. OMG. http://www.omg.org/. Denver, CO, USA, October 6, 2009 24 MoDELS'09 ACES-MB Workshop Proceedings 24. OMG. Systems Modeling Language SysML. www.sysml.org. 25. OMG. UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded systems, Beta 3. www.omgmarte.org. 26. OMG. UML Profile for Modeling Quality of Service and Fault Tolerance Charac- teristics & Mechanisms (QoS & FT profile). www.omg.org. 27. OMG. Unified Modeling Language (UML) Specification: Infrastructure. Version 2.0. www.uml.org, 2004. 28. OMG. UML Profile for Schedulability, Performance, and Time Specification. www. uml.org, 2005. 29. F. Ougier and F. Terrier. ADONA: an open Integration Platform for Automative Systems Development Tools. In Euopean Congress Embedded real Time Software (ERTS), 2008. 30. D. Schmidt. Model-driven engineering. IEEE Computer, pages 25–31, February 2006. 31. B. Selic. From Model-Driven Development to Model-Driven Engineering. Keynote talk at ECRTS’07. http://feanor.sssup.it/ecrts07/keynotes/k1-selic.pdf. 32. F. Terrier and S. Gerard. MDE benefits for distributed, real-time and embedded systems. In From Model-Driven Design to Resource Management for Distributed Embedded Systems, IFIP TC 10 Working Conference on Distributed and Parallel Embedded Systems (DIPES 2006), 2006. 33. Veryard Projects. Component-based Development FAQ. http://www.users. globalnet.co.uk/~rxv/CBDmain/cbdfaq.htm, February 2008. Denver, CO, USA, October 6, 2009 25