Open slang-telekom opened 11 months ago
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
@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?
@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.
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.
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.
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.