Architecture Community F2F Workshop [2025-02-11 - 2025-02-13]

[qor-lb]

Note

Approved in #472

Participants

Architecture WG

• Nico Hartmann (Qorix)
• Lars Bauhofer (Qorix)
• Vinod Reddy Gopi Reddy (Qorix)
• Zoran Cutura (ETAS)
• Arvid Sievert (ETAS)
• Ulrich Freund (ETAS)
• Markus Bechter (BMW)
• Ulrich Huber (BMW)
• Lutz Niebergall (Continental)
• Daniel Steinke (Continental)
• Martin Thiede (ESR Labs)
• Armin Bartsch (ESR Labs)
• Simon Gasse (ESR Labs)

CFT FEO

• Hanky Sjafrie (Qorix)
• Matthias Weinmann (MB)
• Christian Eltzschig (Qorix/Ekxide)
• Mathias Kraus (Qorix/Ekxide)

CFT IPC

• Mark Schmitt (MB)
• Jochen Seemann (MB, online)
• Florian Bock (MB, online)
• Dirk Linhos (Continental, online)
• Christian Eltzschig (Qorix/Ekxide)
• Mathias Kraus (Qorix/Ekxide)
• Manuel Fehlhammer (BMW)

CFT Logging

• Lars Pöschel (Qorix)
• Gangadhara Maddikery Raghavendra (BMW)
• Alexander Mohr (MB)
• Paula Grosu (Continental; online)
• Christian Eltzschig (Qorix/Ekxide)
• Mathias Kraus (Qorix/Ekxide)

CFT Persistency

• Sven Bachmann (Qorix)
• Alexander Mohr (MB)
• Christian Eltzschig (Qorix/Ekxide)
• Mathias Kraus (Qorix/Ekxide)
• Guy Sagnes (Continental; online)

Agenda

Day 1 (FEO) - 10:00 - 18:00

1. 10:00 - 10:30 FEO Feature Request
2. 10:30 - 12:00 Contribution Pitch: Runtime (Qorix)
3. 12:00 - 13:00 Lunch break
4. 13:00 - 14:00 Contribution Pitch: FEO (ESR Labs)
5. 14:00 - 15:00 Contribution Pitch: Nautilus (BMW)
6. 15:00 - 18:00 Grooming FEO

Day 2 (IPC) - 8:00 - 18:00

1. 8:00 - 8:30 Communication Feature Request
2. 8:30 - 10:00 Contribution Pitch: iceoryx2 (Ekxide/Qorix)
3. 10:00 - 11:30 Contribution Pitch: Lola (BMW)
4. 11:30 - 12:30 Lunch break
5. 12:30 - 14:00 Contribution Pitch: IPC (Continental)
6. 14:00 - 17:00 Grooming IPC
7. 17:00 - 18:00 S-CORE approach for common library

Day 3 (Logging/Tracing & Persistency) - 8:00 - 16:00

1. 8:00 - 8:15 Log & Trace Feature Request
2. 8:15 - 9:00 Contribution Pitch: Log & Trace (BMW)
3. 9:00 - 10:00 Contribution Pitch: Log & Trace (Continental)
4. 10:00 - 10:30 Contribution Pitch: MP Log (ETAS)
5. 10:30 - 11:30 Grooming Log & Trace
6. 11:30 - 12:30 Lunch break
7. 12:30 - 12:45 Persistency Feature Request
8. 12:30 - 14:00 Contribution Pitch: Persistency (Continental)
9. 14:00 - 15:30 Grooming Persistency
10. 15:30 - 16:00 Wrap-up WS & Next steps

Meeting Minutes

These minutes document decisions (D) and action items (AI) from the workshop. The items are grouped by day and topic.

Day 1

Topic: Fixed Execution Order (FEO) Framework

• AI1 (@alex-warg-mb): Define a proposal for the next CFT FEO meeting regarding how the activity receives access to time while enabling record/replay scenarios.
• AI2 (@qor-lb): Define a location to collect lessons learned. (@simon-acc: follow-up regarding the finding on C++/Rust interoperability.)
• D1: Use FEO ESR contribution as a basis for further development in S-CORE.
• D2: Consider Qorix Runtime as a potential orchestrator to replace current orchestration functionalities in FEO ESR.
  • AI3: Evaluate this option based on a reference system (see AI4).
• AI4 (@eclipse-score/cft-feo): Develop a reference system for evaluating the framework and its integrated components (with respect to orchestration and communication).

Day 2

Topic: Communication (IPC)

• AI5 (@eclipse-score/automotive-score-project-leads): Investigate the possibility of including core components that do not have all artifacts for the safety certification available in open source but accessible through a commercial offer.
• AI6 (@eclipse-score/community-architecture): Add a stakeholder requirement: a version shall not be an attribute of the interface but of the instance that implements an interface.
• AI7 (@eclipse-score/cft-communication): Define the COM API applicable for Lola and Iceoryx2.
  Participants: Nico (Qorix), Christian/Mathias (Qorix/Ekxide), Ulrich H./Manuel F. (BMW), Ulrich F. (ETAS/Bosch), Mark (MB/MB TI), Daniel (Continental).
• D3: The COM API will be implemented by Lola for version 0.5.
  Optional goal: Iceoryx2 may serve as an alternative implementation after AI5 is resolved.
• AI8 (@eclipse-score/automotive-score-project-leads): (Decision proposal) For S-CORE 0.5, features may be implemented in either C++ or Rust.
  Goal for v0.5: Provide well-defined user-facing interfaces for all features in both languages.
• D4: S-CORE’s long-term target is to implement features consistently in a single language while still supporting applications in both Rust and C++.
• D5: Defining the approach for bindings or gateways is not a goal for the 0.5 release. The proposed solutions keep the door open for both directions. Any risk invalidating this assumption must be raised to the architecture community.

Topic: Common Libs / Exceptions

• D6: The proposal in Handling of C++ Exceptions #301 is accepted for production code.
• D7: New code should adhere to weak exception safety to increase testability.
• AI9 (@elfenpiff): Extend the definition of weak exception safety in the discussion Handling of C++ Exceptions #301.
• D8: Use the common C++ libs contributed by BMW for S-CORE, refactoring as needed.
• D9: S-CORE’s long-term target is that all features contributed in S-CORE (not dependencies) use the same common libs.
• AI10 (@elfenpiff/@elBoberido): Propose contributing common libs for Rust (possibility of maintaining the same Rust common libs for S-CORE and Iceoryx2).
  Questions: Where would the common libs be hosted and maintained? How would we handle differing requirements between the two projects (if any)?
• D10: Newly developed code should only use the available common libs (no STL usage).
• D11: Code in common libs should resemble their STL counterparts as closely as possible.
• AI11 (@LittleHuba / @ramceb): Propose a plan for the preparation and roll-out of the common libs (covering both C++ and potential Rust outlook).
• AI12 (@eclipse-score/community-architecture): Define the allowed language subset.
• D12: The root namespace shall be score. Every (S-CORE/Bazel) module must have its own namespace.
• D13: Rust and C++ style guides & formatting must be compatible for newly developed code. (AI follow-up: @eclipse-score/community-operational)
• D14: During the run phase, S-CORE features shall not request additional memory from the OS.
  • AI13 (@elfenpiff): Define a solution that enforces this behavior.
• AI14 (@eclipse-score/community-architecture): Define the run phase for the features.

Day 3

Topic: Logging & Tracing

• D15: BMW log will serve as the implementation behind the logging frontend façade.
• AI15 (@eclipse-score/cft-logging & @eclipse-score/cft-communication): Refactor the design to utilize S-CORE COM for communication between the user and the log daemon.
• D16: Use the Rust log/defmt crate as the frontend façade for Rust.
• AI16 (@eclipse-score/cft-logging): Perform a gap analysis for certifying the Rust log/defmt crate.
• D17: Ensure that the C++ and Rust facades have the same "look and feel".
• AI17 (@LittleHuba + @eclipse-score/cft-logging): Define a scalable concept for DLT message compatibility.
• AI18 (@@eclipse-score/cft-logging): Define the use cases for logging along with a clear context definition including safety goals.
• AI19 (@elBoberido): Define lazy evaluation in the frontend in the context of logging.
• AI20 (@eclipse-score/cft-communication ): Develop a concept for attaching metadata for processing in gateways (e.g. QoS for network).
• AI21 (@elfenpiff): Define structured logging and explore potential connections to existing OSS projects.
• AI22 (@elfenpiff): Develop logging guidelines detailing when to use each log level.

Topic: Persistency

• D18: The S-CORE code base will include only C++17 and Rust (except at the FFI boundary).
  • AI23 (@LittleHuba): Investigate the possibility of utilizing C++20. Until C++20 coding rules are released, apply C++17 rules to C++20 code.
• Options for Persistency:
  • Option A: Use a Rust frontend with a C persistency backend.
    Benefit: Fast implementation; Drawback: Tooling must be extended for C code.
  • Option B: Rewrite the persistency from scratch in Rust.
    Benefit: Native language support; Drawback: Longer lead time for functionality.
  • Option C: Combine A & B: Start with Option A and subsequently replace the implementation (the C backend is excluded from certification scope).
    • AI24 (@eclipse-score/cft-persistency): Check file representation compatibility.
• D19: Select Option C for persistency.
  • AI25: Define the public API for the persistency feature for both C++ and Rust.
    Participants: Guy (Continental), Uwe (BMW), Sven (Qorix), Johannes (ESR), Arvid (ETAS).
• D20: Lock-free access to the key-value store is not required but is favored.
  If possible, enable concurrent read access; write access may use locks.
• AI26 (@eclipse-score/cft-persistency): Define the approach for concurrent access from two different languages. (Low priority; persistency scope must fit in 0.5 by the end of June.)
• AI27 (@elfenpiff/@elBoberido): Propose coding rules (for both C++ and Rust) that are applied and traceable in the open source.
• AI28 (@eclipse-score/community-operational & @eclipse-score/community-architecture): Prioritize establishing C++ and Rust coding rules in the CI/CD pipeline.

Next Steps

• Vote in CFTs for leads.
• Current FR owner invite for the next session and subsequently invites by new owners.
• CFTs perform a gap analysis and create a plan to achieve version 0.5 by the end of February.

Formal criteria for contribution selection

Criteria

Functional adherence to feature request

• ++ everything according to fr
• + partially fulfilling fr (subest of functionality)
• 0 fr needs to be implemented

Availability of source code

• ++ open source available under OSI compliant license
• + plan to be open source under OSI compliant license
• 0 open source available non OSI compliant license
• - not open sourced

Maturity (technical debt of code base): Is the implementation already safety certifiable?

• ++ implemented in a certifiable subset of C++ or Rust
• + refactoring needed but mostly using certifiable subset of C++ or Rust
• 0 written in QM or not according to project programming language

Adherence of available artifacts to score process expectations. Are all artifacts for a certification available in public?

• -- not available (no plan to close the gaps)
• - not open source but available (not planned to open source)
• 0 not available but plan to close gap exists
• + not open source but available and planned to be open source
• ++ available in open source and compliant with S-CORE process

Features

FEO

Criteria	Runtime	FEO PoC	Nautilus
Functional adherence to feature request	+ (subset of FEO)	++	++
Availability of source code	++	++	- (tbc)
Maturity (technical debt of code base): Is the implementation already safety certifiable?	0 (PoC)	0 (PoC)	++
Adherence of available artifacts to score process expectations. Are all artifacts for a certification available in public?	0	0	- (tbc)

IPC

Criteria	iceoryx2	Lola	IEC + DRP
Functional adherence to feature request	++	++	0
Availability of source code	++	++	+
Maturity (technical debt of code base): Is the implementation already safety certifiable?	++	++	0
Adherence of available artifacts to score process expectations. Are all artifacts for a certification available in public?	-	+	--

Log & Trace

Criteria	mw::log	Log & Trace	MP Log
Functional adherence to feature request	++	++ covers also tracing	+
Availability of source code	++	++	+
Maturity (technical debt of code base): Is the implementation already safety certifiable?	++	0	++
Adherence of available artifacts to score process expectations. Are all artifacts for a certification available in public?	+	-- only artefacts from COVESA/dlt are availible	+

Persistency

Criteria	Persistency
Functional adherence to feature request	++
Availability of source code	++ ? (Usage of MPL within S-CORE to be checked -> @johannes-esr)
Maturity (technical debt of code base): Is the implementation already safety certifiable?	0
Adherence of available artifacts to score process expectations. Are all artifacts for a certification available in public?	--

Referenced Material

• Contribution Pitch: Runtime (Qorix): S-CORE_Runtime_Pitch.pdf
• Contribution Pitch: FEO (ESR Labs): Score_FEO_Proposal_Accenture_ESR.pdf
• Contribution Pitch: Nautilus (BMW): Represented in FEO: Feature request #294
• Contribution Pitch: iceoryx2 (Ekxide/Qorix): iceoryx2-score-pitch.pdf
• Contribution Pitch: Lola (BMW): High level Architecture for LoLa #374
• Contribution Pitch: IPC (Continental): In ECU Communication (IEC).pdf, DRP User guide-v1-20250217_143410.pdf
• Contribution Pitch: Log & Trace (BMW): mw_log_pitch.pdf
• Contribution Pitch: Log & Trace (Continental): SDV_SCORE_Architecture_Analytics_LogAndTrace.pdf
• Contribution Pitch: MP Log (ETAS): 20250213_SCORE_MPLog.pdf
• Contribution Pitch: Persistency (Continental): SCORE - Introduction One Pager Persistence.pdf