E cient safety analyses of complex software intensive embedded systems are still a challenging task. This article illustrates how model-driven development principles can be used in safety engineering to reduce cost and e ort. To this end, the article shows how well accepted safety engineering approaches can be shifted to the level of model-driven development by integrating safety models into functional development models. Namely, we illustrate how UML pro les, model transformations, and techniques for multi language development can be used to seamlessly integrate component fault trees into the UML.
Embedded systems are of crucial importance to our society. We recognize our dependence in the moments when these systems do not work or produce errors. Headlines in the newspaper about plane crashes or car accidents show how coupled the advantages and dangerous disadvantages of these systems are to each other. Therefore the development of embedded systems comes with a large responsibility. Particularly the development of safety critical systems therefore underlies a series of legislative and normative regulations making safety to one of the most important non-functional properties of embedded systems. One of the main requirements is a sophisticated safety analysis of the system. Particularly in the case of software-intensive embedded systems, their complexity is rapidly increasing and extended analysis techniques are required that scale to the increasing system complexity.
Model driven development is currently one of the key approaches to cope with increasing development complexity, in general. Applying similar concepts to safety engineering is a promising approach to extend the advantages of model driven development to safety engineering activities. First, it makes safety engineering as a standalone subtask of system development more e cient. Second, and even more importantly, this is an essential step towards a holistic development approach closing the gap between functional development and safety engineering.
This paper illustrates how model driven design principles can be applied to
safety analysis techniques in order to enable an e cient analysis of complex
systems. In contrast to other approaches it is not the goal to extend existing
development approaches with some additional safety properties. Instead, it is
the goal to shift full- edged, established, and well-accepted safety engineering
approaches to the level of model-driven development and to seamlessly integrate
them to the functional development. In this paper, we use fault trees as an
established analysis approach and illustrate how they can be integrated to a
model-driven design approach. As a starting point we use component fault trees,
which extend standard fault trees with the concept of modularity. In order to
shift this approach to the model driven development level, we have de ned a
domain speci c modeling language and according analysis and transformation
algorithms. Since safety and particularly certi cation bodies are usually very
conservative, it is very important to enable the use of proven-in-use tools to
perform the actual analyses. To this end, model transformations are used to
generate exchange formats for standard fault tree analysis tools like FaultTree+
[
To tap the full potential of this approach, the safety meta models are seamlessly integrated to the functional meta models in the second step. To this end the functional models have been extended using a view concept, i.e., it is possible to de ne a safety view for each component using DSML-based component fault trees. By this means, safety becomes an integral part of software and systems development, safety modeling tasks can (partially) be delegated to developers, consistency checks between safety and functional models can be automated, and safety models are automatically reused together with the owning component. And even most importantly, it is su cient to de ne the safety models of the single components, the overall safety models can then be generated automatically using the component safety models and the functional architecture models. In most cases, the complexity consequently increases linearly with the number of components so that the approach scales to large systems. Regarding rst applications in industry, the advantages of model-driven development can be successfully extended to safety engineering. The combination of modularization, reuse, and automation can tremendously increase the e ciency of safety analyses of large systems. The remainder of this paper is structured as follows. First, we present related work. Second, we introduce component fault trees. Third, we present a more formal de nition of CFTs based on a generic meta-model for components. Based on, we explain our multi language integration for integrating CFTs into architectural design models. Finally, we summarize our approach and discuss its bene ts for industrial usage. 2
Many approaches exist that try to integrate safety analyses and design models in order to reduce e ort by automatically transforming the integrated model into a classical safety analysis such as fault trees. These approaches can be divided into three classes: Semantic Enriching, Fault Injection, and Failure Logic Modeling.
Semantic Enriching annotates additional safety-relevant semantic
information to design models such as the role of a class in a fault tolerance
mechanism, the safety requirements of the annotated entity, or failure modes and
their likelihood of occurrence. The assumption for approaches belonging to this
category is that adding semantic information to entities of the system model is
su cient for the deduction of a safety analysis model and requires less e ort,
than modeling the safety behavior manually. In UML models stereotypes, tagged
values, and constraints are used for this purpose, usually. In [
The advantage of Semantic Enriching is that safety-relevant information is speci ed in the language of the design engineer or programmer and within the same model as the analyzed system. This approach supports thereby the consistency of the design and the safety analysis model and increases the communication between the system developer and the safety engineer. However, the main disadvantage of approaches belonging to this category is the need for a high degree of detail in the safety analysis model complicating the process of annotating the model entities. Additionally, the annotations are usually not using the widely used semantics of common safety analysis models such as fault trees and additional knowledge for using the semantics is needed. This makes them di cult to apply, they are time-consuming, error prone and unfamiliar for safety engineers and certi cation bodies.
Fault Injection requires a formal or an executable design model. Undesired
behavior is modeled along with the system model and model checkers or
simulations, for example, are used to nd inconsistencies between the model and the
safety requirements. This procedure allows a high degree of automation and a
strong correctness of the results. Using model checking for fault injection was
invented by Liggesmeyer in [
The approach presented in this paper, belongs to the third category: Failure
Logic Modeling (FLM) modularly de nes the failure propagation of modules of
the system in parallel to the data- ow through the system similar to a standard
safety analysis. The disadvantage of FLM is that the annotation is still a manual
task and very similar to a manual safety analysis. However, in our opinion this
is also its advantage against Semantic Enriching and Fault Injection. The used
development model is not constrained to be executable, as in fault injection,
and the advantages of semantic enrichment that come from the combination of
the system model and safety analysis model can be achieved without the
drawback of applying a complicated and unfamiliar set of annotations. In failure logic
modeling, the safety analysis can be performed in the way the safety engineer is
familiar with, but modularly and in parallel to the design model, which helps to
handle complexity and increases the communication between safety and system
engineering. Examples of Failure Logic Modeling can be found in [
Fault tree analysis is a deductive, top-down method that analyzes the causes of
a hazardous failure of a complex system. Fault trees o er thus a breakdown with
regard to the hierarchy of failure in uences. The root of the tree is called top
event and the leaves are called basic events. The decomposition of the top
event into the basic events is de ned by the remaining nodes which are logical
operators. However, this kind of hierarchical decomposition is not su cient when
dealing with complex technical systems. In the functional design, the complexity
of these systems is typically handled by an appropriate component concept that
allows the decomposition into manageable components. To facilitate this
architectural decomposition also for the fault tree analysis, the concept of component
fault trees (CFTs) has been proposed in [
CFTs feature a decomposition approach that is used in a similar way in
modern software design notations: subcomponents appear as "black boxes" on the
next-higher level and are connected to the environment via their interface. The
output interface is given by so-called output events and the input interface
is given by so-called input events. Further, a CFT comprises so-called basic
events that represents internal faults. The CFT relates every output event to
its internally caused basic events and its relevant input events. This
decomposition is modeled with logical operators as it is done in the decomposition of a top
event to a set of basic events in a common fault tree. Similar to a component,
a CFT can be instantiated several times in other CFTs. In their environment,
these instantiations are called "subcomponent" or "CFT instances". These
instances can be composed by connecting input and output events. In- and output
events of a CFT appear as subcomponent events when they are instantiated
on the next-higher hierarchy level. The CFT graph as a whole is de ned by its
edge connections and the mappings from subcomponents to the corresponding
CFT model describing their "internals". The complete CFT can be evaluated
qualitatively and quantitatively like a classical fault tree (see [
In the following, we exemplify the modeling of CFTs with the running example of this article. It is a system for charging the battery of a car with an electric power train. This system charging has to ful ll the safety requirement that the car must not start-up when the male connector is plugged, since otherwise the charging cable may crack and electrocute somebody. For detecting the plugging of the male connector, the system comprises a hardware component ProximitySensor, a hardware component VoltageSensor, and a software component PlugDetection.
The hardware components send respectively a signal to the component PlugDetection that indicates whether the male connector is plugged or not. The component ProximitySensor outputs the boolean signal proximity that is supposed to be true when the connector is plugged and false when the connector is unplugged. The component VoltageSensor outputs a signal voltage that is supposed to be true when the plug connection is energized and false otherwise. If both signals are false then the component PlugDetection sets its Boolean output signal plugged to true else it sets signal plugged to false. In this way, the component minimizes the risk of violating the safety requirement due to an undetected plugged connector.
Figure 1 shows the CFT PlugDetection that refers to the detection of a plugged connector based on the signals proximity and voltage. The CFT comprises two output events (top triangles), two input events (bottom triangles) and three basic events (circles). The event plugged omission refers to the common failure mode omission, i.e., an unexpected absence of a signal when it is required. The event unplugged commission refers to the common failure mode commission, i.e., an unintended provision of a signal when not required. The input event Proximity FN captures a false negative value of signal proximity, i.e., the value is false although a connector is plugged. Accordingly, the input event voltage FN refers to a false negative value of signal voltage. A false negative value of both input signals leads to an undetected plugging of the connector. Hence, the CFT de nes that the conjunction of the input events causes both output events. As the outputs events can also be caused by internal faults of the component PlugDetection, the CFT comprises the basic events that refer to these internal faults. It has three basic events in order to distinguish between different kinds of faults. Basic event fault 1 refers for the class of faults that causes only a omission of signal plugged. Basic event fault 2 refers to faults that cause an omission and a commision of signal plugged. Accordingly, it is connected to both OR gates. Basic event fault 3 refers to faults that cause an comission of signal plugged. Please note that the identi ers fault 1 fault 2 and fault 3 are anonymized due to NDA reasons. In practice the names should be expressive and semantically meaningful.
The CFT ProximitySensor that describes the failure behavior of the proximity sensor comprises an output event Proximity FN that refers to a false negative value of the measured signal proximity. The CFT VoltageSensor that describes the failure behavior of the voltage sensor comprises an output event Voltage FN that refers to a false negative value of the measured signal voltage. As illustrated in Figure 1, instances of the CFTs ProximitySensor and PlugDetection are composed by connecting output event Proximity FN with input event Proximity FN in order to de ne the overall CFT graph of the system. Instances of CFTs VoltageSensor and PlugDetection are composed by connecting output event Voltage FN with input event Voltage FN. This means that the fault trees belonging to output events Proximity FN and Voltage FN are adhered to the fault trees belonging to output events plugged omission and unplugged comission. 4
The aforementioned component fault trees enable developers to formally specify the failure-propagation of their developed systems, and enable formal analysis techniques. CFTs are on the most abstract level hierarchical components with parts and connections between them. We therefore de ne CFTs based on a generic meta-model for component based software development that resembles the most important principles of component based development CBD (cf. Figure 4). This meta model was build based on the UML modeling language.
The meta model consists of components, which de ne component types, component proxies, which represent component instances, ports, and directed connections. All are well known concepts in CBD. Components consist of elements, which may be component proxies, connections, or generic parts. Generic parts are abstract placeholders for more specialized language constructs therefore and need to be specialized by more concrete meta models.
CFTs are de ned based on this abstract meta model (cf. Figure 3). This approach is helpful for language integration, which will be described in the next section. CFTs de ne a specialized type of components, CFTComponent, and specializes generic ports to input- and output event ports . Gates and Events are specializations of the abstract element Part. Gates combine events with each other. Two prede ned gate types are common to all calculation backends, these are the prede ned and and or gates. Events represent faults, which are the core of fault trees. After identifying faults and their propagation logic, the next step is the de nition of counter-measures to mitigate or tolerate the faults. Because classic (C)FTs do not support the modelling of measures, in practice the workaround is to model a failing measure as a basic event and relate it to the fault or the fault-subtree with an AND-gate. The semantic of this would be that a fault propagates, whenever the fault occurs AND the counter-measure fails, too. The disadvantage is that one cannot distinguish original faults from failing counter-measures. Having a meta-modelled DSML it is straight forward to add a modelling element called Measure. This makes it not only possible to distinguish faults from measures graphically, but also to use the extended semantic information for additional analyses. One analysis could be to reason, whether every fault is covered by at least one measure. Figure 3 shows the complete meta model of Component Fault Trees, which is the abstract syntax of the CFT language.
Sometimes, for speci c application domains, or for enabling more expressive fault trees, tool vendors provide proprietary gates as extensions to standard fault tree gates. These types are valuable, and therefore must not be omitted by modeling frontends. Additionally, it is necessary to integrate new domain speci c languages with existing tool chains. For these reasons, the concrete syntax of CFTs is realized as a UML pro le. This makes it possible to use UML modeling tools for developing component fault trees, and it enables us to inherit the UML pro ling mechanism for vendor speci c language adaptations. For this reason, the meta model has been converted to a UML pro le (cf. Figure 4).
Our DSML approach for CFTs is based on the separation of modelling and calculation. Thus, the step of code-generation for functional DSML is replaced by a model transformation step from our model to a proprietary, tool speci c format for analysing with an external calculation back-end. The challenge on the one hand and one huge advantage of our DSML approach on the other hand was the demand for supporting several back-ends with vendor speci c language extensions. The need for rapid tailoring and adaption of our DSML arose with the realization that the analytical expressiveness of the di erent back-ends are not equal. Some gate-types such as m-out-of-n-gates cannot be directly transformed to the back-end language of other tools. Therefore we decided to apply the aforementioned pro le based approach together with tailored transformation rules for each tool. By adding pro les to the regular CFT meta model, the language is tailored to a speci c tool. The generic set of transformation rules for CFTs is specialized as well to yield tool speci c transformations that transform to vendor speci c target models. This way, a heterogeneous and non-standardized set of backend tools is made useable through one UML-based frontend, without disabling tool speci c extensions.
Fig. 4. CFT UML pro le 5
The visualization of the elements, names and their relations of the concrete syntax seems to be almost identical to the abstract syntax of the CFT language (cf. Figures 3 and 4). Nevertheless by de ning the concrete syntax of the CFT language as UML pro le, many bene ts of model-driven development approaches are available to the speci cation of fault trees. However, this does not change the fact that the modeling language for describing component fault trees is still isolated. The rst advantage is to create safety models in the same tools that are used for creating the architecture and design of the embedded system.
Moving from this promising step further to model-driven development, we need tightly integrated models that store all relevant information for a developed systen in one location. This enables developers to model relations between different system aspects and prevents redundant storage of information in several repositories. This way components and their ports for example need to be stored only once, in one repository. Languages that focus on speci c aspects of the developed system - for example on CFTs and UML-based architecture de nitions, can refer to this common location. This makes it possible to reuse modeling elements in several modeling languages, and keep them synchronized automatically. The common limitation when applying MDD approaches, the replication of information can be easily mitigated. As an example, the name of components are replicated in two modeling languages, the UML and the CFT DSML. This replication of information leads to inconsistencies as projects grow and get more mature, and introduce therefore signi cant defects into models over time.
The solution to this situation is multi language integration, which is still a challenging and uncommon topic. With multi language integration, modeling languages or DSMLs are integrated in a manner that they refer to the same elements. For example, if a developer changes the name of a component, all references in other modeling languages are updated as well. In the following, we describe the application of our approach to language integration of CFTs and UML-based architecture de nitions.
A common scenario regarding the UML for practitioners is to use only a subset of the UML for developing software, which may be viewed as a UML based DSL. Normally, this language tailoring is done through pro les, which de ne new language elements based on existing meta classes and add (OCL) constraints. This yields a DSL with a UML-based concrete syntax. Optionally, the abstract syntax of the DSML may be speci ed as a meta model.
Our UML based DSML supports only very basic concepts, which are components, ports, and relations. Relations are specialized into generalizations, aggregarions, compositions, and directed, as well as non-directed relations. Component types may consist of component proxies that provide an instance of a de ned component type. Other aspects of the UML are not considered in the following. Our multi language integration approach supports two di erent types of coupling: referencing and harmonization. For our example, we use the tighther harmonization approach. Referencing however is applicable for situations, in which a more light-weight integration is necessary.
Referencing supports the integration of incompatible meta models with each
other. This technique does not require modi cation of any of the meta models
that are integrated, and therefore enables integration of existing tools and MDD
approaches even when they cannot be modi ed easily. Here, meta model
integration is performed through explicit references, mapping functions, and
synchronization. Model elements are explicitely mapped from one modeling language to
another one through mapping functions. These functions de ne links between
both meta models, and are kept in an independent model. A concrete
realization of a referencing based approach was published in [
Considering our multi language integration example, the set of functions f 2 F de ne explicit mappings from CFTs to UML, while f 1 2 F 1 de ne mappings from UML back to CFTs. The shown mapping functions ensure that port names are synchronized properly between components - relevant model elements are passed as parameters to the mapping functions. Additional functions would cover the remaining properties of ports, e.g. they would ensure that ports are deleted synchronously, or they would handle di erent language elements. All language elements that are not explicitely known to mapping functions are ignored. Since mapping functions only extract relevant model information, they are resistant to meta model extensions. Another bene t, which is illustrated in as well is the ability to provide 1:n synchronization - in CFTs, one UML port may be represented by several input or output events, which represent di erent error modes. In the example, there are unexpected values and high delays for port A. This situation is also easlily resolved by mapping functions, because the mapping is performed for each pair of conforming model elements.
The referencing based approach is applicable in situations, in which it is not possible to modify the meta models and/or tools that are integrated with each other. Meta models of both languages remain unchanged, and therefore are not a ected by the integration. This also holds for existing transformations, model checking approaches, and validations.
In our example, two DSMLs are integrated, which both may be modi ed for integration. This enables application of our harmonization approach, which provide a tighter, and more e cient integration of languages than referencing. It modi es the meta model of both languages but ensures that the integrated meta models remain compatible to those of the original languages. Figure 5 illustrates our approach with a generic meta class as example. Here, rst the common base class g is created that holds common properties of classes e and f . Joint properties, such as the proxies property are moved to the common base class. Afterwards, the user visible meta class h is created, which is used for modeling and contains all properties of all integrated classes.
This algorithm ensures a conforming integration of two DSMLs - its detailed and formal description is the following: { If two language elements e and f were distinct in the originating meta models M and N , there are two distinct language elements e0 and f 0 in the combined meta model O. { All language elements e0 in the integrated meta model O have at least all properties of their originating language elements e from each originating meta model. { All language elements e0 in the integrated meta model O are compatible to their source type (i.e. also have the type) e from their originating meta model M .
This guarantees that existing pro les, model transformations, validations, and model checkers may still be used with the integrated meta model, which is our de nition of compatibility. Integration on the other hand guarantees the following: { If two language elements e and f were similar in both originating meta models M and N , they are represented by only one element g0 in the resulting meta model O. This applies to language elements, relations, and attributes. { Attributes with con icting types from originating meta models are not harmonized. { Attributes with con icting default values are given a new default value that conform to the integrated meta model.
These de nitions may be extended to integrated meta models that originate from more than two meta models. A tighter integration is applicable when meta models of modeling languages are su ciently compatible to each other, e.g. when they are built on a common meta model. The big advantage of this integration approach is an implicit synchronization across modelling languages. Since modelling languages are now parts of one holistic meta model, it is not necessary to duplicate information anymore. Therefore, information is always accurate and synchronized.
Meta model harmonization is our approach for tight meta model integration.
This is not a new technique - both, the UML and the MOF apply this technique
to merge language packages that de ne subsets of their respective meta models.
Package merging of one package with another creates the union of both packages,
which spans meta classes, attributes, and relations. Resulting meta classes hold
all properties of the original meta classes. The existing package merge relation
as de ned by the UML is ambiguious in some situations though (see [
Integration of meta models and/or UML pro les requires the integration of meta classes, attributes, and relations. We use the following approach for harmonization of source meta models or pro les M and N (in the following, meta classes are used as synonym for meta classes/stereotypes): { De nition of the harmonized meta model or pro le O. { Harmonization of meta classes/stereotypes from M and N . For every pair of meta classes e and f that are similar in originating meta model, a new meta class g is created that generalizes e and f . Additionally, a new meta class h that specializes e and f is created. { For realization through pro les only: the stereotyped meta class(es) of g is set to union of the stereotyped meta classes of e and f . { Harmonization of class attributes for all meta classes e 2 M and f 2 N .
Every attribute a of meta class e, for which a 2 e and a 2 f holds is moved to g, i meta properties of a can be harmonized (see below). Attribute remains in e or f otherwise. { Harmonization of regular relations r: Regular relations are handled like attributes, therefore, the rules for attributes apply here as well. { Harmonization of generalizations g: Generalization relations g between two elements i, j 2 M are added as new generalization relations g0 between elements i0 and j0 2 O. { Harmonization of aggregations a: Aggregation relations are handled like attributes.
For the harmonization of attributes, additional meta properties need to be checked to ensure proper harmonization. These properties are the following: { def aultV alue de nes the default value of a property. Here, a suitable new default value must be found if default values from both harmonized elements e 2 M and f 2 N di er from each other. If no default value is found, no default value is assumed for g 2 O. { isComposite de nes whether a property is contained in its owner or not. If the value of this property di ers in source elements e 2 M and f 2 N , a creative decision is to be made by language developers to avoid meta modeling con icts. this may yield the decision of keeping both properties seperated, because they obviously follow di erent (static) language semantics, or to decide for one value for g 2 O. { isDerived de nes whether a property value may be derived from other properties. If the value of this property di ers in source elements e 2 M and f 2 N , isDerviced needs to be set to false in g 2 O, because its value needs to be set manually and cannot be calculated. { isReadOnly de nes whether a property may be modi ed. If e 2 M and f 2 N di er, the value for g 2 O is false. This may open unexpected privileges that were not given by original meta models, which is necessary in this case. { opposite de nes an opposite value for an attribute. If values from both originating meta models di er, again a creative decision is necessary, because there is no automated way for harmonization. { The name property is typically the same and kept during harmonization, the type is set to the harmonized input type g that was created during the second step of our approach.
Language-speci c presentations ensure that in each view only properties that
are of relevance to the currently used DSML are visible. For example, the safety
engineer that models with CFTs only perceives CFT related properties of the
Component modeling elements, software architects only perceive UML related
properties. Realization of views is tool speci c - in our case, we used the DSL
engine of MagicDraw [
Meta model harmonization also has implications on the semantics of modeling languages. When a component with an associated CFT is generalized, the sub-components inherit the CFT of the parent component. Therefore, they may add new failure analysis, for example for new ports that are introduced by specialized components. A thorough analysis of these implications for all possible integration scenarios is considered to be future work. 6
From a safety point of view, safety analyses are indispensable for ensuring the safety of embedded systems. Particularly for complex, software intensive systems, safety analyses is very time consuming and error-prone. The approaches we illustrated in this paper, have shown in their practical application that applying the principles of model driven engineering to safety analyses yields a promising means to reduce the e ort and to increase the quality of the analyses. This is particularly true, if the safety analysis models are seamlessly integrated to the functional development models leading to a higher potential for reuse as well as automated generation and consistency checks of safety models. From a DSML point of view, the integration of safety models has shown the feasibility that the concepts of multi language development can be used to integrate non-functional models to functional development models. The harmonization of the modeling language based on pro les as well as the model transformations developed enables the integrated use of accepted modeling environments and proven-in-use analysis tools. The approach has been implemented and evaluated in context of a cooperation project between Fraunhofer IESE and Siemens-CT. The implementation of the modeling language based on the pro ling mechanisms of the UML in combination with additional concepts for the multi language development was fe times more e cient than a traditional development approach (a team that developed a standalone CFT modeler using a traditional development approach required more than ve times as much e ort as an independant team that using the DSML-based modeler). Besides this speed-up factor, a further very important advantage is the exibility of the approach. The CFT extensions can be easily modi ed and extended, which enabled a fast tailoring to the organization-speci c and even the project-speci c requirements, which has been a crucial advantage over the in exible o -the-shelf solutions. The modeling language was evaluated by applying to several real world examples of Siemens-CT. The building of safety models according to the functional model was practical in all examples as a reasonable overall structure for the component fault trees was already given. The approach presented in this article therefore provides a very good basis for future work. Regarding safety, this particularly means the inclusion of further important safety models, like hazard and risk analyses or safety case models. For safety and for the NFP modeling in general, it is very important to further advance the integration over di erent non-functional models.