Draft: Recommended approaches and rationale#59
Conversation
|
A preview of 914c89e is here: |
Signed-off-by: Paul Albertella <paul.albertella@codethink.co.uk>
7900a31 to
914c89e
Compare
reiterative
left a comment
reiterative
left a comment
There was a problem hiding this comment.
Comments collected in discussions in the OSEP weekly meeting
| This means that _Enabling Linux in Safety Applications_ involves understanding | ||
| the risks that using Linux entails, and then designing system architectures that | ||
| can manage or mitigate those risks, with or without the involvement of Linux | ||
| itself. |
There was a problem hiding this comment.
This requires understanding the system in question from engineering first principles, in order to identify the risks and document how the system is intended to address these.
| source code and configurations (and modification of the associated build files | ||
| and tests), to avoid having to analyse these and their associated risks, and | ||
| having to justify their inclusion in the software subset. | ||
| - Any deficiencies identified by analysis of the chosen Linux version and subset |
There was a problem hiding this comment.
The need to fix any deficiencies that you find is a disincentive if this results in more work for you to do.
| @@ -0,0 +1,115 @@ | |||
| # What approaches do we recommend? | |||
There was a problem hiding this comment.
Lighthouse WG feedback:
- The title should specify the intent of the approach (i.e. approach to do what?)
- Who is "we"
Gab feedback: From my personal standpoint it is possible to fork linux and safety certify it as a SEooC (e.g. see RHIVOS certificates). So at least myself is not part of 'we' in this PR
| @@ -0,0 +1,115 @@ | |||
| # What approaches do we recommend? | |||
|
|
|||
| Our starting position in this working group is that Linux is **not viable as a | |||
There was a problem hiding this comment.
Lighthouse WG feedback: it is better to replace "Linux" with "Vanilla Linux" (i.e. we do not know if some integrators or OEMs have proven in use or SW systematic capability evidences that would be sufficient to do what you recommend not to do)
| based on this unless we used the same version of the software, in the same kind | ||
| of system for the same purpose. | ||
|
|
||
| ## Why not fork Linux and safety certify it? |
There was a problem hiding this comment.
Lighthouse WG Feedback: It should be specified that this remark is valid for the current state of Vanilla Linux, given the technical debt that comes with it. However ELISA is working towards reducing such a debt (e.g. in the Lighthouse WG as well as in the Safety Arch WG as well as in the Tool WG); one of ELISA's goal is to make this easier in the future (so that we do not need to consider architectural decomposition solutions only).
| - Maintaining such a codebase would be an ongoing commitment for the lifetime of | ||
| any products making use of the special Linux | ||
|
|
||
| ## Why not show that Linux is safe by testing it thoroughly? |
There was a problem hiding this comment.
Lighthouse WG feedback: The point here should be that increased testing is not sufficient if it is not traced to corresponding safety claims, safety requirements and safety scope of the code being tested and supported by a solid verification strategy.
This is quite a complex problem that cannot be summarised by a statement like <<All such measures have a dependency on specified requirements for the software, the system(s) within which it is intended to operate, and the safety-related functions that the system(s) must provide.>>.
So it is a good start but it should be structured better (maybe with some examples about what testing-only can lead to)
2 participants
Write up recommended approaches and rationale based on workshop presentation and previous discussions