Whilst modern vehicle networks continue to increase in terms of communication speeds and arguably complexity, there remains an essential need for a reliable, low-speed, cost-effective network solution for which the LIN protocol (Local Interconnect Network) is perfect.
The LIN protocol provides the ideal media for connecting low-priority components (i.e. typically convenience items) over a single wire with communication speeds up to 20 kbit/s in a reliable and deterministic fashion. In addition, LIN allows vehicle manufacturers the flexibility to customise the communication exchange (in terms of IDs and returned values/parameters) using standardised, low-cost, reliable components with included diagnostic support
It is not unusual to find several LIN networks in a single vehicle, where each is configured using the Commander/Responder architecture (historically named Master/Slave). Each LIN network Commander ECU can be connected to a maximum of 15 Responder ECUs over a network length no greater than 40 meters. Note: A Commander ECU can include a Responder node (i.e. command a response from itself) whilst also acting as a Gateway for relaying converted LIN messages to other networks such as CAN (See figure 1.)
Before we describe the operation and functionality of LIN, a quick review of the historical events that have seen this protocol become widely adopted across the majority of vehicle manufacturers, whilst also finding its way into automated machinery and domestic appliances:
- 1999 LIN version 1.0 released by the LIN consortium (consisting of several vehicle manufacturers
- 2000 LIN updated to version 1.1, then 1.2
- 2002 LIN version 1.3 released (commenced adoption by select vehicle manufacturers)
- 2003 LIN version 2.0 released (includes major amendments)
- 2006 LIN 2.1 specification released
- 2010 LIN 2.2A was released and widely adopted by multiple vehicle manufacturers
- 2012 LIN Standardised as SAE J2602 (Based on LIN 2.0)
- 2016 LIN 2.2A Transcribed to the International Organization for Standardization (ISO) to be accepted as ISO 17897 and officially released
In terms of interoperability of the various LIN versions, backward compatibility is possible but not without its caveats! Whilst LIN 2.1 originates from LIN 1.3, it excels in terms of capabilities and so below, we summarise “compatibility”:
LIN versions 1.3 & 2.1
- A LIN 2.1 Commander ECU can accommodate networks consisting of both LIN 1.3 and/or LIN 2.1 Responders
- A LIN 2.1 Responder ECU cannot operate with a LIN 1.3 Commander ECU
LIN versions 2.0 & 2.1
- A LIN 2.1 Commander ECU can accommodate networks consisting of LIN 2.0 Responder ECUs if the LIN 2.1 Commander contains all functionality of a LIN 2.0 Commander ECU
- A LIN 2.1 Responder ECU can be used in a network with a LIN 2.0 Master ECU if the LIN 2.1 Responder is pre-configured, i.e. the LIN 2.1 Responder ECU is configured accordingly
As can be seen above, “interoperability” is possible (in the correct order) but may require reconfiguration to prevent erroneous operation and communication errors.
Note: Mismatched LIN versions may become apparent where pattern parts are used to replace LIN-controlled components, e.g. Alternators
Moving now to the physical construction and operation of a LIN network, we summarise below:
- LIN utilises a single wire connected to the Commander and all Responder ECUs
- Whilst there can be several LIN buses on a vehicle, each LIN bus has only 1 Commander ECU
- LIN communication is bidirectional, deterministic and controlled solely by the Commander ECU
- Typical LIN bus baud rates utilised for transmission include 9.6 and 19.2 kbit/s
- The LIN Bus is biased to battery voltage via a diode and a 1 kΩ pull-up resistor at the Commander ECU
- Each Responder ECU LIN Bus wire is connected to battery voltage via a 30 kΩ pull-up resistor
- The transceivers within the Commander & Responder ECUs are responsible for pulling the LIN bus voltage down from the biased 12 V to near 0 V during signalling (i.e. communication)
- The LIN bus has only 2 states to denote a logic 1 or 0
- Recessive high state (LIN bus at 12V denotes logic 1)
- Dominant low state (LIN bus close to 0 V denotes logic zero)
LIN Encoding
In addition to the typical voltage levels above, consideration must also be given to the time intervals within a train of voltage pulses. (i.e. a LIN packet) Using our Guided Test LIN bus example waveform (Figure 2, point A), using our time rulers to measure a single bit within a LIN packet, we find a frequency value of 19.2 kHz.
To now find the bit rate/period that is used to represent a logic zero or 1, we use the reciprocal of our frequency value, e.g. 1 / 19,200 = 0.00005209 s or 52.09 µs
Note: A time interval of 52.09 µs (1 bit rate/period) equates to a frequency value of 19.2 kHz
Based on the summary above, we will now take a look at how a LIN packet is formed and break down each section into its respective functions.
A LIN packet consists of 5 main fields, which can be further divided into the Header and Response segments: (See Figure 2.)
The Header (Figure 2, point 6) consists of:
- Break
- Sync
- Protected identifier inc. Frame ID
The Response (Figure 2, point 7) consists of:
- Data (Payload)
- Checksum
Header
Figure 2, point 1 (Break)
The Break is generated by the Commander ECU to signify the start of a new packet, where the bus voltage is typically at a dominant level (near 0 V) for a minimum of 13-bit periods. In Figure 2, point 1, our Break field is at a dominant level for 778 µs or 778 / 52.09 = 14.94-bit periods, followed by a recessive delimiter before the Sync field start bit
Note: The Break field is purposely held dominant for a prolonged period so as to clearly define the “start-of-packet” from all other fields
Figure 2, point 2 (Sync)
The Sync field (1-byte consisting of hex value 0x55) is generated by the Commander ECU and provides a means for the Responder ECUs to synchronise their timings precisely to that of the Commander before the transmission of the Protected identifier field.
Note: The Sync field consists of 10 bits (1 start bit, 8 bits for synchronisation purposes and 1 stop bit)
Figure 2. point 3 (Protected identifier inc. Frame ID)
The 8-bit Protected identifier contains the Frame ID (6 bits, 0 to 5) and the parity bits (2 bits, 6 & 7). Starting with the Frame ID, values 0 to 63 can be used to identify a maximum of 64 different frames, which are defined as follows:
- Values 0 to 59 (0x3B) are used for frames carrying signals
- Values 60 (0x3C) and 61 (0x3D) are used for frames to carry diagnostic / configuration data
- Values 62 (0x3E) and 63 (0x3F) are reserved for future improvements to the LIN protocol
Note: The Frame ID ranges can be used to denote the “Data” (Payload) length; however, this depends on the vehicle manufacturer. The “Data” length can be customised, whereby the Frame ID does not correlate to “Data” length!
The parity bits are calculated on the frame identifier bits as a means to validate the ID (i.e. error checking) whilst also providing instructions on how or if the Responder ECU needs to respond, i.e. there will be one of three outcomes:
- The Responder ECU receives only (listen)
- The Responder ECU is required to respond (publish)
- The Responder ECU can ignore the header/message being sent
Response
Figure 2. point 4 (Data)
A LIN packet can carry between 2 and 8 bytes of data allocated within a byte field. Each byte field also includes a single start bit (prior to each data byte) followed by a single stop bit, where bytes are labelled as “Data 1” for the first byte, through to “Data 8” for the final byte (within an 8-byte packet)
Where the transmitted data is longer than a single byte, the LIN protocol allows for data to be shared across multiple bytes, with the least significant bit (LSB) contained in the first transmitted byte and the most significant bit (MSB) sent in the final byte
Note: There will only be one Responder ECU transmitting data on the bus at any given time, which is based on the relevant ECU “responding” (within the allocated time frame) to the information contained in the header (instructed by the Protected identifier) sent from the Commander ECU
Figure 2, point 5 (Checksum)
The 8-bit Checksum forms an integral portion of the packet “Response” segment and serves as a means to validate the transmitted “Data” whilst verifying no errors have appeared during transmission. Depending on the LIN version undertest, the Checksum can be either “Classic” (LIN version 1.x calculated over the “Data” bytes alone) or “Enhanced” (LIN version 2.x calculated over the “Data” bytes and Protected identifier) The PicoScope decoder table will reveal the version of LIN undertest thanks to the presence of “tick” entries in the “Enhanced Checksum” column, so denoting LIN version 2.x in Figure 2. above
Note: Frame IDs 60-61 will always use the “Classic Checksum” regardless of the LIN version under test.
Figure 2, point 8 (Interbyte space) & point 9 (Response space)
Whilst not defined as one of the 5 main fields of a LIN packet, “Interbyte” spaces can be seen between every byte, before and after every start/stop bit. In addition, the interbyte space between the header and response (after the protected identifier & before the Data 1 field) is named the “Response” space. These spaces can be optionally included within a packet as a means to tolerate characteristic delays in communication from Responder ECUs, whilst the Response space provides sufficient time for Responders to react to the preceding “Header”
Note: Both the Interbyte and Response spaces are recessive (logic 1, 12 V) and equate to 1 bit time/period of 52 µs (with a baud rate of 19.2 kbit/s)
Packet Types
With an understanding of each field within a LIN packet, we can now describe the various “Packet Types”. During LIN communication, the majority of packet types are described as “Unconditional”; however, not all packets are the same, as some differ in terms of timing, data content and serve a specified purpose, see below:
Unconditional: ID 0-59 (Dec) 0x00-0x3B (Hex)
Unconditional packets serve as the default form of LIN bus communication, where the Commander ECU requests information from a specific Responder ECU during a scheduled, allocated packet slot. The response is always provided by the relevant Responder ECU so ensuring deterministic timing. Note: Whilst a specific Responder ECU is targeted by the Commander ECU, other ECUs receive the request and act accordingly (i.e. listen/ignore). Remember, a Commander ECU also contains a Responder and so may request data from itself
Event triggered: ID 0-59 (Dec) 0x00-0x3B (Hex)
Event triggered packets serve to minimise bandwidth utilisation whereby the Commander ECU broadcasts a request to multiple Responder ECUs who only respond if it has something to transmit i.e. a change of state of a door handle or window switch etc. (Neither of which will change state that often) A Responder ECU that wishes to transmit an “event” will place its Protected Identifier within the first data byte (Data 1) which becomes the source address, so helping the Commander identify which Responder ECU responded. There is, however, the possibility of collisions on the bus if multiple Responder ECUs have “events” to transmit at the same time! In such a scenario, the LIN Commander will switch to the “Unconditional” style of communication and request data from each Responder individually.
Note: The above event-driven data “collisions” are not considered as errors on the LIN bus, as (to a degree) they are expected and a resolution is in place
Sporadic: ID 0-59 (Dec) 0x00-0x3B (Hex)
Sporadic packets are used for updated non-time-critical data that doesn’t fit the regular timing of unconditional packets. Where the Commander ECU is aware of such data from any of the Responders ECUs on the network, it will respond to its own header (i.e. the Commander becomes the Responder). In this scenario, the Commander compiles the data bytes, informing the remaining Responders.
Note: Where multiple Responders have updated non-time-critical data, the Commander will share such data with the other Responder ECUs during subsequent sporadic packets in order of data priority
Diagnostic: ID 60-61 (Dec) 0x3C-0x3D (Hex)
Diagnostic packets always contain 8 bytes and are used for onboard diagnostics and fault detection of the LIN bus system. The Commander ECU will receive diagnostic requests from the tester and respond accordingly or relay the diagnostic request to the relevant Responder ECU, who responds back to the tester via the Commander ECU
Note: The Commander diagnostic request can be identified by the Frame ID 60 (0x3C) and
61 (0x3D) for the response from a Responder ECU
User defined: ID 62 (Dec) 0x3E (Hex)
User-defined packets allow for customisation of the LIN communication and provide manufacturers the freedom and flexibility to adapt the network to support their bespoke applications
Reserved: ID 63 (Dec) 0x3F (Hex)
Reserved packets (identified by Frame ID 63) are not utilised within LIN 2.0 as they are reserved for future improvements to the LIN protocol
Note: Not all ECUs on a LIN bus network have to support all the packet types mentioned above
LIN bus “Sleep & Wake” functionality
Whilst the LIN bus is considered low cost, it certainly does not lack in features that lend themselves perfectly to automotive applications. One such feature is the ability of the LIN bus to “Sleep & Wake” based on the following characteristics:
- The LIN Responder ECUs can be instructed to “sleep” by the Commander ECU
- Every Responder ECU will automatically sleep after 4 seconds of inactivity on the bus
- The Responder ECUs can be woken by the Commander or other Responder ECUs who send a “wake up” request as follows:
- Bus voltage is forced dominant (0 V) for 250-5000 µs, followed by a recessive pause (12 V) for 150-250 ms
- The above process may be repeated 3 times (maximum), whereby all ECUs should wake within 100 ms
- Should the above attempts fail to wake the Commander ECU, a pause of 1.5 seconds is required before sending further wake-up requests
- Once the Commander ECU is awake, LIN bus communication can commence
LIN bus voltage thresholds
We have described above how LIN bus voltages switch from 12 V to 0 V in order to convey logic states 1 and 0, respectively. However, in reality, there has to be an allowance for voltage drop and impedance variations across the entire bus.
To combat signal degradation, the following bullet points indicate the actual voltage thresholds utilised by the ECUs on the LIN bus
Receiving ECUs
- All ECUs will interpret a bus level voltage above 60% of battery voltage as logic 1 (Recessive)
- All ECUs will interpret a bus level voltage below 40% of battery voltage as logic 0 (Dominant)
Transmitting ECUs
- All ECUs will interpret a bus level voltage above 80% of battery voltage as logic 1 (Recessive)
- All ECUs will interpret a bus level voltage below 20% of battery voltage as logic 0 (Dominant)
The above “transmitting” thresholds ensure a more robust signalling structure to accommodate signal degradation and ensure all ECUs on the bus receive adequate instructions
Note: The LIN bus recessive voltage (12 V) may deviate from the actual vehicle supply voltage, given the differing circuit impedance characteristics and as a result, should not be considered as a fault
A further insight into LIN bus and decoding into human-readable data can be found here: