Introduction au protocole de bus LIN

Le bus LIN (Local Interconnect Network) et le bus CAN (Controller Area Network) sont des protocoles de communication couramment utilisés dans les systèmes automobiles et industriels. Bien que LIN et CAN servent des objectifs similaires, il existe des différences notables dans leurs architectures et leurs capacités. 

LIN a été développé pour créer une norme de communication multiplexée bas de gamme à faible coût dans les réseaux automobiles. Bien que CAN réponde au besoin de réseaux avancés de gestion des erreurs à large bande passante, les coûts matériels et logiciels de la mise en œuvre de CAN sont devenus prohibitifs pour les périphériques moins performants tels que les contrôleurs de vitres électriques et de sièges. LIN fournit une communication rentable dans les applications non critiques où la bande passante et la polyvalence du CAN ne sont pas requises. Vous pouvez implémenter LIN à relativement peu de frais en utilisant le récepteur/émetteur asynchrone universel (UART) série standard intégré dans la plupart des microcontrôleurs 8 bits modernes à faible coût.

Les réseaux automobiles modernes utilisent une combinaison de LIN pour des applications peu coûteuses principalement dans l’électronique de carrosserie, CAN pour les communications de groupe motopropulseur et de carrosserie grand public, et le bus FlexRay émergent pour les communications de données synchronisées haute vitesse dans des 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 1 : Cadre de message LIN}

L'en-tête de message consiste en une pause utilisée pour identifier le départ de la trame et le champ de synchronisation utilisé par le nœud esclave pour la synchronisation d'horloge. L'identificateur (ID) consiste en un ID de message 6 bits et un champ de parité 2 bits. L'ID indique une adresse de message spécifique mais pas la destination. Lors de la réception et de l'interprétation de l'ID, un esclave commence la réponse au message, qui consiste en un à huit octets de données et une somme de contrôle de 8 bits. 

Le maître contrôle le séquencement des trames de messages, qui est fixé dans une planification. Vous pouvez modifier l'horaire selon vos besoins. 

Il existe plusieurs versions de la norme LIN. La version 1.3 a finalisé la communication par couche d'octets. Les versions 2.0 et 2.1 ont ajouté des spécifications et des services de messagerie supplémentaires mais sont compatibles au niveau des octets avec LIN 1.3. 

¹Cette fonctionnalité n'est pas supportée nativement par l'API, mais vous pouvez l'implémenter. 

^{Tableau 1 : Comparaison des versions 1.3, 2.0 et 2.1} de LIN

Le bus LIN est un bus interrogé avec un seul périphérique maître et un ou plusieurs périphériques esclaves. Le périphérique maître contient à la fois une tâche maître et une tâche esclave. Chaque périphérique esclave ne contient qu'une tâche esclave. La communication via le bus LIN est entièrement contrôlée par la tâche maître dans le périphérique maître. L'unité de transfert de base sur le bus LIN est la trame, qui est divisée en un en-tête et une réponse. L'en-tête est toujours transmis par le nœud maître et se compose de trois champs distincts : la pause, la synchronisation (sync) et l'identificateur (ID). La réponse, transmise par une tâche esclave et pouvant résider soit dans le nœud maître, soit dans un nœud esclave, consiste en une charge utile de données et une somme de contrôle. 

Normalement, la tâche maître interroge chaque tâche esclave d'une boucle en transmettant un en-tête, qui consiste en une séquence break-sync-ID. Avant de démarrer le LIN, chaque tâche esclave est configurée pour publier des données sur le bus ou s'abonner à des données en réponse à chaque ID d'en-tête reçu. À la réception de l'en-tête, chaque tâche esclave vérifie la parité d'ID puis vérifie l'ID pour déterminer si elle doit publier ou s'abonner. Si la tâche esclave doit publier une réponse, elle transmet un à huit octets de données au bus suivis d'un octet de somme de contrôle. Si la tâche esclave doit s'abonner, elle lit la charge utile de données et l'octet de somme de contrôle du bus et prend les mesures internes appropriées. 

Pour la communication esclave-maître standard, le maître diffuse l'identificateur au réseau, et un seul esclave répond avec une charge utile de données.

La communication maître à esclave est réalisée par une tâche esclave distincte dans le nœud maître. Cette tâche reçoit automatiquement toutes les données publiées sur le bus et répond comme s'il s'agissait d'un nœud esclave indépendant. Pour transmettre des octets de données, le maître doit d’abord mettre à jour la réponse de sa tâche esclave interne avec les valeurs de données qu’il veut transmettre. Le maître publie alors l'en-tête de trame approprié, et la tâche esclave interne transmet sa charge utile de données au bus.

^{Figure 2 : Cadre de message LIN}

1. Attn

Chaque trame LIN commence par la pause, qui comprend 13 bits dominants (nominaux) suivis d'un séparateur de pause d'un bit (nominal) récessif. Ceci sert d'avis de début de trame à tous les nœuds du bus.

2. Sync

Le champ de synchronisation est le deuxième champ transmis par la tâche maître dans l'en-tête. Sync est défini comme le caractère x55. Le champ de synchronisation permet aux périphériques esclaves qui effectuent une détection automatique du débit en bauds de mesurer la période du débit en bauds et d'ajuster leurs débits internes pour se synchroniser avec le bus.

3. ID

Le champ ID est le champ final transmis par la tâche maître dans l'en-tête. Ce champ fournit une identification pour chaque message sur le réseau et détermine finalement quels nœuds du réseau reçoivent ou répondent à chaque transmission. Toutes les tâches esclaves écoutent continuellement les champs d'ID, vérifient leurs parités et déterminent si elles sont des éditeurs ou des abonnés pour cet identificateur particulier. Le bus LIN fournit un total de 64 ID. Les ID 0 à 59 sont utilisés pour les trames porteuses de signaux (données), 60 et 61 sont utilisés pour transporter des données de diagnostic, 62 est réservé aux extensions définies par l'utilisateur et 63 est réservé aux améliorations futures du protocole. L'ID est transmis sur le bus sous forme d'un octet d'ID protégé, les six bits inférieurs contenant l'ID brut et les deux bits supérieurs contenant la parité.

^{Tableau 2 : Méthode de calcul de parité}

4. Octets de données

Le champ octets de données est transmis par la tâche esclave dans la réponse. Ce champ contient de un à huit octets d'octets de données de charge. 

5. Somme de contrôle/Checksum

Le champ checksum est transmis par la tâche esclave dans la réponse. Le bus LIN définit l'utilisation d'un des deux algorithmes de checksum pour calculer la valeur dans le champ checksum 8 bits. La somme de contrôle classique est calculée en additionnant les octets de données seuls, et la somme de contrôle améliorée est calculée en additionnant les octets de données et l'ID protégé.

La spécification LIN 2.0 définit le processus de calcul de checksum comme la somme 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). Selon la spécification LIN 2.0, checksum classique est à utiliser avec les nœuds esclaves LIN 1.3 et checksum amélioré est à utiliser avec les nœuds esclaves LIN 2.0. Il précise en outre que les numéros d'identification 60 à 63 doivent toujours utiliser la somme de contrôle classique. L'interface NI LIN fournit un attribut pour définir le type de somme de contrôle à classique ou amélioré. Le paramètre par défaut est classique. Selon la spécification LIN 2.0, les ID 60 à 63 utilisent toujours la checksum classique, quel que soit le paramètre de l'attribut checksum.

La figure 3 illustre comment un en-tête de tâche maître et une réponse de tâche esclave se combinent pour créer une trame complète LIN. 

^{Figure 3 : Création de trames LIN}

Comme le bus LIN est un bus interrogé, le traitement de chaque trame se voit allouer un intervalle de temps nominal comme suit :

THeader_Nominal = 34 * Toit
RéponseTR_Nominale = 10 * (NDonnées + 1) * TBit
TFrame_Nominal = THeader_Nominal + TResponse_Nominal
Le traitement de chaque trame se voit allouer un intervalle de temps maximal comme suit :
THeader_Maximum = 14 * THeader_Nominal
RéponseTR_Maximum = 1,4 * RéponseTR_Nominale
TFrame_Maximum = THeader_Maximum + TResponse_Maximum

Le bus LIN connecte un seul périphérique maître (nœud) et un ou plusieurs périphériques esclaves (nœuds) dans un cluster LIN. Le comportement de chaque nœud est décrit par son propre fichier de capacité de nœud. Les fichiers de capacité du nœud sont des entrées d'un outil de définition du système, qui génère un fichier de description LIN (LDF) qui décrit le comportement de tout le cluster. Le LDF est analysé par un générateur de système pour générer automatiquement le comportement spécifié dans les nœuds désirés. À ce stade, la tâche maître du nœud maître commence à transmettre des en-têtes sur le bus, et toutes les tâches esclaves du cluster (y compris la tâche esclave du nœud maître) répondent, comme spécifié dans la LDF.

En général, la LDF est utilisée pour configurer et créer le comportement de planification du cluster LIN. Par exemple, il définit le débit en bauds, les délais d’ordonnancement et de transmission des en-têtes de la tâche maître et le comportement de chaque tâche esclave en réponse. Le matériel NI LIN et l'API NI-CAN Frame for LIN ne fournissent pas nativement une prise en charge complète des LDF, ce qui signifie que vous ne pouvez pas télécharger le comportement de planification dans le matériel. Cependant, le support de bas niveau de l'accès au bus (écriture des en-têtes et publication ou abonnement aux réponses) est fourni de sorte que l'utilisateur peut créer ce comportement de planification au niveau de l'application. Comme mentionné dans la description du type de trame d'entrée de réponse NI LIN, le matériel NI LIN comporte une file d'attente de réponses pour stocker les réponses des tâches esclaves. La file d'attente de réponses contient 64 réponses, une pour chaque nombre maximum de 64 ID spécifié pour LIN. Cela garantit que la tâche esclave d'interface LIN peut répondre aux en-têtes dans le temps de réponse défini par la spécification LIN.

L'API NI-CAN Frame for LIN offre un moyen robuste d'interaction complète et de bas niveau avec le bus LIN. Cela fournit à l’utilisateur final les fonctionnalités de base pour développer des applications complexes impliquant l’analyse et le prototypage de réseaux LIN. NI-CAN Frame API for LIN ne supporte pas nativement les diagnostics ou la configuration LIN, les LDF ou les tables d'horaires. Cependant, vous pouvez implémenter ces tâches dans des applications qui utilisent l'API NI-CAN Frame pour LIN.

La spécification LIN 2.0 stipule que la détection d'erreur doit être gérée par les tâches esclaves et que la surveillance d'erreur par la tâche maître n'est pas requise. La spécification LIN 2.0 ne requiert pas la gestion de plusieurs erreurs dans une trame LIN ou l'utilisation de compteurs d'erreur. Lorsqu'elle rencontre la première erreur dans une trame, la tâche esclave abandonne 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 log bus errors est défini à Vrai, une trame d'erreur de bus est enregistrée dans la file d'attente de lecture. Si l'attribut log bus errors est défini à false, une erreur est renvoyée par ncWriteNet ou ncWriteNetMult. 

LIN permet également de rapporter les erreurs 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 une de ses trames transmises. Ce bit est défini quand 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 avoir été transmis dans une des réponses publiées de l'esclave. L'API NI-CAN Frame for LIN ne supporte pas nativement le bit d'état Response_Error mais fournit à l'utilisateur final un moyen d'implémenter facilement cette fonctionnalité au niveau de l'application. La procédure définit l'attribut log bus errors à 1 pour activer l'enregistrement des trames d'erreur de bus dans la file d'attente de lecture. L'application peut alors surveiller une lecture d'une trame d'erreur de bus avec le code d'erreur indiquant une erreur dans la réponse. À cette condition, l'application peut définir un bit d'état Réponse_Erreur dans une variable locale. L'application peut alors utiliser le type de trame d'entrée de réponse NI LIN pour mettre à jour la file d'attente de réponse esclave avec des données contenant le bit d'état Response_Error, puis effacer le bit dans la variable locale.

LIN dispose d'un mécanisme qui permet aux périphériques d'entrer dans l'état de veille et potentiellement de conserver l'énergie. Selon la spécification LIN 2.0, tous les esclaves peuvent être forcés en mode veille par le maître envoyant une trame de requête maître de diagnostic (ID=60) avec le premier octet de données égal à zéro. Cette étape spéciale est appelée commande mise en veille. Les esclaves passent aussi automatiquement en mode veille si le LIN est inactif pendant plus de quatre secondes. L'API NI-CAN Frame for LIN offre une grande flexibilité en permettant à l'utilisateur d'endormir l'interface LIN comme il le souhaite au niveau de l'application. Lorsqu'il reçoit une trame complète contenant un message de requête de mise en veille, ou une trame inactive du bus indiquant quatre secondes d'inactivité du bus, l'utilisateur peut choisir d'endormir l'interface LIN en définissant l'attribut LIN Sleep à VRAI.

LIN offre également un mécanisme de réveil des périphériques sur le bus. Le réveil est une tâche qui peut être initiée par n'importe quel nœud du bus (un esclave aussi bien que le maître). Selon la spécification LIN 2.0, la requête de réveil est émise en forçant le bus à être dominant pendant 250 μs à 5 ms. Chaque esclave doit détecter la requête de réveil et être prêt à traiter les en-têtes dans les 100 ms. Le maître doit aussi détecter la demande de réveil et commencer à envoyer des en-têtes lorsque les nœuds esclaves sont prêts (dans les 100 à 150 ms suivant la réception de la demande de réveil). Si le maître n'émet pas d'en-têtes dans les 150 ms suivant la réception de la première requête de réveil, l'esclave qui demande le réveil peut essayer d'émettre une deuxième requête de réveil (et attendre 150 ms supplémentaires). 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'y a toujours pas de réponse, l'esclave doit attendre 1,5 seconde avant d'émettre une quatrième requête de réveil. L'API NI-CAN Frame for LIN permet d'effectuer le réveil conformément à la spécification LIN 2.0, que l'interface LIN fonctionne en tant que maître ou esclave.

La spécification LIN 2.0 classe en outre les trames LIN en six types :

1. Inconditionnel
2. Événement déclenché
3. Sporadique
4. Diagnostic
5. Définis par l'utilisateur
6. Réservé

Il est important de noter que les différences dans ces types de trames sont dues soit au cadencement de leur transmission, soit au contenu des octets de données. Quelle que soit la classification de trame, une trame LIN complète consiste toujours en un en-tête transmis par la tâche maître et une réponse transmise par une tâche esclave. NI-CAN Frame API for LIN peut répondre aux besoins de gestion de chacun de ces types de trames spécifiés par LIN. Le type de trame inconditionnelle est le plus couramment utilisé. Les trames inconditionnelles transportent des signaux (données) et leurs identificateurs se situent dans la gamme de 0 à 59.

Le type de trame déclenchée par événement tente de conserver la bande passante du bus en demandant une réponse de trame inconditionnelle à plusieurs esclaves dans un intervalle de temps de trame.

La trame déclenchée par événement peut avoir un ID compris entre 0 et 59. Chaque esclave qui pourrait potentiellement répondre à l'ID d'en-tête déclenché par événement a son premier octet de données chargé avec l'ID protégé auquel il répondrait si le maître l'interrogeait pour une trame inconditionnelle. L'étape déclenchée par événement fonctionne comme suit. Le maître écrit un ID déclenché par événement dans un en-tête. Les esclaves peuvent répondre uniquement à l'ID déclenché par é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 regardant le premier octet de données, sait de quel esclave (via l'ID protégé) elle a été reçue. Si plusieurs esclaves publient une réponse, une collision se produit, que la tâche esclave du périphérique maître rapporte comme erreur de bus. Le périphérique maître interroge ensuite une réponse de chaque esclave en utilisant des trames inconditionnelles. 

Les trames sporadiques tentent de fournir un comportement dynamique au LIN. Ils transportent toujours des signaux (données) et leurs ID vont de 0 à 59. L'en-tête d'une trame sporadique ne doit être envoyé que dans son emplacement de trame lorsque la tâche maître sait qu'une valeur de données (signal) dans la trame a été mise à jour. Cette exigence fait de la tâche esclave du périphérique maître l'éditeur normal de réponses de trames sporadiques.

Les trames de diagnostic ont toujours une longueur de huit octets de données et transportent toujours des données de diagnostic ou de configuration. Leurs ID sont 60 pour une trame de requête maître ou 61 pour une trame de réponse esclave. Les trames définies par l'utilisateur, dont l'ID est 62, peuvent transporter n'importe quel type d'informations. Les trames réservées ont l'ID 63 et ne peuvent pas être utilisées dans un cluster LIN 2.0.

NI-XNET LIN

La ligne de produits NI-XNET est une combinaison d ' interfaces CAN accélérées, LIN et FlexRay, d ' un driver optimisé, d ' API faciles à utiliser et d ' utilitaires de configuration et de mise au point. À l'aide des interfaces NI-XNET, vous pouvez développer des applications pour prototyper, simuler et tester les réseaux CAN, LIN et FlexRay plus rapidement et plus facilement dans NI LabVIEW et LabVIEW Real-Time ainsi que dans C/C++.

Les interfaces NI-XNET PCI/PXI et LIN de la Série C incluent également le support LDF intégré, la planification à cadencement matériel pour les tâches maîtres et la communication de trames et de signaux. 

^{Figure 4 : Plateforme NI-XNET pour CAN, LIN et FlexRay}

NI USB LIN

^{Figure 5 : Interface LIN NI USB-8506}

Vous pouvez également communiquer avec des périphériques LIN en utilisant un matériel d’interface LIN USB. Il s’agit d’une solution mobile à moindre coût pour communiquer avec les réseaux LIN.