Updated approach

Signed-off-by: Paul Albertella <[email protected]>

approach.md

@@ -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?