Apr 28, 2025 ‐ 13:00 UTC - elisa-tech/wg-systems GitHub Wiki

Host:

Philipp Ahmann

Participants:

Troy Sabin
Victor Lu
Daniel Weingaertner
Rinat Shagisultanov

Regrets:

Attended Recently

Nicole Pappler
Walt Miner
Naoto Yamaguchi
Masanori Itoh
Patrick Uven
Sebastian Hetze
Gabriele Paoloni
Leonardo Rossetti
Kate Stewart
Karen Bennet
Slim Dhouibi
Roberto Paccapeli
Steven Carbno
Alfred Strauch
Olivier Charrier

Topics & Notes:

Check past action items

Previous meeting notes: https://github.com/elisa-tech/wg-systems/wiki/Feb-24,-2025-%E2%80%90-16:00-UTC
AI-Sebastian: Involvement of DIN can also be interesting. Sebastian will take a first contact.
- Communication started. Another meeting scheduled in Feb.
AI-Philipp: Get the corrected picture and the content of the press release into the systems WG repo.

Good Quality Practices in Open Source [cont.]

Repo: lighthouse-oss to be created and content to be transferred
So far feel free to comment on https://github.com/elisa-tech/wg-systems/pull/16
Daniel plans to make proposals and Philipp has to review.

Eclipse Process WS infos

Eclipse Process Workshop
Workshop execute on Apr 23rd and 24th.
Major focus was the fit of Trustable (TSF) in the Eclipse Ecosystem
Trustable Software Framework (TSF)
- Focuses on creating evidence and arguments for safety-critical software
- Uses quantitative criteria and scoring system
- Considers security alongside safety
- Currently has 450 claims with equal weighting
- Based on Doorstop and GitLab, with Doorstop being replaced
- https://gitlab.com/CodethinkLabs/trustable/trustable
- Whenever a new version of TSF is released you should re-execute TSF on your SW. (Color coding for score will turn grey)
- TSF is assessed according to IEC 61508 SIL3 (not ISO 26262 yet)
- If you want to try TSF you can execute it on your project to create the score and others can execute on their own and use your score to judge it.
TSF is not enforcing a process, but collects the WHAT evidence and creates a score based on 450 equally weighted claims.
- This is interesting to see, as they are not describing best practices, but apply the process on any form of practice creating artifacts.
TSF tooling is available and will be enhanced further.
Doorstop is used for the requirements, but will be replaced by another "tool" to create enhanced traceability. This tool will also be part of TSF.
TSF will integrate further into the Eclipse Foundation and be relevant to other process areas. It may make badges obsolete.
The workshop focused on aligning various approaches to enable open source software (OSS) in safety-critical systems, with particular attention to:
- Reducing the number of competing initiatives
- Creating trustworthy processes for functional safety (FuSa) development
- Leveraging OSS development models while meeting safety standards
- Identifying overlaps and complementary aspects between existing approaches
Eclipse Functional Safety Process
- This may be discontinued and be consuming concepts from the other initiatives like TSF and S-Core
ThreadX Process remains untouched, but TSF may be executed on ThreadX -> Resulting scoring will be very interesting to see.
- Not sure how open this execution will be. Normally you need to be member of ThreadX which any Eclipse SDV member can be without further charge.
- Alternatively also uProtocol executes and applies TSF. This work is already started by Daniel Krippner.
S-Core
- Complies with Eclipse development processes and enhances it with new roles
- Follows requirements from ASPICE, ISO214343, ISO26262 being currently audited by exida on ISO26262
- TSF may be used to integrate pre-existing OSS into S-Core platform.
Codethink and Exida offer support in applying TSF on Open Source projects.
Key conclusions:
- Process Alignment:
  - TSF could serve as the framework for generic Eclipse safety functionality
  - S-Core will explore adopting TSF
  - The original Eclipse Functional Safety Process may be discontinued
- Badges vs. TSF:
  - Current badge scheme will remain for now until TSF is fully operational
  - Long-term coexistence to be determined based on community needs
  - uProtocol will be a test case for implementing TSF
- Three pillar approach for safety argumentation:
  - Process-based evidence
  - Technical measures/monitoring
  - Statistical models
  - All three should be considered, not just process compliance
- Transparency is Essential:
  - Enables trust verification
  - Reduces reliance on certificates alone
  - Allows assessors to evaluate actual implementation
- Next Steps from workshop:
  - Investigate how S-Core can integrate with TSF
  - Evaluate how TSF can support S-Core for both new and existing OSS components
  - Execute TSF on ThreadX
  - Consider adding ISO 26262 mappings to TSF (similar to IEC 61508)
  - Prepare communication materials (blog post, FAQ)

AoB

no meeting next week due to ELISA WS
Troy will present the cont. compliance architectural draft during meeting May 12th.
Open Eclipse SDV S-Core + Trustable Workshop upfront to ELISA Workshop: https://www.eclipse-foundation.events/event/330e7e66-de49-41f1-98db-7c579c97bd78/home
- Paul Albertella will be in Lund (was not present at WS in Munich) to talk about Trustable (TSF) and Daniel Krippner, who executes TSF on uProtocol