Vehicle Abstraction Layer (VAL)

Introduction

The Eclipse Velocitas project is using the Vehicle Abstraction Layer (VAL) of the Eclipse KUKSA project, also called KUKSA.VAL. It is a reference implementation of an abstraction layer that allows Vehicle applications to interact with signals and services in the vehicle. It currently consists of a data broker, a CAN feeder, and a set of example services.

Architecture

The image below shows the main components of the Vehicle Abstraction Layer (VAL) and its relation to the Velocitas Development Model.

KUKSA Data Broker

The KUKSA Data Broker is a gRPC 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.

Data Feeders

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 mappings specified in e.g. a CAN network description (dbc) file. The feeder uses a mapping file and data point meta data 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.

Vehicle Services

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 Services repository contains examples illustrating how such kind of vehicle services can be built.

Hardware Abstraction

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.

Information Flow

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.

Data flow when a Vehicle Application uses the KUKSA Data Broker.

Data flow when a Vehicle Application uses a Vehicle Service.

Source Code

Source code and build instructions are available in the respective KUKSA.VAL repositories:

• KUKSA Data Broker
• KUKSA DBC Feeder
• KUKSA example services

Guidelines

• Guidelines for best practices on how to specify a gRPC-based service interface and on how to implement a vehicle service can be found in the kuksa.val.services repository.