Hello Readers,
My name is Aravind B N, and I work at Luxoft India as a Junar Software Developer. Luxoft has given me several opportunity to work on vurious projects, which has inspired me to discuss the important processes involved in developing a LIN (Local Interconnect Network) protocol.
Introduction
LIN (Local Interconnect Network) is a concept that aims to create networks adding to the range of existing multiplex networks, in the automotive industry. LIN plays a role in establishing a vehicle network leading to improved quality and cost reduction for vehicles. Standardizing this technology will streamline the end multiplex solutions currently available resulting in reduced development, production, service and logistics costs, within vehicle electronics.
Features of LIN protocol
The LIN is a serial communications protocol that efficiently supports the control of mechatronics nodes in distributed automotive applications.
The LIN bus's primary characteristics are as follows:
single master with multiple slaves concept
Low-cost silicon implementation based on common UART/SCI interface hardware, software equivalent, or pure state machine.
Self-synchronization in slave nodes without a quartz or ceramics resonator
Deterministic signal transmission with computed signal propagation time
low cost single-wire implementation
speed up to 20 kbit/s.
signal based application interaction
The purpose of this specification is to achieve compatibility with any two LIN implementations in terms of the standard's scope, that is, from the application interface, API, all the way down to the physical layer.
LIN provides a cost efficient bus communication where the bandwidth and versatility of CAN are not required. The line driver/receiver specification is based on the ISO 9141 standard, with some EMI enhancements.
Workflow
The LIN transceiver and its implementation are the focus of this application note; however, comprehending the transceiver's place in an application requires a high-level comprehension of the overall LIN network. As LIN was defined, it was specified not only for the actual 1's and 0's data transmission, but also for a higher-level network implementation: the LIN workflow. For those working with the protocol, the LIN workflow provides an easy-to-use, dependable implementation strategy (as seen in the image below). The LIN Description File (LDF) is used to specify and standardise the configuration of the entire network cluster.
The LDF is what distinguishes LIN clusters by identifying the specific usage and attributes for that cluster (node count, quantity and description of message frames, message rate, and so on). This allows developers to create software files that specify the tasks each node in the cluster does. The LDF may be used to automatically develop communication software as well as feed information to measurement and test tools used in LIN cluster analysis.
Fig: - LIN Workflow
The LDF is written in the syntax described by the LIN Configuration Language Specification. This syntax is used in conjunction with the System Defining Tool to generate the LDF and hence define the whole network. Along with these tools, there is the LIN Node Capability Language. This enables the developer to specify and describe the implementation of Off-the-Shelf Nodes, which are readily implementable, general-purpose LIN nodes built for common applications and available in large quantities.
LIN Protocol
The seven-layer Open System Interconnection (OSI) Model, as shown here, can be used to describe many network protocols:
Fig: - Open System Interconnection Model
According to the OSI-model, LIN is a comprehensive concept that covers the Physical, Data Link, Network, and Application layers.
LIN Physical Layer
The Physical Layer has to do with getting the bits on the wire in the OSI model. The Local Interconnect Network (LIN) physical layer depends on ISO 9141 (the K-line bus). It's made up of the two-way bus line LIN that connects to the transceiver of every bus node, and connects through a termination resistor and diode to the positive battery node, VBAT.
Transceiver
The transceiver is the thing that lets the bus and network talk to each other. It takes the 1s and 0s from the microcontroller and bumps them up to higher voltages so they can travel down the bus, and it does the opposite going the other way. The TXD (transmit) and RXD (receive) parts of the transceiver make it possible to send and get messages through that voltage changing as the signals pass through and the TXD hooks to the microcontroller, where the message comes from before the transceiver puts it out on the LIN bus. The RXD keeps an eye on the bus and turns the messages there into voltages the microcontroller understands, so it can react to what's happening on the bus.
Standard voltage levels for the TXD and RXD are like most microcontroller levels: 3. 3 V and 5 V. The LIN bus and LIN transceivers usually work at voltages ranging from 9 V to 18 V, although some can go up to 30 V (depending on the application) and an average vehicle is a 12-V battery system however some larger vehicles go up to 24 V.
Fig: - A "Master" LIN ECU Node
Diodes Dser_intand Dser_master are mandatory to prevent uncontrolled powering of the ECU node from the bus line, in the case of a battery loss.
This is first part of the LIN Protocol next article based on Data link layer & Application layer of LIN protocol along with example.
Do let me know if you have any queries in the comments below.
Thanks for reading.
Top comments (0)