Subsystem Hazard Analysis(SSHA tem Hazard Analysis EXamine subsystems to determine how their Normal performance Operational degradation Functional failure Unintended function Inadvertent function(proper function but at wrong time or in wrong order) could contribute to system hazards Determine how to satisfy design constraints in subsystem design Validate the subsystem design satisfies safety design constraints and does not introduce previously unidentified hazardous system behavior OL Software Hazard Analysis A form of subsystem hazard analysis Validate that specified software blackbox behavior satisfies system safety design constraints Check specified software behavior satisfies general software system safety design criteria Must perform on ALL software, including COTS
c ✢✡☎✣✞✡☎✆✟✙✤✕✔✥✧✦✩★✪✦ ✂✁☎✄☎✆✞✝✟✆✞✠✡☎☛✌☞✎✍☎✏✟✍☎✑✒✔✓✖✕☎✍☎✗✝✞✆✟✘✆ Subsystem Hazard Analysis (SSHA) Examine subsystems to determine how their Normal performance Operational degradation Functional failure Unintended function Inadvertent function (proper function but at wrong time or in wrong order) could contribute to system hazards. Determine how to satisfy design constraints in subsystem design. Validate the subsystem design satisfies safety design constraints and does not introduce previously unidentified hazardous system behavior. c ✢✡☎✣✞✡☎✆✟✙✤✕✔✥✧✦✩★☎✫ ✂✙☎✚✠✛✜✍☎✑✡✔☞✎✍☎✏✞✍☎✑✒✔✓✖✕☎✍☎✗✝✞✆✞✘✆ Software Hazard Analysis A form of subsystem hazard analysis. Validate that specified software blackbox behavior satisfies system safety design constraints. Check specified software behavior satisfies general software system safety design criteria. Must perform on ALL software, including COTS
State Machine Hazard Analysis Sothys ard Anaysis Like system hazard analysis, software(subsystem) hazard analysis requires a model of the components behavio Using code is too hard and too late Software is too complex to do analysis entirely in one's head Formal models are useful, but they need to be easily readable and usable without graduate-level training in discrete math Only a small subset of errors are detectable by automated tools: the most important ones require human knowledge and expertise Mathematical proofs must be understandable(checkable)by application experts Hazard analysis process requires that results can be openly reviewed and discussed Software State Machine Hazard analysis(2 State machines make a good model for describing and analyzing digital systems and software Match intuitive notions of how machines work(e.g, sets do not) Have a mathematical basis so can be analyzed and graphica notations that are easily understandable Previous problems with state explosion have been solved by meta-modeling"languages so complex systems can be handled Some analyses can be automated and tools can assist human analyst to traverse(search)model Our experience is that assisted search and understanding tools are the most helpful in hazard analysis Completely automated tools have an important but more limited role to play
c ✢✡☎✣✞✡☎✆✞✙☎✕✔✥✧✦✩★☎✬ ✂✙☎✚✠✛✜✍☎✑✡✔☞✜✍☎✏✞✍☎✑✒✔✓✂✕☎✍☎✗✝✞✆✞✘✆ State Machine Hazard Analysis Like system hazard analysis, software (subsystem) hazard analysis requires a model of the component’s behavior. Using code is too hard and too late. Software is too complex to do analysis entirely in one’s head. Formal models are useful, but they need to be easily readable and usable without graduate−level training in discrete math. Only a small subset of errors are detectable by automated tools: the most important ones require human knowledge and expertise. Mathematical proofs must be understandable (checkable) by application experts. Hazard analysis process requires that results can be openly reviewed and discussed. ✡☎✣✞✡☎✆✞✙☎✕✔✥✧✦✩★☎✭ ✂✙☎✚✠✛✜✍☎✑✡✔☞✜✍☎✏✞✍☎✑✒✔✓✂✕☎✍☎✗✝✞✆✞✘✆ State Machine Hazard Analysis (2) State machines make a good model for describing and analyzing digital systems and software. Match intuitive notions of how machines work (e.g., sets do not) Have a mathematical basis so can be analyzed and graphical notations that are easily understandable. Previous problems with state explosion have been solved by "meta−modeling" languages so complex systems can be handled. Some analyses can be automated and tools can assist human analyst to traverse (search) model. Our experience is that assisted search and understanding tools are the most helpful in hazard analysis. c ✢ Completely automated tools have an important but more limited role to play
Example of a State Machine Model Software Hazard Ana lysis Wate Reading at set point lose drain Reading at setpoint Turn off pump level at High reading setpoint pen drain pipe pl Water Low reading le Activate pump low Software Hazard Analsis Requirements validation Requirements are source of most operational errors and almost all the software contributions to accidents Much of software hazard analysis effort therefore should focus on requirements Problem is dealing with complexity 1)Use blackbox models to separate external behavior from complexity of internal design to accomplish the behavior. 2) Use abstraction and metamodels to handle large number of discrete states required to describe software behavior Do not have continuous math to assist us But new types of state machine modeling languages drastically reduce number of states and transitions modeler needs to describe
✡☎✣✞✡☎✆✞✙☎✕✔✥✧✦✩★☎✮ ✂✙☎✚✠✛✜✍☎✑✡✔☞✜✍☎✏✞✍☎✑✒✔✓✂✕☎✍☎✗✝✞✆✞✘✆ Example of a State Machine Model c ✢ Reading at set point / Close drain pipe / Water level high level at setpoint Water Low reading / Activate pump Reading at setpoint / Turn off pump Water level low Open drain pipe High reading c ✢✡☎✣✞✡☎✆✞✙☎✕✔✥✧✦✩★☎★ ✂✙☎✚✠✛✜✍☎✑✡✔☞✜✍☎✏✞✍☎✑✒✔✓✂✕☎✍☎✗✝✞✆✞✘✆ Requirements Validation Requirements are source of most operational errors and almost all the software contributions to accidents. Much of software hazard analysis effort therefore should focus on requirements. Problem is dealing with complexity 1) Use blackbox models to separate external behavior from complexity of internal design to accomplish the behavior. 2) Use abstraction and metamodels to handle large number of discrete states required to describe software behavior. Do not have continuous math to assist us But new types of state machine modeling languages drastically reduce number of states and transitions modeler needs to describe
cruise control turned on initialize cc Cruise Cruise Control on Control and in increase speed commanded Off Standby Mode send command to throttle to increase at x rate brake depressed Increasing or accelerator Speed depressed discontinue cruise control set point reached /reduce throttle Maintaining Speed read wheel turning rate adjust throttle
cruise control and in Control On Cruise or accelerator depressed / cruise control to increase at X rate send command to throttle initialize cc turned on / discontinue brake depressed set point reached / reduce throttle Standby increase speed commanded / Mode Cruise Control Off Maintaining Increasing Speed Speed read wheel turning rate / adjust throttle
Blackbox specifications Provide a blackbox statement of software behavior Permits statements only in terms of outputs and externally observable conditions or events that stimulate or trigger those outputs trigger output(double implication) Complete trigger specification must include full set of conditions that may be inferred from existence of specified output Such conditions represent the assumptions about the environment in which program or system is to operate Thus the specification is the input to output function computed by the component, i.e., the transfer function Internal design decisions are not included Softwa Process models Define required blackbox behavior of software in terms of a state machine model of the process(plant) Measured SensorsLvariables Process inputs Human Automated Controller Controlled Model of Disturbances Process Process Model of Model of Displays Process Automation Actuators Process Controlled variables
c ✢✡☎✣✞✡☎✆✟✙☎✕✔✥✯✦✩★☎✰ ✖✙✤✚✠✛✜✍☎✑✡✔☞✎✍☎✏✞✍☎✑✒✔✓✖✕☎✍☎✗✝✞✆✞✘✆ Blackbox specifications Provide a blackbox statement of software behavior: Permits statements only in terms of outputs and externally observable conditions or events that stimulate or trigger those outputs. trigger output (double implication) Complete trigger specification must include full set of conditions that may be inferred from existence of specified output. Such conditions represent the assumptions about the environment in which program or system is to operate. Thus the specification is the input to output function computed by the component, i.e., the transfer function. Internal design decisions are not included. ✡☎✣✞✡☎✆✟✙☎✕✔✥✯✦✩★☎✱ ✖✙✤✚✠✛✜✍☎✑✡✔☞✎✍☎✏✞✍☎✑✒✔✓✖✕☎✍☎✗✝✞✆✞✘✆ Process Models Define required blackbox behavior of software in terms of a state machine model of the process (plant). c ✢ Sensors variables Controls Displays Model of Process Actuators Controlled Measured Disturbances Process Model of Automated Process inputs outputs Process Human Automation Model of Controller Process Controlled Supervisor variables
Software Ha zard Anal Level 3 Specification(modeling)language goals · Readable and reviewable Minimize semantic distance Minimal(blackbox) Easy to learn Unambiguous and simple semantics Complete Can specify everything need to specify Analyzable Executable Formal(mathematical) foundation ludes human actions Assists in finding incompleteness Software Hazard Analysis SpecTRM-RL Combined requirements specification and modeling language a state machine with a more readable notation on top of it Includes a task modeling language Could add other notations and visualizations of state machine Enforces or includes most of completeness criteria Supports specifying systems in terms of modes Control modes Operational modes Supervisory modes Display modes
✡☎✣✞✡☎✆✞✙☎✕✔✥✧✦✩★☎✲ ✂✙☎✚✠✛✜✍☎✑✡✔☞✜✍☎✏✞✍☎✑✒✔✓✂✕☎✍☎✗✝✞✆✞✘✆ c ✢ Level 3 Specification (modeling) language goals Readable and reviewable Minimize semantic distance Minimal (blackbox) Easy to learn Unambiguous and simple semantics Complete Can specify everything need to specify Analyzable Executable Formal (mathematical) foundation Includes human actions Assists in finding incompleteness c ✢✡☎✣✞✡☎✆✞✙☎✕✔✥✧✦✩✰☎✳ ✂✙☎✚✠✛✜✍☎✑✡✔☞✜✍☎✏✞✍☎✑✒✔✓✂✕☎✍☎✗✝✞✆✞✘✆ SpecTRM−RL Combined requirements specification and modeling language A state machine with a more readable notation on top of it Includes a task modeling language Could add other notations and visualizations of state machine Enforces or includes most of completeness criteria Supports specifying systems in terms of modes Control modes Operational modes Supervisory modes Display modes
Software Hazard Ana lysis Model of process Process is modeled using state variables Traffic Density Schedule Slot [1...90] LoW Available Average Aircraft scheduled High Blocked Unknown Unknow Values of state variables given by AND/OR tables Software Environment Sensor Measured variable 1 Measured Variable 2 Component SUPERVISORY: INFERRED SYSTEM OPERATING MODES Control CONTROL INFERRED SYSTEM STATE Command Controlled Supervisor MODES Device
c ✢✡☎✣✞✡☎✆✞✙☎✕✔✥✧✦✩✰✪✦ ✂✙☎✚✠✛✜✍☎✑✡✔☞✜✍☎✏✞✍☎✑✒✔✓✂✕☎✍☎✗✝✞✆✞✘✆ Model of Process Process is modeled using state variables Average Low Unknown High Traffic Density Schedule Slot [1...90] Unknown Blocked Aircraft Scheduled Available Values of state variables given by AND/OR tables c ✢✡☎✣✞✡☎✆✞✙☎✕✔✥✧✦✩✰☎✫ ✂✙☎✚✠✛✜✍☎✑✡✔☞✜✍☎✏✞✍☎✑✒✔✓✂✕☎✍☎✗✝✞✆✞✘✆ Component MODE SUPERVISORY CONTROL INFERRED SYSTEM OPERATING MODES MODES Measured Variable Command Control Display Output Control Input Controlled Device Measured Variable 1 Measured Variable 2 Supervisor (Feedback) Sensor Environment INFERRED SYSTEM STATE
Digital altitude Altimeterstatus altitude Altimeterstatus Analog altitude Altimeterstatus Altitude Device of interest InterfaceA Inhibit Signal Switch Power-on Signal (DOI) Reset Signal DOI Status Signal Strobe Watchdog Timer
Altimeter Digital Altimeter Analog Digital Altimeter Pilot Interface Device of Interest Switch (DOI) Altitude Watchdog Timer Power-on Signal Strobe DOI Status Signal altitude status altitude status altitude status Inhibit Signal Reset Signal
Analog Digital Digital Altimeter Altimeter 1 Altimeter 2 Analog-Alt-Signal DA1-Alt-Signal DA2-Alt-Signal Below, Above) 50.2500}wr -50.2500} Analog-Alt -Status DA1-Status-S DA2-Status-signa (Invalid, Validy Fail, NCD, Test Fail, NCD, Test, Norm) Altitude switch SUPERVISORY INFERRED SYSTEM STATE MODE Analog-AIt Dig 1-AIt DOJ-Power-On Valid Valid Cockpit Unknown Unknown Device Fault Inhibit (On, Off] CONTROL Interest ndicator MODES Aircraft Altitude Dig2-AIt Below-threshold Valid Reset T, Fy At-or-above-threshold Invalid Unknown Fault Detected Cannot-be-determined Not Inhibited DOl-Status tOn, Oft] Inhibited On Off Unknown Fault-det Watchdog-Strobe(Highy Watchdog Timer
Watchdog Timer {Fail,NCD,Test,Norm} DA2-Status-Signal INT DA2-Alt-Signal {-50..2500} {Fail,NCD,Test,Norm} DA1-Status-Signal INT {-50..2500} DA1-Alt-Signal {Invalid,Valid} Analog-Alt-Status {Below,Above} Analog-Alt-Signal Digital Altimeter Altimeter 1 Analog Altitude Switch Cockpit Fault Indicator Lamp On Off INFERRED SYSTEM STATE DOI-Status On Off Unknown Fault-detected Unknown Cannot-be-determined Below-threshold At-or-above-threshold Aircraft Altitude Valid Invalid Unknown Valid Unknown Invalid Analog-Alt Valid Invalid Unknown Altimeter 2 Digital (DOI) Interest of Device {High} DOI-Power-On DOI-status-signal {On, Off} Watchdog-Strobe {High} Inhibit {On,Off} Reset {T,F} Dig1-Alt Dig2-Alt Operational Fault Detected Startup Inhibited Not Inhibited MODES CONTROL Cockpit Controls MODE SUPERVISORY
Output Command DOl-Power-On Destination: DOI Acceptable Values: ( high] Initiation Delay: 0 milliseconds Completion Deadline: 50 milliseconds Exception-Handling: ( What to do if cannot issue command within deadline time) Feed back Information Variables: DOl-status-signal Values: high(on) Relationship: Should be on if ASW sent signal to turn on Min. time(latency ) 2 seconds Max time: 4 second Exception Handling: Dol-Status changed to Fault-Detected Reversed By: Turned off by some other component or components. Do not know which ones Comments: I am assuming that if we do not know if the dol is on, it is better to turn it on again, i.e., that the reason for the restriction is simply hysteresis and not possible damage to the device This product in the family will turn on the doE only when the aircraft descends below the threshold altitude. Only this page needs to change for a product in the family that is triggered by rising above the threshold References: CONTENTS discrete signal on line PWR set to high TRIGGERING CONDITION Control Mode Operational Not inhibited State values Ititude below-threshhold Prev(Altitude)= At-or-above-threshold
Output Command DOI-Power-On Destination: DOI Acceptable Values: Initiation Delay: {high} 0 milliseconds Completion Deadline: 50 milliseconds Exception-Handling: Feedback Information: Variables: (What to do if cannot issue command within deadline time) DOI-status-signal Values: high (on) Relationship: Should be on if ASW sent signal to turn on Min. time (latency): 2 seconds Max. time: 4 seconds Exception Handling: Reversed By: DOI-Status changed to Fault-Detected Turned off by some other component or components. Do not know which ones. Comments: I am assuming that if we do not know if the DOI is on, it is better to turn it on again, i.e., that the reason for the restriction is simply hysteresis and not possible damage to the device. This product in the family will turn on the DOE only when the aircraft descends below the threshold altitude. Only this page needs to change for a product in the family that is triggered by rising above the threshold. References: CONTENTS = discrete signal on line PWR set to high TRIGGERING CONDITION T Prev(Altitude) = At-or-above-threshold T Altitude = Below-threshhold State Values DOI-Status = On F Operational T Not Inhibited T Control Mode