Architecture Community F2F Workshop [2025-07-08 - 2025-07-10]

[qor-lb]

Note

Approved in https://github.com/orgs/eclipse-score/discussions/472#discussioncomment-13831810

Participants

• Ulrich Freund (Bosch)
• Zoran Cutura (ETAS)
• Arvid Sievert (ETAS)
• Rebecca Markert (ETAS)
• Markus Bechter (BMW)
• Andrey Babanin (BMW)
• Sourabh Agrawal (BMW)
• Wolfgang Mader (BMW)
• Uwe Maucher (BMW)
• Ulrich Huber @LittleHuba (BMW, day 1&2 f2f, remainder online)
• Lars Bauhofer (Qorix)
• Vinod Reddy Gopi Reddy (Qorix)
• Nico Hartmann (Qorix)
• Oliver Pajnok (Elektrobit)
• Dejan Pangercic (Apex.AI)
• Leonardo Rossetti (Red Hat)
• Johannes Glamsch (Accenture)
• Gerd Schäfer (Accenture)
• Thomas Fleischmann (Accenture, online)
• Armin Bartsch (Accenture, online)
• Tim Kliefoth @timkl7 (MB)
• Thilo Schmitt @thilo-schmitt (MB)
• Frank Scholter Peres @FScholPer (MB, online)
• Alexander Warg @alex-warg-mb (MB, online)
• Yang F. Liu (MB, online)
• Holger Braun (Continental)
• Guy Sagnes (Continental, online)
• Mike Gerdes (Qualcomm, day1 f2f, remainder online)
• Ahmed Zakaria (Qualcomm, day1 f2f, remainder online)
• Vadim Selinger (Qualcomm online)
• Ajay Nambi (Qualcomm online)
• Girish Shirasat (Qualcomm online)
• Thomas Wilhelm (Vector)

Agenda

Goal:

• Evaluation of the 0.5 features & module architecture + dependencies for the RC 0.5
• Review of 1.0 FR's and aligning anticipated module architecture

Day 1: 10:00 - 18:00

Review 0.5

• 10:00 - 11:30 FT Update: 0.5 architecture (à 15 min, FEO, Com, Log, Per, Orch, BaseLibs)

Lunchbreak: 11:30 - 12:30

• 12:30 - 13:30 0.5 Release Candidate
  • Preparation of overall module architecture for identified RC's (everyone)

Preparation 1.0 (per FR 30 min presentation incl. anticipated architecture, 20 min discussion, 10 min filling review criteria)

• 13:30 - 14:00 Introduction, criteria for accepting a new feature request
• 14:00 - 15:00 Feature Request for Deterministic App Abstraction Layer (DAAL) #864 (FEO & DAAL)
• 15:00 - 16:00 Feature Request for Security & Crypto #905
• 16:00 - 17:00 Feature Request for Health & Lifecycle #909
• 17:00 - 18:00 Feature Request for Time #910

Day 2: 9:00 - 18:00

• 9:00 - 10:00 Feature Request for Config Management #754
• 10:00 - 11:30 Feature Request for Diagnostic Services & Fault Management #911

Lunchbreak: 11:30 - 12:30

• 12:30 - 13:30 Feature Request for SOME/IP Gateway #914
• 13:30 - 14:30 Feature Request for ABI compatible datatypes #917
• 14:30 - 15:30 Feature Request for Cross-VM IPC #916

Coffe break: 15:30 - 16:00

• 16:00 - 17:00 Feature Request AI - GenAI #913
• 17:00 - 18:00 Feature Request: AutoSD Development Platform #855

Day 3: 9:00 - 15:00

• 9:00 - 11:30 Anticipated architecture for the 1.0

Lunchbreak: 11:30 - 12:30

• 12:30 - 13:00 Contribution Pitch: Using OpenSOVD in S-CORE
• 13:00 - 14:00 Next steps 0.5 & 1.0
• 14:00 - 15:00 MISC

Topics

Misc

• Modules developed in the AUTOSAR context
• Call for FR: Feature Request for Record & Replay #1167
• SDV Hackathon

Meeting Minutes

Day 1

• 10:00 - 11:30 FT Update: 0.5 architecture

  • Note: Information/alignment on architecture building blocks required (Module, Component, Unit)
  • Note: Until multi-repo setup works, move modules out of feature tree and to the top level.
  • Note: Fallback plan for QNX8.0 rust support created and discussed
  • AI: Platform safety concept: Support creation of Assumed AoUs by a safety-critical OS

• 13:30 - 14:00 Introduction, criteria for accepting a new feature request

  • Review criteria introduced and discussed

    1. Clarity of the Problem Statement: Does the request clearly describe the problem it intends to solve in the motivation?

       A well-motivated feature request focuses on a real-world challenge or limitation users face today.

    2. Clarity of the Proposed Functionality: Does the proposal clearly define the what (not the how) in the specification?

       We expect a precise description of the intended functionality without diving into implementation details. The proposal should describe the semantics and intended behavior.

    3. Novelty and no Feature Overlap: Does this feature already exist in the stack, or does it overlap with something similar?

       In S-CORE we aim for having only one solution for a specific problem. Duplication is discouraged unless justified by significant benefit. Is this potentially a feature modification request.

    4. Alignment with S‑CORE Scope: Is the feature aligned with the scope of S‑CORE and beneficial to its target community?

       We prioritize functionality that supports the scope of providing a safety critical middleware for the microprocessor domain over niche or proprietary needs.

    5. Concept Maturity and Implementation Effort: Can the feature be realized within a reasonable time frame (e.g., 1–2 years)?

       The request should not rely on speculative technologies, large architectural overhauls, or undefined external standards. If feasibility is uncertain, a scoped-down prototype path should be proposed.

  • Review criteria will be answered Yes/No. If no, justification statement required.

• 14:00 - 15:00 Feature Request for Deterministic App Abstraction Layer (DAAL) #864 (FEO & DAAL)

  • Review Criteria:
    • Clarity of the Problem Statement: Yes.
    • Clarity of the Proposed Functionality: Yes.
    • Novelty and no Feature Overlap: TBD. From a first point of view the functionality is semantically included in FEO, mostly syntactic difference to FEO APIs. PoC to decide if this is a functional difference.
    • Alignment with S‑CORE Scope: To be defined after the PoC.
    • Concept Maturity and Implementation Effort: Yes
  • Next steps:
    • Alignment with FEO on API. Incubation repository to check difference/integrateability before deciding about FR continuation.
      • FEO to potentially consider DAAL as C++ API

• 15:00 - 16:00 Feature Request for Security & Crypto #905

  • Review Criteria:
    • Clarity of the Problem Statement: Yes.
    • Clarity of the Proposed Functionality: Yes.
    • Novelty and no Feature Overlap: Yes.
    • Alignment with S‑CORE Scope: Yes.
    • Concept Maturity and Implementation Effort: TBD. Platform security plan required as input + architecture through PoC has to be explored.
  • Next steps:
    • Extend FR draft to incorporate open topics and assumed safety impact
    • Prepare security plan
    • Start PoC + explore interface towards hardware module "abstraction"

• 16:00 - 17:00 Feature Request for Health & Lifecycle #909

  • Review Criteria:
    • Clarity of the Problem Statement: Yes.
    • Clarity of the Proposed Functionality: Yes.
    • Novelty and no Feature Overlap: Yes.
    • Alignment with S‑CORE Scope: Yes.
    • Concept Maturity and Implementation Effort: Yes.
  • Next Steps:
    • Finalize feature request (formal acceptance criteria for feature requests)
    • Call for contribution

• 17:00 - 18:00 Feature Request for Time #910

  • Review Criteria:
    • Clarity of the Problem Statement: Yes.
    • Clarity of the Proposed Functionality: No. Improvement of specification needed.
    • Novelty and no Feature Overlap: Yes.
    • Alignment with S‑CORE Scope: Yes.
    • Concept Maturity and Implementation Effort: Yes.
  • Next steps:
    • Add/incorporate specification improvements (accuracy, mockability, etc.)
    • Discuss with FEO regarding placement of cycle time
    • Finalize feature request (formal acceptance criteria for feature requests)
    • Call for contribution

Day 2

• 9:00 - 10:00 Feature Request for Config Management #754

  • Review Criteria:
    • Clarity of the Problem Statement: No. Extension on parameter lifecycle and context. UC: decouple different clients (or source and client)
    • Clarity of the Proposed Functionality: No. Consistency/integrity check allocation; expected functionality that might come from plugins for populating the DB; what are the functionality left in the config provider (e.g. qualification check, caching).
    • Novelty and no Feature Overlap: Yes. Discuss with persistency if there are potential UC overlaps/reuse (e.g. internal caching parameter in the config provider, using in config daemon).
    • Alignment with S‑CORE Scope: Yes.
    • Concept Maturity and Implementation Effort: Yes.
  • Next Steps:
    • Add/incorporate improvements
    • Finalize feature request (formal acceptance criteria for feature requests)
    • Call for contribution

• 10:00 - 11:30 Feature Request for Diagnostic Services & Fault Management #911

  • Review Criteria:
    • Clarity of the Problem Statement: Yes.
    • Clarity of the Proposed Functionality: No. Log in Fault Lib; Service validation and relation to SM/Launch Manager + State in Service App; Possibility for SOVD via UDS sockets instead of IP;
    • Novelty and no Feature Overlap: Yes.
    • Alignment with S‑CORE Scope: Yes. Separation between stack dependent and stack independent functionality.
    • Concept Maturity and Implementation Effort: Yes.
  • Next Steps:
    • Add/incorporate improvements
    • Finalize feature request (formal acceptance criteria for feature requests)
    • Call for contribution

• 12:30 - 13:30 Feature Request for SOME/IP Gateway #914

  • Review Criteria:
    • Clarity of the Problem Statement: Yes.
    • Clarity of the Proposed Functionality: No. Exposure of (checksum mismatch; dropped messages) faults. Discovery of external services; Involvement with lifecycle management
    • Novelty and no Feature Overlap: Yes.
    • Alignment with S‑CORE Scope: Yes.
    • Concept Maturity and Implementation Effort: Yes. (does not exclude that we will have an additional diverging approach later)
  • Next Steps:
    • Add/incorporate improvements
    • Finalize feature request (formal acceptance criteria for feature requests)
    • Call for contribution
  • Note: IPC should still consider that not all data types are transparent (i.e. transport blob to leave interpretation up to a specialized binding in mw::com)

• 13:30 - 14:30 Feature Request for ABI compatible datatypes #917

  • Review Criteria:
    • Clarity of the Problem Statement: Yes.
    • Clarity of the Proposed Functionality: No. Extension of type reflection (type tagging). Evaluation of interplay between description and definition first workflow. Specific inclusion of tooling.
    • Novelty and no Feature Overlap: Yes.
    • Alignment with S‑CORE Scope: Yes.
    • Concept Maturity and Implementation Effort: PoC first; evaluating reflection and type description workflows.
  • Next Steps:
    • Add/incorporate improvements
    • PoC in incubation in parallel to closing FR.
    • Finalize feature request (formal acceptance criteria for feature requests)
    • Call for contribution

• 15:00 - 16:00 Feature Request for Cross-VM IPC #916

  • Review Criteria:
    • Clarity of the Problem Statement: No. Feature modification to Com (IPC/LoLa). Clarify usecase especially on hypervisor, sharing memory between host & guest VMs. (UC not only S-CORE to S-CORE but in second step also S-CORE to e.g. AAOS - porting LoLa to the target but not full s-core).
    • Clarity of the Proposed Functionality: No. requires dedicated reference to evaluate theoretical concepts.
    • Novelty and no Feature Overlap: No. Feature modification (see above).
    • Alignment with S‑CORE Scope: Yes.
    • Concept Maturity and Implementation Effort: Yes.
  • Next Steps:
    • Rename Feature request: Cross-VM IPC
    • Clear target definition for context evaluation (specific hypervisor as reference, virtio based capabilities in general).
      • should match with our existing target/development platforms
    • Continue as Feature Modification

• 16:00 - 17:00 Feature Request AI - GenAI #913

  • Review Criteria:
    • Clarity of the Problem Statement: (Yes) but separating GenAI topic in separate FR.
    • Clarity of the Proposed Functionality: Yes.
    • Novelty and no Feature Overlap: Yes.
    • Alignment with S‑CORE Scope: Yes.
    • Concept Maturity and Implementation Effort: (Yes) but PoC/incubation for GenAI part first
  • Next Steps:
    • Split feature requests (AI Platform/GenAI Platform), add/incorporate improvements
    • Finalize AI Platform FR
    • Parallel start GenAI PoC
    • Call for contribution for AI Platform

• 17:00 - 18:00 Feature Request: AutoSD Development Platform #855

  • Review Criteria:
    • Clarity of the Problem Statement: No. Extending target platforms does not add functionality to the stack itself. A new type of request is required. Following questions not applicable.
    • Clarity of the Proposed Functionality:
    • Novelty and no Feature Overlap:
    • Alignment with S‑CORE Scope:
    • Concept Maturity and Implementation Effort:
  • Next Steps:
    • Process for extending target platforms (!= Feature Request)
    • Definition
      • Host Platform: Used to execute the development process.
      • Development Target: Used to functionally validated Refence Integrations on.
      • Production Target: Development Target + confirmed conformance between Assumed AoUs and available AoUs.
    • First evaluate impact on Host Platform/CI integration to support new Development Platform (no cross-compilation for AutoSD)
    • Second, include RH AutoSD as Development Target for the 1.0 an prepare evaluation to promote to Production Target
      • Support the reference integration team for setting up the image

Day 3

• 9:00 - 13:00 Anticipated architecture for the 1.0

  • Needed control-flow tracing FR for event points and spans (control flow tracing)
  • Needed data tracing FR for event points and spans (control flow tracing)
  • ToDo: place for architectural decision records (@LittleHuba)
  • Priorization whishlist (guideline/wishlist for external contributors)
    1. Feature Request for ABI compatible datatypes #917
    2. Feature Request for Health & Lifecycle #909
    3. Feature Request for Time #910
    4. Feature Request for Diagnostic Services & Fault Management #911
    5. Feature Request for Config Management #754
    6. Feature Request for Security & Crypto #905
    7. Feature Request for Deterministic App Abstraction Layer (DAAL) #864
    8. Feature Request AI - GenAI #913
    9. Feature Request for SOME/IP Gateway #914

• 13:00 - 13:30 Contribution Pitch: Using OpenSOVD in S-CORE

  • Proposal for fault lib in S-CORE, rest in OpenSOVD
  • OpenSOVD commits to provide a default compatibility with S-CORE components
  • Risk: circular dependency between projects
    • OpenSOVD -> S-CORE: Com, Persistency, Config Mgmt, Authentication, Baselibs? (+ transitive dependencies)
    • S-CORE -> SOVD: Interface to Diagnostic Fault Manager (+ transitive dependencies)
  • S-CORE will continue with a call for contributions until architecture of OpenSOVD substantializes (with a strong recommendation to place a contribution in OpenSOVD)
  • @eclipse-score/automotive-score-technical-leads: Nomiation of S-CORE Diagnostics representatives

• 13:00 - 13:45 Next steps 0.5 & 1.0

  • 0.5
    • Feature teams to evaluate the gaps for the 0.5 wrt. aligned module architecture (target end of July)
    • Setup reference integration team to integrate 0.5
  • 1.0
    • Finalize FR's to issue call for contributions
    • Between call for contributions and contribution pitches we should plan 2 months
    • Presentations for contribution pitches should be available latest 1 week before the contribution pitches
    • Contribution Pitches targeted for 4th to 6th November (will replace the F2F planned for Sept & Dec)
    • Feature Requests have to be finalized until 17th of August

• 14:00 - 15:00 MISC

  • Modules developed in the AUTOSAR context
    • Pressing topics for 1.0: SomeIP, E2E, DLTv2 (if v1 is not sufficient)
    • Fallback for AUTOSAR components (if there is no alternative until contribution pitches):
      • Feature Request for SOME/IP Gateway #914 - Use vsomeip supported SomeIP and E2E version (or switch to DDS)
      • Feature Request for Logging #68 - Use DLTv1 as supported in COVESA
  • Call for FR: Feature Request for Record & Replay #1167
    • @johannes-esr to organize kick-off next week
  • SDV Hackathon (30th Sept to 2nd Oct)
    • Reprocessing based on Lichtblick on top of FEO (volunteers collected until Monday)

Referenced Material

0.5 Module Architecture

QNX8 Fallback

[ZoranCutura]

Please add me as a participant to the workshop @ZoranCutura

[opajonk]

Please add me as well.

[guysagnes]

Pls Add to the list:
@guysagnes - Guy Sagnes, [email protected] (Remote)
@dasoho - Holger Braun, [email protected] (On location)

[qor-lb]

added

[opajonk]

"Oliver Panjok" --> "Oliver Pajnok" 😄

[qor-lb]

Fixed :)

[opajonk]

Oh man, now I messed up my own name in the correction - wow, first time ;-)

“Pajonk”

[4og]

Please add two participants from BMW:

• Andrey Babanin (@4og)
• Sourabh Agrawal

[qor-lb]

added

[FScholPer]

@qor-lb can you please remove feo vs daal.

[qor-lb]

Do you mean removing the DAAL feature request from the agenda or was the question regarding DAAL and FEO differences/similarities already concluded?

[thilo-schmitt]

I think it's not a question of "versus" in the sense of either-or. Let's at least rephrase this to "&" or "with" (instead of "vs").

[FScholPer]

I would prefer respectful and neutral wording as there is no intention to work against (a vs b, b vs c...)

[qor-lb]

updated 👍

[4og]

@qor-lb, can you please also add Wolfgang Mader (BMW) to the list? @wmader23

[qor-lb]

added

[WoojungHuh]

Hi, @qor-lb,
I'm new to here. Can I get detail how to join this F2F? Only on site? If remote is possible, all time is Central European Summer Time (CEST)? Thanks.

[ZoranCutura]

Hello WoojungHuh,
there will be a remote session in MS-teams to dial in, which will be setup on the first day.
Yes, the given schedule is in CEST timezone.

[ZoranCutura]

Did you add yourself to the list of participants or request participation with the f2f workshop?
If you have, you should have received invitations from @qor-lb with the remote sessions.

[WoojungHuh]

Hi @ZoranCutura,
Sorry for the late reply. I can't join these sessions. So didn't request putting my name in the list.

[ZoranCutura]

You're welcome to read and review the outcome / minutes that will be shared and open for ev1.

[ZoranCutura]

@qor-lb FYI, on wednesday I will join later and arrive in Ulm around 12:00.
That fits with the current schedule, where SOME/IP-GW will be in the afternoon session that day.

[odra]

"Leonardo Rosetti" -> Leonardo Rossetti

Also, I am "f2f" participant.

[qor-lb]

sorry my bad, is updated