Course 3

Mastère Professionnel Co-
Construit M2 Ingénierie
Automobile et Aéronautique
Automotive
Technologies
Omar Triki Lecture 3 2023-2024

Diagnostics in an Electronic Control Unit (ECU) are used for several important reasons in the context of
automotive and electronic systems:
 Fault Detection: ECU can identify issues such as sensor failures, wiring faults, or component failures.
 Error Reporting: When a fault is detected, the ECU generates error codes.
 Performance Monitoring: ECUs check engine parameters, exhaust emissions, …
 Emission Control: Ensure that the vehicle's emissions are within regulatory limits.
 Safety: The ECU do continuous checks to ensure vehicle proper operation and safety of occupants.
 Preventive Maintenance: Identify wear and tear on components, allowing for proactive maintenance.
 Remote Monitoring and Telematics: Transmit data to a central server to keep track of vehicle health
and performance in real-time.
 Calibration and Optimization: Aid in the calibration and optimization of various parameters, such as
fuel injection and ignition timing, to improve engine efficiency and performance.
On-Board Diagnostics II
Operative perspective all things we need the system to do throughout the entire lifecycle:
 from development where we want to carry out debugging

 to manufacturing where we want to make sure that the assembly has been performed correctly,
 during use and maintenance where we want to ensure that we can detect faults, repair them and we
apply updates and of course all the way through to dispose
 or where we may need to remove sensitive data such as user IDs and passwords for online systems or
possibly even hazardous devices airbag systems contain pyrotechnic devices small explosives that
can severely injure people if they’re not disposed of properly so we need to make those safe before we
throw them away
An important part to define the operative perspective is to define exactly which participants are involved in
a specific task. For example, the tester can’t go up to the vehicle and open a door or process a button but
of course the technician can do those kind of things and similarly the technician can’t directly talk to the
ECU’s that are in the vehicle to find out if they've logged default or to ask them to turn on an output but
the tester gives that capability
So it important to define which participant does what in the process while we’re thinking about the
operative perspective once we’ve started to refine this view and understand the operative perspective we
can really start to dig into the communication that is needed between the tester and the ECU’s that are in
the vehicle for each task that we want them to perform together
To do this we need to take an external perspective on the diagnostic interface that means that we need
to describe the requests that we ‘re going to send to the ECU’s in the vehicle and of course the
information that we want to receive in response to each request.
This information is absolutely critical and there is a standardized data called ODX or Open Diagnostic
data eXchange that allows us to describe all the possible communication between a tester and a vehicle.
It is important to note that ODX has been designed to allow a tester to automatically load the data for an
ECU or for multiple ECU’s in fact it could be for whole vehicles or for vehicle platforms when we talk about
a project, so we can really load a lot of data by using ODX and transport a lot of data.
This means that only ODX files can absolutely immense and way too complex for human being to easily
understand them. So we need to approach ODX with some degree of caution as human beings because
it’s not necessary very easy to work with directly however it is fantastically useful once we want to take a
tester and connect it to a vehicle understand what we want to do so for that process automation aspect
is absolutely the right tool for the job.
ODX is a XML based standard to define ECU diagnostic data in OEM independent way. It contains all
necessary data for the diagnostic communication for example communication parameters, ECU variant
relationship, diagnostic services, units of measures, precision, data-types etc. The complexity and size of
the ODX data depends on ECU variants and amount of diagnostic services supported by the ECUs
When OBDII detects a problem or malfunction in any of these areas, it stores a diagnostic trouble code
(DTC) in the vehicle's computer. Mechanics and technicians can use a scan tool to read these codes,
which provide information about the specific issue that needs attention.
Data Link Connector (DLC)

OBDII Query
The functional PID query is sent to the vehicle on the CAN bus at ID 7DFh, using 8 data bytes. The bytes
are:
OBDII response
The vehicle responds to the PID query on the CAN bus with message IDs that depend on which module responded. Typically
the engine or main ECU responds at ID 7E8h. Other modules, like the hybrid controller or battery controller in a Prius,
respond at 07E9h, 07EAh, 07EBh, etc. These are 8h higher than the physical address the module responds to. Even though
the number of bytes in the returned value is variable, the message uses 8 data bytes regardless (CAN bus protocol form
Frame format with 8 data bytes). The bytes are:
Engine Speed
Let consider the case of a tester requesting to measure the current engine speed:
 The query is sent on the CAN bus  ID?

 Length  to be calculated at last step
 We need to measure the current data  Service?
 Engine Speed  Has a PID 0xC (given)
Query ID + Length + Service + PID
Query 7DF 02 01 0C CC CC CC CC CC
Engine Speed
What is the format of the ECU response in case the engine speed is coded in 2 bytes
Let decode the response received from the ECU
7E8 04 41 0C 0F A0 55 55 55
Response ID + Length + Service plus 40 + PID + Response bytes
The engine speed in RPM is computed based on the formula (256A+B)/4. So what is the speed value
measured?
Fuel Rail Gauge Pressure
Let consider the case of a tester requesting to measure the current Fuel Rail Gauge Pressure:
 The query is sent on the CAN bus  ID?

 Length  to be calculated at last step
 We need to measure the current data  Service?
 Engine Speed  Has a PID 35 (given)
Query ID + Length + Service + PID
Query 7DF 02 01 23 55 55 55 55 55
Fuel Rail Gauge Pressure
What is the format of the ECU response in case the engine speed is coded in 2 bytes
The Fuel Rail Gauge Pressure in kPa is computed based on the formula 10*(256A+B). Formulate the
ECU response so that the measured value equals 5,3 10^6 Pa
Response ID + Length + Service plus 40 + PID + Response bytes

Vehicle Identification Number (VIN)
The Vehicle Identification Number (VIN) is a unique alphanumeric code used to identify individual motor
vehicles. It serves as a fingerprint for a specific car, truck, or motorcycle, and no two vehicles should
have the same VIN. The VIN is typically a 17-character code but can vary in length for certain types of
vehicles.
Here's how a typical VIN is structured:
 World Manufacturer Identifier (WMI): The first three characters represent the WMI, which identifies
the vehicle's manufacturer and the country or region where it was built.
 Vehicle Descriptor Section (VDS): Characters 4 through 9 provide information about the vehicle's
attributes, such as its model, body type, and engine type.
 Vehicle Identifier Section (VIS): Characters 10 through 17 make up the VIS, which is a unique serial
number for that specific vehicle. It's used to differentiate vehicles produced by the same manufacturer
with the same attributes.
Vehicle Identification Number (VIN)
In automotive software, VINs can be used for various purposes, including software updates, diagnostics,
and maintenance. Manufacturers and service centers may use the VIN to determine the exact vehicle
model and configuration, ensuring that the correct software updates or diagnostic procedures are
applied. It also aids in tracking a vehicle's service history and ensuring that it complies with safety and
emissions regulations.
OBDII Query
Service 09 - Request vehicle information

PID 02
OBDII Response
17 bytes returned
ISO TP (ISO 15765-2)
ISO TP (ISO 15765-2) as a Transport Protocol is used as a transport layer protocol within the OBD-II
communication stack. It serves as a method for transmitting diagnostic information between the
vehicle's ECM and external devices in a reliable and standardized manner.
Segmentation and Reassembly: One of the key features of ISO TP is its ability to handle large
messages by segmenting them into smaller packets for transmission and then reassembling them at
the receiving end. This is important because some OBD-II diagnostic messages can be quite long,
and breaking them into smaller pieces ensures data integrity and efficient communication.
Flow Control: ISO TP includes flow control mechanisms to manage the transmission of segments. It
ensures that the receiving end is ready to receive and process data before the transmitting end
continues sending more segments. This prevents data overload and potential data loss.
If we want to transmit more bytes of data (>8 bytes) using CAN protocol what we will do? Here we will
use CAN TP concept, because maximum payload of CAN message is 8 bytes.
The standard ISO 15765 – 2 involves 2 layers of OSI model “network layer” and “transport layer”, the
ISO transfer protocol segments longer CAN message frame into multiple frames, Multi frame contain
one first frame and minimum one or more consecutive frames. Using CAN – TP up to 4095 bytes (i.e.,
4KB) of payload can be send per message packet.
 Single Frame: Unsegmented message which can be fit into single frame.
 First Frame: First frame of segmented message.
 Consecutive Frame: Frame followed by the first frame are consecutive frame.
 Flow Control Frame: When first frame is received a flow control frame is send, which contain
status flow, block size and minimum separation, it’s used for acknowledging the first frame.

Course 3

Uploaded by

Copyright:

Available Formats

Course 3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Course 3

Uploaded by

Copyright:

Available Formats

Mastère Professionnel Co-

Omar Triki Lecture 3 2023-2024

 from development where we want to carry out debugging

Data Link Connector (DLC)

 The query is sent on the CAN bus  ID?

Query ID + Length + Service + PID

Let decode the response received from the ECU

Response ID + Length + Service plus 40 + PID + Response bytes

 The query is sent on the CAN bus  ID?

Query ID + Length + Service + PID

Response ID + Length + Service plus 40 + PID + Response bytes

Here's how a typical VIN is structured:

Service 09 - Request vehicle information

You might also like