Skip to content

Minutes 28 Mar 2024

Jump to bottom
Paul Albertella edited this page Mar 28, 2024 · 3 revisions

Host: Paul Albertella

Participants: Sebastian Hetze, Igor Stoppa, Florian Wuehr, Pete Brink, Luigi Pellechia

Agenda:

Discussion:

No meeting next week as Paul is on vacation.

Research Report

  • European Railway Undertakings describe a reference architecture (OCORA)
  • Attempt to standardise and achieve vendor independence
  • RTE: Runtime Environment - monolithic, intended to provide functional safety
  • RTE split into safety layer and basic operating system
  • Safety layer SIL4, but OS has no SIL category
  • The OS is implicitly designated as Linux-based, and in use in the field
  • But worth noting that this requires multiple (redundant) instances of the RTE, and voting between diverse (legacy OS instances and legacy apps)
  • Supports Igor’s point about “safety in spite of Linux”
  • Key takeaway: the “Basic OS” (Linux) has no safety requirements, and is intended to be a ‘swappable’ component of the RTE
  • Example of safety, security and availability requirements solved at a broader system level, rather than the individual OS component level

Igor: Strategies for achieving safety and security can be in conflict with each other

Paul: Conflict between safety, security and availability requirements may be inevitable at a component level, but it may be possible to deal with this at a larger system or service level

Sebastian: With this in mind, is a focus on Linux as a component appropriate, or should we be thinking about it as part of a larger system? e.g. what service architecture could we use to deal with issues that are difficult to achieve at an individual system level

Igor: Yes: can problem X at a Linux kernel level be solved by system-level mechanism Y - but are there remaining problems at a Linux level that we cannot solve in this way?

Sebastian: Are there other system architectures that can help to overcome Linux ‘deficiencies’ where Linux has some safety responsibility? Does the diversity requirement in redundant systems also require diverse OS instances?

Sebastian: Do we want to extend the ELISA scope to include more than just the kernel, and are there components of this larger scope that can address some of the issues that we can’t easily address at the kernel level?

Clone this wiki locally