Hi Lukas

The second in the dance of the five veils...

We're talking about an Operating System here - and systems developers would never develop an operating system from scratch for their new embedded systems. Not Samsung or LineageOS for mobile phones, for example. Not TP-Link or OpenWRT for routers... They select the operating system flavor and version that best suits them "off the shelf" and integrate it into their products.

I dug out an old illustration of a bog-standard V-model for embedded systems(enclosed). It could have been from a textbook i.e. [1] but it's mostly compatible with the processes envisaged by safety standards. I added the operating system aspects. I'm neglecting the hardware development process here as well.

According to the textbook definition, the operating system-related part of the development process starts at the software architecture phase. The system developer may initially have a set of operating system alternatives to choose from, say an RTOS or Linux or even BSD for all I know. The basic application functionality and its (logical) requirements on the OS are defined in the architecture phase. As processing aspects are considered, specific interfaces to the OS are identified at the technical design stage. Probably at this stage at the latest, the alternatives have been narrowed down to one operating system. Extraneous OS functionality, such as communication stacks or file systems can be eliminated and options can be chosen which defines a specific OS configuration. Code may have to be developed to bring the OS up at run-time.

There are then OS-related aspects to the validation activities which correspond to the various development phases.

==> The system developer selects, configures and tests an operating system: no development is involved, neither by the system developer nor by the operating system supplier, and by extension there is no need for a DIA.

There is of course, the possibility that the system developer needs custom OS functionality, a new feature (or, to use Chris Temple's terminology, a chunk). In which case, if the system developer can afford it, either party can develop the feature or enhancement from scratch. Consider what Google has done with off-tree development of Linux functionality for Android, which they sometimes got retroactively accepted upstream. In this case, Google would be making a DIA with itself: between its Android and Linux organisations, which is foreseen in the definition of a DIA.

While a system developer must choose an operating system from the flavours and versions that are available at the time, what ELISA is actually looking at is the interaction between the user community and the Linux development community. The user community has the possibility to specify its expectations on future operating system development: a DIA for future functionality in general rather than for a specific feature development effort. The operating system developers then have the possibility of considering the needs of the user community when adding or modifying OS features.

Again, this holds for all systems, safety-critical or not. I'll consider safety-critical systems in the next e-mail.

[1] https://www.geeksforgeeks.org/software-engineering-sdlc-v-model/

Mit freundlichen Grüßen / Best regards

John MacGregor

Safety, Security and Privacy (CR/AEX4)
Robert Bosch GmbH | Postfach 10 60 50 | 70049 Stuttgart | GERMANY | www.bosch.com
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