In the following chapter we look at transport and diagnostic protocols. After a brief introduction, we first consider the transport protocol as it is for CAN in use and then discuss the differences that have arisen in the development of FlexRay. Then we look at the three main diagnostic logs today:

• OBD on CAN - Required by law for the diagnosis of emission-related system
• UDS (Unified Diagnostic-Services) - For general vehicle diagnostic
• PCC 2000 - The predecessor of UDS

The following section is divided into:

• Einleitung
• Off-board communication
• Protocol stack (protocol stack)
• Standardization

Einleitung

So we are moving in the off-board communication, that is, the communication between devices on the vehicle and external workshop and diagnostic testers.

Simplified diagram of the communication in the vehicle

In the ISO / OSI layer model, these are the level 4, the transport layer and the layer 7, the application layer. On the latter, the diagnostic logs are located.

Open System Interconnection (OSI) layer model ISO 1978

Off-board communication

In contrast to the on-board communication with CAN or FlexRay, in each ECU sends its information to all, we have a clear communication in the diagnosis role model: the diagnostic tester always starts the communication. He sends a request, such as: "Are there emissions-related defects in the system" or "What is the oil temperature?". He also sends commands such as: "a Switch on the engine fan". This request, called a diagnostic request goes to one or more control devices. These responses with the appropriate diagnostic responses. So there is a clear division of roles: The tester asked to answer the controllers. We call this communication principle known as the request / response mechanism, as illustrated.

Off-Board Communications - Request / response

At the beginning of the communication do not necessarily know the diagnostic tester, which control devices are installed in the vehicle. That is, he does not always have the exact car model and particularly not the combination of the installed optional equipment. On the one hand, it must therefore be possible that the diagnostic tester communicates with all control devices in any way. On the other hand, of course, can everyone not just the authorized repair station, a diagnostic tester connected to the vehicle. There will be a need to ensure that the diagnostic tester not read all things and above all, can not change or manipulate all things.

Another problem for communication is the result of the messages that are exchanged, are also much longer than a single bus message. If you want to query such as the chassis number, you have to transmit 17 characters. CAN can transmit in a single message of up to 8 user data bytes. So you need more CAN messages in order to realize this query. An extreme case is flashing the ECU software dar. There, there is often delegated to several hundred kilobytes to several megabytes even.

Protocol stack (protocol stack)

By the ISO / OSI reference model, the distribution of tasks in the communication between tester and control unit is set as shown. The diagnostic protocol describes the application layer, ie, the level currently used by the diagnostic application. This application layer now represents individual services, such as the service: "Read fault memory". If the diagnostic message does not fit into a single message bus, cut the transport protocol, then the appropriate diagnostic message at the transmitter into several bus messages. The bus system itself, the data link layer and physical layer send this message.

Protocol stack (protocol stack)

On the side of the control device, the message is received. At the level of the transport protocol in the controller each bus messages are reassembled to the original diagnosis Embassy and handed over the application layer as a service to the application software on the controller. The controller will then turn up the answer and passes it to a service that sends this response. This is again in the transport plane segmented transmitted via the bus system, on the side of the tester back together in reverse order and at the top over to the diagnostic application.

Standardization

When we discuss diagnostic issues, we are dealing mostly with ISO standards and ASAM specification. In the corresponding standards of ISO and ASAM, concerning the transport and diagnostic protocols have control units on one side and tester specific, on the other side names. In ASAM is the diagnostic tester "Master" because he gets into his request requests communication, while the control devices are called "slaves" because they only respond with the responses to such requests. ISO, however, the whole looks more from the perspective of computer science. Here, the control unit, which is waiting for a request, as a "server" and the tester that provides such a request, as a "client".

The following chart you can see listed the different ISO standards, which may confuse some at first glance:

Overview of Standards - Historical development in Europe

Historically, there is the general vehicle diagnostic for a long time. First, she has every manufacturer, at least in the application layer, managed proprietary. At the level of the diagnostic interface one has defined with ISO 9141, the K-line interface, or SAE J1850 relatively early. The differences at the application level have led to the control devices and diagnostic tester manufacturer had a lot of parallel development efforts for various vehicle manufacturers. To reduce this, led to the one specified in the ISO 14230 KWP 2000th This standard attempted to diagnostic services that were with all the manufacturers are working to standardize more or less.

While the introduction of KWP 2000, the K-Line nor the dominant bus system on the market. As was then, however, introduced for the diagnosis of CAN, we have transferred the application layer of KWP 2000 initially to CAN. The changes were relatively small. Was specified with the draft standard ISO / DIS 15765-3, which never left the draft status and became a full ISO standard. Reason: During the development process of this standard, we rejected the KWP 2000 protocol for various reasons and on the so-called Unified System Diagnostic Protocol (UDS) is set. UDS is different, not in the basic principles, but in many details from KWP 2000th This is in the ISO 14229 standard UDS bit clearer and cleaner than KWP 2000th Moreover, it is in principle independent from the underlying bus system, but is now put into practice only for CAN. This reaction is carried out by the ISO 15765 (DIS without!). Part 3 describes the adaptation of CAN and 2, the appropriate transport protocol.

Parallel to the general vehicle diagnostic the legislature was active. The OBD first, the American legislature has placed demands on the exhaust emissions of a vehicle and whose fault monitoring. The Europeans have taken over the then more or less unchanged. Ensure an appropriate diagnosis and a diagnostic interface protocol were necessary. These were specified in Europe in the ISO 15031st This standard has a number of different parts. In the third part, for example, the diagnostic socket (OBD-box) and in Part 5 specifies the application layer with the diagnostic services. OBD is used with all common bus systems, ie, with K-Line, SAE J1850 and CAN.