How Different are On-board and Off-board Vehicle Diagnostics? A Detailed Analysis of Functions, Scope & Services
‘If something can go wrong, it definitely will, states the Murphy’s Law. When we talk about machines, this law which is more of a proverb completely holds true.
So what do we do when a machine goes wrong? We first perform an inspection of the machine to zero in on the problem. Identifying the issue helps us to find the right solution.
This process of inspection or analysis is known as Diagnostics. And this plays a very important role in human beings favorite machine – a Car/Automobile/Vehicle.
How Vehicle Diagnostics Works?
In a car, passenger vehicle or any other automotive, Vehicle Diagnostics is a very elaborate and necessary process. It may also become quite complex at times.
The state of the motion or rest of the car becomes primarily important. Also, the diagnostics parameters change when the vehicle is moving and when it is at rest in a garage. In order to cover both these scenarios, off-board and on-board vehicle diagnostics have been introduced.
The typical vehicle diagnostics feature checks the state of functions performed by the subsystems, sensors and other such components. The errors reported by all these components are recorded in the error memory in the form of DTCs (Diagnostic Trouble Codes).
While on-board vehicle diagnostics protocols like OBD/OBD2 are tasked primarily with emission related diagnosis, off-board vehicle diagnostics (UDS, KWP etc.) handle the diagnostics related to every other vehicle ECU (Electronic Control Unit).
What’s the Functional Scope of On-board Diagnostics System
On-board vehicle diagnostics (OBD2) comes into the picture when the vehicle is moving. The tests are being conducted while the vehicle is on the road. The test results can be seen on the vehicle’s dashboard in the form of MIL (Malfunction indicator light) or an OBD tester tool. The data that the OBD makes accessible is related to:
- Emission Control System
- Engine and Transmission ECUs (powertrain)
OBD2 was mandatory for all the cars that were manufactured in the USA after the year 1996. This was essentially done to keep the emissions level of the vehicles in check.
Every parameter related to the vehicle emission such as info from oxygen sensors and the fuel injectors etc. is checked. In case of any malfunction, an MIL (malfunction indicator light) is triggered to warn the vehicle owner.
Additionally, a limp home mode may be activated in some high-end cars. This mode activates an algorithm to let you drive home or to the service garage without causing more damage to the vehicle.
The error that triggers the MIL is also stored in the automotive ECU which can later be retrieved by the tester tool at the garage. This error code helps the technicians to pin-point the emission issue and rectify it.
In order to request the data from the vehicle ECU, Parameter IDs (PIDs) are sent to the automotive ECU using the tester tool. Hundreds of PIDs have been specified by SAE J1979 and a few by specific automotive OEMs.
The technician sends the PIDs and gets the response corresponding to that PID. The technician can then zero in on the specific issue that is causing the trouble.
These tester tools perform generic tests that are similar for most vehicles. In some countries, the police is also equipped with such testers that can be used to detect the emission related data of the vehicle. Any breach of standards set by EURO (Europe) and CARB (USA) are liable for penalty.
What needs to be noted here is that on-board diagnostics has services that are not specific to a particular vehicle or variant (except the ones specified by the OEM). In contrast, the off-board diagnostics protocol like UDS may be vehicle specific. We will discuss this further, when we talk in-depth about the off-board vehicle diagnostics
More About On-board Vehicle Diagnostics: Services Categorization and their Functions
The services provided by OBD2 are categorized under nodes. Services here refer to the functions of the OBD2 software stack.
Every node has some Parameter identifiers as per the standards set by SAE J1979. The automotive OEMs can also configure some vehicle specific PIDs.
The function of each OBD2 node has been described here in brief.
Mode $01 – Request Live Data from the powertrain that is available to the tester tool.
Mode $02 – Request Freeze Frames i.e. the vehicle data captured when the issue occurred.
Mode $03 – Request Stored Trouble Codes; displays the exact 4 digit code to help identify the fault
Mode $04 – Clear/Reset Stored Emissions Related Data
Mode $05 – Request Oxygen Sensors Test Results
Mode $06 – Request On-Board System Tests Results from exhaust gas sensors, catalyst monitor, fuel system monitor and others; an advanced mode that can be accessed only by professional grade tester tool
Mode $07 – Request Pending Trouble Codes captured during the current or last driving instance.
Mode $08 – Request Control of On-Board Systems by an off-board diagnostics system
Mode $09 – Request Vehicle Information like vehicle identification number, calibration identification etc.
Mode $0A – Request Permanent Trouble Codes. Any code that turns the malfunction indicator light and is stored in a non-volatile memory must be logged as a permanent trouble code.
Exploring the Scope of Off-board Diagnostics in the Vehicle
Off-board vehicle diagnostics takes care of the diagnostics of every other vehicle ECU function other than emission. There are several protocol standards defined for off-board diagnostics, however, Unified Diagnostics Services (UDS) is the most popular diagnostic protocol.
P.S: We would use UDS and off-board diagnostics interchangeably for the convenience of reading and better understanding.
The diagnostics managerof the UDS protocol stores every issue as fault codes called Diagnostics Trouble Code (DTC). When a vehicle is running, the off-board diagnostics is also active. However, the contrast with on-board diagnostics lies in the reporting part.
In case of OBD, the fault is communicated to the information cluster by triggering the Malfunction indicator light. Whereas, in the off-board diagnostics, no such instant reporting is carried out. The issue is stored in the EEPROM part of the vehicle ECU for retrieval at the service garage using a vehicle diagnostic testing tool.
However, the scope of off-board diagnostics (UDS) is not limited to just storing the diagnostic trouble codes (DTCs). It is capable of offering services such as vehicle ECU reprogramming, remote routine activation, writing data on the automotive Electronic Control Unit and even more.
Detailed explanation of some of these services can be found here.
We also mentioned about the vehicle-specific aspect of the UDS protocol earlier in the blog. This is one of the major aspects that differentiates on-board and off-board vehicle diagnostics.
When the UDS stack is integrated to the vehicle ECU, the UDS services are configured to it. These configurations are mostly OEM-specific. It means that a tester tool authorized by the same automotive OEM can only read or write data from the vehicle ECU. Unlike the OBD 2, any after-market tester tool will not work.
A Comprehensive List of Off-board Diagnostics (UDS) Services
As UDS has been accepted by many automotive OEMs as the de facto Off-board diagnostics, its services are very important. We have compiled them here:
|0x10||Diagnostic Session Control||Enable various diagnostics sessions within ECU|
|0x11||ECU Reset||Resetting the ECU to be back in the default session|
|0x27||Security Access||Limit access to data and services to prevent unauthorized access|
|0x3E||Tester Present||Alert the ECU(s) that client is still connected so that diagnostic sessions remain active.|
|0x22||Read Data By Identifier||Request data from ECU(s)|
|0x2E||Write Data By Identifier||Write data onto ECU(s)|
|0x14||Clear Diagnostic Information||Clear diagnostic trouble codes (DTC) stored in the ECU|
|0x19||Read DTC Information||Read DTC from the ECU|
|0x2F||Input Output Control By Identifier||Control the input/output signals through the diagnostic interface|
|0x31||Routine Control||Control all the routine services (erasing memory, testing routines etc.)|
|0x34||Request Download||Request ECU to initiate download session based on request from the tester|
|0x36||Transfer Data||Manage actual transmission ( upload and download) of data|
|0x37||Request Transfer Exit||Terminate and exit data transfer|
|0x28||Communication Control||Manage the exchange of messages in the ECUs|
|0x85||Control DTC Setting||Enable/disable updating of DTC settings in ECU|
|0x87||Link Control||Control the ECU- client (tester) communication to gain bus bandwidth for diagnostic purposes.|
|0x23||Read Memory By Address||Read memory data from the memory address provided|
|0x24||Read Scaling Data By Identifier||Read scaling data stored in the server using data identifier.|
|0x3D||Write Memory By Address||Write information into the server memory location|
|0x35||Request Upload||Request ECU to upload data|
On-board vs Off-board Vehicle Diagnostics: A Quick Comparison
We hope the scope and services of both on-board and off-board vehicle diagnostics should be clear by now. Emission being a very crucial aspect of a vehicle, on-board diagnostics is completely dedicated to it. The strict CARB and EURO emission guidelines call for real-time monitoring of emission related parameters. The Malfunction Indicator light is also associated with the on-board diagnostics, implying the urgency an emission related issue requires.
The off-board vehicle diagnostics, on the other hand, may not require enough urgency to light up an MIL. However, it has many other roles to play. Its comprehensive set of services help the garage personnel perform tests, run routines, update the ECU, write data and much more.
The crux of the story is that both on-board and off-board systems perform diagnostics and have their scope clearly demarcated by their services. While one takes care of the emission the other handles everything other than that.
ASK OUR EXPERTS
Car HUD (Heads-up Display)
Go-to-market in 6 months with our automotive grade hardware and software design
Automotive Control Units
Electronic Control Units (ECU) development services for Body Control Modules (BCM), Powertrain, Chassis and Infotainment
AUTOSAR Software Services
AUTOSAR MCAL development, RTE and BSW integration, Application Layer development, Tools configuration and code generation
CUSTOMER SUCCESS STORIES
Find out how J1939 stack resolved on-chip memory issue for an Automotive Tier-I supplier
Modular architecture re-design across fleet management product lines - GPS fleet security, vehicle and trailer tracking
Design and development – Sensor Networks, Custom IoT gateway, Cloud and Mobile App