Fault Tree Analysis of UML Designs · • A fragmentary fault tree template is defined for every...
Transcript of Fault Tree Analysis of UML Designs · • A fragmentary fault tree template is defined for every...
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
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
LockDoors signalnot sent when
intended
Not developed in this exampleNot developed in this example
AxleSpeed < 5when not intended
AxleSpeed < 5when not intended
AlarmActive = truewhen not intendedAlarmActive = truewhen not intended
IsFireAlarmActive()returns incorrect value
of FireAlarmState
IsFireAlarmActive()returns incorrect value
of FireAlarmState
FireAlarmStateattribute set Activewhen not intended
FireAlarmStateattribute set Activewhen not intended
IsFireAlarmActive()called when not intended
IsFireAlarmActive()called when not intended
OpenDoors signalsent when
not intended
OpenDoors signalsent when
not intended
getAxleSpeed()returns incorrect
value of AxleSpeed
getAxleSpeed()returns incorrect
value of AxleSpeed
Tacho sensor inputreads < 5kph
when not intended
Tacho sensor inputreads < 5kph
when not intended
getAxleSpeed()called whennot intended
getAxleSpeed()called whennot intended
Wheel slip causeslow speed
measurement
Wheel slip causeslow speed
measurement
Tachosensorfault
Tachosensorfault
Fire sensor hardware faultsFire sensor hardware faults
ControlDoors()called whennot intended
ControlDoors()called whennot intended
ControlDoors()calls getAxleSpeed()when not 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
ControlDoors()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
Doors openwhile train is
moving (>= 5kph)
Doors openwhile train is
moving (>= 5kph)
LockDoors signalnot sent when
intended
LockDoors signalnot sent when
intended
Not developed in this exampleNot developed in this example
AxleSpeed < 5when not intended
AxleSpeed < 5when not intended
AlarmActive = truewhen not intended
AlarmActive = truewhen not intended
IsFireAlarmActive()returns incorrect value
of FireAlarmState
IsFireAlarmActive()returns incorrect value
of FireAlarmState
FireAlarmStateattribute set Activewhen not intended
FireAlarmStateattribute set Activewhen not intended
IsFireAlarmActive()not called
when intended
IsFireAlarmActive()not called
when intended
OpenDoors signalsent when
not intended
OpenDoors signalsent when
not intended
getAxleSpeed()returns incorrect
value of AxleSpeed
getAxleSpeed()returns incorrect
value of AxleSpeed
Tacho sensor inputreads < 5kph
when not intended
Tacho sensor inputreads < 5kph
when not intended
getAxleSpeed()called whennot intended
getAxleSpeed()called whennot intended
Fire sensor Fire sensor hardware hardware
faultsfaults(TBD)(TBD)
Wheel slip causeslow speed
measurement
Wheel slip causeslow speed
measurement
Tachosensor
fault
Tachosensor
fault
Internal errors within Internal errors within operation algorithmoperation algorithm
Internal errors Internal errors within within
operation operation algorithmalgorithm
getAxleSpeed()called whennot intended
getAxleSpeed()called whennot intended
ControlDoors()calls getAxleSpeed()when not intended
ControlDoors()calls getAxleSpeed()when not intended
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
•• 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)
Doors openwhile train is
moving (>= 5kph)
AxleSpeed < 5when not intended
AxleSpeed < 5when not intended
OpenDoors signalsent when
not intended
OpenDoors signalsent when
not intended
Tacho sensor inputreads < 5kph
when not intended
Tacho sensor inputreads < 5kph
when not intended
getAxleSpeed()called whennot intended
getAxleSpeed()called whennot intended
Wheel slip causeslow speed
measurement
Wheel slip causeslow speed
measurement
Tachosensorfault
Tachosensorfault
ControlDoors()called whennot intended
ControlDoors()called whennot intended
ControlDoors()calls getAxleSpeed()when not intended
ControlDoors()calls getAxleSpeed()when not intended
AlarmActive = truewhen not intendedAlarmActive = truewhen not intended
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.
Doors openwhile train is
moving (>= 5kph)
Doors openwhile train is
moving (>= 5kph)
AxleSpeed < 5when not intended
AxleSpeed < 5when not intended
OpenDoors signalsent when
not intended
OpenDoors signalsent when
not intended
Tacho sensor inputreads < 5kph
when not intended
Tacho sensor inputreads < 5kph
when not intended
getAxleSpeed()called whennot intended
getAxleSpeed()called whennot intended
Wheel slip causeslow speed
measurement
Wheel slip causeslow speed
measurement
Tachosensorfault
Tachosensorfault
ControlDoors()called whennot intended
ControlDoors()called whennot intended
ControlDoors()calls getAxleSpeed()when not intended
ControlDoors()calls getAxleSpeed()when not intended
AlarmActive = truewhen not intendedAlarmActive = truewhen not intended
Synthesis of Safety Validation Tests from Fault TreesSynthesis of Safety Validation Tests from Fault TreesDoors openwhile train is
moving (>= 5kph)
Doors openwhile train is
moving (>= 5kph)
AxleSpeed < 5when not intended
AxleSpeed < 5when not intended
OpenDoors signalsent when
not intended
OpenDoors signalsent when
not intended
Tacho sensor inputreads < 5kph
when not intended
Tacho sensor inputreads < 5kph
when not intended
getAxleSpeed()called whennot intended
getAxleSpeed()called whennot intended
Wheel slip causeslow speed
measurement
Wheel slip causeslow speed
measurement
Tachosensorfault
Tachosensorfault
ControlDoors()called whennot intended
ControlDoors()called whennot intended
ControlDoors()calls getAxleSpeed()when not intended
ControlDoors()calls getAxleSpeed()when not intended
AlarmActive = truewhen not intendedAlarmActive = truewhen not intended
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.
AxleSpeed < 5when not intended
AxleSpeed < 5when not intended
Validated Tachosensor inputreads < 5kph
when not intended
Validated Tachosensor inputreads < 5kph
when not intended
getAxleSpeed()called whennot intended
getAxleSpeed()called whennot intended
Axle #1 slip causeslow speed
measurement
Axle #1 slip causeslow speed
measurement
Tacho #1sensorfault
Tacho #1sensorfault
ControlDoors()called whennot intended
ControlDoors()called whennot intended
ControlDoors()calls getAxleSpeed()when not intended
ControlDoors()calls getAxleSpeed()when not intended
Door Control RelayDoor Control Relay
WheelTachoWheelTachoWheelTacho FireAlarmSignalFireAlarmSignalFireAlarmSignalDoorControllerDoorControllerDoorController
ControlDoorsControlDoors()()
getValidAxleSpeedgetValidAxleSpeed()()
Speed Speed ValidAxleSpeedValidAxleSpeed
IsFireAlarmActiveIsFireAlarmActive()()
boolbool AlarmActiveAlarmActive
altaltalt[[AlarmActiveAlarmActive = true & = true & ValidAxleSpeedValidAxleSpeed < 5]< 5]
[else][else]
OpenDoorsOpenDoors
LockDoorsLockDoors
Axle #2 slip causeslow speed
measurement
Axle #2 slip causeslow speed
measurement
Tacho #2sensorfault
Tacho #2sensorfault
Tacho #1 sensorinput reads < 5kphwhen not intended
Tacho #1 sensorinput reads < 5kphwhen not intended
Tacho #2 sensorinput reads < 5kphwhen not intended
Tacho #2 sensorinput reads < 5kphwhen not intended
Tacho semaphoreavailable whennot intended
Tacho semaphoreavailable whennot intended
ControlDoors()calls getAxleSpeed()when not intended
ControlDoors()calls getAxleSpeed()when not 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)