![[DoCAN] Vehicle Diagnostic Communication Part 1 [Overview]](https://www.simulationroom999.com/blog/wp-content/uploads/2022/10/01_eyecatch-23.png)
Click here for back issues.
https://www.simulationroom999.com/blog/diagnostic-communication-en-back-issue/
Introduction.
Automobiles are equipped with a diagnostic communication function.
This is a series of articles about it.
The genesis of things that often occur.
This is usually how people end up learning about vehicle diagnostic communications, isn’t it?
The characters are a client belonging to an ECU supplier company, his boss and his subordinate belonging to a subcontractor company.
Customer: “We are developing a new ECU recently, but we are having trouble with various requirements from the manufacturer.”
Boss: “Oh, well. We can take care of anything!
Customer: “I’m always sorry. Is your company expert in vehicle diagnostic communication?”
Boss: “Diagnosis? Ah, our vehicle diagnostic communication is perfect!
(I think the customer should ask specifically how it is perfect…)
Customer: “That’s good to know! The vehicle diagnostic communication function is the easiest to isolate when carving out ECU functions.”
Boss: “Oh, really?”
Customer: “I would like to leave the entire vehicle diagnostic communication function to you.”
Boss: “Leave that to me already!
(This situation is not normal, the customer should not leave it to him!)
The boss then returns to his own office to talk to a subordinate of his.
Boss: “All right! My subordinate! It’s vehicle diagnostic communication. It’s easy to isolate. It’s easy to get orders.”
Subordinate: “What is vehicle diagnostic communication? Is it like non-destructive testing?”
Boss: “Don’t you know that? But you have to find out by yourself.”
(Normally, his subordinate should refuse this job.)
There are probably quite a few people who have had to study vehicle diagnostic communication like this.
It is my hope that this series will be of help to such people.
What should you do first?
First, do a Google search for “Vehicle Diagnostic Communication”, “UDS”, or “OBD2”.
You will find that Wikipedia has more information than you might expect.
If you can read Japanese or are willing to translate, the following is the most comprehensive resource.
The case is now closed.
I’m sure you came to my site because it’s not going to happen, right?
Vehicle Diagnostic Communication
Let’s also talk about an overview of vehicle diagnostic communication as I know it.
First, in broad strokes, vehicle diagnostic communication consists of the following.
- Off-board tester, so you can collect vehicle information.
- Various sensor values.
- Various actuators.
- Communication lines include K-LINE and CAN, but CAN is the mainstream.
- In case of CAN, it is called DoCAN (Diagnostic over CAN).
- The standard is ISO 15765-2.
- In case of CAN, it is called DoCAN (Diagnostic over CAN).
- ISO 14229-1 defines various services.
- Acquisition of vehicle information
- Fault information acquisition and erasure
- Reprogramming (FlashROM rewriting)
And you would be stuck with no further information to retrieve.
Is a standard (ISO 15765-2, ISO 14229-1) necessary or unnecessary?
The standard should still be obtained.
Here is why.
The requirements for vehicle diagnostic communication come from the manufacturer, but some may only “comply with ISO 15765-2”.
But it’s hard to read the standard out of the blue, so let me explain a few more details.
Layers of Vehicle Diagnostic Communication
There are relatively distinct layers of vehicle diagnostic communication.
This can be expressed in the OSI model.
The Open Systems Interconnection model (OSI model) is a conceptual model that ‘provides a common basis for the coordination of [ISO] standards development for the purpose of systems interconnection’. In the OSI reference model, the communications between a computing system are split into seven different abstraction layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application.
https://en.wikipedia.org/wiki/OSI_model
The model partitions the flow of data in a communication system into seven abstraction layers, to describe networked communication from the physical implementation of transmitting bits across a communications medium to the highest-level representation of data of a distributed application. Each intermediate layer serves a class of functionality to the layer above it and is served by the layer below it. Classes of functionality are realized in all software development through all and any standardized communication protocols.
Based on this, the DoCAN can be expressed as follows.
| Layer | UDS | OBD |
|---|---|---|
| Application layer | ISO14229-1 | ISO15031-5 |
| Presentation layer | – | – |
| Session layer | ISO14229-2(UDS) | – |
| Transport layer | ISO15765-2(DoCAN) | – |
| Network layer | ISO15765-2(DoCAN) | ISO15765-4(OBD) |
| Data link layer | ISO11898-1(CAN) | ISO15765-4(OBD) |
| Physical layer | ISO11898-2(CAN) | ISO15765-4(OBD) |
What is interesting here is that there are two types of UDS and OBD.
This is where things get complicated in vehicle diagnostic communication.
Basically, there is no problem if we consider only UDS.
However, the OBD is tied to CARB regulations, i.e., vehicle emission regulations, and cannot be ignored.
Vehicle emissions control is the study of reducing the emissions produced by motor vehicles, especially internal combustion engines.
https://en.wikipedia.org/wiki/Vehicle_emissions_control
There are some things that actually have to be measured for the sake of automobile emission regulations.
Typical examples are as follows.
- Vehicle speed
- Accelerator pedal position
- Intake air flow
- Intake air pressure
- O2 sensor value
In other words, the standard specifies how to obtain these.
UDS and OBD
There are two major use cases for vehicle diagnostic communication.
- Process efficiency purposes for manufacturers and suppliers.
- Disclosure of information required by law.
The first is UDS and the second is OBD.
UDS stands for Unified Diagnostic Services.
OBD stands for On-Board Diagnostics.
Since OBD is a standard referenced by laws and regulations, it has clearer communication timeout values, etc. compared to UDS.
The UDS standard only describes recommended values, and the actual values are manufacturer-dependent.
In addition, there is the concept of session control, which allows the communication timeout value to change when switching sessions.
If you try to design a full-fledged system, the many parameters defined in the standard and their unintelligible meanings will take your motivation to the core.
We will talk about the details later, so here it is enough to understand the relationship between the OSI model and the standard number.
Conclusion.
- The typical standards for vehicle diagnostic communication are ISO 15765-2 and ISO 14229-1.
- Depending on the manufacturer’s policy, the standard number may be a requirement rather than a specific requirement.
- The layers of vehicle diagnostic communication can be represented by the OSI model.
- There are two main axes of vehicle diagnostic communication.
- UDS and OBD.
- OBD is referenced by vehicle emission regulations, so the various parameters are clear.
- UDS only has recommended values, and the actual values are dependent on the finished vehicle manufacturer.
- UDS and OBD.
Click here for back issues.
コメント