Automative networking: An introduction to LIN

The introduction of advanced control system demands on the communication used within cars is creating new challenges for the automotive industry. These new requirements can only be met via networks. As the environment in vehicles is quite specific, three main communication standards have been introduced to the automotive industry:



• FlexRay is highest speed (up to 10Mbps per channel). It includes two channels and is time triggered, robust and fault tolerant for use as a backbone. The typical target application is the X-by-wire car concept.







• CAN (controller area network) is characterized by mid-range speed (up to 1Mbps). Single channel, dual wire and fault tolerant, the protocol is currently in wide use not only in cars but also in many industrial applications.



• LIN (local interconnect network). This low-speed (up to 20Kbps), single-wire and lowcost protocol can be used mainly for end-node applications.





Local interconnect network

Intended for use mainly in the distributed electronic systems of vehicles and in the network-based car concept, the LIN is based on the common UART/SCI interface and guarantees deterministic data transmission with a baud rate of up to 20Kbps. Typical applications for the LIN bus are in assembly units such as doors, the steering wheel and many others.



Self-synchronization without the need for crystal or ceramic resonators in the slave nodes is another notable feature of the LIN protocol. This, together with the simplicity of SCI-based communication, is the major factor in the cost efficiency of any LIN implementation.



Operation basis

The LIN operational concept is based on a single master/multiple slave topology. Within this term, a LIN cluster consists of one master node and several (up to 15) slave nodes.



Figure 1 shows how the LIN node can be virtually split into two separate parts: the “master task,” responsible for deciding which frame will be transferred and when, and the “slave task,” which provides the data to be transferred on the LIN bus.

Frame composition

The data units transferred via the LIN bus are called frames. Each frame consists of a header, provided by the master task; and the response handled by the slave task. The header includes a break characterized by at least a 13bit long period of dominant state of the LIN bus generated by the master task; a synchronization field defined as a bit field with a data value 0?55 enabling the slave task to synchronize to the master clock; and the protected identifier (PID), which uniquely defines the message content but not the address of the recipient.



The response part of the LIN frame is provided by the slave task. It can be divided into the data field carrying between one and eight bytes of data, and the checksum field containing the inverted 8bit sum with carry-over data bytes. The structure of a LIN frame can be seen in Figure 2.



The transmission of the headers by the master task is based on the schedule table of a cluster. The schedule table concept is a mechanism that ensures that the network is never overloaded. It also guarantees deterministic data transmission.



LIN 2.0 specification package

The LIN specification in version 2.0 reflects the trends identified by the LIN Consortium and consists of the following parts:



• The LIN physical layer specification describes the physical layer, including bit rate and clock tolerances.



• The LIN protocol specification describes the data link layer of LIN.



• The LIN API specification describes the interface between the network and the application program, including the configuration and diagnostic layers.



• The LIN configuration language specification describes the syntax and semantics of the LIN description file (*.ldf).



• The LIN diagnostic and configuration specification describes the service that can be layered on top of the data link layer to provide information for diagnostic messaging and node configuration.



• The LIN node capability language specification defines the format (*.ncf) used to describe off-the-shelf slave nodes that can be used with a plug-andplay tool to automatically create LIN description files.



By comparing the LIN 1.3 and LIN 2.0 specification packages, the two most important changes are a standardized support for configuration and diagnostics, and specified node capability files, both targeted at simplifying the use of off-the-shelf nodes.



SAE J2602 LIN task force

The goal of SAE J2602 is to improve the interoperability of LIN devices within a network by resolving those LIN 2.0 requirements that are ambiguous, conflicting, or optional. Generally, SAE J2602 was designed with the long-term vision of ASIC slave implementations, while LIN 2.0 assumes the use of an MCU-based implementation. There are differences between the main J2602 and the LIN 2.0 specs. For instance, baud rate is fixed at 10.417Kbps (leading to better EMC). Slave-toslave communication is not recommended, and event-based messaging is not allowed. In addition, all configuration and diagnostic services are optional, except for sleep and targeted reset.



SAE J2602 also provides additional requirements not present in LIN 2.0 (such as fault tolerant operation, network topology, builtin standardized error reporting behavior and others).

About the author Zdenek Kaspar is group leader and system application engineer; Jiri Kuhn is system application engineer in the transportation ad standard products group, Freescale Semiconductor, 6501 William Cannon Dr., West, Austin, TX 78735; (512) 895-2000;www.freescale.com.