The Open-Source Engineering Process WG examines how software engineering processes can be used to facilitate the certification of safety-critical systems incorporating Linux and other FOSS.
Other
11
stars
8
forks
source link
Agree and document overall engineering approach to safety for Linux #34
Based on the following notes from discussion between Paul and Igor, document the proposed approach that we have been dicsussing in OSEP and a plan for how to build on and elaborate it in collaboration with the other WGs.
Goal is to have this written up in and shared with other WGs before the next Workshop (4th/5th June), so that we can discuss feedback and next steps at the workshop itself.
Introduction
Observation: many points of view and opinions, often not incompatible,
but applied to different situations and under different circumstances.
Proposed approach
1) Define in an objective way the problem at hand
(i.e. use Linux within safety applications), based on facts that everyone
can independently verify:
- The document about HW (ARM64) and SW (Linux Kernel)
- The document about requirements for FFI and availability
2) Create a rudimentary - but still independently verifiable - syllabus with
a collection of known issues associated to the previous point, and the
condition under which said issues will manifest themselves
(i.e. the KNU, to represent those problems usually ignored/downplayed)
3) Provide guidelines that address the problem for what it really is:
an all-around engineering challenge that must lead to the creation of a
"product" (it doesn't have to be commercial, but it needs to satisfy
functional requirements) that is also compliant with safety goals.
(i.e. the document under review in PR 33)
Goals for ELISA
Describe a long-term, iterative, overall engineering approach to arguing
system safety for systems including a Linux component, with the
following general principles:
Make claims about the safety of the system-including-Linux, rather than
Linux-as-a-component
Identify the risks and limitations that are unavoidable when using
Linux as the basis of an operating system, and system design strategies
for mitigating these (where they exist)
Start with use cases where (for example):
a) Safety requirements are largely or entirely assigned to other
system components
b) Linux is used in a redundant component of a fault-tolerant system
design e.g. using a 2oo3 voting architecture
c) Component failure in the Linux-based component can be detected and
mitigated by other means
Next steps
1) OSEP (Paul) to write up a summary / framing document describing this
approach and linking to the documents contributed by Igor.
2) OSEP to document a 'decision tree' to help guide system designers
planning to use Linux as part of a safety application, identifying both
the risks that are involved (checklist) and approaches for dealing with
these (engineering considerations)
3) Arch WG to follow that process, singling out aspects of Linux that are
the most invariant (or unavoidable), in the sense that they are likely to
be receiving safety requirement whenever a safety goal depends on Linux.
And also identify, for each Linux component, an alternate approach,
e.g. through other HW or some other SW running either on separate systems
or in a different HW mode. (effectively ensuring that the decision tree is
indeed a tree and not a very straight stick)
4) LFSCS WG to do a deep dive into those Linux features identified by the
Arch WG, in practice navigating the tree along the "path of Linux choices"
igor-stoppa
commented
7 months ago
Based on the following notes from discussion between Paul and Igor, document the proposed approach that we have been dicsussing in OSEP and a plan for how to build on and elaborate it in collaboration with the other WGs.
Goal is to have this written up in and shared with other WGs before the next Workshop (4th/5th June), so that we can discuss feedback and next steps at the workshop itself.
Introduction
Observation: many points of view and opinions, often not incompatible, but applied to different situations and under different circumstances.
Proposed approach
1) Define in an objective way the problem at hand (i.e. use Linux within safety applications), based on facts that everyone can independently verify: - The document about HW (ARM64) and SW (Linux Kernel) - The document about requirements for FFI and availability
2) Create a rudimentary - but still independently verifiable - syllabus with a collection of known issues associated to the previous point, and the condition under which said issues will manifest themselves (i.e. the KNU, to represent those problems usually ignored/downplayed)
3) Provide guidelines that address the problem for what it really is: an all-around engineering challenge that must lead to the creation of a "product" (it doesn't have to be commercial, but it needs to satisfy functional requirements) that is also compliant with safety goals. (i.e. the document under review in PR 33)
Goals for ELISA
Describe a long-term, iterative, overall engineering approach to arguing system safety for systems including a Linux component, with the following general principles:
Next steps
1) OSEP (Paul) to write up a summary / framing document describing this approach and linking to the documents contributed by Igor.
2) OSEP to document a 'decision tree' to help guide system designers planning to use Linux as part of a safety application, identifying both the risks that are involved (checklist) and approaches for dealing with these (engineering considerations)
3) Arch WG to follow that process, singling out aspects of Linux that are the most invariant (or unavoidable), in the sense that they are likely to be receiving safety requirement whenever a safety goal depends on Linux. And also identify, for each Linux component, an alternate approach, e.g. through other HW or some other SW running either on separate systems or in a different HW mode. (effectively ensuring that the decision tree is indeed a tree and not a very straight stick)
4) LFSCS WG to do a deep dive into those Linux features identified by the Arch WG, in practice navigating the tree along the "path of Linux choices"