-
Notifications
You must be signed in to change notification settings - Fork 8
STPA Goals and Approach
Paul Albertella edited this page Mar 29, 2023
·
1 revision
What are the goals of using STPA to conduct a safety analysis relating to Linux, and how should we approach it?
Document the assumptions that we are we making about a given system (or class of systems) that may incorporate Linux, and the environment (e.g. the hardware that it executes on, other hardware that it communicates with, and/or the physical environment) within which it operates.
- What is the system?
- An abstraction for the purposes of our analysis
- May be a concrete system, or a class of systems with assumed characteristics
- e.g. An ECU in a vehicle, which provides part of a safety-relevant vehicle function
- What defines its boundary?
- How do we distinguish between the system and its environment?
- What do we assume we can (or cannot) control about the system context?
- What aspects of the environment (i.e. that which is not the system) are relevant to our analysis?
- What information do we need from (or about) our environment in order to prevent harm or manage risks?
- What does our system interact with (provide outputs to and/or receive inputs from)?
What sources and types of harm do we wish to avoid, how might they occur in our context, and what needs to be done to prevent them or to mitigate the associated risks (i.e. reduce the severity or probability of harm)?
- Identify the negative outcomes that we want to avoid (losses)
- May include non-safety losses as well - anything that matters to the stakeholders of a system
- Identify the system and/or environment states or conditions that can lead to these losses (system-level hazards)
- States or conditions that need to be prevented, not states that the system must normally be in to accomplish its goals
- Identify what criteria must be satisfied to prevent or mitigate them (system-level constraints)
- Not a solution or a mechanism: what criteria must hold true if hazards are to be avoided or mitigated?
- Identify the (subset) of functionality provided by Linux (and associated software components) that is pertinent to our safety goals
- How is this functionality involved in achieving those goals
- What responsibilities does Linux have with respect to this functionality?
- What responsibilities do we assume (other components have with respect to this functionality?
- Define safety requirements for Linux and for other components of the system
- Criteria that must hold true for individual components with safety-relevant responsibilities (controller constraints)