Architecture Community F2F Workshop [2025-11-04 - 2025-11-06]

[qor-lb]

Important

Agenda Finalized

Location

• Location: Mercedes-Benz Tech Innovation GmbH, Wilhelm-Runge-Straße 11, 89081 Ulm, Germany
• Online: Teams Meeting

Participants

All in person attendees, please send participant details (first name, last name, company, company address (street, number, city, postcode)) directly to Leo Hnatek ([email protected]) for registration and access to the premises/building. After your participant details have been received, we will update the list here to reflect the registered status. The deadline for registration is 29th October.

• Zoran Cutura (ETAS)
• Andreas Thums (ETAS)
• Arvid Sievert (ETAS)
• Andreas Mittag (ETAS)
• Nicolas Fussberger (ETAS)
• Shady Mohamed (ETAS)
• Michael Tänzer (ETAS)
• Oliver Heilwagen (ETAS)
• Mike Haller (ETAS)
• Ulrich Freund (Bosch)
• Christian Heissenberger (Eclipse)
• Ian McLeod (RedHat)
• Michael Engel (RedHat)
• Leonardo Rossetti (RedHat)
• Isabella Stilkerich (Schaeffler)
• Christian Rappl (Schaeffler)
• Oliver Pajonk (Elektrobit)
• Lutz Reinhardt (Elektrobit)
• Daniel Steinke (Aumovio)
• Holger Braun (Aumovio)
• Leo Hnatek (MB)
• Frank Scholter Peres (MB remote)
• Thilo Schmitt (MB)
• Tim Kliefoth (MB)
• Jochen Seemann (MB)
• Markus Braun (MB)
• Stephanie Even (MB remote)
• Mathias Weinmann (MB)
• Karim Wafik (Valeo)
• Artem Mygaiev (EPAM)
• Rafal Brewka (Qorix)
• Adrian Willenbücher (Qorix)
• Vinod Reddy Gopi Reddy (Qorix)
• Nico Hartmann (Qorix)
• Lars Bauhofer (Qorix)
• Jaakko Aho(BMW)
• Andrey Babanin (BMW)
• Stephan Münch (BMW)
• Ulrich Huber (BMW)
• Ankur Sattle (BMW)
• Uwe Maucher (BMW)
• Vadim Selinger (Qualcomm)
• Girish Shirasat (Qualcomm)
• Sanimir Agovic (Liebherr)
• Ramachandran Chakravadhanula (ZF)
• Gerd Schäfer (Accenture)
• Jonas Rummel (IAV Remote)
• Andre Larberg (IAV Remote)

Agenda

• Target: [Contribution Requests] Identify maintainer for the 1.0 (1st round - 4th - 6th Nov 2025) #1571

Breakouts to cover

• Breakout: How to release a module so that it is integrated into a S-CORE release
  • Open Question
    • I-Gate: how is the release process of a module (pipeline & tooling)
    • Managing Changes: how and when is a breaking change planned & aligned (content)
  • internal/external dependencies
  • @qor-lb to clarify with TL circle
• Breakout: Rust approach in the 1.0
• Breakout: Baselib Change Request: Change: add component binary config loader #1935

Day 1 - 9:00 - 18:00

1. 9:00 - 9:30 Welcome & Coffee
2. 9:30 - 12:00 lifecycle & health - @ramceb to detail agenda for lifecycle & health
   1. 9:30 - 9:45 From Qorix : Contribute Health monitoring Lib #1803
   2. 9:45 - 10:00 C++ API mw::lifecycle #1831
   3. 10:00 - 10:15 Lifecycle implementation based on systemd #1832
   4. 10:15 - 10:30 etas: launch_manager and healthmonitor #1903
   5. 10:30 - 10:45 epam: pitch for lifecycle feature #1904
   6. 10:45 - 12:00 Grooming Feature Request for Health & Lifecycle #909
3. 12:00 - 13:00 Lunch break
4. 13:00 - 13:30 Feature Request for Config Management #754 - @michaelsaborov
5. 13:30 - 14:30 BMW proposal for config management #1946
6. 14:30 - 15:30 EPAM pitch for Config Management #1943
7. 15:30 - 16:00 Coffee break
8. 16:00 - 17:00 Grooming Feature Request for Config Management #754

Day 2 - 9:00 - 18:00

1. 9:00 - 9:30 Welcome & Coffee
2. 9:30 - 9:45 Feature Request for ABI compatible datatypes #917 - @awillenbuecher-xq-tec
3. 9:45 - 10:30 Qorix: ABI compatible data types #1919 & Grooming Feature Request for ABI compatible datatypes #917
4. 10:30 - 11:00 Feature Request for SOME/IP Gateway #914 - @ZoranCutura
5. 11:00 - 11:45 [Contribution Proposal] SOME/IP Gateway #1830
6. 11:45 - 13:00 Lunch break
7. 13:00 - 13:45 etas: [Contribution Proposal] SOME/IP Gateway #1906
8. 13:45 - 14:30 Qorix:SOME/IP gateway Proposal #1917
9. 14:30 - 15:30 Grooming Feature Request for SOME/IP Gateway #914
10. 15:30 - 16:00 Coffee break
11. 16:00 - 17:00 Feature Request for Diagnostic Services & Fault Management #911 & OpenSOVD - @timkl7
12. 17:00 - 18:00 Call for Feature Request: IDL & Code Generation - MB TI Feature Request for IDL and Codegeneration #1964

Day 3 - 9:00 - 15:00

1. 9:00 - 9:30 Welcome & Coffee
2. 9:30 - 10:30 Feature Request for Deterministic App Abstraction Layer (DAAL) #864 & MB TI contribution pitch
3. 10:30 - 11:30 Breakouts (Breakout: Baselib Change Request: Change: add component binary config loader #1935)
4. 11:30 - 12:30 Lunch break
5. 12:30 - 14:00 Breakouts (Breakout: Rust approach in the 1.0)
6. 14:00 - 15:00 Wrap-up & Next steps

Meeting Minutes

#1739 (comment)
#1763 (comment)
#1764 (comment)
#1769 (comment)
#1771 (comment)
https://github.com/orgs/eclipse-score/discussions/1922#discussioncomment-14871055
https://github.com/orgs/eclipse-score/discussions/1922#discussioncomment-14891648

[ChristianR9911]

We (Schaeffler) plan to have two people attend the workshop on site and, as mentioned above, have registered.

We look forward to a personal meeting on site.

[odra]

Please include Ian McLeod (@imcleod) from Red Hat

[FScholPer]

Please also add your names to the participant list above or add an comment so that committers can add you

[chheis]

not all can modify the discussion above. @FScholPer Could you please add me as well?

[opajonk]

Please add me as well (I cannot edit the discussion above)

[anmittag]

ETAS has directly contacted @i0b

[bucci-kawabuchi]

From EPAM for the pitches, please include:

onsite - Artem Mygaiev https://github.com/klogg (detail sent to @i0b )
remote - Oleksandr Grytsov https://github.com/al1img

I will join remote if time works for Japan.

[ZoranCutura]

@qor-lb I see you reserved a 30' for SOME/IP Gateway on the second day before the contribution pitches.
The intend is to give a brief overview on the feature request, right? I think we can shorten that to 15', no need to make an exhaustive intro, as most contributors have participated in the earlier discussions. Do you agree?

[qor-lb]

@ZoranCutura yes correct. Fully agree, this is intended as a short recollection of the goals before dive into the pitches. If we need only 15 min then this is great, I am sure we find use of the time later through out the day.

[TomFleischmann]

@FScholPer Can you please as well add from our side Gerd Schäfer?

[FScholPer]

added

[andilar]

Hey @FScholPer

Jonas Rummel (IAV)
Andre Larberg (IAV)

will join remotely, looking forward to it. :)

[FScholPer]

added

[chheis]

Breakout discussion

How to release a module so that it is integrated into a S-CORE release

Preliminary Meeting Minutes
Open Question

• I-Gate: how is the release process of a module (pipeline & tooling)
• Managing Changes: how and when is a breaking change planned & aligned (content)
• internal/external dependencies

Valid use cases:

• Usage of Modules
• Integration in one Stack

Hypotheses:

• Modules need to be usable independently. (Alexander Warg)
• Can the full "blob" be released in e.g. Eclipse S-Core 1.0, and must work together (Thilo)
• We need to make sure that modules of Eclipse S-Core is working together. (Every day the integration must work)
• Safety manuals should be Independent from each other (more components out of context)
  • AoU (Asumptions of Use) must be specified for ever module
  • Impact: More work, but it is reasonable as there is no one writing the full safety manual alone.
  • Dependency graph of modules is needed (in every moduled as the dependencies must be 100% clear)
• As fast as possible to series production.
• Security concurs must be addressed in the whole
• Reference integration stream is doing the first running software
• Eclipse S-Core foundation is the 0.5 components

Question: What is your main adoption strategy?

• It is a high risk / nearly impossible to take all components at once.
• But the consistent Stack is the goal

Scenario:

• What is happening if there is a breaking change in BaseLibs? How you introduce the change?
  • BaseLibs needs to provide the changes to the other modules what are inside the Eclipse S-Core reference integration.
  • Tools needed to show dependencies. Integration tests must block the merge
  • There is a strong discussion about the strategy to release modules, in contradiction to breaking changes

Deprecation mechanism of APIs

• stable APIs maybe not a real goal
• e.g. communication module is changing often

More focus on the reference integration and a User demo application.
A promise of stable APIs is needed.

Summary:
Stack is the goal

Statement:
You can not merge into the main branch of your module (what is a release) if you can not integrate (in reference integration).

Follow up action:
Lars (@qor-lb) is opening a discussion in the Architecture community.

[anmittag]

@chheis where do I find the minutes?

[chheis]

They are directly written to the contribution requests. @qor-lb and I will also provide the links to all meeting minutes in this discussion as well

#1739 (comment)
#1763 (comment)
#1764 (comment)
#1769 (comment)
#1771 (comment)

[FScholPer]

Links added

[chheis]

Breakout discussion

Breakout: Rust approach in the 1.0

Preliminary Meeting Minutes

Main Question:

• What has to be done to use Rust in safety critical systems
• Therefore the Rust Safety Critical Consortium was founded https://github.com/rustfoundation/safety-critical-rust-consortium
  • 3 subcommittees:
    • Coding Guidelines
    • Tooling
    • Liaison
  • Current status to start:
    • https://github.com/orgs/eclipse-score/discussions/1933
  • Next step, that the Rust SCC is taking up
• What can be defined within Eclipse S-Core to work on which topics?

Q (Andreas): Are there certified libs available?
A: Yes they will be. We must go through libs and crates what are widely used
There is a activity to get some widely used crates under a "standard" maintenance.
Ferrocens has a lot of experience with that.
Q: What has to be there to apply it?
A:
Can be started now:

• Code review guideline (there is nothing yet)
• API Guideline (nothing there yet)
• Linters (started but not much / Clippy)
• Unsafe guidelines
• Biggest gap: MC/DC

What is the interest?

• Category
  • I wait until Rust is there?
  • I invest time and money that Rust can be used?
  • A (Tim MB): We are using Rust. And we are interested to use it. But currently we are using C++.
  • A (Andreas ETAS): We are interested. We are contributing but we do not see it in 2026.
  • A (Markus BMW): We are counting that Rust is getting there until 1.0 release.
    • We need invest from Eclipse S-Core to bring it forward. E.g. Clippy can be integrated directly now.
  • A (PR): There is a different approach. We can do get our code already ready instead of waiting for the compiler and libraries.
  • A (Qorix): --
  • A (EB): --
  • Suggestion: Lets establish a method what is currently used?
  • Open Question: We need a decision what is time to decide if we bet on Rust or not?
    • Fully commit or revert?
  • What are the early adoptions and developed in Rust?
  • Assessing the risk with using Rust is not easy, as there is no Roadmap of open points yet.
  • Q (Andrey): What event we are waiting for? Is it an assessor coming around?
  • A (Lars): There has to be a solution for where with a change (not open) to be certified.
  • We should not endlessly working on the guidelines, we should start somewhere.
  • Timeline estimation:
  • Coding guideline Mid next year (~August 26) using Clippy
  • Certified Frameworks is the hardest part tp be certified
    • a gap analysis can be started now.
  • From a Tech perspective Rust is preferred.
  • Idea: Start with a component what we like to be use in production. There are some of these. (Persistency)
  • For Clippy Tooling certification, needs to be done.
  • Concern (Thilo): This is a real bet. There is a clear timeline that we need to release in 2026.
    • I do not believe that in the 1.0 release is in Rust and certified.
  • Is there a big gap, in the Safety analysis?
  • (Markus) If it is not in 1.0, would it be replaced ever?
  • Q: What is about the version updates?
  • A: The only solution is to use only the certified version with the compiler.
  • Q: Is Ferrocens uses Clippy there own?
  • A: Partially.
  • Q: What is about the southbound? (OS)
  • A: The LibC is the connection to the OS.

Next Steps:

• Gap analysis needs to be done
• Until February
• Is done in the Rust community

Proposal:
Continuing in Rust first until February

• Rust first: If there is a new implementation, we do the development in Rust.
  Hints:
• Follow the already known guidelines (only lib-core / libc) and keep the surface low.
• Only allow and use tools and known libs.
• More participation in the Rust round with @darkwisebear

[lurtz]

@chheis You approached me because something is odd with my Github <-> Eclipse account setup and it seemed ok. Maybe I have found something: I have configured github.com to hide my E-Mail address and to replace it with [email protected]. Could that cause what you have observed? I turned this option now off.