RAFIA STPA glossary

This glossary provides definitions and guidance for the key concepts in System Theoretic Process Analysis (STPA) as applied in the accompanying procedure.

Note that RAFIA's use of STPA is specifically focussed on its application for software systems; refer to the works in References section for more general, system-oriented guidance.

References

RAFIA-specific terms

Software under analysis (SUA)

The software under analysis (SUA) is the software project, product or component that is the focus of the team or organisation applying RAFIA. This is normally analogous to the XYZ placeholder (metasyntactic variable) used by the Eclipse Trustable Software Framework.

Element

An Element is a component, subsystem or collaborating set of components in a System, which has an identifiable purpose within that system. STPA principally deals with those Elements that have a Controller or Controlled Process role, but it can also be useful to consider Elements that have neither of these roles, or both, as part of the analysis.

Scope of analysis

The scope of a given analysis using STPA is defined by the System that will be analysed, as delineated by a boundary (or boundaries) that divide or distinguish it from its Environment.

System

from STPA Handbook

A system is a set of components that act together as a whole to achieve some common goal, objective, or end. A system may contain subsystems and may also be part of a larger system

The System is an Abstraction that defines the scope of our analysis. It must, by definition, have a purpose or set of goals.

A System is defined by a Boundary and may have inputs and outputs that cross this boundary. Factors that are external to the system, but which may nevertheless influence its state, are referred to as its Environment.

System boundary

The boundary of the System is an arbitrary construct that we define for the purposes of analysis. It may or may not correspond to a physical boundary, or a concrete separation in a software context (e.g. between process or threads of operation, or between binary components), and may only indicate a division of responsibility.

from STPA Handbook

The most useful way to define the system boundary for analysis purposes is to focus on those parts of the system over which the system designers have some control

Environment

Factors that are external to the System, but which may nevertheless influence its state, are referred to as its Environment. This might be a physical environment (e.g. if the system under analysis is a vehicle), but it can describe anything outside the defined boundary that may nevertheless be relevant to the goals of the System.

For a software component, this might include the processor hardware that it executes upon, or other hardware devices it interacts with, or the operating system software if the system under analysis is an application.

from STPA Handbook

The environment is usually defined as the set of components (and their properties) that are not part of the system but whose behavior can affect the system state.

The concept of an environment implies that there is a boundary between the system and its environment.

Abstraction levels

from STPA Handbook

..When talking about a system, it is always necessary to specify the purpose of the system that is being considered.

A system is an abstraction, that is, a model conceived by the viewer.

The observer may see a different system purpose than the designer or focus on different relevant properties. Specifications, which include the purpose of the system, are critical in system engineering. They ensure consistency of mental models among those designing, using, or viewing a system, and they enhance communication.

STPA involves the use of abstractions, which can be a confusing unless the contributors to an analysis (including later consumers of its results) have a clearly-defined common frame of reference.

The risk of confusion can increase if we refer to 'levels of abstraction', which may refer to different perspectives or focussed analyses within a given abstraction.

For the purposes of RAFIA, we define levels of abstraction in relation to the SUA and the set of Hazards and Losses defined for an analysis.

The entry level abstraction should be one where the focus is on the role of the SUA as a whole (or Elements representing discrete functional aspects thereof) in a System, with respect to a defined set of Losses and Hazards.
A higher level abstraction is one at which the SUA is not distinguished as an Element, but where it has a defined role or responsibilities as part of one or more Controllers or Controlled Processes.

When a software product or project is the focus of STPA, the Losses defined for an analysis may only have meaning at a higher level of abstraction. This is because software alone does not typically lead to losses; it must necessarily be executed in a given context, and this context may determine the set of applicable Losses.

For example, if the SUA is a software component intended for use in a subsystem of a vehicle, and the Losses relate to safety ("Loss of life or injury to humans"), then the relationship between a software failure or misbehaviour and consequent harm to a human may not be 'visible' at the entry level.

A lower level abstraction is one at which the focus of analysis is on the functionality of a component or a specific aspect of the SUA, rather than the role of the SUA in a system.

Consideration of a lower level abstraction may be valuable as part of Causal Scenario analysis, but this could be conducted using a different form of software, system or safety analysis.

Purpose of analysis

The purpose of a given STPA is defined by a set of Losses and associated Hazards - negative outcomes associated with the System - that the analysts wish to prevent or mitigate. Key outputs of the methodology are a set of Constraints, which describe the conditions that must exist in order to accomplish this goal.

Loss

from STPA Handbook

A loss involves something of value to stakeholders. Losses may include a loss of human life or human injury, property damage, environmental pollution, loss of mission, loss of reputation, loss or leak of sensitive information, or any other loss that is unacceptable to the stakeholders.

Losses represent outcomes that we (or other stakeholders) wish to avoid.

They should be at the highest level of abstraction and focus on the most critical aspects of the System. For safety, these will normally focus on loss of life or human injury, but they may also included losses relating to other system design goals, such as security, performance, reliability or usability.

from STPA Handbook

Example Losses

L-1: Loss of life or injury to people
L-2: Loss of or damage to vehicle
L-3: Loss of or damage to objects outside the vehicle
L-4: Loss of mission (e.g. transportation mission, surveillance mission, scientific mission, defense mission, etc.)
L-5: Loss of customer satisfaction

from STPA Handbook

Tips to prevent common mistakes when identifying losses

Losses should not reference individual components or specific causes
Losses may involve aspects of the Environment over which the system designer or operator has only partial control or no control at all.
You should also document any special considerations or assumptions made, such as losses that are explicitly excluded.

Hazard

from STPA Handbook

A hazard is a system state or set of conditions that, together with a particular set of worst-case environmental conditions, will lead to a loss

Hazards are states or conditions of the System, as opposed to states of the Environment or individual Element failures. These are states or conditions that need to be prevented, not states that the system must normally be in to accomplish its goals.

This does not mean that we can exclude external factors from our analysis; rather, we should focus upon how the System under analysis is involved in managing or controlling the associated risk. Understanding how the System can detect and respond to an external factor may be a key part of this.

If we cannot control or manage a Hazard as the designer or operator of our System, then it may be out of scope for our specific analysis. However:

It is still important to document such Hazards, as the associated risk may need to be managed by some other means
Even if a Hazard cannot be prevented, it may still be possible to reduce the severity of the consequent Loss(es) or the probability of it occurring. (See Mitigation).

It is important not to confuse hazards with failures, or with system functions that have not been implemented as specified. Hazards may result from a failure of a component, or from a flaw in its design or implementation, but they may also arise when all of a system’s components perform exactly as specified.

from STPA Handbook

Examples of system-level hazards

H-1: Aircraft violate minimum separation standards in flight [L-1, L-2, L-4, L-5]
H-2: Aircraft airframe integrity is lost [L-1, L-2, L-4, L-5]
H-3: Aircraft leaves designated taxiway, runway, or apron on ground [L-1, L-2, L-5]
H-4: Aircraft comes too close to other objects on the ground [L-1, L-2, L-5]
H-5: Satellite is unable to collect scientific data [L-4]
H-6: Vehicle does not maintain safe distance from terrain and other obstacles [L-1, L-2, L-3, L-4]
H-7: UAV does not complete surveillance mission [L-4]
H-8: Nuclear power plant releases dangerous materials [L-1, L-4, L-7, L-8]

Hazards are not inevitable. There must always be a worst-case environment in which hazards will lead to a Loss, but a given hazard may not necessarily lead to a loss in all cases.

from STPA Handbook

Tips to prevent common mistakes when identifying hazards

Should not refer to individual components of the system: all hazards should refer to the overall system and system state
Must be traceable to one or more losses
Should refer to factors that can be controlled or managed by the system designers and operators
Should describe system-level conditions to be prevented, not failures or deviations from specified system functions
The number of hazards should be relatively small, usually no more than 7 to 10
Should not include ambiguous or recursive words like "unsafe", "unintended", "accidental", etc.

Sub-hazards

System-level Hazards can also be refined into sub-hazards for more complex Systems, which may be helpful when identifying more granular System Level Constraints, or to guide the definition and allocation of Controller Responsibilities in the Control Structure.

from STPA Handbook

Example sub-hazards

Sub-hazards derived from H-4	Example constraints
H-4.1: Deceleration is insufficient upon landing, rejected takeoff, or during taxiing	SC-6.1: Deceleration must occur within TBD seconds of landing or rejected takeoff at a rate of at least TBD m/s
H-4.2: Asymmetric deceleration maneuvers aircraft toward other objects	SC-6.2: Asymmetric deceleration must not lead to loss of directional control or cause aircraft to depart taxiway, runway, or apron
H-4.3: Deceleration occurs after V1 point during takeoff	SC-6.3: Deceleration must not be provided after V1 point during takeoff

Constraints

Constraints define conditions that must exist (or be maintained) in order to avoid a Hazard, or to provide a Mitigation when it cannot be avoided. This may mean adding or refining Behaviours to:

Eliminate a Misbehaviour at a system or component design level
Proactively control a Misbehaviour, to avoid the conditions that cause it
Reactively control a Misbehaviour, to avoid its consequences
Proactively or reactively control a Misbehaviour's consequences, to reduce their impact, or delay it long enough for another mitigation to be activated.

Constraints can also specify new or refined development processes, such as:

Using specific tests or types of test to detect Misbehaviours
Using specific analysis methodologies to detect Misbehaviours

More than one Constraint of each type may be defined for a given Misbehaviour. Where more than one Constraint of a given type are 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).

General tips for constraints

A good constraint clearly communicates what needs to be true in order to avoid a negative outcome, rather than how that is to be accomplished.
Avoid using terms like 'must', 'should' or 'shall': use the indicative mood, rather than the imperative mood.
Frame the constraints using the context and the terminology used in the associated Hazards, UCA or Causal Scenarios, and using the element names from the Control Structure

The accompanying procedure defines three different types of constraint:

SLC : System Level Constraints
CFC : Controller (Functional) Constraints
CSC : Causal Scenario Constraints

Note that different sets of constraints may be defined and apply at different Abstraction Levels. If a constraint is difficult to frame in specific terms at the current abstraction level, then that is an indication that further analysis is required at a lower or higher level.

Such analysis at a lower level could involve:

Completing a new STPA with a different control structure and Hazards / Losses
Specifying a set of system use cases for the SUA, to clarify the role(s) it is expected to take
Improving the specification of the SUA, or the other documentation (about components or integrating systems) that is used to inform the analysis (e.g. by adding UML sequence diagrams for specific interactions)
Using the results of Causal Scenario analysis to:
- Direct a design or code analysis of components
- Define a test campaign to determine control or feedback paths
- Confirm predicted misbehaviour (and detection / responses) using stress, soak and fault induction tests
- Add observability or monitoring features to the SUA or an integrating system to gather more information or drive Mitigations

Mitigation

If possible, Constraints should eliminate a risk (Hazard, UCA or Scenario) e.g. by explicitly designing and implementing the system to make it impossible. However, this will not always be feasible, and even if a risk can be realistically 'designed out', STPA directs us to consider worst case scenarios where e.g. the design has not been correctly implemented, or has an undetected flaw.

If a risk cannot be eliminated, then it may be possible to:

proactively control it, to detect conditions that may lead to it, and take actions to avoid the risk manifesting
reactively control it, by detecting when it manifests and taking actions to return the system to a safe state
reduce its impact, by taking actions to limit the negative outcomes

Multiple mitigation strategies may be employed to address a single risk, which can significantly increase overall confidence in the solution or reduce the overall probability of an undetected and/or unmitigated fault. However, each mitigation represents another set of behaviours to analyse, and may introduce new risks.

System Level Constraint (SLC)

from STPA Handbook

A system-level constraint specifies system conditions or behaviors that need to be satisfied to prevent hazards (and ultimately prevent losses)

System-level constraints are the criteria that we use during our analysis to determine whether a given set of conditions can lead to a Hazard.

Note

In some STPA training material, you may see this type of constraint referred to as a High Level Safety Constraint (HLSC).

SLC document the high-level properties that a system must exhibit in order to achieve its goals, whether these relate to safety, security or some other critical objective, as expressed by the Losses and Hazards.

These are not intended to be verifiable requirements: rather, they help us to clearly specify the safety goals for the System as a whole. Violating a system-level constraint is what leads to Hazards. We use them to identify UCAs and Causal Scenarios; from these we derive Controller Constraints and Causal Scenario Constraints which are verifiable, and provide us with the basis for testing and fault injection.

There are two common patterns of SLC:

Specifying how a Hazard may be prevented, by inverting the condition of the hazard
- e.g. "X happens, leading to Y" becomes "X must not happen"
Specifying how the consequences of a Hazard can be reduced, by identifying initiating condition(s) and mitigating action(s)
- e.g. "If hazard occurs, then this mitigating action must occur"

from STPA Handbook

System level constraint examples

Hazard	System-Level Constraint
H-1: Aircraft violate minimum separation standards [L-1, L-2, L-4, L-5]	SC-1: Aircraft must satisfy minimum separation standards from other aircraft and objects [H-1]
H-2: Aircraft airframe integrity is lost [L-1, L-2, L-4, L-5]	SC-2: Aircraft airframe integrity must be maintained under worst-case conditions [H-2]

from STPA Handbook

Tips to avoid common mistakes with system-level constraints

These constraints relate to the system, rather than individual components
Should not specify a particular solution or implementation
Can often be derived by simply inverting the condition of a hazard
Must be traceable to a hazard, but this need not be one-to-one
- A single constraint might be used to prevent more than one hazard
- Multiple constraints may be related to a single hazard
- Each hazard could lead to one or more losses
Subsequent stages of analysis will systematically identify scenarios that can violate these constraints

Controller Constraint

from STPA Handbook

A controller constraint specifies the controller behaviors that need to be satisfied to prevent UCAs

Controller constraints identify the criteria that must be satisfied by a Controller in order for UCA to be avoided. They must always relate to a UCA, and are typically derived by inverting the conditions of the UCA. However, a number of controller constraints may be required to prevent a UCA, or one controller constraint may address several UCAs. They may also be defined to reduce the harmful effects of a UCA that has led to a hazardous condition, or to prevent a UCA identified for another Element.

Be careful not to confuse controller constraints with particular design features or mitigations that the Controller must implement in order to satisfy the constraint. They describe the criteria that must be satisfied, not how or by what means this is to be achieved.

Control Structure

from STPA Handbook

A hierarchical control structure is a system model that is composed of feedback control loops. An effective control structure will enforce constraints on the behavior of the overall system.

We use control structures to model the behaviour of the System under analysis, to help us determine how specific behaviour, in combination with worst-case system and/or environmental conditions, may lead to the violation of one or more System-level Constraints, and potentially lead to Losses.

Control structures contains at least five types of elements:

Controlled Processes
Controllers
Control Actions
Feedback
Other inputs and outputs

A control structure diagram consists of boxes representing Elements (Controllers and Controlled processes), which are arranged in a hierarchy, and directional arrows, representing interactions between Elements (Control Actions, Feedback, Other inputs and outputs).

from STPA Handbook

The vertical axis in a hierarchical control structure is meaningful. It indicates control and authority within the system... Downward arrows represent control actions (commands) while the upward arrows represent feedback

Control structures are an abstraction of the System that we can use to reason about its behaviour.

aviation

This is an example of a control structure from STPA Handbook.

from STPA Handbook

Common points of confusion with control structures

1) A control structure is not a physical model

The hierarchical control structure used in STPA is a functional model, not a physical model like a physical block diagram, a schematic, or a piping and instrumentation diagram.
The connections show information that can be sent, such as commands and feedback — they do not necessarily correspond to physical connections.

2) A control structure is not an executable model

Instead, STPA can be used to carefully derive the necessary behavioral constraints, requirements, and specifications needed enforce the desired system properties.
A control structure does not assume obedience
- Just because a controller sends a control action does not mean that in practice it will always be followed.
- Likewise, just because a feedback path is included in a control structure does not mean that in practice the feedback will always be sent when needed or that it will be accurate.

3) Use abstraction to manage complexity

Control structures use abstraction in several ways to help manage complexity
The principle of abstraction can also be applied to the command and feedback paths in the control structure.
Even if details are known and design decisions have been made, it can be helpful to first apply STPA at a higher abstract level first to provide quicker results and identify broader issues before analyzing more detailed control structure models.

Controlled process

A controlled process is involved in some way in the system state(s) that can lead to Hazards and Losses.

from STPA Handbook

A hazard is defined in terms of the state of the controlled process at the bottom of the figure, e.g., the attitude of the aircraft, the speed of the automobile, the position of the robot. States are made up of components or variables. As the goal of STPA is to identify how the controlled process gets into a hazardous state, then we need to look at the ways the controlled process state can change state.

In more complex systems, there may be controlled processes at higher levels in the hierarchy, or at lower (more detailed) levels of abstraction, which relate to system functions that are indirectly involved in Hazards.

Controller

A controller controls some aspect of a controlled process. In order to do this, it must have:

a goal or goals (responsibilities), which may include maintaining constraints on the behaviour of the controlled process
some way to affect the behaviour of the controlled process, via control actions
a model of the state of the controlled process (process model)
a control algorithm that is used to determine when control actions are required
some source(s) of feedback relating to the controlled process

Note that in some control structures, controllers may represent a human interacting with the system. Where this is the case, concepts such as Control Action,Control Algorithm and Process Model are replaced with equivalents that apply to humans (e.g. expected action, instructions / procedure, mental model).

Control action

Control Actions are interactions that a Controller provides to control the behaviour of a Controlled Process or another controller, in order to meet a defined set of goals. These goals should relate to the System Level Constraints.

"Tips for Control Actions

Do not be tempted to list every possible interaction between elements as a Control Action.
One Control Action may represent a series of software-level operations

Control algorithm

Controllers typically have a control algorithm, which determines the Control Action that they may provide, based on 'beliefs' that the controller has about the state of the Controlled Process, which may be stored in a Process Model and/or informed by Feedback

from STPA Handbook

The automated control algorithm has two primary functions: (1) generate control actions and (2) maintain accurate information (models) about the state of the controlled process and external system components and environment that can impact the generation of control actions.

Feedback

Feedback is information that a Controller needs to help determine when a Control Action is required, either as a direct input to a Control Algorithm, or to inform the controller’s 'beliefs' about a Controlled Process.

Feedback relating to one process may be received indirectly, from other controllers or processes, and may relate to (or be inferred from) the Environment.

"Tips for Feedback

In software, a Control Action frequently has implicit Feedback (e.g. if it is a function call), which means that feedback is not always a discrete signal.
It is best to think about Feedback as the data that a Controller needs in order to correctly perform a Control Action, rather than as a single interaction or communicated 'packet'

from STPA Handbook

Feedback can be derived from the control actions and responsibilities by first identifying the process models that controllers will need to make decisions.

Process model

A process model is an abstraction of the Controller's 'beliefs' about the state of a Process that it is responsible for controlling, which are inputs to its Control Algorithm and may inform the Control Actions that it provides.

This model is based on the feedback that the controller receives and/or historical information that it has stored. Issues with the design, fidelity and/or timely update of this model may be a causal factor for UCA and consequent Hazards.

Other interactions

Controllers and Controlled Processes may also have inputs and outputs that are neither Control Actions nor Feedback, but which may nevertheless be relevant in an analysis (e.g. because they may affect the state of an Element, or its provision of required control actions or feedback).

Controlled Processes in particular will often have inputs and outputs that are not Control Actions or Feedback, but rather aspects of a process that we wish to control.

You may include these as I-type interactions in the Control Structure, as this can be useful as a reminder of possible interference mechanisms between Elements in Step 7

Controller Responsibility

from STPA Handbook

Responsibilities are a refinement of the system-level constraints — what does each entity need to do so that together the system-level constraints will be enforced?

Once Controllers have been identified, these can be assigned responsibilities. These reflect the goal(s) or purpose of the controllers and should relate to the System-level Constraints, and the System role(s) that controllers are required to play in maintaining these constraints.

from STPA Handbook

Tips to prevent common mistakes in a control structure

Ensure labels describe functional information that is sent, not a specific physical implementation.
Avoid ambiguous and vague labels like simply "Command" or "Feedback" when the type of information is known.
Check that every controlled physical process is controlled by one or more controllers (not always required, but often indicates a mistake).
Review responsibilities (including traceability) for conflicts and gaps.
Check that control actions needed to satisfy the responsibilities are included.
Check that feedback needed to satisfy the responsibilities is included. (optional if applied early in concept development when feedback is unknown; later steps can identify missing feedback)

UCA

from STPA Handbook

An Unsafe Control Action (UCA) is a control action that, in a particular context and worst-case environment, will lead to a hazard.

The Handbook describes four ways in which a Control Action can be unsafe:

from STPA Handbook

Categories of Unsafe Control Action

Not providing the control action leads to a hazard
Providing the control action leads to a hazard
Providing a potentially safe control action, but too early, too late, or in the wrong order
The control action lasts too long or is stopped too soon

The Handbook also notes that sub-categories may be distinguished for each category:

from STPA Handbook

Example sub-categories for 'Providing' UCAs

Consider contexts in which the control action may never be safe
Consider contexts in which the control action has an incorrect parameter (e.g. setting an incorrect emergency frequency on a radio)
Consider contexts in which an insufficient or excessive control action may be unsafe (e.g. providing insufficient or excessive braking commands)
Consider contexts in which the direction of the control action may be unsafe (e.g. providing turn left instead of turn right commands)
Consider contexts in which the control action has already been provided (repetitive control actions)

A UCA must have 5 parts:

Part:	source	type	action	context	hazard
Content:	Controller	UCA Type	Control Action	UCA Context	Hazards
Example:	BSCU Autobrake	provides	Brake command	during a normal takeoff	H-4.3

Structuring a UCA so that it includes or references all of these elements makes it clearer and helps to prevent some of the common mistakes summarised below.

from STPA Handbook

Tips to prevent common mistakes when identifying UCAs

Ensure every UCA specifies the context that makes the control action unsafe.
Ensure UCA contexts specify the actual states or conditions that would make the control action unsafe, not potential beliefs about the actual states.
Ensure the UCA contexts are defined clearly.
Ensure the UCA contexts are included and not replaced by future effects or outcomes.
Ensure traceability is documented to link every UCA with one or more hazards.
Review any control action types assumed to be N/A, and verify they are not applicable.
For any continuous control actions with a parameter, ensure that excessive, insufficient, and wrong direction of the parameters are considered.

Ensure any assumptions or special reasoning behind the UCAs are documented

UCA Type

The nine types of UCA used for RAFIA are as follows

Not Provided
Provided
Magnitude (too little)
Magnitude (too much)
Duration (too short)
Duration (too long)
Timing (too early)
Timing (too late)
Sequence / Order

Note that these categories are provided for guidance only and may not apply in all contexts, or to all types of control action.

For example, the Magnitude and Duration categories are relevant for continuous control actions, such as applying pressure to an actuator or emitting a warning tone, but may not apply to discrete ones, such as activating a relay or sending a message.

UCA Context

The context of a UCA describes the actual System conditions that make the Control Action unsafe. A control action may be safe in one context and unsafe in another.

For example, a UCA associated with a rear-facing camera system in a vehicle may only apply while the vehicle is reversing, while another UCA only applies while the vehicle is not reversing.

Causal Scenario

from STPA Handbook

A loss scenario describes the causal factors that can lead to the unsafe control actions and to hazards.

Causal scenarios (which are called loss scenarios in the STPA Handbook) provide more specific context for a UCA or Hazards. UCAs identify the actual system states or conditions that may result to a hazard, but should not attempt to explain the reasons why the associated Control Action is provided, not provided, or provided incorrectly.

The STPA Handbook describes two classes and four types of causal scenario:

a) Scenarios leading to UCAs

Due to unsafe controller behaviour
Due to missing or inadequate feedback or input

b) Scenarios in which control actions are improperly executed or not executed

Involving the control path
Related to the controlled process

These can be further broken down into the following categories:

Controller: Problems with the Controller itself
Control Algorithm: Problems with the logic (specification, design or implementation) of the controller's Control Algorithm
Unsafe Control Input: Problems relating to unsafe control inputs from other controllers, including UCAs
Process Model: Problems with the process model (or mental model) of the controller
Controller Disturbance: Problems arising from other factors that may affect the Controller
Feedback: Problems with the data / information that needs to be communicated
Feedback Path: Problems with the communication / transmission of the data / information
Unsafe Data / Information: Problems with the data / information contributing to the Feedback, which may result from another UCA
Control Action: Problems with the control action itself, including Unsafe / Insecure Control Actions
Control Path: Problems with the communication of the Control Action to its target
Process: Problems with the controlled process itself
Conflicting Control: Interference from other controllers
Process Inputs: Other information or actions which may affect the process
Process Outputs: Other information or actions which may result from the control action or the operation of the Controlled Process
Process Disturbance: Anything else outside the process that may affect it

from STPA Handbook

Common mistakes when identifying Loss Scenarios

The most common mistake is to identify individual causal factors rather than a scenario... The problem with listing individual factors outside the context of a scenario is that it’s easy to overlook how several factors interact with each other, you can overlook non-trivial and non-obvious factors that indirectly lead to UCAs and hazards, and you may not consider how combinations of factors can lead to a hazard. Considering single factors essentially reduces to a FMEA where only single component failures are considered.

Control Path

The control path refers to the means by which a Control Action is communicated from a Controller to a Controlled Process.

Feedback Path

The feedback path refers to the means by which Feedback is communicated from a Controlled Process to a Controller.