Framework for Building Low-Cost OBD-II Data-Logging Systems for Battery Electric Vehicles

Abstract

With the electrification of transport (BEVs) and the growing benefits of smart vehicles, there is a need for a simple solution to perform real-time monitoring of the BEV and its battery for diagnostics and coordinated charging. The On-Board Diagnostics (OBD) system, originally designed for internal combustion engine cars (ICE), can be used to extract the necessary BEV data. This paper presents a developed framework for a low-cost solution to online monitoring of BEVs. A Raspberry Pi Zero W, along with other auxiliary components, was installed in two Hyundai Ioniq Battery Electric cars to communicate with the vehicles via the OBD-II port. A python script was developed to periodically request the vehicle data by sending various Parameter IDs to the vehicles and storing the raw response data. A web server was created to process the hexadecimal encoded data and visualize the data on a dashboard. The key parameters, such as the battery state of health (SOH), state of charge (SOC), battery temperature, cell voltages and cumulative energy consumption, were successfully captured and recorded, which can now facilitate trending for battery diagnostics and future integration with smart chargers for coordinated charging.

1. Introduction

In 2015, the United Nations (UN) developed the seventeen sustainable development goals (SDGs) to alert all countries to the actions required to secure social, economic and environmental sustainability [1]. Addressing climate change is a key component to achieving these SDGs and ensuring the population’s sustainable future, as global warming is one of the most concerning issues at present [2]. Human-induced warming reached approximately 1 °C above pre-industrial levels (relative to the period 1850–1900) in 2017. Climate models predict that a global temperature increase of 2 °C will lead to a severe risk of heavy precipitation, flooding, droughts, water scarcity and poverty [3]. As a result, the International Energy Agency (IEA) set a maximum limit of 1.5 °C by 2050. However, if greenhouse gas (GHG) emissions continue at the current trajectory, the global temperature is estimated to rise by 2.7 °C by the year 2100 [4]. Thus, in order to maintain the 1.5 °C limit, a significant GHG emissions reduction is needed to the point of carbon neutrality. When addressing greenhouse gases, transport is of major concern, as it is the second largest emitter of carbon (after generation and heating), accounting for approximately 25% of global emissions [5]. Battery electric vehicles (BEVs) which have no tailpipe emissions are believed to be a promising solution to transform the transport sector and combat climate change [6].

While there are no tailpipe emissions, BEVs create an additional demand for grid electricity to charge their batteries which will produce GHGs in locations which use fossil fuels as the primary energy source. As a result, the Well-to-Wheel (WTW) methodology is commonly used to quantify the GHG avoidance. It considers the emissions from the production to combustion of fuel and the energy conversion efficiencies, allowing the actual emissions per kilometer for BEVs and internal combustion engine (ICE) vehicles to be computed. Using the WTW calculation, the GHG avoidance varies for each country, according to the energy mix. For example, the study by [7] shows that in countries such as Norway and Canada, that generate most of their electricity by hydroelectric units, as well as in countries such as France and Japan, that depend on mainly nuclear energy, the carbon avoidance is very high. On the other hand, in countries such as China, Australia and India, which produce a large proportion of energy from coal, the penetration of BEVs will result in a net increase in carbon emissions. A similar WTW study by [8] indicated that in most EU member states, the GHG savings are approximately 50–60%, but in some EU countries, there is no savings as a result of higher fossil fuel-based energy production. While there are varying GHG impacts at this time, the BEV technology ensures that in a future state where the energy source is predominantly renewable, transport will be carbon neutral, unlike ICE vehicles which will always have emissions from the combustion of diesel or petrol.

Apart from the GHG reduction, the electrification of transport has additional sustainable benefits. A comprehensive review of the published BEV literature and its social impacts was conducted in [2,9]. It shows that BEVs have a significant association with several UN SDGs, including “sustainable cities and communities”, “climate action” and “decent work and economic growth”. The impact on the latter can be observed due to the rapid expansion of new industries along the value chain. For example, in India, the e-mobility transition is expected to result in the net employment generation of 32,017 jobs in the city of Jaipur by 2030 [10].

Due to the sustainable benefits, many countries have made pledges to phase out ICE vehicles and implemented subsidies and incentives to encourage the adoption of BEVs. In 2021, the sales of battery electric vehicles more than doubled from the previous year to a new record of 4.7 million [11]. With this increasing penetration of BEVs, there will be an increasing need for the management of the battery storage system as it plays a crucial role in the BEV. Various techniques and control operations that work automatically, such as cell monitoring, data acquisition, charge control, power management control, temperature control and fault diagnosis, should be developed [2]. The objective of this paper is to present a methodology for how a BEV can be upgraded to a smart vehicle by installing readily available low-cost components. This will allow for the real-time monitoring of key vehicle parameters so that trending for battery diagnostics and coordinated charging schemes can be integrated. The On-Board Diagnostics (OBD) II system was utilized to interface with the vehicle.

Initially developed for internal combustion engine (ICE) vehicles, the OBD-II system provides owners or technicians access to information on the state of the vehicle and its subsystems. It encompasses a set of engine and exhaust sensors and actuators linked to the engine control unit (ECU). The OBD system also includes a connection from the ECU to a female port located near the driver side of the vehicle where technicians can plug in a diagnostic scanner to view any errors detected within the subsystems in the vehicle. The ECU can also transmit real-time engine data via the port. As a result, work has been widely conducted on developing real-time monitoring and diagnostics for ICE vehicles [12,13,14,15,16,17]. However, the real-time monitoring of BEV battery data via the OBD system has been limited thus far. In [18], driving data and battery parameters were collected to predict the battery state of charge based on real driving cycles. Similar work was performed in [19] where the OBD-II data were used to predict the energy consumption in an electric vehicle. In [20,21], the data on the batteries in hybrid electric vehicles were extracted via the OBD-II port to demonstrate future diagnosis and fault reporting, but an interactive user interface was not yet developed for real-time monitoring.

In this paper, BEV data were also collected from the OBD-II system, but at a lower cost than the existing commercially available OBD-II loggers. An interactive web interface was developed to store and plot the key parameters, such as the battery state of health (SOH), state of charge (SOC), battery temperature, cell voltages and cumulative charge power. An additional benefit of this work is the development of real charging cycles and the typical time of arrival and departures so that grid studies on the impact of BEV charging can be conducted.

2. Review of OBD Technology

2.1. History

In the early 1980s, vehicle manufacturers implemented sensors and electronics to reduce exhaust emissions and increase fuel efficiency. The electronic devices also helped identify and diagnose the failure modes of the vehicle engine. When failure was detected, the system stored the details of the failure to be analyzed by a technician and turned on the Malfunction Indicator Light (MIL) on the dashboard of the vehicle [12]. The first policy for OBD systems was implemented in 1988 by the California Air Resources Board (CARB) to reduce air pollution and required vehicle manufacturers to monitor emissions [13].

Initially, each manufacturer adopted a different system to read and communicate the data to drivers and mechanics, and there was no standardization [22]. In 1991, the Society of Automobile Engineers (SAE) developed the first On-Board Diagnostics specification, OBD-I. From 1991, in the United States, OBD-I was required on all vehicles [23].

Although OBD-I supplied valuable information on the critical emissions-related system and components, several important items were not incorporated into the OBD standards due to the technical limitations at the time [24]. In addition, the first OBD iteration did not specify a standardized Data Link Connector (DLC) in which scan tools can interface to the ECU or diagnostic codes [14].

With further technological breakthroughs, the OBD-II standard was subsequently developed and in 1996 became mandatory for all cars manufactured in the United States. OBD-II added the following to be monitored: the catalyst efficiency, engine misfire, canister purge, secondary air system monitoring and Exhaust Gas Recirculation (EGR) flow rate [24]. The newer standard also provided a standardized hardware interface and standard diagnostic trouble codes (DTCs) [14].

2.2. Data Link Connector

The female 16-pin (2 × 8) J1962 connector is the standardized hardware interface for OBD-II systems. Nine pins have fixed functions and the remaining seven pins are left to the discretion of the vehicle manufacturer [25]. Two variations exist: Type A, found typically in cars, and Type B, common in medium and heavy duty vehicles. Both types have similar pinouts differing only in the power supply outputs (12 V for Type A and 24 V for Type B). The SAE J1962 defined the pinout for the connector as shown in Figure 1. This enabled diagnostic equipment manufacturers to build universal equipment that can communicate with all vehicles. The actual pins available are dependent on the communication protocol used by the vehicle.

2.3. Communication Protocol

The J1962 connector is compatible with the following five communication protocols:

• ISO 15765 (CAN bus).
• ISO14230-4 (KWP2000).
• ISO9141-2.
• SAE J1850 (VPW).
• SAE J1850 (PWM).

In 2008, regulations were set so that all cars sold in the US must use the ISO 15765 (the CAN bus protocol) [15]. The most popular implementation of these communication protocols is hardware-based, using a chip that converts the OBD-II signals into text data. The ELM327 converter automatically handles all protocols and is therefore used in several OBD-II data recorders [12,13,20,26].

2.4. Parameter IDs

The Parameter ID (PID) is a command code that can be issued to the vehicle. The ECUs within the vehicle will receive the code and then issue the information requested. The response contains the data hexadecimal encoded. There are nine available modes for the PIDs [26]:

• Mode 1: gives current real-time engine data.
• Mode 2: gives fault information detected on the engine.
• Mode 3: DTCs that the ECU currently stores.
• Mode 4: sends a command to the ECU to clear all the DTCs and turn off the Malfunction Indicator Lamp (MIL) if on.
• Mode 5: tests the results from the oxygen sensor monitoring.
• Mode 6: other sensors test results.
• Mode 7: pending DTCs.
• Mode 8: controls the operation of the on-board system.
• Mode 9: the engine VIN (Vehicle Identification Number).

Figure 2 shows the response for the PID request (010C) sent to a 2008 Nissan Y12 Wingroad.

At this time, there is no agreed standard for the battery system of battery electric vehicles [21]. As a result, PIDs for BEVs are mostly unspecified. Reverse engineering was performed by [27] to determine some of the PIDs for the Hyundai Ioniq Battery Electric car. These are given below:

• 2101—battery modules 1–5 temperatures, drive motor rpm, cumulative charge data.
• 2102—battery cells 1–32 voltages.
• 2103—battery cells 33–64 voltages.
• 2104—battery cells 65–96 voltages.
• 2105—battery modules 6–10 temperatures, SOH and SOC.

2.5. Diagnostic Trouble Codes

In OBD-II systems, the diagnostic trouble codes (DTCs) are standardized to allow drivers and repair shops to easily diagnose and repair vehicles. However, manufacturers were permitted to include additional exclusive codes. Four classes of codes were specified for distinctive functions of the vehicle. There are five characters in total to represent each DTC. The first character is an English alphabet letter (either B, C, P or U) to indicate the malfunctioned areas. The remaining four characters are digits. The second code indicates whether the DTC is defined by the SAE or manufacturer specific; the third character shows the area of the vehicle system, and the remaining two characters are hexadecimals used to represent the issue detected, as shown in Figure 3.

2.6. Commercially Available OBD-II Systems

Table 1. Costs of commercially available OBD-II data loggers.

Item	Cost (USD)
Auto Pi Telematics Unit, CAN-FD 4G/LTE Edition [28]	246.86
CANedge2: 2× CAN Bus Data Logger (SD + WiFi) [29]	576.18
OTC Tools—Infologger Event Data Recorder [30]	139.57
IOSIX—OBD-II/CAN Logger WiFi [31]	900.00

lists the existing OBD-II data logging devices along with the costs. The Auto Pi Telemantics Unit has a rich feature set, including WiFi, 3G/4G, GPS and Bluetooth, making it an ideal choice for logging EV data. The CANedge2 data logger has less features compared to the other devices, but it is still capable of logging OBD-II data and transmitting it over WiFi. A disadvantage to the CANedge2 is it is expensive for the features provided. The OTC Tools data logger is the cheapest on the list; however, it is limited because it can only record approximately 24 hours of vehicle data and the data must be extracted manually via the USB port. The IOSIX device is packed with features, including built-in WiFi, Bluetooth, an accelerometer, a gyroscope and 64 Gb of on-board storage, but is much more expensive at 900.00 USD. In this design, WiFi was included to allow automatic data logging but at a much cheaper cost than the existing devices found online. In addition, the web interface to visualize the data was designed specifically for BEVs and battery monitoring.

3. OBD-II Data Logger Design

3.1. Hardware

Figure 4 shows the block diagram of the OBD-II system developed and installed in the two Hyundai Ioniq Battery Electric cars. A Raspberry Pi Zero W was selected as the microcomputer unit to communicate with the BEV because it is low-cost, has the necessary features (USB, WiFi and SD card storage) and it is small in size. It periodically sends PID requests to the BEV and receives the responses. This device is a low-cost option with WiFi connectivity so that the data can be uploaded to the server for real-time monitoring. The OBDLink EX contains an STN 2230 chip which is fully compatible with the ELM AT 327 command set to convert messages between the OBD-II protocol and serial data. It has a male OBD-II connector as well as a male micro USB connector which was plugged into the Raspberry Pi Zero W. An OBD-II power cable was used to convert the 12 V from the OBD-II port to 5 V to run the microcomputer. A 2:1 splitter was used to facilitate both the OBD Link EX and OBD-II power cable connection to the BEV’s OBD-II port. Figure 5 shows the Raspberry Pi Zero W installed in the BEV and Figure 6 shows the splitter connected to the OBD-II port. The total cost of the parts was 92.90 USD and listed in

Table 2. List of hardware used and costs for OBD-II logging system.

Item	Cost (USD)
Vilros Raspberry Pi Zero W Basic Starter Kit	27.99
SanDisk 32 GB Micro SD Card	7.99
OBDLink EX FORScan OBD Adapter (USB)	33.95
Rearmaster Universal OBD Power Cable (Micro USB)	13.98
OBD-II Splitter Cable Male to Dual Female	8.99
Total	92.90 (USD)

.

3.2. Data Capture

The Raspberry Pi Zero W communicated with the OBDLink EX via the serial communication port. This was performed using serial port library, and Python programming was used to achieve this. The following three actions were executed to obtain data from the ECU via the OBD-II port (detailed in Figure 7).

• Communication initiation setup—set the specific path to the COM port in which the OBDLink EX is connected to as well as the baud rate.
• OBDLink EX configuration setup—set the format for the data responses.
• PID requests and response capture—looped every five seconds (current setting) to continuously send PID requests to the OBDLink EX and store the raw data responses.

3.3. Online Data Logging

When the Raspberry Pi Zero W sensed a viable internet connection, the raw BEV logged data were automatically uploaded to a web server using post requests. An internet subroutine (ISR) handler was developed that periodically checks for internet connectivity in the background of the main data capture program, as the Raspberry Pi Zero W may not always be connected to the internet. This task cannot exist within the main code as it will slow down the data logging.

Multi-threading was utilized to develop this background task. A separate thread process was created to continuously monitor the status of internet connectivity. Depending on whether the Raspberry Pi Zero W was connected or not, the main code changed modes and uploaded data to the web server via post requests.

3.4. Data Processing

The data captured and uploaded from each PID request were hexadecimal encoded. When uploaded to the web server, processing was required to convert the raw data into information that can be trended and displayed on a developed user interface. The experimental work performed in [27] indicated the location in the data response, scale factor and unit of each parameter and was used to process the data captured. Figure 8 shows the raw data response for PID 2105 and two examples for how two parameters can be interpreted. The location for the battery max temperature is “21 7”, i.e., the 7th hexadecimal number in the row starting with “21” (excluding the header “7EC”). Converting to decimal and applying the scale factor of “1” indicated that the temperature was 31 ${}^{\circ }$C. The battery state of charge was read to be 82.5 percent using the same approach. The parameter that was available on the vehicle’s dashboard (battery SOC) was cross-referenced to validate that the data were measured and interpreted accurately.

Table 3. Conversion for parameters contained in response to PID 2105.

Parameter	PID Response Location	CAN hex	Dec.	Scale Factor	Value	Unit
Battery Max Temperature	21 7	1F	31	1	31	°C
Battery Min Temperature	22 1	1E	30	1	30	°C
Battery Module 6 Temperature	21 6	1F	31	1	31	°C
Battery Module 7 Temperature	22 2	1F	31	1	31	°C
Battery Module 8 Temperature	22 3	1E	30	1	30	°C
Battery Module 9 Temperature	22 4	1E	30	1	30	°C
Battery Module 10 Temperature	22 5	1E	30	1	30	°C
Available Charge Power	22 6:7	2648	9800	0.01	98	kW
Available Discharge Power	23 1:2	2648	9800	0.01	98	kW
Battery Cell Voltage Deviation	23 3	0	0	-	0	V
Quick Charge Normal Status	23 4	1	1	-	1	-
Airbag H/wire Duty	23 5	50	80	1	80	%
Battery Heater Temp 1	23 6	0	0	1	-	°C
Battery Heater Temp 2	23 7	0	0	1	-	°C
State of Health (SOH)/Max Deterioration	24 1:2	3E8	1000	0.1	100	%
Max Deterioration Cell no.	24 3	2E	46	1	46	-
Min Deterioration	24 4:5	3E8	1000	0.1	100	%
Min Deterioration Cell no.	24 6	1	1	1	1	-
State of Charge (SOC) Display	24 7	A5	165	0.5	82.5	%

shows the full list of parameters contained in the response to PID 2105, along with the conversions.

4. Results

An interactive web interface was developed so that the processed BEV data can be viewed and trended. This tool will allow for drivers to perform their own diagnostics and gain insights from their vehicle.

Figure 9 shows the main user dashboard where the driver can view high-level instantaneous data on the BEV, such as the SOC, SOH, temperature and cumulative energy consumption. The SOC value obtained from the OBD-II system was verified with the value displayed in the vehicle dashboard. Other parameters could not have been validated at this time. With this dashboard, the driver can easily log in and view the battery health and performance without having to plug in a diagnostic scanner or visiting a mechanic shop. The cumulative quantities form the basis for developing systems to estimate energy consumption as performed in [19,32]. It also allows for the vehicle to be remotely monitored while charging to reduce the needless physical checking of the battery status on the vehicle dashboard. The SOC since the last charge session is shown in green below the “Battery SOC” in the Battery Status section of Figure 9. The Battery Max Temperature and Battery Min Temperature changes are also shown in green and red, respectively. These differences were also considered from the value of the last driving session.

Figure 10 shows the SOC vs. time (captured at a rate of two samples per minute) which can be used to integrate coordinated charging schemes or the adaptive control of electric vehicle supply equipment (EVSE) when combined with grid data [33]. This has the potential to reduce the strain on the grid during peak usage times. These trended data are also useful for developing statistical methods of estimating driver behavior [34]. The SOC data collected were also used to develop charging curves, as shown in Figure 11. For regions that lack data surrounding the BEV charging characteristics, this graph can be used along with equivalent circuit models, such as [35], in simulation software to develop BEV integration grid studies.

The temperature vs. time graphs in Figure 12 (also captured at a rate of two samples per minute) and the cell voltage graphs in Figure 13 are useful for tracking battery health. Unusually high battery module temperatures or cell voltages can be detected as a means of preventative maintenance, as stated in [2].

The battery’s health can also be investigated for diagnostics by observing if the temperature behaves higher than nominal voltages during any intervals of the SOC, as seen in Figure 14. This is a critical aspect of battery diagnostics which is otherwise impossible or impractically difficult to detect unless manufacturers implement internal recording systems and associated error codes. Even then, these are often difficult to investigate with low-cost commercially available scanners as most are still tailored to ICE vehicles.

5. Conclusions

A low-cost solution for the real-time monitoring of BEV data was developed. Using a Raspberry Pi Zero W to communicate with the vehicle and OBD-II connectors, the system cost less than 100 USD. Key parameters, such as the battery state of health (SOH), state of charge (SOC), temperature, cell voltages and cumulative energy consumption, were successfully captured and recorded to a web server. An interactive web dashboard was created so that the visualization and trending of BEV data can be conducted for diagnostics. With this system, the need for visiting a mechanic shop and plugging in an OBD-II scanner is eliminated as the BEV status can be viewed from the web dashboard. The next phase of this work will develop intelligence into the web server so that the driver can be alerted if there are any parameters trending out of range, before a fault occurs. For example, if a cell voltage is increasing above the nominal, the driver will be notified so that preparations to test and repair the cell can be made prior to significant battery degradation. The following phase will then integrate this system with smart EVSE to facilitate coordinated charging. All data will be stored and made available to the local utility so that grid studies, measuring the impact of the BEV charging, can be conducted.