Safety-critical systems are subject to rigorous safety analyses, e.g., hazard analyses. Fault trees are a deductive technique to derive the combination of faults which cause a hazard. There is a tight relationship between fault trees and system architecture as the components contain the faults and the component structure in uences the fault combinations. In this paper, we describe an explorative case study on multiple evolution scenarios of a factory automation system. We report on the evolution steps on the system architecture models and fault trees and how the evolution steps in the di erent models relate to each other.
Safety-critical systems require a rigorous assessment of the system's safety. Different techniques like Fault Tree Analysis (FTA) and Failure Mode and E ects Analysis (FMEA) are used to analyze the relations between failures of system parts and hazards, which are situations that might lead to accidents which harm life, health, property or the environment.
The outcome of hazard analysis techniques like FTA and FMEA are the
corresponding safety evaluation models, e.g., fault trees, as well as improved
and revised architectural and behavioral models. However, all these models are
not totally independent but rather have a tight relation, e.g., the failures of
an architectural component must be considered in the fault tree. Hence, the
consistency of these models is of utmost importance since inconsistencies would
lead to an incorrect safety evaluation which can lead to severe consequences.
System evolution makes the consistency problem worse as not only at one point
in time consistency between the models must be ensured but also after each
evolution step as also noted as challenge for evolution in [
The overall goal of our work is to support the co-evolution of system
architecture and fault tree models to ensure the consistency between those two models.
We envision a model transformation based approach where incremental model
transformations are used to evolve one model and co-evolve another model.
Existing approaches (e.g., [
As a rst step in this research, we analyzed a case study for the evolution
of a factory automation system to identify the possible model changes, the
relations between elements of the two models and the changes in the two models, as
well as where input from the user is required. The example is commonly used in
the German priority program \Design for Future | Managed Software
Evolution" and addresses a pick and place unit (PPU). The evolution scenarios on the
architecture have been described in [
We developed architecture and fault tree models for a safety-relevant subset of the PPU evolution scenarios. This enabled us to study the evolution of the individual models as well as to study the relation between the individual evolution of the two models in order to understand which changes in one model a ect changes in another model.
The models and detailed model changes for the selected evolution changes
are the rst contribution of this paper which enables other researchers to study
co-evolution as well. The raw data is made available to the general public at [
The next section introduces the two modeling languages for software architecture and fault trees as well as the evolution scenarios of the PPU case system|including the individual evolution of the two models. Based on that, Section 3 describes the identi ed general evolution changes and the identi ed relations between the evolutions of the di erent models. Section 4 draws the conclusions and outlines future work. 2
Modeling Languages and PPU Case Study System Section 2.1 introduces the two modeling languages used to express the two types of co-evolving models: system architecture and fault trees. Section 2.2 describes the pick and place unit (PPU) case study system, including the manually created|and individually evolving|models. 2.1
Due to space limitations, we provide only textual descriptions of the core
concepts of both languages, referred to as SA and FT. In both cases, well-known
concepts from architecture description languages (ADLs) [
The core entities provided by our software architecture (SA) language for describing system architectures are components, ports, and connectors. SA distinguishes between type and instance level for these elements. Component types can be further distinguished between hardware (electronic and mechanical) and software. Components may be composite structures of other interconnected components. SA also includes concepts for ports and connectors, which are omitted in this paper due to space limitations.
Our second modeling language FT allows the de nition of a failure model
and a set of corresponding fault trees. A failure model includes the de nition of
error types and failure types and their instances based on [
The case study system is a laboratory plant, called pick and place unit (PPU).
The PPU mimics an industrial plant by moving so-called work pieces (WPs)
between di erent working positions where they are stored or processed. Out of
the 14 evolution scenarios that have been de ned for the PPU [
Figure 1(a) includes the decomposition of the PPU into three top-level component instances for stack, crane, and slide (depicted as part of the sorter introduced in SC10)|with a dedicated component type for each. The stack and the crane are further decomposed according to the afore-mentioned information about this scenario, including the software components responsible for their control. Note that both the sensors and the software components share the same <<Sensor>> WPpresents: TactileDigital +Sc2 +Sc7 <<Sensor>> Metalpresents: InductiveDigital <<Sensor>> Lightpresents: OpticalDigital
~Sc3,4 <<SoftwareComponent>> craneFB:FunctionalBlock
<<Sensor>> upS:TactileDigital
<<Sensor>> downS:TactileDigital <<MechanicalDevice>> cylinder:Cylinder <<MechanicalDevice>> vacuum:Vacuum
+Sc3 <<Sensor>> #Sc4 atPositionStampS:
InductiveDigital <<MechanicalDevice>> ConveyorBelt:Conveyor +Sc9 +Sc10 +Sc10 <<Actuator>> pusher2:Pusher <<Actuator>> pusher:Pusher
+Sc10 Sensor for Pusher2 error occurs in Sorter Belt speed impl error occurs Sensor for Pusher error occurs in Sorter Pusher2 pushes at wrong time ≥1
G10 Pusher pushes in wrong time Belt is timeworn
Belt is slack G9 ≥1
Sensor for Pusher error occurs in Sorter Belt is timeworn
Belt is slack
Belt speed impl error occurs &&
G7
+Sc4 Sensor error for position of Stack occurs (redundant) respective type for simpler presentation: a type for tactile digital sensors and one for software building blocks.
With respect to safety, the FT model for this scenario includes ve error types (software error, sensor error, timing and general vacuum errors, and external error), three failure types (position failure, timing failure, exceeded capacity), as well as respective failure (four) and error (eight) instances for the respective component instances. Figure 1(b) shows an FT, referred to as FT1, for the hazard that a WP gets outside the system.
SC2 | Black Plastic WPs A sensor (inductive digital) is added to the stack, which|together with the existing tactile digital sensor|allows to distinguish metallic WPs from black plastic WPs introduced in this scenario. In the SA model, this leads to an addition of a new component type (for inductive digital sensors) and a component instance of this type as subcomponent of the stack. With respect to safety, no changes to the failure model and the FT appear, as the two types of WPs are not handled di erently, so far.
SC3 | Stamp Module Added A stamp is added, including a magazine, a cylinder, and four sensors (tactile digital). The magazine moves a WP to/from the stamp position; the cylinder does the actual stamping by moving down, pressing, and retracting. Two of the sensors are used for the magazine; the remaining two for the cylinder. An additional tactile digital sensor is added to the crane in order to detect when it is at the position of the stamp. Only metallic WPs are stamped. The SA model is changed at two places. First, a new sensor component instance (existing type) is added to the crane. Second, a new top-level component instance for the stamp (along with the addition of a new component type), including component instances for the software (existing type), magazine (including a new type), cylinder (existing type), and the four sensors (existing type) are added. With respect to safety, six error instances (existing error types) for sensors are added: ve for the sensors introduced in this scenario and another for the sensor added in SC2, which is used now. A failure instance and a corresponding failure type are added for the event that a wrong WP is stamped. This scenario also introduces a new hazard: WPs may get corrupted. Therefore, we created a second FT, referred to as FT2, which includes three basic events|a sensor error in the stack as well as a sensor and an implementation error in the stack|and an OR gate leading to an intermediate event for pressing wrong WPs. A diagram for FT2 is not included due to space limitations. SC4 | Inductive Sensors for Crane Positioning Each of the ve tactile digital crane positioning sensors are replaced by inductive digital sensors, which are more robust against pollution. In the SA model, this changes the component type of the component instances for the crane sensors. With respect to safety, the probability of the ve basic events in FT1 that one of the crane sensors fails is decreased. FT2 remains unchanged.
SC4b | Increase Reliability of Crane Positioning As a variant of SC4 with redundancy being introduced, the new inductive sensors are added but the existing sensors remain (being spatially shifted). In the SA model, this scenario leads to the addition of ve sensors as subcomponents of the crane (component instances with existing component type). With respect to safety, ve error instances (existing type) are added to the failure model for the new sensors. In FT1, new basic events are added for the sensor errors. Five AND gates (G3{7 in Figure 1(b)) are added, each having two basic events as input and leading to the already-existing OR gate (G8). Note that the following scenarios are not based on this one but on SC4.
SC7|Additional White WPs In order to support newly introduced white WPs, a new optical digital sensor is added to the stack. White WPs are stamped. In the SA model, the new sensor is added as a new component instance of the stack, including a new type for the optical digital sensor. The controller logics of the stack is changed to incorporate the kind of WPs. With respect to safety, a new error instance (existing error type) is introduced for the new sensor. A basic event for the sensor error is added to FT2 as input to an existing intermediate event as output of an existing OR gate.
SC8|Di erent Pressure Pro les This scenario introduces two additional components to the stamp, in order to support stamping with di erent pressure pro les: a proportional valve and an analogue pressure sensor. White WPs are stamped with less pressure than metallic WPs. Changes to the SA model are the addition of subcomponent instances (proportional valve and analogue pressure sensor) to the stamp (including types) and changes to the stamp's controller logic (software). In the failure model, new error instances are added for the stamp's controller (existing error type), as well as for errors of the valve (new error type for actuator errors) and the sensor (existing error type). A new failure instance (existing type) is added for the event that too much pressure is put to white WPs. In FT2, four new basic events are added: two for sensor errors (the stack's WP sensor and the stamp's pressure sensor), and others for errors in the valve and the stamp's controller logic. These new basic events lead to a new intermediate event (referring to the created failure instance) via a new OR gate. SC9|Installation of Sorter A conveyor is added to the PPU, which uses a belt to transport WPs to the slide|now located at the end of the belt. Conveyor and slide are now referred to as the sorter. Changes to the SA model are the creation of a new top-level component for the sorter, including the conveyor and the slide|which previously was a top-level component|as subcomponents. With respect to safety, an error type for the belt material corruption and two corresponding error instances for the belt to become slack or time-worn, respectively, are added. One failure instance along with a new failure type for speed failures of the belt is added: belt too fast. Basic events for each new error instance, an intermediate event for the new failure instance, and two OR gates (G1, G12) are added to FT1.
SC10|Additional Slides and Pushers Two additional slides are added to the sorter at both sides of the conveyor's belt to increase the PPU's output storage capacity. Pushers are pushing the WPs into the slides. Two optical digital sensors are used to detect WPs. The SA model is changed by adding two additional slides, the two pushers, and the two sensors as subcomponent instances (new type for the pushers) of the sorter component. With respect to safety, two error instances of existing type (external cause for exceeded slide capacity, sensor error for WP detection), and a failure instance of existing type (timing failure for the pushers) are added for both sides. Also for both sides, FT1 is extended by two intermediate events referring to the new failure instances, as a result of two OR-connected (new Gates G9, G10) occurrences of the basic events. 3
Identi ed Relations Between Model Changes In order to understand the relations between the changes in one model and changes in the other models presented in the previous section, we summarized the changes in Table 1. The table shows the individual changes of the architecture model in the rows and the changes on the failure model and the fault trees in the columns. The cells contain the scenario IDs. This means that in the given scenario a certain change in the architecture coincides with a certain change in the failure model and fault tree. We do not include ports and connections for simplicity and exclude the initial scenario. +Component%Type +Component%Instance 0Component%Instance ~Component%Instance%(SW) #Component%Instance%(type) No%change 3 3 e p 8,#9%rrryET+o7,#8,%rrrE+o#9,#Itscaenn
13 8 3,#4b,#7,# 8,#9,#10,# 13
Failure%model %I0trrrscEaenno 3,#9%ilrFyaT+eeup 3,#9,%ilrFa+eu#10Itscaenn 3 rzaa+dH7,#8,#9%itscvEa+enB,#
13 3,#9 3,#9,#10 3 3,#4b,#7,# 8,#9,#10,# 13 13 13 t n e v E %i c s a B 0
Fault%tree % e liitrya#Pbbo 3,#9,#ta+eG 13 0taeG3,#9,iIttra+eendm#10tvEen,# 2,#3,#9%cgaehnoN,# 10 13 14 3,#9,# 13 3,#9,#10,# 2,#3,#9 10 13 7,#8 8 3,#7,#8 3,#8,#10 4,14 4b 8 8 3,#7,#10,# 13
We made a couple of general observations from the results of the case study
and building the aforementioned table (and its detailed version [
Hence, the main result of the case study is that there is no simple, straightforward co-evolution of system architecture and fault tree models that could be fully automated for all possible di erent co-evolution steps contained in the case study. Instead, user interaction is required for some of them, e.g., when to add a basic event to the fault tree for a new component as described above. 4
We presented the results of a case study in the co-evolution of system architecture
and fault trees based on the evolution scenarios presented in [
Threats to validity of our results are (1) the limits of our metamodel and instance models, (2) the models were built by ourselves, (3) the selected subset of scenarios and hazards, and (4) the result is based on only one case study.
Based on the identi ed evolution changes, we currently work on a toolsupported co-evolution approach that supports the developer if one model evolves to choose a consistent co-evolution of the other model.
Acknowledgements: This work was partially supported by the DFG (German Research Foundation) under the Priority Programme SPP1593: Design For Future - Managed Software Evolution.