The KUKSA.VAL provided by the Eclipse KUKSA project is a reference implementation of a Vehicle Abstraction Layer (VAL). It offers Vehicle Applications, downloadable from or even runnable in the cloud, to interact with the underlying vehicle hardware and software in a unifom way - independent of model, make or even manufacturer.
This independency is gained by supporting standarized data models and service catalogs like the COVESA Vehicle Signal Specification (VSS) and the Vehicle Service Catalog (VSC). Although encouraged, the usage of those COVESA (or other) specifications is neither a premise nor is it a limitation. It is an offer: You are completely free to chose whatever vehicle model and service catalog you want to use and also to create your own ones. The usage of the COVESA specification is no limitation, as both allow for proprietary extensions to enable bringing in your latest innovations.
The vehicle data (signals, sensors, and other states) provided to the applications is accessible via the central component KUKSA Data Broker. Access to vehicle functions and controls (e.g. actuators) is provided via a set of vehicle services. The data broker and the vehicle services are offering gRPC based interfaces.
A developer of a Vehicle Applications could either use the gRPC/Protobuf tooling for generating gRPC skeletons in the preferred programming language and bind his/her code directy to those. A more comfortable way to develop vehicle applications is offered by the Eclipse Velocitas project. The Eclipse Velocitas project cares for supporting the developer of an vehicle app to abstract from the gRPC-based access to the VAL. It offers a toolchain and programming language-specific SDKs and data models for interacting with the vehicle.
The image below shows the main components of the Vehicle Abstraction Layer (VAL) and also shows its relation to the Velocitas Development Model (in the upper left corner).
The KUKSA Data Broker is a gRPC-based service acting as a broker of vehicle data / data points / signals. It provides central access to vehicle data points arranged in a - preferably standardized - vehicle data model like the COVESA Vehicle Signal Specification (VSS) or others. It is implemented in Rust, can run in a container and provides services to get datapoints, update datapoints and for subscribing to datapoints. Filter- and rule-based subscriptions of datapoints can be used to reduce the number of updates sent to the subscriber.
Conceptually, a data feeder is a provider of a certain set of data points to the data broker. The source of the contents of the data points provided is specific to the respective feeder.
As of today, the Vehicle Abstraction Layer contains a generic CAN feeder (KUKSA DBC Feeder) implemented in Python,
which reads data from a CAN bus based on specifications in a e.g., CAN network description (dbc) file.
The feeder uses a mapping file and data point metadata to convert the source data to data points and injects them into the data broker using its Collector gRPC interface.
The feeder automatically reconnects to the data broker in the event that the connection is lost.
A vehicle service offers a gRPC interface allowing vehicle apps to interact with underlying services of the vehicle. It can provide service interfaces to control actuators or to trigger (complex) actions, or provide interfaces to get data. It communicates with the Hardware Abstraction to execute the underlying services, but may also interact with the data broker.
The KUKSA.VAL is providing examples how such kind of vehicle services could be built-up in the kuksa.val.services repository.
Data feeders rely on hardware abstraction. Hardware abstraction is project/platform specific. The reference implementation relies on SocketCAN and vxcan, see https://github.com/eclipse/kuksa.val.feeders/tree/main/dbc2val. The hardware abstraction may offer replaying (e.g., CAN) data from a file (can dump file) when the respective data source (e.g., CAN) is not available.
The vehicle abstraction layer offers an information flow between vehicle networks and vehicle services. The data that can flow is ultimately limited to the data available through the Hardware Abstraction, which is platform/project-specific. The KUKSA Data Broker offers read/subscribe access to data points based on a gRPC service. The data points which are actually available are defined by the set of feeders providing the data into the broker. Services (like the seat service) define which CAN signals they listen to and which CAN signals they send themselves, see documentation. Service implementations may also interact as feeders with the data broker.
Source code and build instructions are available in the respective KUKSA.VAL repositories:
- Please see the vehicle service guidelines for information on how to implement a Vehicle Service.
- Please see the interface guideline for best practices on how to specify a gRPC interface.