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

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

Previously in Part 1 and Part 2 in this three partseries, Icreated asafety analysis metamodel, and then defined the set of stereotypes andtags to create a UML profile for safety analysis.

In this last part in this series, I will describe the system I havechosen to use to illustrate how to use this safety critical designanalysis technique: a surgical anesthesia ventilator. I will also gointo detail on how to use the UML FTA profile to delineate the problemareas in its configuration.

This system the delivers inhalant anesthetic drugs, mixes gases,delivers gas/drug mixture to the patient via ventilation, scavengesexhaled CO2 , and monitors both patient and machine status,includingblood O2 saturation (SpO2 ), inspiratory limb O2 concentration,expiratory limb CO2 concentration, inspiratory limb agent(drug)concentration, gas flow, and breathing circuit gas pressures.

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

Gas supplies – these may be wall supplies ortanks butsupply medically certified gases (O2 , N2 , N2 O,He, or Air)
Gas Mixer – formally a part of the ventilator, thisdevice mixes the input gases from the gas supplies as directed andoutputs a mixed gas to the breathing Circuit
– this device shapes the breath delivered to thepatient. It's primary parameters include the respiration rate(breaths/minute ), tidal volume(volume per breath ), I: E ratio(I nspiration time : E xpiration time ratio ), InspiratoryTime (seconds ),and an optional inspiratory pause (delaybetween breaths ).
Vaporizer –
this device vaporizes an anesthetic drug, such asSuprane, Halothane, or Enflourane, and delivers it to the breathingcircuit in the concentration demanded.

Figure1: Anesthesia Machine Schematic

The overall use case model for the SleepyTime AnesthesiaMachine isshown in Figure 2 below . Certain functionality, such as CO2 scavenging, while important, doesn't involve the software and so is notincluded in this model. ( This model is focused on the developmentof embedded software. If this was a system engineering model, then gasscavenging would most definitely be included.

Figure2: SleepyTime Anesthesia Machine Use Cases

Most of our discussion will focus on the patient ventilator ” adevice responsible for mixing incoming gases to appropriateconcentrations, and shaping and delivering breaths via the breathingcircuit inspiratory limb to the patient.

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

Additionally, a pause between breaths may be specified (InspiratoryPause ) as well as a rate of respiration (Respiration Rate ). In thecontext of this discussion, the ventilator is a subsystem of theanesthesia machine.

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

Figure3: Ventilator Use Cases

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

Figure4: Requirements for use case Set Ventilation Parameters

(To view an enlarged version of this figure ClickHere. )

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

Figure5: Requirements for use case Alarm on Critical Event

(To view an enlarged version of this figure ClickHere. )

Figure6: Requirements for use case Display Machine Status

(To view an enlarged version of this figure ClickHere. )

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

Let's consider a single hazard – Hypoxia. This is a very fundamentalhazard for a ventilator but although just one of many. (Others includehyperoxia (a problem that can lead to blindness is neonates), overpressure, inadequate anesthesia, over anesthesia, and leaking drugsinto the operating room environment. )

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

Figure7: FTA for hazard Hypoxia

Figure 7 above shows thebasic structure of the FTA for the Hypoxia hazard. The ResultingCondition O2 Concentration Problem occurs only if all of thefollowingfaults occur: the breathing circuit O2 sensor fault, the SpO2 sensorfault, and the O2 Supply fault. The last of these is theprimary faultwhile the other two are faults in what are known as safety measures “elements and behaviors added to the system specifically to addresssafety concerns.

In this case, we add both a breathing circuit sensor and an SpO2 finger cuff sensor to improve safety. The hazardous condition due to afault in the O2 gas supply can only occur if both the SpO2 andbreathing circuit O2 sensor have faults. This is what wemean byAND-ing redundancy. For the hazardous condition to occur both theoriginal fault AND the fault in the safety measure must occur.

Furthering this analysis, we see that for an O2 concentrationproblem to result in the Hypoxia hazard, other conditions must be true.Specifically, the ventilator must be in use and the attending physiciandoesn't take proper action ” either because he or she doesn't know theyshould (Failure to Alarm fault) or because for some reason they areunable to (Physician unable to manually ventilate).

Besides an O2 concentration problem, other faults couldalso resultin Hypoxia, subject to the same overall conditions discussed in theprevious paragraph. There could be a problem delivering the gas (GasFlow Problem) or the patient could be disconnected from the breathingcircuit (Connection Problem).

These latter concerns are somewhat involved and including them inthis diagram would make it difficult to read. For this reason, transferoperators connect them logically into their appropriate logicalposition within this diagram even though they are drawn on a separatediagram.

Figure8: FTA for Gas Flow Problem subdiagram

(To view an enlarged version of this figure ClickHere. )

Figure 8 above elaboratesthe FTA for the Resulting Condition “Gas Flow Problem”. Here again wesee that basic faults must be ANDed with the faults of safety measuresfor the hazard to be realized. This analysis leads to theidentification of new requirements for the safety measures ” such asgas flow sensors, CRCs on parameter settings, and redundant computationof ventilator control.

Figure9: FTA for Connection Problem subdiagram

Figure 9 above points outthe last concern for the Hypoxia hazard we will consider ” the problemof misconnection or disconnection of the patient from the breathingcircuit. A very common problem is improper intubation. (Intubation isthe insertion of the breathing circuit connection into the patienttrachea ).

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

The selected safety measure is to add a CO2 sensor on theexpiratorylimb. Since the only thing in the entire system that inserts CO2 intothe breathing circuit is the patient's lungs. (In Great Britain, it is common practicefor anesthesia machines to actually drive CO2 into thepatient lungswhen 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 CO2 concentration, then either the patient isn't producing CO2 (a very badsign) or the expiratory limb of the breathing circuit isn't connectedto the patient's lungs.

The identified faults can be characterized with the fault metadataby filling in the identified tag fields. Figure 10  below shows aportion of the generated fault table summarizing the faults.

Figure10: Fault Table

(To view an enlarged version of this table ClickHere.)

One of the results for the safety analysis is the discovery ofadditional requirements to enhance safety. We can tie the requirementsto the faults identified in the FTA. For example, Figure 11 below shows the FTA forthe Connection Problem linked to the relevant requirements with theTrace To Requirement relation. This is important because it binds thesafety analysis directly to the requirements. The result of thisprocess is captured in the generated Fault-Requirement Matrix, aportion of which is shown in Figure12 below .

Figure11: Faults linked to Requirements

(To view an enlarged view of this figure ClickHere. )

Figure12: Fault-Requirement Matrix

(To view an enlarged view of this figure ClickHere. )

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

Figure13: SleepyTime Subsystems

(To view an enlarged view of this figure ClickHere. )

Figure14: Ventilator Design Model

(To view an enlarged view of this figure ClickHere. )

Figure 14 above shows someelectronic components with the stereotype «electronics» andcolored in blue .The other elements are all software classes that collaborate togetherto realize the ventilator use cases.

During the design and development work, new hazards may be added “for example, the selection of bottled O2 might result in apressureexplosion hazard ” as well as questions as to whether or not the designappropriately addresses the safety concerns.

At this point, we can elaborate the FTA model with that informationand we can add specific links from the profile from the faults to theelements in the model that can manifest the faults or that detect orextenuate the faults.

The safety analysis profile also supports linking the analysis anddesign elements to the faults using the Manifests (to Fault Sources),Detects and Extenuates (to Safety Measures) relations. Figure 15 below and Figure 16 below show examples ofsuch elaborated FTA diagrams.

Figure 15: FTA with Design Element Links

(To view an enlarged view of this figure ClickHere. )

Figure 16: FTA with Design Elements

Not only is this information visually apparent. It is alsorepresented in the Fault Source Matrix, Fault Detection Matrix, andFault Extenuation Matrix. For example, Figure17 below shows a portion of the matrix of the faults and thedesign elements that can manifest them while Figure 18 below shows the sameview for the faults and the design elements that detect them.

Figure 17: Fault Source Matrix

(To view an enlarged view of this figure ClickHere. )

Figure 18: Fault Detection Matrix

(To view an enlarged view of this figure ClickHere. )

In addition, a complete hazard analysis can be generated from theannotated fault model. This is generated as an external Tab-SeparatedValue (.tsv) file. This file is placed automatically in the maindirectory of the model and may be added as a controlled file into themodel.

This file can be read by most spreadsheet programs, although you mayhave to customize the registry to open the appropriate application ifthe spreadsheet program doesn't do that for you automatically.

The hazard analysis consists of three sections. The first shows thehazards and the metadata from the safety model. The output from thismodel is shown in Table 1 below .

Table 1: Hazard Analysis Part 1 – Hazard Metadata

The second part of the hazard analysis summarizes the relationsbetween the faults and the hazards. This involves the tracing ofmultiple levels of logic flows connecting the faults with the hazards.The output for this model is shown in Table2 below .

Table 2: Hazard analysis Part 2 – Hazard Fault Matrix

(To download a PDF of the long version of this truncated version ofthe Hazard Fault Matrix, ClickHere. )

Lastly, the hazard analysis contains the relations between allfaults and the elements of the model, including requirements, andclasses that manifest, detect, or extenuate faults. This view iscrucial for a detailed understanding of the correctness and safety of adesign model. Table 3  below showsthe output for the example model.

Table 3: Hazard analysis Part 3 ” Model Element Relations

(To download a PDF of the long version of this truncated version ofthe Model Element Relations list, ClickHere. )

Fault Tree Analysis (FTA) iswell established as a useful method forunderstanding how normal events, conditions and faults combine tocreate hazardous conditions. The safety analysis profile discussed inthis paper adds the ability to create and report on FTA diagrams into aUML tool. This includes the specification of safety-related metadata,such as hazard severity, risk, probability and safety integrity level,as well as fault probability and MTBF .

The profile extends the FTA method by supplying relations from theanalysis to normal UML model elements ” specifically, requirements,source of faults, and elements that can detect or extenuate the faults.These extensions add value by making the relations between the safetyanalysis and the UML model elements explicit and traceable.

This profile supports the safety approach identified in theHarmony/ESW (Embedded Software) process [4,5] from IBM/Rational, developedby the author. Through the use of this profile, developers and safetyanalysts can use a common language and tool environment, improvingtheir collaboration and quality of work.

“Build safety-critical designs with UML-based fault tree analysis” is a 3-part series:
To read Part 1, go to “The basics”
To read Part 2, go to “Defining a a profile”
To read Part 3, go to “Anesthesia ventilator evaluation”

Bruce has worked as a software developer in real-time systems for over 25 years and is a well-known speaker, author, and consultant in the area of real-time embedded systems. He is on the Advisory Board of the Embedded Systems Conference where he has taught courses in software estimation and scheduling, project management, object-oriented analysis and design, communications protocols, finite state machines, design patterns, and safety-critical systems design. He develops and teaches courses and consults in real-time object-oriented analysis and design and project management and has done so for many years. He is the chief evangelist for Rational/IBM. Bruce worked with various UML partners on the specification of the UM, both versions 1 and 2. He is a former co-chairs of the Object Management Group's Real-Time Analysis and Design Working Group. He is the author of several other books on software, including Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks and Patterns (Addison-Wesley, 1999), Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems (Addison-Wesley, 2002), Real-Time UML 3rd Edition: Advances in the UML for Real-Time Systems (Addison-Wesley, 2004), Real-Time UML Workshop for Embedded Systems (Elsevier Press, 2006) and several others, including a short textbook on table tennis. His latest book on employing agile methods to develop real-time and embedded systems, Real-Time Agiliy, will appear in June, 2009.

[1] Leveson, Nancy. Safeware:System Safety and Computers Reading, MA: Addison-Wesley, 1995

[2] Guidance for FDAReviewers and Industry: Guidance for the Content of PremarketSubmissions for Software Contained in Medical Devices Washington, D.C.;FDA, 1998

[3] IEC 65A/1508: FunctionalSafety: Safety-Related Systems Parts 1-7 IEC 1995

[4] Douglass, Bruce Powel.Doing Hard Time: Developing Real-Time Systems with UML, Objects,Frameworks and Patterns Reading, MA: Addison-Wesley, 1999

[5] Douglass, Bruce Powel.Real-Time Agility Reading, MA: Addison-Wesley, 2009.

[6] Douglass, Bruce Powel.Real-Time Design Patterns: Robust Scalable Architecture for Real-TimeSystems Addison-Wesley, 2002

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.