Subnode [[@flancian/system-theoretic-process-analysis]] in node [[system-theoretic-process-analysis]]
- for hazard analysis
- by nancy leveson and john thomas
- pull stpa handbook stpa workshop
- i love how STPA defers key steps to a later stage so they can be done systemically, once partial but complete initial modeling has taken place.
- it can be applied recursively. it could be argued that because STPA can be applied recursively the cost of abstraction is minimized or at least bound.
- 4 steps
step one: define the purpose of the analysis
- start with the losses, which involve something of value to stakeholders
- continue by defining the scope of the system
- find hazards, which are systemic states or conditions to be prevented, and which together with (worst-case) environmental conditions lead to losses.
- find system level constraints.
- optionally find sub hazards, which might also help define further constraints
step two: model the control structure
a control structure is a system model that is composed of feedback control loops.
- a good control structure will enforce the system level constraints.
control goes down, feedback goes up
- vertical axis represents a hierarchy (heterarchy? perhaps in voting systems)
- responsibilities can be assigned to each control structure entity; they are refinements of system level constraints
- feedback can be derived from responsibilities (which information does the process model need to contain?)
step three: identify unsafe control actions
- an unsafe control action is one that, in a particular context, will lead to a hazard.
- it must include the actual (real) context in which the control action is unsafe, instead of controller beliefs; and it must be linked to a hazard.
- define controller constraints: behaviours that need to be satisfied to prevent UCAs. they can usually be derived from negations of the UCAs.
- step four: identify loss scenarios