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 frequency of accidents will be acceptable. For this purpose, safety engineers need to specify all possible safety parameters that directly impact the software architecture 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.
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 systems [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 industrial motivations. We also provide a rationale for SOPHIA as well as a description of its Fundamental Concepts. Moreover, we investigate the strategies regarding the integration 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.
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 Language) [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 provide 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 European 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 applications, middleware, plant (environment), abstract hardware architecture, and preliminary 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 defined 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 contributions 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 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.
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 standards 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 modelbased engineering of safety; 3. providing an environment for system development in which coherence (compatibility of all requirements at the same level of abstraction, i.e., horizontal development) 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
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 between 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 mechanisms (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 consequences 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 Tolerability. 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. Next, we discuss the strategies to integrate the safety conceptual concepts defined above with a given general-purpose modelling language, in this case 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 modification 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.
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 Strategy 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 Concepts 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 approach. Moreover, this approach improves tool interoperability and facilitates the interface 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]. 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
In the context of SOPHIA, we were particularly interested in MARTE to define nonfunctional 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 alignment 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). 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 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.
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 mapping 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 different 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 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 represents 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 contains 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 predefined MARTE data types are imported and reused in SOPHIA constructs. For instance, RealInterval (a MARTE's data type stereotyped VSL::IntervalType) is typing the magnitudoOrder property of FrequencyMapType. This allows instances of IntervalType to (1)
Frequent Fig. 5. Although it is written in pseudo-code, it can be implemented in Java code and easly introduced in a static profile implementation of SOPHIA.
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 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 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 componentbased 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.
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 infrastructure 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.
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 ACES M B Workshop for their valuable suggestions.