Architecture Board - Meeting Minutes

[timkl7]

2025-07-21

Participants

• @timkl7
• @lh-sag
• Leonardo Rossetti
• Venkat Sundar
• Mark
• Rama
• @floroks
• @FScholPer
• Raviprasad
• John Emad

Agenda

• Definition of work packages
• Project setup

Meeting Minutes

Work packages

Technical components:

• CDA (including ODX Converter)
• Fault Library (in collaboration with S-CORE)
• Diagnostic Fault Manager
• Diagnostic Database
• Server
• Service Apps (Routines)
• Gateway
• UDS2SOVD Proxy
• Client

High level definition here: https://github.com/eclipse-opensovd/opensovd/blob/main/docs/design/design.md

Cross functional topics:

• Testing
• Tooling + CI
• Cyber Sec
• Project Steering Committee
• Process
• Architecture

Project setup

• Fault Library to be developed in collaboration with S-CORE, acts as the technical and organizational interface to S-CORE
• multi repo approach
  • client, server, gateway start in single repository due to many shared concepts and easier testing
  • otherwise repo per component
• language: rust first, cpp secondary (especially) + tooling languages (python, kotlin, etc.)
  • investigate language for client compatible with web assembly
• license model: Apache 2.0 License
• requirements: ISO 17978
  • use table of contents of ISO 17978 - open now
  • tests per paragraph
  • status: implemented, partially, missing
• Documentation flow: ISO -> requirements -> design doc -> ADR
  • code first
  • ASPICE compliance via a tbd framework
• unit testing, framework tbd and depends on specific components -> decide per work package
• component testing, iso compliance testing / rating, framework tbd
• testing work stream: integration testing with all OpenSOVD components together
• meetings invited via Eclipse foundation, meeting per workpackage (possible to consolidate (e.g. server, client, gateway))
• target platforms: x86, arm64
• build system depends on specific components -> decide per work package
• epics/tickets: GitHub projects with issues as ticketing system
• prioritization per work package

Misc

• CDA not suitable as a base for SOVD Server
• what can be reused between CDA and SOVD Server as own crate? to be checked if it is worth it

To do

• detailed design per component in accordance to ISO 17978
• create GitHub Projects Board and initial issues
• check what can be reused between CDA and SOVD Server

[FScholPer]

2025-07-25

Participants

• @FScholPer
• @thilo-schmitt
• Andre Larberg
• Christian Heissenberger
• @floroks
• John Emad
• Raviprasad
• Samir Agnovic
• Ulrich Renner
• Venkat Sundar
• Vinod

Agenda

• Overall into to the project from @thilo-schmitt

Meeting Minutes

• Intro from @thilo-schmitt
• Common crate
• Skeleton setup of SOVD Core discussion start this week
• Question raised how to bring in code -> Please raise up pull request
• Adding repos please create a pull request to https://github.com/eclipse-opensovd/.eclipsefdn
• Add organization readme
• SOVD Server main usecase RnD but future no current plan right now but could be in-vehicle and offboard
• Agenda for the architecture board will be created the week before. Please add agenda points to that as comments.

[thilo-schmitt]

2025-08-04

Participants

• Leonardo Rossetti
• @timkl7
• Masanori Itoh
• Rama
• Oliver Eggeler
• Florian Roks
• Jonas Rummel
• Michael Zanetti
• Felix Mölders
• Ravidprasad
• Markus Hosch
• Stephan Münch
• @FScholPer
• @lh-sag
• Vinodreddy
• Michael Wolf
• Naoto Yamaguchi
• Venkat Sundar
• Shivam Iast

Agenda

• Welcome Michael Zanetti (@mzanetti)
• Update on CDA work (Floria Roks @floroks)
• Align on code coverage, see https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/6479 (Sanimir @lh-sag)
• Github organisation-wide PR/issue templates (Sanimir @lh-sag)

Minutes

• CDA code published, demo in CDA workstream
• share parts between CDA and other components, for example
• BMW lead UDS2SOVD work stream:
  • CHORE ISSUE contact eclipse to add contributors and add a calendar invite from the Eclipse Calendar for uds2sovd
• move issue to opensovd repo from cad repo
• open fast trace under evaluation for aspice
• overlapping components: mainly plugin concept to be used: e.g. logging
• need to align on QM process and contribution requirements
• how to track code coverage in a simple way? see https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/6479
  • add code sonar support -> awaiting eclipse approval
• CHORE ISSUE add PR and I templates to .github repo --> look into yaml templates
• use openapi generators for sovd gw? -> how about the license -> can we publish code from generator?
  • openapi schema on iso page: https://standards.iso.org/iso/17978/-3/ed-1/en/
  • LICENSE ISSUE can we use openAPI generators and publish the generated code or do we have a license conflict?
• CHORE ISSUE contact eclipse to add a calendar invite from the Eclipse Calendar for opensovd-core
• two week vacation break from now on -> slack to be used for questions

[stmuench]

@thilo-schmitt about the above CHORE issues, are there maybe any updates meanwhile?

[thilo-schmitt]

@stmuench, as far as I know:

1. the Core work stream is set up
2. the UDS2SOVD work stream not so much - I have not seen any progress there, maybe due to the relevant people being on vacation
3. PR / issue templates on .github: not done yet - probably good to bring this up again and assign a care taker.

[floroks]

2025-08-25

transferred from #26

Workstreams

Architecture

Participants

• Vermala
• Christer Larsson
• Masanori Itoh
• Leo Xenakis
• Venkat Sundar
• VinodreddyG
• @floroks
• @elena
• @lh-sag

Agenda

• New workstream core meeting on Tuesdays 11:30 to 12:15 CET https://github.com/eclipse-opensovd/opensovd/blob/main/meetings/Eclipse_OpenSOVD_-_Workstream_Core.ics

Meeting minutes

No response

[timkl7]

2025-09-01

Workstreams

Architecture

Participants

• @floroks
• @lh-sag
• @timkl7
• Michael Zanetti
• Christer Larsson
• Patrik Karlsson
• Venkat Sundar
• Masanori Itoh
• Rama
• Ravi
• VinodreddyG
• Vermala
• Ahmed Sadek

Agenda including Meeting Minutes

• submit issue towards ISO SOVD Standard for clarification on certain points, workshop in future to influence SOVD development, e.g.
  • sovd to sovd communication, how to tunnel
  • nested areas: how does the API allow it to query subcomponents
• preparation of slide deck for next meeting client, server, gw meeting ongoing
• IP scan by Eclipse for OpenSOVD
• Workshop for 1.2 SOVD was announced. First meeting in October https://www.asam.net/index.php?eID=dumpFile&t=f&f=9550&token=a5c6bf54429b6fba3ad53b8914f180067b185658

[asadekasam]

Hi,
This is Ahmed Sadek from ASAM. Sorry, I had a bad connection during the meeting. Are these issues to be submitted to ISO or ASAM group?

[lh-sag]

Welcome @asadekasam. These issues will be filed against https://github.com/eclipse-opensovd/opensovd and be discuss next week. If we agree that these issues are blocking us we will handover to ISO/ASAM. Would be great if you could join.

[asadekasam]

Thanks @lh-sag . Then we see next time if I could help.

[thilo-schmitt]

2025-09-08

Workstreams

Architecture

Participants

• @thilo-schmitt
• @floroks
• @lh-sag
• @stmuench
• John Emad
• Michael Zanetti
• Masanori Itoh
• Andrasi Ioan
• Markus Hosch
• Martin Jehle
• Ravi Prasad
• Vermala
• Lorin Clubeica
• Ahmed Aboelkheir
• Andy Riexinger

Agenda

1. status of UDS2SOVD workstream setup
2. status of PR / issue template in .github repo - finding / assigning care taker
3. ISO feedback SOVD server to SOVD server communication #30
4. status on client side

Meeting Minutes

to 1. status of UDS2SOVD workstream setup

• initial suggestion for time slot is Tuesdays 1pm CET
• contact @chheis for meeting setup in Eclipse SDV community calendar
• Markus Hosch / @stmuench to take care

to 2. status of PR / issue template in .github repo - finding / assigning care taker

• Proposal to initially adopt the PR/issue templates of opensovd repo and have it inherited by all repos be default
• Later overwrite in specific repos, if needed
• @thilo-schmitt to check with @timkl7

to 3. ISO feedback #30

• @lh-sag shows and explains SOVD server to SOVD server communication #30
• please review and comment
• @lh-sag to follow up with ASAM

to 4. status on client side

• Markus Hosch asks whether there is some discussion on what clients have to expect (APIs, ...)
• @lh-sag: discussed in Core workstream (Server and Gateway) - please take this up there

[thilo-schmitt]

2025-09-15

Workstreams

Architecture

Participants

@thilo-schmitt
@floroks
@stmuench
@darkwisebear
@lh-sag
@odra
@rama492
Michael Zanetti
Venkat Sundar
Franklin A Fernandes
John Emad
Masanori Itoh
Andrasi Ioan
Martin Jehle
Vermala

Agenda

1. update on UDS2SOVD workstream setup
2. info: OpenSOVD talk at Eclipse SDV Community Meetup Detroit
3. info: CDA workstream with a demo on odx descriptions
4. question on status of FaultLib
5. how to handle requirements

Meeting Minutes

to 1. update on UDS2SOVD workstream setup

• meeting series was setup and is available in the Eclipse SDV Community Calendar (thanks @chheis)
• still need to extend workstream section in README and upload accompanying .ics file, like we have for the other workstreams
• first meeting happened last week already with a first introduction round

to 2. info: OpenSOVD talk at Eclipse SDV Community Meetup Detroit

• October 7 in Detroit, see https://www.eclipse-foundation.events/event/ba2afb9d-6a32-44f9-b4b0-3670299e7a2c/home
• @thilo-schmitt to deliver talk on OpenSOVD - project update: workstreams, code contributions, discussions, ...
• @lh-sag suggested to include a small "how to contribute" section, @thilo-schmitt agreed and had that already on the talk's agenda

to 3. info: CDA workstream with a demo on odx descriptions

• CDA workstream meeting today (09/15 2pm-3pm CET) will include a demo on ODX descroption handling
• for onboard format see odx-converter repo: https://github.com/eclipse-opensovd/odx-converter/tree/main/database/src/main/proto

to 4. question on status of FaultLib

• initial ideas being in the works
• discussed in the Core workstream

to 5. how to handle requirements

• discussion on how to put down requirements - granularity level, etc.
• suggestion to tackle it use case by use csse
• hint: look at how CDA handles it (which is also to be extended): https://github.com/eclipse-opensovd/classic-diagnostic-adapter/tree/main/docs
• probably need to turn ISO document into a requirements tree; there is also the idea of having a compliance test suite that would need such a conversion from ISO to (formal) requirements
• choice of requirements tooling unclear at this point; for integration in S-CORE probably want Sphinx-Needs, at least we would need to convert to it
• needs more in-depth discussion with some prep time before

[i0b]

2025-09-22

Workstreams

Architecture

Participants

• @floroks
• @stmuench
• @rama492
• @i0b
• Christer Larsson
• Masanori Itoh
• Andreas Zinkl

Agenda including Meeting Minutes

1. added uds2sovd meeting to readme @thilo-schmitt
2. copy/move issue and mr templates @timkl7

[thilo-schmitt]

2025-09-29

Workstreams

Architecture

Participants

@thilo-schmitt
@stmuench
@rama492
Andrei Rusu
Holger Braun
Mihai Chelaru
Shorouk Ramzy
Christer Larsson

Agenda

1. info: CDA workstream meeting today (09/29) is cancelled
2. info: UDS2SOVD workstream meeting added to README
3. OpenSOVD logo
4. question on plans for contribution

Meeting Minutes

to 1. info: CDA workstream meeting today is cancelled

As decided in last week's workstream meeting, today's (09/29) instance of CDA meeting is cancelled.

to 2. info: UDS2SOVD workstream meeting added to README

UDS2SOVD meeting series was already setup in Eclipse SDV WG Community Calendar. Now an meeting invite as .ics file is provided in the opensovd repo and linked in the README. (see PR #39)

to 3. OpenSOVD logo

OpenSOVD as a project has no logo yet. @thilo-schmitt is trying to get the professionals at his organization to create one. (This also relates to issue #29.)

to 4. question on plans for contribution

@stmuench: Does anyone plan to contribute to the FaultLib or the SOVD Server.
@rama492: ZF plans to bring a contribution regarding SOVD Server, pending approval from internal processes; he believes Liebherr might be in a similar situation
Holger Braun: Aumovio might be able to allocate work for contributions, asking for feedback where contributions would be required / welcomed
@thilo-schmitt: Mercedes-Benz Tech Innovation is pretty active right now on the CDA component, but of course welcomes contributions from others - please join the CDA workstream if interested; generally join the respective workstream that appeals most to you and get involved there - the project is still in its infancies and contributions or collaboration will be welcome and helpful in any case
@rama492: Also have a look on the filed GitHub issues (in any of the repos), this is work identified to be done and might have not yet an assignee.

[thilo-schmitt]

2025-10-06

Workstreams

Architecture

Participants

@thilo-schmitt (Mercedes-Benz Tech Innovation)
@lh-sag (Liebherr)
@stmuench (BMW)
@rama492 (ZF)
Roland Jentsch (ETAS)
Simone Kriso (ETAS)
Ravi Prasad (Valeo)
Lukasz Juranek (GlobalLogic)
Markus Hosch (BMW)
Martin Jehle (Schaeffler)
Andrei Rusu (Aumovio)
Mihai Chelaru (Aumovio)
Venkat Sundar (Systream)
Lorin Clubeica
John Emad

Agenda

1. how close to the SOVD spec do we want implement?
2. supervision of approvals

Meeting Minutes

to 1. how close to the SOVD spec do we want implement?

@lh-sag presents his motivation: reduce friction, internal and external to the project, as well as towards standardization
as an example: discussions on PRs, see examples CDA PR 57 and CDA PR #50
Some suggestions for specific technical situations presented.
We should clarify - as a project - how we want to approach this in general.

Feedback from @stmuench, Roland Jentsch, Simone Kriso on how deviations could be handled and that we should drive clarification in the ISO standard.

AR: @lh-sag: Provide concrete proposal text. (-> dev mail list?) ( ✅ #43)

to 2. supervision of approvals

@stmuench: Currently preparing design proposals, but touching several components (has cross-cutting impact). How do we approach project-wide agreement?
@thilo-schmitt: Challenge with the impacted workstreams and get feedback; present a consolidated proposal to the Architecture Board and establish agreement / consensus in here; document project decision in dedicated place.
Audience voiced agreement to proposed approach.

[thilo-schmitt]

2025-10-13

Workstreams

Architecture

Participants

@thilo-schmitt (Mercedes-Benz Tech Innovation)
@timkl7 (Mercedes-Benz Tech Innovation)
@theswiftfox (Mercedes-Benz Tech Innovation)
@alexmohr (Mercedes-Benz Tech Innovation)
@lh-sag (Liebherr)
@vinodreddy-g (Qorix)
@stmuench (BMW)
Markus Hosch (BMW)
Venkat Sundar (Systream)
Franklin A Fernandes (Systream)
Jonas Kirchhoff (d-fine)
Erik Hu (d-fine)
Rafal Brewka (int2code)
Simone Kriso (ETAS)
Ramachandran Chakravadhanula (ZF)
Andrei Rusu (Aumovio)
Pawel Rutka

Agenda

1. Contribution pitch: Onboard Client
2. OpenSOVD as contribution pitch for S-CORE
3. ISO standard conformance guidelines
4. Draft PR Middleware API Layer for User Applications

Meeting Minutes

to 1. Contribution pitch: Onboard Client

Venkat Sundar (Systream) presents a proposal for contribution: Onboard Client

• Offboard Client currently in discussion in the OpenSOVD Core workstream
• Onboard Client : Part of this proposal
• Major Functionality: Onboard Diagnostic Sequence handler
• Shall include a method to create/configure sequences in a configuration file that is independent of any tool used to generate it. No hardcoded sequence in the code.
• Sequences are a list of Diagnostic services that are accessible through a single SOVD API to a client. E.g: write sequence to write VIN to each ECU, Variant coding sequence, session/authentication/security access sequence etc.
  Could be the central module supporting SOVD functions and scripts (Yet to be explored - Open point How shall scripts and functions be implemented)
• May require and is proposed to reuse the ODX parser from the gateway to list out available SOVD APIs in the system.
  Alternative => It shall parse the Vehicle CDF to derive this information
• Implementation languange proposed to be in Rust
• Tool for generation of configuration of sequence not proposed as part of OpenSOVD
• Open point: Testing in a real world scenario with vehicles

Discussion points:

• @timkl7: Not sure about the naming "onboard client" - might want to reconsider naming
• Discussion around format for specifying sequences - have to see what is the best / most "compliant" solution

Next steps:

• Work to be organized in Core workstream
• Create repositories, etc.

to 2. OpenSOVD as contribution pitch for S-CORE

See S-CORE Feature: https://eclipse-score.github.io/score/main/features/diagnostics/index.html
See S-CORE Contribution Request: eclipse-score/score#1766

@stmuench how will the integration in S-CORE specifically work (APIs, processes, CI, pulling code, etc.)?
@stmuench We have to look into how applications interact with the diagnostics stack. And also define what is part of the stack in the first place.
Markus Hosch: By the end of 2026 S-CORE plans its 1.0 release - we have to define scope and a roadmap for OpenSOVD towards that goal.

AR: @timkl7 to prepare contribution pitch (S-CORE view)
AR: @timkl7 to bring back feedback from S-CORE Architecture Workshop (Nov 4-6) to this round here -> then drive OpenSOVD roadmap discussion here based on the data

to 3. ISO standard conformance guidelines

Also see #43
@lh-sag recapping the write-up.
Feedback from the round:

• @theswiftfox: on the example in point 2 (PUT vs. POST): where SOVD standard doesn't say anything specific for this situation, therefore use best-practice REST semantics
• @theswiftfox: The example is very specific to the CDA component, probably not easily be generalized
• @thilo-schmitt: In general I'm on the same page that our implementation should be as close as possible to the standard. In cases where the standard doesn't specify anything concretely or at least doesn't give some guidance, I feel any solution is viable. There might be arguments for a solution from other areas of the standard (kind of "applying the spirit of the standard"), but there also might be cases where we leverage best practices from other contexts (e.g. typical REST semantics used in cloud service API designs). Probably hard to give a generic guidance on how to solve this, might need to look on a case-by-case basis.

Call to action for everyone: Please leave feedback as comments on the issue (see reference above) and move the discussion there. Once we accrued a critical mass of feedback, we can bring this back here for decision-making and instantiating a decision record.

to 4. Draft PR Middleware API Layer for User Applications

See #46
@stmuench This is a proposal on the API between Applications and SOVD Server (as opposed to API to FaultManager taken care of by @timkl7)
Please give feedback on the PR!

[timkl7]

2025-10-20

Workstreams

Architecture

Participants

@timkl7 (Mercedes-Benz Tech Innovation)
@floroks (Mercedes-Benz Tech Innovation)
@thilo-schmitt (Mercedes-Benz Tech Innovation)
@i0b (Mercedes-Benz Tech Innovation)
@stmuench (BMW)
@darkwisebear (BMW)
@lh-sag (Liebherr)
@vinodreddy-g (Qorix)
@rama492 (ZF)
Michael Zanetti (Mercedes-Benz Tech Innovation)
Andrasi Ioan (ZF)
Andreas Zinkl (AVL)
Roland Jentsch (ETAS)
Simone Kriso (ETAS)
Martin Jehle (Schaeffler)
Mihai Chelaru (Aumovio)
Jonas Rummel (IAV)
Rafal Brewka (int2code)
Pawel Rutka
SOUHAIL
John Emad (Brightskies)

Agenda

1. Timeline: MVP Scope Idea Collection
2. Fault API / Library
3. Instances of Gateway + CDA

Meeting Minutes

MVP Scope and Timeline

• create a separate discussion page for MVP scope based on minimal feature set: MVP Scope #48

Fault Lib

• add proposals as PR under https://github.com/eclipse-opensovd/fault-lib
• API towards fault manager -> do together with Fault Lib API
• Communize with BMW proposal for SOVD Service API
• Consider Snapshot data for fault manager, IF for environment data
• keep fault lib close to Adaptive Autosar design?

Instances of Gateway + CDA

• discussion about: https://sdvworkinggroup.slack.com/archives/C0958MQNGP2/p1760597477381049
• discuss around example use cases to validate the design
• ADR needed: for fault aggregation -> how and where are faults aggregated
  • DFM 1 to n? or 1 to 1?
• ADR needed: two libraries or one: sovd server vs fault manager API -> two APIs one for faults, one for services -_> overlap for data possible, overlap with entity -> make sure one endpoint for component
• user facing topology proposal @lh-sag

[timkl7]

2025-10-27

Workstreams

Architecture

Participants

@timkl7
Christer Lyssnar
Andrei Rusu
Jonas Rummel
Mihai Chelaru

Agenda

1. Reminder MVP Scope
2. Fault Lib API

Meeting Minutes

-> cancelled due to vacation

[thilo-schmitt]

2025-11-03

Workstreams

Architecture

Participants

@thilo-schmitt (Mercedes-Benz Tech Innovation)
@timkl7 (Mercedes-Benz Tech Innovation)
@mzanetti (Mercedes-Benz Tech Innovation)
@jleuser (Mercedes-Benz Tech Innovation)
@lh-sag (Liebherr)
@vinodreddy-g (Qorix)
@stmuench (BMW)
@rama492 (ZF)
Simone Kriso (ETAS)
Oliver Heilwagen (ETAS)
Roland Jentsch (ETAS)
John Emad (Brightskies)
Ravi Prasad (Valeo)
Jonas Rummel (IAV)
Rafal Brewka (int2code)

Agenda

1. MVP Scope Review
2. Fault Lib API
3. Services API Review

Meeting Minutes

to 1. MVP Scope Review

See #53
@timkl7 presents the PR and its contents and asks for feedback
@stmuench / Rafal Brewka suggest to add an example diagnostic service app
@lh-sag / Rafal Brewka recommend omitting security aspects like ACLs, etc. -- agreed to not have an actual implementation, but rather a conceptual idea
Simone Kriso suggests rephrasing fault reset terminology to aging/healing as commonly used term
@lh-sag / @stmuench raise concern that not all needed components are available yet, so that timeline is probably unrealistic or MVP scope is to broad.

AR: @timkl7: to update the PR with the feedback
AR: everyone: to comment on the PR

to 2. Fault Lib API

See eclipse-opensovd/fault-lib#1
@timkl7 presents the Fault Lib API design and asks for feedback (additional to the existing comments on the PR)
Simone Kriso: You cannot do a simple mapping from fault to DTC. E.g. running a test routine can also yield a "passed" status or have the status "not executed yet", which need to be distinguishable and can't be reflected by a pure DTC record. Suggestion to draw some inspiration from ISO 14229 (UDS) how this is handled there.

AR: @timkl7: to update the PR based on the feedback given.
AR: Everyone: to review the PR.

to 3. Services API Review

Due to time limitations, we offload the discussion to the Core workstream (Tues @ 11am CET)

[thilo-schmitt]

2025-11-10

Workstreams

Architecture

Participants

@thilo-schmitt (Mercedes-Benz Tech Innovation)
@timkl7 (Mercedes-Benz Tech Innovation)
@mzanetti (Mercedes-Benz Tech Innovation)
@floroks (Mercedes-Benz Tech Innovation)
@jleuser (Mercedes-Benz Tech Innovation)
@lh-sag (Liebherr)
@stmuench (BMW)
@darkwisebear (BMW)
@rama492 (ZF)
Ulrich Renner (ZF)
Andrasi Ioan (ZF)
Simone Kriso (ETAS)
Ajitesch Mlshra (ETAS)
Daniel Krippner (ETAS)
Martin Jehle (Schaeffler)
John Emad (Brightskies)
Ravi Prasad (Valeo)
Jonas Rummel (IAV)

Agenda

1. Information on recent/upcoming talks on OpenSOVD
2. Report results from OpenSOVD pitch at S-CORE Architecture Workshop
3. Question: Split of SOVD Gateway and Server
4. Question on design of fault API, mapping DTC status
5. MVP scope definition (cont'd)

Meeting Minutes

to 1. Information on recent/upcoming talks on OpenSOVD

• OCX Webinar Week - OC for Automotive, November 4th 2025 (https://www.ocxconf.org/event/2026/webinar-week)
  • @lh-sag: "Eclipse OpenSOVD: Diagnostics for the masses"
• Eclipse SDV Community Meetup Japan in Yokohama, December 11th 2025 (https://www.eventbrite.com/e/eclipse-sdv-community-meetup-japan-co-hosted-by-bosch-group-tickets-1540218427779)
  • @thilo-schmitt: "OpenSOVD in Action: Shaping the Future of Vehicle Diagnostics"
• OCX 2026 in Brussels, April 21-23 2026 (https://www.ocxconf.org/event/403bffe2-15d8-49ac-af52-e2781b7296b3/open-community-for-automotive)
  • accepted as Early Bird talk
  • @thilo-schmitt, @alexmohr: "Diagnostics Reimagined: How Eclipse OpenSOVD Powers Open Collaboration and Standard Evolution"

to 2. Report results from OpenSOVD pitch at S-CORE Architecture Workshop

Fault API design and MVP scope was presented at the S-CORE workshop. Both accepted and confirmed from the S-CORE side.
@timkl7 will update the respective S-CORE Feature Request to make it align with the agreed contents.
In general S-CORE agreed to have OpenSOVD as the diagnostics subsystem - concrete delivery and implementation to be determined by OpenSOVD project.

to 3. Question: Split of SOVD Gateway and Server

@rama492 voiced a need for agreement on whether gateway and server should be separate or one single component.
Offloading this discussion to the Core workstream.
AR: Core Workstream to come up with a proposal of an Architecture Decision Record, to be finally agreed in and decided by the Architecture Board.

to 4. Question on design of fault API, mapping DTC status

Simone Kriso voiced concerns on unclear specification how test run outcomes are reported and when test runs happen within the driving cycle. Martin Jehle underlined the importance of this, e.g. clearing fault memory is critical and synchronizing the state across the components in the stack.
AR: Simone Kriso and Martin Jehle to provide a proposal for discussion.

to 5. MVP scope definition (cont'd)

Refining discussion on the proposal. Couple questions around what's in and out. Going through the diagram.
AR: @timkl7: to update the diagram

[thilo-schmitt]

2025-11-17

Workstreams

Architecture

Participants

Thilo Schmitt (Mercedes-Benz Tech Innovation) @thilo-schmitt
Jörg Leuser (Mercedes-Benz Tech Innovation) @jleuser
Florian Roks (Mercedes-Benz Tech Innovation) @floroks
Sanimir Agovic (Liebherr) @lh-sag
Stephan Muench (BMW) @stmuench
Ankur Satle (BMW)
Simone Kriso (ETAS)
Roland Jentsch (ETAS)
Ajitesh Mishra (ETAS)
Ramachandran Chakravadhanula (ZF) @rama492
Ulrich Renner (ZF)
Maciej Bacal (Qorix)
Vinod Reddy Gopi Reddy (Qorix) @vinodreddy-g
Ravi Prasad (Valeo)
Martin Jehle (Schaeffler)
Jiri Meduna
Lorin Ciubeica

Agenda

1. Status of PRs

Meeting Minutes

to 1. Status of PRs

PR on fault lib (eclipse-opensovd/fault-lib#1) closed, merged as a first version, with feedback integrated from Simone. Happy to receive any further feedback and refinements.
PR on MVP scope (#53) pending - some feedback has arrived, happy to receive more input if any. @timkl7 to consolidate.

[thilo-schmitt]

2025-12-08

Workstreams

Architecture

Participants

Thilo Schmitt (Mercedes-Benz Tech Innovation) @thilo-schmitt
Tim Kliefoth (Mercedes-Benz Tech Innovation) @timkl7
Sanimir Agovic (Liebherr) @lh-sag
Andrasi Ioan (ZF)
Lorin Ciubeica (ZF)
Simone Kriso (ETAS)
Ajitesh Mishra (ETAS)
Daniel Krippner (ETAS) @dakrbo
Roland Jentsch (ETAS) @RolandJentschETAS
Rafal Brewka (Qorix)
Luca Füger (d-fine)
Sherif Hegazy (Valeo)
Martin Jehle (Schaeffler)
Alexander Gebhard (Softing)
Svetlana Serpik (Softing)
Akshai M (Analog Devices)
Ahmed Tarek (Appraid Tech)
Vadim Selinger (Qualcomm)
Michael Luxen (FEV.io)
bozlak

Agenda

1. CI/CD-Workflows repo exists now - call for review, usage & contribution
2. tracing-dlt crate
3. Eclipse initial IP check
4. Meeting cancellation during holiday season
5. FaultLib repo structure
6. Adding hardware into CI

Meeting Minutes

to 1. CI/CD-Workflows repo exists now - call for review, usage & contribution

Repository is at: https://github.com/eclipse-opensovd/cicd-workflows
All, please use the shared workflows in your component's CI. Please also contribute/put shareable workflows here.
Currently PR eclipse-opensovd/cicd-workflows#2 is pending, please review.

to 2. tracing-dlt crate

See: https://crates.io/crates/tracing-dlt

tracing-dlt provides a tracing layer that forwards logs and spans to the COVESA DLT daemon. This allows you to use the standard tracing macros in your Rust application while outputting to DLT.
We encourage everyone to have a look at it; feel free to use it in your components.

to 3. Eclipse initial contribution IP check

As per Eclipse project creation process an IP check is to be done after initial contribution. Since some code is already there, we'll proceed to trigger this IP check. (@thilo-schmitt drives this.)

to 4. Meeting cancellation during holiday season

Architecture Board will be cancelled over holiday season. We'll resume operations on January 12th 2026.

to 5. FaultLib repo structure

Rafal Brewka presents. See PR: eclipse-opensovd/fault-lib#3
As discussed in last Architecture Board, Rafal has put forward a proposal and asks for feedback on it.
All: Please engage in that discussion.

to 6. Adding hardware into CI

Vadim Selinger (Qualcomm) proposes to add actual hardware into CI runs. Argument is to enable gaining some (more) meaningful performance data. Asks for feedback whether this is interesting to the project / community.
@lh-sag, @dakrbo: Not sure whether this will be helpful right now during development, seems to be more of an integration topic. Subscribe to GitHub Actions and run you performance tests, then we can look into how to report back regressions.
Roland Jentsch: Likes the approach, because it gives guidance where it can be applied.
Rafal Brewka: Good to have a HW target, rather than just having Qemu.
@dakrbo: Idea: Maybe collaborate with SOAFEE?
@thilo-schmitt: Probably even better to do this for S-CORE and have OpenSOVD tested as part of the whole solution.
@lh-sag: Like it to be loose coupled, not as gating factor (so it doesn't block merges).
@dakrbo: If of interest, can help to make contact with other parties that could be helping this.
=> Vadim to take this up with the Testing community of S-CORE (@thilo-schmitt to forward contacts to Vadim). Addtionally, reach out to @dakrbo to get contacts for SOAFEE.

[thilo-schmitt]

2026-01-12

Workstreams

Architecture

Participants

Thilo Schmitt (Mercedes-Benz Tech Innovation) @thilo-schmitt
Elena Gantner (Mercedes-Benz Tech Innovation) @theswiftfox
Alexander Mohr (Mercedes-Benz Tech Innovation) @alexmohr
Michael Zanetti (Mercedes-Benz Tech Innovation) @mzanetti
Jörg Leuser (Mercedes-Benz Tech Innovation) @jleuser
Tim Kliefoth (Mercedes-Benz Tech Innovation) @timkl7
Florian Roks (Mercedes-Benz Tech Innovation) @floroks
Stephan Muench (BMW) @stmuench
Sanimir Agovic (Liebherr) @lh-sag
Ramachandran Chakravadhanula (ZF) @rama492
Lorin Ciubeica (ZF)
Ajitesh Mishra (ETAS)
Simone Kriso (ETAS)
Roland Jentsch (ETAS) @RolandJentschETAS
Kai Hudalla (ETAS) @sophokles73
Andrei Rusu (Aumovio)
Mihai (Aumovio)
Sherif Hegazy (Valeo)
Akshai M (Analog Devices)
Martin Mager

Agenda

1. Implementation status
2. Logging issue tracker URL (in all components)
3. Aligning linting rules across all components
4. Authentication / authorization concept for OpenSOVD

Meeting Minutes

to 1. Implementation status

Core workstream: @rama492: Plan is to go with @lh-sag's implementation for Server. Not yet Production code, we'll take it from that base onwards. @stmuench: Client API design in PR discussion, pending approval
UDS2SOVD workstream: @stmuench: No implementation yet, starting from scratch. Looking into re-use of CDA logic where possible.
CDA workstream: @floroks: Already solid implemention, on the way to production grade (not there yet, though). @alexmohr: Looking into Otel tracing and providing health endpoint, bugfixes, etc.

to 2. Logging issue tracker URL (in all components)

Context: Came up in @jleuser's comment on CDA PR eclipse-opensovd/classic-diagnostic-adapter#123 and the evolving discussion.
There is a few concerns regarding this (see discussion). In general appears to be good to have. But then should be worded wisely and same approach should be used in all OpenSOVD components.
@floroks, @theswiftfox: Inject URL via build env variable
@theswiftfox: Create crate for this that all the components can use
@alexmohr: Let's have a separate repo for shared crates (will need more such crates in the future)

to 3. Aligning linting rules across all components

Context: see discussion on CDA PR eclipse-opensovd/classic-diagnostic-adapter#121
Idea is to have common code guidelines / linting rules and enforcement through tooling uniformly across all components. Respective aspects in CDA pipeline could be carved out and put into shared CI repo.
@stmuench: Which linter / tools? @theswiftfox: clippy and rustfmt (at least)
@theswiftfox to prepare Decision Record on Rust linting and formatting, to be discussed and decided in the Architecture Board

to 4. Authentication / authorization concept for OpenSOVD

Kai proposes Spiffe to be used as a common framework.
@floroks: Discussion so far was to use plugins for auth since OEM solutions will be very specific and deviate from each other. For the public / open-source reference plugin could be implemented through Spiffe.
Should try to align as much as possible between the Server / CDA, even though requirements might be quite different.
@theswiftfox: CDA has already defined traits etc. to this end and recommend reuse of this in other components.
@lh-sag: Feedback on Spiffe: works great in general, but needs some extra work in this context.
Let's offload the discussion to the Core workstream for now.

[thilo-schmitt]

2026-01-19

Workstreams

Architecture

Participants

Thilo Schmitt (Mercedes-Benz Tech Innovation) @thilo-schmitt
Jörg Leuser (Mercedes-Benz Tech Innovation) @jleuser
Alexander Mohr (Mercedes-Benz Tech Innovation) @alexmohr
Tim Kliefoth (Mercedes-Benz Tech Innovation) @timkl7
Florian Roks (Mercedes-Benz Tech Innovation) @floroks
Stephan Muench (BMW) @stmuench
Markus Hosch (BMW) @darkwisebear
Sanimir Agovic (Liebherr) @lh-sag
Ramachandran Chakravadhanula (ZF) @rama492
Lorin Ciubeica (ZF)
Andrasi loan (ZF)
Simone Kriso (ETAS)
Ajitesh Mishra (ETAS)
Roland Jentsch (ETAS) @RolandJentschETAS
Andrei Rusu (Aumovio)
Alexander Gebhard (Softing)
Martin Jehle (Schaeffler)
Ravi Prasad (Valeo)
Sherif Hegazy (Valeo)
Michal Faferek (42dot)
Bartosz Burda (42dot)
Praveen Gudi (LTTS)
Martin Mager

Agenda

0. AI bot participation
1. OpenSOVD at PlugFest @ HS Esslingen
2. Eclipse SDV Community Days in Bonn @ T-Systems
3. Info: FaultLib PR
4. Design documents - where to merge and how
5. Integration of OpenSOVD in S-CORE - Rust build system

Meeting Minutes

to 0. AI bot participation

Observing the attendance of an AI bot ("...'s Notetaker (Otter.ai)") - which raised concerns with other attendees.
No option available to kick or ban the bot.
@thilo-schmitt to ask Eclipse what could be measures against this.
Human participants were okay to proceed despite the presence of the bot.

to 1. OpenSOVD at PlugFest @ HS Esslingen

PlugFest with S-CORE and OpenSOVD planned for CW18/2026 at HS Esslingen. For details please contact @chheis
Call for participation: Preparation (technical, organizing) to make it a fruitful event highly appreciated.

to 2. Eclipse SDV Community Days in Bonn @ T-Systems

Eclipse SDV Community Days are scheduled for end of February in Bonn.
See https://www.eclipse-foundation.events/event/SDV-Community-Days-2026/home
Any plans for OpenSOVD talks?
@lh-sag planning to present on Core and 2026 outlook - if no other proposals

to 3. Info: FaultLib PR

An implementation proposal for FaultLib is available: eclipse-opensovd/fault-lib#4
Note the following in the PR's description:

No further work will be done on this PR by the original team.
If this should move forward, it needs a new owner/volunteer.

Therefore: call for engagement leading the FaultLib engineering.

@rama492 will look into this, but unclear how far the support / ownership can go.

to 4. Design documents - where to merge and how

PR pending: #46
@stmuench: How to get approval and get it merged?
Obtain approvals from relevant people and have a committer merge it.

to 5. Integration of OpenSOVD in S-CORE - Rust build system

In OpenSOVD uses Cargo so far, S-CORE uses Bazel.
Will need a (automated) translation?!
@darkwisebear: Basic idea being pulling OpenSOVD repos in the S-CORE build within the Bazel? Or having OpenSOVD support a Bazel build?
@lh-sag: Cargo build is mandatory. Have a diagnostics repo in S-CORE that provides a Bazel module / build for OpenSOVD.
@darkwisebear: How to integrate Bazel modules like IPC, etc. from S-CORE for use in OpenSOVD components (with no bazel support)?
@lh-sag: FEO in S-CORE uses Bazel features to just use Cargo-toml
-> Searching for a lead on this matter. Please everyone check internally for capacity. Will revisit next week.

[thilo-schmitt]

2026-01-26

Workstreams

Architecture

Participants

Thilo Schmitt (Mercedes-Benz Tech Innovation) @thilo-schmitt
Alexander Mohr (Mercedes-Benz Tech Innovation) @alexmohr
Tim Kliefoth (Mercedes-Benz Tech Innovation) @timkl7
Florian Roks (Mercedes-Benz Tech Innovation) @floroks
Stephan Muench (BMW) @stmuench
Markus Hosch (BMW) @darkwisebear
Sanimir Agovic (Liebherr) @lh-sag
Ramachandran Chakravadhanula (ZF) @rama492
Lorin Ciubeica (ZF)
Andrasi Ioan (ZF)
Ajitesh Mishra (ETAS)
Simone Kriso (ETAS)
Marcus Prinz (ETAS)
Roland Jentsch (ETAS) @RolandJentschETAS
Svetlana Serpik (Softing)
Martin Jehle (Schaeffler)
Bartosz Burda (42dot)
Sherif Hegazy (Valeo)
Akshai M (Analog Devices)

Agenda

1. Documentation and Traceability of Requirements
2. Onboard Diagnostic Client Proposal
3. Eclipse SCORE wants to discuss integration with us - they ask for a meeting

Meeting Minutes

to 1. Documentation and Traceability of Requirements

See #74
@floroks presents the contents of the writeup - especially how Sphinx Needs can be used nicely.
Feedback of round: Makes sense to be as close as possible to what S-CORE does. Therefore makes sense to continue with Sphinx Needs.
Decision: Proceed with Sphinx-Needs in CDA.

to 2. Onboard Diagnostic Client Proposal

Skipped due to Venkat Sundar not being available.

to 3. Eclipse SCORE wants to discuss integration with us - they ask for a meeting

@thilo-schmitt to organize meeting between S-CORE and OpenSOVD. Participants for OpenSOVD (at least one representative per workstream):

• @stmuench for UDS2SOVD
• @rama492, @lh-sag for Core
• @floroks for CDA (@alexmohr, @theswiftfox)

Unclear curently who asked for it and will participate from S-CORE.
Will announce meeting here, on Slack and on dev mailing list.

[thilo-schmitt]

2026-02-02

Workstreams

Architecture

Participants

Thilo Schmitt (Mercedes-Benz Tech Innovation) @thilo-schmitt
Florian Roks (Mercedes-Benz Tech Innovation) @floroks
Alexander Mohr (Mercedes-Benz Tech Innovation) @alexmohr
Elena Gantner (Mercedes-Benz Tech Innovation) @theswiftfox
Stephan Muench (BMW) @stmuench
Markus Hosch (BMW) @darkwisebear
Ramachandran Chakravadhanula (ZF) @rama492
Lorin Ciubeica (ZF)
Andrasi Ioan (ZF)
Simone Kriso (ETAS)
Marcus Prinz (ETAS)
Ajitesh Mishra (ETAS)
Venkat Sundar (Systream)
Franklin A Fernandes (Systream)
Martin Jehle (Schaeffler)
Andrei Rusu (Aumovio)
Alexander Gebhard (Softing)
Ravi Prasad (Valeo)
Bartosz Burda (42dot)
Peter T (GoDot)

Agenda

1. Onboard Diagnostic Client Proposal
2. Decision: Support of C++ applications
3. Discussion/Decision: How to handle stale PRs

Meeting Minutes

to 1. Onboard Diagnostic Client Proposal

Venkat Sundar presents follow-up to the contribution pitch from 2025-10-13. Presented slides: 2026-02-02_OnBoard_Client_Proposal_Update.pdf
Onboard Diagnostic Client has a YAML configuration of SOVD request sequences that can be triggered from "outside", the sequence will be run internally and responses aggregated, finally aggregated responses will be returned to the outside requestor.
Is the sequence definition using a standardized format? Venkat: No, it's a custom format. Might want to think to use a standard format?
Simone Kriso: Sequences are pre-configured and deployed statically. Venkat: Yes, but we can also think about extending this to uploading new sequence definitions that have been created offboard.
Marcus Prinz: YAML seems weird choice for describing sequences.
@stmuench: Wondering what the use case is, since we could do the same with just running the sequences on the offboard-test; also uploading sequences like scripts and running them, could be a security risk. Venkat: Executing sequences from the onboard client simplifies offboard-testers.
@rama492: ECUs can theoretically come and go and so SOVD endpoints will appear and go away, but sequence description is static, so there is a gap? Venkat: Correct, can work on this.
@stmuench: Feature / implementation seems very tailored to your specific use case and rest of infrastructure. Need to get a sense if and in which form the project / community wants this.
Venkat to prepare incubation repository and a PR for the project community to examine and give feedback on.

to 2. Decision: Support of C++ applications

@stmuench: OpenSOVD stack will be written in Rust. We need a way to integrate this with existing software, which is mostly written in C++.
@darkwisebear: Latest when we integrate with S-CORE there will be definitely the need to have a C++ API. But where should this live? Stay in S-CORE or be part of OpenSOVD?
@rama492: Can have a separate repository containing C++ bindings.
Agreement in the round that this should live in the OpenSOVD project.
Next step: Create repo called cpp-bindings. @stmuench will take care.

to 3. How to handle stale PRs

In the CDA we have some stale PRs (e.g. no ECA signed since December). How should we as a project handle these? Individual by each component, or do we want a project-wide policy (e.g. remind them after a month, and again after additional week, and close after with no activity?)
@floroks / @alexmohr: Suggestion to (partially?) automate via CI/CD workflows like https://github.com/actions/stale
@floroks: Do we want a project-wide way of doing this?
Round agrees that project-wide process is favored.
@floroks to prepare Decision Record.

[alexmohr]

Suggestion for stale MRs: Automate via https://github.com/actions/stale

[thilo-schmitt]

2026-02-09

Workstreams

Architecture

Participants

@timkl7
Alexander Gebhard
Roland Jentsch
Akshai M
@lh-sag
Bartosz Burda
@alexmohr
Martin Jehle
Jörg Leuser @jleuser
Simone Kriso
@theswiftfox
Rama
Markus Hosch

Agenda

1. Architecture Decision Record: Rust formatting and linting [Proposal]
2. Architecture Decision Record: Handling stale PRs [Proposal]
3. Fault-lib PR
4. ODX converter in Kotlin

Meeting Minutes

to 1. Architecture Decision Record: Rust formatting and linting [Proposal]

See #80
Please review and give feedback. Target for final decision in next week's Architecture Board (2026-02-16).

to 2. Architecture Decision Record: Handling stale PRs [Proposal]

See #82
Please review and give feedback. Target for final decision in next week's Architecture Board (2026-02-16).

to 3. Fault-lib PR

See eclipse-opensovd/fault-lib#4
@bburda42dot to take over PR and bring it to main.

• decision point: separate fault lib meeting or core workstream? --> D: Core Workstream and Update in Architecture Meeting
• decision point: separate fault lib and DFM --> separate repos (see other discussion)
• new pull request from 42dot for fault lib + release

to 4. ODX converter in Kotlin

• keep the component in Kotlin or move to Rust?
• no plans to switch to Rust as of today
• opinion to move to Rust -> open a discussion/ADR to discuss further @lh-sag (done: [RFC] Language alignment for odx-converter and future tooling #83)

[floroks]

2026-02-16

Workstreams

Architecture

Participants

Roland Jentsch (ETAS)
Ajitesh Mishra | ETAS
Andrasi Ioan | ZF
Andrei Rusi | Aumovio
Carl Eike Hofmeister | Schaeffler
Lorin Ciubeica | ZF
Markus Hosch | BMW
Stephan Muench | BMW
Martin Jehle | Schaeffler AG
Rama
RaviPrasad | VALEO
Simone Kriso (ETAS)
@lh-sag
@alexmohr
@theswiftfox
@floroks

Meeting Minutes

Architecture Decision Record: Rust formatting and linting [Proposal]

no opposition to ADR, we will do it as proposed

@alexmohr will implement it

Architecture Decision Record: Handling stale PRs [Proposal]

discussion about days until stale / closed

label automatically for issues -> triage, logic only applies if the issue has that label

proposal: use 60/30 for PRs and issues, logic only applies to issues with the label

process for looking at stale issues - e.g. filter and look at it in the workstreams

proposal: 60/30 for PRs -- 90 / 30 for issues

vote: decision 90:30

@floroks will implement it

Responsibility and further development for fault lib and fault manager

questions on who is responsible, and how it'll be further developed, no information available -> next meeting @thilo-schmitt

if no one is contributing we need to revise MVP scope

[thilo-schmitt]

2026-02-23

Workstreams

Architecture

Participants

Thilo Schmitt (Mercedes-Benz Tech Innovation) @thilo-schmitt
Elena Gantner (Mercedes-Benz Tech Innovation) @theswiftfox
Alexander Mohr (Mercedes-Benz Tech Innovation) @alexmohr
Michael Zanetti (Mercedes-Benz Tech Innovation) @mzanetti
Florian Roks (Mercedes-Benz Tech Innovation) @floroks
Frank Scholter Peres (Mercedes-Benz Tech Innovation) @FScholPer
Stephan Muench (BMW) @stmuench
Ramachandran Chakravadhanula (ZF) @rama492
Andrasi Ioan (ZF)
Bartosz Burda (42dot) @bburda42dot
Ajitesh Mishra (ETAS)
Simone Kriso (ETAS)
Roland Jentsch (ETAS) @RolandJentschETAS
Andrei Rusu (Aumovio)
Ravi Prasad (Valeo)
Venkat Sundar (Systream)
Akshai Murukakumar (Analog Devices)

Agenda

1. Status SOVD Server / FaultLib / FaultManager progress and outlooik
2. Bazel build / integration strategy with S-CORE

Meeting Minutes

to 1. Status SOVD Server / FaultLib progress and outlooik

Context / data points:

• Server: New attempt on initial implemenration: chore: initial import opensovd-core#25
• FaultLib: Implementation attempt, without maintainer: impl: Fault Lib Initial Impl fault-lib#4
• FaultLib: Possible maintainer: impl: Fault Lib Initial Impl fault-lib#4 (comment)
• FaultLib: Discussion whether we need to drop it from MVP scope: Architecture Board - Meeting Minutes #8 (comment)

OEM interest voiced to make native SOVD PoC in an actual car - requires Server / FaultLib components to be in some sensible state of availability.

@rama492: Currently team looking into implementation proposal; rough expectation is that this could be merged to main the next 2-3 weeks, providing agreement in the workstream.
@bburda42dot: In internal review at 42dot, checking alignment with requirements; planning to take over maintainership and bring a revised PR (using the Qorix/int2code PR as basis).
@stmuench: What about the Fault Manager? Any maintainer on the horizon?
@bburda42dot: Can discuss that we take over maintainership also for Fault Manger - it's possible, also matches well with engagement on FaultLib; need to align with the project in terms of expectations and so on.
@stmuench: Currently only high-level requirements exist, would need to drill down on this.
@rama492: Core workstream can take on FaultLib/FaultManager discussion, at least initially - can later forked off into its own workstream if needed.
@bburda42dot: Unclear how SOVD Server and Fault Manager should talk to each other / interface. This needs to be totally conceptualized from the ground up.

@stmuench: Should have an incubation step before we accept FaultLib code into main.
@thilo-schmitt: Will use an incubation branch for that. Also will make sure to block the initial, unmaintained PR eclipse-opensovd/fault-lib#4 from (accidental) merge.

to 2. Bazel build / integration strategy with S-CORE

@stmuench and @bburda42dot are both working on some aspects of a Bazel build. Only puzzle pieces, not an integration solution right now. Might make sense to exchange on the work being done there, to avoid doubled efforts.
Neverthelss we are in need of a proper integration strategy. @thilo-schmitt to schedule meeting between S-CORE and OpenSOVD to discuss how integration of the two should look like.

[thilo-schmitt]

2026-03-02

Workstreams

Architecture

Agenda

1. Committers in subrepos
2. S-CORE Feature Team for OpenSOVD

Meeting Minutes

to 1. Committers in subrepos

How do we get the right persons, maintainers in subrepos, to become committers.
@thilo-schmitt points to usual Eclipse processes (committer election - to be elected person must demonstrate sustained high-quality contributions to the project). Challenge is to get new components' maintainers as committers since they do not immediately qualify for committer election criteria.
Agreed on proposal: Maintainers of new components should primarily do reviews and gatekeeping on their comppnent, on finalization find existing committers to approve for merge.

to 2. S-CORE Feature Team for OpenSOVD

S-CORE Feature Team for Diagnostics in formation.
See also https://github.com/orgs/eclipse-score/discussions/2632

Related, in-depth discussion: Where should API designs live?
Proposal is to put them in S-CORE, and have OpenSOVD simply implement it.
For APIs to the non-OpenSOVD world only
Roland Jentsch: For docs-as-code in S-CORE it would be good to have this direction.
Consensus in the round: Finalize current work on API designs in OpenSOVD, then move it to S-CORE.

[thilo-schmitt]

2026-03-09

Workstreams

Architecture

Participants

Svetlana Serpik (Softing)
Andrasi Ioan | ZF
Martin Jehle | Schaeffler AG
Stephan Muench | BMW
Ravi Prasad | Valeo
Lorin Ciubeica | ZF
Ajitesh
Rama
@theswiftfox
Thilo Schmitt (Mercedes-Benz Tech Innovation) @thilo-schmitt
Florian Roks (Mercedes-Benz Tech Innovation) @floroks

Agenda

1. Forking of Sam Preston's DoIP implementation into OpenSOVD

Meeting Minutes

to 1. Forking of Sam Preston's DoIP implementation into OpenSOVD

For initial context see eclipse-opensovd/uds2sovd-proxy#4 (comment) and following.
Currently using https://github.com/samp-reston/doip-definitions and https://github.com/samp-reston/doip-codec from a private fork by @theswiftfox in CDA. Considering (partial) forking into OpenSOVD for more reliable maintainership, easier tailoring to OpenSOVD needs and enabling homogeneous re-use within the project.

@theswiftfox : Issues: focussed on no-std environment, we require custom socket stuff (e.g. tls), upstreaming makes it harder to iterate, Sam seems to use it differently. Our fork removes some python stuff due to build issues.

Consensus: We should do it, further discussion about how regarding licenses etc. will be done by Thilo and @floroks - CDA workstream will be in the lead for integration.

docs-as-code

Question on when @floroks can present docs as code --> Still in discussion with our ASPICE folks, basic idea is to use process description from score, simplify the meta model a bit (similar to how it's currently in the CDA). Will take a bit more time.

[thilo-schmitt]

2026-03-16

Cancelled.

[thilo-schmitt]

2026-03-23

Workstreams

Architecture

Participants

Thilo Schmitt (Mercedes-Benz Tech Innovation) @thilo-schmitt
Florian Roks (Mercedes-Benz Tech Innovation) @floroks
Elena Gantner (Mercedes-Benz Tech Innovation) @theswiftfox
Ramachandran Chakravadhanula (ZF) @rama492
Lorin Ciubeica (ZF)
Ajitesh Mishra (ETAS)
Martin Jehle (Schaeffler)
Carl Eike Hofmeister (Schaeffler)
Ravi Prasad (Valeo)
Thomas Clausnitzer (d-fine)
Praveen Gudi (LTTS)

Agenda

1. OpenSOVD Logo
2. Initial IP scan completed
3. OpenSOVD F2F Workshop

Meeting Minutes

to 1. OpenSOVD Logo

Context: See #29
Please leave feedback, in order to finally agree on a project logo.

to 2. Initial IP scan completed

See https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/983#note_6648215

The automatic IP review of the project's initial contribution has been successfully completed. We can now close this ticket and officially declare the project operational.
Please ensure ongoing proper management of your IP and plan to connect with the EMO in 3-6 months to schedule your first official review.

to 3. OpenSOVD F2F Workshop

Proposal to hold a face-to-face workshop to have very focused and efficient discussions on the various open topics to drive them towards finalization. @lh-sag offered to potentially host this at the Liebherr site in Ulm - to be confirmed and details to be worked out. In general possible dates and an workshop agenda has still to be worked out.
@floroks has created a discussion and wiki page for preparation and documention:

• 1. Eclipse OpenSOVD Meetup #96
• https://github.com/eclipse-opensovd/opensovd/wiki/1.-Eclipse-OpenSOVD-Meetup

Please engage in the discussion and give your input which topics you think should be handled at the workshop. Please also follow the discussion to give feedback and track preparation.

[thilo-schmitt]

2026-04-13

Workstreams

Architecture

Participants

Thilo Schmitt (Mercedes-Benz Tech Innovation) @thilo-schmitt
Florian Roks (Mercedes-Benz Tech Innovation) @floroks
Stephan Muench (BMW) @stmuench
Ramachandran Chakravadhanula (ZF) @rama492
Sanimir Agovic (Liebherr) @lh-sag
Roland Jentsch (ETAS) @RolandJentschETAS
Simone Kriso (ETAS)
Ajitesh Mishra (ETAS)
Svetlana Serpik (Softing)
Venkat Sundar (Systream)
Martin Jehle (Schaeffler)
Thomas Clausnitzer (d-fine)
Ravi Prasad (Valeo)
Praveen Gudi (LTTS)

Agenda

1. Reminder OpenSOVD Logo
2. Reminder OpenSOVD F2F Workshop
3. Info: OpenSOVD talk @ OCX 2026
4. Info: Hackfest @ HS Essslingen
5. Status Fault API
6. Client lib design / implementation proposal

Meeting Minutes

to 1. Reminder OpenSOVD Logo

See #29
Please leave feedback, in order to finally agree on a project logo.

to 2. Reminder OpenSOVD F2F Workshop

Please engage in the discussion and give your input which topics you think should be handled at the workshop. Please also follow the discussion to give feedback and track preparation.

• 1. Eclipse OpenSOVD Meetup #96
• https://github.com/eclipse-opensovd/opensovd/wiki/1.-Eclipse-OpenSOVD-Meetup

to 3. Info: OpenSOVD talk @ OCX 2026

There will be talk on OpenSOVD next week at the OCX 2026 conference: https://www.ocxconf.org/event/2026/agenda?session=848fe283-330f-4937-88e4-8ed3c9adb9a6&shareLink=true

to 4. Info: Hackfest @ HS Essslingen

OpenSOVD is part of the Hackfest @ HS Esslingen, happening 28th/29th April 2026: https://luma.com/1m5bqx2o

to 5. Status Fault API

@rama492 asks for status/progress on the fault API
@stmuench Proposal to discuss this in the Core workstream

to 6. Client lib design / implementation proposal

@stmuench created a proposal of the client lib design and possible implementation. Lives in diagnostics iincubation repo in S-CORE: eclipse-score/inc_diagnostics#1
Request for everyone to have a look and give feedback.

[floroks]

2026-04-20

Workstreams

Architecture

Participants

bozlak
Svetlana Serpik (Softing)
Roland Jentsch (ETAS) - @RolandJentschETAS
Simone Kriso (ETAS)
Ajitesh [ETAS]
Carl Eike Hofmeister | Schaeffler
Martin Jehle | Schaeffler AG
RaviPrasad | Valeo
Rama (ZF)
Frank Scholter Peres | Mercedes Benz Tech Innovation
Florian Roks (Mercedes-Benz Tech Innovation) @floroks

Agenda

F2F meeting

question on dates (https://github.com/eclipse-opensovd/opensovd/wiki/1.-Eclipse-OpenSOVD-Meetup), since first proposed date is approaching @lh-sag - we should do a poll when all dates are available to pick one with most participation.

fault manager pr

question on how to continue with the fault manager PR -> old one was closed, new one needs to be reviewed

opensovd integration into score

• incubator repository exists in score

• there should be a regular meeting - frank will create poll on time in slack

Meeting Minutes

[thilo-schmitt]

2026-04-27

Workstreams

Architecture

Participants

Thilo Schmitt (Mercedes-Benz Tech Innovation) @thilo-schmitt
Alexander Mohr (Mercedes-Benz Tech Innovation) @alexmohr
Elena Gantner (Mercedes-Benz Tech Innovation) @theswiftfox
Florian Roks (Mercedes-Benz Tech Innovation) @floroks
Ramachandran Chakravadhanula (ZF) @rama492
Martin Jehle (Schaeffler)
Simone Kriso (ETAS)
Andrei Rusu (Aumovio)
Michael Luxen (FEV)
Berke Bozlak (FEV)

Agenda

1. OpenSOVD F2F workshop
2. S-CORE integration F2F workshop
3. demo repository
4. integrate mdd-ui into eclipse-opensovd
5. FaultLib status

Meeting Minutes

to 1. OpenSOVD F2F workshop

Please feedback interest in workshop and possible dates.
See also agenda item 2.

to 2. S-CORE integration F2F workshop

A technical workshop in Ulm (targeted for mid-May, exact dates tbd) was proposed to advance diagnostics in S-CORE through the integration of OpenSOVD. The goal is to identify architectural gaps, define a target technical setup, and clarify concrete next steps, and have focus on requirements from adopters. The workshop aims to address open architecture decisions that currently slow down native diagnostics integration and to foster adoption.

Theoretically could be combined with OpenSOVD-F2F (see previous agenda item) into one larger workshop. That might help with logistics and organization. On the other hand, it's really two different topics.
@rama492: Prefer to keep the workshops separate as target audiences and topics differ enough.

Also note: Polly on Slack for regular feature team meeting on OpenSOVD integration in S-CORE: https://sdvworkinggroup.slack.com/archives/C0AHJC1Q9BL/p1776679154995299 -- we would see the workshop as a "kickoff" and then go into regular operations using the agreed time slot from the Polly.

Announcement to be made via S-CORE and OpenSOVD mailing lists and/or Slack channels. Your feedback then appreciated.

to 3. demo repository

See new demo repo here: https://github.com/eclipse-opensovd/demo - put your OpenSOVD-focused demos here. E.g. @alexmohr will put his CDA security plugin demo from the OCX conference there.

to 4. ntegrate mdd-ui into eclipse-opensovd

Nice browser-based UI to look at and examine MDD files (showing DTCs, requests, etc.) It has an AI Assistant to "chat" with MDDs and find things out via natural language. Also there is a MCP server implemented for agentic AI interfacing.
Request to make this tool part of OpenSOVD.
@rama492: In favor of adding it to OpenSOVD generally. Question where to put it - like a "tooling" repo?
@alexmohr: Prefer to put in its own separate repo.
@floroks: one repo for all tooling would likely make releasing individual tools independent from each other more difficult
Accepted to include MDD-UI in OpenSOVD.

to 5. FaultLib status

@rama492: 42dot raised PR and from their side it is good to merge to main. Asking for actual reviews from 2-3 partners. Caveats are gaps in documentation and specifically requirements docs. Additionally, people involved will leave the project, which brings a certain risk of non-sustained maintenance - but Rama was optimistic on continued maintainership by 42dot (with different people) for the FaultLib.
Call to action for a thorough review of the FaultLib PR.