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

Previously in Part 1 and Part 2 in this three part series, I created a safety analysis metamodel, and then defined the set of stereotypes and tags to create a UML profile for safety analysis.

In this last part in this series, I will describe the system I have chosen to use to illustrate how to use this safety critical design analysis technique: a surgical anesthesia ventilator. I will also go into detail on how to use the UML FTA profile to delineate the problem areas in its configuration.

This system the delivers inhalant anesthetic drugs, mixes gases, delivers gas/drug mixture to the patient via ventilation, scavenges exhaled CO₂, and monitors both patient and machine status, including blood O₂ saturation (SpO₂), inspiratory limb O₂ concentration, expiratory limb CO₂ concentration, inspiratory limb agent (drug) concentration, gas flow, and breathing circuit gas pressures.

Figure 1 below shows a schematic for the SleepyTime anesthesia machine breathing circuit and important sensors. (If you are interested in learning more about anesthesia machine operation, go and read an interesting animated tutorial/simulation of the Drager Fabius GS Anesthesia Workstation.) The primary elements are:

Gas supplies - these may be wall supplies or tanks but supply medically certified gases (O₂, N₂, N₂O, He, or Air)
Gas Mixer - formally a part of the ventilator, this device mixes the input gases from the gas supplies as directed and outputs a mixed gas to the breathing Circuit
Ventilator - this device shapes the breath delivered to the patient. It's primary parameters include the respiration rate (breaths/minute), tidal volume (volume per breath), I:E ratio (Inspiration time:Expiration time ratio), Inspiratory Time (seconds), and an optional inspiratory pause (delay between breaths).
Vaporizer - this device vaporizes an anesthetic drug, such as Suprane, Halothane, or Enflourane, and delivers it to the breathing circuit in the concentration demanded.

Figure 1: Anesthesia Machine Schematic

The overall use case model for the SleepyTime Anesthesia Machine is shown in Figure 2 below. Certain functionality, such as CO₂ scavenging, while important, doesn't involve the software and so is not included in this model. ( This model is focused on the development of embedded software. If this was a system engineering model, then gas scavenging would most definitely be included.

Figure 2: SleepyTime Anesthesia Machine Use Cases

Most of our discussion will focus on the patient ventilator " a device responsible for mixing incoming gases to appropriate concentrations, and shaping and delivering breaths via the breathing circuit inspiratory limb to the patient.

The delivery of ventilation involves the timing of the inspiratory time and expiratory time, delivering a specified volume per breath (known as Tidal Volume), with either a specified Inspiration-to-expiration time ratio (known as I:E Ratio), or, alternatively, a specified time for inspiration (Inspiration Time).

Additionally, a pause between breaths may be specified (Inspiratory Pause) as well as a rate of respiration (Respiration Rate). In the context of this discussion, the ventilator is a subsystem of the anesthesia machine.

Figure 3 below shows the use cases for the ventilator subsystem. The use of the stereotype «InternalActor» indicates that the element used as an actor in this context is actually part of the system but within another scope (e.g. another subsystem).

Figure 3: Ventilator Use Cases

Of course, there are a large number of requirements bound to each of the use cases. These requirements are typically managed with requirements traceability tools such as DOORS, and can then be imported to the model and attached to the use cases and design elements for traceability.

Figure 4: Requirements for use case Set Ventilation Parameters

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

For example, you can see in Figure 4 above the requirements having to do with setting the different ventilator parameters. Figure 5 and Figure 6 below show similar requirements for two other use cases.

Figure 5: Requirements for use case Alarm on Critical Event

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

Figure 6: Requirements for use case Display Machine Status

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

Once we have an understanding of the requirements, we can begin the process of analyzing the system for safety. One of the expected results of such an analysis is the identification of additional requirements needed to ensure the safe operation of the system.