Building a Blueprint for Commercial Fleet Management

The commercial vehicle industry is a smaller world than the passenger vehicle industry and considerably more fractured. The same is true of commercial fleet management, which presents a unique opportunity for open source. 

Much of the available equipment from fleet management service providers is highly proprietary. Often, a fleet operator will hire a company that provides a black box that runs proprietary software and connects to the cloud in the back end, and it’s all proprietary. However, the data that’s being retrieved is more or less standardized. 

This is the sweet spot of open source. In my EclipseCon talk, Trucks on a Leash: Fleet Management the Open Source Way, I’ll explain the background of the industry, highlight the opportunity for open source, and show a technology demo. But first it’s important to understand how the underlying technology works. Fortunately, the Eclipse SDV Blueprints project offers precisely that insight. 

Converging SDV Technologies Through the Blueprints Project

This is a new project, with initial code published just weeks ago. The idea behind the project is to provide blueprints for a variety of use cases. One of those is bringing together many of the underlying technologies necessary for a standardized commercial fleet management software from other projects within the Eclipse Software Defined Vehicle (SDV) Working Group ecosystem as well as the broader open source space. 

Although the individual components might initially appear to be abstracted and disconnected, they converge in some key ways.

One of the most compelling is the Vehicle Signal Specification, which is actually an initiative by COVESA. This defines a syntax and catalog of vehicle signals. Another is the data broker from the Eclipse Kuksa project, which we are using to abstract away the hardware-specific signals in commercial vehicles. Additionally, the Eclipse Leda project provides an operating system that has several relevant components for implementing SDV use cases pre-installed. The Blueprints project brings these and other components together into a prototype fleet management application. 

Vehicle Signal Specification Standardizes Semantics

An initial challenge of trying to build a de-facto standard in this sector is getting everyone to agree on a language. Individual OEMs encode the data for different vehicle signals, such as current speed, tire pressure, and fuel level, in their own individual way and send it via the Controller Area Network (CAN) bus, which enables the different electronic control units inside the vehicle to communicate. This can make it difficult to write software that will run on every vehicle. 

The Vehicle Signal Specification (VSS) addresses this challenge by providing a comprehensive signal tree encompassing over 100 different signal and sensor readings. Applications can then build on this foundation by using these standardized signals. This standard architecture becomes advantageous for OEMs, as they merely need to provide a mapping of their signals to the CAN bus and into the VSS signal tree. On the development side, any application we build doesn’t need to know how the information is being retrieved from the OEMs’ hardware; it simply requests data in the standardized format. 

Eclipse Kuksa Enables Implementation of the Specification

Of course, this all needs to be put into practice, which is where the Eclipse Kuksa data broker comes in. The data broker is an implementation of the VSS tree that provides an API for reading the value of the signals from the CAN bus, an API for subscribing to changes in those signals, and access to vehicle signals and controls by a set of vehicle services.

This provides the ability to:

• Detect and read the relevant information from the vehicle
• Retrieve the data for use and interpretation
• Update the information as needed

This application is crucial. It abstracts away the hardware specifics in each individual vehicle, which vastly reduces the cost of retrieving and applying data from commercial vehicles.

Eclipse Leda Provides the Underlying Operating System

Naturally, all software requires an operating system (OS) to function. Enter the Eclipse Leda project, which offers precisely this, along with several key capabilities that make it very useful in the commercial fleet management space. It excels in managing the software components that are running on it. Moreover, its remote management and installation capabilities stand out as a crucial asset. 

Imagine if you had to physically take your smartphone to an app store every time you wanted to update an application — chances are, you’d opt to live without that app. Similarly, the commercial fleet management space operates on the principle of remote updates and modifications. The Eclipse Leda runtime environment facilitates remote retrieval of software components from a known source, enabling seamless updates, fixes, and the addition of new capabilities. 

Eclipse Blueprints Brings Components Together

While the fleet management Blueprint project is a recent addition, it provides a comprehensive software stack, spanning from in-vehicle systems to cloud-based dashboards for data visualization. This integration of key components forms an initial template of how an SDV application could look.

However, it’s important to note that this is very much an initial version — a proof of concept. For instance, it currently samples data every 5 seconds: a valuable demonstration, but less practical in real-world scenarios. Tracking the GPS location of a vehicle every 5 seconds isn’t going to tell you very much. So, this is certainly something we’d like to improve. 

Here’s where we invite participation from both the Eclipse and commercial fleet management communities. Check out the GitHub repository and take this software for a spin. The next step is contribution, and we value all feedback — positive or otherwise. We want to know what works for you, what doesn’t, along with suggestions for enhancements. 

Notably, feedback from the fleet management industry highlights a lack of enthusiasm for proprietary in-vehicle hardware. Such hardware entails substantial effort and cost, without significant added value. This project is our invitation to make things better.