Skip to content

Commit

Permalink
Updated approach
Browse files Browse the repository at this point in the history
Signed-off-by: Paul Albertella <[email protected]>
  • Loading branch information
reiterative committed Jan 13, 2022
1 parent 12bc516 commit b992712
Showing 1 changed file with 51 additions and 16 deletions.
67 changes: 51 additions & 16 deletions approach.md
Original file line number Diff line number Diff line change
@@ -1,25 +1,60 @@
# OSEP proposed approach

a) Identify and document system scope, losses and hazards
a) Document scope of analysis using STPA

* *Assumed* system context, boundaries of analysis, role of OS, etc
* OS-level losses/hazards that *may* violate a system's safety goals
* Specific to the topic: start simple and elaborate later!
*In collaboration with other WGs e.g. Automotive?*

b) Identify and document constraints and mitigations
* Constraints: Criteria that must be satisfied to *prevent* hazard
* Mitigations: To reduce *impact* of hazards that are not prevented
* Assumed system context
- Hardware features, role of OS, boundaries of analysis, etc
- Doesn't have to be concrete / complex
- Specific to topic: start simple and elaborate later!
* Losses
- OS-related outcomes that *may* violate a system's safety goals
- i.e. lead to harm in a safety-related system
* Hazards
- OS-level system conditions that *may* lead to these losses
* System-level constraints
- Criteria that must be satisfied to *prevent* or *mitigate* hazards
- May be a simple inversion of the hazard

c) Identify and document kernel features or external mechanisms
* To implement OS- or system-level constraints and mitigations
* To be identified and/or investigated by other WGs?
b) Identify and document system measures and mitigations for Linux

d) Investigate and document processes and tools to:
* Implement constraints or mitigations via engineering processes
* Verify constraints and mitigations (at all levels)
* Validate constraints, mitigations & verification measures in-context
* Identify or provide other evidence to support claims
*Out of scope for OSEP - LFSCS group?*

* Provided by kernel features, compiler, hardware, etc
* Find supporting evidence (design, tests, processes) for these
* Identify responsibilities of components (kernel, compiler, etc)

c) Perform hazard and risk analysis using STPA

*In collaboration with LFSCS and Safety Architecture WGs?*

* Based on inputs from (a) and (b)
* Document control structure(s) for topic
- Identify controllers and responsibilities
- Functional abstraction of system elements
- e.g. Kernel or subsystems, complier, other tools, etc
- Define interactions as control actions and feedback
- Identify Unsafe Control Actions and Loss Scenarios
- Define Controller Constraints

d) Identify and document process measures and mitigations

* Identify engineering practices and tools to:
- Implement constraints from (a) and (c)
- Verify constraints from (a) and (c)
- Evaluate and/or increase confidence in (b)
- Identify or provide other evidence to support claims
- e.g. Quality criteria
* Find supporting evidence from FOSS communities
- Formal, verifiable process or inconsistent practice?

e) Identify and document claims and use cases

* To illustrate how a+b+c+d might support an in-context safety argument
* Use cases with kernel config(s) and hardware / system dependencies?
* Evidence needed to support claims
- How can other organisations use (d) to provide confidence?
- What criteria does evidence need to satisfy?
* Document use cases
- In collaboration with Domain WGs?
- With kernel config(s) and hardware / system dependencies?

0 comments on commit b992712

Please sign in to comment.