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