Closed pgangula-src closed 8 months ago
Thanks for the proposal :+1:
I do not think that I fully understand the steps involved, though. Are the two steps supposed to each result into a usable system based on Zenoh? Or do both steps need to be implemented before Zenoh can be used?
Step 1 already allows you to obtain the raw protobuf data through Zenoh and publish it to anywhere. Step 2 primarily facilitates the storage of data in InfluxDB according to the relevant measurements.
Step 1 already allows you to obtain the raw protobuf data through Zenoh and publish it to anywhere.
Why would I want to let the FMS Forwarder publish data to a Zenoh router, if the data is not being processed by any component?
The FMS Forwarder is currently transmitting unprocessed data via MQTT, and we are also offering an alternative option through Zenoh. I wonder what is the question here..
Ok, then step 1 is replacing the direct (MQTT) connection between the FMS Forwarder and the Hono MQTT Adapter with a connection via the Zenoh Router, right? In such a setup the Zenoh router would need to be able to connect to the Hono MQTT Adapter and publish data to the proper topics. Is that what you have in mind?
Zenoh Router gets the data from FMS Forwarder over MQTT or Zenoh (see picture above) and processes it and puts that information into InfluxDB. Thats the scope here and we do not need to connect to Hono MQTT Adapter.
Zenoh Router gets the data from FMS Forwarder over MQTT or Zenoh (see picture above) and processes it and puts that information into InfluxDB.
In the picture above, the Zenoh router seems to require the FMS Consumer to speak Zenoh to receive the messages from the FMS Forwarder. The FMS Consumer then writes the data to Influx. To me, this looks like the outcome of an additional 3rd step? But it does not seem to reflect the outcome of step 2. That's why I'm asking ...
The idea is to include FMS consumer logic into the Router directly using Zenoh Flow. Sorry for the confusion i could perhaps suggest a better picture that makes it clear. "Step 2: FMS consumer Integration in Zenoh Router"
Ok, now I got it. Thanks for your patience ;-)
@pgangula-src can you maybe update the picture so that it reflects the intended target state? Otherwise, I believe that others will also struggle a lot with getting the idea ...
Done.!
Dear all,
I apologize for the delay, but I now have the details regarding the expected Zenoh integration in the FMS blueprint. We will submit the PR in coming days that addresses the step 1 (see below), and I would appreciate your patience and constructive feedback, as this is my first time contributing here.
Objective:
This issue is created to initiate the integration of Eclipse Zenoh into the Eclipse SDV FMS blueprint. The inclusion of Eclipse Zenoh offers a unified interface for accessing VSS (Vehicle Signal Specification) data via Kuksa, leading to several advantages:
Proposed Changes:
The integration of Eclipse Zenoh into the FMS blueprint will be realized in two steps:
Step 1: Extend FMS Forwarder to publish data in Zenoh and configure Zenoh Router to also receive data over MQTT
Step 2: FMS consumer Integration in Zenoh Router
Blueprint Suggestion: