Abstract
Logs of vehicle controller area network (CAN) bus traffic supplemented by accelerometer and GPS data can provide valuable information about the use and operation of advanced driver assistance systems (ADAS) to the broader safety research community. Although CAN bus message codes are often manufacturer-specific, third-party libraries provide partial decoding of messages from many vehicle models, which can be augmented by reverse-engineering additional signals. This study explored the value of CAN bus, accelerometer, and GPS data that were logged on a variety of light vehicle models with an emphasis on availability of lane keep assist/lane departure warning, and adaptive cruise control. This study demonstrated that in-vehicle ADAS variables such as system on/off status and whether the system is actively controlling the vehicle could be determined on a variety of vehicle types. Associated control variables such as steering wheel angle, gas pedal state, and brake pedal state could also be determined from most vehicles tested. CAN messages, together with roadway features identified via GPS location, can provide a richer understanding of ADAS efficacy. Comparisons of message structure between models may also inform standardization efforts for electronic data recorders and telematics.
As researchers seek to quantify the safety effects of advanced driver assistance systems (ADAS) such as lane keep assist (LKAS) and adaptive cruise control (ACC), their task is complicated because crash reports often do not provide safety system status data. The status of such systems is not available to the policy officers who completed the crash reports. For example, if a researcher were to observe a surprisingly low correlation between LKAS equipage and lane departure crashes, it would be desirable to know whether drivers were disabling LKAS, and how often the system was enabled but not actively tracking. Unfortunately this type of status information is not widely available in crash reports, so it is desirable to develop a broadly accessible means of tracking ADAS system status.
Naturalistic driving studies have provided detailed and accurate information relevant to ADAS studies ( 1 , 2 ). A study such as the Strategic Highway Research Program 2 (SHRP 2) collected both video- and sensor data at a frequency of 10 to 100 Hz, with custom radar units logging multiple targets throughout each trip. Such studies can provide a detailed understanding of driver experience and the course of safety events. However, the resulting data reflect the operation of the study-specific system rather than the production system built into the vehicle.
Vehicle manufacturers are able to collect ADAS data in great detail as a matter of course. For example, Orlovska et al. worked with Volvo to collect manufacturer-specific CAN messages, as well as GPS data from a fleet of Volvo vehicles in a naturalistic study of Volvo’s OpenPilot ADAS system usage ( 3 ). Flanagan et al. used telematics data provided by General Motors from its OnStar system to evaluate forward collision warning (FCW) and lane departure warning (LDW) ( 4 ). As manufacturers increasingly build telematics systems into their vehicles, this kind of approach can support larger and more timely evaluation of ADAS systems.
This paper describes an evaluation of access to ADAS usage data when partnership with a manufacturer is not feasible. A subset of useful ADAS status signals can be obtained from some vehicle models using readily available hardware and software: plug-in data loggers recording GPS, accelerometer and controller area network (CAN) bus messages communicated on vehicle internal networks readable via the vehicle’s On-Board Diagnostic System II (OBD-II) data link connector port. The primary logging target is ADAS status variables indicating whether a system is turned on and actively assisting the driver. CAN bus message codes are often manufacturer-specific—a major hurdle for studies involving a wide range of vehicle makes—and this research effort seeks to solve this problem using third-party CAN bus message decoding libraries ( 5 , 6 ).
The evaluation included three primary tasks: testing which CAN messages (if any) could be manually captured with a logger, accumulating a set of trip logs from a set of vehicles for which CAN messages could be captured, and assessing the extent to which select driving parameters could be extracted and converted into engineering units of measure.
Methodology
In-Vehicle Logging via OBD-II
A variety of vehicle logging devices are available to capture data via the OBD-II data link connector (DLC) port, which was made mandatory on US light vehicles in 1996. DLC-based loggers are simple and inexpensive to install because they plug into an existing port on the vehicle. A small set of standardized parameters sharing common message codes are available on all OBD-II equipped vehicles. These cover engine-related data such as throttle setting and revolutions per minute of the engine, but nothing relating to ADAS system status. On several vehicles, additional nonstandardized parameters communicated on vehicle CAN busses are also accessible via the DLC. These include both ADAS status indicators and other relevant signals such as braking, steering angle, and turn signal status. This information is not included in police crash reports, and the ADAS status indicators are not captured by most electronic data recorders. To study ADAS operation, the logger must be able to read nonstandard messages.
Augmenting in-vehicle messages with a GPS receiver and accelerometer provides additional context, such as road type (derived from GPS location and map data), hard braking, and sudden acceleration. The IOSiX OBD-II/CAN Logger version 4 was selected to provide GPS and accelerometer signals in addition to in-vehicle messages. On-board storage and a Wi-Fi interface were used to support convenient wireless data transfer to a centralized database. The logger’s shortcomings include a lack of a gyroscope or an external GPS antenna. When plugged in to the DLC port below the vehicle dashboard, the GPS signal suffered. Although GPS reception can be improved by mounting the logger above the dashboard via an extension cable, this tended to reduce the quality of accelerometer readings.
Accessibility of CAN Bus Data via the Data Link Connector
The availability of CAN messages via the DLC varies substantially among vehicle types. To capture a wide range of CAN data, the study team surveyed a variety of model year 2014 to 2020 vehicles sold in the United States. Samples were taken opportunistically from make/model/model year as summarized in Table 1.
Controller Area Network (CAN) Message Accessibility by Make/Model/Model Year (Model Year 2014 to 2020)
The third column in Table 1 indicates whether CAN signals were captured using the simple test protocol. For setup, the logger was plugged in after being configured to autodetect baud rate; the vehicle was started; diagnostic LEDs were observed to assess logger status; and the resulting log files were reviewed for content. No effort was made to tune the device configuration if logging failed. In some cases, additional CAN data may be accessible if appropriate vehicle-specific settings are provided. “Yes” indicates that a variety of CAN message identifications (IDs) were logged throughout the time the vehicle was on. “No” reflects any of the following failure modes:
The logger did not connect to the bus; no messages captured
The logger failed to autodetect baud rate; no messages captured
The logger captured a small number of messages, after which the message stream stopped
The logger captured a stream of identical messages.
Failure could occur for several reasons. The vehicle might use a nonCAN protocol such as FlexRay or Local Interconnect Protocol. The logger might fail to detect the baud rate on the vehicle message bus. A security gateway between the CAN bus and the DLC could prevent messages from reaching the DLC. Although CAN messages were successfully captured from most vehicles tested, the success rate was noticeably lower with newer vehicles, probably owing to increased use of security gateways on the vehicle message bus. For example, messages were captured from 2017 Jeep and Subaru models but not 2018 and newer models.
Data Set Accumulation
To further study ADAS system operation, the team mounted loggers on 14 vehicles for ongoing data collection, accumulating data for 3,606 trips. Data were automatically accumulated on loggers during trips and were transferred to centralized servers via Wi-Fi access points deployed at designated parking locations. Logged vehicles were either employee-owned or rented.
Because trip logs included personally identifiable information, employees were provided an informed consent approved by MITRE’s Institutional Review Board, with allowable data uses restricted by written agreement, and specified data protections. Rental company staff was informed rented vehicles would be used to test ADAS systems. Employee-owned vehicles were equipped for 2 to 14 months, whereas rentals were equipped for 3 to 14 days.
All vehicles were of model years 2016 to 2020 including Chevrolet Colorado, Chevrolet Equinox, Ford Fusion, Honda Civic, Honda CR-V, Hyundai Elantra, Jeep Grand Cherokee, and Subaru Outback. Vehicles without ADAS (Chevrolet Colorado, Ford Fusion, and Subaru Outback) were not included in findings related to ACC or LKAS. Table 2 provides a summary of vehicles’ make, model, trip statistics, and ADAS equipage.
Summary of Logged Vehicle, Trips, and ADAS Equipage
Note: ACC = Adaptive Cruise Control; BSW = Blind Spot Warning; FCW = Forward Collision Warning; LDW = Lane Departure Warning; LKAS = Lane Keep Assist.
The resulting data set included trips in the eastern, southern, and midwestern United States from all seasons and in a variety of weather conditions. However, neither the population of drivers, the vehicle types, nor driving patterns should be considered representative of US driving.
Processing Logged Data
Logged data consist of GPS sampled at 1 Hz, 3-axis accelerometer at 10 Hz, and a vehicle-specific set of CAN messages at 2 Hz. Data were recorded per trip and temporarily stored on the logger until it connected with a Wi-Fi server deployed at a designated parking location, at which time files were transferred and the logger’s copy was deleted. Transfers generally occurred either daily or weekly, depending on how often participants parked at download points. On the data server, CAN records were extracted from packed binary to text and converted to engineering units. Records from all sources were assigned a log ID, a vehicle ID, and a timestamp. A subset of CAN signals was standardized with common field names and units. For trips passing basic quality checks, oriented accelerometer, standardized CAN, and GPS records were merged into a single log. A synchronized 1 Hz version of parameters was produced in a tabular format convenient for analysis.
Given a log of CAN bus messages, there remains the challenges of decoding and interpreting message content, because messages are logged as a stream of updates in binary format and encodings are not standardized. A comparison of input data format to desired output is illustrated in Figure 1. Updates must first be converted into engineering units, then harmonized with common names and measurement conventions.
Controller area network (CAN) messages must be extracted from binary message stream.
Although the best authority on message interpretation is the vehicle manufacturer, other groups have reverse-engineered vehicle message content. A notable example is comma.ai and its open-source user community, which has developed the CAN decoding library opendbc in support of a research-grade self-driving agent called openpilot ( 5 , 6 ). openpilot provides ACC and LKAS on a range of vehicle types, so the CAN decoding in opendbc reflects a heavy focus on ADAS signals. The decoding, data interpretation process, and knowing the conditions in which the system is designed to be active are technically difficult and the verification process is time-consuming.
Accelerometer data retrieved from the logger were oriented with respect to the position in which the logger was inserted in the OBD-II port, and thus varied by vehicle type. Post-processing was required to align acceleration components with the vehicle. Two rotation matrices were applied to transform raw accelerometer X, Y, and Z components relative to the direction of travel, providing lateral, longitudinal, and normal acceleration components. The vehicle’s turn signals, or its lateral or horizontal acceleration readings from CAN messages, were used as a check on the sign of the lateral component.
Trip data were augmented with weather and roadway attribute information based on GPS location. GPS coordinates were map-matched to “most likely roads the vehicle travelled” using the Snap-to-Roads application programming interface (API) ( 7 ). The more accurate matched GPS records were then used for reverse geocoding to obtain road features, road curvature, and elevations. Road features were obtained via a spatial join in ArcGIS. Curves were identified using an ArcGIS add-in tool, ROCA ( 8 ). Hillcrests were identified based on elevations obtained from the USGS 3D Elevation Program ( 9 ). To obtain weather data, the DarkSky API was queried using latitude, longitude, and time at 3-min increments ( 10 ).
Data from the CAN bus, accelerometer, and GPS were merged into a single time-ordered stream, with the logging device’s clock used to provide a common time reference. Synchronization of GPS to CAN bus and accelerometer was checked by comparing rate of change in vehicle heading from GPS to steering angle from CAN bus and lateral acceleration from the accelerometer. The timing of signal changes corresponding to start of turn events were observed differ by 0 to 4 s; precise synchronization was not deemed critical for the current study. To support convenient analysis, a data set with signals resampled at 1-s intervals was also generated.
Assessment of Decoded ADAS Messages
ADAS data may be missing either because the vehicle did not have the feature in question or because the relevant signals could not be decoded from CAN messages. A second challenge occurs when interpreting data fields standardized from different signals. For example, the “ldw_on” field, which indicates whether LDW is actively monitoring lane position, might come from a dash icon on some vehicle types and a toggle button on others. Because dash icon values could change independently of toggle button presses in some situations, such as when the vehicle is placed in Park, “ldw_on” values may be recorded differently on a vehicle using icon values than a vehicle using the toggle button.
The primary means of validation was test drives in which an engineer in the passenger seat monitored message traffic as the vehicle operated to verify that decoded values corresponded to changes in vehicle state. Secondary assessments against log recordings included review of extreme values, missing values, and consistency checks against related signal. Assessments focused on the parameters of interest listed in Table 3. A small number of additional signals was also reverse-engineered using Intrepid Control Systems’ Vehicle Spy ( 11 ). On-off controls like buttons and switches were especially amenable to reverse-engineering using Vehicle Spy.
Primary Parameters of Interest from CAN
Note: CAN = controller area network; ADAS = of advanced driver assistance systems.
Several caveats apply to the assessment process. First, the database container (DBC) files typically define only a subset of signals sent on the message bus, and some signals may not be used on a given vehicle; for instance, they may relate to an option not purchased with that vehicle. Second, review of message formats indicates a large degree of commonality across model years and models from a given manufacturer. Third, in many cases message formats known on one model can be applied to similar models, but not without some risk of invalid decoding or interpretation. Fourth, there is potentially a risk that signal formats in the DBC may be incorrect. The quality of mappings in a crowdsourced product may vary substantially by vehicle, system, or parameter type, and the consistency of decoded data must be treated with caution. Fifth, interpretation of signals can be challenging. Labels are not always clear, there can be overlapping and partially redundant signals, and units of measure are not always known.
Sample signal data may provide a clearer sense of the issues involved in assessing parameter availability. For example, to ascertain cruise control status for a 2017 Honda Civic EX Sedan, we must first determine which opendbc DBC definitions to use: those corresponding to Nidec sensors, or those using Bosch sensors. Community technical documentation specifies that sedans use Nidec. The next question is whether the DBC contains signals relevant to the parameters of interest. The answer is not always obvious owing to lack of standardization of names and formats. In this case, the message ‘POWERTRAIN_DATA’ contains a signal ‘ACC_STATUS’ that can take a 0 or 1 value. The signal name and data suggest it may be a Boolean variable indicating whether ACC is active, but not unambiguously so.
Results
Table 4 summarizes the initial decoding assessment by make, subject to the caveats described above. It is worth reiterating that the assessment reflects the procedure used and not necessarily the full set of information available via the DLC. In addition, an “X” indicates an assessment that relevant indicators can be captured, but indicators for different vehicle types may not carry precisely the same meaning. Missing Xs may reflect failure to decode messages, absence of relevant messages from the logged message stream, or absence of the relevant ADAS system from the test vehicle.
ADAS System Parameters Collected and Decoded
Note: ADAS = Advance Driver Assistance System; ACC = Adaptive Cruise Control; BSW = Blind Spot Warning; FCW = Forward Collision Warning; LDW = Lane Departure Warning; LKASS = Lane Keep Assist. T = True; F = False
Although relevant signals were logged and decoded from Ford, Mazda, Subaru, and Toyota vehicles as well, those values were omitted from Table 4 because the team was unable to spend sufficient time in vehicle to validate the signals.
Subject to the caveats above, this study demonstrated the ability to obtain, decode, and standardize a substantial number of ADAS parameters, though the set of parameters varies by vehicle type.
Example: Usage of Lane Keep Assist
Figure 2 depicts a short segment of a single trip to illustrate the kind of information obtainable in relation to LKAS. In the figure, the left pane plots a set of CAN signal time series whereas the right pane plots the corresponding locations on a map. The points are color-coded to indicate whether LKAS is actively monitoring the roadway. Orange dots indicate the driver turned the system on and it is tracking the lane. Blue dots indicate the driver turned on the system, but it is not tracking the lane. Common reasons why LKAS might be on but not actively tracking include the turn signal being on, vehicle speed below a minimum threshold (commonly around 40 mph), and sensors unable to detect lane boundaries.
Lane keep assist (LKAS) activity example.
In the time series pane, the topmost plot indicates LKAS was turned on throughout this segment but not actively tracking for 4 s beginning at trip second 1,068 and then the final portion of the segment beginning at trip second 1,107. The third and fourth plots show turn signal status and vehicle speed, showing that the second inactive period coincided with a turn signal, followed by immediate deceleration to below 40 mph. The first inactive period, marked by the arrows in Figure 2, is not explained by either turn signal or vehicle speed. GPS location provides a link to roadway details that may provide additional clues. Inspection of the map in Figure 2 indicate the initial inactive point occurs at a lane divide—the likely reason for the change in state.
Study Limitations
Although the described logging method revealed some details of ADAS system operation, there were several limitations in the results. First, the amount of detail is limited to signals on the high-speed message bus, which typically carries only a fraction of the data available to vehicle control modules. For example, the ACC system may track multiple target vehicles, including valuable safety-related information like distance and rate of approach, but that information is not captured by the method described. Second, not all the available signals were successfully decoded, resulting in different decoded message sets for each vehicle type studied. Third, newer vehicles increasingly block access to CAN messages from the OBD-II. Between increasing penetration of ADAS on newer vehicles and decreasing accessibility of messages, model year 2016 to 2018 vehicles provided the richest ADAS data availability in this study. For future work, telematics may provide a better basis for richer, more scalable, timely results.
Other limitations of this research include constrained resources to expand data collection to a larger set of vehicles. In addition, data collection was suspended because of COVID-19 in March 2020.
Conclusions
This study of logging and decoding vehicle messages has demonstrated the feasibility of logging and analyzing several important ADAS parameters by third-party researchers even in cases when partnership with an automobile manufacturer is not available. Indicators of whether a system has been enabled by the driver and whether the system is actively tracking or controlling the vehicle are amenable to this approach for model year 2016 to 2018 vehicles, which have accessible CAN bus message streams, crowdsourced ADAS decoding information, and a reasonably high penetration of ADAS systems. Because ADAS systems like LKAS are in use only part of the time, a comprehensive understanding of their safety benefits requires knowledge of when the system is in use. If drivers are not choosing to engage the system in a scenario where it could provide particular benefit, for example, manufacturers might want to focus on the user experience in that scenario. Alternatively, if the driver has switched the system on but it is not actively monitoring and controlling the vehicle during hazardous scenarios of interest, the focus might need to be on enhancing the system’s operating range.
Finally, the decoded signals obtained from various manufacturers and vehicle models have been similar enough, despite many differences in detail, to support calculation of a common set of standardized signals. Processing of such signals is therefore a promising avenue for developing standards for applications like electronic data recorders, advanced automatic crash notification, and fleet telematics, for which the industry has not yet deployed standardized ADAS information.
Footnotes
Author Contributions
The authors confirm contribution to the paper as follows: study conception and design: K. Berman, K. Campbell, V. Gawron; data collection: K. Berman, K. Campbell, J. Long; analysis and interpretation of results: K. Berman, K. Campbell, S. Yuja; draft manuscript preparation: K. Berman, K. Campbell, V. Gawron. All authors reviewed the results and approved the final version of the manuscript.
Declaration of Conflicting Interests
The authors declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The authors received no financial support for the research, authorship, and/or publication of this article.
