OBD and the Future

Drew Technologies Founded and incorporated in 1996 Core focus on vehicle communications and diagnostics Customers divided among 3 business groups: OEM, Aftermarket, and Emissions Engineering, Manufacturing, and HQ in Ann Arbor, Michigan Over 20,000 vehicle communications products delivered to OEMs, dealerships, smog shops, and the aftermarket last year

This Morning’s Topics Founded and incorporated in 1996 Existing OBD technology and testing Vehicle changes that may impact IM in the future

OBD Technology The last major production car change that affected OBD hardware was “CAN”, first introduced in 2003 and mandated in 2007, 8 years ago. How long ago was that really? Some other things that came out in 2007

Current Programs Before we look forward at new vehicle technologies, what is the status of “OBD” in I/M programs today? – Pass or fail of a vehicle is based on MIL illumination and monitor readiness – Electronic OBD fraud detection for most programs consists of reading electronic VIN, comparing to scanned VIN. – Many programs are not evaluating VIN stem data for fraud to determine if like VIN stems match: PID Count Specific PID list Monitors supported Bus timing

Current Programs There are still connectivity issues with OBD vehicles. – Not following SAE and ISO specs for the protocols – Using an incorrect protocol determination order – ISO9141 Fast/Slow – Talking to the wrong ECU in the vehicle Mistakes can lead to no-com or even worse causing the vehicle to need repair. I.e. Toyota and CAN Most IM programs are using proprietary OBD hardware that is vendor-specific

What about the DAD BAR made the term “DAD” popular What the DAD really means: A DAD vendor was able to prove a 99.9% connectivity rate on a specific piece of hardware Not everyone has a “DAD” Testing times may increase due to large amounts of data being collected, but state can do much more with the data Combination of increased data collection and rigid “testing” of vendors has led to a smooth deployment and high value data in California

Drew’s DAD Experience Testing showed that there was no “magic”. Performing the communications as prescribed by SAE and ISO lead to success. California was DrewTech’s first time building an IM interface, although DrewTech had years of diagnostic interfaces Drew and Applus were to first pair for certification, Drew 13 days behind Applus Around 6,000 Drew interfaces shipped, making up a majority of the market. Drew DADs have already tested > 3M vehicles in California

Drew’s DAD Approach How did we build a successful DAD interface on our first try? – Follow the prescribed standards – Leverage SAE J2534 for our interface The result is that technicians can use our DAD device for two purposes: – BAR-OIS Testing – Repair using OE Diagnostic Programs Technicians can use their DrewTech DAD interface with the OE diagnostics software from GM, Toyota, VW, Jaguar, BMW, Volvo, and more. Massachusetts R2R law references J2534 for OE diagnostics and reprogramming, will require compliance by all car companies no later than MY2018

Putting the DAD in other states The communication API used in California is proprietary and confidential Other states wanting to replicate the DAD can do so by using J2534 in place of the California API Using J2534 will allow you to accept multiple vendors into your program and let them compete, offering consumers the best price and service You should test your vendor’s DAD. California ran 20,000 tests for each device. Resulted in smooth OIS launch. Using J2534 also allows the VID to capture some of the information that BAR is missing out on with the DAD API

Moving Forward FDCAN DOIP NHTSA’s V2V Telematics and Remote Diagnostics

FD-CAN Although FD-CAN is not being contemplated for OBD emissions testing, I think we need to remain aware of what’s going on with can FD CAN increases performance with a higher bit rate and data fields with more than 8 bytes Many automakers are developing vehicles with FDCAN now, we expect to see cars in the dealership in the next 2-3 years There are two versions of FDCAN, old FD-CAN (non-ISO) and new FD-CAN (ISO) The switch from non-ISO FDCAN to ISO FDCAN is creating some complexity. Using an old CAN scantool on an FDCAN car can cause it to go “Bus-off” FDCAN will be supported thru the J2534 spec, it’s being worked on now. Hopefully it will never show up on pins 6 and 14. OLD CAN (500Kbit)Non-ISO FD-CANISO FD-CAN

DOIP DOIP = Diagnostics Over IP DrewTech has already delivered DOIP tools to car companies First car with DOIP will be model year 2017, showing up early in 2016 It’s not like regular Ethernet. You can’t just plug the car into a PC Most implementations will have 5 wires on the J1962 OBD connector dedicated to Ethernet. (4 + a wakeup line). There is also a 2-wire variant (Broadcom) These cars will have CAN on pins 6 and 14, for now. Eventually there may be a push to get rid of CAN and support only Ethernet. DOIP will be supported thru the J2534 spec, it’s being worked on now. DOIP vehicle network is much faster than CAN Will be more secure, raise the stakes for hackers and tuners

V2V Driven by DOT (NHTSA), SAE, and IEEE with a goal of reducing the number of motor vehicle accidents and fatalities MIT Tech review named it one of the biggest breakthroughs of 2015 First V2V equipped vehicle will be released in 2017 from Cadillac Studies believes they will reduce crashes by up to 292,000/year V2V transmits at GHz Concept broken into two components: Roadside Network and Onboard Vehicle Equipment (OBE)

V2V SAE defines Required and optional data transmitted by vehicles

V2V Currently, MIL status and IM monitors are not a part of SAE J2735 Wouldn't it be nice if that changed… OBD testing could be replaced with strategically placed V2I stations monitoring emissions compliance. License plate recognition could be used to identify users

OE Telematics Most car companies have telematics systems in production cars (i.e. Onstar) There are several initiatives to allow the aftermarket to gain access to these OE telematics systems The most discussed proposal right now would require each car to have a gateway and firewall that would allow 3 rd party applications to connect to the vehicle for diagnostics, emissions testing, UBI Insurance, etc Due to the complexity and the lack of agreement among OEs and the aftermarket, the timeline for this has not yet been established.

Recommendations Best practices in OBD testing should be put in place now Programs beginning in 2016/2017 should be considering OBD hardware that is “capable” of supporting FD-CAN, just in case. Monitor DOIP and see where things are going.

Questions? Brian Herron Drew Technologies, Inc Phone: x602 Brian Herron Drew Technologies, Inc Phone: x602