Hazard-driven realization views for Component Fault Trees

Model-driven engineering is typically associated with automatic generation or transformation of higher-level models into low-level artifacts (e.g., source code generation) [7]. In the context of this work, we focus primarily on the modeling aspect and less on the generation or transformation aspect. Therefore, we will concentrate on the idea that models conform to meta-models, from which modeling languages can be defined [8].

In the world of model-based design, the Unified Modeling Language (UML) is one of the best-known and most commonly used languages within the field of software engineering. Due to its great versatility, UML is considered a General Purpose Language (GPL) that can be used in different fields. However, due to its high level of abstraction, it is not usually practical in real-world engineering projects. For this reason, Domain Specific Languages (DSLs) are used quite often [9]. A DSL is a modeling language tailored to a particular subject area or a certain group of stakeholders. The idea behind a DSL is to create models that help to raise the performance of the stakeholder’s tasks. As part of GPLs and DSLs, different viewpoints are often defined to emphasize the modeling of one aspect or another. In the IEEE1471/ISO 42010 standard [10, 11], a distinction is made between the terms View and Viewpoint; see Fig. 1. Viewpoints relate to the languages (i.e., models, notations, product types) used to define views. Viewpoints are generally defined with the concerns of a specific stakeholder in mind. Viewpoints restrict, in a certain manner, the information displayed through a view, which can be seen as a projection of the system under development.

UML, for example, uses different diagram types to focus on one aspect or another of the system. For instance, class diagrams are used to depict logical structures and component diagrams focus on the composition and sequence diagrams on the behavior. Generally, systems are too complex to show everything in one diagram (i.e., the view). For this reason, it is common to see a functional or logical structuring of the views, leading to a large collection of partial views that, taken together, sum up the system definition.

Fault Tree Analysis (FTA) is a technique recommended for use in the development of safety-critical systems [12, 13] to identify faults within a system [1]. To use this technique, the first step is to define a top event (black triangle in Fig. 2), which represents an undesired event (typically a hazard). The system is then analyzed and the combinations of faults (i.e., basic events, blue circles in Fig. 2) that might lead to that event are linked through Boolean logic. Usually, only OR and AND gates are used, but negative logic can also be used by means of NOT or XOR gates. Figure 2 shows the FTA of a simplified airbag system.

Generally, two problems are associated with airbag systems: failure to deploy and unwanted deployment. The former is generally considered less critical because only that part of the injury that could have been prevented by proper deployment, presumably a severe injury, is compensable. The latter case, i.e., undesired activation, is investigated in Fig. 2. This is a dangerous situation because the force generated during deployment can cause an accident, serious injury, or even death (if children are affected).

Component Fault Trees (CFTs) [2] represent the evolution of FTA with respect to the handling of complexity in large systems. By applying component-based principles [14, 15], CFTs integrate modularization and instantiation concepts into the modeling of fault trees. Figure 3 presents the added modeling constructs.

CFTs encapsulate the failure behavior of a component. They depict incoming failures as Input Failure Modes and outgoing failures as Output Failure Modes. This defines the interface of the CFT, which can be exposed by means of CFT Instances when integrated into the CFT of a larger system. Figure 4 presents the CFT of the airbag system.

At the top, Fig. 4a presents the logical network of the system. Figure 4b depicts the CFT of the system integrating the CFTs of the components through CFT instances and depicts the failure propagation through the connectors. This way of documenting the system faults makes it easier to understand the source of consequences (compared to FTA) and facilitates the planning of where to integrate safety measures in order to prevent or correct the identified issues. Figure 4c presents the CFTs of the components, depicting their specific failure behavior. The dotted lines establish the relationship between failure modes and logical interfaces.

One of the main goals of CFTs [3] is to bring designers and safety engineers closer, given their natural dependency. The goal of a safety engineer is to guarantee that faults identified through fault trees are removed or mitigated. In this sense, FTA influences the design, since the identified faults lead to the definition of safety requirements for which new functions/components will be integrated into the architecture. In order to enhance the interaction between these stakeholders, CFTs propose the use of a component-centric modularization approach where the composition of functions or components (e.g., Logical/Hardware), as provided by the system’s architecture design, is used to structure the Fault Tree Analysis. Therefore, the techniques explicitly associate CFT modules with architecture modules as well as their interfaces, see Fig. 4. Each interface from the architecture is analyzed and failures modes are identified and linked.

One further advantage of CFTs with respect to FTA is that the construction effort can be distributed over several modelers. In this sense, it would be possible to carry out the analysis almost in parallel, since one person will only deal with a certain part of the system at a time. CFTs are also better than FTA in terms of the maintainability of the model. Typically, changes performed in the design models need to be considered in the Fault Tree Analysis. However, it is also usual that these changes occur locally to one or the other components at a time. CFTs facilitate the maintenance in that only for those components which have been modified the associated CFT needs to be reevaluated.

The meta-model for our modeling approach is depicted in Fig. 10. This figure presents the concept-relevant part of the CFT Domain Specific Language as an extension of UML constructs.

Figure 11a shows the representation of the “CFT Realization View” entity, while Fig. 11b shows the model composition for the vehicle system CFT, as presented in Fig. 9. Realization views are highlighted through the red boundary.

CFTs supports the composition of other sub-CFTs similar to “Components” in UML [16]. This is necessary because CFTs are defined for components of logical networks, as shown in Chapter 2. At the modeling level, composition is supported with the help of “CFT Instances” and “CFT Realization Views.”

As with Component-Based Design, CFTs encapsulate their realization in an internal view (white-box view) and expose their interfaces through an external view (black-box view). In our modeling approach, these views are supported such that a CFT has at least one such internal view, (i.e., a default CFT Realization View) and exposes the external view through “CFT Instances” when instantiated in a realization view of another CFT. This is already partially presented in Fig. 9. Figure 12 now depicts the realization views of the “Sensors” entity to clarify the concept.

As can be seen in Figs. 9, 11, and 12, the CFT of the “Sensors” has been instantiated twice, once in each of the realization views of the CFT of the “Vehicle.” It should be noted that each of these instances shows a different interface specification although both have the same type, namely the Sensors CFT. In this way, a “CFT Instance” behaves similarly as a UML Property [16], with the difference that it shall only expose the black-box view corresponding to the assigned preferred realization view; see the “preferred RV” attribute in Fig. 10.

We have added the “CFT Realization Views” as a modeling object to facilitate the understanding of the concept and because in practice, these entities should exist as part of the data model. These views are supported in our approach with diagrams (see UML diagram element in Fig. 10), although they could be supported by other presentation means. The use of model elements is required because they need to be referenceable model artifacts, as already shown by the “preferred RV” attribute. Moreover, these artifacts will be associated with other important artifacts of the safety life cycle (e.g., the safety case) due to traceability requirements.

The proposed modeling approach provides more modeling and expressiveness power than pure CFTs. However, a modeler might be confused as to how to use the approach effectively. For this reason, we propose as part of the solution the definition of the realization views from the point of view of the safety engineer, taking as a basis the hazards/undesired events being analyzed.

As pointed out in Chapter 3, fault analysis with CFTs is typically performed for the entire system, starting from the actuators and then following the data flow backward. Therefore, the modeling process should start by defining a realization view (i.e., diagram) of the CFT associated with the topmost component type, which shall be related to one undesired event at a time. More undesired events might be integrated if there is high reuse potential for existing modeling artifacts and if the complexity of the diagram remains low, i.e., following the traditional modeling approach for CFTs. However, we recommend creating one realization view per undesired event to facilitate the review process, since this will be performed systematically, one hazard at a time.

While moving backward in the data flow, the user will encounter architecture entities to be analyzed. For these, a dedicated CFT realization view in the context of the current top event should also be defined unless it is possible to reuse an existing one or parts of it (e.g., existing failure modes, basic events, and failure logic).

By following this procedure for the complete functional chain up to the sensors or inputs of the system, the modeler will complete the CFT realization view of the topmost component, in which all CFT instances have a dedicated realization view exclusively for the current context under analysis.

It should be noted that this approach primarily targets a top-down development process, because in order to depict the failure behavior of the subsystems and components, good knowledge about their implementation is required. In this work, we do not investigate how distributed development could be supported, i.e., how existing models from suppliers could be integrated at the Original Equipment Manufacturers (OEM) level.

In summary, this methodology reflects the focus we have placed on the safety engineer’s tasks, since the goal is to emphasize the modeling in one single undesired event at a time. This approach is intended to keep the model simple and understandable, thereby facilitating the review process.

Thanks to the integration of realization views into the modeling approach, the Fault Tree Analysis can be divided into manageable pieces to handle the complexity of the system. However, this has a negative impact on the maintenance effort, given the fact that more views have to be considered. Because of this and in order to facilitate the modeling process, we have conceived several automation features, which we have implemented as part of the safeTbox modeling tool [17].¹ The following aspects have been considered:

Special attention has been given to the consistency (with respect to the functional/logical interfaces) between component and CFT realization views. As noted in Chapter 2, CFTs are defined for each of the components of the architecture. In addition, as shown in Figs. 4 and 12, the components and their interfaces are shown as part of the realization views of the CFTs. This is done as proposed in [4]. In safety engineering, it is very important to demonstrate that the analysis is consistent and complete. This is typically achieved when all entities in the architecture are considered during the fault analysis or when a convincing argument is provided why this is not the case. Looking back at our solution, one can see that the modeling approach is quite simple, since it is built on the basis of entities (functions/components) and their interfaces. For the first type of constructs, one would typically expect to see in a CFT realization view a CFT instance for each component instance as defined in the component realization view. However, we deliberately decided not to implement any mechanism enforcing composition consistency (e.g., for component instances). The reason for this decision was that during the analysis, entire entities are quite frequently left out, since they might not play any role in the system-level function under analysis. For the interfaces, we did, however, implement a synchronization mechanism that, based on the association between the component and CFT, guarantees that the interfaces remain consistent. This mechanism supports the user by showing the impact of changes, e.g., when showing/hiding interfaces. This functionality is required because the user might not be aware of which CFTs will be affected by performing changes on the architecture. Moreover, this is intended to help guarantee the completeness argument, since all inputs and outputs of a component have been considered. Figure 13 shows a dialog supporting the impact of changes when showing or hiding interfaces.

Besides modeling support for realization views, safeTbox also offers the possibility for CFTs to perform qualitative (e.g., Minimal Cut Sets) and quantitative analysis (Unavailability, Cut Sets Importance, Common Cause Failures). It also supports the definition of type systems for ports and failure modes, as proposed in [20]. CFTs in safeTbox make part of the model-based safety engineering approach integrating modeling support for a hazard and risk assessment and support for the construction of modular safety concepts and safety cases.

In order to show the application of the approach, the “direction lights” functionality is selected. Direction lights serve to announce to other road users the intention of changing the direction of travel. In total (and to ensure visibility from all relevant perspectives), three flashing lights are installed on each side of the vehicle: one in the front, one in the back, and one on the side. The driver can announce the direction of travel by making use of the direction signal lever on the left side of the steering wheel (raised position→ turn right, lowered position→ turn left, middle position→ off). As long as the switch remains in the selected position, the lights of the selected side will flash periodically. At the same time, the driver is informed of the direction lights’ activation state through acoustic and visual feedback (control lamps). Figure 14 shows a high-level architecture of the direction lights functionality.

To keep the model simple, only the front (left and right) direction lights have been modeled. Moreover, stereotypes have been omitted. Starting from the left:

The behavior of the function “Provide Direction Lights State Feedback” is specified as follows:

Plausibility check passed when:

Plausibility check fails when:

Plausibility check fails when:

As mentioned earlier, the starting point for performing fault analysis with fault trees is to identify the undesired events. In order to do that, a Hazard and Risk Analysis (HARA) is typically performed. However, this will not be shown here, as it is not relevant for the current approach. The resulting hazards identified from the HARA are:

For the sake of simplicity, in this document we will only show the application of the methodology in the first two cases. Figure 15 shows the realization view in which the inverted scenario has been modeled for the CFT of the Direction Light System.

As explained in Chapter 3, we analyze the data flow in the system backward. In this case, as can be seen in the model, the direction lights, the indicators lamps, and the sound generator have not been included for the sake of simplicity. While turn lights and indicators might be turned on as the result of a fault, e.g., due to a short circuit to the battery, it is highly unlikely that they will work intermittently, reflecting an actual activation from LCM. The sound generator has also been excluded since it is activated consistently with the indicator lamps. For this reason, the analysis starts at the LCM boundaries.

Without having the intention to deepen the fault tree modeling aspects, this model reflects the situation in which the driver has selected the direction with the lever (e.g., left), but due to errors in the system, the opposite direction (i.e., right) is activated, while visual feedback continues to be received that is consistent with the lever position (i.e., left). This situation is safety-critical, as the driver has no chance to identify the inverted activation, and other drivers will most likely interpret his intentions wrongly, which may lead to an accident.

Figure 16 shows the realization view in which the omission scenario has been modeled for the CFT of the Direction Lights System. In this scenario, the driver would have selected one side with the lever (e.g., left), but the system would have failed to activate the corresponding direction lamp. At the same time, it would have wrongly activated the indicator lamp (i.e., left side). This situation is again safety-critical for similar reasons as explained in the inverted scenario. In particular, in this model the turn signals should be included, since the failure of the lamp can be considered as a root cause and a system behavior has been defined in relation to it.

When comparing the two models, it is easy to find that:

During the creation of the second and further realization views, one would expect the modeler to manually add all modeling entities. In order to save some time in such situations, we have implemented the cloning of realization views as pointed out in Chapter 4—The Tooling Aspect. For the presented modeling scenario, the deep cloning mechanism is of particular interest. This mechanism creates a new realization view on the basis of a selected one. It creates new modeling entities, whose layout is exactly as in the source realization view. During this process, thanks to the “preferred RV” attribute, the newly created CFT instances point to the same realization views as before. As can be expected, the algorithm does not work recursively along the composition. The reason for this is to avoid making the cloning process too complex for the modeler.

From the method point of view, the modeler has three options for creating the second or further realization views:

In any of these cases, the modeler is still confronted with the question of whether to keep the CFT instances as they are or associate them with a new realization view. The former is a better option if the failure modes have been modeled in a relatively abstract way and can be reused in different contexts. The second option should be preferred if the desired level of detail of the analysis is much lower, as was the case in the provided example. If the second option is preferred, then it makes sense that the realization view to be associated should already be modeled.

Figure 18 shows the merged realization view for the Direction Lights System, as it would be obtained by following the typical CFT analysis. As can be seen, even with two top events it is already difficult to identify which functions or failure modes are relevant for which top event. In order to get that information, it is necessary to navigate the realization view of the modeled CFT instances. This, however, has the negative effect that the context is lost, and the modeler is required to keep the information in mind while switching continuously between the realization views in order to get the right picture in their mind. The model becomes harder to understand the more top events are considered, similarly as shown in Fig. 6.

Figure 19 presents the merged realization view of the “Provide Direction Lights State Feedback” function. In comparison with the separated realization views, one can see that the model has become less understandable, even though great effort was invested in avoiding connector crossings. Although the logic itself is not complex, the model appears to be so due to the large number of connectors. In this case, the engineer not only needs to take care of modeling the failure behavior properly, which clearly becomes more difficult and error-prone, but also has to ensure the proper layout of the modeling elements in order to be able to communicate the model to the reviewer later on.