Fail-safe testing of safety-critical systems: a case study and efficiency analysis

Abstract

This paper proposes an approach for testing of safety-critical systems. It is based on a behavioral and a fault model. The two models are analyzed for compatibility, and necessary changes are identified to make them compatible. Then, transformation rules are used to transform the fault model into the same model type as the behavioral model. Integration rules define how to combine them. This approach results in an integrated model which then can be used to generate tests using a variety of testing criteria. The paper illustrates this general framework using a CEFSM for the behavioral model and a fault tree for the fault model. We apply the technique to an aerospace launch system. We also investigate the scalability of the approach and compare its efficiency with integrating a state chart and a fault tree.

Appendix

1.1 INHIBIT gate

INHIBIT is similar to the AND gate. They have the same states and transitions. The only difference is that the predicate for the transitions $\hbox {T}_{2}$ and $\hbox {T}_{3}$ should include the enabling condition. We do not need to have a separate gate representation for NOT gate since we can express it in any predicate. If we want to negate any event, we can use the NOT logical operator inside the gate that the negated event is one of its inputs.

Fig. 40

XOR gate representation in FT and GCEFSM

1.2 XOR gate

This gate is slightly different from the AND gate, although it has the same structure and same number of transitions and states. At this gate, it is necessary to distinguish between the event that has not occurred in the first place and the one whose status is false. The representation of GCEFSM XOR gate is shown in Fig. 40. T$_{0}$ to T$_{3}$ are the possible transitions that may be taken based on their predicates.

• $T_{0}:(S_{0},[NoOfOccurredEvents=0 \& e_{j}.eOccurrence=true],get(m_{j}))/(S_{0},\, update(events))$

• $T_{1}:(S_{0},[NoOfOccurredEvents=1 \& e_{j}.eOccurrence=true \& xor(events)=false],get(m_{j}))/(S_{0},update(events),-)$

• $T_{2}:(S_{0},[NoOfOccurredEvents=1 \& e_{j}.eOccurrence=true \& xor(events)=true],get(m_{j}))/(S_{1},update(events),Send(gateOccurred))$

• $T_{3}:(S_{1},[inputStatusChanged(e_{j})=true],get(m_{j}))/(S_{0},update(events), Send(gate not occurred))$

1.3 Timing an event gate

FT gates such as AND, OR, and INHIBIT are well defined and can be syntactically represented. Events in FT can be simple or composed. A composed event can be decomposed further to simple events or a timed simple event. A timed simple event is the simple event that should occur for a specific period of time to contribute to a hazard. However, FT has no timing gates. Therefore, we need to have a representation that can handle the timing issue (either a minimum or maximum timing). A CEFSM can be supplemented with timers and timer-related operations. A timer is set with a time value during a transition. If the timer is not canceled by the CEFSM, the timer will generate a time expiration signal after the time period has been exceeded (Byun et al. 2001, 2002; Byun 2003; Byun and Sanders 2005, 2006). Thus, we introduce this gate that can time an event and the gate in the subsection 7 that deals with the timing intervals. This gate works as follows. Upon receiving a message that indicates the occurrence of the event, the transition $\hbox {T}_{0}$ takes place which starts the timer. When the time expires and no further “gate not occurred” message was received that indicates that the event is no longer happening, the transition $T_{2}$ is taken and sends a “gate occurred” message. Otherwise, the gate does not occur. $T_{2}$ is taken when the event status $e_{i}$.eStatus changes to false.

Fig. 41

Event timer GCEFSM

• $T_0:(S_0,[e_j.eStatus=true],get(m_{j}))/(S_{1},setTimer(v,Timer_{i}),-)$

• $T_{1}:(S_{1},time-out)/(S_{2},-,Send(GateOccurred))$

• $T_{2}:(S_{1},e_{j}.eStatus= false],get(m_{j}))/(S_{0},reset(Timer_{i});update(events))$

• $T_{3}:(S_{2},e_{i}.eStatus= false],get(m_{i}))/(S_{0},reset(Timer_{i});update(events),Send(GateNotOccurred))$

Fig. 42

Timing continuous intervals GCEFSM

1.3.1 Timing an event for continuous intervals gate

Some event may need to be timed for continuous intervals. For example, we may need to observe an occurrence of an event every consecutive 5 sec as long as the system is operational. Fig. 42 shows that as long as the transition $\hbox {T}_{0}$ is fired and $\hbox {T}_{2}$ was not, the event will be timed for fixed consecutive amounts of time and it keeps timing until the status of the event $e_{i}.eStatus$ changes to false. Upon receiving this event change, the transition $\hbox {T}_{3}$ to the state $S_{1}$ is fired sending out a “gate not occurred” message.

• $T_{0}:(S_{0},[e_j.eStatus=true],get(m_j))/(S_1,setTimer(v,Timer_i),Send(Gate Occurred))$

• $T_1:(S_1,time-out)/(S_2,-,Send(Gate not Occurred))$

• $T_2:(S_1,[e_j.eStatus=false],get(m_j))/(S_0,reset(Timer_i),Send(Gate Not Occurred))$

• $T_3:(S_2,setTimer(v,Timer_i))/(S_1,-,Send(Gate Occurred))$