Establish a measurement/action communication link

[eet1mu3]

[eet1mu3]

We need to discuss and decide the underlying technology. Current options are:

• MQTT https://github.com/eclipse-opendut/opendut/issues/53
• KUKSA.val / VSS https://github.com/eclipse-opendut/opendut/issues/59

[eet1mu3]

Some of my considerations, please chime in!

• For the MVP we just need some way to communicate rather simple instrumentation signals such as KL15 state, relay state, and, some low-frequency measurements for general ECU health surveillance.
• When we are looking in the future, towards integration of other vehicle signals with the final goal of providing integrated restbus simulation, KUKSA/VSS sounds very promising.
• Data model
  • on MQTT would be somewhat ad-hoc
  • on KUKSA/VSS would be more integrated, including data types, handling of target/actual etc.
• Broker
  • KUKSA is possibly more optimized for latency?
  • MQTT has various implementations
• Performance
  • unclear, possibly KUKSA is more optimized for automotive use case?
• MQTT is well established, KUKSA/VSS is new.
  • Technical Risk? Future Support?
• MQTT has lots of integration already available, even generic GUIs
• KUKSA/VSS will considerable complexity and dependency
  • how complex is creating/configuring a test setup? VSS may require more effort to get started?

[eet1mu3]

<Peer>/<Device>/<Channel>/…
 
 
<Device>
model (string)
e.g.: "Manson HCS-3404"
 
<Channel>:
Standard:
•	enable (bool)  (<- do we need an "enabled_target"?)
•	I (float)
•	U (float)
•	U_target (float)
 
Standard for relay:
•	enable (bool)
•	(anything else?)
 
 
 
Others possible sensors:
•	Temp
•	CPU
•	Memory
 
 

[kKdH]

if i understand you correctly an example for a topic to consume the current would be:

/25fedc11-d37f-4752-b20b-0f60aa1541f6/Manson-HCS-3404/I

Right?

[eet1mu3]

This would make connecting multiple power supplies of the same model impossible.

So the idea was more like this: /25fedc11-d37f-4752-b20b-0f60aa1541f6/main-supply1/0/I

Where /25fedc11-d37f-4752-b20b-0f60aa1541f6/powersupply1/model = "Manson HCS-3404"

The would then be usable for power supplies and especially relay boards with multiple channels. Of course the powersupply name would be arbitrary, so it could also be directly named Manson-HCS-3404; and if there is a second one, that could be named, for example, Manson-HCS-3404-2. Would make it easier for lab personnel to identify and handle the device.

Of course, we could just not use the channel sub-topic when the device only has one channel?

[kKdH]

ah. model is a sub-topic and "Manson HCS-3404" it's value. got it. Thank you.

For a test bench with one powersupply providing two channels it would look like this:

/25fedc11-d37f-4752-b20b-0f60aa1541f6/powersupply_0/model
/25fedc11-d37f-4752-b20b-0f60aa1541f6/powersupply_0/0/I
/25fedc11-d37f-4752-b20b-0f60aa1541f6/powersupply_0/0/U
/25fedc11-d37f-4752-b20b-0f60aa1541f6/powersupply_0/1/I
/25fedc11-d37f-4752-b20b-0f60aa1541f6/powersupply_0/1/U

May i suggest to write current instead of I and voltage instead of U?

[eet1mu3]

Added mqqt clients, one for Manson power supply and a demo one for cpu / mem /network stats: https://github.com/eclipse-opendut/opendut/commit/3074aa74bebcb33040f6f71ccef82d34e7068f2c