Open Vehicle API Component Stack

Where to find the Open Vehicle API stack: On the HPC above the middleware.

Layers & Abstraction Levels

Hardware abstraction: Allows easily access to the signals from different sources so that the whole system above can run on the local machine of the developer, a variety testing environments in the cloud (validation SIL), on a variety hardware simulation setups (HIL) and finally on a real vehicle. See also Picture Test-Validate-Release.

Vehicle abstraction: Basic Service s and Vehicle Device s allow to run the Complex Service s and term:Application s on different vehicles. Vehicle Device s and Basic Service s may not come from the same vendor.

Components

… Hardware Services

The main purpose of hardware services is the abstraction to the hardware underneath, the OS or middleware of a target platform. On the bottom side is whatever interface is provided through the OS and middleware, on the top side is the uninterpreted vehicle data to be provided to the data link. Hardware devices are tightly linked to the target platform and can be exchanged when the stack needs to run on a different platform with similar interfaces.

Note

Current supported Operating Systems: Linux (Ubuntu) & Windows. Hardware: x86 & ARM - NXP 532G

Tip

There are two components to access a CAN bus. One based on CAN sockets and one component based on the open-source library The Vector SIL Kit for running tests in the cloud.

… Data Link Layer

The data link layer demonstrates the vehicle bus abstraction and is automatically generated using the DBC (CAN Database) file describing the CAN bus layout. The code is generated by using the sdv_dbc_util utility. Its purpose is the extraction and composition of signals from and to CAN messages.

… Vehicle Devices

Vehicle devices provide a vehicle abstraction layer by interpreting the vehicle data from the data link and providing a standardized vehicle interface. The interface to the data link is described in the DBC file and code is generated using the sdv_dbc_util utility. The standardized vehicle interface is described through VSS (Vehicle Signal Specification), and the code can be pre-generated by using sdv_vss_util utility.

The main purpose of vehicle devices is to provide a low-level translation between the vehicle specific data from the vehicle bus and the standardized vehicle interface. Vehicle devices are closely coupled to the vehicle platform and can be exchanged when another vehicle is targeted.

… Basic Services

Basic services provide the lowest application layer by interfacing with the standardized vehicle interface and providing a standardized application interface. The interface to the vehicle is the same as is used by the vehicle devices and is described in VSS and interface code is automatically generated using the sdv_vss_util. The standardized application interface is also described using VSS and also interface code is automatically generated.

The basic services combine vehicle data to provide a more application friendly interface. In the easiest case, it provides a one-to-one translation between the vehicle data from the vehicle device and the application interface. Basic services should be platform and vehicle independent.

… Complex Services

Complex services provide a more complex processing of vehicle data to provide vehicle services that can be used to operate the vehicle. It can but doesn’t have to have an interface towards applications. Multiple complex services can build on top of each other. Used interfaces are compiled and code is generated using the sdv_idl_compiler.

… Application

The application provides the highest-level user interface. For demonstration purposes it visualizes the data from the example basic services and example complex service as well as from the example vehicle device when running as developer standalone application - which allows all components to run within one process, which allows data analysis and debugging without having to deal with a multi- process application.

… Interfaces

The picture shows the different components in the different layers. The standardized vehicle interfaces described through VSS (Vehicle Signal Specification) above basic service are independent from the vehicle signal data so that any complex service does not need to change when running on a different vehicle.

Application API / Vehicle Abstraction:

Must abstract the complete vehicle independent from any ECU characteristics.

Input: standardized interfaces of defined signal.

Output: Services independent from the vehicle.

Platform Abstraction / Vehicle Bus Abstraction:

Abstracts the Platform underneath so that the basic services are independent from the platform.

Input: Signal from the dispatch service

Output: Services independent from the vehicle platform.

Vehicle Device s & Basic Service s loaded at startup and run within the core process. Any complex service runs in an isolated process and can be installed, started and stopped dynamically at runtime.

The picture shows the components and in which process they are running. The connection over the border of processes will automatically be done. The required proxy & stub code must be available and loaded. The code itself is autogenerated by the idl compiler if not disabled via the parameter –no_ps.