Closed kKdH closed 6 months ago
Hej @erikbosch & @SebastianSchildt @ take a look and maybe we can suggest some idea's for implementation's @eriksven
This issue doesn't provide much context. If you want, we can setup a call.
Coming across this project for the first time. Speaking of HIL/SIL, for tests of "VSS-level" or similar interfaces this certainly seems a good idea. We also have some mock and replay support that might come in handy here. @eriksven ist likely the right guy for giving an overview.
When this project (again, only read the headline :D) , also thinks about lets say replaying raw Bus traces (e.g. CAN/LIN), that are not processed via KUKSA/VSS (as much as this saddens us as KUKSA developers :D), it might not be a good idea to shoehorn them through some "fake" VSS datapoints, but rather using some lower level way such as virtual interfaces might be better.
But then again, there are different levels of testing, so maybe even both is needed.
Virtual interfaces are covered with different technologies, for CAN, something based on Cannelloni: https://github.com/eclipse-opendut/opendut/pull/85
In the call we decided to go with bare MQTT in the first iteration, while keeping it as an option for the future. See also https://github.com/eclipse-opendut/opendut/issues/90#issuecomment-1954498450
kuksa.val could be a solution to exchange signals and data (in contrast to MQTT #53).
The great benefit of kuksa.val is the VSS. VSS serves as an information model about the signals their data types and characteristics. Therefor it is clear what a producer has to provide and what a consumer can expect from data exchanged by the broker.