Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrate Eclipse SDV Developer Console into the Blueprint #15

Open
slang-telekom opened this issue Oct 4, 2023 · 5 comments
Open

Integrate Eclipse SDV Developer Console into the Blueprint #15

slang-telekom opened this issue Oct 4, 2023 · 5 comments

Comments

@slang-telekom
Copy link

The purpose of the Eclipse SDV Developer Console (DCO), see https://gitlab.eclipse.org/eclipse/dco/developer-console, is to enable Quality Assurance for new Vehicle Software Releases by applying a QualityGate process to these Releases. To enhance the current capabilities of the Fleet Management Use-Case, it could be extended to support and apply QualityGates by integrating the SDV Developer Console. This QA step would be situated before the currently already discussed extension within #5 . After passing the to-be-defined Quality Gates DCO could produce as an output the right input format for the Kanto Update Manager.

@tspreck
Copy link

tspreck commented Oct 6, 2023

hey @slang-telekom this idea sounds cool, I'm curious to see how this could all fit together - perhaps we create a new branch for this exploration? Let us know @sophokles73 @eriksven if you need any help with the initial setup. Please raise issues if you find the documentation lacking or better a PR with improvements

@sophokles73
Copy link
Contributor

@slang-telekom this sounds interesting :-) I have read through the README of the DCO project but I have to admit, that I didn't really understand what a Track, a Scenario and a Simulation would actually be in a particular use case. Would it make sense to define some concrete examples for the FMS blueprint?

@slang-telekom
Copy link
Author

slang-telekom commented Oct 13, 2023

@sophokles73 that is totally understandable. Will add that part to the DCO documentation asap. For now in a Nutshell:

  • Track is a combination of a Software Packages and Test Devices/Vehicles, where the Package gets roled out for testing purpose, so technically it is just an entity that has 1:n relations to Software Packages and Test-Devices

  • Scenario is only relevant in case you want the Software Package to be tested in a Simulator, then the Scenario would describe what should be simulated (our Hack-Challenge for November covers this topic), but it is irrelevant for the integration into the FMS Blueprint

  • Simulation is the appliance of a Scenario in combination with a Software Package, not relevant for the FMS Blueprint

The concrete example is quite simple: we would have to define a Track that a new Software Package for the FMS Vehicles has to pass, before it can be roled out onto these Vehicles. The Track would normally define some QualityGates that need to be passed, here we are completely free to decide what that could be. In the first step maybe just a manual "checkmark" by someone who is allowed to do such a kind of role-out.

@sophokles73
Copy link
Contributor

I see. What is the output of running through this process within DCO? Can we trigger the execution of some logic as the result? I could then imagine that we use this in conjunction with #5 and produce a desired state document when all checks pass, which can then be used to install/update the components on the vehicle.

@slang-telekom
Copy link
Author

Output can be anything we want. If you can prepare or describe a desired state document, we can implement it at as output of the SDV Fleet Management Blueprint Track.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants