=Paper=
{{Paper
|id=Vol-3028/D2-02-ESAAMM_2021_paper_3
|storemode=property
|title=Eclipse KUKSA.val for SCR Anti-Tampering Monitoring in Heavy Vehicles
|pdfUrl=https://ceur-ws.org/Vol-3028/D2-02-ESAAMM_2021_paper_3.pdf
|volume=Vol-3028
|authors=Junhyung Ki,Sebastian Schildt,Andreas Hastall,Sven Erik Jeroschewski,Robert Hottger
}}
==Eclipse KUKSA.val for SCR Anti-Tampering Monitoring in Heavy Vehicles==
https://ceur-ws.org/Vol-3028/D2-02-ESAAMM_2021_paper_3.pdf
Eclipse KUKSA.val for SCR Anti-Tampering
Monitoring in Heavy Vehicles
Junhyung Ki Sebastian Schildt
Dortmund University of Robert Bosch GmbH
Applied Sciences and Arts Corporate Research
junhyung.ki001@stud.fh-dortmund.de sebastian.schildt@de.bosch.com
Andreas Hastall Sven Erik Jeroschewski Robert Höttger
Robert Bosch GmbH Bosch.IO GmbH Materna Information & Communications SE
Powertrain Solutions Expert Squad - Open Source BL Digital Transformation
andreas.hastall@de.bosch.com svenerik.jeroschewski@bosch.io robert.hoettger@materna.de
Abstract—Modern internal combustion engines have several trucks on the road, which is cost- and time consuming and does
advanced exhaust treatment systems to meet emission standards not scale.
and legislation. In case of Selective Catalytic Reduction (SCR) for DIAS1 , a joint European research and development project,
diesel engines, a catalyst (“AdBlue”) is used as consumable. This
incurs costs for the operator of diesel vehicles and provides an has the goal to help prevent or uncover these manipulations.
incentive to unlawfully circumvent and shut down those systems. The DIAS approach to detect tampering is two-fold: Inside a
This case study presents how the Eclipse KUKSA stack has vehicle, data from various sensors is gathered and a valida-
been used to realize an anti-tampering system for commercial tion of the gathered data can be performed to detect values
heavy-duty trucks exhaust systems. We show, how the in-vehicle inconsistent with current operating conditions. As computa-
KUKSA.val software and the KUKSA.cloud components can be
used to collect relevant data from a real heavy-duty truck and tional power in a vehicle is limited and it is to be expected
send them to the cloud for further analysis. that tampering methods get more intricate (this has already
happened in the past), the gathered data is transmitted to a
I. I NTRODUCTION cloud backend, where a more complex analysis over longer
time frames is possible.
Modern vehicles with internal combustion engines are
equipped with exhaust treatment systems that drastically re-
duce the emission of harmful exhaust gases. Modern exhaust
treatment systems for diesel engines include an SCR (Selective
Catalytic Reduction) system to reduce emission of nitrogen
oxides (N Ox ). An SCR converts N Ox into harmless nitrogen
(N2 ) and water (H2 0) with the help of a catalyst fluid. The
catalyst, an urea (CO(N H2 )2 ) - water solution, is a fluid, also
called “Diesel exhaust fluid” (DEF) [1] or “AdBlue”
Just like the fuel itself, the DEF is a consumable. Costs
for an operator can reach up to 1500 USD/year for a com-
mercially operated heavy truck. This provides the incentive to
maliciously interfere with the correct operation of the exhaust
treatment system. There are companies that offer facilities
and services to disable these systems. Common tampering
methods are small hardware modules connected to internal Fig. 1: Typical AdBlue Emulator
busses or diagnostics interfaces of a vehicle injecting faulty
data regarding the level of the catalyst or measured N Ox Getting data from a vehicle in a safe and secure manner is a
values, combined with disabling components of the exhaust challenging and recurring task when developing applications
treatment. For common engines, tampering hardware (see for connected vehicles. Not only is this task very complex,
Figure 1 for an example) can be obtained for a one-time most of the time the solution is not portable due to the het-
investment of less than 30 USD. A vehicle modified in such erogeneity and specifics of the underlying system architecture.
a way can still operate with its full performance but will emit The KUKSA.val project aims to ease this task by abstracting
harmful substances significantly above the legal limit. Such
manipulation is difficult to detect, without randomly inspecting 1 https://www.dias-project.com/
Copyright © 2021 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
operation of a vehicle (e.g. Vehicle/Speed), and attributes
that are expected to be static over the lifetime of a vehicle (e.g.
Vehicle/VehicleIdentification/VIN).
B. W3C VISS
While VSS describes the structure of signals in a vehicle,
the W3C Vehicle Information Service Specification (VISS) [3]
defines a websocket-based protocol to access such signals
using either a query response pattern or publish/subscribe
mechanism. Currently, the second iteration of VISS, VISS2
is under development2 . Being a network-based API VISS is
a good fit for modern Vehicle Computer Architectures, where
different safety and security zones are separated by hypervi-
sors or container technologies. Instead of linking to software
components, they can be accessed through the network by
other (micro-)services running in other containers, hypervisor
domains or computers. Basic encryption, authentication and
integrity can be provided by using standard TLS mechanisms.
Fig. 2: Genivi VSS structure
C. Eclipse KUKSA
Eclipse KUKSA provides building blocks for the creation
the underlying systems through the provision of a server with
of ecosystems around applications in connected vehicles. On
which other applications in the vehicle can interact based on
a high-level Eclipse KUKSA differentiates between the in-
a standardized data model and API. By doing so applications
vehicle side and the cloud backend. The in-vehicle platform
can collect vehicle data in a safe, secure and, most importantly,
allows and simplifies the execution of applications in a ve-
portable manner.
hicle. With the cloud backend it is possible to handle the
In this case study we outline the system architecture and
data originating from the in-vehicle applications. In addition,
data model for an integrated system to detect exhaust treatment
KUKSA.cloud can manage the distribution and roll-out of
tampering and present a prototype that has been created using
applications to the vehicle.
components from Eclipse KUKSA which is an open source
software stack for building connected vehicle ecosystems. D. Eclipse KUKSA.val
We present how to access data in a heavy-duty truck and
Eclipse KUKSA.val3 is an in-vehicle component from the
introduce the necessary extensions enable the KUKSA data
Eclipse KUKSA stack. KUKSA.val is a server that man-
feeder component to work with heavy-duty vehicles. Finally,
ages VSS data and provides them via the VISS protocol
a working prototype of the system has been tested in a real
to other applications running in the vehicle in a safe and
heavy-duty truck.
secure manner. Written in C++, KUKSA.val offers a small
II. B UILDING BLOCKS footprint making it suitable running in a vehicle computer.
In our system we use various existing technologies and KUKSA.val implements Version 1 of the VISS protocol with
standards, which we will explain in the following. some extensions, most notably a security mechanism based on
JSON Web tokens [4] providing fine-grained access control to
A. Genivi VSS each element in the VSS tree. Additionally, it supports dy-
The Genivi Vehicle Signal Specification (VSS) [2] intro- namic extension/modification of the VSS tree during runtime
duces a domain taxonomy for vehicle signals. The goal is to and provides a Python library wrapping the VISS websocket
create a common understanding of vehicle signals in order to protocol to simplify application development. KUKSA.val is
reach a “common language” for vehicle data independent of optimized to run in a light-weight container environment.
the protocol or serialization format. VSS can be used as stan- E. Eclipse KUKSA.cloud
dard in automotive applications to communicate information
related to the vehicle, which is semantically well defined. It The cloud backend of the Eclipse KUKSA ecosystem4 is
focuses on vehicle signals, in the sense of classical sensors and a composition of multiple open source projects and KUKSA
actuators usually connected to the “deeply-embedded” ECUs specific components. Many of the adopted technologies are
as well as data which is more commonly associated with the coming from the community around the Eclipse IoT working
infotainment systems. A simplified structure of the VSS model group. The current version of the KUKSA.cloud is tailored to
is shown in Picture 2. run in a Kubernetes environment and can be deployed with a
A VSS tree consists of three basic types of nodes: Branches 2 https://github.com/w3c/automotive
describe the hierarchy of signals (e.g. Vehicle.Cabin), 3 https://github.com/eclipse/kuksa.val
sensors describe values that are expected to change during the 4 https://github.com/eclipse/kuksa.cloud
KUKSA.cloud specific Helm Chart. Besides the management in the 29 bit CAN identifier, where data belonging to a PGN
of applications on a vehicle, the KUKSA.cloud allows the can span multiple CAN messages.
ingestion of data coming from the vehicles. In this case study
we are mainly dealing with the data aspect where the data III. A NTI TAMPERING S YSTEM
ingestion is covered by running Eclipse Hono 5 within the As lined out in the introduction, a resilient anti-tampering
KUKSA.cloud. system relies on in-vehicle components as well as a powerful
Eclipse Hono is a communication hub that provides in- cloud backend. In the vehicle data needs to be collected and
terfaces and endpoints for connecting a large numbers of transmitted. As upcoming vehicle platforms include powerful
IoT devices to a backend and enables interaction with them computing units, data can be processed on-board to detect
in a uniform way regardless of the device communication many naive forms of tampering. However, compared to the
protocol. In that regard, Eclipse Hono has a “southbound” cloud, a vehicle’s computational resources are still limited.
API designated to be used by the IoT devices like in our case Sending gathered data to a cloud backend gives the chance
heavy-duty vehicles and a “northbound” API which allows to run more complex algorithms. For example more precise
other applications in a cloud backend to consume the data engine models and longer time frames can be taken into
coming from the devices. Similarly, it is also possible to send account. Also, even with modern vehicle computers it is to
data through the northbound API from the cloud backend to be expected that cloud services can be updated faster.
devices connected at the “southbound” API. To support a wide
A. Architecture
range of devices and implementations, Eclipse Hono offers
the “southbound” API for a number of protocols like HTTP, Figure 3 shows the overall system architecture and compo-
MQTT or CoAP through different protocol adapters which nents. The prototype is built around a Raspberry Pi 4 SBC
are implemented as individual micro-services. These protocol running Linux, allowing a desk setup as well as connecting
adapters internally convert the messages to the AMQP 1.0 to a vehicle. Additionally, a Pi is roughly comparable to
protocol which is currently used for Hono’s “northbound” API. upcoming vehicle computers in terms of computing power
Since Eclipse Hono is designed to be highly scalable, it is a and memory. Data is received using the standard Linux socket
feasible option for ingesting data from a large fleet of vehicles. CAN interface. This way either simulated CAN traces can be
Furthermore, we are using a Hono-InfluxDB connector 6 played or the Pi can be connected to an existing CAN network.
that is maintained within the KUKSA.cloud project . This Raw CAN/J1939 data is processed by the DBCFeeder (see
connector listens at the “northbound” API of Eclipse Hono Section III-C) and converted to valid VSS signals that are fed
for new data and then writes it into the time-series database, into the KUKSA.val server.
InfluxDB 7 . Storing the data into a database makes it easily The cloudfeeder component connects to the KUKSA.val
accessible for further processing or visualization like in our server and collects the required data in VSS format via VISS.
case using a Grafana8 dashboard. It will then upload the collected data to the cloud. Optionally,
(pre)processing on the vehicle is possible.
F. SAE J1939
B. VSS Model
While VSS, VISS and KUKSA.val offer useful abstrac-
tions dealing with vehicle data and enable rapid function Not all the signals required for monitoring the exhaust
development, the majority of data in a vehicle originates system are part of the VSS standard catalog. However, the
from deeply embedded ECUs connected to low bandwidth standard tree provided by VSS can be extended with custom
busses such as CAN [5]. Standard CAN is a simple two-wire signals. Figure 4 shows all signals collected for our exhaust
communication protocol where messages are identified by 11 treatment monitoring. While algorithms for anti-tampering de-
or 29 bit identifiers including up to 8 bytes of payload. tection probably need to be parameterized differently depend-
In addition to CAN, SAE J1939 [6] standard is a higher ing on each specific engine type, the input data required from
level protocol that uses the CAN Bus technology as a physical a vehicle will be similar. By mapping data to a common VSS
layer. It is used for communication and diagnostics among model, the software module for accessing data and transmitting
vehicle components. Originating in the car and heavy-duty it to a cloud backend can be reused across different vehicles.
truck industry in the United States, it is now widely deployed C. Reading J1939 data
in heavy-duty vehicles around the world. In addition to the
standard CAN Bus capabilities, SAE J1939 supports node As mentioned in Section II-F, relevant data from heavy-
addresses, and it can deliver data frames longer than 8 bytes duty vehicles is available via the J1939 protocol based on
(up to 1785 bytes). Signals are not identified by the raw CAN CAN. To read data from a real truck we equipped the Pi with
ID, but by a Parameter Group Number (PGN), that is encoded a dual channel CAN shield9 . As most vehicles have several
CAN buses and not all data is available on all of them, a dual
5 https://www.eclipse.org/hono/ channel shield gives the opportunity to easily tap two busses
6 https://github.com/eclipse/kuksa.cloud/tree/master/utils/hono-influxdb-
at once.
connector
7 https://github.com/influxdata/influxdb 9 https://wiki.seeedstudio.com/2-Channel-CAN-BUS-FD-Shield-for-Raspb
8 https://grafana.com/oss/grafana/ erry-Pi/
the retrieved data using a custom pre-processor script, and
finally transmits the result data to the cloud via MQTT. The
Cloud pre-processor script can be changed depending on the kind of
Cloud
Platform processing that is desired on-board the vehicle.
Figure 6 shows the sequence of how the CloudFeeder
works. In our setup the CloudFeeder is set up to transmit
data to an Eclipse Hono instance running in the cloud.
vss_rel_2.0.json E. Cloud setup
VSS
In-vehicle Database
(kuksa.val) Tree The CloudFeeder uses MQTT to connect to an Eclipse
dbcFile.dbc Hono MQTT protocol adapter. We are using the KUKSA.cloud
CAN frame
Interpretation dbcfeeder.py
kuksa-val-server cloudfeeder.py InfluxDB Connector, which receives data from Hono and puts
(vehicle signal specification)
mapping.yml it into the time-series database InfluxDB.
Mapping
A custom diagnostic routine 11 can access the data from
the InfluxDB and perform analysis on historic data to detect
anomalies that can not be detected in a vehicle. The cloud
CAN Interface
(can0 or vcan0) analytics can be updated more frequently to keep up with
Raspberry Pi 4
novel tampering methods, and it can perform more compute
In-vehicle
intensive analytics, such as incorporating detailed models of
Platform
a specific internal combustion engine. Having the data of a
ECU
larger number of vehicles at hand also offers the potential to
or
apply more sophisticated algorithms for automated anomaly
Playing a logfile Connecting to CAN
Data Input
Truck
detection.
The raw and processed data stored in InfluxDB can also be
Fig. 3: Exhaust Anti-Tampering System Architecture monitored in custom Grafana Dashboards (see Figure 7c).
IV. R EAL -W ORLD T EST
KUKSA.val already offered a python-based DBCFeeder
component to read CAN data and map it to the VSS tree. To validate our setup we tested it in a real truck. The
A DBC file is an ASCII file describing which CAN frames test vehicle used by the DIAS project is a Ford Otosan F-
contains which signals and what conversions are required. This MAX heavy duty truck (Figure 7a. This truck is modified, so
is important, as most CAN data is not directly encoded in SI that the in-vehicle CAN busses and measurement equipment
units, but instead the range and resolution is space-optimized is available for easy access in the cabin (Figure 7b). It is
for a specific use case, so often an offset and scale factors important to note, the truck’s ECUs do not need to be modified.
need to be applied. However, we discovered the DBCFeeder The only component required to enable this use case is the
was only able to deal with raw CAN frames, and was not Raspberry connected to the vehicle’s busses providing a run-
J1939 aware. time for the in-vehicle part of the software stack and Internet
For this case study we extended the KUKSA DBCFeeder access. In a series production vehicle, it is expected, that
with J1939 support. As the DBCFeeder included in the software running on the Pi will be running on a Vehicle
KUKSA.val is Python-based, we leveraged support of an Computer inside the truck alongside other services. Figure 7c
existing Python J1939 implementation10 . When dealing with shows a Grafana dashboard that is updated live during the test
a J1939 system and an associated DBC file describing J1939 drive.
PGN units, the DBCFeeder can be started with the “-j1939” During the test drives in the Stuttgart region the system
option. This will switch the Raw CAN reader normally used performs as expected. The major challenge is dealing with
by the DBCFeeder with the J1939 stack reassembling PGN intermittent Internet connectivity. While our simple prototype
data from the raw CAN frames, before decoding and mapping still has some potential for optimization in this regard, it is not
the data to VSS. As multiple DBCFeeder instances can run a blocker for the DIAS use case: Anti-tempering monitoring
in parallel, you can process raw CAN frames or J1939 PGN does not require real-time data. Real-time analysis is done
data at the same time (see Figure 5). The initial J1939 support directly on the vehicle, and any errors are logged similar to
developed has also been merged upstream, so it is available other error conditions. In cases of no connectivity, data can
to all KUKSA.val users. be cached in the vehicle and transmitted once connectivity is
available again.
D. Processing and Transmitting The availability of connectivity hardware can be expected
CloudFeeder is a module that retrieves the observed signals’ for all vehicles in the near future. In fact, many heavy-duty
values from the in-vehicle KUKSA.val-server, pre-processes trucks already contain some form of connectivity for fleet
10 https://pypi.org/project/j1939/ 11 https://github.com/junh-ki/dias kuksa/
Vehicle AmbientAirTemp
AfterTreatment OBD Drivetrain
NOxLevel Aftrtrtmnt1SCRCtlystIntkGasTemp FaultDetectionSystem BarometricPress FeulSystem
FuelSystem InternalCombustionEngine
Aftertreatment1IntakeNOx
NOxIntake ExhaustMassFlow ProtectLampStatus EngCoolantTemp TimeSinceEngineStart Engine
Aftertreatment1OutletNOx RedStopLampState EngPercentLoadAtCurrentSpeed EngRefenceTorque
AmberWarningLampStatus EngSpeedAtIdlePoint1
MalfunctionIndicatorLampStatus EngSpeedAtPoint2
FlashAmberWarningLamp EngSpeed
FlashMalfuncIndicatorLamp ActualEngPercentTorque
: Branch
FlashProtectLamp NominalFrictionPercentTorque
: Attribute
: Sensor FlashRedStopLamp
Fig. 4: VSS signals used for exhaust treatment monitoring
CANbus tries to tackle this problem using a combination of on-board
Mapped signals Decoded signals Raw CAN frames
and off-board diagnostic of vehicle data. In this case study, we
KUKSA.val dbcfeeder.py dbcreader.py
have presented a system for Exhaust System Anti-Tampering
Decoded Signals
Mapped signals
Direct CAN Messages monitoring using open source components from the Eclipse
dbcreader.py
dbcfeeder.py
Decoded signals
J1939reader.py
PGN Messages
j1939.ElectronicControlUnit
(j1939 python package)
KUKSA ecosystem.
CAN Interface:
Raw CAN frames
CAN0 or VCAN0
We were able to collect the relevant data from heavy-duty
Fig. 5: Two dbcfeeders feeding a single KUKSA.val instance trucks, processing them on board the vehicle and transmitting
them to the cloud for further analysis. The system has been
tested extensively with simulated CAN traces and inside a real
Cloud
CloudFeeder VSS Server Pre-processor
(Hono) heavy-duty truck. To enable this we extended KUKSA.val with
J1939 support and provided it upstream.
do_getValue
In the future, the system can be extended with more robust
caching during times of no connectivity. Additionally, the
value returned
data received from CAN busses can be authenticated. While
preprocessing most communication in contemporary vehicle is unencrypted
and unauthenticated, there are upcoming standards providing
processed JSON telemetry data returned security on the level of automotive field busses such as CAN.
One example is AutoSar SecOC [10], that can provide authen-
mosquitto_pub (transmits telemetry data via MQTT)
tication of individual CAN messages. On vehicles supporting
such standards, they are a good first line of defense.
This example showcases the applicability of open source
Fig. 6: Cloudfeeder sequence diagram components in the automotive domain. While the technology
behind exhaust treatment systems, and advanced tampering
detection mechanisms are highly proprietary in nature, it is still
management purposes. Additionally, existing or upcoming possible to leverage the power of open software and standards.
legislation might require to provide connectivity hardware to By using the open VSS standard and existing open source
a vehicle: In the EU, the eCall regulation [7] already requires components on modern vehicle computers, applications for
cellular connectivity in every passenger vehicle type-approved gathering, processing and transmitting data to a cloud backend
after March 2018, China already requires telemetry for all can be realized in a fast and cost-effective manner.
EVs [8] and a legislative initiative by the German ministry
of transport aims to require that all vehicles with autonomy ACKNOWLEDGMENTS
functions have to be connected “all the time” [9]. This paper is supported by European Union’s Horizon 2020
research and innovation programme under grant agreement No
V. C ONCLUSION & O UTLOOK 814951, project DIAS (https://dias-project.com/).
We have introduced the problem of exhaust treatment R EFERENCES
system tampering. Potential cost savings incentivize actors
[1] “ISO 22241-1:2019- Diesel engines — NOx reduction agent AUS
to unlawfully interfere with the correct function of heavy 32 — Part 1: Quality requirements,” International Organization for
vehicle’s exhaust treatment system. The DIAS research project Standardization, Standard, 2019.
(a) F-MAX test vehicle (b) Setup in cabin (c) Dashboard Overview
Fig. 7: Testing System in a Heavy-Duty Truck
[2] Vehicle Signal Specification, GENIVI Alliance Std., 2020. [Online]. [7] “REGULATION (EU) 2015/758 concerning type-approval requirements
Available: https://genivi.github.io/vehicle signal specification/ for the deployment of the eCall in-vehicle system based on the 112
[3] P. Kinney, A. Crofts, W. Lee, and K. Gavigan, “Vehicle information service and amending Directive 2007/46/EC,” European parliament and
service specification,” Candidate Recommendation, Feb. 2018, council, Tech. Rep., 2015.
https://www.w3.org/TR/2018/CR-vehicle-information-service- [8] B. Martens and B. Zhao, “JRC Digital Economy Working Paper - Data
20180213/. access and regime competitionA case study of car data sharing in China,”
[4] M. Jones, J. Bradley, and N. Sakimura, “Json web token (jwt),” European Commision, Tech. Rep., Aug. 2020.
Internet Requests for Comments, RFC 7519, May 2015, http: [9] German Ministry of Transport, “Entwurf eines Gesetzes zur AÄnderung
//www.rfc- editor.org/rfc/rfc7519.txt. [Online]. Available: http: des Straßenverkehrsgesetzes und des Pflichtver- sicherungsgesetzes –
//www.rfc-editor.org/rfc/rfc7519.txt Gesetz zum autonomen Fahren,” Feb. 2021. [Online]. Available:
[5] “ISO 11898-1:2015- Road vehicles — Controller area network (CAN) https://www.bmvi.de/SharedDocs/DE/Anlage/Gesetze/Gesetze-19/gese
— Part 1: Data link layer and physical signalling,” International Orga- tz-aenderung-strassenverkehrsgesetz-pflichtversicherungsgesetz-auton
nization for Standardization, Standard, 2015. omes-fahren.pdf
[6] J1939 Standards Family, Society of Automotive Engineers SAE Std., [10] Specification of Secure Onboard Communication, AUTOSAR Std., 2017.
2013. [Online]. Available: https://www.sae.org/standardsdev/groundveh [Online]. Available: https://www.autosar.org/fileadmin/user upload/stan
icle/j1939a.htm dards/classic/4-3/AUTOSAR SWS SecureOnboardCommunication.pdf