Dec 02, 2024 ‐ 16:00 UTC ‐ Meet Eclipse SDV
Host:
- Philipp Ahmann
Participants:
- Ansgar Lindwedel
- Dana Vede
- Martin Schleicher
- Daniel Krippner
- Detlef Zerfowski
- Sara Gallian (1st half)
- Leonardo Rossetti
- Sebastian Hetze
- Walt Miner
- Gabriele Paoloni
- Nicole Pappler
- Karen Bennet
- Andreas Bartelt
- Daniel Weingaertner (2nd half)
Regrets:
Attended Recently
- Rinat Shagisultanov
- Gabriele Paoloni
- Roberto Paccapeli
- Alfred Strauch
- Steven Carbno
- Kate Stewart
- Thomas Mittelstädt
- Stewart Hildebrand
- Olivier Charrier
- 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
- 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
- VDA sessions and in Eclipse
- pushing hard to get people in.
- distributor like in a core stack need to feed back.
- Get an overview what is there and what is needed. And reach out to companies after this!
- This is what ELISA currently prepares: Goal, work packages and effort.
- Most members in the work group are there to learn and are not yet in a stage to contribute.
- Big gap by the companies how to contribute and deal ACTIVELY with open source (beyond consumption).
-
Can we put it somewhere into existing projects HAL4SDV and SHIFT2SDV as the topic fits to their goals?
- Take this also into VDA.
- Go directly to HAL4SDV and FEDERATE.
- 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.
- **First draft ** Eclipse Foundation Functional Safety Process (EFFSP) is in preparation -> tailored for ThreadX, so improve to fit more SDV projects.
- 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)
- Meeting discussion
- Coming with one voice to not bringing many requests to the open source communities.
- Generated development artifacts are important to consider.
- Quality badges: What kind of artifacts and to what level do they exist. Badges can support here.
- Not a process, but what kind of artifacts and what kind of quality do the projects have.
- Some parts are automated, some remain manual (based on reviewing).
- Criteria for badges relate to implementation of SDV development process taken by 6 projects so far.
- Improve adoption and improve collaboration among projects. -> E.g. offer skills I have to improve open points. Better project planning.
- Aligning goals?! -> Would this be own work products or joint results.
- If we simply try to follow the standard and apply it to Open Source, we will fail.
- Many from OSS may not even understand the reason why these standards exist and ask for what they asking for
- How can we fulfill the intention of the standards in a different manner.
- Address the needs of the standards, but not the formalities.
- Two scenarios: Existing software and newly written software in open source.
- A lot of work in automotive is still done manually, and here OSS best practices can apply also to manual parts of Automotive development.
- ISO PAS 8926 already describes a path towards qualification of pre-existing software (but not its modification).
- Maybe in future there is not a strong difference between open and closed software development.
- There is processes and implementing these processes with all the details.
- What to actually do is the idea of the process SIG
- The "how" is what ELISA is looking into mainly today to check and write down the specification to come to a what
- Check also the objectives of quality and find evidences that the quality objectives are met by OSS process implementation (tools).
- Check also robotics industry. Can we take lessons learnt from them?!
- How to align -> We need to synchronize!
- Requires also the closer connect to the badge program?
- This should be on operational level. Not another "management meeting".
- Both initiatives serve the same industry.
- The scopes slightly differ with what and how.
- We should take care that we do not throw things to developers that puts double efforts in different ways of doing it.
- Not giving more work to developers means: "We use existing practices and give this information to project as it exists
- Exchange on that level: This comes out of one initiative, this comes out of the other. This is how we not confuse developers.
- Keep a smaller alignment round once a month maybe to keep everybody synced.
- 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.
- Tried to reverse engineer the development process from ISO 26262 part 6. This was not fitting.
- Alsp part 8 clause 12 does not fit to the Linux Kernel.
- Last part is that there is no formal requirements driven process in the Linux kernel
- This was driver for the idea of a good practices in open source and later derive the application to safety.
- Here we want to align, if this fits to Eclipse SDV view
- 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?
- ...