LES LIAISONS "SERIE"
LE BUS LIN

 

Hugues ANGELIS

page  1

Le bus LIN

Le bus LIN (Local Interconnect Network) est un protocole réseau utilisé dans l’industrie automobile en complément du bus CAN, il sert essentiellement à communiquer avec des capteurs ou des micro-actionneurs lents (par exemple les vitres électriques, le toit ouvrant, ou la mesure de l’intensité lumineuse ambiante pour l’allumage automatique des phares). LIN est le prolongement du bus CAN, mais il est plus simple à utiliser et moins coûteux en ressources.

Le bus LIN utilise une liaison série pour établir une communication en half-duplex entre un maître et un maximum de 15 périphériques qui agissent comme des esclaves, le maitre étant lui-même considéré comme un esclave une fois ses tâches de maître accomplies, on a donc potentiellement jusqu’à 16 nœuds sur un bus LIN.

LIN est déterministe (on sait qui parle et quand) car il utilise un agenda  pour séquencer les tâches à accomplir. Les communications se font à des débits réglables entre 1 et 20 Kbit/s. Généralement on utilise un débit de 10,4 Kbit/s (héritage du bus SAE J1850, ancêtre du bus LIN). La ligne LIN utilise un modèle à drain ouvert pour ses communications, c'est-à-dire qu’au lieu d’utiliser un ‘1’ ou un ‘0’ pour coder l’état du signal, on a des états dominants (‘0’) ou récessifs (‘1’). L’état récessif pouvant être écrasé par l’état dominant s’ils sont émis simultanément.

Les esclaves ne pouvant pas prendre la parole de leur propre initiative, le maître du bus doit prendre des nouvelles de ses esclaves en les interrogeant régulièrement (polling). Toutefois la solution de les interroger tous les uns après les autres présente l’inconvénient de remplir le bus de trames inutiles (si l’esclave n’a rien à dire). Pour éviter de remplir le bus de trames inconditionnelles n’entrainant pas forcément de réponse, le maître envoie des trames événementielles auxquelles certains esclaves peuvent répondre en même temps. Le fait que plusieurs esclaves puissent parler en même temps risque d’entrainer des collisions.

Le maître du bus doit détecter la collision dans la réponse à une trame évènementielle (par détection d’une trame malformée ou présentant une erreur de checksum) et résoudre le problème en interrogeant un à un tous les nœuds, qui pouvaient être impliqué dans la collision, en envoyant des trame inconditionnelles aux nœuds identifiés comme pouvant être en collision.

Il existe donc 2 familles de trames, les trames inconditionnelles qui n’impliquent la réponse que d’un seul nœud, et les trames évènementielles qui sont susceptibles de déclencher des collisions. Pour chaque trame événementielle qui sera émise, l’agenda doit prévoir un temps permettant le traitement des collisions, avant l’envoi d’une quelconque autre trame.

Plus la trame évènementielle touche un grand nombre de nœuds, plus le risque de collision est grand et plus le temps de résolution de la collision sera long. Chaque nœud peut donc, à l’instar du bus CAN, être sensible à plusieurs identifiants, soit pour émettre soit pour recevoir (la réception n’ayant pas d’influence sur le fonctionnement du bus).

Les identifiants de diagnostic sont, au minimum, les seuls identifiants actifs pour tous les nœuds.