Build Safety-Critical Designs with UML-based Fault Tree Analysis: Anesthesia ventilator evaluation

Bruce Powel Douglass, IBM/Rational

April 29, 2009

Bruce Powel Douglass, IBM/Rational

Let's consider a single hazard - Hypoxia. This is a very fundamental hazard for a ventilator but although just one of many. (Others include hyperoxia (a problem that can lead to blindness is neonates), over pressure, inadequate anesthesia, over anesthesia, and leaking drugs into the operating room environment.)

If we now create a new FTA diagram it would look like the drawing in Figure 7 below.

Figure 7: FTA for hazard Hypoxia

Figure 7 above shows the basic structure of the FTA for the Hypoxia hazard. The Resulting Condition O₂ Concentration Problem occurs only if all of the following faults occur: the breathing circuit O₂ sensor fault, the SpO₂ sensor fault, and the O₂ Supply fault. The last of these is the primary fault while the other two are faults in what are known as safety measures " elements and behaviors added to the system specifically to address safety concerns.

In this case, we add both a breathing circuit sensor and an SpO₂ finger cuff sensor to improve safety. The hazardous condition due to a fault in the O₂ gas supply can only occur if both the SpO₂ and breathing circuit O₂ sensor have faults. This is what we mean by AND-ing redundancy. For the hazardous condition to occur both the original fault AND the fault in the safety measure must occur.

Furthering this analysis, we see that for an O₂ concentration problem to result in the Hypoxia hazard, other conditions must be true. Specifically, the ventilator must be in use and the attending physician doesn't take proper action " either because he or she doesn't know they should (Failure to Alarm fault) or because for some reason they are unable to (Physician unable to manually ventilate).

Besides an O₂ concentration problem, other faults could also result in Hypoxia, subject to the same overall conditions discussed in the previous paragraph. There could be a problem delivering the gas (Gas Flow Problem) or the patient could be disconnected from the breathing circuit (Connection Problem).

These latter concerns are somewhat involved and including them in this diagram would make it difficult to read. For this reason, transfer operators connect them logically into their appropriate logical position within this diagram even though they are drawn on a separate diagram.

Figure 8: FTA for Gas Flow Problem subdiagram

(To view an enlarged version of this figure Click Here.)

Figure 8 above elaborates the FTA for the Resulting Condition "Gas Flow Problem". Here again we see that basic faults must be ANDed with the faults of safety measures for the hazard to be realized. This analysis leads to the identification of new requirements for the safety measures " such as gas flow sensors, CRCs on parameter settings, and redundant computation of ventilator control.

Figure 9: FTA for Connection Problem subdiagram

Figure 9 above points out the last concern for the Hypoxia hazard we will consider " the problem of misconnection or disconnection of the patient from the breathing circuit. A very common problem is improper intubation. (Intubation is the insertion of the breathing circuit connection into the patient trachea).

The most common physician fault is intubation of the esophagus. Esophageal intubation cannot be detected with gas flow sensors, pressure sensors, or even O₂ sensors.

The selected safety measure is to add a CO₂ sensor on the expiratory limb. Since the only thing in the entire system that inserts CO₂ into the breathing circuit is the patient's lungs. (In Great Britain, it is common practice for anesthesia machines to actually drive CO₂ into the patient lungs when trying to wake them after the completion of a surgical procedure, so this is not strictly true in the UK.)

So if the expiratory limb doesn't see an increased CO₂ concentration, then either the patient isn't producing CO₂ (a very bad sign) or the expiratory limb of the breathing circuit isn't connected to the patient's lungs.

The identified faults can be characterized with the fault metadata by filling in the identified tag fields. Figure 10  below shows a portion of the generated fault table summarizing the faults.

Figure 10: Fault Table

(To view an enlarged version of this table Click Here.)

One of the results for the safety analysis is the discovery of additional requirements to enhance safety. We can tie the requirements to the faults identified in the FTA. For example, Figure 11 below shows the FTA for the Connection Problem linked to the relevant requirements with the Trace To Requirement relation. This is important because it binds the safety analysis directly to the requirements. The result of this process is captured in the generated Fault-Requirement Matrix, a portion of which is shown in Figure 12 below.

Figure 11: Faults linked to Requirements

(To view an enlarged view of this figure Click Here.)

Figure 12: Fault-Requirement Matrix

(To view an enlarged view of this figure Click Here.)

During subsequent analysis and design, the UML model of the design elaborates. Figure 13  below shows a model system emphasizing the vaporizer and their relations with other elements while Figure 14 below shows the primary classes within the Ventilator subsystem.

Figure 13: SleepyTime Subsystems

(To view an enlarged view of this figure Click Here.)

Figure 14: Ventilator Design Model

(To view an enlarged view of this figure Click Here.)

Figure 14 above shows some electronic components with the stereotype «electronics» and colored in blue. The other elements are all software classes that collaborate together to realize the ventilator use cases.