Sync on Detailed Design for S-Core

[PhilipPartsch]

Scope:
Let’s talk about how to model the detailed design within S-Core.
Topic which we have to solve (minimized):
How to model Detailed Design within S-Core (Sphinx-Needs)?
How to link source code to the Detailed Design?
How to get the evidence, the implementation fits to the model?

In the meeting we should sync on:

1. Who is doing what (e.g. for the rust pilot, what is already been defined in the process, etc.)?
2. Who will take up which topic?

Participants:
[x] @nradakovic
[x] @dcalavrezo-qorix
[x] @hoe-jo
[ ] @MaximilianSoerenPollak
[ ] @vinodreddy-g

Meeting Minutes:

Decisions:
We agreed to use the already defined sphinx-needs directives dd_sta and dd_dyn as defined in process.
We agreed to use the same elements for c/c++ and rust components.
We agreed to stay with defined attributes and links to the requirements and architecture elements.

We work on linking the source code via extensions to fetch source code to the documentation.
Example how it looks like in python.

Open Decisions:
How do we want to link to the source code / implementation?

Next Steps:

Evaluation of automatic source code to documentation translation to link from dd_sta and dd_dyn to these sphinx targets.
Or we have the possibility to generate needs elements within the source code e.g. via https://codelinks.useblocks.com
Questions: Do we have to have here bidirectional links? Resp.: @PhilipPartsch

1. Rust: (focused by @nradakovic and @dcalavrezo-qorix)
   Work item: Analyze Generation of Detailed Design Documents from Rust Code Using Sphinx-Based Docs-as-Code Approach #1376
   We currently prefer to use https://github.com/sphinx-extensions2/sphinx-rust .
   Example in PR.
   See the following rendering

2. C/C++: (focused by @PhilipPartsch)
   We start a evaluation, hopefully on repo inc_mw_per and/or on generic repos, to look into alternatives like https://boschglobal.github.io/doxysphinx/docs/alternatives.html and https://codelinks.useblocks.com/ to be as close as possible to the rust tool look and feel.

Follow up:
Meeting is planed on Friday 1st August 2025 from 14 to 15 CET.

Topics:

• Sync on questions and present current prototypes.

• Agree on documentation in the process repo

• Fetch open topics from https://github.com/orgs/eclipse-score/discussions/1295 and work on

[PhilipPartsch]

Here is the current definition in the process: https://eclipse-score.github.io/process_description/main/folder_templates/modules/module_name/component_name/docs/detailed_design/index.html

[PhilipPartsch]

Tools to get c/c++ code to sphinx/sphinx-needs:
https://boschglobal.github.io/doxysphinx/docs/alternatives.html
https://codelinks.useblocks.com/

[MaximilianSoerenPollak]

Discussion tooling team already had with process in regards to this:
https://github.com/orgs/eclipse-score/discussions/1295

[PhilipPartsch]

Discussion 2025-09-26
@PandaeDo @PhilipPartsch
Topics:

1. Pilot: Fetch elements for documentation from source code
   We can generate the needs from the source code via a Sphinx-Needs Extension:
   Need been tech from source code shall be these: examples in the porcess
   The extension to be used is https://codelinks.useblocks.com
   The syntax within the source code shall follow https://codelinks.useblocks.com/components/analyse.html#id3

2. Pilot: Fetch elements for documentation from source code
   Add for the elements in the documentation the doxygen like implementation documentation.

Form the last meeting:
We currently prefer to use https://github.com/sphinx-extensions2/sphinx-rust .
Example in PR.
See the following rendering

C/C++ has to be piloted. Best Idea currently from one of the feature teams, with support from PhilipPartsch. Issue is how to get these in Bazel, not to do it in tooling itself.

3. Document process description update via PMP - Software Verification Plan, ML2 #1311 within there the process update topic work item 85
   We do want to have two step by step instruction:

I. How to introduce the tooling to infrastructure (e.g. docs-as-code repo and pipeline scripts)
II. How to use the tools within a feature repository

Follow-up:
Follow up with hopefully agreed support from per feature team is planned for 10.10.2025.
Invitation is already sent.

[dcalavrezo-qorix]

@PhilipPartsch @PandaeDo
You can find here the changes and demo I did a while ago for DDD integration:

eclipse-score/persistency#27
https://eclipse-score.github.io/inc_mw_per/pr-27/ddd.html

[PhilipPartsch]

Meeting planed for 10.10.2025 were hold on 13.10.2025 with @PandaeDo .
We reviewed the Solution in PR, findings are documented there.
Next meeting to decide on alternatives with architect and team of per is planed for 17.10.2025.

[PhilipPartsch]

Meeting on 17.10.2025 with @dcalavrezo-qorix @PandaeDo

We do want to enhance PR with metadata based diagram generation like in the Architecture. For this we do have to introduce a needs element for the component and link the units to it.
We do want to make the changes in a cooperation style.

Steps to be done:

• add component as need-element
• link units to comp
• define what the software unit (the already defined need element sw_unit) stands for in C++/ Rust
• provide generic function to generate needarch code for comp detailed design and unit detailed diagnosis views like it is in the architecture

We do have to agree on the add component / feature and platform as needs element, let's discuss this in the process community.

[PhilipPartsch]

We have to describe how to auto link between Rust and C++.

[PhilipPartsch]

@PandaeDo and @PhilipPartsch will focus on

• define what the software unit (the already defined need element sw_unit) stands for in C++/ Rust
  Document: https://github.com/eclipse-score/process_description/edit/main/process/process_areas/implementation/implementation_concept.rst
  Task: Create chapter with definition of a SW Unit (can be a depending of the programming language: source file, definition file (c++ header), classes, structs, functions, and ...).

• Optional: We have to describe the concept how to auto link between Rust and C++ Code.
  Document: https://github.com/eclipse-score/process_description/edit/main/process/process_areas/implementation/implementation_concept.rst

• Give guidance how to model Diagrams within Detail Design.
  Document: https://github.com/eclipse-score/process_description/edit/main/process/process_areas/implementation/guidance/implementation_guideline.rst

Overall:

• Everything from
  https://github.com/eclipse-score/process_description/edit/main/process/process_areas/implementation/_assets/detailed_design_example.rst has to be merged in https://github.com/eclipse-score/process_description/edit/main/process/process_areas/implementation/implementation_concept.rst
• And has to be detailed in https://github.com/eclipse-score/process_description/edit/main/process/process_areas/implementation/guidance/implementation_guideline.rst

Next steps:

• Follow up 27.11.2025 at 1pm.
• Philip will rewrite https://github.com/eclipse-score/process_description/edit/main/process/process_areas/implementation/implementation_concept.rst