fault tree analysis of uml designs - object management group

Fault Tree Analysis of UML DesignsFault Tree Analysis of UML DesignsDr. Christopher HarperDr. Christopher Harper Director, Avian Technologies Ltd.Director, Avian Technologies Ltd.

www.avianwww.avian--technologies.co.uktechnologies.co.ukcjharper@[email protected]

Alan ParkinsonAlan Parkinson Director, AGP Micro Ltd.Director, AGP Micro [email protected]@agpmicro.co.uk

http://www.avian-technologies.co.uk/

mailto:[email protected]

http://www.agpmicro.co.uk/

mailto:[email protected]

ContentsContents

•• The Engineering ProblemThe Engineering Problem•• Failure Analysis using Fault TreesFailure Analysis using Fault Trees•• UML SemanticsUML Semantics•• Fault Tree Analysis of UMLFault Tree Analysis of UML•• ModelModel--driven Safety Validationdriven Safety Validation•• Current workCurrent work

The Critical Systems Engineering ProblemThe Critical Systems Engineering Problem

•• Critical systems require dependability assuranceCritical systems require dependability assurance

•• Dependability assurance requires a lot of extra work (analysis, Dependability assurance requires a lot of extra work (analysis, review, testing)review, testing)

•• The extra work can introduce late design changes into the systemThe extra work can introduce late design changes into the system

•• Late design changes are extremely expensive!Late design changes are extremely expensive!

Software Design (UML)

Software Design (UML)

ImplementationImplementation

Software VerificationSoftware

Verification

Software ArchitectureSoftware Architecture

Software ValidationSoftware ValidationSoftware RequirementsSoftware RequirementsDesign Validation Test SpecDesign Validation Test Spec

Design Verification Test SpecDesign Verification Test Spec

System RequirementsSystem Requirements

Software DesignSoftware Design

Verified SoftwareVerified Software

Validated SoftwareValidated Software

Source CodeSource Code

Software Hazard Analysis• HAZOP/FFASoftware Hazard Analysis• HAZOP/FFA

Software Safety Analysis• FTA, FMEASoftware Safety Analysis• FTA, FMEA

Implementation Safety Assessment• Design reviewImplementation Safety Assessment• Design review

Safety Validation• Safety-directed acceptance testingSafety Validation• Safety-directed acceptance testing

Safety Case PreparationSafety Case Preparation

SW Safety RequirementsSW Safety Requirements

Safety Validation Test SpecificationSafety Validation Test Specification

Safety Verification Test Spec

Safety Verification Test Spec

Safety StandardsSafety Standards

Software ArchitectureSoftware Architecture

Derived RequirementsDerived Requirements

Software DesignSoftware Design

Code ChangesCode Changes

Source CodeSource Code

Safety Verification• Safety-directed unit / component testingSafety Verification• Safety-directed unit / component testing

Derived RequirementsDerived Requirements

Train Brake Control System: Context Use Case DiagramTrain Brake Control System: Context Use Case Diagram

Driver ServiceDriver ServiceBrake HandleBrake Handle

EmergencyEmergencyBrake ButtonBrake Button

BrakesBrakes

Train Brake Control SystemTrain Brake Control System

Door Control RelayDoor Control RelayLow Pressure SensorLow Pressure Sensor

TachoTacho SensorsSensors

Brake Cylinder PressureBrake Cylinder PressureServiceBrakingServiceServiceBrakingBraking

EmergencyBraking

EmergencyEmergencyBrakingBraking

BrakeManagement

BrakeBrakeManagementManagement

<<extend>><<extend>>

<<include>><<include>>

Wheel SlideProtection

Wheel SlideWheel SlideProtectionProtection

<<include>><<include>>

Door ControlDoor ControlDoor Control

Fire Alarm SignalFire Alarm Signal

Door Control: Class DesignDoor Control: Class DesignClass ModelClass Model

Tacho InterfaceTacho Interface

Door ControlDoor Control

<<uses>><<uses>>

WheelTachoWheelTacho

+ Speed + Speed getAxleSpeedgetAxleSpeed()()

DoorControllerDoorController

+ void + void ControlDoorsControlDoors()()

+trip+trip

FireAlarmSignalFireAlarmSignal

+ + boolbool IsFireAlarmActiveIsFireAlarmActive()()

--AlarmTypeAlarmType FireAlarmStateFireAlarmState

<<enumeration>>AlarmType

ActiveInactive

Type definition: Speed: real[0..500]

11

11

Train Brake System: Interaction DiagramTrain Brake System: Interaction Diagram

Door Control RelayDoor Control Relay

WheelTachoWheelTachoWheelTacho FireAlarmSignalFireAlarmSignalFireAlarmSignalDoorControllerDoorControllerDoorController

altaltalt

ControlDoorsControlDoors()()

getAxleSpeedgetAxleSpeed()()

Speed Speed AxleSpeedAxleSpeed

IsFireAlarmActiveIsFireAlarmActive()()

boolbool AlarmActiveAlarmActive

[[AlarmActiveAlarmActive = true & = true & AxleSpeedAxleSpeed < 5]< 5]

[else][else]

OpenDoorsOpenDoors

LockDoorsLockDoors

Example Fault TreeExample Fault TreeDoors openwhile train is

moving (>= 5kph)

Doors openwhile train is

moving (>= 5kph)

LockDoors signalnot sent when

intended


intended

Not developed in this exampleNot developed in this example

AxleSpeed < 5when not intended


AlarmActive = truewhen not intendedAlarmActive = truewhen not intended

IsFireAlarmActive()returns incorrect value

of FireAlarmState


of FireAlarmState

FireAlarmStateattribute set Activewhen not intended


IsFireAlarmActive()called when not intended

IsFireAlarmActive()called when not intended

OpenDoors signalsent when

not intended


not intended

getAxleSpeed()returns incorrect

value of AxleSpeed


value of AxleSpeed

Tacho sensor inputreads < 5kph

when not intended


when not intended

getAxleSpeed()called whennot intended


Wheel slip causeslow speed

measurement


measurement

Tachosensorfault

Tachosensorfault

Fire sensor hardware faultsFire sensor hardware faults

ControlDoors()called whennot intended


ControlDoors()calls getAxleSpeed()when not intended


ControlDoors() calls IsFireAlarmAcvtive()when not intended

ControlDoors() calls IsFireAlarmAcvtive()when not intended

Internal errors within Internal errors within operation algorithm

Internal errors Internal errors within operation within operation

algorithmControlDoors()

called whennot intended


operation algorithmalgorithm

Natural part of algorithm !!Natural part of algorithm !! Commission error of Commission error of ControlDoorsControlDoors()()

Natural part of algorithm !!Natural part of algorithm !! Commission error of Commission error of ControlDoorsControlDoors()()

UML 2.0+ Semantics (1)UML 2.0+ Semantics (1)•• UML semantic model has two parts, the semantics architecture andUML semantic model has two parts, the semantics architecture and the causality model [the causality model [SelicSelic] ]

Semantics Architecture:Semantics Architecture:

ActivitiesActivities State MachinesState Machines InteractionsInteractions

Behavioural BaseBehavioural Base

Inter-object Behaviour Base• Defines how structural entities communicate

• Sync/async calls, operations/receptions, events, triggers

InterInter--object Behaviour Baseobject Behaviour Base•• Defines how structural entities communicateDefines how structural entities communicate

•• Sync/Sync/asyncasync calls, operations/receptions, events, triggerscalls, operations/receptions, events, triggers

Intra-object Behaviour Base• Defines how structural entities behave internally

• Activities, structured activities, nodes, edges, flows

IntraIntra--object Behaviour Baseobject Behaviour Base•• Defines how structural entities behave internallyDefines how structural entities behave internally

•• Activities, structured activities, nodes, edges, flowsActivities, structured activities, nodes, edges, flows

Actions• Defines semantics of individual actions

• Communication, Read/Write, Computation, Structural Actions

ActionsActions•• Defines semantics of individual actionsDefines semantics of individual actions

•• Communication, Read/Write, Computation, Structural ActionsCommunication, Read/Write, Computation, Structural Actions-- behavioursbehaviours-- behavioural classifiersbehavioural classifiers

Structural FoundationsStructural FoundationsStructural Foundations -- no disembodied behaviour in UMLno disembodied behaviour in UML-- all behaviour generated by actions of structural elementsall behaviour generated by actions of structural elements-- pure values, variables, objects, links, messages, composites/agpure values, variables, objects, links, messages, composites/aggregatesgregates

UML 2.0 Semantics (2)UML 2.0 Semantics (2)•• Basic unit of behaviour is the Basic unit of behaviour is the actionaction

•• Actions are specified as:Actions are specified as:–– Output Pins = Output Pins = f(Inputf(Input Pins, Structural Elements)Pins, Structural Elements)

•• Pins are the parameters of class operation signatures

Actionoutputs = f(inputs, Internal Elements)

Actionoutputs = f(inputs, Internal Elements)

Structural Element-1Structural Element-1 Structural Element-nStructural Element-n

Output Pins

Output Pins

Input PinsInput Pins

Pins are the parameters of class operation signatures

•• Causality ModelCausality Model [[SelicSelic]]

ActiveObject #1

ActiveObject #1

PassiveObject

PassiveObject

ActiveObject #2

ActiveObject #2

ActiveObject #4

ActiveObject #4

ActiveObject #3

ActiveObject #3

•• Active objects have a threadActive objects have a thread→→ time of responsetime of response not dictated by calling objectnot dictated by calling object→→ runrun--toto--completion semanticscompletion semantics→→ messages arriving between activations are messages arriving between activations are

bufferedbuffered

•• Passive objects run only when calledPassive objects run only when called→→ responds regardless of whether a previous call responds regardless of whether a previous call

has been completed (requires has been completed (requires mutexmutex to protect, to protect, if necessary)if necessary)

s1s1 s2s2

Op1( )Op1( )s3s3

Op2( )Op2( )

Semantic Variation PointsSemantic Variation Points•• Not all the semantics required to specify correct operation is dNot all the semantics required to specify correct operation is defined efined

within the UML standard, BUTwithin the UML standard, BUT……

•• ‘‘PlaceholdersPlaceholders’’ are left for the gaps are left for the gaps –– Variation PointsVariation Points

•• Variation points must be completed by suppliers of executive Variation points must be completed by suppliers of executive software systems, e.g. RTOS, software systems, e.g. RTOS, CommsComms

•• Care must be taken! Models may have different behaviour under Care must be taken! Models may have different behaviour under different variation points. different variation points. Assumptions about semantics must be Assumptions about semantics must be recordedrecorded..

•• But, given these caveats, we believe that the semantics of UML iBut, given these caveats, we believe that the semantics of UML is s (just) sufficient to support more advanced model(just) sufficient to support more advanced model--based analysis, based analysis, (e.g. failure analysis)(e.g. failure analysis)

Failure ModellingFailure Modelling•• Failure analysis is only complete with respect to a particular Failure analysis is only complete with respect to a particular failure failure

modelmodel, which must be a prior assumption at the start of any analysis, which must be a prior assumption at the start of any analysis

•• Failure model used in this methodology is drawn from techniques Failure model used in this methodology is drawn from techniques developed by David developed by David PumfreyPumfrey at the University of York [at the University of York [PumfreyPumfrey]]

•• Six basic software failure types:Six basic software failure types:

–– Service Service ProvisionProvision Failures:Failures: Omission, CommissionOmission, Commission–– Service Service TimingTiming Failures:Failures: Early, LateEarly, Late–– Service Service ValueValue Failures:Failures: Coarse (implausible value),Coarse (implausible value),

Subtle (plausible value)Subtle (plausible value)

•• Failure model used extensively by Failure model used extensively by UoYUoY in conjunction with in conjunction with aerospace industry (e.g. Airbus, BAE Systems) and by Avian aerospace industry (e.g. Airbus, BAE Systems) and by Avian Technologies on contract work in the rail sectorTechnologies on contract work in the rail sector

UML Interpretation of Failure ModelUML Interpretation of Failure Model•• The standard failure types must be The standard failure types must be interpretedinterpreted in UML terms:in UML terms:

Service Provision Error Service Timing Error Service Value Error

Omission Commission Early Late Coarse (Implausible)

Subtle (Plausible)

Synchronous Operation Call

Call Action associated with message is not executed at the intended point in the behaviour

Call Action associated with this message executed instead the intended one

N/A

(GeneralOrderingerror?)

N/A

(GeneralOrderingerror?)

Implausible values taken by operation parameters (if possible)

Plausible, but incorrect, values taken by operation parameters

Combined Fragment : Loop

Loop body not executed when intended:

– minintparameter value error (is too low, or is zero)

– maxintparameter value error (too low)

– guard condition incorrectly false

Loop body executed when not intended:

– minintparameter too high

– maxintparameter too high (or infinite)

– guard condition incorrectly true

As commission As omission N/A N/A

UML Model Element Type

UML Fault Tree Construction MethodologyUML Fault Tree Construction Methodology

Sync CallSubtle ErrorSync Call

Subtle Error

Subtle error inCall Parameter n

Subtle error inCall Parameter n

Loop omissioncauses failureLoop omissioncauses failure

Value errorin maxint

causes failure

Value errorin maxint

causes failure

Value errorin minint

causes failure

Value errorin minint

causes failure

Loop guard is incorrectly falseLoop guard is

incorrectly false

Value error inguard antecedent

Value error inguard antecedent

Value error inguard consequent

Value error inguard consequent

[1[1……nn ]]

•• A fragmentary fault tree template is defined for every type of fA fragmentary fault tree template is defined for every type of failure of every type of model element in ailure of every type of model element in a class of UML behaviour diagram [cf. a class of UML behaviour diagram [cf. LevesonLeveson et al]. Each fragment relates the failure type of the et al]. Each fragment relates the failure type of the associated UML Action (at its output pins) to a set of failures associated UML Action (at its output pins) to a set of failures of its input pins.of its input pins.

•• The causal logic of each fragment is specific to the type of actThe causal logic of each fragment is specific to the type of action. Its structure may depend on ion. Its structure may depend on semantic variation points semantic variation points –– in this case the relevant variation must be selected as the anain this case the relevant variation must be selected as the analysis unfoldslysis unfolds

•• PatternPattern--based methodology (cf. OO design patterns, safety case patterns based methodology (cf. OO design patterns, safety case patterns [[HabliHabli & Kelly])& Kelly])

ParameterisedParameterisedtemplate / pattern : Output PinOutput Pin

Errorstemplate / pattern :

Errors

Input PinInput PinErrorsErrors

causally related tocausally related to

Systematic Integration of Analyses and ModelsSystematic Integration of Analyses and Models


moving (>= 5kph)


moving (>= 5kph)


intended


intended

Not developed in this exampleNot developed in this example



AlarmActive = truewhen not intended

AlarmActive = truewhen not intended


of FireAlarmState


of FireAlarmState



IsFireAlarmActive()not called

when intended

IsFireAlarmActive()not called

when intended


not intended


not intended


value of AxleSpeed


value of AxleSpeed


when not intended


when not intended



Fire sensor Fire sensor hardware hardware

faultsfaults(TBD)(TBD)


measurement


measurement

Tachosensor

fault

Tachosensor

fault

Internal errors within Internal errors within operation algorithmoperation algorithm

Internal errors Internal errors within within

operation operation algorithmalgorithm







altaltalt


getAxleSpeedgetAxleSpeed()()

Speed Speed AxleSpeedAxleSpeed



[[AlarmActiveAlarmActive = true & = true & AxleSpeedAxleSpeed < 5]< 5]

[else][else]

OpenDoorsOpenDoors

LockDoorsLockDoors

•• The templateThe template--driven approach ensures that a consistent interpretation is driven approach ensures that a consistent interpretation is taken of the causal relationships between input and output pins taken of the causal relationships between input and output pins of actionsof actions

•• A UML diagram can be scanned automatically to obtain the overallA UML diagram can be scanned automatically to obtain the overall structure structure of its associated fault treeof its associated fault tree

•• The end result is a Fault Tree that is logically consistent withThe end result is a Fault Tree that is logically consistent with, and , and systematically derivable from, its associated UML Behaviour Diagsystematically derivable from, its associated UML Behaviour Diagram.ram.

•• The procedure can be (partially) mechanized, thereby acceleratinThe procedure can be (partially) mechanized, thereby accelerating the g the analysis process and improving its consistencyanalysis process and improving its consistency(but a human analyst must still decide which template fits into (but a human analyst must still decide which template fits into each slot)each slot)

The Counterfactual Nature of Failure AnalysisThe Counterfactual Nature of Failure AnalysisDoors openwhile train is

moving (>= 5kph)


moving (>= 5kph)




not intended


not intended


when not intended


when not intended




measurement


measurement

Tachosensorfault

Tachosensorfault






IF this system failure occursIF this system failure occurs……

THEN these are the software errorsTHEN these are the software errorsthat would have to have happenedthat would have to have happened……

and these are the basic faults that would and these are the basic faults that would have to have happened to cause error A have to have happened to cause error A …… AAA BBB

The Counterfactual Nature of Failure Analysis (2)The Counterfactual Nature of Failure Analysis (2)BUT :BUT :if the basic faults if the basic faults dondon’’t happen t happen …

……this system failure this system failure cancan’’tt happen!

AAA

happen!…

SO :SO :

If we test the software for the If we test the software for the existence of the basic faultsexistence of the basic faults……

……we can determine whether we can determine whether the software will cause the the software will cause the systemsystem--level hazard.level hazard.

This is the real value of This is the real value of performing a software FTA.performing a software FTA.


moving (>= 5kph)


moving (>= 5kph)




not intended


not intended


when not intended


when not intended




measurement


measurement

Tachosensorfault

Tachosensorfault






Synthesis of Safety Validation Tests from Fault TreesSynthesis of Safety Validation Tests from Fault TreesDoors openwhile train is

moving (>= 5kph)


moving (>= 5kph)




not intended


not intended


when not intended


when not intended




measurement


measurement

Tachosensorfault

Tachosensorfault






A fault tree corresponds with a set of DNF (sumA fault tree corresponds with a set of DNF (sum--ofof--products) statements, products) statements, which are derived from the paths from the top condition to the bwhich are derived from the paths from the top condition to the base events. ase events. Two statements are shown below, derived from the paths shown by Two statements are shown below, derived from the paths shown by the white the white trace through the tree:trace through the tree:

1.1. ((Tacho_faultTacho_fault ∧∧ FireAlarmStateFireAlarmState=Active)=Active)2.2. ((Wheel_slipWheel_slip ∧∧ FireAlarmStateFireAlarmState=Active)=Active)

These sets of events are, in effect, test patterns that cause thThese sets of events are, in effect, test patterns that cause the potential e potential hazard to occur at the output. They can be applied as test caseshazard to occur at the output. They can be applied as test cases to verify this to verify this fact.fact.

Fault trees can also reveal test cases for other operations/clasFault trees can also reveal test cases for other operations/classes/modules ses/modules that require assessment, because they are sources of sensitive bthat require assessment, because they are sources of sensitive base events ase events causing the failure condition (e.g. red dotted path).causing the failure condition (e.g. red dotted path).

•• Test cases can be derived easily from fault trees, because faultTest cases can be derived easily from fault trees, because fault trees specify a set of trees specify a set of weakest preweakest pre--conditionsconditions for the for the occurrence of a hazard (the top condition of the tree) [occurrence of a hazard (the top condition of the tree) [McDermid&ClarkeMcDermid&Clarke].].

•• The inverse or negation of each preThe inverse or negation of each pre--condition forms a verification condition, or could be recondition forms a verification condition, or could be re--written as a design inspection written as a design inspection criterion. criterion.

•• UML is wellUML is well--suited to this because it includes the language OCL, which is insuited to this because it includes the language OCL, which is intended for the specification of design pretended for the specification of design pre--condition and postcondition and post--condition information.condition information.

Synthesis of Design Corrections from Fault TreesSynthesis of Design Corrections from Fault Trees•• Fault trees can be used to drive design changes by exploring theFault trees can be used to drive design changes by exploring the tree for vulnerable points tree for vulnerable points

(where paths from top events to base events consist only of OR(where paths from top events to base events consist only of OR--gates) and correcting the gates) and correcting the design so as to (design so as to (re)introducere)introduce AND gates into the new fault tree for the corrected design. AND gates into the new fault tree for the corrected design. [Illustrated by changes marked in green.][Illustrated by changes marked in green.]

•• This can also be done by the creation and enforcement of This can also be done by the creation and enforcement of design contractsdesign contracts (pre(pre--conditions or conditions or postpost--conditions to code execution) because of the relationship betweeconditions to code execution) because of the relationship between fault trees and n fault trees and weakest preconditions.weakest preconditions.



Validated Tachosensor inputreads < 5kph

when not intended

Validated Tachosensor inputreads < 5kph

when not intended



Axle #1 slip causeslow speed

measurement


measurement

Tacho #1sensorfault

Tacho #1sensorfault








getValidAxleSpeedgetValidAxleSpeed()()

Speed Speed ValidAxleSpeedValidAxleSpeed



altaltalt[[AlarmActiveAlarmActive = true & = true & ValidAxleSpeedValidAxleSpeed < 5]< 5]

[else][else]

OpenDoorsOpenDoors

LockDoorsLockDoors


measurement


measurement

Tacho #2sensorfault

Tacho #2sensorfault

Tacho #1 sensorinput reads < 5kphwhen not intended




Tacho semaphoreavailable whennot intended

Tacho semaphoreavailable whennot intended



altaltalt [[TachoTacho = Available]= Available]

[else][else]

getTachoSemaphoregetTachoSemaphore()()

SemaphoreTypeSemaphoreType TachoTacho

set set ValidAxleSpeedValidAxleSpeed = 500= 500

NOTE:Assigning the maximum value to the axle speed is a safe-side response to the validity error

HiCASEHiCASE –– A New Software Tool for Safety Assurance of A New Software Tool for Safety Assurance of SysMLSysML/UML Designs/UML Designs

Avian Technologies and AGP Micro are working on a joint venture Avian Technologies and AGP Micro are working on a joint venture to develop to develop HiCASEHiCASE --a software tool for safety assurance and engineering of UML (anda software tool for safety assurance and engineering of UML (and eventually eventually SysMLSysML) ) system designs:system designs:

•• ObjectivesObjectives–– Reduce costs of developing high integrity systems/software by imReduce costs of developing high integrity systems/software by improving integration of proving integration of

safety processes with design processessafety processes with design processes–– SemiSemi--automatic generation of safety analyses directly from UML/automatic generation of safety analyses directly from UML/SysMLSysML modelsmodels–– Automatic generation of safety validation tests/checklists from Automatic generation of safety validation tests/checklists from causal analyses (fault trees)causal analyses (fault trees)–– Automatic generation of safety properties as class contracts forAutomatic generation of safety properties as class contracts for designdesign--byby--contract contract

processes and formal verification (e.g. SPARK)processes and formal verification (e.g. SPARK)

•• Production Schedule (approximate)Production Schedule (approximate)–– Product launch early summer 2007Product launch early summer 2007–– Functionality upgrades/enhancements at least once per year (for Functionality upgrades/enhancements at least once per year (for subscription holders)subscription holders)

•• Product VersionsProduct Versions–– Professional Edition:Professional Edition: basic UML model scanning and safety analysis capabilities onlybasic UML model scanning and safety analysis capabilities only–– Enterprise Edition:Enterprise Edition: full range of functionsfull range of functions–– Certification Pack:Certification Pack: additional documentation for DefStan00additional documentation for DefStan00--56 qualification (all 56 qualification (all SILsSILs))

ReferencesReferences1.1. AndaAnda B., Hansen K., B., Hansen K., GullesenGullesen I, I, ThorsenThorsen H.K., Experiences from Introducing UMLH.K., Experiences from Introducing UML--

based Development in a Large safetybased Development in a Large safety--Critical Project, URL: Critical Project, URL: http://www.simula.no/departments/engineering/publications/Anda.2http://www.simula.no/departments/engineering/publications/Anda.2005.3005.3

2.2. PatariczaPataricza A., A., MajzikMajzik I., I., HuszerlHuszerl G., G., VVáárnairnai GyGy.: .: UMLUML--based Design and Formal based Design and Formal Analysis of a SafetyAnalysis of a Safety--Critical Railway Control Software Module, Critical Railway Control Software Module, Proc. Proc. SympSymp. . FORMSFORMS--2003, Budapest, May 152003, Budapest, May 15--16, pp.12516, pp.125--132, 2003 132, 2003

3.3. SelicSelic B.V., B.V., On the Semantic Foundations of Standard UML 2.0On the Semantic Foundations of Standard UML 2.0, LNCS 3185, , LNCS 3185, pp181pp181--199, Springer 199, Springer VerlagVerlag 20042004

4.4. LevesonLeveson N.G., Cha S.S, N.G., Cha S.S, ShimeallShimeall T.J., T.J., Safety Verification of Safety Verification of AdaAda Programs Using Programs Using Software Fault TreesSoftware Fault Trees, IEEE Software, July 1991, pp48, IEEE Software, July 1991, pp48--5959

5.5. McDermidMcDermid J.A., Clarke S.J., J.A., Clarke S.J., Software fault trees and weakest preconditions: a Software fault trees and weakest preconditions: a comparison and analysiscomparison and analysis, IEE , IEE SoftwSoftw. Eng. . Eng. JournJourn., July 1993, pp225., July 1993, pp225--236236

6.6. PumfreyPumfrey D., D., The Principled Design of Computer System Safety The Principled Design of Computer System Safety Analyses, PhD Analyses, PhD Thesis, University of York 1999Thesis, University of York 1999

7.7. HabliHabli I., Kelly T., I., Kelly T., Achieving Integrated Process and Product ArgumentsAchieving Integrated Process and Product Arguments, Proc. 15, Proc. 15thth

SafetySafety--critical Systems Symposium, Eds. critical Systems Symposium, Eds. RedmillRedmill and Anderson, Springer 2007 and Anderson, Springer 2007 (also: the tutorial in this OMG Software Assurance Workshop)(also: the tutorial in this OMG Software Assurance Workshop)

http://www.simula.no/departments/engineering/publications/Anda.2005.3

fault tree analysis of uml designs - object management group

Documents