Introduction

Recently, the number of high performance electronic control units (ECU) installed in vehicles has increased significantly. ECUs provide convenient features to drivers,
such as advanced driver assistance systems (ADAS) . Both the number of ECUs for high-performance and the size of the software for reprogramming are increased. This
results in the requirement for the network to have a higher bandwidth and provide real-time functionality, but the current CAN-based networks cannot meet these requirements because of a small data size of 8 bytes and low bandwidth of maximum 1 Mbps.
To solve these difficulties, DoIP, which is an Ethernet based diagnostic protocol, was introduced for use in automotive systems. Ethernet can support a maximum data size of 1,500 bytes and with a bandwidth 100 Mbps. Therefore, Ethernet-based DoIP can meet the requirements for high-performance functions. Moreover, automotive systems can provide services, such as diagnosis, calibration and software updates for ECUs, and
new applications that support DoIP through the in-vehicle gateway provide convenience to drivers.

Introduction – DOIP

• The new generation vehicle will provide connectivity and telematics services for enabling vehicle communication. The diagnostic over IP in TCP/IP means enables a connection between diagnostic tool and in-vehicle nodes using IP protocols.

• DoIP facilitates diagnostics related communication between external test equipment’s and automotive control units (ECU) using IP, TCP and UDP.

•  Short and simple: “DoIP is the packaging of diagnostic messages in Ethernet frames for communication of a diagnostic tester with a vehicle”

• DoIP is used in combination with the standardized diagnostic protocol UDS (ISO 14229-5: UDSonIP)

• DoIP with Ethernet 100 Base-TX instead of CAN enables substantial higher  bandwidth

• In vehicle diagnostics, the diagnostic tools and vehicles are separated by an inter network.

• The DoIP (Diagnostic over IP) standard is used to develop a prototype for vehicle diagnostics

• The main aim of using IP into the family of automotive diagnostic protocol is that the development of new in-vehicle network has led to the need for communication between external test equipment and onboard ECUs using many data link layer technologies.

• DoIP is a protocol mainly used for communication between off-board and on-board diagnostic system

ISO 13400 has been established in order to define common requirements for vehicle diagnostic systems implemented on a Internet Protocol communication link.

ISO 13400 specifies Transport layer, Network layer, Data Link layer and Physical layer for Diagnostics over Internet Protocol (DoIP).

Since the standard Ethernet Physical layer is used as a transmission medium for DoIP, it is also known as Diagnostics over Ethernet.

DoIP with Ethernet 100 Base-TX instead of CAN enables substantial higher bandwidth

DoIP is used in combination with the standardized diagnostic protocol UDS (ISO 14229-5: UDSonIP)

Diagnostics over IP is now readily available and is specified in ISO 13400. It makes no difference which physical layer is used as long as it supports the transmission of IP packets. For example, besides Ethernet, the use of WLAN and UMTS as physical media is also conceivable with DoIP.

The important thing here is that DoIP does not represent a diagnostic protocol according to ISO 13400 but rather an expanded transport protocol. This means that the transmission of diagnostic packets is defined in DoIP, but the contained diagnostic services continue to be specified and described by diagnostic protocols such as KWP2000 and UDS.

A requirement for DoIP is the support of UDP and TCP. UDP is used for transmission of status or configuration information. A TCP connection, on the other hand, enables transmission of actual diagnostic packets via a fixed communication channel. This ensures high reliability of data transmission and enables automatic segmentation of large data packets. TCP and UDP must be implemented in the diagnostic tester as well as in each ECU with DoIP diagnostic capability (DoIP Node) and in each diagnostic gateway (DoIP Gateway or DoIP Edge Node).

As mentioned before, ISO 13400-2 transport layer facilitates diagnostic communication between external test equipment and vehicle electronic components.

• The implementation of a common set of Unified Diagnostic Services (UDS) on Internet Protocol (UDSonIP) is done using ISO 14229-5 Application layer.

• The Vehicle transport layer is facilitated by TCP or UDP. Based on the standard, IPv6 acts a Network Layer and IPv4 can be used for compatibility.

• Ethernet MAC is used as the Data Link Layer. The corresponding Physical Layer for on-board communication is specifies as Broad Reach or 100 Base T, while that for off-board communication is Ethernet.

is DoIP mandatory to use UDS over Ethernet?

UDS defines the Application Layer, but you will need also a Transport Layer – this can be:

• ISO-TP (ISO 15765-2) in case of CAN (UDS on CAN; ISO 14229-3)
• DoIP (ISO 13400-2) in case of Ethernet (UDS on IP; ISO 14229-5)

Using “only UDS” without a Transport Layer is not possible

On the basis of systems architecture:

UDS application layer has been modified to support compatibility with Ethernet transmission medium. This compatibility for UDS on IP is defined by ISO 14229-5 standard.

While the ISO 14229-3 standard defines implementation of UDS on CAN. UDS on IP has DoIP Transport Layer defined by ISO 13400-2 standard. While UDS on CAN has ISO 15765-2 transport layer that support CAN physical layer.

The physical layer for UDS on IP is Ethernet, based on IEEE 802.3, a wired vehicle interface standard and the UDS on CAN is defined by ISO 11898 standard (classical CAN network

On the basis of Data Transmission:

• UDS on IP supports greater latency time of data transmission as compared to CAN.
• A greater bandwidth capacity in DoIP enables it to handle large amount of data in comparison with CAN.
• The standardized data format in DoIP makes the data less prone to error and ideal for diagnostic services.

Why UDS over Ethernet (as DoIP) for next generation automotive applications?

The ever growing complexity of electronic systems and need for large volume of data communication between vehicle networks, meant that automotive OEMs’and Suppliers felt the need for a more effective vehicle communication network like Ethernet.

Case in point: ECU re-programming, remote & on-board diagnostics are some examples of automotive applications that demand for faster data transfer rate.

As Ethernet physical layer doesn’t support bus like structure (like that in CAN), a switch is required for every network node. This ensures that Ethernet based DoIP supports rates of upto 100 mbps as compared to 500 kbps by CAN.

In the past, OEM’s provided diagnostic services over proprietary or KWP protocols. But the trend has shifted to more popular (UDS) protocol that supports various BUS systems such as CAN, K-line, FlexRay and Ethernet.

Hence, UDS is now the most properly used standard for Diagnostic Protocol. DoIP transport layer is defined as a part of the UDS specification.

USE OF DOIP

Retrieving a predefined amount of data from a vehicle without any need for connection establishment or security, 

• Quick availability of data that are needed for inspection, maintenance and repair over the IP network without any need for connection establishment or negotiation, 

•  Programming or updating ECU software with connection establishment and security negotiation, 

• Quick availability of all the data that is needed for inspection, maintenance and repair in the assembly line without any need for connection establishment and security negotiation, 

• Retrieval of non-diagnostic data, such as address book, e-mail from infotainment components and transferring it to the vehicle or vice versa.

Diagnostic Gateway Implementation

The external diagnostic devices based on DoIP cannot interface directly with in-vehicle networks, so an in vehicle gateway is essential to integrate different in-vehicle networks with Ethernet. As a result, the external diagnostic devices can be connected to the automotive system. The gateway provides an interface to the external diagnostic devices to access the in-vehicle ECUs through an on-board diagnostics (OBD) terminal. If the external diagnostic device is connected to the Internet, the vehicle can provide a range of telematics services from the external diagnostic devices through the gateway.

The diagnostic gateway can be connected to the external diagnostic device through the Transmission Control Protocol (TCP), and provides the reliability and integrity of the diagnostic data through the TCP connection. Diagnostic request messages (from the external diagnostic device to the in-vehicle networks) are packed in the TCP datagram and transmitted to the gateway. The diagnostic gateway unpacks the TCP datagram when the TCP packet is received, and separates the diagnostic information (DoIP data type, data length, target address, data payload) into the TCP datagram. Moreover, the
gateway searches the configured routing table that includes a routing parameter, such as the target address, a network type of a target ECU and other network information, and transmits the diagnostic request data to the destination network domain (CAN and FlexRay). The target ECU receives the diagnostic request messages, which perform a diagnostic operation, and transmit a diagnostic response message. The diagnostic
response message is assembled in DoIP format by the diagnostic gateway. A DoIP frame is packed in the TCP datagram, and the diagnostic gateway transmits the TCP
packet to the external diagnostic gateway.

The diagnostic gateway implements the basic operation, such as the connection control, routing activation handler, DoIP header handler and routing of diagnostic messages, and adds additional functions, such as security and a software reprograming.

The system consists of the following components: one gateway ECU, two ECUs connected to a High Speed CAN (HS-CAN), two ECUs connected to a Low Speed CAN (LS-CAN), two ECUs connected to a FlexRay network, and on ECU connected to an Ethernet network

Nested header structure

A) The Protocol Version field specifies the version of the DoIP protocol being used, such as 0x01, 0x02, or 0x03. The Inverse Protocol Version field carries the bit inverted value of the Protocol Version, ensuring error-checking during transmission.

B) Payload type :The Payload Type field, represented by two bytes, indicates the type of payload in the message. Multiple payload types are defined, including vehicle identification, diagnostic message delivery, and route activation.

c) The Payload Length field, represented by four bytes, specifies the length of the payload in bytes. It determines the number of data that follows the header section.

d) The DoIP Payload contains the actual data to be transmitted, such as diagnostic messages or control signals. The structure of the payload depends on the Payload Type specified in the header. Within the payload, the Identifier field is used to identify the sender and receiver of the message, providing Source Address and Target Address subfields.

The DoIP module can manage the active connection between the external diagnostic device and the gateway, and it routes the diagnostic messages between the external
diagnostic device and the in-vehicle networks. presents the process for routing the diagnostic message to the target ECU from the external diagnostic device. The
gateway receives the DoIP request messages from the external diagnostic device, and the received DoIP request messages are delivered to the DoIP module through the
TCP/IP stack. The DoIP module separates the protocol version, payload type, and payload length in the DoIP frame, and then checks the target ECU address in the DoIP payload. Finally, the diagnostic user data in the DoIP payload is transmitted to the network domains connected to the target ECU.

Diagnostics process

During diagnosis, the diagnostic gateway first receives the request from the tester. The request contains the diagnostic packet with the desired diagnostic service and the logical address of the ECU to be diagnosed. The gateway then removes the diagnostic packet and packs it into a message that can be sent on the utilized bus system or network. For example, if an ECU is to be addressed using CAN, the gateway sends out a message with the associated identifier (e.g., 0x600) to this bus. It then waits for a response from the ECU. As soon as the response is received from the associated bus system or network (e.g., CAN with identifier 0x700), the gateway returns the response for the original diagnostic service to the tester. For this, it adds the logical address of the ECU so that the tester can uniquely assign the response. This allows a tester to send requests for multiple ECUs to different bus systems and networks without waiting for a sequential response.

Let’s explore the step-by-step communication flow involved in establishing a connection between the user test equipment and the DoIP entity in the vehicle.

1.Opening a UDP Socket: The initial step is to open a UDP socket with the destination port (13400). This socket allows communication between the client and server.

2. Vehicle Identity Request: The client sends a vehicle identity request to the server DoIP, seeking information about the vehicle’s identification. This request helps establish a connection between the client and the vehicle.

3. Vehicle Identity Response: The server DoIP responds to the vehicle identity request by providing the necessary information, such as VIN (Vehicle Identification Number), GID (Global Identifier), EID (Entity Identifier), and logical address.

4. Opening a TCP Connection: After receiving the vehicle identity response, the client opens a TCP connection over the TCP_DATA port. From this point forward, all further messages are exchanged via this TCP socket.

5 Routing Activation Request: To enable routing on the initialized connection, the client sends a routing activation request message to the DoIP server. This request indicates the client’s eligibility and the desire to activate routing.

6.Routing Activation Response: If the client is eligible and there are fewer active connections registered, the server responds with a routing activation response. This response confirms that the routing has been successfully activated, allowing the client to send valid DoIP messages, such as diagnostic messages.

7. DoIP Header Handler: The DoIP entity executes the DoIP header handler upon receiving any type of data. If the payload contains a diagnostic message (identified by payload type 0x8001 in the generic DoIP header), the diagnostic message handler is called to process the payload.

8. Diagnostic Message Handler: The diagnostic message handler parses the received request, filters the required data for the UDS request based on the service ID and identification, and forwards it to the UDS protocol handler. This handler plays a crucial role in processing diagnostic requests and generating appropriate responses.

9.Diagnostic Response: Once the diagnostic response is formed, the ECU transmits it to the user test equipment. This response contains the requested data or information related to the diagnostic process.

This communication flow ensures a seamless exchange of information between the client and server, allowing for effective diagnostic processes and troubleshooting.

Refrences:

https://avtoad.com.ua/en/base/ethernet-doip-diagnostic-protocol

What is a LIN Bus?

The Local Interconnect Network, or LIN Bus, plays a crucial role in facilitating communication between components within vehicles. Designed as a supplement to the more complex CAN Bus system, LIN offers a more economical means for connecting various parts of a car’s network.

While the LIN protocol is notably more cost-effective than its CAN counterpart, it does so by modestly scaling back in terms of performance and reliability. This balance of cost and functionality makes LIN an intelligent choice for less critical communication tasks.

What is a LIN protocol?

The LIN protocol is a structured system of wired communication specifically designed for electronic devices  within vehicles. It operates on a master-slave architecture, where a single master device controls the communication flow to one or several slave devices.

Communication within the LIN network is organized into frames, each containing a header and a response. The master initiates the dialogue by sending out the header, while the response is provided by a designated slave or, in some cases, the master itself.

Additionally, the LIN protocol is designed with two distinct operational states: an active mode for regular communication and a sleep mode for energy conservation when the network is not in use.

The LIN specification has been repeatedly revised, and three types, LIN Revision 1.3, 2.0, and 2.1, are mainly used for automotive ECUs, but the last revision by the LIN Consortium was LIN Revision.2.2A. It has now been transferred to ISO, and the LIN specification was published as ISO17987 in August 2016. LIN is positioned as a sub-bus of CAN, making it possible to construct a network at a lower cost than CAN.

Key facts about LIN Bus

Here are key facts about the LIN Bus protocol, highlighting its functionality and design within vehicle communication systems:

• Cost-efficient solution.
• Single wire, capable of 1-20 kbit/s, up to 40m (+ground).
• Standard 12V operating voltage.
• Commonly used for vehicle subsystems like wipers and windows.
• Configurations include 1 master and up to 16 nodes.
• Modern vehicles often feature over 10 nodes.
• Supports various data lengths: 2, 4, and 8 bytes.
• Ensures timely data transfer with scheduled transmission.
• Features sleep mode and wake-up capabilities.
• Adheres to ISO 9141 – K-line for the physical layer.
• Includes error detection and configuration mechanisms.

LIN network construction example

Today, LIN bus is a de facto standard in practically all modern vehicles – with examples of automotive use cases below:

• Steering wheel: Cruise control, wiper, climate control, radio
• Comfort: Sensors for temperature, sun roof, light, humidity
• Powertrain: Sensors for position, speed, pressure
• Engine: Small motors, cooling fan motors
• Air condition: Motors, control panel (AC is often complex)
• Door: Side mirrors, windows, seat control, locks
• Seats: Position motors, pressure sensors
• Other: Window wipers, rain sensors, headlights, airflow

Further, LIN bus is also being used in other industries:

• Home appliances: Washing machines, refrigerators, stoves
• Automation: Manufacturing equipment, metal working

Positioning with other protocols

LIN bus history

Below we briefly recap the history of the LIN protocol:

• 1999: LIN 1.0 released by the LIN Consortium  (BMW, VW, Audi, Volvo, Mercedes-Benz, Volcano Automotive & Motorola)
• 2000: The LIN protocol was updated (LIN 1.1, LIN 1.2)
• 2002: LIN 1.3 released, mainly changing the physical layer
• 2003: LIN 2.0 released, adding major changes (widely used)
• 2006: LIN 2.1 specification released
• 2010: LIN 2.2A released, now widely implemented versions
• 2010-12: SAE standardized LIN as SAE J2602, based on LIN 2.0
• 2016: CAN in Automation standardized LIN (ISO 17987:2016)

LIN FRAME FORMAT

The LIN frame format is straightforward, composed of two main components: a header and a response. In a typical exchange, the LIN master dispatches a header onto the bus, prompting a response from a designated slave node.

This response can carry a payload of up to 8 data bytes. The streamlined structure of the LIN frame is designed for efficient communication within the network. Below, you’ll find a detailed illustration of the LIN frame format, showcasing the precise way that messages are constructed and exchanged within the system.

Break: The Sync Break Field (SBF) aka Break is minimum 13 + 1 bits long (and in practice most often 18 + 2 bits). The Break field acts as a “start of frame” notice to all LIN nodes on the bus.

13 dominant bits long including start bit. Synch break ends with a “break delimiter” which should be at least one recessive bit.

Sync: The 8 bit Sync field has a predefined value of 0x55 (in binary, 01010101). This structure allows the LIN nodes to determine the time between rising/falling edges and thus the baud rate used by the master node. This lets each of them stay in sync.

Identifier: The Identifier is 6 bits, followed by 2 parity bits. The ID acts as an identifier for each LIN message sent and which nodes react to the header. Slaves determine the validity of the ID field (based on the parity bits) and act via below:

1. Ignore the subsequent data transmission
2. Listen to the data transmitted from another node
3. Publish data in response to the header

 The Identifier determines the content of the message and also the priority; lower numerical values mean higher priority. Nodes on the network use this field to decide whether to ignore the message, to listen in, or to prepare a response for the frame’s data field that follows.

Typically, one slave is polled for information at a time – meaning zero collision risk (and hence no need for arbitration).Note that the 6 bits allow for 64 IDs, of which ID 60-61 are used for diagnostics (more below) and 62-63 are reserved.

The parity bits are calculated as followed: parity P0 is the result of logic “XOR” between ID0, ID1, ID2 and ID4. Parity P1 is the inverted result of logic “XOR” between ID1, ID3, ID4 and ID5.

Data: When a LIN slave is polled by the master, it can respond by transmitting 2, 4 or 8 bytes of data. The data length can be customized, but it is typically linked to the ID range (ID 0-31: 2 bytes, 32-47: 4 bytes, 48-63: 8 bytes). The data bytes contain the actual information being communicated in the form of LIN signals. The LIN signals are packed within the data bytes and may be e.g. just 1 bit long or multiple bytes.

Checksum: As in CAN, a checksum field ensures the validity of the LIN frame. The classic 8 bit checksum is based on summing the data bytes only (LIN 1.3), while the enhanced checksum algorithm also includes the identifier field (LIN 2.0)

Six LIN frame types

Multiple types of LIN frames exist, though in practice the vast majority of communication is done via “unconditional frames”.

Note also that each of the below follow the same basic LIN frame structure – and only differ by timing or content of the data bytes.

LIN Bus vs. CAN Bus

• LIN is lower cost (less harness, no license fee, cheap nodes)
• CAN uses twisted shielded dual wires 5V vs LIN single wire 12V
• A LIN master typically serves as gateway to the CAN bus
• LIN is deterministic, not event driven (i.e. no bus arbitration)
• LIN clusters have a single master – CAN can have multiple
• CAN uses 11 or 29 bit identifiers vs 6 bit identifiers in LIN
• CAN offers up to 1 Mbit/s vs. LIN at max 20 kbit/s

The LIN Node Configuration File (NCF) and LIN Description File (LDF)

The LIN network is described by a LDF (LIN Description File) which contains information about frames and signals. This file is used for creation of software in both master and slave.

The master node controls and make sure that the data frames are sent with the right interval and periodicity and that every frame gets enough time space on the bus. This scheduling is based on a LCF (LIN Configuration File) which is downloaded to the master node software.

All data is sent in a frame which contains a header, a response and some response space so the slave will have time to answer. Every frame is sent in a frame slot determined by the LCF.

LIN Bus: Streamlining Communication

1. Known for its straightforwardness and affordability, LIN Bus provides a streamlined option for vehicle communication.
2. With a clear master-slave relationship, it ensures organized dialogue between one master and several slaves.
3. LIN Bus shines in managing simple tasks such as adjusting mirrors, seats, and operating wipers.
4. To save power the slave nodes will be put in a sleep mode after 4 seconds of bus inactivity or if the master has sent a sleep command. Wakeup from sleep mode is done by a dominant level on the bus which all nodes can create.

CAN Bus: The Nerve Center of Auto Communication

1. CAN Bus stands out for its capacity to handle essential, data-heavy systems like the engine and safety mechanisms.
2. Positioned at the heart of the vehicle’s network, CAN Bus orchestrates complex communication.
3. It teams up with LIN Bus, allowing LIN to take on the simpler tasks, thereby enhancing the network’s efficiency.

Refrences