Carlos Enrique Hernández Ibarra bio photo

Carlos Enrique Hernández Ibarra

Passionated Software Engineer with experience in the Automotive Industry. Interested in the state of the art of design, development, and test of technology based on C/C++, Autosar, and Matlab/Simulink. Nevertheless, always with an open mind to new technologies, industries and solutions.

Email LinkedIn Github

LIN communication

LIN (Local Interconnected Network) is a serial automotive network protocol designed to establish a Local Network connection between devices at a lower cost compared to other networks like CAN (Controller Area Network), CAN FD (Flexible Data-rate), etc. Unlike more complex networks, LIN is not intended to be the primary network for the entire vehicle but serves as a complementary network for specific applications within the vehicle.

01

In the provided diagram, the red arrows represent CAN communication, while the green arrows represent LIN communication. Notably, the communication between the modules of the Seat Belt is exclusively through LIN. However, the communication between the Security Modules and the Seat Belt involves the use of CAN. This design choice is influenced by the fact that LIN does not offer the same bandwidth as CAN. Therefore, for data exchanges involving larger amounts of information, where LIN might be less suitable, CAN is employed to ensure efficient communication between the Seat Belt and other Security Modules.

The main properties of a LIN bus are:

  1. One master for “n” slaves.
  2. Similar low cost implementation of sillicon related to UART/SCI communication.
  3. Self sycnhronization without the need of external clock in the slave nodes.
  4. Deterministic signal transmision

Concepts

Node

Within a LIN cluster, nodes are signal based interaction layers to allow the Application SW to access the LIN physical layer.

02

Within the LIN interface, there is an attached “Transport layer” responsible for defining the transportation of one or more frames, including Single Frames or Multiple Frames. Positioned between the Physical Frame Handling and the Application layers, the transport layer plays a crucial role in managing the transmission and reception of frames, ensuring effective communication within the LIN network.

In a LIN Cluster, there is always a Master Node and one or more Slave Nodes. The Master Node encompasses two types of tasks: a Master Task and a Slave Task. On the other hand, Slave Nodes can only contain Slave Tasks.

  1. Master Task: Responsible for determining the flow of communication between nodes within the LIN bus.
  2. Slave Task: Provides the necessary data for each frame within the LIN communication.

In the LIN Cluster architecture, the Master Node initiates a process where it requests data from each Slave Node in parallel. Simultaneously, the Master Node also provides data from its own node, especially when a Slave Node requires information to formulate a response. This bidirectional exchange of data ensures effective communication and coordination within the LIN network.

Frame

In the LIN communication protocol, a frame is composed of a header and a response. The responsibilities for providing these components are divided between the Master and Slave tasks:

  1. Header:
    • Provided exclusively by the Master task.
    • Mainly comprises a break field, synchronization field, and a frame ID.
  2. Response:
    • Provided exclusively by the Slave task.
    • Mainly consists of a data field and a checksum.

03

This division ensures that the Master and Slave nodes each contribute essential information to the construction of a LIN frame, maintaining a structured and coordinated communication process.

Within a LIN frame, two types of data can be transported:

  1. Diagnostic Message:
    • Composed of two reserved frame ID bytes along with a data field.
    • Diagnostic messages have the capability to trigger various behaviors in the receiving node.
    • The specific behavior triggered depends on the communication status of the receiving node, whether it is in a normal communication state or any special state such as DV mode, extended session, etc.
  2. Signals:
    • Signals can represent scalar values or arrays of scalar values.
    • Signals consistently maintain the same order within the frame.

These two types of data, diagnostic messages and signals, allow for the transmission of diverse information within the LIN communication framework, serving different purposes based on the content and context of the data.

Schedule Table

The schedule table is an essential component that specifies the transmission of headers within a LIN cluster, defining both the order and timing of these transmissions. In the LIN communication framework, the Master Application Software has the capability to define multiple schedules and transitions between them. This flexibility in schedule definition allows for dynamic adjustments and efficient coordination of communication events within the LIN network.

Signal Management

In a LIN cluster, signals can take the form of scalar values or arrays of scalar values. The interaction between signals and nodes follows a publisher-subscriber model:

  1. Publisher-Subscriber Relationship:
    • Each signal has a designated publisher, who is exclusively authorized to write data for that particular signal.
    • There can be zero, one, or more subscribers to a signal, which are nodes interested in receiving and processing the signal.
  2. Initial Value Requirement:
    • As per node configuration specifications, every signal must have an initial value.
    • The initial value remains in effect until the signal publisher updates the signal data with new information. Once updated, the signal is ready to be published to the other nodes in the network.

This mechanism ensures a controlled and structured flow of data within the LIN cluster, with signals serving as carriers of information between nodes.

Signal operations, including writing and reading, must be atomic operations in LIN communication. Atomicity ensures that these operations are indivisible and occur as a single, uninterruptible unit.

Signal packing dictates that a signal’s transmission involves bundling multiple signals into a frame. During the reading and writing processes, data flows from the Least Significant Bit (LSB) to the Most Significant Bit (MSB). For optimal efficiency in the packing and unpacking procedures, signals should be aligned to ensure they are separated in multiples of bytes. This alignment enhances the overall efficiency of the packing and unpacking operations within the frame.

Signal reception and transmission are intricately linked to the timing of both the Master and slave nodes. The master node, responsible for managing the schedule, determines precisely when to dispatch each specific frame. In contrast, the timing of the slave node revolves around the reception of headers from the Master node. This synchronization ensures a coordinated and efficient exchange of signals within the LIN network.

Signal reception is acknowledged through distinct mechanisms for the master and slave nodes:

  1. Master Node: The master node lacks explicit acknowledgment of signal reception. It updates its received signals periodically, adhering to the timing specified at the task level. 04

  2. Slave Node: The slave node acknowledges the reception of a signal upon successful validation of the checksum in the received frame. The timing for this acknowledgment is based on the interruption level, ensuring precise coordination in the LIN network.

05

Frame Transfer

A frame is constructed by two compositions: A header and a response.

  1. The header is composed by the break field, a PID and the synch field.
  2. Break field. The break field is exclusively generated by the master task, signifying the commencement of a new frame. Comprising a minimum of 13 nominal bits, each set to a dominant value, the break field is succeeded by a break delimiter. Slave nodes detect the impending header transmission when they identify at least 11 dominant bits within a specified threshold.
  3. Synch field. The synch byte field contains a data value of 0x55. Coupled with the break field, this ensures that the slave consistently detects new frame headers and processes requests for old frame information in a timely manner. 06
  4. Protected ID (PID). The PID comprises a frame ID and a parity checker. The two most significant bits are reserved for parity checking, while the remaining bits are utilized as the frame ID.
  5. The Frame ID is 6 bits long 1. Values from 0x00 to 0x3B are intended to be used for frames carrying signals. 2. Value of 0x3C or 0x3D are used to diagnostic and configuration carrying signals. 3. Value of 0x3E and 0x3F are intended for future protocol enhancements.
  6. The parities bit are calculated based on the frame ID bits as follows: 1. P0 = ID0 ⊕ ID1 ⊕ ID2 ⊕ ID4. 2. P1 !(ID1 ⊕ ID3 ⊕ ID5). 07

Response

The data response carries between 1 to 8 bytes of data, with the Least Significant Bytes (LSBs) sent first. For validation, both the publisher and all subscribers must agree on the data contained within a frame. The response can contain two different types of checksums.

  1. Classic checksum, which is the inverted sum of data response, it is used for LIN 1.x nodes and diagnostic and configuration frames.
  2. Enhanced checksum, which is the inverted sum of data response plus PID,it is used for LIN 2.x nodes

Transport layer

Transport layer defines how to transport data that can be contained within only one frame or within several frames from a LIN cluster. The transport layer is intended to set diagnostic to a back-bone bus (external from the LIN cluster).

08

PDUs

The units transported from the Transport Layer are called Packed Data Units (PDU). These can be part of complete messages or part of several consecutive messages. Messages issued by the client (external tester or the master node on behalf of external devices) are referred to as requests, while messages issued by the server (LIN cluster) are called responses.

To simplify the mapping from LIN transport layer frames to other transport layer frames, a similar message structure is defined as follows:

  1. NAD (Node Address): Sent first, this is the address of the slave node. Only slave nodes have NAD, as NADs are used to indicate the source of a response. NAD ID values range from 1 to 127, while other IDs are reserved for different purposes. Since a slave node can be logically addressed by several mappings, a physical slave can have numerous logical NADs.
  2. PCI (Protocol Control Information): Defines whether the transported message can fit into a single PDU or requires several PDUs. When PCI = SF, means that the transported message fits into a single PDU. Also, it contains the length of the data inside this Single Frame. When PCI = FF, means that the transported message does not fit into a single PDU, and that the transportation of that message is beginning. FF indicates the first PDU of the multiple PDU message. Also, it contains the total of Consecutive Frame data indicating how many Consecutive Frames are required to transport the multi PDU data. When PCI = CF, means the continuation of the Consecutive Frames sending. It consists also of the frame counter, which is consecutive from 0 to 15 and it wrappers the counter when it reaches the maximum number.
  3. LEN, it is used only for PCI = FF, it contains the least significant bits of the message length, so the maximum is 4095 (0xFFF).
  4. SID (Service ID), defines the request that shall be performed by the slave node, it can be diagnostics responses or node configurations.
  5. RSID (Response Service ID), specifies the content of a response (activated by a request with SID), it is the way that slave nodes respond for a diagnostic or configuration request. About diagnostic, either the response is positive or negative (NCF), the slave shall responded. While configurating the slave should be able to configure and respond in the next schedule time. The RSID for a positive response is always = to SID + 0x40.
  6. Data (1 to 6), the interpretation of this data depends merely from the SID and RSID values and if the message is not filled completely, then the mas value is always 0xFF

Transport Layer Communication

The Transport Layer can process only one message in the bus at one time. Transmission of PDUs messages are up to six bytes always shall be SF.

  1. When a SF with more than six bytes is received, then any receiver shall ignore it.

Transmission of PDU messages longer than six bytes, up to a maximum of 4095 bytes, always involves segmentation into consecutive messages starting with FF and continuing with CFs.

  1. When an FF with a length less than 6 bytes is received, then any receiver shall ignore it.
  2. When an FF with a length greater than 4095 is received, then any receiver shall ignore it as well as the following CF transmissions.
  3. Any NAD that does not exist receiver, and PDUs with unexpected PCIs shall be ignored.
  4. When the reception of CF with a no consecutive sequence number occurs, then the reception of the message shall be aborted.

Node Configuration by CANoe

CANoe is a Vector toolset which is able to configure a complete LIN cluster. Inside the toolset, you can find the option of LDF Explorer. LDF stands for (LIN Description File) and encloses all configuration required to run a LIN cluster.

09

To configure a LIN cluster, you need to define:

  1. Slave Nodes
  2. Signals
  3. Schedule

The following steps are intended as a simple walkthrough to create a LDF from scratch

  1. Create a new LDF
  2. Create a Slave Node (there are always by default a Master Node, so the LDF always define one by default).
  3. Define an appropriate name 10
  4. Define a Diagnostic Frame 11
  5. Within this Diagnostic Frame; define the Signal Mapping by adding Map Signals. 12 Note: You can see the mapping of these signals from a more grapichal way, by clicking the colored rectangles 13
  6. Define a LIN Master Node request frame 14
  7. Check the Node and Signals Properties 15
  8. Define the several schedules 16
  9. Run the LIN Consistency Checker to solve warning and error inside the LIN cluster configuration.

LIN communication was published on and last modified on .