When many people talk about the in-vehicle network, their first reaction is often CAN, and they always feel that the really “important” communication is on the backbone bus; one step ahead is the hot words such as automotive Ethernet, domain controller, and central computing.
But if you look back from the whole car frame to the daily car action, you will find another network almost everywhere: lifting windows, door locks, rearview mirror folding, seat adjustment, wipers, air conditioning doors, there are often LIN figures behind them.
It’s not fast, it’s not flashy, and it doesn’t even stand out in many security discussions. But because it is cheap, stable and sufficient, LIN has long been rooted in the layer closest to the actuator of the body electronics.
To understand LIN is not only to understand a set of low-speed protocols, but also to understand why modern automobiles are always “multi-network coexistence” systems.
LIN is not designed for high performance, but to connect a large number of “low-speed but must be stable” body movements with the lowest complexity.
What exactly is LIN?
The full name of LIN is Local Interconnect Network. Its core design goal is not high bandwidth, but low cost to achieve distributed control. Unlike CAN, which has multiple nodes competing for the bus and emphasizes real-time arbitration, LIN uses a single-master and multi-slave architecture: one master node is responsible for scheduling, and multiple slave nodes respond according to the established rhythm.
From the point of view of protocol mechanism, LIN is “restrained”. A frame of message is usually composed of the Header sent by the master node and the Response given by the named node. Header includes Break, Sync and PID; Response carries data and verification. In other words, who speaks when and what kind of words are often written into the schedule in advance.
Its physical layer is also simple: single line, low speed, and simple nodes. Because of this, LIN is particularly suitable for attaching a large number of sensors and actuators with clear functional boundaries and low bandwidth requirements.
Why is LIN still widely used by automobile manufacturers to this day?
The answer is not complicated: because it fits perfectly in its place. For a vehicle, not all control actions are worth the cost of assigning CAN levels, and not all nodes require high-power MCUs, two-wire differential physical layers, and more complex network management mechanisms. Many body electronic modules essentially only need to report status periodically or perform a definite action steadily, and LIN just meets this requirement.
More importantly, the system engineering cost of LIN is also low. Node hardware can be simpler, wiring less, and power management more straightforward. In the scenario of comfort and body accessories, this ability of “enough, long-term stability” is far more valuable than blindly pursuing higher indicators.
Therefore, the reason why LIN has not been eliminated is not because the industry is conservative, but because the automotive architecture pays attention to stratification and matching. High-performance networks should be used in places with high performance, and low-cost networks should be used in places with low cost.
What is the relationship between LIN and CAN?
Many beginners tend to understand the relationship between the two as “who is advanced and who is backward”, which is not accurate. It is more appropriate to say that CAN and LIN are often not substitutes, but divisions of labor.
CAN is more like an important channel inside the vehicle, undertaking the backbone communication across ECUs; LIN is more like an end subnet hanging in a local area, spreading down low-speed, low-cost control tasks.
Therefore, in a real car, we can often see such a structure: the upper controller or gateway manages the whole vehicle logic through CAN, and the lower LIN clusters are responsible for local functions such as door control, seat, lighting, air conditioning door or wiper. From an architectural perspective, LIN is not a “shrunken version of CAN”, but a tailor-made solution for another kind of problem.
Why can’t we ignore LIN when we do car networking security today?
On the surface, many security incidents occur in the cloud, App, Bluetooth, diagnostic interface, or in the infotainment system and gateway layer. But once the attack really wants to fall on the physical action in the car, it often has to continue to push forward to the executive level. That is to say, LIN may not be the “first jump” of attack, but it may be the “last jump” that affects the actions of door locks, windows, seats, rearview mirrors or wipers.
The problem is that LIN was not designed for today’s networked threat model because of its design age and objective function. It emphasizes low cost, predictability, and ease of implementation, rather than providing strong authentication, encryption, and access control in the modern sense at the bus level. As a result, once the upper portal or controller is compromised, researchers will naturally be concerned about whether the lower LIN subnet will be further abused?
This is why academia and industry have begun to shift their attention from “whether a single protocol is secure” to “whether the whole attack path can be closed”. For LIN, what is really alarming is not that it is exposed to the public network alone, but that it is in the layer closest to physical action in the layered architecture of the whole vehicle.
How does the industry now “supplement the security boundary” for LIN?
First, the security perimeter is increasingly moving forward to gateways, domain controllers, and diagnostic links, rather than expecting the LIN itself to suddenly become a “native security bus.”. Who can send commands to the body domain, which diagnostic services can be invoked, and which flash or configuration operations require stronger authentication are often more critical than discussing a low-speed bus alone.
Second, verification around schedules, LDF configuration, and consistency of node behavior is becoming more important. Because the communication of LIN naturally has strong predictability, abnormal polling, abnormal response and abnormal timing can become important signals for safety detection.
Thirdly, vehicle safety research increasingly emphasizes layered defense: remote entrance tightening, inter-domain quarantine, diagnostic authority control, software update security, gateway anomaly detection, and minimum authority of key controllers. In the final analysis, the safety of LIN still depends on the whole vehicle system engineering.
Don’t underestimate this “slow line”
If CAN is the most familiar in-car backbone network, then LIN is more like the long-neglected but extremely practical “grass-roots network” in the automotive world.
It does not undertake all the key tasks of the vehicle, but is deeply involved in a large number of daily interactions. It does not represent the whole direction of the future, but it is still an important answer in the balance of cost and complexity of body electronics today.
So the best way to understand LIN is not to think of it as an outdated technology, but to put it back into the real car architecture: why there are layers, why there are gateways, why security is never a matter of a bus itself. Only by understanding this point can we truly understand today’s smart car network.
