RAFIA STPA Procedure

This is an adaptation of the methodology described in the STPA Handbook, for use with RAFIA, incorporating clarifications and improvements devised by Simon Whitely of Whitely Aerospace.

Terms that are specific to STPA are linked to the glossary, which also includes guidance about how to approach many of these steps, and tips to avoid common pitfalls.

In this procedure:

• An element is a component, subsystem or collaborating set of components in a larger system, which has an identifiable purpose within that system.
• SUA stands for Software Under Analysis, meaning the software element that is the primary focus of your work.
• Target system is a software or hardware/software system that is intended to incorporate the SUA in a given role.

To apply STPA for a given SUA and a given Target system may require more than one analysis, each with different scope and/or purpose. For a given analysis, there may also a number of iterations, which may extend or refine the define purpose or the control structure for that analysis.

The results of each step in a given analysis are recorded in a workbook, which consists of a number of interlinked tables. The columns for these tables are described in the workbook schema and can be seen in the workbook template.

A given iteration of STPA for a defined scope and purpose concludes when all of the 10 steps have been completed, as specified in the Review criteria.

Note

STPA is an iterative process, and you should expect to revisit and refine or extend the results of earlier steps as a result of insights that you obtain in the course of the analysis.

However, if these insights lead to radical changes in your understanding of the existing scope or the control structure defined in step 3, then it may be more effective to conclude the current analysis and restart, rather than attempt to rework.

1. Define the scope of analysis

Describe a System that incorporates the SUA, which might be a physical or a software system, or a discrete part of a larger system.

• This defines the scope of the analysis
  • Typically you will define a scope that corresponds to the limits of your design responsibility, or your ability to influence the design of the system or its elements.
  • You may also decide to focus on one aspect or part of a larger system
• Identify the boundary or boundaries of the System, where applicable, and list the inputs or outputs that cross each boundary
  • A Boundary may be a non-physical interface, or set of interfaces, or represent a set of software APIs
  • A Boundary may be defined by the Elements that manage inputs and outputs between the System and its Environment
• An initial version of the Control Structure can be drawn at this point, and may inform the above.
• Any design assumptions that you make regarding the System or its Elements should also be documented, especially where these relate to safety- or security-critical aspects of the system.

Review criteria

• Scope of the analysis is documented in the workbook, including:
  • High level description of the system, its boundary and its environment
  • A diagram illustrating the system and its boundary, or a preliminary control structure
• Scope is also recorded in artifacts under change control

2. Define the purpose of analysis

Identify Losses (outcomes that are unacceptable for the System's stakeholders) and Hazards (System-level conditions that can lead to these Losses), and then derive or devise System-level constraints (SLC) (system conditions or behaviours that need to be satisfied to prevent hazards) for the latter.

These formally specify the focus of the analysis; typically this will be informed by the safety and/or security goals of the system being analysed. For a software system or component, these may be the assumed goals of an intended target system, or class of systems.

• Losses may include unacceptable commercial- (loss of profit), financial- (damage to property) or user-related (loss of mission) outcomes as well as safety-related (death or injury to people) ones
• Hazards directly relate to the scope of the analysis:
  • They identify a set of System conditions leading to Losses that the designers are responsible for preventing or mitigating.
  • A single analysis may focus on a subset of the complete set of Hazards applicable for a System.
• When writing SLC, it is important to consider the System as a whole and what must be true in order to prevent the Hazards
• See also the guidance for Constraints in general when writing SLC.
• SLC may also describe necessary Mitigations if it is not possible to prevent or avoid a Hazard.

Review criteria

• Losses are documented in the workbook, meeting the following criteria:
  • Do not refer to individual Elements or specific causes
• Hazards are documented in the workbook, meeting the following criteria:
  • Do not refer to individual Elements of the System.
  • Are linked to one or more Losses.
  • Refer to factors that can be controlled or managed by the System designers and operators.
  • Describe system-level conditions to be prevented, not failures or deviations from specified system functions.
  • Do not use ambiguous or recursive words like "unsafe", "unintended", "accidental", etc.

• System Level Constraints are documented in the workbook, meeting the following criteria:

  • Relate to the System, rather than individual components
  • Are linked to one or more Hazards.
  • Communicate what needs to be true in order to avoid a negative outcome, rather than how that is to be accomplished.
  • Use the indicative mood, rather than the imperative mood.
  • Use the same context and terminology as the associated Hazards.

• Losses, Hazards and SLC are stored as artifacts under change control

3. Describe a control structure

Specify a hierarchical Control Structure, which describes the functionality of the System in terms of its Elements (notably Controllers and Controlled Processes) and interactions between these (notably Control Actions and Feedback).

• The System concept from step 1 will provide a starting point for this
• The SUA may be represented by one or more of the Elements
  • Multiple Elements can be used to show discrete functions of the SUA
• Use a hierarchical control structure diagram to show the Elements and Interactions:
  • Elements are represented by labelled rectangular boxes
  • Control actions are represented by arrows with a solid line, and should point downwards wherever possible
  • Feedback is represented by arrows with a dashed line, and should point upwards wherever possible
  • Other interactions are represented by arrows with a dotted line
  • Only include one arrow of each type between Elements in the diagram
    • More specific interactions will be detailed in the Interactions table.
• Label each of the elements with a unique identifier (e.g. E1) in addition to its name.
• Classify each of the interactions (and label accordingly) as:
  • Control Actions (C label)
  • Feedback (F label)
  • Other interactions (I label)
• It may be useful to pair Control Action and Feedback interactions (and number them accordingly) to help identify feedback loops (ie. where feedback leads to control actions, or control actions lead to feedback). This is examined in step 6.
• Use the Elements and Interactions tables to record the diagram
  • Each box in the diagram is an Element
  • Each arrow in the diagram is an Interaction
  • Document more details for each Element, including its Responsibilities and its role(s) in the control structure.
  • Document more details for each Interaction, including a short description its type (C, F or I) and its start and end points.
• Break down the simplified Interactions shown in the diagram
  • Detail more specific Control Actions, Feedback and Other Interactions as appropriate, to characterise discrete Interactions of each type as appropriate for the level of abstraction
    • You should not try to include every possible signal exchanged between the Elements
    • Control Actions may be an abstraction describing the overall intent of a sequence of interactions
    • Feedback is an abstraction classifying information that the Controller needs, rather than specific signals conveying that information
  • Assign these Interactions identifiers based on the Diagram label
    • e.g. More specific Control Actions associated with the diagram label C1 would be assigned identifiers of C1.1, C1.2, etc

Review criteria

• A hierarchical control structure diagram is completed
  • All elements are labelled appropriately
  • All interactions are labelled appropriately
• Control structure is documented in the workbook
  • Control structure diagram is included in Scope, along with a description
  • Elements and Interactions tables are complete,
    • Entries correlate with the Element and Interaction labels in the diagram.
    • Interactions are broken down into more specific Control Actions, Feedback and Other Interactions as appropriate
    • More specific Interactions are grouped under the corresponding Interactions from the diagram, and appropriately labelled.
    • Interactions are described at an appropriate level of abstraction
• Control structure is also stored as artifacts under change control.

4. Identify Unsafe Control Actions

Identify Unsafe Control Actions (UCA) (interactions between a Controller and a Controlled Process that may result in a Hazard) by analysing each Control Action (CA) in the control structure.

Note

Focus on identifying contexts and circumstances in which a control action might potentially lead to a Hazard, rather than what might cause this.

The resulting list feeds into the subsequent Causal Scenario analysis (see step 7), which will explore the reasons why a UCA might occur.

• Use the CA-Analysis table to record the analysis results
  • For each Control Action in the Interactions table, consider each of the types of UCA and record whether it is applicable
  • If a UCA type is applicable, but would never result in an unsafe outcome, then the Analysis Result should be Safe
  • If you can identify any worst-case scenario in which the type of UCA might apply, then the result should be UCA.
  • If the UCA type is not applicable to the Control Action, record the result as N/A, and document your reasoning for this in the Notes column.
• In the Justification field add:
  • A description or example of how a UCA could occur if the result is UCA
  • A justification for why the UCA type does not apply if the result is N/A
  • A justification for why a UCA cannot occur if the result is Safe
• Elements may be designated out of scope for a particular analysis if they have no Control Actions and provide no Feedback
  • Record this designation in the Justification column
• A UCA must include a WHEN-type statement (UCA Context) to describe the system- or component-level condition in which it applies
  • This provides additional context to explain why the UCA is applicable
  • Add contexts in the UCA-Context table, so they may be shared between UCA
  • You may also want to return to earlier Control Actions after adding a new UCA Context, as the new context may suggest a new UCA.
• Where any UCA is identified that you cannot link to a hazard, return to the hazard definitions and determine if you need to add a new hazard or SLC
• For each row with an Analysis Result of UCA add a corresponding row in the UCA table.
  • For each item, review the Justification field and ensure that it provides a clear explanation of how a UCA of this type may result.
  • If the text needs improving, either update the corresponding cell in the CA-Analysis table, or replace the mirrored text in the UCA table.

Review criteria

• At least one set of CA-Analysis rows exists for each control action in the Interactions table
  • Each set of rows for a given CA and UCA-Context includes a row for each of UCA types defined by the UCAType table
  • Specified UCA-Contexts are relevant and specific to the context of the linked CA-Analysis rows
• Each CA-Analysis row with a UCA result has a corresponding row in the UCA table.
• Each CA-Analysis row has a Justification, which either describes a UCA (see next) or explains / justifies why a different result was recorded.
• The UCA Description field for each row in the UCA table provides a clear description of how this type of UCA applies for the given CA and context.
• CA-Analysis considers problems arising from concurrency as a possible factor leading to a UCA, especially for the Sequence/Order category.

5. Devise Controller (Functional) Constraints

Devise Constraints from the UCA results: falsifiable statements about an element of the Control Structure that must be satisfied in order to prevent or avoid each of the UCA.

• Work through the UCA table to consider each UCA in turn
• The generated constraint text and WHEN-type statement are a prompt that should be used to suggest a more meaningful constraint statement.
• Devise (or identify an existing) Constraint (or Constraints) that either achieves the constraint prompt objective, or provides a mitigation
• Record these in the Constraints table, with a type of CFC
• Where more than one Constraint of a given type is needed to address a UCA or Causal Scenario, define a 'parent' constraint (e.g. CFC-3) and group the sub-constraints under it (e.g. CFC-3.1, CFC-3.2 etc).

Review criteria

• Each row in the UCA table links to a corresponding CFC constraint
• The Constraint text meets the following criteria:
  • Communicates what needs to be true in order to avoid a negative outcome, rather than how that is to be accomplished.
  • Uses the indicative mood, rather than the imperative mood.
  • Uses the same context and terminology as the associated UCA.

6. Identify Control Loops and Sequences

These are groups of control actions and feedback that inform or trigger one another, and which realise a discrete set of behaviour associated with a particular feedback control loop.

• Add loops to the Control-Loops table
  • Each control loop should have a description to make its role clear
  • What is the controlled process?
  • How and why does the loop control it?
  • What are the associated SLC?
• Add steps for each of the loops in the CL-Sequences table
  • Select the interaction id for each step in a loop sequence
  • Interactions may be control actions, feedback, or interactions as all are relevant
  • Interactions may be included in more than one Control Loop
    • This is a factor to consider as part of Causal Scenario Analysis for the repeated Interactions, as it may lead to conflicting, unintended or out of sequence interactions
• Record for each step (or N/A with an justification):
  • Provider Process Model or state: What information does the Provider use to inform this interaction? If the provider is a Controlled process providing feedback, then this will be its state.
  • Provider logic: What logic does the provider use to determine when to to provide the interaction, and what to provide? What interfaces are used to provide the Control Action or Feedback. What protocols and/or lower-level components are involved in the Control Path or the Feedback Path?
  • Target behaviour: What is the Target expected to do as a result of the provided interaction
• Note that provider logic may be very simple ("Return from a Control Action").

Review criteria

• Each Control Loop has a description, which identifies:
  • The controlled process involved
  • The overall objective(s) of the control mechanisms
• Each Control Loop is linked to a SLC
• Each row in the Interactions table is linked to at least one row in the CL-Sequences table
• Each CL-Sequence row documents Provider Process model, Provider Logic, and Expected target behaviour, or N/A with a note justifying why this is not applicable.
• Provider Logic clearly identifies the interfaces, protocols and/or components involved in providing and communicating the Interaction.

7. Identify Causal Scenarios

Identify Causal Scenarios (factors that can lead to Unsafe Control Actions, or directly to Hazards)

• Use the Control Loops to identify Causal Scenarios
• For each control loop step, add a full set of rows in the Causal-Scenarios table for the defined set of CSTypes
  • Note: Feedback has different applicable CS types (CS2- and CS4-) to those applicable to Control Actions (CS1-, CS3-, CS4-)
  • Where the CS Type is not applicable, the CS Result should be set to N/A
• For each step/type pair that is applicable, write a description of how this step might lead to either a UCA or Hazard in the Causal Scenario Definition column. Include examples or clarifying notes in the Notes column.
• Identify which UCAs or which Hazards may result

Review criteria

• Each CL-Sequence row is linked to at least one set of Scenarios rows
• Each set of Scenarios rows includes all 15 of the CSType categories, with a Result from the CSResults table
• Each applicable Scenario row includes a Causal Scenario Definition
• Clarifying examples and/or notes are recorded in the Notes column as required.
• Each applicable Scenario row is linked to at least one UCA or Hazard.
• Scenarios involving Interactions consider the role of the interfaces, protocols and/or components used to provide or communicate the Control Action or Feedback.
• Scenarios involving Conflicting Control and Controller or Process Disturbance consider whether there is sufficient isolation between potential interfering elements.
• Scenarios consider reasonably foreseeable misuse of the system as a possible causal factor for unintended actions or feedback.

8. Devise Causal Scenario Constraints

• Devise (or identify an existing) Constraint (or Constraints) that either prevents or avoids this scenario, or provides a mitigation
  • Add new items to the Constraints table with a type of CSC
  • Link them to the Scenario(s)
  • If linking to a CFC type Constraint, add an explanation to justify how and why the Constraint addresses the Causal Scenario to its Notes column

Review criteria

• Each Causal-Scenario row is linked to at least one CSC of CFC Constraint
  • If a CFC Constraint, the Scenarios Notes column justifies how and why the CFC Constraint addresses the Causal Scenario
• New Constraints have a type of CSC and are linked to the associated Causal Scenario(s)
• Constraint text meets the following criteria:
  • Communicate what needs to be true in order to avoid a negative outcome, rather than how that is to be accomplished.
  • Use the indicative mood, rather than the imperative mood.
  • Use the same terminology as the associated Causal Scenario, UCA and/or Hazards.

9. Specify Misbehaviours and Expectations

Based on the results of the analysis, devise and specify:

• Misbehaviours identified or considered in the Causal Scenario analysis
  • These identify a class of fault, failure mode or other misbehaviour involving the SUA that can lead to a UCA or a Hazard as part of a Causal Scenario
  • These are a prompts for Fault Inductions
  • When we find an issue through testing, it should be compared to this list, to see if it defines a new class of Misbehaviour
    • If so, then the STPA should be revisited
• Expectations for the SUA where it is responsible for preventing or mitigating a risk (Hazard, UCA or Causal Scenario) or Misbehaviour
  • These might be directly provided by Constraints
  • Constraints might need to be decomposed into a set of Expectations, or rewritten to reflect specific system components names instead of the element names used in the Control Structure.
  • Expectations may cover all, or part of, more than one Constraint
• Assumptions for other elements of a system, or for integrators or designers of a system incorporating the SUA, where these are responsible for preventing or mitigating a risk or misbehaviour
  • Again these might be directly provided by Constraints, or require some decomposition or aggregation

Review criteria

• Misbehaviours are recorded in artifacts under change control
  • Recorded Misbehaviours include references linking them to the corresponding STPA result artifacts (UCA, Causal Scenarios)
• Expectations are recorded in artifacts under change control
  • Recorded expectations include references linking them to the corresponding STPA result artifacts (Constraints)
• Assumptions are recorded in artifacts
  • Recorded expectations include references linking them to the corresponding STPA result artifacts (Constraints)

10. Review STPA results

• Review your own analysis results and extend or clarify where appropriate.
  • e.g. New SLC may be suggested by the defined Constraints, Expectations or Assumptions, and re-considering the CA-Analysis in the light of these new SLC may identify new UCA
• Have an independent STPA practitioner review the analysis results.
  • Verifies that the process was followed correctly and the results were recorded coherently.
  • Checks the recorded results using the Review criteria in the step and the guidance from the Glossary.
• Have an independent subject matter expert review the analysis results.
  • Verifies that the technical inputs to the process are appropriate, clearly described, and sufficient.
  • Verifies that the process resulted in appropriate, coherent, applicable outputs (Step 9).

Review criteria

• Analyst review findings are documented
• Independent STPA practitioner review findings are documented
• Independent SME review findings are documented