Introduction au bus LIN (Local Interconnect Network)

Date de publication: mars 08, 2010

Introduction
Le protocole LIN (Local Interconnect Network) est un protocole réseau embarqué économique destiné à connecter ensemble des matériels intelligents. Il est très répandu dans l'industrie
automobile.

Table des matières

1. Présentation du LIN
2. Format des trames LIN
3. Cadencement du bus LIN
4. Topologie et comportement d'un réseau LIN
5. Détection d'erreurs et isolation du LIN
6. Mise en veille et réveil du LIN
7. Types de trames avancés
8. Interfaces PC LIN recommandées
9. Informations supplémentaires sur le LIN

1. Présentation du LIN
Le bus LIN (Local Interconnect Network) a été développé dans le but de créer une norme de communication multiplexée faible coût, d'entrée de gamme sur les réseaux automobiles. Bien que le
CAN cible le besoin de réseaux avancés large bande gérant les erreurs, les coûts du matériel et des logiciels d'une implémentation CAN sont prohibitifs pour des matériels aux performances plus
faibles comme les vitres à commande électrique ou les contrôleurs de sièges. Le LIN permet une communication économique dans les applications où la bande passante et la polyvalence du
CAN ne sont pas requises. Vous pouvez mettre en œuvre un réseau LIN de façon peu coûteuse en utilisant l'émetteur/récepteur asynchrone universel (UART) série standard intégré dans la
plupart des microcontrôleurs 8 bits économiques modernes.
Les réseaux automobiles modernes utilisent une association de LIN pour les applications faible coût principalement dans l'électronique du châssis, du CAN pour les communications avec la
transmission et le châssis en grande série, ainsi que le bus émergeant FlexRay pour les communications de données synchronisées haute vitesse dans les systèmes avancés tels que la
suspension active.
Le bus LIN utilise une approche maître/esclave qui comprend un maître LIN et un ou plusieurs esclaves LIN.

Figure n°1. Trame de message LIN

L'en-tête du message est constitué d'un break utilisé pour identifier le début de la trame et d'un champ sync utilisé par le nœud esclave pour la synchronisation d'horloge. L'identifiant (ID) est
constitué d'un ID de message sur 6 bits et en un champ de parité sur 2 bits. L'ID indique une adresse de message spécifique mais pas la destination. À la réception et à l'interprétation de l'ID, un
esclave débute un message de réponse, qui consiste en 1 à 8 bits de données et en une somme de contrôle sur 8 bits.
Le maître contrôle le séquençage des trames de message, qui est fixé dans un plan d'exécution. Vous pouvez modifier le plan d'exécution si nécessaire.
Il existe plusieurs versions de la norme LIN. La version 1.3 a finalisé la communication octet/couche. Les versions 2.0 et 2.1 ont ajouté des spécifications de messagerie et des services, mais elles
restent compatibles au niveau octet avec la version 1.3.

Fonctionnalité Supportée par NI LIN USB

LIN 1.3 Oui

LIN 2.0 Oui1

Somme de contrôle améliorée Oui

Concept de nœud esclave standard Oui1

Format NCF Oui1

Diagnostics et configuration du nœud esclave Oui1

Tableaux d'octets Oui

LIN 2.1 Oui1

Nouveaux services de configuration de nœuds esclaves Oui1

Diagnostics de l'esclave de classe I à III Oui1

Adressage fonctionnel Oui1

Table de résolution Oui1

1
Cette fonctionnalité n'est pas supportée nativement par l'API ; cependant, elle peut être implémentée.
Tableau n°1. Comparaison des versions LIN 1.3, 2.0 et 2.1

1/4 www.ni.com
2. Format des trames LIN
Le bus LIN est un bus interrogé avec un seul et unique maître et un ou plusieurs périphériques esclaves. Le maître effectue à la fois une tâche maître et une tâche esclave. Chaque esclave
n'effectue qu'une tâche esclave. La communication avec le bus LIN est entièrement contrôlée par le maître. L'unité de base de transfert sur le bus LIN est la trame, qui est divisée en en-tête et en
réponse. L'en-tête est toujours transmis par le nœud maître et consiste en trois champs distincts : le break, la synchronisation (sync) et l'identifiant (ID). La réponse, qui est transmise par une
tâche esclave et peut résider soit dans le nœud maître soit dans le nœud esclave, consiste en une charge de données et en une somme de contrôle.
Normalement, la tâche maître scrute chaque tâche esclave successivement dans une boucle en transmettant un en-tête, qui consiste en une séquence break-sync-ID. Avant de commencer une
communication LIN, chaque tâche esclave est configurée soit pour publier les données sur le bus soit pour souscrire aux données en réponse à chaque ID d'en-tête reçu. Lorsque la tâche esclave
doit publier une réponse, elle transmet de 1 à 8 octets de données au bus, suivis par un octet de somme de contrôle. Lorsque la tâche esclave doit souscrire, elle lit la charge de données et l'octet
de contrôle provenant du bus et effectue l'action interne appropriée.
Pour une communication standard esclave-vers-maître, le maître diffuse l'identifiant sur le réseau, et un seul esclave répond avec une charge de données.

La communication maître-vers-esclave est réalisée par une tâche esclave séparée dans le nœud maître. Cette tâche reçoit elle-même l'ensemble des données publiées sur le bus et répond
comme s'il était un nœud esclave indépendant. Pour transmettre des bits de données, le maître doit préalablement mettre à jour sa réponse de tâche esclave interne avec les valeurs de données
qu'il souhaite transmettre. Le maître publie ensuite l'en-tête de trame approprié et la tâche esclave interne transmet sa charge de données au bus.

Figure n°2. Trame de message LIN

1. Break
Chaque trame LIN débute par un break, qui comprend 13 bits (nominaux) de poids fort suivis par un délimiteur break sur un bit (nominal) de poids faible. Il sert de message de début de trame
pour tous les nœuds du bus.
2. Sync
Le champ sync est le deuxième champ transmis par la tâche maître dans l'en-tête. Sync est défini comme étant le caractère x55. Le champ sync permet aux matériels esclaves d'effectuer une
détection automatique de la vitesse de transfert pour ajuster leurs vitesses afin de se synchroniser avec le bus.
3. ID
Le champ ID est le dernier champ transmis par la tâche maître dans l'en-tête. Ce champ fournit l'identification pour chaque message sur le réseau et détermine en dernier ressort quels nœuds du
réseau reçoivent ou répondent à chaque transmission. L'ensemble des tâches esclaves sont continuellement à l'écoute des champs ID, vérifient leurs parités et déterminent si elles sont émettrices
ou réceptrices pour cet identifiant particulier. Le bus LIN offre un total de 64 ID. Les ID 0 à 59 sont utilisés pour les trames porteuses du signal (données), les ID 60 et 61 sont utilisés pour porter
des données de diagnostic, l'ID 62 est réservé pour les extensions définies par l'utilisateur et l'ID 63 est réservé pour les évolutions futures du protocole. L'ID est transmis sur le bus en tant
qu'octet ID protégé, les 6 premiers bits contenant l'ID brut et les 2 derniers contenant la parité.

ID protégé (7:6) ID
protégé (5:0)

P(1) P(0) ID (5:0)

ID(1) ^ ID(3) ^ ID(4) ^ ID(5) ID(1) ^ ID(3) ^ ID(4) ^ ID(5) 0–63

Tableau n°2. Méthode de calcul de la parité

4. Octets de données
Le champ d'octets de données est transmis par la tâche esclave dans la réponse. Ce champ contient de 1 à 8 octets de données.
5. Somme de contrôle
Le champ de somme de contrôle est transmis par la tâche esclave dans la réponse. Le bus LIN définit l'utilisation de l'un des deux algorithmes de somme de contrôle pour calculer la valeur du
champ somme de contrôle à 8 bits. La somme de contrôle classique est calculée en additionnant les octets de données seuls, la somme de contrôle améliorée est calculée en ajoutant les octets
de données et l'ID protégé.
La spécification LIN 2.0 définit le processus de calcul de la somme de contrôle comme étant l'addition de toutes les valeurs et la soustraction de 255 à chaque fois que la somme est supérieure ou
égale à 256 (contrairement à modulo-255 ou à modulo-256). D'après la spécification LIN 2.0, la somme de contrôle classique est à utiliser avec les nœuds esclaves LIN 1.3 et la somme de
contrôle améliorée est à utiliser avec les nœuds esclaves LIN 2.0. Elle spécifie également que les ID 60 à 63 devraient toujours utiliser la somme de contrôle classique. L'interface NI LIN offre un
attribut pour fixer le type de somme de contrôle, classique ou améliorée. La valeur par défaut est classique. D'après la spécification LIN 2.0, les ID 60 à 63 utilisent toujours la somme de contrôle
classique, quelle que soit la valeur de l'attribut de somme de contrôle.
La Figure n°3 illustre la manière dont l'en-tête de tâche maître et la réponse de tâche esclave s'associent pour créer une trame LIN complète.

Figure n°3. Création des trames LIN

3. Cadencement du bus LIN
Parce que le bus LIN est un bus interrogé, le traitement de chaque trame se voit allouer un temps nominal comme suit :
THeader_Nominal = 34 * TBit
TResponse_Nominal = 10 * (NData + 1) * TBit
TFrame_Nominal = THeader_Nominal + TResponse_Nominal
Le traitement de chaque trame se voit allouer une durée maximum comme suit :
THeader_Maximum = 14 * THeader_Nominal
TResponse_Maximum = 1.4 * TResponse_Nominal
TFrame_Maximum = THeader_Maximum + TResponse_Maximum

2/4 www.ni.com
4. Topologie et comportement d'un réseau LIN
Le bus LIN connecte un seul maître (nœud) et un ou plusieurs esclaves (nœuds) dans un cluster LIN. Le comportement de chaque nœud est décrit par son propre fichier de fonctionnalités. Les
fichiers de fonctionnalités sont les entrées d'un outil de définition du système qui génère un fichier de description LIN (LDF) détaillant le comportement du cluster entier. Le fichier LDF est analysé
par un générateur de systèmes qui génère automatiquement le comportement spécifié dans les nœuds souhaités. À ce stade, la tâche maître du nœud maître commence à transmettre les
en-têtes sur le bus, et toutes les tâches esclaves du cluster (y compris les propres tâches esclaves du nœud maître) répondent, comme le fichier LDF le spécifie.
En termes généraux, le fichier LDF est utilisé pour configurer et créer le comportement d'ordonnancement du cluster LIN. Par exemple, il définit la vitesse de transfert, l'ordre et les durées de
transmission des en-têtes de la tâche maître, et le comportement de chaque tâche esclave dans la réponse. Le matériel NI LIN et l'API NI-CAN Frame pour le LIN ne fournissent pas nativement
un support complet des fichiers LDF, ce qui signifie que vous ne pouvez pas télécharger le comportement d'ordonnancement dans le matériel. Cependant, le support bas niveau d'accès au bus
(écriture des en-têtes et publication ou souscription aux réponses) est fourni de façon à ce que l'utilisateur puisse créer ce comportement d'ordonnancement au niveau de l'application. Comme
mentionné dans la description pour la réponse à une trame, le matériel NI LIN offre une file d'attente de réponses destinée au stockage des réponses des tâches esclaves. La file d'attente de
réponses contient 64 réponses, une pour chacun des 64 ID (nombre maximum) spécifiés pour le LIN. Ceci permet à la tâche esclave de l'interface LIN de répondre aux en-têtes pendant le temps
de réponse défini par la spécification LIN.
L'API NI-CAN Frame pour le LIN offre des moyens robustes d'interactions complètes bas niveau avec le bus LIN. Ceci offre à l'utilisateur final les fonctionnalités de base à partir desquelles
développer des applications complexes impliquant l'analyse et le prototypage de réseaux LIN. L'API NI-CAN pour le LIN ne supporte pas nativement les diagnostics ni la configuration LIN, les
fichiers LDF, ni les tableaux. Cependant, vous pouvez mettre en œuvre ces tâches dans des applications qui utilisent l'API NI-CAN Frame pour le LIN.
5. Détection d'erreurs et isolation du LIN
La spécification LIN 2.0 déclare que la détection d'erreurs devrait être prise en charge par les tâches esclaves et que la surveillance des erreurs par la tâche maître n'est pas requise. La
spécification LIN 2.0 ne nécessite pas de gérer plusieurs erreurs dans une trame LIN ni l'utilisation de compteurs d'erreurs. En rencontrant la première erreur dans une trame, la tâche esclave
interrompt le traitement de la trame jusqu'à la détection de la séquence break-sync suivante (dans l'en-tête suivant transmis par le maître). Si l'attribut d'enregistrement des erreurs du bus est fixé
à vrai, une trame d'erreur du bus est enregistrée dans la file d'attente de lecture. Dans le cas contraire (faux), une erreur est renvoyée par ncWriteNet ou par ncWriteNetMult.
Le LIN offre également des fonctionnalités de rapports d'erreur au réseau. La spécification LIN 2.0 définit un bit d'état Response_Error, que l'esclave doit rapporter au maître dans l'une de ses
trames transmises. Ce bit est activé à chaque fois qu'une trame reçue ou transmise par un nœud esclave contient une erreur dans le champ de réponse. Le bit est effacé après sa transmission
dans l'une des réponses publiées de l'esclave. L'API NI-CAN Frame pour le LIN ne supporte pas nativement le bit d'état Response_Error mais elle offre à l'utilisateur final un moyen de mettre
facilement en œuvre cette fonctionnalité au niveau de l'application. La procédure est de fixer l'attribut d'enregistrement des erreurs de bus à 1 pour permettre l'enregistrement des trames d'erreur
de bus dans la file d'attente de lecture. L'application peut ensuite suivre la lecture d'une trame d'erreur de bus par un code d'erreur indiquant une erreur dans la réponse. À cette condition,
l'application peut fixer un bit d'état Response_Error dans une variable locale. Elle peut ensuite utiliser le type de trame de réponse d'entrée NI LIN pour mettre à jour la file d'attente de réponse de
l'esclave avec les données contenues dans le bit d'état Response_Error et ensuite effacer le bit dans la variable locale.
6. Mise en veille et réveil du LIN
Le LIN offre un mécanisme qui permet à tous les matériels d'entrer dans un état de sommeil et d'économiser potentiellement l'énergie. D'après la spécification LIN 2.0, tous les esclaves peuvent
être forcés en mode de veille par le maître qui envoie une trame maître de requête de diagnostic (ID = 60), dont le premier octet de données est égal à zéro. Cette trame particulière est
dénommée commande de mise en veille. Les esclaves entrent aussi automatiquement en mode de sommeil lorsque le réseau LIN reste inactif pendant plus de 4 secondes. L'API NI-CAN Frame
pour le LIN offre une grande flexibilité en permettant à l'utilisateur de mettre l'interface LIN en sommeil comme souhaité au niveau de l'application. À la réception d'une trame complète contenant
un message de requête de sommeil, ou d'une trame de bus inactif indiquant une inactivité du bus de quatre secondes, l'utilisateur peut choisir de mettre l'interface LIN en sommeil en fixant
l'attribut LIN Sleep à TRUE.
Le LIN offre également un mécanisme de réveil des matériels sur le bus. Le réveil est une tâche qui peut être initiée par n'importe quel nœud sur le bus (par un esclave aussi bien que par le
maître). D'après la spécification LIN 2.0, la requête de réveil est émise en forçant le bus dominant pendant 250 µs à 5 ms. Chaque esclave devrait détecter la requête de réveil et être prêt à traiter
les en-têtes dans les 100 ms. Le maître devrait également détecter la requête de réveil et commencer à envoyer les en-têtes lorsque les nœuds sont prêts (100 à 150 ms après la réception de la
requête de réveil). Si le maître n'émet pas les en-têtes 150 ms après la réception de la première requête de réveil, l'esclave ayant demandé le réveil peut essayer d'émettre une seconde requête
de réveil (et d'attendre pendant encore 150 ms). Si le maître ne répond toujours pas, l'esclave peut émettre la requête de réveil et attendre 150 ms une troisième fois. S'il n'obtient toujours pas de
réponse, l'esclave doit attendre pendant encore 1,5 secondes avant d'émettre une quatrième requête de réveil. L'API NI-CAN Frame pour le LIN permet de réaliser un réveil suivant la spécification
LIN 2.0, que l'interface LIN fonctionne en mode maître ou esclave.
7. Types de trames avancés
La spécification LIN 2.0 classe en outre les trames LIN en six types :
1. Non conditionnelle
2. Déclenchée par un événement
3. Sporadique
4. De diagnostic
5. Définie par l'utilisateur
6. Réservée
Il est important de remarquer que les différences entre ces types de trames sont dues soit à la temporisation de leur mode de transmission soit au contenu des octets de données. Quelle que soit
la classification de la trame, une trame LIN complète consiste en un en-tête transmis par la tâche maître et en une réponse transmise par une tâche esclave. L'API NI-CAN Frame pour le LIN peut
répondre aux besoins de gestion de chacun de ces types de trames spécifiées par le protocole LIN. Le type de trame non conditionnelle est très couramment utilisé. Les trames non
conditionnelles portent des signaux (données) et leurs identifiants sont dans la plage de 0 à 59.

Le type de trame déclenchée par un événement tente d'économiser la bande passante du bus en demandant une réponse par trame non conditionnelle provenant de multiples esclaves pendant
la durée de la trame.

La trame déclenchée par un événement peut avoir un ID compris dans la plage de 0 à 59. Chaque esclave qui pourrait potentiellement répondre à l'ID d'en-tête déclenché par un événement a son
premier octet de données chargé avec l'ID protégé qu'il renverrait si le maître lui demandait une trame non conditionnelle. La trame déclenchée par un événement fonctionne de la façon suivante.
Le maître écrit un ID déclenché par un événement dans un en-tête. Les esclaves peuvent répondre uniquement à l'ID déclenché par un événement si leurs données ont été mises à jour.
Si un seul esclave publie une réponse, le maître la reçoit et en examinant le premier octet de données, sait quel esclave l'a reçue (par le biais de l'ID protégé). Si plusieurs esclaves publient une
réponse, une collision se produit, que la tâche esclave du matériel maître rapporte en tant qu'erreur du bus. Le matériel maître demande ensuite une réponse à chaque esclave en utilisant les
trames non conditionnelles.
Les trames sporadiques tentent de fournir une forme de comportement dynamique au LIN. Elles portent toujours des signaux (données), et leurs ID vont de 0 à 59. L'en-tête d'une trame
sporadique ne devrait être envoyé que pendant sa durée allouée lorsque la tâche maître sait qu'une valeur (signal) a été mise à jour dans la trame. Cette exigence fait de la tâche esclave du
matériel maître l'émetteur normal des réponses de trames sporadiques.
Les trames de diagnostic ont systématiquement une longueur de 8 octets de données et portent toujours des données de diagnostic ou de configuration. Leurs ID sont soit 60 pour une trame de
requête maître soit 61 pour une trame de réponse esclave. Les trames définies par l'utilisateur, qui possèdent l'ID 62, peuvent porter n'importe quel type d'information. Les trames réservées ont un
ID de 63 et ne doivent pas être utilisées dans un cluster LIN 2.0.
8. Interfaces PC LIN recommandées

Figure n°4. Interface LIN NI USB-8476

Vous pouvez communiquer avec des matériels LIN en utilisant l' interface LIN NI USB-8476.
3/4 www.ni.com
Vous pouvez communiquer avec des matériels LIN en utilisant l' interface LIN NI USB-8476.
9. Informations supplémentaires sur le LIN
Pour en savoir plus sur les spécifications LIN, visitez le site du consortium LIN sur www.lin-subbus.org.

4/4 www.ni.com