Skip to content

24 Apr 2024

Jump to bottom
Philipp Ahmann edited this page Apr 24, 2024 · 3 revisions

Roll call

* indicates TSC voting members

Host

  • *Philipp Ahmann

Attended this meeting

  • Naresh Ravuri
  • *Alessandro Carminati
  • Pete Brink
  • Olivier Charrier
  • *Kate Stewart
  • *Steve VanderLeest
  • *Paul Albertella
  • Youssef Hajjioui
  • *Sudip Mukherjee
  • JE[A]Y
  • *Matt Kelly

Regrets

Attended recently in the past

  • *Christopher Temple
  • *Lukas Bulwahn
  • Vipul Gupta
  • *Gabriele Paoloni

Topics & Notes

Check past action items

  • Action items in github issues
  • Philipp to check with Eclipse SDV if someone can join the Lund workshop.
  • Philipp to check if someone from ZAL.aero is interested in joining the Lund workshop
    • Reached out to ZAL.aero, waiting for response

June workshop registration and agenda planning

  • Registration is here: https://forms.gle/HV9ciQTcbkSwLZ1BA
  • More information in past TSC meeting minutes.
  • Nearest airport Copenhagen CPH
  • Local transport from Airport to Lund almost every 20 minutes.

WG Coordination

  • Input for discussion: Recently, in the safety arch WG the current asset and coordination between WGs has been quickly discussed. As of now the expectations have been to have the domain specific WGs to define safety requirements for Linux following specific use cases analyses and then having the horizontal WGs (especially Arch, LFSCS and OSEP) to elaborate on specific safety analyses, methodology and technical investigation for Linux to support the allocated safety requirements. However recently the OSEP WGs has been elaborating safety requirements and architectural assumptions that can be used as a baseline for the Arch WG and the LFSCS WG to work on. So in addition to the top-down flow (from domain WGs to Horizontal WGs) we could also discuss a bottom up flow; i.e. domain specific WGs can review such safety requirements/claims in the context of their specific use cases.
  • How to coordinate communication across working groups?
  • LFSCS has not started to evaluate a feature as it needs a system to be analysed.
  • What are the AoU and where should they be made? IS LFSCS a consumer of AoU or are they do it internally on their own?
    • Currently consumption only may not be possible. If own assumptions are made they need to feed back.
    • Where are devices allocated? E.g. is a watchdog internal or external part of the Linux system part?
    • Can we assume a safety island?
  • From use cases group it is discussed what is needed from Linux and more a communication back and forth and not a concrete use case.
    • System is not clearly defined, but more a conversation.
    • Different use cases may create different paradigm on the system.
    • Few example systems may be needed. In aerospace the considered use cases have different system behaviour.
  • Regarding watchdog can we e.g. say, there is a demand to do a reset.
    • What is the role of the watchdog and what requirements does it put on the system.
    • The actual watchdog may be less relevant.
  • Safety analysis approach documented in OSEP: https://github.com/elisa-tech/wg-osep/tree/pa-new-approach/safety-analysis
  • What is the process to feedback in case we demand changes in assumptions?
    • Have common pool of requirements and AoUs documented in BASIL
    • We can refine the requirements, add AoUs or update descriptions based on discoveries from the working groups.
    • There need to be maintainer/moderator/coordinator to check for duplications, conflicts.
      • Note: Also conflicting requirements may be okay, in case their context and usage is different.
    • We can't get there in one step.
  • Coordinating across all working groups and attending all meetings cannot be achieved.
    • All kind of requirements on system, process and other areas can be placed at one place.
    • WG can put their assumptions to move forward to the requirements tool
    • A workshop can be a point to spend dedicated time to align on decisions and assumptions created
      • Agenda prepared by the moderator for the workshop and highlight changes and identify conflicts.
    • Paul will talk about it as a start during Lund workshop to explain what OSEP has done already.
  • Coordinator/moderator could be the TSC co-chair.
  • To start and point to LFSCS request the assumptions need to be documented. These can be wiki, repo in case BASIL is not setup.
    • Igor Stoppa already wrote a document about fundamental assumptions. This can be a good starting point.
    • It is a big document in OSEP repository currently. This can be broken down in requirements in a collaborative space.
    • We can agree and re-check based on these requirements.
    • Requirements are also put on tools.
  • LFSCS is able to start the work
  • LFSCS will start an initial list of requirements and assumptions and after creation push back to other groups.
  • BASIL setup
    • BASIL setup is still in progress. There were some security concerns. This is discussed on the Tools WG
    • BASIL does not work in the way how we did with e.g. codechecker.
    • A subdomain could be an option. After this a separate VM isolated from the host could be setup.

The core parts of the kernel workshop session preps [skipped]

  • Focus topic for next TSC

AoB

Announcements

First half year topics for webinar series

  • Past webinars on website: https://elisa.tech/seminar-series/
  • ASIL-D certified Rust compiler scheduled - May 8th (will be announced after Lukas' webinar)
  • Seminar on Coverage by university Illinois and Boeing (Steve) scheduled - May 22nd
  • stress-ng update -> Kate wants to follow up with Collin King
  • Later during the year:
    • Have something about SOTIF, depending on discussions during June workshop.
    • RT webinar once PREEMPT_RT is fully mainline.
    • ELISA user story by a company.

Upcoming events

  • 22-23 May Lund Linux Con https://lundlinuxcon.org
  • 04-05 Jun ELISA Workshop in Lund (Sweden)
  • 16-18 Sep Open Source Summit Europe in Vienna (Austria)
  • 18-20 Sep Linux Plumbers in Vienna (Austria)
Clone this wiki locally