One Sunday last May, a driver on the A270 highway from Helmond to Eindhoven in the Netherlands braked abruptly in heavy traffic. It was the type of sudden slowing that forces drivers following closely behind to brake, causing a ripple effect, or shockwave. Even if the lead vehicle accelerates again immediately, shockwaves can bring traffic to a standstill as each driver in the chain slows to avoid a collision with the driver ahead.
On this particular day, however, there was no traffic jam. This was because 10% to 30% of the cars on the highway were demonstrating a technology, using information from roadside units (RSUs), that damps shockwaves and helps ensure smooth traffic flow after sudden braking incidents .
A core component of the technology is the on-board unit (OBU), a hardware device currently under development by TomTom. The OBU, which runs on the Android™ operating system, provides drivers with navigation information. The shockwave damping software installed on the OBU uses a technique known as cooperative driving, in which OBUs work together with RSUs to improve traffic flow. TNO engineers modeled the software for the OBU in Simulink®. These engineers then developed a process for deploying the model to the Android-based OBU using Simulink Coder™.
Preparing for Cooperative Driving on the A270 Highway
The Android devices installed on the test vehicles are complemented by monitoring and control hardware installed along a 5-kilometer stretch of the A270. This hardware includes 48 video cameras mounted on poles spaced 100 meters apart (Figure 1) and 11 communications gateways spaced 500 meters apart.
A single RSU computer processes images from the cameras, computes an optimal speed profile for vehicles traversing each section of the highway, and transmits this speed profile to the vehicles via Wi-Fi®-p communications gateways.
As soon as the RSU detects the start of a shockwave, it calculates adjusted speed profiles to gradually slow down approaching vehicles. Vehicles farthest from the incident may need to reduce their speed very little, if at all. Vehicles closer to the incident will slow down more, but not so much that they propagate the shockwave.
The behavior of vehicles in communication with the RSU influences the behavior of other vehicles in the traffic flow. As a result, we do not need to equip all vehicles with OBUs. In fact, of the 68 vehicles in the experiments conducted on the A270, only 20 had OBUs. Of these, 8 included an adaptive cruise control system (ACC), controlled directly by the OBU, that automatically sets the vehicle's speed. In the remaining 12 vehicles, the OBU displayed the suggested optimal speed (Figure 2), letting the driver accelerate or decelerate manually .
Modeling the OBU Software
The OBU control system determines the current speed of the vehicle using coordinates from the OBU's integrated GPS system and its accelerometer. It also processes speed profile updates from the RSU, updates the OBU display, and generates CAN messages to set the ACC speed when the system is running in automatic mode.
We modeled the complete control system in Simulink and Stateflow® and ran simulations using input data recorded from earlier road tests. In the weeks immediately before the road tests, we used Simulink external mode to verify the real-time performance of the system's interfaces with the CAN bus, the RSU, and the on-board display. These simulations enabled us to find and eliminate problems in our algorithms before conducting road tests. This capability was vital to the success of the project, as each road test involved closing the highway to other vehicles and coordinating 68 volunteer drivers.
Generating Code for the Android Platform
Modeling and simulating the OBU control system was relatively straightforward, as the TNO engineering team has significant experience with Model-Based Design. What we lacked was experience in developing software for Android.
Based on the Linux® kernel, the Android operating system is designed to run Java™ applications, or apps. An Android device's input and output—including the accelerometer and GPS data—are available to any Java app running on the device. We could not generate Java code from our Simulink model, nor could we generate C code for a standalone executable and deploy it directly to Android.
To address this issue we developed a novel approach for running a Simulink model on Android. This approach uses the Android Native Development Kit (NDK), a toolset that lets engineers implement portions of their apps using native-code languages such as C and C++. The Java Native Interface (JNI) provides the framework for exchanging data between the Java portions of the app and a shared library created using C or C++.
We created a target for Simulink Coder that generates code for a shared library rather than a standalone executable. The C code in the shared library includes functions for initializing the model, executing a single model step, and closing the model. The code also includes functions for accessing input and output data from Java via JNI and an external mode interface to access parameters and data during execution. Because Java arrays are structured differently from C arrays, the code also includes functions that transform arrays from Java to C and from C to Java. Lastly, we updated the standard template makefile to support compilation for an Android target using the NDK.
Running Road Tests and Processing the Results
Although we had eliminated most problems with the control system through simulation, when we began road tests we discovered some issues with the display and with the processing of the speed profile information from the RSU. To resolve these issues, we had to update our Simulink model in the field and then redeploy the system. The ability to generate code and create an updated Android app with a single click proved invaluable—it enabled us to rapidly make the needed changes and resume road testing in the limited time that we had access to the highway.
Following road tests, we used MATLAB® to postprocess data, including measurements of vehicle speed and the distance between vehicles, that we had collected during the tests. We generated plots of vehicle position as a function of time (Figure 3). The plots confirmed what the tests had demonstrated: The system effectively damped the shockwave and enabled a smooth flow of traffic.
The left-hand plot in Figure 3 shows the results of a road test with the shockwave damping system turned off. At 3900 meters the lead vehicle brakes, slowing from 85 kph to 45 kph. This creates a shockwave that affects all vehicles, ultimately causing some vehicle speeds to fall below 20 kph. A second shockwave, caused by vehicles' accelerating after leaving the first shockwave, is also apparent .
The right-hand plot shows the results of a test conducted under the same conditions but with shockwave damping enabled; the braking action of the first vehicle is exactly the same as in the previous experiment. In this test, the RSU generated a speed profile when it detected the first shockwave. Vehicles equipped with OBUs 1500 meters beyond the shockwave reduced their speed to 65 kph. As a result, gaps emerged in the traffic flow (visible as white zones in the plot). The first shockwave was successfully damped after only 30 seconds. The right-hand plot also shows a second braking action of the lead vehicles. Again, the shockwave was successfully damped. The difference between both braking actions is that during the first, the OBU-equipped vehicles were driving in advisory mode, while during the second, they were driving in automated mode.
We are currently using Model-Based Design and the new Android target for Simulink Coder to develop an enhanced version of the system. This version factors in input from traffic lights to improve traffic flow within and between cities.