Skip to content

Minutes 02 Nov 2023

Jump to bottom
Paul Albertella edited this page Nov 30, 2023 · 1 revision
  • Host: Paul Albertella
  • Participants: Sebastian Hetze; Igor Stoppa; Raffaele Gianessi, Daniel Krippner

Agenda

  • PiU document
  • Sebastian sharing some material from his project
  • Workshop “next Steps”

Discussion

PiU document

  • ‘Proven in Use’ as a general strategy for justifying the use of Linux in a safety context is problematic, especially in the context of specific clauses in the standards, but:
    • Evidence from use (even in different contexts) might still be part of a justification
    • It may be more reasonable to consider evidence for specific elements of / aspects of Linux in a different
    • There is a wide interest in using Linux in safety, so it may be possible to ‘crowdsource’ the gathering of relevant data

Igor: There are technical issues with this kind of claim, because bugs / weaknesses may not have been exposed in one context and yet be critical in another

Lukas: Two aspects of PiU:

  1. Show that nominal functionality works reliably well
  2. Show that functionality works reliably in the presence of faults
  • We can make an assertion for 1 relatively easily for individual functions of Linux, and support it with field data, but it is much harder for 2.

Sebastian: If this PiU approach has been applied in a context (automotive), is there some kind of precedent about gathering data to confirm its viability?

Lukas: Examples of it in automotive are for relatively simple 16-bit software in a specific context, not for a reusing complex software in different contexts

  • However: Combining argument that software has some level of suitability / reliability for nominal use (1) based on prior use, with other measures (e.g. targeted testing, fault injection) to show that it can also work reliably in the presence of faults (2) may be viable.
  • The problem is with a ‘proven in use’ argument as the only basis for a claim, not with employing ‘evidence from use’ as part of an approach

Daniel: Is there a better term for us to use?

  • Lukas: IEC standard for machinery (15???) includes ‘extensive testing’ as a basis

Sebastian to review the PiU document in light of discussion, to try to arrive at a set of statements that we can agree on.

Comparison / correlation between safety standards

Sebastian shared some material from his current project, mapping equivalent / comparable requirements / clauses in different standards

  • Using Doorstop to link requirements from one safety standard to those in another
  • Provides a way to index between standards, even if you do not have access to them
  • May be valuable for ELISA to have something like this
  • May be possible to generate a summary of the clause(s) using something like ChatGPT, to make it easier to understand if you do not have access to the standards

Paul: There was a previous effort in ELISA to create a standalone reference process summary that mapped to multiple standards (ISO 26262, IEC61508, A-SPICE):

Lukas: Danger that this leads one to build a safety case / argument by showing compliance clause-by-clause. This is not the right approach: aspects of a safety case / argument will relate to a number of different clauses / parts of the standard Standards do not exist to guide your development process, but to guide an evaluation of your development process

Lukas: European research project OPENCOSS was looking at something similar:

Clone this wiki locally