From 12bc5162685db1468d50b608327969d72fead2c3 Mon Sep 17 00:00:00 2001 From: Paul Albertella Date: Thu, 28 Oct 2021 13:44:10 +0100 Subject: [PATCH 1/4] Draft of proposed approach Signed-off-by: Paul Albertella --- approach.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 approach.md diff --git a/approach.md b/approach.md new file mode 100644 index 0000000..5502edf --- /dev/null +++ b/approach.md @@ -0,0 +1,25 @@ +# OSEP proposed approach + +a) Identify and document system scope, losses and hazards + +* *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! + +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 + +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? + +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 + +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? From b9927122aa3e1f716b08a1bcf7b4114956bc0af2 Mon Sep 17 00:00:00 2001 From: Paul Albertella Date: Wed, 10 Nov 2021 17:26:42 +0000 Subject: [PATCH 2/4] Updated approach Signed-off-by: Paul Albertella --- approach.md | 67 ++++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 51 insertions(+), 16 deletions(-) diff --git a/approach.md b/approach.md index 5502edf..fa9c760 100644 --- a/approach.md +++ b/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? From ac1674392d48bbb46d129c6780f12d6c70687be3 Mon Sep 17 00:00:00 2001 From: Paul Albertella Date: Thu, 30 Jun 2022 11:24:27 +0100 Subject: [PATCH 3/4] Add framework description - Based on Eli Hibshoosh's slides Signed-off-by: Paul Albertella --- framework.md | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 framework.md diff --git a/framework.md b/framework.md new file mode 100644 index 0000000..7926c22 --- /dev/null +++ b/framework.md @@ -0,0 +1,38 @@ +# ELISA Safety Study Framework + +This document describes the motivation, objectives and underlying assumptions +for the Linux- and safety-related studies undertaken and published by the +ELISA project, and proposes + +## Motivation + +* Organisations seek guidance on achieving their safety goals and facilitating safety certification for systems that involve Linux + +## Objectives + +* To provide a framework for the specification and analysis of Linux-based + systems in the context of a project employing safety-relevant applications +* To undertake and document safety and systems analysis and prototyping for specific functionality and safety-related use cases, to illustrate how this framework may be applied + +## Framework Inputs + +Organisations using the proposed framework must necessarily provide the +following inputs, as these are context-specific. + +* Project definition + - What is the purpose of the system using Linux and what role does Linux + (or applications depending on Linux) play in that system? +* Project Context + - System specification, including high-level system architecture +* Target standard for compliance + - e.g. ISO 26262:2018 +* Execution environment + - Other system components or inputs that inform the execution environment + for applications that depend on the Linux implementation +* Safety Concept + – Safety goals for the target system, and strategies or solutions to be + provided by other processes, or components of the target system + +For ELISA's illustrative examples, we will document our assumptions about these +inputs, to help organisations to understand how they may apply to their own +target context. From ccb662a51421d62ab0e4d9dacebe303972dc854e Mon Sep 17 00:00:00 2001 From: Paul Albertella Date: Thu, 30 Jun 2022 11:25:57 +0100 Subject: [PATCH 4/4] Update OSEP approach - Base don review comments from Safety Architecture WG Signed-off-by: Paul Albertella --- approach.md | 66 ++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 47 insertions(+), 19 deletions(-) diff --git a/approach.md b/approach.md index fa9c760..ee58c64 100644 --- a/approach.md +++ b/approach.md @@ -1,35 +1,61 @@ # OSEP proposed approach -a) Document scope of analysis using STPA +This document proposes an approach to the [framework](framework.md)) using STPA. -*In collaboration with other WGs e.g. Automotive?* +## 1) Document scope of analysis -* Assumed system context - - Hardware features, role of OS, boundaries of analysis, etc - - Doesn't have to be concrete / complex +*With inputs from other WGs* + +a) Specify the topic that will be the focus of analysis + +* What specific functionality are we going to focus on? +* What is the *system under analysis (SUA)*? + - This could be a complete hardware-software stack or a specific subsystem +* What are our assumptions about the SUA's *environment*? + - Environment means the context within which the SUA will operate + - This is likely to include a larger system that includes the *SUA* as a component or element + - These assumptions do *not* need to be comprehensive, as we will identify more during analysis +* What safety-related goals do we have for the *SUA*? + - How might the *SUA* contribute to the safety goals of the larger system? + - e.g. is it used to implement a safety mechanism? + - What must the *SUA* avoid doing in order to support those goals? + +b) Document the scope of analysis and top-level goals using STPA + +* System boundaries and inputs/outputs + - What boundary defines the *SUA*? + - What does it interact with outside this boundary? + - e.g. hardware components + - Does not have to be concrete or complex - Specific to topic: start simple and elaborate later! * Losses - - OS-related outcomes that *may* violate a system's safety goals + - Outcomes that *may* violate the *SUA*'s goals - i.e. lead to harm in a safety-related system + - Can also include outcomes that may violate non-safety goals + - e.g. customer dissatisfaction * Hazards - - OS-level system conditions that *may* lead to these losses + - 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 + - Can include non-safety criteria (e.g. relating to performance or reliability) -b) Identify and document system measures and mitigations for Linux +## 2) Document system architecture -*Out of scope for OSEP - LFSCS group?* +*In collaboration with LFSCS and Safety Architecture WGs* -* Provided by kernel features, compiler, hardware, etc -* Find supporting evidence (design, tests, processes) for these -* Identify responsibilities of components (kernel, compiler, etc) +Can include known measures and mitigations for Linux -c) Perform hazard and risk analysis using STPA - *In collaboration with LFSCS and Safety Architecture WGs?* +* Identify responsibilities of components (kernel, compiler, kernel subsystem, etc) -* Based on inputs from (a) and (b) + +## 3) Perform hazard and risk analysis + + *In collaboration with Safety Architecture WG* + +* Based on inputs from (1) and (2) * Document control structure(s) for topic - Identify controllers and responsibilities - Functional abstraction of system elements @@ -38,7 +64,7 @@ c) Perform hazard and risk analysis using STPA - Identify Unsafe Control Actions and Loss Scenarios - Define Controller Constraints -d) Identify and document process measures and mitigations +## 4) Identify and document process measures and mitigations * Identify engineering practices and tools to: - Implement constraints from (a) and (c) @@ -49,11 +75,13 @@ d) Identify and document process measures and mitigations * Find supporting evidence from FOSS communities - Formal, verifiable process or inconsistent practice? -e) Identify and document claims and use cases +## 5) Identify and document claims and use cases + + *In collaboration with other WGs* -* To illustrate how a+b+c+d might support an in-context safety argument +* To illustrate how (1)+(2)+(3)+(4) might support an in-context safety argument * Evidence needed to support claims - - How can other organisations use (d) to provide confidence? + - How can other organisations use (4) to provide confidence? - What criteria does evidence need to satisfy? * Document use cases - In collaboration with Domain WGs?