Re: "Pseudo-DIA" between the Linux Kernel Development Community and its Users

John MacGregor <john.macgregor@...>

Hi Lukas,

Most other safety standards (that I deal with at least) don't address the specific problem areas of volume manufacturers who rely on suppliers to supply and/or develop parts of their safety-critical systems. A significant part of the group also doesn't have that background either. That's why I sent the email with the links before the telco.

Simply understanding how a DIA works in a normal supply chain (i.e. without open source) might be a good first step. I mean which divisions of labour (and responsibility) are possible and what the obligations and responsibilities would be for both customer and supplier to achieve a seamless chain of evidence sufficient to satisfy a safety case might be a good first step (although, given my obvious bias, I might also say qualifying for QM rather than satisfying a safety case ;-) )



BTW, if you post the document on the ELISA Tech Google Drive, we could put our comments there as well.

Mit freundlichen Grüßen / Best regards

John MacGregor

Safety, Security and Privacy (CR/AEX4)
Robert Bosch GmbH | Postfach 10 60 50 | 70049 Stuttgart | GERMANY |
Tel. +49 711 811-42995 | Mobil +49 151 543 09433 | John.MacGregor@...

Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar Denner,
Prof. Dr. Stefan Asenkerschbaumer, Dr. Michael Bolle, Dr. Christian Fischer, Dr. Stefan Hartung,
Dr. Markus Heyn, Harald Kröger, Christoph Kübel, Rolf Najork, Uwe Raschke, Peter Tyroller

-----Original Message-----
From: development-process@... <development-
process@...> On Behalf Of Lukas Bulwahn
Sent: Donnerstag, 7. Mai 2020 15:24
To: development-process@...
Subject: Re: [development-process] "Pseudo-DIA" between the Linux Kernel
Development Community and its Users

The quick question after the meeting today:

Where is more explanation needed?

More explanation on the abstract description of the concept of a "Pseudo DIA"
(maybe someone has a better word?)?

Or should I provide some more examples of potential activities, how they may be
described as split between the two organizations, and how the overall argumentation
of fulfilling a procedural requirement can be described in such a way where the
activities are split among Kernel Community and User?

Do you have some specific process step in mind that might serve as a good
example? I am happy to pick those suggestions and try to describe that as a
Pseudo-DIA example.


Join to automatically receive all group messages.