On board vechicle communication interface – Ethernet

This state of art  Telematic control unit  includes on board vehicle communication interface over automotive Ethernet 100Base-T1 or Broad-R physical interface.

This enables access to vehicle communication network and open doors for realization of several use cases.

Few typical use case includes

  1. Remote Signal acquisition that allows AI algorithms to suggest  preventive maintenance, analyze driving behavior.
  2. Remote Diagnostics – Uds, OBD-II,etc
  3. Software updates over the Air / Flashing over the Air
  4. Emergency call (E-call)
  5. Pay how you drive – Interesting for insurance companies

Telematic Control Unit (TCU) is playing the role of diagnostics tester on board. On Ethernet based vehicle network diagnostics will be done using a protocol called DoIP (Diagnostics over IP).

The DoIP capable ECUs and Gateways on the network will play the DoIP-server. DoIP protocol works on top of TCP connection. The DoIP-server listen of tcp port 14300.

TCU shall implement a DoIP download client that act as a tester for a test of network.

Please refer to  official ISO 14300 specification for further details.

K-Line Data Transfer

After the communication link has been established, the tester can send request messages and receive message response(s) from the ECU(s) of the OBD system. This is referred to as data transfer and is performed by the transfer() method.

The transfer timing is very important and is determined by the periods P1…P4 with specified maximal and minimal allowable values.

The timing is implemented by using system timer for wait function and by using communication read timeouts.

In this way it is possible to group received response bytes into messages, based on separation period P2.

The period P3max has value of 5000 ms. After that time the communication link is automatically terminated by the server.

Therefore, to keep connection alive the tester must send periodically request messages.

Kline data transfer

Credits & further reference:
http://www.cnblogs.com/shangdawei/p/3593598.html

K-Line Fast Initialization

The fast initialisation sequence starts with wake-up pattern (WuP), transmitted by the tester simultaneously on K and L lines(if available)

After the time TWuP has elapsed the client sends StartComminication message request.

This message uses functional addressing and contains the target address of the OBD system and the source address of the tester.

The server responds with StartCommunication positive response(s), which contains the keywords.

fast init

Credits & further reference:
http://www.cnblogs.com/shangdawei/p/3593598.html

K-Line 5-baud init

The tester issues the initialisation request at address 0x33 with 5 bits per second. Once the vehicle’s ECU has validated the address (after time W1) a confirmation is sent to the tester at 0x55, the so called synchronisation byte. This synchronisation byte tells the tester the baud rate at which communication shall take place, usually 10400 baud. The tester then re-configures the baud rate, while the vehicle waits (W2). After time W2 has passed the vehicle sends two key bytes (either 08,08 or 94,94) to the tester with a delay of W3. These key bytes describe the collision prevention time P2MIN after which an ECU is checking the K-Line for a falling edge. [Reif, Automotive Mechatronics, BOSCH] If the tester acknowledges P2Min the second key byte is inverted and returned to the vehicle. The vehicle then sends the complement of 0x33 to the tester as confirmation, signaling ready for interaction.

5 baud init
5 baud init sequence

Credit: 
https://stackoverflow.com/questions/34743457/python-obd-encoding