Minutes 11 Apr 2024

Host: Paul Albertella

Participants: Florian Wuehr, Igor Stoppa, Pete Brink, Sebastian Hetze, Gabriele Paoloni, Daniel Weingaertner, Mikel Azkarate

Agenda:

• ELISA Workshop - OSEP session topic
• "Using Linux in a Safe System" PR
• Defining 'core' parts or functions of Linux?
• Process and criteria for adopting contributed content

Discussion

Mikel from Canonical joining for second time - learning about WGs

Framing the approach:

• “Safe in spite of Linux”
• System-level safety
• Safety of the application, rather than the OS
• The context within which a device with a safety requirements operates can strongly affect the requirements assigned to an individual component of a system
  • e.g. Physical measures (a cage around a robotic arm)

Difference between a) Linux as part of an application with safety implications, as opposed to b) Linux as part of the implementation of a safety mechanism

• Expectation in ELISA has been focussing on b) rather than a).

Igor: Start from something simple, that you can validate e.g. Linux without an explicit safety role, and then build on this to understand the implications of adding safety responsibilities

Gab: Don’t see too much value with starting with no safety requirements allocated to Linux, but starting with a simple use case makes sense

Paul: Could we consider a use case with an (user space) application running on Linux, where the safety requirements are all on the application

• Could have only limited responsibilities as an OS and assign the safety requirements to an external mechanism (watchdog)
• Or with a system design based on the example shared by Sebastian

Igor: Rather than identifying the core parts of Linux, identify the functions it provides that we cannot avoid relying on, but which cannot easily be mitigated by external mechanisms

• Understand how the kernel can interfere with your safety-related applications, and what measures you can use to e.g. protecting from stack overflows
• Places the responsibility on the safe system designer

Gab: How can we assign different roles to WGs within ELISA?

Igor's proposal:

What I would propose is more like to define a sort of "decision tree" or decision process, that might guide a system designer in choosing how to allocate requirements to this or that component, and how these decisions would reflect on Linux, involving certain subsystems.

Pete: Danger is that this requires us to accept that a system perspective on safety is the only way to approach the problem. Also means that OSEP as a group needs the expertise to be able to devise and define such a process.

Igor: Also important to understand that there are always costs in dealing with the risks associated with a given product - it may be less costly to solve the risks associated with using Linux with an external solution. Need to have an overall framework to describe how we evaluate this kind of system design problem.

Pete: Can be hard for people coming from an application (or non-embedded) context to understand how the system perspective works.

Gab: Need an example to focus our minds

• Use this to help to illustrate the framework

Igor: Hoped that my documents would provide the basis for this

A flowchart or a cheatsheet or a checklist?

• Signposting people to more detailed material and helping them to understand how it is relevant to their goals.