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