LINbus (Local Interconnect Network bus) nodes provide for distributed control of devices using a simple, low-speed (20 kilobits/second), 1-wire network between the nodes, controlled by a master. If you don’t feel like going through 200 pages or so of bus specifications (vaialble free of charge from the LIN consortium steering committee, then check out this brief summary (of version 1.3) provided by ???.
The network is slow, so it cannot be used for time-critical stuff requiring real-time response. But it’s good enough for watching switches and control knobs, running motors (that don’t require hard synchonisation with devices on other nodes), lights, etc.
The primary objective is to minimise cabling so the LIN nodes are used to encode the necessary signals between switches and the corresponding “actors” onto a single wire, with the node nearest to each handling the necessary coding and decoding. So each area of the vehicle needs to be looked at to determine what would be connected to each node.
Although one could try to keep the number of nodes to a minimum, that has to be balanced against the amount of cabling to the devices and the LINbus’ capacity to transfer the control data in sufficient time.
In a “modern” car, the LINbus is used as a sub-bus from a CAN (Controller Area Network) controller in a small area of the vehicle between e.g. a block of switches, solenoids and motors and the CAN controller. CANbus is a much more capable network, with higher speeds (up to 1 megabit per second), multiple masters, etc. but also more complex in terms of hardware and software, carrying substantial costs.
LINbus provides for reliable networking at low speed and low cost which appears to satisfy all the requirements for electrical control of the non-drivetrain parts of the vehicle. The main downside is that LINbus allows for only one bus master, but there are workarounds that e.g. allow a slave to “wake” the bus master and get it to ask why it got worken up.
Each Linbus node requires at least 3 wires; power from the vehicle battery, chassis ground and the data wire. It taps into those 3 wire as a tee, on a short branch. Everything else will be to deal with the local devices.
The required number of nodes is near the limit for a single LINbus cluster. To network will be divided into at least two clusters to minimise delays in response and the potential for collisions with node cluster as follows:
- LM DD DR RB HV PD PR TG
- LM FL TM FC FR DC SC IA
As some of the local devices are potentially heavy consumers of electrical current, and electrical faults aren’t unheard of so circuit protection must be provided at each node and preferably for each major current-drawing device.
Although each node will likely be controlling its outputs electronically and able to monitor the state of the load, fuse protection is cheap, even if access to the node for checking/replacing its fuse(s) may not be so simple. Certainly, access for maintenance will determine location and therefore cable lengths, even if the state of a fuse within a working node could be queried through the LINbus.