Dec 02, 2024 ‐ 16:00 UTC ‐ Meet Eclipse SDV

Host:

• Philipp Ahmann

Participants:

Regrets:

Attended Recently

• Rinat Shagisultanov
• Gabriele Paoloni
• Sebastian Hetze
• Daniel Weingaertner
• Roberto Paccapeli
• Karen Bennet
• Nicole Pappler
• Alfred Strauch
• Steven Carbno
• Kate Stewart
• Walt Miner
• Thomas Mittelstädt
• Stewart Hildebrand
• Olivier Charrier

Topics & Notes:

Open Source Good Practices Standard and OSS processes supporting safety

• Current ELISA project draft document: https://docs.google.com/document/d/1Uzp4-mAAOd9uMhyKx5Vaa0C8Mq5w1IxhHFAgyE0I9p0
  • 
  • Focus is on Open Source practices to argue QM not on "safety compliant development"
  • Standard is considered as an quality management argumentation for e.g. ISO 26262

Funding for such an activity (like pfp)

• proper grant would need to be identified
• ELISA project is not seeing themselves as participant.
• It needs to align with wider community, so that US or ASIA can also participate.
• Relation to cyber-security may be important beyond safety, as the topic seems relevant for both

Relation between ELISA Systems WG and Eclipse SDV Automotive Process SIG

• Eclipse SDV:
  • Eclipse SDV Automotive Process SIG Meetings: https://gitlab.eclipse.org/eclipse-wg/sdv-wg/sdv-sig-automotivegradeos/meetings/-/blob/main/MeetingNotes.md?ref_type=heads
  • Recently Safety process was presented.
  • Eclipse Foundation Functional Safety Process (EFFSP) is in draft phase
    • Scope: building software compliant to e.g. IEC 61508, IEC 62304, ISO 26262, EN 50128)
    • Builds on Top of Eclipse Foundation Development Process https://www.eclipse.org/projects/handbook/#edp
  • Eclipse Functional Safety Project (FSP)
    • Practices that ensure consistency, completeness, durability, traceability
    • Requirements management
    • First thoughts (trace requirements in git message) differs from first ELISA discussion
      • hard to cover pre-existing code, which already has commits. Benefit of cross repo work.
  • Safety Manual in access restricted environment
  • Badges are proposed, where ELISA was not considering this so far.
• ELISA project
  • cross location requirements are not yet considered in draft.
  • SPDX-REQ as identifier for requirements
  • No safety manual from ELISA
  • Tools (like BASIL which was introduced to Eclipse SDV) are delivered by ELISA
  • Focus a lot on Linux Kernel and user space (not application)

(Eventually: S-CORE middleware stack and AGL to create a CI system including SBOM creation)

• Webpage published: https://eclipse-score.github.io/
• Would SCORE be something to put on top of ELISA work? The architecture looks like this.
• MVP phase (until b/o 2025):
  • "establish a working infrastructure, that enables every developer of the project to specify requirements and architecture, implement code and test it accordingly."
  • "set-up project structure, that covers all aspects of the open source software development including cooperation between developers and teams, planning, creation of the roadmaps and coordination meetings."
  • "define a software development process compliant to ISO 26262:2018, that is a prerequisite for any other software development in the project."
• Should we take another follow up on this with the SCORE people?

If time allows: Analysis on ISO26262 and how it can or cannot be applied to the Linux Kernel

• Trying to apply and enforce ISO 26262 demands on a Linux kernel will not work 1:1.
• ELISA worked on mapping and comparison.
• Resulting observations may also go into "good practices" document.

AoB

• ...