With the rise of autonomous vehicles and the increasing demand for effective fleet management, businesses are encountering challenges that require a seamless distribution of data. From vehicle tracking to teleoperation, there is a need for an efficient mechanism to manage a smooth flow of data from the vehicles to the edge and across cloud services. To tackle this challenge, the Eclipse SDV working group has combined technologies within the SDV group to create a software stack demonstrating a real-life use case of truck fleet management.
We recently achieved a significant milestone by integrating Eclipse Zenoh into the Fleet Management System (FMS) Blueprint thereby providing the capability to geographically distribute the vehicle signals to services operating across the edge and cloud. This integration uses COVESA vehicle signal specification (VSS) data models to effectively distribute vehicle signals across various services.
COVESA VSS: Structuring Vehicle Signals
COVESA VSS acts like a common language for vehicle data. It organizes information about vehicle signals in a structured way. Thereby allowing engineers working on different services in the cloud-to-thing continuum to reach consensus on standardized interfaces. This shared understanding makes the overall integration of different systems easier.
Eclipse Zenoh Integration: Enhancing FMS Blueprint
The FMS blueprint leverages on a KUKSA broker that mainly gets the vehicle signals from various bus technologies (CAN / SOMEIP etc.) and converts them to COVESA VSS, but there is a need for smart communication technology that can distribute this VSS data to a backend or to a location / service of your choice. This is where the integration of Eclipse Zenoh brings several advantages:
- Streamlined Communication: By reducing the number of hops required, Zenoh minimizes the complexity of software artifacts, streamlining communication pathways.
- Efficient Data Distribution: Zenoh excels in distributing data efficiently in proximity to the edge, catering to the demanding nature of Fleet Management Systems.
- Protocol Plugins: The Zenoh Router is equipped with plugins for various protocols and databases, ensuring seamless communication with other components if needed.
In Figure 2, the FMS forwarder is enabled to transmit data through Zenoh/MQTT, while the FMS Consumer utilizes the plugin functionality of the Zenoh Router. The FMS Consumer subscribes to VSS data via Zenoh, saving it in an InfluxDB for subsequent use by other Fleet Management Services.
Zenoh API: Simplicity is the ultimate sophistication
Let’s see how easy it is to use Zenoh to achieve this. We’ll walk you through some code examples.
Zenoh simplifies data transmission and reception with straightforward pub/sub/query abstractions. For transmitting data, it’s necessary to open a zenoh session with the default or given configuration and create a publisher to publish the data on a given Key expression. Conversely, to receive data, one must open a Zenoh session with the default or specified configuration and then create a subscriber expressing interest in a specified key expression.
Within the FMS Forwarder, we establish a Zenoh session and instantiate a Zenoh publisher to disseminate vehicle data. Since the vehicle data is received in Protobuf format, we first serialize it into a byte buffer before publication. On the consumer side of the FMS, we initiate a session and create a subscriber to retrieve data from the Zenoh infrastructure. Upon retrieval, we deserialize the byte buffer back into Protobuf format.
Below are Code snippets from Eclipse FMS blueprint for the Zenoh:
FMS Forwarder: This component publishes vehicle status information to the Zenoh router/infrastructure. The implementation involves:
- Opening a Zenoh session with configuration specified in the Docker Compose file.
- Creating a Zenoh publisher.
impl<'a> ZenohPublisher<'a> {
pub async fn new(args: &ArgMatches) -> Result<ZenohPublisher<'a>, Box<dyn std::error::Error>> {
let config = parse_args(args);
let session = Arc::new(zenoh::open(config).res().unwrap());
let publisher = session.declare_publisher(KEY_EXPR).res().unwrap();
Ok(ZenohPublisher {
// publisher
publisher,
})
}
}
Figure 3: Code Snippet for Opening a zenoh session and declaring a publisher
- An async trait is implemented to trigger the Zenoh publisher put method to publish the vehicle data from the main.
#[async_trait]
impl<'a> StatusPublisher for ZenohPublisher<'a> {
async fn publish_vehicle_status(&self, vehicle_status: &VehicleStatus) {
match vehicle_status.write_to_bytes() {
Ok(payload) => {
match self.publisher.put(payload).res() {
Ok(_t) => debug!("successfully published vehicle status to Zenoh",),
Err(e) => {
warn!("error publishing vehicle status to Zenoh: {}", e);
}
};
return;
}
Err(e) => warn!(
"error serializing vehicle status to protobuf message: {}",
e
),
}
}
}
Figure 4: Code Snippet for publishing vehicle data by zenoh publisher
FMS Consumer: This component receives data from the Zenoh router/infrastructure. The implementation steps are similar to the FMS Forwarder and involve:
- Opening a Zenoh session with configuration from the Docker Compose file.
- Creating a Zenoh subscriber to receive data.
async fn run_async_processor_zenoh(args: &ArgMatches) {
let influx_writer = InfluxWriter::new(args).map_or_else(
|e| {
error!("failed to create InfluxDB writer: {e}");
process::exit(1);
},
Arc::new,
);
let zenoh_args = args.subcommand_matches(SUBCOMMAND_ZENOH).unwrap();
let config = parse_zenoh_args(zenoh_args);
info!("Opening session...");
let session = zenoh::open(config).res().await.unwrap();
info!("Declaring Subscriber on '{}'...", &KEY_EXPR);
let subscriber = session.declare_subscriber(KEY_EXPR).res().await.unwrap();
loop {
select!(
sample = subscriber.recv_async() => {
let sample = sample.unwrap();
let cloned_writer = influx_writer.clone();
process_zenoh_message(&sample.value.payload.contiguous(), cloned_writer).await;
}
);
}
}
Figure 5: Code Snippet for Opening a zenoh session and declaring a subscriber
Zetta Platform Integration: Unifying Cloud-to-thing continuum
We further took this integration one step ahead by deploying an FMS blueprint software stack using the Zetta Platform. A Platform-as-a-Service that provides you with a single point of control to provision, manage, and monitor the Zenoh infrastructure on the cloud-to-thing continuum. Thereby allowing your Zenoh infrastructure running on premises / vehicles to connect to various services that are deployed across the continuum together with a communication that is end-to-end secured.
Figure 6 shows the integration of vehicle services over Zetta Platform, including the in-vehicle FMS Forwarder and the Consumer/Server (also known as Fleet Manager) over Zenoh routers that are spread across the world and lets your applications (vehicles and services) effortlessly exchange data that are connected to the Zetta PaaS infrastructure, there by simplifying system deployment and data distribution.
Vehicles equipped with the FMS Forwarder component can now leverage on Zenoh routers to store data at the edge, closer to the data source or where it needs to be consumed. The FMS Consumer can then effortlessly access this required information using the Zenoh Query mechanism and the Zenoh’s link-state algorithms identify the shortest and most efficient path for retrieving the data. This can be considered as a built-in load balancing feature where you decentralize the data distribution that can also handle sudden network failures.
At the same time, Zenoh routers also support storing the same data across multiple storage points across the Zenoh infrastructure combined with data replication across the storage points thereby providing redundancy. By storing data at the edge, the system eliminates the constant reliance on a distant and centralized monolithic cloud infrastructure. Therefore, the deployed applications over Zenoh infrastructure guarantees efficient fleet management that is resilient to growing demands of Fleet Management.
Figure 7 displays the vehicle data that is published into an InfluxDB that is later displayed over Grafana Dashboard.
In conclusion, Eclipse Zenoh provides an efficient wire protocol, lightweight discovery, distributed storages, adaptive routing algorithms that prove highly responsive in dynamic environments and topology changes even in the face of mobility. That results in optimal latency and resource consumption of your vehicle applications in decentralized distributed cloud-to-thing continuum, that are critical to managing a fleet.
FOLLOW
