[Probably the last article] Vehicle Diagnostic Communication Part 99 [Looking Back]

[Probably the last article] Vehicle Diagnostic Communication Part 99 [Looking Back]車両診断通信
[Probably the last article] Vehicle Diagnostic Communication Part 99 [Looking Back]

Click here for back issues.



Probably the last article.
I’ll do a quick look back.


Last article?

The story of vehicle diagnostic communication is approximately over.
Therefore, this article is the last article.
However, I didn’t think it would last until the 99th article….

I explained the layers of communication one by one….
I even did a simulation.

Even though it is a simulation, it is easier to get an idea of what it looks like when you actually run the simulation.


A Brief Look Back

Let’s look back briefly.

I think it was a mix of the difficulties of CAN itself, diagnostic communication, and diagnostic services.
Although there are separate layers, it is necessary to be aware of the lower layers.
Compared to TCP/IP, the convenience of the lower layers may have a strong influence on the upper layers.

Diagnostic services are even more difficult, because in addition to that, you have to consider the actual operation.
Diagnostic services are the very thing we want to do, so we often closely follow the vehicle lifecycle.
They are used not only during development, but also during production, market, and disposal.

There are also protocols such as XCP for vehicles, but these are development-specific protocols and are rarely used in production and market failure analysis.
This site also has an article on XCP, written in Japanese.
If you are interested, you may want to look at XCP-related articles in the site search.


One moment, the series is over!

At any rate, this series is over for now!
(Though there may be more to come if new ideas pop up…)



  • Brief look back.
    • The vehicle diagnostic communication has a wide range of use cases, which makes it a broad topic.
  • This series is now over.

Click here for back issues.