REDONDANCE DU MAÎTRE CANOPEN POUR LES TCMS
SYSTÈME DE CONTRÔLE ET DE SURVEILLANCE DES TRAINS (TCMS) DANS LES APPLICATIONS FERROVIAIRES
Cet article technique aborde la mise en œuvre du protocole de communication CANopen Master avec des fonctionnalités de redondance dans les systèmes de contrôle et de gestion embarqués des trains (TCMS). Plus en détail, il vise à démontrer les avantages de l’utilisation simultanée des réseaux CAN ; le protocole CANopen et l’architecture de redondance pour répondre à un niveau élevé de disponibilité et de sécurité requis dans des applications de contrôle/commande telles que les architectures TCMS (Train Control Monitoring System).
Les avantages des protocoles CAN et CANopen dans un système embarqué
Dans tous les systèmes de contrôle/commande, la communication entre le contrôleur et les actionneurs ainsi que les capteurs est un élément clé du succès d’un projet. Aux côtés des technologies Ethernet, les technologies CAN (Controller Area Network), initialement conçues pour répondre aux exigences du marché automobile, ainsi que les protocoles CANopen de haut niveau ont démontré leur robustesse et leur fiabilité pour un coût de mise en œuvre réduit et une faible consommation, offrant ainsi une multitude de possibilités, quelle que soit la zone d’application.
CAN Vs RS Serial Links
Contrairement aux bus historiques et aux protocoles basés sur RS232, ou RS422/485 tels que Modbus RTU et PROFIBUS, voire même MVB, le CAN est un bus qui permet de hiérarchiser les messages sans altérer ni détruire le message envoyé. En effet, les bus série RS232 et RS422/485 permettent des protocoles de type Maître/Esclave, où le Maître « parle » et les Esclaves « écoutent » en répondant un par un… Cette méthode, également appelée « polling », nécessite un cycle dont la durée dépend du nombre d’esclaves et de la quantité d’informations à transmettre.
Le principe de sondage Maître/Esclave
Au contraire, le CAN permet la communication selon le modèle Producteur/Consommateur, où chaque nœud, qu’il soit maître ou esclave, peut parler à tout moment, sans se soucier de l’état du bus.
Cette méthode permet d’obtenir des performances bien meilleures car les collisions de messages sont gérées par le contrôleur CAN, ce qui facilite grandement le travail du développeur.
Producer/Consumer model principle
Le CAN intègre la couche 2 du modèle OSI (couche liaison de données), ce qui n’est pas le cas pour le RS232 et le RS422/485, qui se limitent à la couche 1 (couche physique). En réalité, le RS485 n’est pas un protocole car aucune définition de trame n’existe à ce niveau, contrairement au CAN. Il fournit uniquement les règles de base et la liaison physique pour l’échange de bytes afin de permettre la transmission de messages série sur un bus multipoint. Le contenu du message (les bits sur le bus) est entièrement défini par l’utilisateur. Cela présente un avantage en termes de simplicité, mais en ce qui concerne la compatibilité, cela devient un inconvénient étant donné la multitude de protocoles existants.
Le protocole CANopen
CANopen est une couche d’application de haut niveau (couche 7 du modèle OSI) qui met en œuvre les mécanismes nécessaires pour surveiller un réseau, notamment les messages périodiques (PDO) et non périodiques (SDO). Ainsi, CANopen autorise les communications de type Maître/Esclave, mais également les communications de type Producteur/Consommateur, le tout simultanément !
Avec des liens asynchrones de type RS232/422/485, le concepteur devra élaborer un protocole « propriétaire », ce qui nécessite un temps significatif pour la définition et la mise en œuvre, avec un support pour chaque nœud du bus. Le développement peut prendre un temps considérable et la fiabilité et la robustesse d’un protocole propriétaire pourraient être incertaines !
Exemple d’un message PDO
Le Dictionnaire d'Objets
Une notion fondamentale de CANopen est le dictionnaire d’objets. Ce dictionnaire est utilisé pour informer un superviseur CANopen (ou Maître) des propriétés d’un dispositif, de manière normalisée. Ce mécanisme permet ainsi de modéliser ce dispositif, afin de rendre le matériel indépendant du logiciel de contrôle. L’avantage pour l’utilisateur final est de pouvoir choisir son équipement indépendamment du fabricant.
Pour faciliter cette approche, un travail important a été réalisé par l’organisation à but non lucratif CiA (CAN in Automation) à travers des normes pour des profils d’entreprise : modules d’E/S génériques (CiA 401), commande de mouvement et moteurs (CiA 402), profil pour l’IEC 61131-3 pour l’automatisation industrielle (CiA 405), dispositifs médicaux (CiA 412), systèmes de contrôle pour ascenseurs (CiA 417), systèmes photovoltaïques et éoliens (CiA 437, CiA 406, etc.), systèmes de charge de batteries – BMS – (CiA 418/419), véhicules municipaux (CiA 422) et… le marché ferroviaire également !
Le modèle de référence OSI et CANopen
CANopen et le marché ferroviaire
◆ CiA 421 : Profil d’application CANopen pour les réseaux de contrôle des véhicules ferroviaires
◆ CiA 423 : Profil d’application CANopen pour les systèmes d’entraînement électrique des véhicules ferroviaires
◆ CiA 424 : Profil d’application CANopen pour les systèmes de commande de portes de véhicules ferroviaires
◆ CiA 426 : Profil d’application CANopen pour le contrôle de l’éclairage extérieur des véhicules ferroviaires
◆ CiA 430 : Profil d’application CANopen pour les systèmes d’exploitation auxiliaires des véhicules ferroviaires
◆ CiA 433 : Profil d’application CANopen pour le contrôle de l’éclairage intérieur des véhicules ferroviaires
CANopen et cas d'utilisation de TCMS avec la gamme de produits RIOM de Leroy Automation
RIOM est une unité de commande embarquée avec des fonctionnalités d’entrée/sortie intégrées conçue pour être intégrée aux véhicules ferroviaires en tant qu’unité de commande de véhicule (VCU), un puissant module d’E/S distant ou un automate programmable avancé (PLC).
RIOM est entièrement conforme à la norme EN 50155 pour les systèmes ferroviaires.
Ce cas d’utilisation de TCMS décrit un système complet basé sur un réseau CAN avec le RIOM mettant en œuvre une communication maître CANopen avec une fonction de redondance maître.
Architecture système
Ce cas d’utilisation aborde les fonctionnalités suivantes :
- Communication CANopen : entre VCU1 et VCU2 et CANopen esclave 10 ;
- Redondance maître CANopen du VCU via le réseau CAN : VCU1 et VCU2 ;
- Gestion des processus via les VCU ;
- Lien de maintenance via le réseau Ethernet.
Programmation du VCU
Le banc de travail du PC hôte utilisé pour la programmation du VCU est « STRATON » de Copa-Data : ses principales caractéristiques sont énumérées ci-dessous :
- Programmation des processus dans les langages de l’IEC 61131-3 ;
- Configuration des réseaux à travers un éditeur de bus de terrain ;
- Outils de surveillance en temps réel pour le débogage des projets.
Une liste de projets est affichée dans la zone de travail ci-dessus : trois projets sont disponibles et peuvent être conçus et débogués.
Le projet appelé « VCU1_CAN » est divisé en plusieurs programmes et outils pour gérer différentes fonctionnalités : Démarrage, Redondance du VCU, Communication CAN et CANopen.
Redondance du VCU.
La redondance du VCU est gérée pour permettre une redondance à chaud en cas de défaillance d’un VCU. Dans chaque VCU, deux programmes gèrent le processus de redondance :
- Gestion de la redondance avec le deuxième VCU : programme « REDUND ».
- Ce programme appelle le bloc fonction « VCU_ACTIVITY ».
- Machine d’état d’activité du VCU : bloc fonction « VCU_ACTIVITY ».
Ce bloc fonction permet de calculer l’état du VCU : Démarrage, Veille nominale, Veille dégradée, Actif nominal, Actif dégradé.
CAN & CANopen communication
La communication CAN et CANopen est programmée à travers l’éditeur de configuration de bus de terrain et des programmes structurés :
Éditeur de configuration de bus de terrain.
Tous les messages CAN et CANopen sont configurés à travers l’outil de configuration de bus de terrain STRATON :
Les variables d’échange de données et de diagnostic/contrôle peuvent être définies pour chaque message CAN.
Exemples de messages CAN :
- Les messages CAN avec les identifiants 1 et 2 sont utilisés pour la redondance du VCU entre VCU1 et VCU2 ; chaque VCU envoie un signal de vie (heartbeat) et l’état d’activité de son VCU : ces valeurs sont utilisées dans le programme « REDUND » pour gérer l’état d’activité du VCU.
- Les messages CAN avec les identifiants 18A, 28A sont des messages TPDO reçus du CANopen esclave numéro 10.
- Les messages CAN avec les identifiants 20A, 30A sont des messages RPDO envoyés au CANopen esclave numéro 10 uniquement lorsque le VCU est actif, puis définissent la variable de contrôle du message, telle que la variable « CO_10_CD10A » pour l’identifiant 20A.
- Le message CAN avec l’identifiant 70A est le signal de vie envoyé par le CANopen esclave numéro 10.
Programmes structurés
Plusieurs programmes ont été développés pour gérer les messages définis dans l’éditeur de configuration de bus de terrain :
Programme de gestion des messages CANopen envoyés :
- « CAN_SEND_MESSAGES ». Ce programme est utilisé pour déclencher l’envoi de messages RPDO CANopen aux esclaves CANopen, uniquement si le VCU est dans un état actif. La variable de commande pour l’envoi d’un message CAN est définie dans le message CAN (configuration de bus de terrain).
- Gestion des messages NMT CANopen : programme « REDUND ». Seul le VCU actif enverra les messages NMT et gérera les esclaves CANopen. Appel à une instance de bloc fonction de machine d’état CANopen pour chaque esclave CANopen géré.
- Bloc fonction de machine d’état CANopen : « CAN_NMT_STATE_MACHINE ». Ce bloc fonction permet de gérer les états CANopen pour un esclave CANopen.
Vue de surveillance
Pour le débogage du système, plusieurs outils STRATON sont disponibles : liste des variables, vues de surveillance graphiques, oscilloscope logiciel, séquences de tests, vue de la fenêtre de sortie, et traces d’échantillonnage numérique.
Dans une vue de surveillance graphique, tous les objets peuvent être animés par les valeurs des variables du projet, que ce soit en mode simulation ou en mode en ligne :
Tests
Les trois dispositifs dans le système ont été téléchargés avec leur projet STRATON depuis la liste des projets.
Tous ces dispositifs peuvent être débogués en même temps à travers le banc de travail STRATON ou dans plusieurs instances du banc de travail STRATON :
La communication CAN peut être surveillée via le PC avec un logiciel spécifique de réseau CAN : l’outil utilisé ici est le logiciel « Busmaster ». Un convertisseur USB/CAN est utilisé pour connecter le PC au réseau CAN. Tous les messages CAN et la charge du bus peuvent être surveillés.
Le processus du système peut être surveillé via la vue graphique de STRATON :
EN UN COUP D’ŒIL :
- Les technologies CAN et CANopen permettent de gagner beaucoup de temps dans la conception et la mise en œuvre d’un système « temps réel » qui doit communiquer dans un réseau et où la quantité de données à transmettre est limitée.
- Les mécanismes de supervision et de communication sont fournis, les couches matérielles et logicielles ont prouvé leur efficacité et leur robustesse depuis de nombreuses années.
- CANopen vous permet de bénéficier de profils d’entreprise existants afin de rendre un dispositif reconnaissable par un maître CANopen, ce qui permet également d’économiser du temps de développement et d’intégration.
- Une application écrite pour un système CANopen, ainsi que le matériel CANopen, peut facilement évoluer vers des architectures Ethernet temps réel telles qu’EtherCAT, car CANopen est pris en charge par ces protocoles. Une autre preuve de la maturité et de l’efficacité de cette technologie !
- Des profils d’application CANopen spécifiques existent déjà pour le matériel roulant et peuvent être facilement déployés sur du matériel existant en cas de rétrofit, ou sur de nouveaux projets, toujours dans une optique d’optimisation des coûts.
EN CONCLUSION:
En conclusion, ce communiqué de presse a offert un aperçu complet du rôle central que jouent les technologies CAN (Controller Area Network) et CANopen dans le domaine du Système de Contrôle et de Surveillance des Trains (TCMS) pour les applications ferroviaires.
Pour ceux qui recherchent des informations techniques plus approfondies ou qui souhaitent explorer les subtilités des technologies CAN et CANopen au sein du TCMS, Leroy Automation vous invite à entrer en contact.
