Table of Contents

• Table of Contents
• Overview of LIN
• LIN Frame Format
• LIN Bus Timing
• LIN Topology and Behavior
• LIN Error Detection and Confinement
• LIN Sleep and Wakeup
• Advanced Frame Types
• Recommended PC LIN Interfaces
• Additional LIN Information
Overview of LIN
• The Local Interconnect Network (LIN) bus was developed to create a
standard for low-cost, low-end multiplexed communication in
automotive networks.
• LIN provides cost-efficient communication in applications where the
bandwidth and versatility of CAN are not required.
• LIN vs. CAN
CAN is more expensive to implement than LIN. Factors that contribute to
the higher cost of CAN include:
Each node in a CAN network requires a clock generator or crystal
• At a silicon level, CAN is more complex to implement
• 2-wire transmission is used.
Feature and benefit of lin bus
• The key features and benefits of LIN are as follows:

• Complementary role – As already stated, the role of LIN is not to

replace CAN but to complement it. This feature helps CAN to extend
to remote hierarchical sub-networks within applications.
• Single-wire implementation – LIN’s low-cost, single-wire
implementation (contrary to CAN’s twisted pair implantation) reduces
cost considerably.
Benefits of lin bus
• Data rate – Data rates are limited to 20Kbps (for EMI control reasons).
This helps maintain the reliability of the network.
• Broadcast serial network - The LIN network can have one master and
up to 16 slave nodes. All messages originate at the master, and at
most one slave responds, based on the message identifier.
• Self-synchronization - No crystal or resonator is required, thus
lowering implementation cost significantly.
• Latency time - LIN networks provide guaranteed latency times,
making it a more predictable network
Benefit and feature of lin bus
• Overall implementation- LIN is less expensive and simpler to
implement than CAN. In the case of CAN, each node requires a CAN
interface, crystal, and 2-wire connection. LIN can work with a simple
serial communication block (SCB).
• The LIN bus uses a master/slave approach that comprises a LIN
master and one or more LIN slaves.
LIN FRAME FORMAT
• The LIN bus is a polled bus with a single master device and one or more
slave devices. The master device contains both a master task and a slave
task.
• Each slave device contains only a slave task. Communication over the LIN
bus is controlled entirely by the master task in the master device. The
basic unit of transfer on the LIN bus is the frame, which is divided into a
header and a response.
• The header is always transmitted by the master node and consists of three
distinct fields: the break, synchronization (sync), and identifier (ID). The
response, which is transmitted by a slave task and can reside in either the
master node or a slave node, consists of a data payload and a checksum.
• Normally, the master task polls each slave task in a loop by
transmitting a header, which consists of a break-sync-ID sequence.
• Upon receiving the header, each slave task verifies ID parity and then
checks the ID to determine whether it needs to publish or subscribe.
If the slave task needs to publish a response, it transmits one to eight
data bytes to the bus followed by a checksum byte. If the slave task
needs to subscribe, it reads the data payload and checksum byte from
the bus and takes appropriate internal action.
1.BREAK
• Every LIN frame begins with the break, which comprises 13 dominant
bits (nominal) followed by a break delimiter of one bit (nominal)
recessive. This serves as a start-of-frame notice to all nodes on the
bus.
SYNC
• The sync field is the second field transmitted by the master task in the
header. Sync is defined as the character x55. The sync field allows
slave devices that perform automatic baud rate detection to measure
the period of the baud rate and adjust their internal baud rates to
synchronize with the bus.
Identifier
• The ID field is the final field transmitted by the master task in the header. This
field provides identification for each message on the network and ultimately
determines which nodes in the network receive or respond to each
transmission.
• All slave tasks continually listen for ID fields, verify their parities, and
determine if they are publishers or subscribers for this particular identifier.
• The LIN bus provides a total of 64 IDs. IDs 0 to 59 are used for signal-carrying
(data) frames, 60 and 61 are used to carry diagnostic data, 62 is reserved for
user-defined extensions, and 63 is reserved for future protocol enhancements.
• The ID is transmitted over the bus as one protected ID byte, with the lower six
bits containing the raw ID and the upper two bits containing the parity.
DATA BYTES
• The data bytes field is transmitted by the slave task in the response.
This field contains from one to eight bytes of payload data bytes
Checksum
• The checksum field is transmitted by the slave task in the response. The LIN bus
defines the use of one of two checksum algorithms to calculate the value in the
eight-bit checksum field. Classic checksum is calculated by summing the data bytes
alone, and enhanced checksum is calculated by summing the data bytes and the
protected ID.
• The LIN 2.0 specification defines the checksum calculation process as the summing of
all values and subtraction of 255 every time the sum is greater than or equal to 256
(unlike modulo-255 or modulo-256). Per the LIN 2.0 specification, classic checksum is
for use with LIN 1.3 slave nodes and enhanced checksum is for use with LIN 2.0 slave
nodes. It further specifies that IDs 60 through 63 shall always use classic checksum.
The NI LIN interface provides an attribute to set the checksum type to classic or
enhanced. The default setting is classic. Per the LIN 2.0 specification, IDs 60 through
63 always use classic checksum, regardless of the setting of the checksum attribute.
LIN BUS TIMING
• Because the LIN bus is a polled bus, the processing of each frame is
allocated a nominal time slot as follows:
• THeader_Nominal = 34 * TBit
TResponse_Nominal = 10 * (NData + 1) * TBit
TFrame_Nominal = THeader_Nominal + TResponse_Nominal
Processing of each frame is allocated a maximum time slot as follows:
THeader_Maximum = 14 * THeader_Nominal
TResponse_Maximum = 1.4 * TResponse_Nominal
TFrame_Maximum = THeader_Maximum + TResponse_Maximum
LIN ERROR DETECTION AND
CONFINEMENT
• The LIN 2.0 specification states that error detection should be handled by the slave tasks and that
error monitoring by the master task is not required. The LIN 2.0 specification does not require the
handling of multiple errors within one LIN frame or the use of error counters. Upon encountering the
first error in a frame, the slave task aborts the processing of the frame until the detection of the next
break-sync sequence (in the next header transmitted by the master).
• LIN also provides for error reporting to the network.
• The LIN 2.0 specification defines a Response_Error status bit, which the slave is required to report to
the master in one of its transmitted frames.
• This bit is set whenever a frame received or transmitted by a slave node contains an error in the
response field. The bit is cleared after it is transmitted in one of the slave's published responses. The
NI-CAN Frame API for LIN does not natively support the Response Error status bit but provides the
end user with a means to easily implement this functionality at the application level. The procedure
sets the log bus errors attribute equal to 1 to enable the logging of bus error frames in the read
queue. The application can then monitor for a read of a bus error frame with the error code
indicating an error in the response.
LIN SLEEP AND WAKEUP
• LIN features a mechanism that allows devices to enter the sleep state and potentially conserve power. Per the LIN 2.0
specification, all slaves may be forced into sleep mode by the master sending a diagnostic master request frame (ID=60)
with the first data byte equal to zero.
• This special frame is called the go-to-sleep command. Slaves also automatically enter sleep mode if the LIN is inactive
for more than four seconds. The NI-CAN Frame API for LIN provides great flexibility by allowing the user to put the LIN
interface to sleep as desired at the application level. Upon receiving a full frame containing a sleep request message, or
a bus inactive frame indicating four seconds of bus inactivity, the user may choose to put the LIN interface to sleep by
setting the LIN Sleep attribute to TRUE.
• LIN also offers a mechanism for waking devices on the bus. Wakeup is one task that may be initiated by any node on the
bus (a slave as well as the master). Per the LIN 2.0 specification, the wakeup request is issued by forcing the bus to be
dominant for 250 µs to 5 ms. Each slave should detect the wakeup request and be ready to process headers within 100
ms.
• The master should also detect the wakeup request and start sending headers when the slave nodes are ready (within
100 ms to 150 ms after receiving the wakeup request).
• If the master does not issue headers within 150 ms after receiving the first wakeup request, then the slave requesting
wakeup may try issuing a second wakeup request (and waiting for another 150 ms).
• If the master still does not respond, the slave may issue the wakeup request and wait 150 ms a third time. If there is still
no response, the slave must wait for 1.5 seconds before issuing a fourth wakeup request.
TYPES OF frame
• Unconditional frame. These always carry signals and their identifiers
are in the range 0 to 59 (0x00 to 0x3b). All subscribers of the
unconditional frame shall receive the frame and make it available to
the application (assuming no errors were detected).
TYPE OF frame
• Event-triggered frame. The purpose of this is to increase the
responsiveness of the LIN cluster without assigning too much of the bus
bandwidth to the polling of multiple slave nodes with seldom occurring
events. The first data byte of the carried unconditional frame shall be
equal to a protected identifier assigned to an event-triggered frame. A
slave shall reply with an associated unconditional frame only if its data
value has changed. If none of the slave tasks responds to the header the
rest of the frame slot is silent and the header is ignored. If more than
one slave task responds to the header in the same frame slot a collision
will occur, and the master has to resolve the collision by requesting all
associated unconditional frames before requesting the event-triggered
frame again.
Types of frames
• Sporadic frame. This frame is transmitted by the master as required, so a
collision cannot occur. The header of a sporadic frame shall only be sent in
its associated frame slot when the master task knows that a signal carried
in the frame has been updated. The publisher of the sporadic frame shall
always provide the response to the header.
• Diagnostic frame. These always carry diagnostic or configuration data and
they always contain eight data bytes. The identifier is either 60 (0x3C),
called master request frame, or 61(0x3D), called slave response frame.
Before generating the header of a diagnostic frame, the master task asks its
diagnostic module if it shall be sent or if the bus shall be silent. The slave
tasks publish and subscribe to the response according to their diagnostic
module.
Types of frames
• User-defined frame. These can carry any kind of information. Their
identifier is 62 (0x3E). The header of a user-defined frame is always
transmitted when a frame slot allocated to the frame is processed
• Reserved frame. These shall not be used in a LIN 2.0 cluster. Their
identifier is 63 (0x3F).
APPLICATION
Application segments Specific LIN application examples
Roof Sensor, light sensor, light control, sun roof
Cruise control, wiper, turning light, climate control,
Steering wheel
radio, wheel lock
Seat Seat position motors, occupant sensors, control panel
Engine Sensors, small motors, cooling fan motors
Grille Grille shutter
Climate Small motors, control panel
Mirror, central ECU, mirror switch, window lift, seat
Door
control switch, door lock
Vehicle trim enhancement, sill plates illuminated with
Illumination
RGB LED
LIN ADVANTAGES
• Easy to use
• Components available
• Cheaper than CAN and other communications buses
• Harness reduction
• More reliable vehicles
• Extension easy to implement.
• No protocol license fee required
• LIN is not a full replacement of the CAN bus. But the LIN bus is a good alternative
wherever low costs are essential and speed/bandwidth is not important.
Typically, it is used within sub-systems that are not critical to vehicle performance
or safety - some examples are given below
THE DISADVANTAGE
• Some of the main drawbacks of LIN are lower bandwidth and less
effective bus access scheme with the master- slave configuration.
Comparison of lin and can bus