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

[qor-lb]

Participants

Zoran Cutura (ETAS)
Ulrich Freund (Bosch)
Arvid Sievert (ETAS)
Markus Bechter (BMW)
Andrey Babanin (BMW)
Thilo Schmitt (MB)
Tim Kliefoth (MB)
Matthias Weinmann (MB)
Thomas Fleischmann (Accenture)
Martin Thiede (Accenture)
Johannes Glamsch (Accenture)
Armin Bartsch (Accenture)
Lars Bauhofer (Qorix)
Nico Hartmann (Qorix)
Vinod Reddy Gopi Reddy (Qorix)
Lutz Niebergall (Conti)
Daniel Steinke (Conti)
Rebecca Markert (ETAS) -> Only Thursday

Agenda

Goal: shape the picture of 1.0 so that constraints/requirements for 0.5 features become clearer

Day 1: 9:00 - 18:00

• 9:00 - 9:30 CFT Update (cft leads, ulrich - standin nico/markus h/manuel, markus b, arvid, lutz)
• 9:30 - 10:30 MB App FW contribution pitch (matthias weinmann)
• 10:30 - 11:30 Orchestration FR (lars b)

Lunchbreak 11:30 - 12:30

• 12:30 - 13:30 Configuration FR (markus/michael)
• 13:30 - 14:30 Reference System for FEO (? - markus b to verify)
• 14:30 - 15:30 Base libs: dedicated feature team vs distributed effort, rust & c++ approach
• 15:30 - 18:00 Execution related features
  • Lifecycle & Health (API, Service & HW Health Mgmt)
  • Time (API)
  • Fault Management (API)
  • Configuration (API, Service)
  • Diagnostics (Service)

Day 2: 9:00 - 18:00

• 9:00 - 10:00 AI & HW Acceleration (Tim)
• 10:00 - 11:30 Com related features
  • SOME/IP, Gateway/binding concept (Communication)

Lunchbreak 11:30 - 12:30

• 13:30 - 18:00 Misc Features
  • Breakout

Day 3: 9:00 - 15:00

• 9:00 - 10:30 Autosar Discussion
• 10:30 - 11:30 Update Target Picture 1.0

Lunchbreak 11:30 - 12:30

• 12:30 - 15:00 Next steps 0.5 & 1.0

Meeting Minutes

Day 1

• 0900- Brief update of current modules given

  • FEO: skip (afternoon)
  • COM: API work continues; current implementation in inc_mw_com; First communication pattern: Event Pub/Sub
  • Log:
  • Persistency: -

• 0930: MBAG pitch SafeApplication framework; Lifecycle model presented

• 1030: Runtime Orchestration Feature Request presented

  • Group acknowledges need to have a user space orchestration
  • No mandate for all core components to use orchestration as of now; same for other frameworks like COM and LOG.
  • Qorix to connect with ESR on FEO to showcase orchestration.

• 1300: BMW (Markus): FEO & COM

  • To have consistent relevant data for a number of components/activities in a macro-cycle we require a mechanism to "snapshot" the current COM state in the relevant events to be valid through this cycle.
  • Two realization options:
    A) handle in FEO
    B) handle in COM
  • FEO/COM CFT have to align and process the request

• Record & Replay

  • For Record & Replay COM has to provide access points with API to R&P framework
  • R&P framework is separate framework from COM

• 1400: Config FR

  • Config FR is accepted.
  • Preferred is a solution utilizing COM (incl. Security)
  • COM needs to discuss required communication pattern (Fields)
  • Solution should also interact with PER
  • Call for CFT in Tech Leads round. Lars takes the call
  • Open: Config as a single instance on a device or multiple

• 1430: FEO demonstration application

  • Alignment Frank/Markus; Targets:
  • Migration path from "Adaptive" towards S-CORE
  • Functionality
  • Stress of available APIs
  • Mixed-Criticality

• Potential app: "Mini ADAS"

• 1445: Baselibs / Common libraries

  • One Repo approach: C++ and Rust impls in one repo, different folders; Open: How to handle one build then?
  • Request for a baselib CFT as governance/gatekeeping team.
  • Contributions will come from frameworks or other sources, but not necessarily from the baselib CFT.
  • Baselibs include all language extensions required to build the S-CORE stack.
  • Use of qualified std:: is allowed and static code analysis enforces correct use.
  • S-CORE baselibs may contain extensions utilizing these qualified std:: implementations
  • All baselibs in one namespace with sub-namespaces for the different modules.
  • Namespace proposal to be discussed in architecture community. Coordination: Lars

• Requirement: ABI compatible data types

  • FR required: Lead: Qorix

• 1540: Further S-CORE 1.0 frameworks, Part 1

  • Health & Lifecycle

    • Decision to include in 1.0
    • Agreement to have one framework for both
    • Power-up to power-down lifecycle, excl. Update
    • Feature Request required: Lead: BMW

  • Time

    • Decision to include in 1.0
    • Feature Request required: Lead: Qorix/ESRlabs

  • Fault Management

    • Decision to include in 1.0
    • Feature Request required: Lead: MBAG

  • Diagnostic Services

    • Decision to include in 1.0
    • MBAG to check diagnostics against Config, Fault Mgmt, Com
    • SW Update topic remains open
    • Diagnostic transport open,
    • UDS not set, SOVD in consideration
    • Feature Request required: Lead: MBAG

  • Streaming: Audio/Video (API, Frameserver service)

    • Agreement on first FR considerations in 1.0
    • S-CORE 1.0 can contain a vendor specific implementation of the FR functionality
    • Feature Request required: Lead: BMW/Qorix

  • Crypto (API)

    • Decision to include in 1.0
    • Authentication, Authorization
    • Cryptographic Hashes (init, ingest, finalize, output)
    • Symmetric En-/Decryption
    • PKCS#11 compliant key creation & management
    • FR required: Lead: ESRlabs

  • Key & Certificate Mgmt (Service)

    • Combined with Crypto
    • FR required: Lead: ESRlabs

  • User Management (Service)

    • Combined with Crypto
    • local in-device user management & resource access
    • privilege management in applications and API
    • Assumption 1.0: Posix compliance and QNX 8.0 is available
    • FR required: Lead: ESRlabs

  • Hash (Lib)

    • Simple (hashmap) and former crypto hashes on byte strings
    • Part of baselib
    • No FR required

  • Serialization (Lib)

    • SerDes helper stuff
    • Part of baselib
    • No FR required

• 1800 Close

Day 2

• 9:15 - HW accelerators / AI

  • Presentation given by Tim
  • Consensus among the group to make AI based systems a first class citizen S-CORE 1.0 (hw accelerators as compute abstraction)
  • Very high level abstraction proposed to work with any kernel and the orchestration of that kernel from the CPU
  • Achieving SHM/zero-copy interoperability is of high interest but platform/vendor specific and therefore outside of the control of S-CORE, the feature request shall anyhow elaborate how this could be achieved
  • FR required: Lead: MB TI/Qorix/ESRLabs

• 10:00 - Com related features

  • SOME/IP, Gateway/binding concept (Communication)

    • The group agrees that in a production deployment scenario, the S-CORE COM within the applications contains only the IPC/shared memory binding. The support/translation into different communication protocols that are not accessible via shared memory shall be implemented via gateways.
      • Pros and cons were already elaborated here: https://github.com/orgs/eclipse-score/discussions/542#:~:text=in%20network%20service-,Error%20scenarios%3A,-De/Encoding%20fails
      • The decision was taken for the following reasons:
        • e2e protection does not affect applications in the same system interested in the same data
        • if multiple applications in the system are interested in the same network message, the serialization/deserialization is only applied once instead of every application
        • The above mentioned use-cases are met by ~95% of the applications
      • Applications still have the option to "bypass" the internal IPC/Gateway translation logic to create communication channels in cases where e.g. having an end2end communication with a specific protocol between two applications on a separate host. This could be achieved "on top" of the S-CORE COM solution and utilize the IPC to transport "blobs". This shall only be applied with a good justification because this impacts the reprocessing use-case of that application.
    • The configuration of how an IPC endpoint is represented on "the outside world" shall be maintainable within/next to the gateway.
    • The S-CORE COM API might support different IPC implementations/bindings. However, the production system shall deploy only one specific IPC implementation. Having ABI compatibility of different IPC mechanisms is not a goal of S-CORE COM.
    • FR required: Lead: ETAS/Qorix

  • Zero-copy shared-memory communication (that is not IPC, e.g. inter-vm)

    • Should be use-case driven
    • UC1: Communication between a partition hosting S-CORE and a partition hosting AAOS
      • The S-CORE communication shall be capable to expand into an AAOS hosted vm partition
      • FR required: Lead: MB TI (Alex)/Qorix

• Break-out sessions 14-16

  • Health & Lifecycle: Vinod, Daniel, Markus
  • Time: Nico, Johannes, Alex, Jack, Andrey, Ulrich, Tom
  • Fault Management & Diagnostic Services: Tim, Matthias, Lars, Arvid, Guy

• Side Discussion: Framework API's shall have the capability to support different implementations. S-CORE has only a defined set of supported implementations. Ensuring compatibility with other implementations is not a goal of S-CORE. Hint: this greatly benefits the testability to support mocking. Additional benefits are implementations for replay capabilities (e.g. time).

Day 3

• 9:00 Autosar Discussion

  • Strong interest in the availability of AUTOSAR protocols to ensure that its implementations can interoperate seamlessly with existing AUTOSAR distributions.
  • High Priority Protocols for S-CORE 1.0
    • End-to-End (E2E) Protocol
    • SOME/IP Protocol
    • SOME/IP Service Discovery Protocol
    • Log and Trace Protocol
    • Network Management Protocol
    • Secure Onboard Communication Protocol
    • Time Synchronization Protocol
  • Low to Mid Priority Protocols for S-CORE 1.0
    • Intrusion Detection System Protocol
    • DDS Service Communication Protocol
    • DDS Service Discovery Protocol
    • Vehicle-to-X Remote Access Layer Protocol
    • ARXML meta-model/schema
  • Interoperability Goal
    • Why: The availability of AUTOSAR protocols is greatly of interest to S-CORE to ensure compatibility and interaction with existing AUTOSAR-based systems.
    • How: S-CORE would like to implement stack modules supporting these AUTOSAR protocols.
      (Additionally, S-CORE seeks the option to develop ARXML parsers that can translate specific elements of existing ARXML files into S-CORE configuration formats.)

• 13:00 Update Target Picture 1.0

  • Updates will be available in Add S-CORE architecture diagram in drawio format #765

[LuNieb]

Additional Participants:

Lutz Niebergall (Conti)
Daniel Steinke (Conti)

[DanielSteinkeSDV]

@qor-lb Could you please forward the official invitation to me please?

[TomFleischmann]

@qor-lb Can you please as well forward me the invite? Thx, Tom

[timkl7]

Breakout Session Diagnostics + Fault Management

Notes

• SOVD first focus

• application exposes faults, faults are not part of payload

• FLIB -> API to set faults (via macro)

  • pub fault via IPC -> tbd event vs topic
  • log faults
  • define IF semantics
    • FID, time, ENUM Fault type like DLT, meta data optional (tbd)

• Diagnostics fault manager

  • fault collection via sub to FLIBs IFs via IPC
  • table with FID, DTC, CNT, metadata, etc. + tbd
  • debouncing tbd

• Generic Service App w. IF towards SOVD Server -> e.g. Routines, SW Updates

• Config IF towards SOVD Server

• SOVD Server

• OTA / update out of scope -> would use IF of SOVD Server

• SOVD Gateway -> for adapters

• SOVD Client (tbd)

• SOVD2UDS -> SoC uC use case

• UDS2SOVD (tbd)

• Certificate Management to be solved by Crypto Team -> function: auth

• Next step: feature request

High Level Architecture

Misc drawings