Introduction au protocole CAN. Le bus CAN n'est pas réservé qu'aux voitures. Présentation du CAN

Administrateur

La nécessité d'une connexion série dans les voitures

Voici notre prochain article traduit du cycle consacré au bus CAN, qui dévoile un peu plus en détail comment le bus CAN est agencé et fonctionne. original en anglais.

De nombreuses voitures ont déjà un grand nombre systèmes électroniques la gestion. La croissance de l'électronique automobile est le résultat en partie des demandes des consommateurs pour plus de sécurité et de confort, et en partie des demandes du gouvernement pour un meilleur contrôle des émissions et une consommation de carburant plus faible. Des dispositifs de commande qui répondent à ces exigences sont utilisés depuis un certain temps dans les domaines de la commande du moteur, de la transmission et de l'accélérateur, ainsi que des systèmes de freinage antiblocage (ABS) et du contrôle d'accélération (ASC).

La complexité des fonctions mises en œuvre dans ces systèmes nécessite l'échange de données entre eux. Dans les systèmes traditionnels, l'échange de données est effectué à l'aide de lignes de signaux dédiées, mais cela devient de plus en plus difficile et coûteux à mesure que les fonctions de contrôle deviennent plus complexes. Dans le cas de systèmes de contrôle complexes (tels que Motronic), en particulier, le nombre de connexions ne peut plus être augmenté.

En outre, un certain nombre de systèmes sont en cours de développement pour mettre en œuvre des fonctions couvrant plus d'un dispositif de contrôle. Par exemple, l'ASC nécessite l'interaction du système de gestion du moteur et de la commande d'accélérateur (injection) pour réduire le couple lorsque la roue motrice patine. Un autre exemple de fonctions couvrant plus d'une unité de commande est la commande de transmission électronique, où la facilité de changement de vitesse peut être améliorée en ajustant brièvement le calage de l'allumage.

Si nous considérons également les développements futurs visant à l'optimisation globale du véhicule, alors les limitations associées aux dispositifs de contrôle conventionnels doivent être surmontées. Cela ne peut être fait qu'en mettant en réseau les composants du système à l'aide d'un bus de données série. Bosch a développé le Controller Area Network (CAN) à cette fin, qui a depuis été normalisé au niveau international (ISO 11898) et a été « moulé dans la pierre (en silicium) » par plusieurs fabricants de semi-conducteurs.

En utilisant CAN, les stations peer (peer-to-peer) (contrôleurs, capteurs et actionneurs) sont connectées via un bus série. Le bus lui-même est un circuit à deux fils symétrique ou asymétrique, qui peut être blindé ou non blindé. Les paramètres électriques de la transmission physique sont également spécifiés dans la norme ISO 11898. Des puces de pilote de bus appropriées sont disponibles auprès d'un large éventail de fabricants.

Le protocole CAN conforme à la couche liaison de données dans le modèle de référence ISO / OSI répond aux exigences automobiles pour les applications automobiles d'aujourd'hui. Contrairement aux arborescences de câbles, le protocole réseau détecte et corrige les erreurs de transmission causées par les interférences électromagnétiques. Les avantages supplémentaires d'un tel réseau sont la facilité de configuration de l'ensemble du système et la possibilité d'un diagnostic centralisé.

Le but de l'utilisation du CAN dans les véhicules est de permettre à n'importe quelle station de communiquer avec une autre sans trop solliciter l'ordinateur du contrôleur.

Utilisation du réseau CAN dans les voitures

Il existe quatre applications principales pour la communication série dans les véhicules, chacune avec des exigences et des objectifs différents.

Contrôleurs en réseau pour la synchronisation du moteur, de la transmission, du châssis et des freins. Les débits de données sont dans la plage - typique des systèmes en temps réel, de 200 kbps à 1 Mbps.
Composants de mise en réseau de l'électronique générale et de l'électronique du châssis qui rendent le véhicule plus confortable. Des exemples de telles applications multiplex sont la commande d'éclairage, la climatisation et le verrouillage centralisé, ainsi que le réglage des sièges et des rétroviseurs. Un accent particulier doit être mis sur les coûts des composants et les exigences de câblage. Les débits en bauds typiques sont d'environ 50 kbps.
Dans un avenir proche, les communications série seront également utilisées dans les communications mobiles pour relier des composants tels que des autoradios, des téléphones de voiture, des aides à la navigation, etc. à un panneau de commande central plus ergonomique. Les fonctions définies dans le projet Prometheus, telles que la communication de véhicule à véhicule, reposeront fortement sur la communication série.
Actuellement, CAN est utilisé pour les trois premières applications, mais pour le diagnostic, la solution préférée est une interface conforme à la norme ISO 9141.

Applications industrielles du réseau CAN

La comparaison des exigences des systèmes de bus de véhicules et des systèmes de bus de terrain industriels révèle des similitudes surprenantes : un faible coût, une opérabilité dans un environnement électrique difficile, des capacités en temps réel élevées et une facilité d'utilisation sont également souhaitables dans les deux secteurs.

L'utilisation standard du CAN dans la "Classe S" de Mercedes-Benz et l'adoption du CAN par les constructeurs automobiles américains pour une transmission rapide (jusqu'à 1 Mbps) ont laissé les utilisateurs industriels surexcités. Non seulement les fabricants de machines et d'équipements agricoles et marins mobiles et fixes ont choisi CAN, mais également le choix des fabricants d'équipements médicaux, de machines textiles, ainsi que d'équipements spéciaux et de commandes d'ascenseur. Le système de bus série est particulièrement bien adapté aux dispositifs d'E/S « intelligents » en réseau ainsi qu'aux capteurs et actionneurs au sein d'une machine ou d'une installation.

L'industrie des machines textiles est l'une des pionnières de la CAN. Un fabricant a équipé ses métiers à tisser de systèmes de contrôle modulaires communiquant en temps réel via des réseaux CAN dès 1990. Entre-temps, plusieurs fabricants de machines textiles ont fusionné dans le groupe d'utilisateurs de textiles CAN, qui à son tour est membre du groupe international d'utilisateurs et de fabricants CAN in Automation. Des exigences similaires pour les machines textiles se retrouvent dans les machines d'emballage et de fabrication et de traitement du papier.

Aux États-Unis, un certain nombre d'entreprises utilisent CAN dans les lignes de production et les machines-outils comme système de bus interne pour les capteurs et actionneurs de réseau en ligne ou directement dans la machine. Certains utilisateurs, comme le secteur de l'ingénierie médicale, ont opté pour CAN car ils avaient des exigences de sécurité particulièrement strictes. D'autres fabricants de machines et d'équipements ayant des exigences de sécurité particulières (par exemple, des robots et des systèmes de transport) sont confrontés à des problèmes similaires.

Outre la fiabilité élevée de la transmission, les faibles coûts de connexion par station sont un autre argument décisif pour CAN. Dans les applications où le prix est critique, il est très important que les puces CAN soient disponibles auprès de divers fabricants. La compacité des autres puces de contrôle est également une considération importante, par exemple dans le domaine des appareillages basse tension.

Comment fonctionnent les réseaux CAN

Principes d'échange de données

Lorsque les données sont transmises via CAN, aucune station n'est adressée, mais le contenu du message (comme le régime ou la température du moteur) est indiqué par un identifiant unique sur tout le réseau. L'identifiant détermine non seulement le contenu, mais aussi la priorité du message. Ceci est important pour l'attribution des bus lorsque plusieurs stations sont en concurrence pour l'accès aux bus. Si le CPU d'une station donnée souhaite envoyer un message à une ou plusieurs stations, il transmet les données et leurs identifiants à la puce CAN désignée (état "Prêt"). C'est tout ce que la CPU a à faire pour initier la communication. Le message est généré et transmis à l'aide d'une puce CAN. Dès que la puce CAN reçoit une allocation de bus (état "Send Message"), toutes les autres stations du réseau CAN deviennent destinataires de ce message (état "Receive Message"). Chaque station du réseau CAN, ayant correctement reçu un message, effectue un test de réception (test de réception) pour déterminer si les données reçues sont liées à cette station (état « Select »). Si la donnée est significative pour la station correspondante, elle est traitée (état « Accepté »), sinon elle est ignorée. Un haut degré de flexibilité du système et de la configuration est obtenu grâce à un schéma d'adressage orienté contenu. Il est très facile d'ajouter des stations à réseau existant CAN sans apporter de modifications matérielles ou logicielles aux stations existantes, à condition que les nouvelles stations soient de purs récepteurs. Étant donné que le protocole de transfert de données ne nécessite pas d'adresses de destination physiques pour les composants individuels, il prend en charge le concept d'électronique modulaire et permet également la réception multiple (diffusion, multidiffusion) et la synchronisation de processus distribués : les mesures requises sous forme d'informations par plusieurs contrôleurs peuvent être transmises sur le réseau de cette façon, que chaque contrôleur n'a pas besoin d'avoir son propre capteur.

1. Transmission de diffusion et filtrage d'entrée par les nœuds CAN pour déterminer si les données conviennent à un nœud particulier

Vérification non destructive au niveau du bit :

Pour que les données soient traitées en temps réel, elles doivent être transférées rapidement. Cela nécessite non seulement une liaison de données physique jusqu'à 1 Mbps, mais nécessite également une affectation rapide du bus lorsque plusieurs stations souhaitent envoyer des messages en même temps.

2. Le principe du contrôle bit à bit non destructif (évaluation, lecture)

En temps réel, l'urgence (séquence) de la messagerie sur le réseau peut être très variable : une dimension changeant rapidement (par exemple la charge du moteur) doit être transmise plus fréquemment et donc avec des délais plus faibles que d'autres mesures (par exemple la température du moteur) qui varient relativement lentement. La priorité à laquelle un message est envoyé par rapport à un autre message moins urgent est déterminée par l'identifiant du message correspondant. Les priorités sont définies dans la conception du système sous la forme de valeurs binaires correspondantes et ne peuvent pas être modifiées dynamiquement. L'identifiant avec le plus petit nombre binaire a la priorité la plus élevée.

Les conflits d'accès au bus sont résolus par une vérification bit à bit des identifiants reçus par chacune des stations participantes en observant (lecture) le niveau de bus bit à bit. Selon le mécanisme "filaire et" par lequel l'état dominant (logique 0) écrase l'état récessif (logique 1), la contention d'allocation de bus est perdue par toutes ces stations avec émission récessive et supervision dominante (attente 0 pour recevoir). Tous les "perdants" sont automatiquement destinataires du message de priorité la plus élevée et ne retransmettent pas tant que le bus n'est pas à nouveau disponible.

Efficacité de la distribution des pneus :

L'efficacité d'un système de distribution de bus est principalement déterminée par application possible pour ce système de bus série. Pour juger quels systèmes de bus conviennent à quelles applications, la littérature comprend une méthode de classification des procédures d'allocation de bus. On distingue généralement les classes suivantes :

Distribution selon un horaire fixe. L'attribution se fait séquentiellement à chaque participant pour la durée maximale, que ce participant ait besoin d'un bus à l'instant ou non (exemples : transfert de cellule marqueur ou de jeton).
Attribution des bus en fonction des besoins. Le bus est attribué à un participant en fonction des demandes de transfert en suspens, c'est-à-dire que le système d'allocation ne considère que les participants souhaitant transférer (exemples : CSMA, CSMA/CD, contrôle de vol, round robin ou bitwise check). Pour CAN, l'allocation de bus est négociée exclusivement entre les messages en attente. Cela signifie que la procédure définie par CAN est classée comme allocation basée sur les besoins.

Un autre moyen d'évaluer l'efficacité des systèmes de test (évaluation) de bus est la méthode d'accès au bus :

Accès non destructif au bus. Avec des méthodes de ce type, un bus est affecté à une et une seule station, soit immédiatement, soit dans un délai déterminé après un accès au bus (par une ou plusieurs stations). Cela garantit que chaque accès au bus par une ou plusieurs stations se traduit par une affectation de bus sans ambiguïté (exemples : cellule de marqueur, transfert de jeton, bouclage, vérification au niveau du bit.
Distribution destructive des pneus. L'accès simultané au bus par plusieurs stations interrompt toutes les tentatives de transmission et donc aucune attribution de bus réussie. L'allocation de bus peut nécessiter plusieurs accès au bus, le nombre de tentatives avant que l'allocation de bus ne réussisse est purement statistique (exemples : CSMA / CD, Ethernet). Afin de traiter toutes les demandes de transfert du réseau CAN tout en respectant les limites de latence au débit le plus bas possible, le protocole CAN doit mettre en œuvre une méthode d'allocation de bus qui garantit qu'il y a toujours une allocation de bus unique, même s'il y a des accès bus simultanés depuis différentes stations .

La méthode de contrôle bit par bit, utilisant l'identifiant des messages à transmettre, résout sans ambiguïté toute collision entre plusieurs stations qui souhaitent transmettre, et ce dans des périodes de 13 (format standard) ou 33 (format étendu) bits à au plus tard pour toute période d'accès. Contrairement au contrôle de message utilisé par la méthode CSMA/CD, cette méthode de résolution de collision non destructive garantit que la bande passante du bus n'est pas utilisée sans transmettre d'informations utiles.

Même dans les situations où le bus est encombré, l'association de la priorité d'accès au bus avec le contenu du message s'avère être un attribut système utile par rapport aux protocoles CSMA/CD ou token (token) existants : malgré une bande passante de bus insuffisante, toutes les demandes de transfert en attente sont traités en fonction de leur importance pour l'ensemble du système (tel que déterminé par la priorité du message).

La bande passante disponible est effectivement utilisée pour le transfert de la charge utile, car les "lacunes" dans l'allocation du bus restent très faibles. L'effondrement de l'ensemble du système de transmission en raison d'une surcharge, qui peut se produire avec le protocole CSMA / CD, n'est pas possible avec CAN. Ainsi, CAN permet un accès au bus rapide et spécifique au trafic qui est non destructif en raison d'une validation au niveau du bit basée sur la priorité de message utilisée.

L'accès au bus non destructif peut être divisé en :

Contrôle d'accès aux bus centralisé et
Contrôle d'accès de bus décentralisé

Selon que les mécanismes de contrôle sont présents dans le système une seule fois (centralisé) ou plusieurs fois (décentralisé).

Le système de communication avec la station désignée (en particulier pour le contrôle d'accès centralisé du bus) doit prévoir une stratégie efficace en cas de défaillance de la station principale. Ce concept présente l'inconvénient que la stratégie de gestion des pannes est complexe et coûteuse à mettre en œuvre, et que la prise en charge d'une station centrale par une station de secours peut être très longue.

Pour ces raisons, et afin de contourner le problème de fiabilité de la station maître (et donc de l'ensemble du système de communication), le protocole CAN met en œuvre une commande de bus décentralisée. Tous les mécanismes de communication de base, y compris le contrôle d'accès au bus, sont exécutés plusieurs fois dans le système, car c'est le seul moyen de répondre aux exigences de haute disponibilité du système de communication.

En général, on peut dire que CAN implémente un système de distribution de bus spécifique au trafic, qui permet d'utiliser un accès non destructif au bus avec un contrôle d'accès décentralisé pour fournir une haute vitesse utile transmission de données à la vitesse de transmission de bus la plus faible possible lorsque le bus est occupé pour toutes les stations. L'efficacité de la procédure de contrôle du bus est augmentée par le fait que le bus n'est utilisé que par les stations en attente de transmission de requêtes.

Ces demandes sont traitées par ordre d'importance pour le système dans son ensemble. Ceci est particulièrement avantageux en cas de surcharge. Étant donné que l'accès au bus est prioritaire sur une base de message, une faible latence individuelle peut être garantie dans les systèmes en temps réel.

3. Trame de message pour le format standard (spécification CAN 2.0A)

Formats de messages.

Le protocole CAN prend en charge deux formats de trames de message (frames), la seule différence significative est la longueur de l'identifiant (ID). Dans le format standard, la longueur de l'identifiant est de 11 bits, et dans le format étendu, la longueur est de 29 bits. Le télégramme pour la transmission par bus contient sept champs de base.

Un message au format standard commence par un bit de départ "début de trame", suivi d'un "champ de contrôle" qui contient l'identifiant et le bit "RTR" (remote transmission request) qui indique s'il s'agit d'une trame de données ou d'une requête trame sans aucun octet de données (trame de demande distante).

Le "champ de contrôle" contient un bit d'extension IDE (identifiant d'extension) qui indique soit le format standard soit le format étendu, le bit est réservé aux extensions futures et - dans les 4 derniers bits - le nombre d'octets de données dans les données domaine.

Le "champ de données" a une longueur de 0 à 8 octets et est suivi d'un champ "CRC", qui est utilisé comme contrôle de sécurité de trame pour détecter les erreurs de bits.

Le champ "ACK" contient un slot ACK (1 bit) et un délimiteur ACK (un bit récessif). Le bit dans le créneau ACK est envoyé en tant que bit récessif et est écrasé en tant que bit dominant par les récepteurs qui les ont reçus correctement (correctement) (accusé de réception positif) à ce moment-là. Les messages corrects sont confirmés par les récepteurs quel que soit le résultat du test d'acceptation. La fin du message est désignée "fin de trame". "Break" est le nombre minimum de périodes de bits séparant des messages successifs. Si une station n'a pas d'accès au bus suivant, le bus reste inactif ("bus inactif").

Détection et signalisation des erreurs.

Contrairement à d'autres systèmes bus CAN-le protocole n'utilise pas de messages de confirmation, mais signale à la place toutes les erreurs qui se produisent. Pour détecter les erreurs dans le protocole CAN, trois mécanismes sont mis en œuvre au niveau du message :

Contrôle de redondance cyclique (CRC) Le CRC protège les informations dans une trame en ajoutant des bits de contrôle redondants à la fin de la transmission. Du côté du récepteur, ces bits sont recalculés et comparés aux bits reçus. S'ils ne sont pas d'accord, une erreur CRC s'est produite. Frame Check - Ce mécanisme vérifie la structure de la trame transmise en vérifiant les champs de bits pour un format et une taille de trame fixes. Les erreurs trouvées lors de la validation des trames sont appelées « erreurs de format ».
ACK erreurs. Comme mentionné ci-dessus, les trames reçues sont acquittées par tous les destinataires avec un "accusé de réception positif". Si aucun accusé de réception n'est reçu par l'expéditeur du message (erreur ACK), cela peut signifier qu'il y a une erreur de transmission qui n'a été détectée que par les destinataires, que le champ ACK a été corrompu, ou qu'il n'y a pas de destinataires.

CAN implémente également deux mécanismes de détection d'erreurs au niveau du bit.

Surveillance. La capacité de l'émetteur à détecter les erreurs repose sur la surveillance des signaux du bus : chaque nœud qui émet surveille également le niveau du bus et détecte ainsi les différences entre le bit envoyé et le bit reçu. Cela garantit une détection fiable de toutes les erreurs globales et locales de l'émetteur.
Bourrage de bits - le codage des bits individuels est vérifié au niveau des bits. La représentation des bits utilisée par CAN est le codage NRZ (non retour à zéro), qui garantit une efficacité maximale dans le codage des bits. Les fronts de synchronisation sont générés par bourrage de bits, c'est-à-dire qu'après cinq bits égaux consécutifs, l'émetteur insère un bit d'information dans le flux binaire avec une valeur supplémentaire qui est supprimée par les récepteurs. La vérification du code se limite à vérifier que la règle de remplissage a été respectée. Si une ou plusieurs erreurs sont détectées par au moins une station (n'importe quelle station) utilisant les mécanismes ci-dessus, la transmission en cours est interrompue en envoyant un "indicateur d'erreur". Cela empêche d'autres stations de recevoir des messages et garantit ainsi la cohérence des données sur l'ensemble du réseau.

Lorsque la transmission d'un message erroné est arrêtée, l'expéditeur retente automatiquement la transmission (demande de réessai automatique). La concurrence pour l'attribution des bus pourrait réapparaître. Typiquement, la retransmission commence dans les périodes de 23 bits après qu'une erreur est détectée ; Dans des cas particuliers, le temps de récupération du système est de 31 bits.

Cependant, la méthode décrite peut être efficace et efficiente dans le cas où un dysfonctionnement de la station peut entraîner l'interruption de tous les messages (y compris les bons), ce qui bloque le système de bus si aucune mesure n'a été prise pour l'autosurveillance. Ainsi, le protocole CAN fournit un mécanisme pour isoler les erreurs sporadiques des erreurs persistantes et localiser les pannes des stations (limitation des erreurs). Cela se fait en évaluant statistiquement les situations d'erreur de la station afin de reconnaître les propres défauts de la station et entrée possible dans un mode de fonctionnement où le reste du réseau CAN n'est pas affecté négativement. Cela peut aller jusqu'à ce que la station s'éteigne d'elle-même pour éviter la reconnaissance erronée de messages invalides parmi ceux qui ont été interrompus.

Fiabilité des données du protocole CAN :

La mise en œuvre de systèmes de sécurité dans les voitures est associée à des exigences élevées en matière de fiabilité de la transmission des données. L'objectif est souvent formulé pour garantir qu'aucune situation dangereuse ne se présente pour le conducteur en raison de la communication pendant toute la durée de vie du véhicule.

Cet objectif est atteint si la fiabilité des données est suffisamment élevée ou si la probabilité d'erreur résiduelle est suffisamment faible. Dans le contexte de ces systèmes de bus, la fiabilité fait référence à la capacité d'identifier les données corrompues par des erreurs de transmission. La probabilité d'erreur résiduelle est une mesure statistique de la détérioration de la fiabilité des données : elle détermine la probabilité de corruption des données et le fait que cette corruption passera inaperçue. Le risque d'erreur résiduelle doit être si faible qu'en moyenne, aucune donnée corrompue ne passera inaperçue pendant toute la durée de vie du système.

4. Probabilité d'erreur résiduelle en fonction de la probabilité d'erreur sur les bits

Le calcul de la probabilité d'erreur résiduelle nécessite une classification des erreurs et que l'ensemble du chemin de transmission soit décrit par un modèle. Si l'on définit la probabilité d'erreur CAN résiduelle en fonction de la probabilité d'erreur sur les bits pour des longueurs de message de 80 à 90 bits, pour des configurations de système, par exemple, cinq ou dix nœuds et avec un taux d'erreur de 1/1000 (erreur dans un message sur mille), alors la probabilité maximale d'une erreur de bit est d'environ 0,02 - de l'ordre de 10 ^ -13. À partir de là, le nombre maximal d'erreurs indétectables pour un réseau CAN donné peut être calculé.

Par exemple, si un réseau CAN fonctionne à un débit de données de 1 Mbps, avec une utilisation moyenne de la bande passante du bus de 50 %, avec une durée de vie totale de 4000 heures et une longueur de message moyenne de 80 bits, alors le nombre total de messages transmis est 9x10 ^ 10. Le nombre statistique d'erreurs de transmission non détectées sur la durée de vie est ainsi inférieur à de l'ordre de 10 ^ -2. Ou, pour le dire autrement, avec une autonomie de huit heures par jour pendant 365 jours par an et un taux d'erreur de 0,7 seconde, une erreur non détectée se produit tous les mille ans (moyenne statistique).

Messages CAN au format étendu

Le sous-comité des camions et des autobus de la SAE a normalisé des signaux et des messages ainsi que des protocoles de communication pour divers débits de données. Il est devenu évident que ce type de normalisation est plus facile à mettre en œuvre lorsqu'un champ d'identification plus long est disponible.

Pour soutenir ces efforts, le protocole CAN a été étendu avec l'introduction d'un identifiant de 29 bits. Cet identifiant se compose d'un identifiant existant de 11 bits (ID de base) et d'une extension de 18 bits (ID d'extension). Ainsi, le protocole CAN permet d'utiliser deux formats de messages : StandardCAN (Version 2.0A) et ExtendedCAN (Version 2.0B). Les deux formats devant coexister sur le même bus, il est établi quel message a la priorité la plus élevée sur le bus en cas de collisions d'accès au bus avec des formats de tramage et le même identifiant de base : un message standard est toujours prioritaire sur un message au format étendu.

Les contrôleurs CAN qui prennent en charge les messages au format étendu peuvent également envoyer et recevoir des messages au format standard. Seuls les messages au format standard peuvent être transmis sur l'ensemble du réseau si des contrôleurs CAN sont utilisés sur ce réseau qui ne prennent en charge que le format standard (Version 2.0A). Les messages au format étendu seront mal compris. Cependant, il existe des contrôleurs CAN qui ne prennent en charge que le format standard, mais reconnaissent les messages au format étendu et les ignorent (la version 2.0B est passive).

La distinction entre le format standard et le format étendu se fait à l'aide du bit IDE (bit d'extension d'identifiant), qui est transmis comme dominant dans le cas d'une trame au format standard. Pour les cadres étendus, c'est récessif. Le bit RTR est transmis de manière dominante ou récessive, selon que des données sont transmises ou qu'un message spécifique est demandé à la station. A la place du bit RTR au format standard, le bit SRR (Replace Remote Request) est transmis pour les trames avec identifiants étendus. Le bit SRR est toujours transmis comme récessif pour s'assurer que, lorsqu'il est vérifié, la trame standard a toujours la priorité de bus sur la trame étendue lorsque les deux messages ont le même identifiant de base.

Contrairement au format standard, dans le format étendu, le bit IDE est suivi d'un numéro d'identification de 18 bits, d'un bit RTR et d'un bit réservé (r1).

Tous les champs suivants sont identiques à la norme. La correspondance entre les deux formats est assurée par le fait que les contrôleurs CAN prenant en charge le format étendu peuvent également échanger des données au format standard.

5. Trame de message pour le format étendu (spécification CAN 2.0A)

Implémentations du protocole CAN

La communication est identique pour toutes les implémentations du protocole CAN. Cependant, il existe des différences quant à la mesure dans laquelle la mise en œuvre effectue la transmission des messages des microcontrôleurs qui la suivent dans le circuit. La communication est identique pour toutes les implémentations du protocole CAN. Cependant, il existe des différences dans la façon dont le message transmis par les microcontrôleurs qui le suivent dans le circuit est mis en œuvre.

Contrôleur CAN avec tampon intermédiaire

Les contrôleurs tampon CAN (anciennement appelés puces basicCAN) implémentent en tant que matériel la logique nécessaire pour générer et vérifier le flux binaire conformément au protocole. Cependant, l'administration des jeux de données à émettre et à recevoir, en particulier le filtrage de réception, est réalisée uniquement par le contrôleur CAN.

En règle générale, les contrôleurs CAN avec un tampon intermédiaire ont deux tampons de réception et un tampon de transmission. Les registres de code et de masque à 8 bits permettent un filtrage d'acceptation limité (ID 8 MSB). Une sélection appropriée de ces valeurs de registre permet de lire des groupes d'identifiants ou, dans des cas limites, de sélectionner tous les identifiants. Si plus de 8 ID-MSB sont nécessaires pour différencier les messages, le microcontrôleur suivant le contrôleur CAN dans le circuit doit compléter le filtrage d'acceptation avec un logiciel.

Les contrôleurs CAN tampon peuvent transférer une charge importante vers un microcontrôleur à filtre de réception, mais ils ne nécessitent qu'une petite surface de puce et peuvent donc être fabriqués à moindre coût. En principe, ils peuvent recevoir tous les objets du réseau CAN.

Contrôleur CAN avec stockage d'objets.

Les objets CAN sont principalement composés de trois composants : un identifiant, un code de longueur de données et une charge utile réelle.

Les contrôleurs CAN de stockage d'objets (anciennement appelés fullCAN) fonctionnent comme des contrôleurs CAN tampons, mais gèrent également des objets spécifiques. Lorsqu'il y a plusieurs demandes simultanées, elles déterminent, par exemple, quel objet doit être soumis en premier. Ils effectuent également un filtrage d'acceptation sur les objets entrants. L'interface vers le prochain microcontrôleur correspond à la RAM. Les données à transmettre sont écrites dans la zone RAM correspondante, les données reçues sont lues à partir de la zone RAM, respectivement. Le microcontrôleur n'a besoin de contrôler que quelques bits (par exemple, une demande de transfert).

Les contrôleurs CAN de stockage d'objets sont conçus pour gérer la charge maximale du microcontrôleur local. Cependant, ces contrôleurs CAN nécessitent une plus grande surface de matrice et sont donc plus chers. De plus, ils ne peuvent administrer qu'un nombre limité de puces (microcontrôleurs).

Les contrôleurs CAN sont disponibles aujourd'hui qui combinent les deux principes de mise en œuvre. Ils ont un stockage d'objets, dont au moins un est conçu comme un tampon intermédiaire. Pour cette raison, il n'est plus logique de faire la différence entre basicCAN et fullCAN.

Contrôleurs esclaves CAN pour les fonctions E/S.

Tout comme les contrôleurs CAN qui prennent en charge toutes les fonctions du protocole CAN, il existe des puces CAN qui ne nécessitent pas le prochain microcontrôleur à suivre. Ces puces CAN sont appelées SLIO ( connexion série entrée sortie). Les puces CAN sont des esclaves et doivent être contrôlées par un maître CAN (microcontrôleur central, principal du réseau).

Connexion CAN physique

Les débits de données (jusqu'à 1 Mbit/s) nécessitent une pente d'impulsion suffisamment forte qui ne peut être réalisée qu'à l'aide d'éléments de puissance. En principe, plusieurs connexions physiques sont possibles. Cependant, les utilisateurs et les fabricants du groupe CAN in Automation recommandent d'utiliser des schémas de pilotes conformes à la norme ISO 11898.

Des circuits intégrés de pilote intégrés conformes à la norme ISO 11898 sont disponibles auprès de plusieurs sociétés (Bosch, Philips, Siliconix et Texas Instruments). L'International Users and Manufacturers Group (CiA) définit également plusieurs liaisons mécaniques (câbles et connecteurs).

6. Connexion CAN physique selon ISO 11898

Bien cordialement, traduction assurée par l'équipe de l'atelier

L'interface réseau CAN (Controller Area Network) a été développée en 1987. (version 1.0) par BOSCH et INTEL pour la création de systèmes multiprocesseurs temps réel embarqués. La dernière spécification d'interface 2.0, développée par BOSCH en 1992, est un ajout à la version précédente. ISO 11898 (pour les applications à grande vitesse) et ISO 11519-2 (pour les applications à faible vitesse) sont enregistrées auprès de l'Organisation internationale de normalisation.

Principe d'opération

CAN est une interface réseau hautement intégrée pour la transmission de données jusqu'à 1 Mbit/s. Les appareils du système CAN sont connectés via un bus composé de 3 fils (2 fils de signal et un commun) (voir Fig.).

Les messages de données transmis depuis n'importe quel nœud via le bus CAN peuvent contenir de 1 à 8 octets. Chaque message est marqué d'un identifiant unique dans le réseau (par exemple : « Chauffage jusqu'à 240 », « Panne chauffage », « Bunker chargé », etc.). Lors de la transmission, d'autres nœuds du réseau reçoivent le message et chacun d'eux vérifie l'identifiant. Si le message est lié à ce nœud, alors il est traité, sinon il est ignoré. Le contrôleur CAN de chacun des appareils peut traiter plusieurs identifiants en même temps (par exemple, les contrôleurs SIEMENS et INTEL peuvent en traiter jusqu'à 15). Ainsi, dans chacun des appareils, vous pouvez facilement organiser plusieurs canaux "virtuels" d'échange d'informations avec divers appareils, y compris des canaux de réception simultanée de messages.

Figure. 1. Connexion des appareils via le bus CAN

Identifiants

L'identifiant détermine le type et la priorité du message. Une valeur d'identifiant numérique inférieure correspond à une valeur de priorité supérieure. Un message avec une priorité plus élevée est envoyé avant un message avec une priorité plus faible. Un message avec une priorité plus élevée est suivi d'un message avec une priorité plus faible, si aucun message avec une priorité plus élevée n'apparaît lors de la transmission, alors un message avec une priorité encore plus faible est envoyé, etc.

Bus physique

Représente paire torsadée(blindé ou non blindé) et fil commun. Une paire plate (câble de type téléphone) fonctionne également bien, mais est plus sensible aux sources de bruit externes.

Grande fiabilité

Pour garantir un fonctionnement sans problème dans des conditions difficiles conformément à la norme ISO11898, le contrôleur CAN assure le fonctionnement du réseau dans les cas suivants :

• l'un des 3 fils du bus est cassé,
• n'importe quel fil - court-circuité au pouvoir,
• tout fil est court-circuité à un fil commun.

Si 2 fils sont rompus, une partie des fonctions du système principal peut être implémentée dans chacun des sous-systèmes créés par la rupture.

Flexibilité du réseau et facilité d'extension

Le schéma de transmission des messages adopté dans le réseau CAN offre de grandes opportunités pour la création, l'extension et la modernisation des systèmes.

De nouveaux appareils destinés à recevoir des données peuvent être ajoutés au réseau sans modifier ceux existants outils logiciels si leur connexion n'entraîne pas un dépassement de la capacité de charge et de la longueur maximale du bus. Dans le même temps, les nouveaux périphériques réseau peuvent échanger des informations entre eux sans perturber les performances ancien système si de nouveaux identifiants ont été utilisés dans le protocole d'échange.

Dans le réseau CAN, il est possible de transmettre simultanément des messages à plusieurs appareils à la fois. Cette fonction permet aux signaux de synchronisation d'être transmis dessus.

Arbitrage bus CAN

Dans n'importe quel système, certains paramètres changent plus rapidement que d'autres. Par exemple, la vitesse du rotor d'un moteur a tendance à changer en moins de temps que sa température corporelle ou la position de l'amortisseur. Les paramètres changeant rapidement doivent être transmis plus fréquemment et nécessitent donc une priorité plus élevée. Pendant le fonctionnement, des alarmes peuvent également apparaître, qui doivent être transmises avec la plus haute priorité (par exemple, dépassement de la température admissible, solénoïde de contrôle ouvert, court-circuit dans le circuit, etc.).

Les nœuds du réseau CAN sont des pairs en échange, et chacun d'eux peut à tout moment avoir un message qui nécessite une transmission immédiate. La probabilité d'une demande de transmission simultanée de divers appareils n'est pas inhabituel, mais se produit régulièrement. Pour résoudre un tel conflit, un mécanisme de mise en file d'attente rapide des messages est requis. Pour cela, le système CAN utilise Arbitrage binaire non destructif.

La priorité d'un message CAN est déterminée par la valeur binaire de son identifiant.

La valeur numérique de chaque identifiant de message est attribuée lors de la phase initiale de conception du système. L'identifiant avec la valeur d'identifiant numérique la plus faible a la priorité la plus élevée. Le transfert d'un zéro logique via le bus CAN s'effectue par un message courant, et l'état d'une unité logique est déterminé par l'absence de courant. En cours de transmission, chacune des sources de message, qui a un besoin de transmission, commence à transmettre son identifiant, tout en le vérifiant sur la ligne. Si une discordance est détectée pendant la transmission (c'est-à-dire un zéro « supplémentaire »), alors l'émetteur qui a détecté cette discordance arrête de transmettre son identifiant et passe en réception. Dans ce cas, il n'y a pas de conflit sur le bus, puisque la valeur d'un bit de niveau logique un n'est pas réellement transmise, et par conséquent, le message de priorité la plus élevée traverse le bus comme s'il était le seul une. Le prochain cycle de bus enverra un message avec une priorité inférieure, et ainsi de suite. Cela permet d'obtenir une bande passante de bus maximale et une latence minimale pour les messages chauds.

Figure. 2. Connexion des appareils via CAN-bus

Détection d'erreur

CAN contient un mécanisme de détection d'erreur en 5 étapes :

• contrôle de redondance cyclique (CRC),
• contrôle du champ de bits transmis,
• le contrôle du signal "Confirmation de Réception",
• surveiller le niveau logique des bits,
• contrôle de remplissage de bits.

Contrôle de redondance cyclique (CRC)

Chaque message transmis contient un code de contrôle (CRC) calculé par l'émetteur sur la base du contenu du message transmis. Les nœuds récepteurs effectuent une opération similaire, marquent les erreurs détectées et définissent les indicateurs appropriés.

Surveillance du niveau de bit logique

Tout émetteur surveille et compare automatiquement le niveau logique réel des bits sur le bus avec le niveau qu'il transmet. Si les niveaux ne correspondent pas, une erreur de niveau de bit logique est signalée.

(Remarque : ce mécanisme est également utilisé dans l'arbitrage de bus pour déterminer la priorité d'un message, cependant, une erreur dans ce cas, bien sûr, ne se produit pas).

Contrôle du champ de bits transmis

Dans le cadre des messages CAN, des modèles de bits prédéfinis sont transmis, qui sont surveillés à la réception. Si le récepteur détecte un bit invalide dans l'une de ces combinaisons, alors l'indicateur d'erreur de format est positionné.

Contrôle de remplissage de bits

CAN utilise une technique de bits de remplissage pour contrôler davantage les messages transmis. Après avoir transmis cinq bits consécutifs de même niveau, l'émetteur insère automatiquement un bit de valeur opposée dans le train de bits. Les destinataires du message suppriment automatiquement ces bits avant de traiter le message. Si un sixième bit de la même polarité est détecté, alors une erreur de bourrage de bits est signalée.

Contrôle du signal "Acquittement de réception"

Chaque message transmis est acquitté par le récepteur, et si ce n'est pas le cas, le drapeau d'erreur d'accusé de réception est positionné.

Indicateur d'erreur

Si une erreur est détectée, le nœud qui a détecté l'erreur interrompt la transmission en envoyant un indicateur d'erreur. Dans ce cas, l'émetteur réinitialise automatiquement la transmission du message, ce qui empêche tous les nœuds de provoquer des erreurs et assure la cohérence des données dans le réseau.

Compte tenu de l'action de tous les mécanismes de contrôle, la valeur réelle de l'apparition d'une erreur non détectée dans le système CAN est de 10-11.

Format de message CAN

Le protocole CAN standard (version 2.0A) prend en charge le format de message avec des identifiants 11 bits (Message Standard).

Le protocole CAN étendu (version 2.0B) prend en charge les formats d'identifiant 11 bits et 29 bits (message étendu).

La plupart des contrôleurs de la version 2.0A transmettent et reçoivent uniquement des messages au format standard, bien que certains d'entre eux ne puissent recevoir que des messages au format étendu.

Les contrôleurs de la version 2.0B peuvent envoyer et recevoir des messages dans les deux formats.

Différences de format

Dans la version 2.0B, le champ bits d'identifiant comporte deux parties.

Première partie(la partie principale de l'identifiant) fait onze bits pour une compatibilité avec la version 2.0A, la deuxième partie de- dix-huit bits (extension d'identifiant) donnant une longueur totale d'identifiant de vingt-neuf bits.

Les bits d'extension d'identifiant (IDE) et de demande à distance de substitution (SRR) dans le champ d'arbitrage sont utilisés pour faire la distinction entre les formats.

CAN (Control Area Network) est une dorsale série qui connecte des périphériques d'entrée/sortie intelligents, des capteurs et des actionneurs d'un certain mécanisme ou même d'une entreprise dans un réseau. Il se caractérise par un protocole qui permet de trouver plusieurs appareils maîtres sur l'autoroute, assure la transmission de données en temps réel et la correction d'erreurs, et une immunité élevée au bruit. Le système CAN est équipé d'un grand nombre de microcircuits qui permettent le fonctionnement d'appareils connectés au bus, dont le développement a commencé par BOSH pour une utilisation dans les automobiles, et qui sont maintenant largement utilisés dans l'automatisation industrielle. Le brochage du connecteur est indiqué sur la figure.

• Conçu pour l'organisation de canaux de communication très fiables et à faible coût dans les systèmes de contrôle distribués. L'interface est largement utilisée dans l'industrie, l'énergie et les transports. Permet de construire à la fois des canaux multiplex bon marché et des réseaux haut débit.
• Le taux de transfert est défini dans le logiciel et peut aller jusqu'à 1 Mbps. L'utilisateur choisit le débit en fonction de la distance, du nombre d'abonnés et de la capacité des lignes de transmission.

• Nombre maximal abonnés connectés à cette interface est en fait déterminé par la capacité de charge des émetteurs-récepteurs appliqués. Par exemple, lors de l'utilisation d'un émetteur-récepteur PHILIPS PCA82C250, il est de 110.
• Le protocole CAN utilise système d'origine adresser des messages. Chaque message est fourni avec un identifiant qui définit la finalité des données transmises, mais pas l'adresse du destinataire. Tout récepteur peut répondre à un ou plusieurs identifiants. Plusieurs récepteurs peuvent répondre à un même identifiant.
• Le protocole CAN dispose d'un système avancé de détection et de signalisation des erreurs. A ces fins, le contrôle bit par bit, le remplissage direct du train de bits, la vérification du paquet de message avec un polynôme CRC, le contrôle de la forme du paquet de message, la confirmation de la bonne réception du paquet de données sont utilisés. Intervalle de Hamming d = 6. La probabilité globale d'erreur non détectée est de 4,7x10 -11.
• Le système d'arbitrage du protocole CAN élimine la perte d'informations et de temps en cas de "collisions" sur le bus.
• L'interface utilisant le protocole CAN est facilement adaptable au support physique de transmission des informations. Il peut s'agir d'un signal différentiel, d'une fibre optique, d'un simple collecteur ouvert, etc. L'isolation galvanique est facile à faire.
• La base d'éléments qui prend en charge CAN est largement disponible dans la conception industrielle.

Le contrôleur CAN inclus dans le STM32 MC est un nœud CAN complet qui répond aux exigences des appareils CAB 2.0A et 2.0B actifs et passifs et prend en charge le transfert de données à une vitesse ne dépassant pas 1 Mbit/s. Le contrôleur CAN est également équipé de capacités supplémentaires pour organiser la transmission de données déterministe à l'aide d'un protocole de transmission en temps réel CAN spécial TTCAN. Après l'activation de la fonction TTCAN, la retransmission automatique des messages et l'insertion automatique de deux octets supplémentaires dans le paquet CAN avec une heure fixe de transmission des messages seront prises en charge. Toutes ces capacités sont requises dans les systèmes de contrôle CAN en temps réel.

Le nom complet du contrôleur CAN est module bxCAN, où bx indique que le module prend en charge des fonctionnalités supplémentaires. Un module CAN conventionnel utilise un tampon de transmission et de réception, tandis qu'un module CAN étendu utilise plusieurs tampons de transmission et de réception. Le module bxCAN est un hybride des deux architectures de module CAN. Il dispose de trois boîtes aux lettres pour les messages à envoyer et de deux boîtes aux lettres pour les messages reçus. Chacune des boîtes aux lettres réceptrices possède une FIFO pour y placer trois messages. Cette architecture est un compromis en termes de performances de transfert de données et d'espace dans la puce IC.

Le module CAN est équipé de trois boîtes aux lettres pour la transmission des messages et a la capacité d'insérer automatiquement l'heure actuelle dans le message en utilisant le protocole TTCAN

La prochaine fonction importante du contrôleur CAN est le filtrage des messages reçus. Puisque CAN est un bus de diffusion, chaque message transmis est reçu par tous les nœuds du bus. Un bus CAN d'un degré de complexité raisonnable transporte un assez grand nombre de messages. La tâche de chaque CPU connectée au nœud CAN est de répondre aux messages CAN. Ainsi, afin d'épargner au contrôleur CAN le problème de la réception de messages indésirables dans le buffer, leur filtrage est nécessaire. Le contrôleur CAN STM32 MCU dispose de 14 bancs de filtres qui peuvent être utilisés pour bloquer tous les messages CAN, à l'exception de certains messages ou groupes de messages.

14 filtres de messages prennent en charge deux configurations qui peuvent être utilisées pour filtrer des messages individuels

Chaque banc de filtres se compose de deux registres de 32 bits et peut fonctionner dans l'un des quatre modes. Avec la méthode de base, un ID de message est écrit dans chaque registre de banque de filtres. Après l'arrivée du message, son identifiant est vérifié et, sur cette base, une décision est prise d'accepter ou de rejeter le message. Ce mode prend en charge deux configurations. Dans la première configuration, les registres du banc de filtres sont de 3 bits et peuvent être utilisés pour filtrer les champs ID de message de 11 et 29 bits, ainsi que les bits RTR et IDE en mode 16 bits.

Dans la seconde configuration, l'identifiant du message est écrit dans le premier registre de 32 bits, et le masque de message est écrit dans le second. Le registre de masque marque les bits du registre d'identifiant comme "importants" ou "sans importance". Cela permet de recevoir un groupe de messages à l'aide d'un banc de filtres. Si les filtres de réception transmettent le message, un pointeur vers le filtre correspondant sera écrit avec la FIFO de réception. Cela permet à l'application d'accélérer l'identification du message sans avoir à lire et déchiffrer l'identifiant du paquet de message.

Tous les contrôleurs CAN prennent en charge deux modes de fonctionnement : le mode normal pour la réception et la transmission de paquets de messages et le mode d'initialisation pour la définition des paramètres de communication. Comme déjà mentionné, les MCU STM32 peuvent fonctionner en mode économique SLEEP. Dans ce mode, la synchronisation du module bxCAN est désactivée, mais l'accès aux registres des boîtes aux lettres est toujours possible. Le module bxCAN a la capacité d'activer le fonctionnement dès détection d'activité sur le bus CAN. Il peut également être réactivé par le programme d'application. En fonctionnement normal, deux sous-modes supplémentaires sont pris en charge. Le premier sous-mode est le mode SILENCE. Dans celui-ci, le contrôleur CAN peut recevoir des messages, mais ne peut pas transmettre et ne génère pas de bits d'erreur lors de l'envoi et de l'acquittement des messages. Ce mode est conçu pour les bus CAN avec surveillance passive. Le deuxième sous-mode est le mode LOOPBACK. Dans ce mode, les messages transmis sont immédiatement reçus dans le tampon de réception. Il est nécessaire à la mise en œuvre des fonctions de diagnostic et est également utile dans la phase de débogage du code du programme. Les deux modes considérés peuvent être combinés. Ils sont idéaux pour exécuter des fonctions d'autotest lorsqu'ils sont connectés à un bus sous tension.

L'idée de CAN a été proposée pour la première fois au milieu des années 1980 par la société allemande Robert Bosch, qui l'a conçue comme un moyen rentable de combiner des contrôleurs situés à l'intérieur d'une voiture. La méthode traditionnelle de connexion des contrôleurs répartis sur l'objet avec des faisceaux de câbles par sa complexité technique, par les paramètres de prix et de poids pour un tel produit de masse, qu'est une voiture, s'est avérée inadaptée. Une solution alternative était nécessaire pour réduire le nombre de fils, c'est pourquoi le protocole CAN a été proposé, pour lequel n'importe quelle paire de fils est suffisante.

L'idée était de créer solution réseau pour les systèmes distribués fonctionnant en temps réel. Initialement, CAN a été utilisé dans les voitures, mais son champ d'application s'est ensuite étendu aux problèmes d'automatisation des processus technologiques.

CAN offre un niveau élevé de protection des données contre les dommages, même en cas de travail dans des conditions difficiles (fortes interférences), tout en atteignant un taux de transfert de données suffisamment élevé (jusqu'à 1 Mbit / s). Un avantage important de CAN est que le concepteur du système peut influencer la priorité des messages afin que les plus importants n'attendent pas dans la file d'attente pour être envoyés. Cette propriété de CAN permet de construire des réseaux prenant en charge le temps réel.

Le degré élevé et la fiabilité du réseau dus aux mécanismes développés pour détecter et corriger les erreurs, l'auto-isolement des nœuds défectueux, l'insensibilité à un niveau élevé d'interférences électromagnétiques offrent au réseau le champ d'application le plus large.

Parmi les nombreux facteurs qui ont assuré la montée en popularité du CAN ces dernières années, il faut noter la diversité de la base d'éléments CAN et son faible coût.

Un rôle important est joué par la capacité à prendre en charge différents types de supports de transmission de données physiques - de la paire torsadée bon marché à la fibre et à la radio. Un certain nombre de mécanismes originaux d'interaction réseau (multi-maîtrise, diffusion, arbitrage au niveau du bit) en combinaison avec un taux de transfert de données élevé (jusqu'à 1 Mbit/s) contribuent à la mise en œuvre efficace du mode temps réel dans les systèmes de contrôle distribués .

Topologie du réseau CAN.

Dans toute mise en œuvre de CAN - le support (support physique de transmission de données) est interprété comme l'éther, dans lequel les contrôleurs fonctionnent comme récepteurs et émetteurs. Dans le même temps, après avoir commencé la transmission, le contrôleur n'interrompt pas l'écoute de l'air, en particulier, il surveille et contrôle le processus de transmission des données actuelles transmises par lui. Cela signifie que tous les nœuds du réseau reçoivent simultanément des signaux transmis sur le bus. Il n'est pas possible d'envoyer un message à un nœud particulier. Tous les nœuds du réseau reçoivent tout le trafic transmis sur le bus. Cependant, les contrôleurs CAN offrent la capacité matérielle de filtrer les messages CAN.

Le réseau CAN est destiné à la communication de ce qu'on appelle des nœuds. Chaque nœud se compose de deux composants. Il s'agit du contrôleur CAN lui-même, qui assure l'interaction avec le réseau et implémente le protocole, et le microprocesseur (CPU).

Les contrôleurs CAN sont connectés à l'aide d'un bus comportant au moins deux fils CAN_H et CAN_L, à travers lesquels les signaux sont transmis à l'aide d'émetteurs-récepteurs IC spécialisés. De plus, les circuits intégrés des émetteurs-récepteurs implémentent des fonctions de service supplémentaires :

• Ajustez la vitesse de balayage du signal d'entrée en faisant varier le courant d'entrée.
• Le circuit de limitation de courant intégré protège les sorties du transmetteur contre les dommages en cas d'éventuels courts-circuits des lignes CAN_H et CAN_L avec les circuits de puissance, ainsi que contre une augmentation de tension à court terme sur ces lignes.
• Protection thermique interne.
• Mode basse consommation, dans lequel les récepteurs continuent de signaler l'état du bus au contrôleur de sorte que lorsque des signaux d'information sont détectés sur le bus, il puisse amener les émetteurs-récepteurs en fonctionnement normal.

Les plus répandus sont deux types d'émetteurs-récepteurs :

• Émetteurs-récepteurs « haut débit » (ISO 11898-2),
• Émetteurs-récepteurs "à tolérance de pannes"

Les émetteurs-récepteurs fabriqués conformément à la norme "High-Speed" (ISO11898-2) sont les plus simples, les moins chers et offrent la possibilité de transférer des données à des vitesses allant jusqu'à 1 Mbit/s. Les émetteurs-récepteurs "Fault-Tolerant" (insensibles aux dommages sur le bus) vous permettent de construire un réseau basse consommation hautement fiable avec des débits de données ne dépassant pas 125 kbps.

Couche physique du canal CAN.

La couche physique du protocole CAN détermine la résistance du câble, le niveau des signaux électriques dans le réseau, etc. Il existe plusieurs couches physiques du protocole CAN (ISO 11898, ISO 11519, SAE J2411). Dans la grande majorité des cas, la couche physique CAN est définie dans la norme ISO 11898.

ISO 11898 définit une ligne différentielle à deux fils avec une impédance (terminateurs) de 120 ohms comme support de transmission (des fluctuations d'impédance entre 108 ohms et 132 ohms sont autorisées.

La vitesse maximale du réseau CAN conformément au protocole est de 1 Mbit/s. A une vitesse de 1 Mbit/sec, la longueur maximale du câble est d'environ 40 mètres. La limitation de la longueur du câble est associée à la vitesse de propagation du signal final et au mécanisme d'arbitrage au niveau du bit (pendant l'arbitrage, tous les nœuds du réseau doivent recevoir le bit de transmission actuel en même temps, le signal doit avoir le temps de se propager le long de en un seul échantillon de temps dans le réseau.

Le rapport entre la vitesse de transmission et la longueur maximale du câble est donné dans le tableau : vitesse de transmission longueur maximale du réseau 1000 Kbps 40 mètres 500 Kbps 100 mètres 250 Kbps 200 mètres 125 Kbps 500 mètres 10 Kbps 6 kilomètres.

Les connecteurs pour le réseau CAN ne sont toujours PAS NORMALISÉS. Chaque protocole de haut niveau définit généralement son propre type de connecteurs pour le réseau CAN.

Le zéro logique est enregistré lorsque le signal sur la ligne CAN_H est supérieur à celui de la ligne CAN_L.
Unité logique - dans le cas où les signaux CAN_HI et CAN_LO sont identiques (différent de moins de 0,5 V).
L'utilisation d'un tel schéma de transmission différentielle permet d'exploiter le réseau CAN dans des conditions extérieures très difficiles.
Un zéro logique est appelé bit dominant et un un logique est appelé bit récessif. Ces noms reflètent la priorité du 1 logique et du zéro sur le bus CAN.

Avec transmission simultanée au bus, le journal. zéro et un, seul le zéro logique (signal dominant) sera enregistré sur le bus, et le un logique sera supprimé (signal récessif).

Arbitrage bus CAN.

La vitesse du réseau CAN (jusqu'à 1 Mbit/s) est atteinte grâce au mécanisme d'arbitrage de bus non destructif en comparant les bits des messages concurrents. Ceux. s'il arrive que plusieurs contrôleurs commencent à émettre en même temps, alors chacun d'eux compare le bit qui va être transmis au bus avec le bit que le contrôleur concurrent essaie de transmettre au bus. Si les valeurs de ces bits sont égales, les deux contrôleurs essaient de transmettre le bit suivant. Et cela se produit jusqu'à ce que les valeurs des bits transmis soient différentes. Maintenant, le contrôleur qui a transmis un zéro logique (signal de priorité plus élevée) continuera à transmettre, et l'autre (autre) contrôleur interrompra sa transmission jusqu'à ce que le bus soit à nouveau libre. Bien entendu, si le bus est actuellement occupé, le contrôleur ne commencera à émettre qu'une fois relâché.

Cette spécification CAN suppose que tous les contrôleurs CAN reçoivent des signaux du bus en même temps. Ceux. en même temps, le même bit est reçu par tous les contrôleurs du réseau. D'une part, cet état de fait permet un arbitrage bit à bit, et d'autre part, il limite la longueur du bus CAN. Le signal se propage le long du bus CAN à une vitesse énorme, mais finale, et pour que CAN fonctionne correctement, il est nécessaire que tous les contrôleurs "l'entendent" presque simultanément. Presque, car chaque contrôleur accepte un bit pendant un certain laps de temps, compté par l'horloge système. Ainsi, plus le débit en bauds est élevé, plus la longueur du bus CAN est courte.

Structure de format de transfert de données.

Les données sur le réseau CAN sont envoyées sous forme de trames séparées dans un format standard. Les champs les plus importants sont le champ identifiant et les données elles-mêmes.

L'identifiant sert de nom unique pour le type de message et définit qui le recevra et comment le prochain champ de données sera interprété. Ce qu'est exactement (arithmétiquement) ce nombre, dans le cas général, n'a pas d'importance. Cet adressage contextuel présente plusieurs avantages pour les réseaux à petite échelle. Cela rend la mise à niveau aussi facile que possible. Étant donné que les contrôleurs décentralisés ne sont en aucun cas interconnectés logiquement, l'ajout d'un nouvel élément au système n'affectera en aucune manière le comportement de tous les autres.

Il semble plus intéressant d'utiliser les identifiants comme principal outil utilisé dans la procédure de résolution des collisions. Dans CAN, la priorité des messages est utilisée comme critère principal pour analyser les collisions, pour décider à qui donner de l'air. Si plusieurs stations ont commencé à émettre en même temps, et qu'une collision s'est produite, une superposition des identifiants transmis se produit. Les identifiants sont séquentiellement, bit à bit, en partant du plus élevé, superposés les uns aux autres et dans leur "confrontation" celui qui a la valeur arithmétique la plus faible de l'identifiant, ce qui signifie que la priorité est la plus élevée, l'emporte. Un "zéro" dominant supprimera les uns et dans tous les cas, à la fin de la transmission du champ identifiant, il deviendra égal à la valeur de priorité la plus élevée. Ainsi, le système permet au niveau de la conception (et de la définition de l'identifiant) pour tout message du système de prédéterminer sa priorité en service.

La priorité du message est ainsi déterminée par la valeur de l'identifiant. Plus l'identifiant est bas, plus la priorité est élevée. En règle générale, le contrôleur permet uniquement de spécifier ces deux champs. Les autres champs sont utilisés pour transférer des données spécifiques nécessaires au fonctionnement du CAN.

Formats de cadre.

Les données dans CAN sont transmises dans des télégrammes courts d'un format standard. Il existe quatre types de messages dans CAN :

• Trame de données
• Cadre à distance
• Cadre d'erreur
• Cadre de surcharge

Trame de données est le type de message le plus couramment utilisé. Il se compose des parties principales suivantes : le champ d'arbitrage définit la priorité d'un message lorsque deux ou plusieurs nœuds tentent simultanément de transmettre des données au réseau.

Le domaine de l'arbitrage, quant à lui, comprend :

• pour la norme CAN-2.0A, identifiant 11 bits + RTR 1 bit (retransmission)
• pour la norme CAN-2.0B, identifiant 29 bits + RTR 1 bit (retransmission)

Il est à noter encore une fois que le champ identifiant, malgré son nom, n'identifie pas en lui-même un nœud du réseau ou le contenu du champ de données.

Pour une trame de données, le bit RTR est toujours mis à zéro logique (signal dominant). Le champ de données contient 0 à 8 octets de données Le champ CRC contient la somme de contrôle de 15 bits du message, qui est utilisée pour détecter les erreurs Slot d'accusé de réception (1 bit), chaque contrôleur CAN qui reçoit un message correct envoie un bit d'accusé de réception au réseau . Le nœud qui a envoyé le message écoute ce bit, et si la confirmation n'est pas reçue, il répète la transmission. Si le slot d'acquittement est reçu, le nœud émetteur peut seulement être sûr qu'au moins un des nœuds du réseau a bien reçu son message.

Cadre à distance est une trame de données sans champ de données et avec le bit RTR défini (1 - bits récessifs). L'objectif principal de la trame distante est l'initiation par l'un des nœuds du réseau de la transmission de données vers le réseau par un autre nœud. Ce schéma vous permet de réduire le trafic réseau total. Cependant, dans la pratique, Remote Frame est rarement utilisé maintenant (par exemple, dans DeviceNet, Remote Frame n'est pas du tout utilisé).

Cadre d'erreur est un message qui viole clairement le format du message CAN. La transmission d'un tel message conduit au fait que tous les nœuds du réseau enregistrent une erreur dans le format de la trame CAN, et à leur tour transmettent automatiquement la trame d'erreur au réseau. Le résultat de ce processus est la retransmission automatique des données vers le réseau par le nœud émetteur. La trame d'erreur se compose d'un champ d'indicateur d'erreur, qui est de 6 bits de la même valeur (et donc la trame d'erreur viole le contrôle de bourrage de bits, voir ci-dessous), et d'un champ de délimiteur d'erreur, qui est de 8 bits récessifs. Le délimiteur d'erreur permet à d'autres hôtes sur le réseau d'envoyer leur indicateur d'erreur au réseau lors de la détection d'une trame d'erreur.

Cadre de surcharge- répète la structure et la logique de la trame Erreur, à la différence qu'elle est utilisée par un nœud surchargé, qui pour le moment ne peut pas traiter le message entrant, et demande donc la retransmission des données à l'aide de la trame Surcharge. Actuellement, le cadre Overload n'est pratiquement pas utilisé.

Mécanisme de gestion des erreurs.

La fiabilité du réseau CAN est également déterminée par les mécanismes de détection d'erreurs. La norme CAN définit les méthodes suivantes pour détecter les erreurs dans le réseau CAN :

• Vérifier la surveillance des bits
• peu de farce
• Vérification du cadre
• Reconnaissance Vérifier
• Vérifier le CRC

Vérifier la surveillance des bits- chaque nœud, tout en transmettant des bits au réseau, compare la valeur du bit transmis avec la valeur du bit qui apparaît sur le bus. Si ces valeurs ne correspondent pas, le nœud génère une erreur de bit. Bien entendu, lors de l'arbitrage du bus (envoi du champ d'arbitrage vers le bus), ce mécanisme de contrôle d'erreur est désactivé.

peu de farce- lorsqu'un nœud transmet 5 bits de même valeur séquentiellement au bus, alors il ajoute le sixième bit de valeur opposée. Les nœuds de réception suppriment ce bit supplémentaire. Si un nœud détecte plus de 5 bits consécutifs avec la même valeur sur le bus, il génère une Stuff Error.

Vérification du cadre- certaines parties d'un message CAN ont la même signification dans tous les types de messages. Ceux. le protocole CAN définit exactement quels niveaux de tension et quand doivent apparaître sur le bus. Si le format du message est violé, les nœuds génèrent une erreur de formulaire.

acquittement Vérifier- chaque nœud, ayant reçu le bon message sur le réseau, envoie un bit dominant (0) au réseau. Si cela ne se produit pas, le nœud de transmission enregistre une erreur d'accusé de réception.

Contrôle CRC- chaque message CAN contient une somme de CRC, et chaque nœud de réception calcule la valeur de CRC pour chaque message reçu. Si la valeur CRC calculée de la somme ne correspond pas à la valeur CRC dans le corps du message, le nœud récepteur génère une erreur CRC.

Chaque nœud du réseau CAN, pendant le fonctionnement, essaie de détecter l'une des cinq erreurs possibles. Si une erreur est détectée, le nœud envoie une trame d'erreur au réseau, détruisant ainsi tout le trafic réseau actuel (envoi et réception du message actuel). Tous les autres nœuds détectent la trame d'erreur et prennent les mesures appropriées (jettent le message reçu).

De plus, chaque nœud gère deux compteurs d'erreurs :

• Compteur d'erreurs de transmission(compteur d'erreurs de transmission) et
• Compteur d'erreurs de réception(Compteur d'erreurs de réception).

Ces compteurs augmentent ou diminuent selon plusieurs règles. Les règles de gestion des compteurs d'erreurs en elles-mêmes sont assez complexes, mais elles se résument à un principe simple, une erreur de transmission entraîne une augmentation du compteur d'erreurs de transmission de 8, une erreur de réception augmente le compteur d'erreurs de réception de 1, toute transmission correcte / la réception d'un message diminue le compteur correspondant de 1. Ces règles conduisent à ce que le compteur d'erreurs d'émission du nœud émetteur augmente plus rapidement que le compteur d'erreurs de réception des nœuds récepteurs. Cette règle correspond à l'hypothèse qu'il est hautement probable que le nœud émetteur soit la source d'erreurs.

Chaque nœud de réseau CAN peut être dans l'un des trois états. Lorsqu'un nœud est démarré, il est dans un état Erreur active. Lorsque la valeur d'au moins un des deux compteurs d'erreurs dépasse la limite de 127, le nœud entre dans l'état Erreur passive. Lorsque la valeur d'au moins un des deux compteurs dépasse la limite de 255, le nœud passe à l'état Bus Off.

Un nœud dans l'état Erreur active envoie des drapeaux d'erreur active au réseau si une erreur est détectée sur le bus. Les drapeaux d'erreur actifs se composent de 6 bits dominants, donc tous les nœuds l'enregistrent.

Un nœud dans l'état d'erreur passive envoie des drapeaux d'erreur passive au réseau lorsqu'une erreur est détectée sur le réseau. Les drapeaux d'erreur passifs se composent de 6 bits récessifs, de sorte que le reste des nœuds du réseau ne le remarque pas, et les drapeaux d'erreur passifs ne font qu'augmenter le compteur d'erreurs du nœud.

Un nœud dans l'état Bus Off ne transmet rien au réseau (pas seulement des trames d'erreur, mais pas d'autres du tout).

Adressage et protocoles haut niveau

Cependant, les services réseau de la spécification CAN Robert Bosch 2.0A/B et de la norme internationale ISO 11898 sont souvent clairement insuffisants pour le développement efficace des réseaux CAN. Le fait est que les documents mentionnés ne décrivent que les deux niveaux les plus bas du modèle de référence (à sept niveaux) de l'interconnexion des systèmes ouverts OSI/ISO, physique et canal. Les formats des messages, les processus de transfert de données jusqu'à 8 octets, les mécanismes de détection d'erreurs, certains paramètres physiques du support de transmission de données (uniquement dans ISO 11898), etc. ont été déterminés.
Mais "en coulisses", il y a des moments aussi importants au stade du développement que l'adressage des nœuds, la répartition des identifiants CAN entre eux, l'interprétation du contenu de la trame de données, la transmission de données de plus de 8 octets, etc.

Dans CAN, il n'y a pas d'adressage explicite des messages et des nœuds, les messages n'ont pas d'adressage explicite du récepteur. La source met son identifiant et ses données sur le bus, et le récepteur indépendamment, en fonction des tâches à résoudre, traite les données reçues de cette source, ou les ignore.
CAN ne spécifie nulle part que le champ Identification + RTR doit être utilisé comme identificateur de message ou de nœud. Ainsi, les identifiants de message et les adresses d'hôtes peuvent être trouvés dans n'importe quel champ du message (dans le champ d'arbitrage ou dans le champ de données, ou les deux).

D'autre part, la norme de protocole prévoit une demande de données à distance (RTR). Contrairement à la description précédente, le récepteur n'attend pas que les données nécessaires apparaissent, mais demande les données au nœud requis.

De même, le protocole n'interdit pas l'utilisation du champ d'arbitrage pour la transmission de données.

La norme CAN ne réglemente pas la manière dont des applications spécifiques transmettront leurs données spécifiques sur le réseau CAN. Donc il est nécessaire d'utiliser une sorte de protocole de niveau supérieur. Vous pouvez créer votre propre protocole qui permettrait aux applications de fonctionner avec le réseau CAN de manière simple et pratique, mais cela ne vaut guère la peine s'il existe déjà de nombreux protocoles de haut niveau basés sur la technologie CAN. De plus, ce sont des protocoles ouverts, c'est-à-dire vous pouvez obtenir des spécifications toutes faites et même participer au développement ultérieur de ces systèmes.

Par conséquent, avec le début de la production en série de composants CAN et la large diffusion des applications CAN, un certain nombre d'entreprises indépendantes et d'associations à but non lucratif dans le domaine des systèmes d'automatisation industrielle, des transports, etc., ont été (et continuent à ce jour) travailler à la création et à la standardisation des spécifications des protocoles de niveau supérieur HLP (Higher Level Protocol) pour les réseaux CAN.

L'utilisation du champ d'arbitrage et du champ de données, ainsi que la répartition des adresses de nœuds, des identificateurs de message et des priorités dans le réseau font l'objet des protocoles dits de couche supérieure (HLP).

Le nom HLP reflète le fait que le protocole CAN ne décrit que les deux couches inférieures de la référence modèle de réseau ISO / OSI, et le reste des couches sont décrits par les protocoles HLP.

À ce jour, plus de quatre douzaines de CAN HLP sont connus. Parmi une telle variété de CAN HLP, les plus courantes, en particulier dans les systèmes d'automatisation industrielle, sont quatre prises en charge par la CiA, à savoir :

• CAL / CANopen,
• Royaume de CAN,
• DeviceNet et

CAL / CANopen

Le développement et la maintenance d'un protocole de couche d'application ouvert pour les réseaux d'automatisation industrielle était l'un des objectifs prioritaires de la création de l'organisation CiA en 1992. La base d'un tel protocole était le HLP développé par Philips, après révision et amélioration par le groupe de travail CiA, la spécification CAL CAN Application Level (CiA DS 20x) a été publiée en 1993.

Les applications CAN en réseau basées sur la couche d'application CAL sont actuellement utilisées avec succès dans l'électronique médicale, les systèmes de contrôle du trafic, les transports et les équipements industriels. Le résultat de l'ajout de CAL (plus précisément, une partie de son sous-ensemble) avec un système de profils (périphériques, interfaces, applications, etc.) et des spécifications de la couche physique (types de connecteurs, règles de quantification des bits, etc.) a été l'émergence d'un standard plus "spécifique" pour le protocole CANopen... CANopen est essentiellement une couche d'application CAL. CANopen était à l'origine destiné aux réseaux de contrôle des machines en mouvement dans les systèmes d'automatisation industrielle.
Cependant, le protocole a par la suite trouvé des applications dans la médecine, l'électronique marine, les transports et les systèmes d'automatisation des bâtiments. CANopen est basé sur deux couches de la norme CAN (ISO 11898, Bosch CAN Specification 2.0 A/B). En plus des spécifications de couche physique ISO 11898 (support de transmission différentiel à deux fils), CANopen contient ses propres règles de quantification des bits et définit également trois types de connecteurs recommandés. L'affectation des broches pour tous les types de connecteurs permet d'alimenter les émetteurs-récepteurs d'unités avec isolation galvanique. Huit grades de débits de transmission de données sont définis dans le réseau CANopen : 1 Mbit/s, 800 kbit/s, 500, 250, 125, 50, 20 et 10 kbit/s. La prise en charge de 20 kbps est obligatoire pour tous les modules.

CAN Royaume

Le protocole de la société suédoise KVASER-AB (www.kvaser.se) occupe une place particulière parmi CAN HLP en raison du concept original de mise en réseau et de l'efficacité des applications CAN basées sur celui-ci.

Le début des travaux sur la première version (troisième actuelle) du protocole CAN Kingdom en 1990 a été précédé par les nombreuses années d'expérience de l'entreprise dans le domaine de la création de systèmes de contrôle distribués. Le protocole a été spécialement développé pour contrôler les machines en mouvement et les mécanismes des robots industriels, des machines textiles, des appareils hydrauliques mobiles, et vous permet d'atteindre des performances élevées en temps réel tout en répondant à des exigences de sécurité strictes.

CAN Kingdom est également à la base de la norme militaire américaine CDA 101 et est largement utilisé dans les équipements militaires, des bateaux pneumatiques et des systèmes de ciblage aux chasseurs et missiles supersoniques. L'objectif principal de la création du protocole était de fournir au développeur du système une liberté maximale dans la mise en œuvre de ses idées lors de la construction d'un réseau, tout en conservant la possibilité d'utiliser des modules standard de fabricants indépendants. CAN Kingdom n'est pas un protocole « prêt à l'emploi » au sens où il l'est, par exemple, par rapport à des standards tels que CANopen ou DeviceNet. Il s'agit plutôt d'un ensemble de primitives de métaprotocoles qui peuvent être utilisées pour "assembler" un protocole pour un réseau spécifique de modules. Cela permet d'obtenir une combinaison unique de facilité d'intégration de modules prêts à l'emploi avec un degré élevé de "proximité" du protocole d'origine. La pierre angulaire du concept de réseautage de CAN Kingdom est que les modules MSN servent le réseau, par opposition au réseau NSM sert les modules dans les réseaux informatiques.

Il n'y a pas de débits en bauds recommandés sur le réseau CAN Kingdom. Mais dans les 200 premières ms après la mise sous tension, le nœud doit s'accorder pour écouter sur le bus à une vitesse de 125 kbps. Des spécifications de couche physique autres que l'ISO 11898 sont acceptables.

DeviceNet

DeviceNet est un protocole développé et publié en 1994 par Allen-Bradley (www.ab.com) de Rockwell Corporation puis sous-traité à ODVA (Open DeviceNet Vendor Association Inc., www.odva.org) spécialement organisé pour le prendre en charge.

DeviceNet est une solution peu coûteuse, simple et efficace pour combiner une variété de dispositifs d'automatisation industrielle tiers en un seul système : capteurs photo, thermiques, démarreurs, lecteurs de codes-barres, éléments IHM de clavier, panneaux d'affichage, ainsi que des dispositifs de contrôle PLC, ordinateurs , etc. Lors de l'élaboration du protocole, en plus de réduire le coût, il s'agissait également de simplifier et d'unifier le diagnostic de tels dispositifs. Les premiers appareils répondant à la spécification DeviceNet sont apparus sur le marché au début de 1995. DeviceNet repose également sur les deux couches inférieures de la norme CAN, complétées par des spécifications de supports physiques plus détaillées que les autres HLP.

Le réseau DeviceNet a une topologie de bus de dérivation. Le support physique de transmission est un câble à 4 fils (CAN_H, CAN_L, Vcc, Terre), et il existe deux types possibles : épais (diamètre extérieur 12,2 mm) et fin (6,9 mm). Seuls trois débits de données sont définis, 125, 250 et 500 kbps.

Une caractéristique importante du réseau DeviceNet est la possibilité d'alimenter les modules directement à partir du câble réseau (24 V, jusqu'à 8 A sur un câble épais), et il est également possible d'utiliser plusieurs alimentations en tout point du bus. Tout cela permet de construire un réseau autonome, indépendant de la disponibilité ou de la qualité de l'alimentation externe, et, si nécessaire, facilitera le démantèlement et le redéploiement du système sur un nouvel emplacement.

Le réseau DeviceNet permet le branchement et le débranchement à chaud des modules. La norme DeviceNet contient également une description détaillée de nombreux types d'adaptateurs, de répartiteurs (simple et multiport), de connecteurs (Mini, Micro), de prises réseau, etc. Lors de la description de l'organisation des types de données, du comportement réseau des modules dans DeviceNet, un objet modèle orienté est utilisé.

Le nombre maximum de nœuds sur un réseau DeviceNet est de 64.

SDS (Système Distribué Intelligent)

FDS développée par Honeywell Inc. (Division Micro Switch, www.honeywell.sensing.com). Avec la norme DeviceNet, SDS est une autre solution économique et complète pour le contrôle en réseau de capteurs et d'actionneurs intelligents à partir d'un contrôleur central (API, ordinateur) dans les systèmes d'automatisation industrielle. En termes d'exhaustivité depuis les spécifications de l'environnement physique jusqu'à la couche application, en se concentrant sur la réduction des coûts, la norme SDS ressemble à DeviceNet. Une topologie de bus est un bus de ligne (joncteur ou circuit) avec des dérivations courtes.

Deux types de câblage de base sont définis :

• Câble mini (utilisé lors de l'assemblage du tronc réseau) à 4 fils avec une charge de courant maximale de 8 A, connecteur à 5 broches et
• Micro (pour connecter des appareils physiques au réseau) Câble 4 fils, 3 A, connecteur 4 broches sans contact séparé pour le blindage du câble.

Dans un réseau SDS, le câblage conventionnel utilisant des connecteurs à bornes ouvertes est également autorisé. Tous les types de câblage et de connecteurs, ainsi que dans le réseau DeviceNet, assurent la tension d'alimentation des nœuds.

Un réseau SDS nécessite toujours un seul gestionnaire de réseau maître au moins pendant la phase de mise sous tension pour régler automatiquement le débit en bauds des modules. Dans le processus d'exploitation du réseau, il est permis d'avoir plusieurs maîtres sur le bus, mais ils doivent fonctionner dans leurs domaines d'adresses, et lorsque le réseau est allumé, un seul d'entre eux peut assumer la fonction de gestionnaire de réseau pour l'auto -réglage de la vitesse des appareils.