Current Projects
OBD-II to RS232 Interpreter
Background:
Cornell's entry into the Progressive Insurance Automotive X-Prize competition is a series diesel-electric plug-in hybrid that utilizes a National instruments CompactRIO microcontroller and FPGA (pictured below). This device is a highly scalable, modular unit that provides a multitude of connectivity options while still maintaining ease of use through NI's LabView software.
Cornell's hybrid, nicknamed "RedShift", utilizes a 1.4L 3-Cyl Volkswagen engine from a 2002 Polo. This engine is coupled to an EVO Electric Pancake-style generator and serves as a range-extender. The main drive system is a UQM PowerPhase 125kw AC induction motor, and is the only device capable of deliverable power to the wheels (called a series drivetrain).
In order to safely and effectively control the diesel engine genset, parameters such as engine block temperature, coolant temperature, rpm, and fuel flow, need to be available to the vehicle management software. Additionally, various engine error and sensor codes that may provide useful information to support staff back in New York are desirable. Thus this project was born. We needed a way to get the information from the OBD-II port of the engine harness to the cRio with as little hardware as possible.
Research:
The first step on the way towards determining a viable interface involved researching the communications protocols supported by the cRio and the type of signaling the VW Polo Engine utilizes.
cRio Interfaces:
National Instruments offers a wide range of plug-in cards for the CompactRIO microcontroller. We are already employing generic analog and digital I/O modules, in addition to a Controller Area Network (CAN) card capable of controlling the batteries and communicating with the competition's cellular data acquisition device (pictured below).
CAN communication between the cRIO and the VW Engine seemed promising, however this would require the 2002 Polo to have implemented this protocol for its diagnostic communications across the ODB-II port in addition to CAN communication between the main car ECU and the various other computers in the vehicle. The CompactRIO also provides (1) RS-232 serial port and (2) RJ-45 Ethernet ports, which were also considered as viable options for connecting to the VW Engine. It is important to note that the 12" Touchscreen display which serves as the vehicle's instrument panel communicates via Ethernet with the cRio, leaving only 1 port available.
VW Diagnostic Communication Protocol:
Various OBD-II protocols exist for road vehicles and they can vary based on the year of the vehicle, and whether it was designed for european or american markets. All U.S. based vehicles manufactured after 2008 are required to implement CAN communication across the OBD-II link, therefore standardizing the communications standards throughout all vehicle makes and markets.
It was determined that the 2002 VW Polo utilizes the following protocol:
ISO 14230 - KWP2000 (Keyword Protocol 2000)
- pin 7: K-line
- pin 15: L-line (optional)
- Physical layer identical to ISO 9141-2
- Data rate 1.2 to 10.4 kBaud
- Message may contain up to 255 bytes in the data field
Since the 2002 VW Polo does not infact employ CAN as the primary diagnostic protocol, it would be impossible to directly interface the VW engine with the CompactRIO without some sort of interpreting logic as the middle-man between these two interfaces.
After significant research, the ELM327 OBD-II to RS-232 chip was found to be the most viable option.
ELM327 Integrated Circuit:
This chip is an extraordinarily powerful little device capable of translating nearly every diagnostic protocol implemented by vehicles over the past 10 years into standard ASCII text across an RS-232 link. The device accepts ASCII commands from the host, queries the vehicle ECU, waits for a response, then returns the requested data in Hex format to the user. A block diagram illustrating the information flow and labeled with pin-outs is provided below courtesy of the data sheet:
The ELM327 is very affordable and sold as a single 28-pin chip. It is up to the user to design and implement the necessary supporting timing and biasing circuitry. While ELM electronics does offer an example circuit available HERE, another option for utilizing this chip was discovered that although came at a slightly higher cost, would take less time to implement, and likely be a more reliable solution. The following device was chosen:
ELMSCAN 5 Compact OBD-II Reader:
This commercial tool implements the ELM327 IC, and therefore is capable of supporting the KWP2000 Protocol that the VW utilizes. This reader is housed in a durable plastic case, and ships with an ample length of cable and a pre-wired DB-9 Connector. Although a junior in ECE at Cornell could have built the aforementioned example circuit, wired the connectors, and mounted everything into an enclosure, it is unlikely that it would be finished in time frame the team needed it, and been as reliable as the readily available commercial option.
Preliminary Testing:
In order to ensure that the ELMSCAN 5 Compact would be suited for the application, and since the VW Polo Engine in the Cornell RedShift was out of commission for several months, it was advantageous to test the device using another vehicle. A 1998 Oldsmobile Aurora with a 250-hp V8 engine was a prime testing candidate. The testing setup also included a laptop computer with a terminal application installed. For testing, the ELMSCAN 5 was connected directly to the OBD-II Port of the Oldsmobile and the serial interface at the other end was connected to a USB-to-Serial converter, then into the laptop computer.
The vehicle was turned on, and the terminal program was initiated on the computer. After several seconds the '>' character was presented to the user, indicated the ELM327 chip was ready to receive commands. Initially, communication was only tested between the computer and ELM chip. A wealth of commands prefixed by 'AT' provides the user with the ability to change the setting of the chip, as well as gain additional auxiliary information, such as the battery voltage.
After successfully communicating with the ELM327 chip, an OBD-II command was sent to the Oldsmobile's ECU requesting the current RPM of the vehicle: '01 0C' (in hex). The vehicle responded with the engine rpm in hex, therefore proving the functionality of this device as a means of interpreting ISO 14230 signal into RS-232 ASCII.
In order to assure the multi-protocol functionality of the device, it was also connected to a 2004 Toyota Camry with similar results. The device had no problem reading engine trouble codes, reporting the engine rpm, and the vehicle's 12 volt battery voltage.
Once the RedShift's engine was again operational, testing was done with the ELMSCAN 5 Compact Tool and a laptop as the host device. Although limited, this test again proved the functionality of the ELM327 chip in interfacing with the VW engine as well the command line control of the device. Below is a video taken during genset testing while the team was in Michigan right before the first Progressive Automotive X-Prize Event.
LabView Implementation:
The next phase of the project will be to create the LabView software that will enable the cRIO to send commands and receive data across the OBD-II Interface. Andrew Gifft will be providing the necessary support to write and test the code, however the following section will outline the methodology as well as the commands that need to be sent to the ELMSCAN device.
The following website provides a tutorial for creating LabVIew code to send commands, read values, and scale them as needed: LINK
This LabView VI module determines the sampling rate (how often to request the value), sets up the serial interface, reads in the desired parameter, formats the data by truncating and scaling, then outputs it as a variable for other parts of the program to utilize.
The following chart represents a sample cycle where all parameters are read, and offers insight into how often the master program will require updates to these parameters.
Parameter |
Delay |
Command |
Output |
Scaling |
|---|---|---|---|---|
Engine RPM |
1 sec |
01 0C |
41 0C XY ZW
|
(XYZW -> dec)/4
|
Coolant Temp |
2.5 sec |
01 05 |
41 05 XY |
(XY -> dec) - 40 |
Air Temp |
2.5 sec |
01 46 |
41 46 XY |
(XY -> dec) - 40 |
Load Value |
2.5 sec |
01 04 |
41 04 XY |
(XY -> dec)*100/255 |
Sample Execution:
| Time | Event |
|---|---|
| T=0 | Request RPM |
| T=250mS | Read RPM |
| T=500mS | Request Coolant Temp |
| T=750mS | Read Coolant Temp |
| T=1sec | Request RPM |
| T=1.25sec | Read RPM |
| T=1.5sec | Request Air Temp |
| T=1.75sec | Read Air Temp |
| T=2sec | Request RPM |
| T=2.25sec | Read RPM |
| T=2.5sec | Request Load Value |
| T=2.75sec | Read Load Value |
Engine Trouble Codes and Aux Information:
If at any time the driver wishes to poll the Engine ECU for diagnostic trouble codes, a button on the touchscreen may be pressed that will send the following code to the ELM 327: "01 01". The Touchscreen will then display the output of the chip directly as a sequence of hex values. The pit crew will then be able to lookup these values in a readily available table, and alert the engine support staff back in New York of the trouble code. Furthermore the cRio may poll the ELM327 for the current 12-volt battery voltage with the command "AT RV". This data is useful since it can alert the driver if the battery voltage dips below a preset threshold, perhaps 11.5 volts, indicating the rear DC-DC converter is malfunctioning.
Interface Error Detection:
The LabView code will have built in error checking mechanisms that will analyze the reported parameters for any values that are completely out of range of expected values. For example, if the interface reports the coolant temperature to be 500 degrees C or - 20 degrees C, it is likely that there is a communications or data parsing issue. If the code detects these sort of range errors over more than 3 cycles, it will send the following reset command to the ELM327 chip "AT Z". A counter will store the total number of resets for a given operational cycle. If this number exceeds 5, the interface will be disabled, and an alarm light will illuminate on the touchscreen display, indicating communication has been lost between the cRio and engine.
Future Work:
Once RedShift is rebuilt and the batteries are reinstalled and operational, the LabView VI can be coded and the interface tested while the engine is running in the vehicle. It will be important to analyze how well the connection holds up during operation, especially since the vehicle can be electromagnetically noisy while enabled. After logging the parameters for at least 3 charge cycles, if the data seems reliable, the information can be used to make logical decisions elsewhere in the code. For example, if the engine over-revs and speed increases to over 3000 rounds per minute, the engine should be shutoff. If the data is not quite as reliable as what is desirable, the information can be averaged and then displayed on the touchscreen or beamed back to the pit crew over the cell connection through a CAN interface.