1 Introduction

Far more than 600 million cars have entered the streets worldwide [26] in the last decade. With very few exceptions, each of them is equipped with a standardized On-Board-Diagnostics (obd  [41]) interface. Five years ago, it surfaced that many of the cars out there do not adhere to the regulatory framework with which they are supposed to comply. A number of undeniable proofs of tampered emission cleaning systems in passenger cars [6, 15, 34] are known by now. This scandal was made possible by legislatory frameworks that imposed very few and precisely defined emission tests, to be carried out under laboratory-like conditions on chassis dynamometers upon type approval of a new car model [7, 45].

Since then, there has been a growing understanding that measurements of emission and fuel or battery consumption should best be carried out in non-artificial contexts. As a result, the first test framework for testing on public roads, the real driving emissions (rde) test, has been developed [42, 44] and is being rolled out for car model approval in Europe and other entities of jurisdictions.

The rde regulation specifies the conditions under which a car trip qualifies as a valid rde test. These conditions refer to the trajectory driven, duration, altitudes, speeds, as well as the dynamics of the driving profile [42]. By combining the information available at the obd port and the position of the car, it is possible to cast rde testing into a runtime monitoring [29, 31, 46] problem. Indeed, we have shown in earlier work [25] how to formalize the rde regulations in rtlola  [4, 22], a real-time extension of the stream-based specification language Lola [16]. Lola combines the ease of use of rule-based specification languages with the expressive power of heavy-weight scripting languages or temporal logics. The eponymous framework generates runtime monitors for such specifications, some of which were successfully deployed, for instance, on unmanned aircraft [4, 43].

An official rde test requires a calibrated portable emissions measurement system (pems) to be connected to the car’s exhaust pipe while driving the test, so as to correctly quantify the amount of exhaust emissions induced. The purchasing costs of a pems are in the order of € which is close to unaffordable even in a research context. However, many car models expose a variety of diagnosis data through obd, and an obd-to-Bluetooth adapter can be purchased for around €. Which types of data are exposed depends on the type of engine, emission cleaning system, and other components in use. There are several minimal combinations of obd data giving good approximations of emitted gases. All combinations in particular rely on the car model exposing the sensor readings of an \(\textrm{NO}_x\) sensor deployed at the rear of the exhaust pipe. Such a sensor is typically part of the exhaust cleaning control loop of systems using selective catalytic reduction.

Fig. 1
figure 1

LolaDrives

Full size image

Contribution This paper introduces LolaDrives, an Android app enabling car owners to carry out real driving emission tests with little investment. Prerequisites to use this app are (i) an Android phone, (ii) an obd-to-Bluetooth adapter, and (iii) a car model that does indeed expose the needed values via obd. If the latter is not the case, the app can still serve the user as a convenient personal monitoring and logging device for the many quantities exposed while driving. We provide a detailed account of LolaDrives, its look-and-feel, and its inner working. Moreover, we explain the details of our Car Data Platform (cdp), a set of tools and services for car-related, data dependent research. We also discuss our approach to testing LolaDrives during code development.

A structural overview of LolaDrives is depicted in Fig. 1. At the core of the app is an Android version of the rtlola engine [22]. The engine is strictly separated from the data acquisition and the rtlola rde specification. This separation makes it possible to reuse the approach in other runtime monitoring contexts, be it of espresso machines via usb, or drones via Wi-Fi. In both cases, it is especially the specification in rtlola that needs to change, not the engine. Car sensor data are acquired via Bluetooth from the obd device, and combined with location data provided by Android’s gps service. The data streams are recorded for later diagnosis in a Portable Car Data Format file (pcdf). Anticipating future application scenarios involving crowd sourcing car data, we advertise the app as part of the car data platform, which includes an upload facility for donating drive records. While driving, the app’s user interface (ui) displays diagnostic information to the user, both regarding the correct execution of an rde test drive and the car’s emission data.

Notably, the lack of any calibration and the unknown precision of the data exposed by the car manufacturer via obd make it, in a legal sense, impossible to consider the rde test results reported by LolaDrives as anything more than indicators of the car’s rde behaviour.

Table 1 Some constraints for the three modes of rde tests [25]
Full size table

This article is an extended version of a conference publication [9] where a preliminary version of the app was showcased. We here present the latest version of LolaDrives, which has been extended by on-device analytics and a more intuitive user interface. Moreover, we explain the details of our Car Data Platform, a set of tools and services for car-related, data-dependent research. We also provide insights into how to test LolaDrives without having a real car at hand. Finally, we present our findings based on four additional on-the-road experiments with LolaDrives.

2 Context

In 2015, the Diesel Emissions Scandal unveiled an uncomfortable truth about the work of many passenger car manufacturers. Millions of diesel-powered cars were equipped with tampered emission cleaning systems; during official test situations they performed commendably, but in real driving situations they polluted the environment most of the time. Among the early discoveries and most severe cases is Volkswagen. Their cars were equipped with engine control units provably [15, 40] containing software components to detect whether the car is undergoing an official emissions test according to the, then effective, admission regulations. These regulations [45] define a driving cycle called New European Driving Cycle (NEDC) with the weakness of enforcing tests with a constructed and very unnatural driving behaviour largely containing constant speed phases and repeating patterns—it can be detected easily.

Research and the vehicle regulations consortia have each taken up these weaknesses to suggest solutions. A product of research is a breach of the (proprietary) software running in Volkswagen cars, which allowed gaining valuable insights into their defeat devices [15]. These devices were so precise that even small deviations from the NEDC came with a significant increase of emissions. Small input deviations leading to large output deviations—this observation was taken up by D’Argenio et al. [17] and was turned into a set of formal definitions for clean behaviour of systems. Systems that are not clean would be called doped, and the usage of defeat devices in diesel cars becomes an instance of software doping. The theory is amenable to model-checking [14, 23] and testing and has been successfully used to find cases of software doping in practice [7, 8, 11, 19]. The official homologation process has been adapted to better cover real driving behaviour; the NEDC has been replaced by the Worldwide Harmonised Light Vehicles Test Cycle (WLTC), which eliminates constant speed phases and pattern repetition, and represents a more dynamic driving behaviour. In addition, a relatively large set of driving cycles is potentially considered for real driving emission tests carried out in-the-wild under presumably realistic conditions. The rde regulation specifies broad certification conditions for tests conducted under real-word conditions, on public roads and during working days. An (informal) specification document [42] spells out precise preconditions a trip, i. e., a trajectory driven with a car, has to satisfy in order to count as a valid rde test. These preconditions comprise constraints on the route, allowed altitudes and speeds, and on the dynamics of the driving profile. An rde test must comprise three modes, the urban, the rural, and the motorway mode covering different speed ranges and each making up approximately one-third of the total trip distance. Table 1 provides an overview of the constraints for all three modes.

In an official rde test, a calibrated portable emissions measurement system is connected to the car’s exhaust pipe and to the obd interface. It measures the amount of several gases and particles emitted by the car and combines this information with the information received from the obd interface. As mentioned, the costs of a PEMS are in the order of €.

Nevertheless, without a PEMS it is still possible to access the obd interface, the use of which is documented in the official regulation [41]. The amount of data offered through obd depends on the type of engine, emission cleaning system and other components of the car. There are several minimal combinations of obd data, which can be combined to get a good approximation of emitted gases. Köhl et al. successfully performed rde tests with an Audi A7 solely using obd data and indeed observing excessively high emission values, thus indicating a violation of the regulation [28]. One of their major contributions is a formalization of the informal rde specification in the official regulation. This formalization is written in the Lola specification language [16] with syntactic sugar for discrete aggregation windows [28]. For the present work, we translated this specification to rtlola, which is an extended variant of the discrete specification language Lola and the input language. In prior work, rtlola was used to monitor log data of networks [21] and drones [3, 22]. An automatic synthesis onto a field programmable gate array [5] enabled a flight test with rtlola as a monitor of an autonomous drone of the German Aerospace Center [4]. LolaDrives brings rtlola technology to Android devices for the purpose of RDE testing. It is, however, not the first ever verification and validation tool to run on mobile devices. For example, APHzip [33] is an app for construction and minimization of continuous probability distributions.

2.1 RTLola

rtlola  [4, 22] is a stream-based specification language for real-time properties. An rtlola   specification is a collection of input stream, output stream and trigger declarations. Input streams represent data sources such as sensors or information retrieved over the obd interface. Each output stream declaration details how to filter and refine input data to obtain relevant statistical information. Trigger declarations use this information to indicate when the system under observation reaches an undesired state such as a violation of a safety margin or a transgression of the permitted \(\textrm{NO}_x\) emission.

The rtlola toolkit generates a monitor for a given specification. The monitor receives input data from the system. These data may be asynchronous, i. e., different input sources can produce data at different points in time. Upon reception, the monitor computes output stream values and checks for satisfaction of trigger conditions. The result can then be fed back to the system or displayed to the user.

The rtlola language can most easily be understood by example. Consider the following specification:

figure b

The specification consists of one input stream and one output stream. The input stream carries the velocity of the system in km/h as a 32-bit wide floating point number. Let us consider the system to operate in an urban environment when its velocity is below 60 km/h. To this end, the Boolean output stream is_urban indicates exactly this condition.

To extend the specification, suppose the system is not allowed to travel more than 10 km in an urban environment within 20 min. In this case, the specification can be extended by two output streams and a trigger:

figure c

The first stream, urban_velo, carries the velocity of the system provided it operates in an urban environment, or zero otherwise. The second one integrates the urban velocity for 20 min to compute the distance travelled as a sliding window aggregation. Notice the annotation @10Hz, which transforms the stream into a periodic one. This prompts the monitor to compute the output stream only 10 times a second and is mandatory for streams with a sliding window aggregation operation such as the integral. This mandate allows the monitor to employ an efficient algorithm for aggregation [30]. In particular, if the aggregation additionally is a list homomorphism, the monitor does not have to store input values received within the time frame. This reduces the memory footprint of the monitor drastically. Details can be found in earlier work on rtlola  [4, 38].

Other output streams are event-based, i. e., they are computed when the monitor receives new input values. However, some streams depend on more than one input stream. When the monitor receives only an update for a subset of input streams due to asynchrony, it re-computes the output streams for which all relevant inputs were updated. Since the urban_velo stream only depends on velocity, it will be evaluated upon every reception of this input.

To finalize the example, the trigger declaration states that the urban_dist should remain below 10. Specifiers may provide a human-readable explanation after the condition. This string can then be displayed to users.

Beyond this brief introduction into rtlola, we refer the reader to earlier work [22, 38] for the full syntax and type system of rtlola.

3 From regulation to specification

The distinguishing feature of LolaDrives relative to all other apps on the market is the ability to monitor the progress of an rde test while driving. For this, it harvests the rtlola monitoring framework bringing formally rigorous runtime monitoring techniques to the end user and every-day use cases.

While rtlola targets a broad audience, that audience is still intended to be expert users rather than the general public. To leverage rtlola, one has to provide a formal specification capturing the intended behaviour, supply input data, and interpret the monitor’s output. LolaDrives reduces these tasks to minimal action points for end users. The specification for rde tests is fixed [28] and baked into the app. The app takes care of supplying the relevant input data, and the app visualizes the monitor’s output.

While the app takes care of those details for the end user, it has been a major undertaking to formalize the rde regulation [42] itself in the rtlola framework. We were able to build on top of our earlier efforts [25, 28] formalizing the rde regulation. For the purpose of LolaDrives, we extended this previous work. We here elaborate on (a) the formalizing of the rde regulation and (b) the changes made in order to bring this formalization to the end user. Regulation The rde regulation has been issued by the European Commission [42] in order to make exhaust emissions tests more realistic. To this end, it meticulously describes conditions a trip driven on public roads has to satisfy in order to count as a valid rde test. The regulation itself mostly relies on natural language, however, as we shall demonstrate, the individual conditions translate naturally into a stream-based specification language such as rtlola.

Some of the conditions apply universally, e.g., the ambient temperature must range between 273 K and 303 K throughout the whole trip. For others, the rde regulation differentiates between three modes characterized by the speed of the car: urban, rural, and motorway. Table 1 shows an overview over both the universal conditions and the conditions for the individual modes. Driving in each mode can be interrupted by short periods of driving in another mode, e.g., when changing the motorway the data collected by virtue of the driving speed may count towards the rural or urban environment. While modes may be interrupted, each one needs to occupy a specific share of the total distance.

The three modes To identify the mode a given data record belongs to, we introduce a Boolean stream for each mode being true if and only if the speed of the car is in the respective range as required for the given mode. For instance, for the rural segment:

figure d

This directly reflects §6.3 of the regulation [42, ANNEX IIIA] which says: “Rural operation is characterized by vehicle speeds higher than 60 and lower than or equal to 90 km/h.” Note that in contrast to other EU regulations, such as domestic market trade laws, the rde regulation lends itself well to formalization as it clearly defines rde tests in terms of mathematical concepts. The whole regulation assumes that records of test data come in synchronously at a fixed frequency of at least 1 Hz. Hence, the stream-based specification language \(\textsc {rtlola} \) is a perfect fit for formalization.

Now, for each of the modes it is required to determine the distance driven in that mode. The ratio \(d_m / d\) of the distance \(d_m\) driven in a given mode m and the distance driven overall d need to be within a specific interval for each mode (see Table 1 and §6.6 of the regulation [42, ANNEX IIIA]): “The trip shall consist of approximately 34 % urban, 33 % rural and 33 % motorway driving classified by speed as described in points 6.3 to 6.5 above. ‘Approximately’ shall mean the interval of \(\pm 10\) percentage points around the stated percentages. The urban driving shall, however, never be less than 29 % of the total trip distance.” So, we define a stream for the total distance d:

figure e

Here Dd is the distance driven since the last data record. Assuming that data are provided with a fixed frequency of 1 Hz, we calculate the distance in m from the velocity v in km/h by dividing by 3.6 to obtain m/s and then multiplying the result with 1.0 s. To obtain the total distance d, we use rtlola ’s aggregation functions and simply take the sum of Dd over the last 2 h, i. e., the maximal duration of a test.

Obtaining the distance travelled in a specific mode is also straightforward: Remember that we have a Boolean stream for each of the modes. We first define an auxiliary stream for each mode whose value is Dd when the car is in the respective mode and 0 otherwise. For instance, for the rural mode, we define r_d_a:

figure f

Using aggregation functions again, we obtain the distance travelled in the rural mode with:

figure g

So, §6.6 of the rde regulation translates in part to the following condition for the rural mode:

figure h

Doing this for all the other modes enables us to compute whether the ratio condition defined in §6.6 is satisfied or not. Analogously to the distance ratios, one defines streams for the remaining conditions.

Driving Dynamics A more complex part of the rde regulationFootnote 1 concerns the driving dynamics. The intuition is simple: Too aggressive driving leads to highly increased emissions; hence, at least for testing, it would not be fair for the manufacturer to have their car evaluated based on unrealistically aggressive driving. Likewise, too restrained driving is unrealistic as well. Hence, the rde regulation specifies lower and upper bounds on the driving dynamics. The driving dynamics is defined as the product of speed and acceleration:

figure i

v is the speed in km/h and a the acceleration in m/s\(^2\). The resulting stream dyn captures the dynamics in \(\frac{m^2}{s^3}\). For an analysis of the dynamics in a rural environment, the r_dyn stream mirrors dyn besides discarding values not acquired in a rural environment.

The requirements for the lower bound of the dynamics consider the relative positive acceleration (RPA). The RPA is the sum of the positive values of the dynamics. The regulation defines a dynamics \( dyn = \frac{va}{3.6}\) as positive, if the acceleration a is at least to 0.1 m/s\(^{2}\). As shown below, our rtlola specifications compute the RPA by first generating an output stream rpa_va that copies dyn but replaces all values computed with a non-positive acceleration by zero. An output stream rpa_agg computes the sum of these values, and output stream rpa computes the RPA by dividing this sum by the length of the trip. The specification snippet below shows the computation of the RPA for the rural mode (hence, each stream name is prefixed with r_):

figure j

The threshold for the RPA depends on the average velocity. If \(v_ avg \) is the average velocity; then, the regulation requires that the RPA is above \(-0.0016 \cdot v_ avg + 0.1755\) if \(v_ avg \le 94.05\) and above 0.025 otherwise.

The requirements for the upper bound for the dynamics consider the 95th percentile of the dynamics values. The following specification snippet shows the computation of the 95th percentile for the parts of the rde test that belong to the rural mode:

figure k

The percentile aggregation is computed for up to 7200 time steps, i.e. for a duration of 2 h given the (regulation enforced) fixed frequency of 1 Hz. The computation uses the values of the rural dynamics output stream r_dyn. Analogous streams u_pctl_dyn and m_pctl_dyn are constructed for the urban and, respectively, motorway mode. As for the RPA, the concrete threshold depends on the average velocity \(v_ avg \): the 95th percentile of the dynamics must not be greater than \(0.136 \cdot v_ avg + 14.44\) if \(v_ avg \le {74.6}\hbox { km/h}\) and no greater than \(0.0742 \cdot v_ avg + 18.966\) otherwise.

We can now encode the validity of the (rural) dynamics as a Boolean stream:

figure l

Checking emissions After establishing that a trip is indeed valid according to the conditions of the rde regulation, the exhaust emissions have to be checked. If a trip is not valid, the emissions are irrelevant and the test has to be repeated. To calculate the emissions, one first needs the exhaust mass flow (EMF), i. e., the mass of exhaust gas emitted per time unit. Based on the EMF in g/s and the measured particles per million, one can then compute the emissions in g/s. From this, the amount of \(\textrm{NO}_x\) emission in g/km can be computed by dividing the total amount of \(\textrm{NO}_x\) (in gram) emitted during the test by the total trip length. For \(\textrm{NO}_x\) and diesel fuel, the respective equations are:

figure m

Appendix 4 of the rde regulation provides a table of factors for computing the emissions. For \(\textrm{NO}_x\) and diesel fuel, the necessary factor is 0.001586.

It remains to sum up all the emitted gases over the whole trip in order to calculate the amount of gases emitted per kilometre. For each of the gases, we introduce a stream indicating whether the limit for the respective gas has been exceeded:

figure n

The exact threshold, here 168 mg/km, depends on the emission class of the vehicle.

Finally, we use a trigger to indicate when the trip is valid but the emission limits have been exceeded constituting a violation of the rde regulation, i. e., that the vehicle did not pass the test (where the Boolean output stream is_valid_test is a conjunction of Boolean streams such as r_is_dynamics_valid that must necessarily be true for a regulation conforming rde test):

figure o

As soon as the condition is violated, the trigger goes of notifying the user of the violation.

A vision As we have demonstrated, there is a mostly obvious correspondence between individual sections and paragraphs of the rde regulation and the respective rtlola formal specification. Instead of writing the rde regulation in natural language, one could have equally well written it in a suitable formal specification language such as rtlola. The full specification is available online.Footnote 2 It also contains further comments stating which parts of the specification relate to which parts of the regulation.

Fig. 2
figure 2

Components of the car data platform

Full size image

For the future, we suggest legislators take advantage of formal specification languages to define what is allowed behaviour and what is not. Formal languages enable not only a rigorous and unambiguous definition of allowed behaviour but furthermore the usage of tools, e.g., to synthesize runtime monitors or verify a system for compliance with a regulation.

Dynamic specification While the specification of the rde regulation itself is fixed, the app may be connected to a variety of cars, not all of which provide the relevant data. For instance, we need the exhaust mass flow (EMF) which is usually measured directly by the pems. In case the car does not come equipped with an EMF sensor and we do not have a pems at our disposal, we may still be able to calculate the EMF from other data. This has already been demonstrated in the previous work and has been the nucleus of the lightweight and low-cost variant of the rde test procedure [28] LolaDrives relies on. Clearly, having the layperson end user change or modify the rtlola specification to account for different car configurations is infeasible. Hence, LolaDrives automatically adapts the specification to a specific car. To this end, it queries the car for the supported sensors and then automatically pieces together the best specification for the car. This specification then includes the necessary formulae to compute values such as the EMF from data the car actually provides.

4 Car data platform and LolaDrives

It is in the nature of Software Doping analysis, that, from the user perspective, systems under investigation are black-box systems, where “observing the system” is the only possibility to gain insights into the software controlling the system [8]. For cars, this raises three concrete questions: 1) how can we observe what the car is doing, 2) how can we accumulate sufficiently many observations to draw conclusions, and 3) how can we address the above two questions in a cost-efficient manner? Our answer to all three questions is cdp, the Car Data Platform. It combines several car-related tools and services.

Figure 2 summarizes the main components that belong to the cdp. At the core is the Portable Car Data Format (pcdf) to encode car-related diagnostics data in a well-defined way [36]. The central place to collect pcdf files is a data server, which provides interfaces to submit new files, to analyse existing files, and to view analysis results. New files are typically submitted by instances of the mobile app LolaDrives , which run in-the-field connected to the diagnostics interface obd of a car. LolaDrives enables and encourages users to donate their pcdf files. cdp offers a repository of analyses for pcdf files [12] that is used by LolaDrives instances as well as the server. A server frontend provides researchers with convenient access options regarding the analysis results computed for donated data.

4.1 LolaDrives

LolaDrives is an Android application publicly available in Google’s Play Store [1]. It is compatible with many Bluetooth obd adapters to access diagnostic data from cars. The app supports two main diagnosis modes: real-time diagnostics monitoring and rde test guiding.

Fig. 3
figure 3

Diagnostics monitoring view displaying the most recent diagnostics data

Full size image
Fig. 4
figure 4

rde test guide displaying the current state parameters of the test drive

Full size image
Fig. 5
figure 5

All recorded files can be inspected data packet by data packet

Full size image
Fig. 6
figure 6

For recorded rde tests, an rde summary view is shown rde specific parameters

Full size image

Diagnostic monitoring In diagnostics monitoring mode, the user selects a set of diagnostic parameters (e.g. vehicle speed, ambient air temperature, etc.), for which real-time values are shown on the screen (see Fig. 3). Monitoring is supported for all cars with combustion engine built since 2005Footnote 3.

RDE Testing In rde test mode, the app constantly analyses the driving behaviour of the user to check whether it satisfies the rde constraints. The constraints [42] require the driver to equally partition the test into an urban, rural and motorway mode, and to adhere to realistic acceleration and deceleration behaviour. LolaDrives displays the most critical rde parameters (that the driver can influence) by visualizing the evaluations of the rtlola streams presented in Sect. 3. This allows the test personnel to easily detect and understand constraint violations. Figure 4 shows the rde feedback view of LolaDrives . From top to bottom, it shows the total time, which must be between 90 and 120 min to finish the test, and the total distance travelled (corresponding to the rtlola stream d). The next line indicates the current state of the conditions for a valid rde test drive disregarding emission data. In the screenshot, the drive is still in progress and inconclusive, indicated by the question mark. Instead, the ui can also indicate success or failure. The latter verdict can occur far before the time limit is reached, caused by an irrecoverable situation such as transgression of the 160 km/h speed limit. We remark that currently LolaDrives does not always detect if for a test the rde constraints are irrecoverably violated. For example, if a test has run for 119 minutes, but there are still at least 3 km remaining to drive in the motorway mode to cover the 23 % share of the total trip distance; then, this would require the driver to drive faster than 160 km/h for the remaining minute. Since this is forbidden by the regulation, the rde constraints are in this moment irrecoverably violated. In the converse case in which the indicator reports a successful drive, this concerns the trip up until this moment. Together with the regulatory constraints, this implies that the current verdict can alternate between success and inconclusive from minute 90 to 120 and also jump to failure. As there is no specific point in time when the test ends, the app continues to compute statistics until the tester manually stops it or the 120-min mark is reached. Beneath the status indicator is the green \(\textrm{NO}_x\) bar displaying the total \(\textrm{NO}_x\) emissions (rtlola nox_per_kilometer stream). The two markings denote the permitted thresholds of 168 mg/km for cars admitted before 2021 and 120 mg/km for cars admitted in 2021 or later.

The next three ui groups represent the progress in each of the distinct modes: urban, rural, and motorway. Each group consists of two horizontal bars. The grey progress bar displays the distance covered in the respective mode (e.g. rtlola r_d stream for the rural mode). The vertical blue indicators denote lower and upper bounds as per official regulation, for an expected trip length configured by the user. We remark that the configured trip length is solely used to determine the initial position of the distance indicators. In particular, when the user drives the car so that the distance would cross the upper bound of a mode, then LolaDrives instead increases the upper bound as necessary to avoid an overstepping and updates the distance bound indicators for the other two modes accordingly. The blue bar below the grey one illustrates two different metrics for the driving dynamics (e.g. rtlola r_rpa and r_pctl_dyn streams for the rural mode). Both dots need to eventually remain in the middle of the bar below/above their thresholds. A more aggressive acceleration behaviour shifts the dots to the right and a passive driving style to the left. The rde test guide is available for cars with compatible diagnosis characteristics. Necessary diagnostic parameters to check the rde constraints are vehicle speed, fuel type and the ambient air temperature. Furthermore, LolaDrives needs access to the location services of the phone to check rde conditions that are concerned with the altitude of the car. To compute the amount of emitted \(\textrm{NO}_x\) , the exhaust mass flow and relative amount of \(\textrm{NO}_x\) as measured in the exhaust pipe are necessary. The exhaust mass flow can be approximated from the mass air flow into the engine and the fuel rate [28]. Instead of the fuel rate, the air–fuel ratio can also be used. In case, neither is available, an expected air-fuel ratio based on the fuel type can be used.

Drive History In both monitoring and rde testing modes, the data received from the car are stored in a pcdf file. All recorded files can be inspected in the “History” section of LolaDrives . It is possible to inspect the raw data received from the car (Fig. 5), but also results of the analyses once it is available (e.g. rde results in Fig. 6). Every analysis has individual requirements about the set of diagnostics parameters that must be available in the record.

4.2 File server

To collect pcdf files at a central place, cdp provides a file server with an easy to use API to submit new files and to get analysis results. The server provides two distinct repositories, one for internal usage by the developers and one for official usage of the PlayStore version protected by a strong privacy policy. Figure 7 shows the web frontend for the internal repository.

Fig. 7
figure 7

Server Frontend: list of internal test files

Full size image

Internal files can be downloaded, and several analysis results can be inspected. Accessing and submitting data is protected by authorization tokens. The implementation of the server is an interplay of individual components, deliberately held flexible so that components can be replaced, removed or extended by other components in the future.

4.3 Technical set-up

The Car Data Platform is a collection of tools and services for car-related research. It is designed in a modular way to allow for a flexible development in the future. Modules are encapsulated in software packages, some of them are publicly available online. The implementation of the analyses shared by LolaDrives and the file server, and the pcdf core for easy handling of pcdf files is written in Kotlin and published online [12, 36]. Maven artefacts are available for integration in other projects. An analysis worker (written in Kotlin) is running on the server to regularly check whether new files have been uploaded and to run the analyses on new files in the background. The file server backend is an npm package written in TypeScript and Express. The frontend is also an npm package providing a react ui to show the contents on the server.

The entire rtlola toolkit is written in Rust and available onlineFootnote 4. The Rust compiler uses LLVM as a backend, which enables compilation for Android devices. Moreover, the implementation of the interpreterFootnote 5 contains both a standalone interpreter and a library. The library exposes a C-compatible interface, which can in turn interface with Java Virtual Machine (JVM)-based languages such as Kotlin. This enables linking of rtlola and LolaDrives . The latter is written in Kotlin and also freely available online [37].

Car simulator By the nature of the app’s functionality, the testing of new features of LolaDrives requires it running on a phone, connected via Bluetooth to an obd adapter, which is plugged into a car being driven by a human. This overhead makes testing quite inefficient. We therefore simplified the test procedure by instead constructing a physical car simulator, to which the obd adapter can be connected. The simulator consists of two parts: 1) a regular PC software to parse and prepare pcdf files for simulation and 2) an Arduino board attached to a CAN bus shield. The Arduino board serves as a “diagnosis storage device” to which the PC repeatedly writes diagnostic data. The CAN bus shield is connected to the obd adapter; it reads the diagnostics data from the diagnosis storage via the obd protocol. The PC transmits each event in the source pcdf file to the board in the same order and with the same delay as it was recorded. PC and Arduino communicate via a protocol based on Consistent Overhead Byte Stuffing (COBS) [13]. The PC software is written in Kotlin and the code on the board is written in the typical C++-based Arduino language. Figure 8 shows the simulator in action.

Fig. 8
figure 8

OBD simulator

Full size image

Privacy An important feature of LolaDrives and cdp is the support for data donation; users can opt-in to upload the files recorded by LolaDrives during monitoring or rde test mode. But pcdf files may contain personal data, for example, the vehicle identification number or GPS coordinates. Collecting personal data is regulated by data protection laws; in our case, the General Data Protection Regulation (GDPR). The GDPR concedes every EU citizen the rights to receive a copy of their data (in a machine readable format), to have it corrected, or deleted. All privacy policies in the EU must educate these rights to the users. LolaDrives does so in full. Moreover, our privacy policy [10] explains that data uploads are automatically deleted after at most 15 years (counting 5 years for doing research with it and 10 years data retention time after publication recommended by the German Research Council DFG [18]). Data donations are voluntary. Refusing or withdrawing consent does not restrict the available features of LolaDrives in any way.

5 Demonstration

This section discusses the user perspective on LolaDrives. After a general overview, we report on the use of LolaDrives for conducting rde test drives with two rented vehicles (the precise car model being unknown upfront).

Overview The preparation of the test requires the user to plug the obd-adapter into the obd-port of the car. After starting car and app, LolaDrives receives data packets and determines the sensor profile of the car, assuming phone and adapter are paired via Bluetooth. As the provided diagnostics data suffices to evaluate the rde constraints, the app selects the appropriate rtlola specification and initializes the rtlola monitor. LolaDrives then starts filtering and visualizing the data output and trigger notifications provided by the monitor, as explained in Section 4.

Test drive The technical framework and visual feedback of the app were tested in two experiments. The first experiments involved two rde test drives that were both conducted with an Audi A6 Avant 45-TDI hybrid diesel, which was admitted in 2020 under the Euro 6d-TEMP-EVAP-ISC (DG) regulation with an \(\textrm{NO}_x\) threshold of 80 mg/km under lab conditions and 168 mg/km for rde conditions. We denote this car as A20 and the rde tests as A20.1 and A20.2. The second experiment involves four rde tests that were conducted with the successor of the above car—an Audi A6 50-TDI hybrid diesel admitted in 2021 under the (moderately stricter) Euro 6d-ISC-FCM (AP) regulation enforcing the same \(\textrm{NO}_x\) threshold of 80 mg/km under lab conditions and a smaller 120 mg/km threshold for rde conditions.Footnote 6 We denote this car as A21 and the rde tests done with this car as A21.1 to A21.4.Footnote 7 Among the diagnosis parameters available within these cars are vehicle and engine speed, ambient temperature, engine fuel rate and mass air flow. The A20 car has two \(\textrm{NO}_x\)-sensors—one in front and one behind the emission cleaning system in the exhaust pipe. The A21 car has three \(\textrm{NO}_x\)-sensors—presumably one in front, one between components of the emission cleaning system and one behind it. With this set of sensors, the car is compatible for rde tests with LolaDrives . We configured LolaDrives to assume an expected trip length of 83 km for the visual guidance.

Table 2 Aggregation of the emission data based on the cdp
Full size table

Test drives A20.1 and A21.4 meet all conditions to be considered as a valid rde test. Test drives A20.2 and A21.1 did not experience sufficiently much accelerations in the urban mode to be a valid rde test; in A21.2 there was a malfunctioning of the OBD adapter and the test was forced to end before reaching the minimal 23 % share of the total trip length in the motorway mode; and test drive A21.3 is invalid, because we failed to comply to the maximum altitude difference of 100 m between start and end points. In all cases, LolaDrives correctly confirmed the satisfaction and violation of the rde criteria. For the valid tests A20.1 and A21.4, we measured 215 mg/km and, respectively, 30 mg/km of \(\textrm{NO}_x\) emissions. Hence, test A20.1 reveals a violation of the rde regulation, while the result of test A21.4 is conforming to it. A comprehensive overview for all measured emissions is shown in Table 2. In this table, the distances and the total amounts of emitted \(\textrm{NO}_x\) are computed directly by LolaDrives; all other values have been computed using a custom rtlola specification that was applied to the trip recordings after they were uploaded to the cdp by LolaDrives ’s data donation feature. Notice that the \(\textrm{NO}_x\) value for A21.3 is significantly higher than for the other A21 drives. Additional diagnostics data recorded made it evident that the car had been cleaning its diesel particulate filter and \(\textrm{NO}_x\) adsorber during the test. We are, however, not certain if this is the reason for the higher emissions. Anyway, if A21.3 were a valid rde test, the overall \(\textrm{NO}_x\) emissions are still below the threshold of 120 mg/km defined in the regulation.

Fig. 9
figure 9

Map with the A20.2 test route highlighted

Full size image

Figure 9 shows the route of test drive A20.2. The first half of the time constituted the urban segment (green). The next 30-40% of the test mainly consisted of the rural segment (purple) followed by the motorway segment (red). The map shows that the rural and motorway segments are regularly interrupted by other segments when the driver had to slow down for traffic reasons; the three phases are solely defined by the vehicle speed. As a result, depending on external circumstances, the driver cannot freely choose their environment, potentially exceeding the distance thresholds for a different segment on accident. It is, therefore, advisable to start with the urban environment and progress to the next environment as early as possible.

6 Conclusion

Since the Diesel Emissions Scandal in 2015, driving a diesel car comes with some uncomfortable feelings about how much the car actually does pollute the environment. With LolaDrives, we aim at more perspicuity and transparency and provide car owners a tool to investigate the ecological footprint of their car and drivings. To this end, LolaDrives pushes runtime verification technology into cars and phones of everyday users. The app is available in Google Play [1]. In the context of ecological responsibility, this kind of research plays an important role [27]. The car data platform constitutes a crowd-sourcing initiative for car data with the intention to enable researchers to conduct large-scale analyses of emission data beyond a single trip and a single car model.

The current state of the cdp is a proof of concept that can be further developed into several, not mutually exclusive directions. LolaDrives was launched in the middle of a global climate crisis. Diesel cars, but also gasoline cars aggravate the situation. Among the most promising modalities to reduce the impact of individual mobility on the climate crisis are electric vehicles. Electric vehicle technology promises a decarbonization process that is deemed necessary with respect to the ongoing climate crisis [35, 39, 50].

Unfortunately, electric vehicles are not legally enforced to provide obd interfaces. Instead, manufacturer-specific protocols [47] are in place for acquiring diagnostic data from these cars, and some of the protocol specifications have been leaked to the public [2]. Clearly, emission data of electric vehicles is irrelevant, but there are other diagnostics data that are of substantial importance for research and for users. Indeed, a measurable success of the decarbonization approach discussed hinges on two quantifiable characteristics: energy efficiency (the power consumption of the car must be as low as possible), and sufficiency (electricity savings by refraining from what is possible but not necessary) [35, Chapter 9][32]. For the latter, a first step is to make users aware of which changes in their driving behaviour have positive or negative effects on the energy consumption of their car. For example, fast accelerations typically consume more energy than moderate accelerations. In this regard, we envision new cdp components that provide app-based feedback to the drivers about their driving behaviour and recommendations on how to change their driving behaviour to become a sufficient driver.

We have already initiated work on further cdp components, for example an iOS-version of LolaDrives, and a “cdp core”, a library of multiple cdp components used by all cdp applications (mobile and server). The pcdf analysis component (with non-stream-based analyses) from Fig. 2 is the first part of this library. More analyses are planned for the future.

A recent approach [11] harvests the data collected with LolaDrives to improve test input selection for (model-based) software doping tests. There, a car is used on the road while rde-related diagnostic data is recorded. Once sufficiently many recordings are available, the data are used to model an emissions prediction function for the car. This prediction function can be combined with a probabilistic falsification technique to find test cycles that likely reveal software doping of the car. To verify this, the resulting test cycle must be driven on a chassis dynamometer with an official emissions measurement device attached to the exhaust pipe.

For stream-based analyses with rtlola, we are planning a native integration into the server frontend. Researchers can then upload an rtlola specification and let the server run the analysis on selected files. For the public repository (protected by privacy laws), we are planning to accept only specifications that do not reveal data of individual donators, which will require non-interference [24] and differential privacy [20] analyses of specifications.