WARNING! The discussions on this page deviate from standard LINbus protocols and use. Please visit the LIN Administration web site for official protocol documentation.
In LINbus nomenclature, a cluster is a group of slave nodes and a master node sharing the same LINbus.
The master LINbus node will retain a list of which slave “owns” a particular device’s state and which slaves are “interested” in that state. Slaves register their interest at the master when queried. This can occur at the initial power-up of the master; and optionally by the master at a later stage; when e.g. advised of a change in slave nodes.
Registration may invoke notification not just on a logic on-off change, but may nominate a set of bounds on a continuous value determined from a device, which a device’s owner will monitor and register a change of state when the bounds are exceeded.
Slaves therefore do not need to know which other slaves have a value, or be in the same cluster. The devices could be in a different cluster; or in a different cluster on the far side of several gateways. Only the master node needs to know.
The master also needs to know about unresolvable registrations. i.e. when a slave registers an interest in a device that is unknown by any other slave, or when the registration sets bounds on values that are out of range for the device.
Using the slave node capabilities and the registered interests, the master node builds a schedule for communications frames on the LINbus. Latency is minimised by only interesting data being presented on the bus. When a diagnostic node is attached temporarily, this may significantly influence latency if the diagnostic information sought is not already considered to be interesting.
A LINbus cluster may have up to 16 nodes, addressed by 4 bits. The number of nodes may be restricted by ensuring guaranteed response time (maximum latency) between an event occuring and the necessary response being initiated. This is a real-time requirement for many control functions. It may be in the order of tenths of a second, but there are still hard constraints on when things should have happened.
Slave nodes are polled frequently for a state change and if there is a change, then the details of the change are retrieved. Other slave nodes which have registered an interest in that state will then be sent an update.
There is a multicast facility inherent in the bus design but the standard message format is too narrow to deal with general state changes. Similarly, slave nodes may snoop on the bus, but delivery is not guaranteed.