La carte Satellite V1 (1)

Principes fondateurs

. Par : bobyAndCo, Dominique, Jean-Luc, Thierry. URL : https://www.locoduino.org/spip.php?article242

Début 2018, l’équipe qui anime LOCODUINO a entrepris de développer un démonstrateur de plusieurs technologies permettant la mise en œuvre de la gestion automatique d’un réseau DCC. Ce démonstrateur, le LOCODUINODROME [1], a été présenté au 16e salon international du train miniature à Orléans les 10 et 11 novembre 2018. Plusieurs éléments intéressants et réutilisables ont été développés et cette série d’articles se propose de présenter l’un d’entre eux, le Satellite V1, du point de vue des principes fondateurs d’abord, puis sa réalisation matérielle et logicielle, ainsi que son API pour l’intégration avec un gestionnaire de réseau.

Dans un réseau DCC piloté automatiquement, c’est à dire permettant de gérer le cantonnement en modulant la vitesse des locomotives, en commandant la position des appareils de voie et en pilotant une signalisation réaliste, il est nécessaire de combiner plusieurs éléments :

  • un système généralement centralisé qui, à partir des informations sur la position des engins roulants, sur la position des appareils de voie et sur une représentation informatique de la structure du réseau, va déterminer l’état des signaux et calculer les vitesses des locomotives. Appelons ce système « le Gestionnaire » ;
  • une électronique d’alimentation des rails et de commande des locomotives en DCC ;
  • une électronique et une mécanique de commande des appareils de voie (aiguillages, TJS, TJD) ;
  • une électronique de commande des signaux (lumineux, mécaniques) ;
  • une électronique de détection de la présence des engins roulant en des points stratégiques du réseau (rétrosignalisation).

Choix de l’architecture électronique

Traditionnellement dans un système DCC, l’électronique de commande des appareils de voie et des signaux est également connectée au bus DCC. Ces dispositifs sont donc équipés de décodeurs qui fonctionnent sur un principe similaire à ceux des locomotives. Et, par conséquent, les ordres de positionnement de ces équipements sont donc également transmis via des trames DCC.

Le bus DCC étant unidirectionnel [2] la transmission des informations de détection nécessite un second bus, le S88 en est un exemple.

Ces différentes électroniques sont distinctes. Il faudra généralement un boitier pour piloter quelques appareils de voie, un boitier pour piloter quelques signaux, un boitier pour détecter la présence par consommation de courant, un boitier pour détecter la présence par barrière infrarouge, etc. Le résultat est que le coût financier devient rapidement important et que la densité de l’électronique et du câblage croît également rapidement.

On voit donc que des dispositifs électroniques dédiés à une seule fonction, commande de servomoteurs, commande de signaux, etc, ne sont peut-être pas la meilleure solution, même si cette fonction est implémentée plusieurs fois (4 fois le plus souvent). De plus, ces technologies ont relativement peu évolué depuis une quarantaine d’années et elles peuvent aujourd’hui être avantageusement supplantées par les équipements disponibles en DIY.

Lors de nos réflexions, nous avons conclu qu’il était préférable de réunir plusieurs fonctions sur une seule carte électronique. Cette dernière pourrait à la fois piloter des signaux et des appareils de voie et aussi détecter la présence des engins roulant. Il était aussi très intéressant d’avoir, autant que faire se peut, un seul type de carte qui soit configurable pour s’adapter à un grand nombre de situations. L’idée de la carte Satellite était née.

Le bus DCC quant à lui, si il est indispensable au pilotage des locomotives, peut avantageusement être remplacé par un bus bidirectionnel servant à la fois à la commande et à la rétro-signalisation. Le bus CAN, déjà présenté dans Locoduino, est un bus industriel largement déployé dans différent domaines comme l’automobile, l’avionique ou le spatial. C’est un choix naturel pour plusieurs raisons :

  • la disponibilité de contrôleurs bon marché qui s’interfacent à l’Arduino sur le SPI ;
  • un débit, de 125kbits/s à 1Mbits/s, très suffisant même pour un grand réseau ;
  • la capacité de connecter jusqu’à 112 nœuds sur le même bus.
  • la robustesse de la communication avec l’incorporation de code de correction d’erreur permettant de détecter jusqu’à 5 erreurs de transmission [3] dans une trame ; le contrôleur procédant à la re-émission de manière autonome ;
  • la facilité de mise en œuvre et la disponibilité de bibliothèques matures ;
  • le mode de communication par diffusion qui permet d’ajouter facilement des dispositifs, comme un TCO, sans construire une communication dédiée à ce dernier.

L’architecture générale

L’architecture générale de l’électronique d’un réseau ferroviaire représentée à la figure 1 sépare, en bas, ce qui touche au réseau (engins roulant, actionneurs et détecteurs) de ce qui touche au pilotage, en haut, dont les 3 blocs (poste de conduite, TCO et gestionnaire) peuvent être combinés de différentes manières, ce qui n’est pas le sujet de cette série d’article mais qui représente ce que nous avons mis en œuvre à Orléans.

Figure 1 : Architecture du Locoduinodrome
Figure 1 : Architecture du Locoduinodrome

Le bus CAN (filaire) interface le haut et le bas, avec, optionnellement une couche TCP (WiFi (sans fil) ou Ethernet (filaire)).

Communication : événements ou états ?

Sur une architecture distribuée comme celle que nous vous présentons, on peut communiquer de deux manières et pour illustrer ceci nous allons considérer la communication entre le Gestionnaire et un Satellite pour la manœuvre d’une aiguille et la communication inverse pour que le Satellite rende compte au Gestionnaire de la position effective de l’aiguille.

La première manière consiste à réaliser une communication ponctuelle qui n’est réalisée que lorsqu’il y a un changement d’état (considéré donc comme un événement) : le Gestionnaire désire que l’aiguille change de position et il envoie donc de manière ponctuelle cette demande, via le réseau, au Satellite qui manœuvre l’aiguille. En retour, le Satellite envoie un acquittement lorsque l’aiguille s’est effectivement déplacée.

La seconde manière consiste à réaliser une communication via des états et de manière répétitive. Dans ce cas, le Gestionnaire communique de manière périodique l’état désiré de l’aiguille et le Satellite responsable de l’aiguille reçoit périodiquement cet état et la manœuvre de manière à ce que sa position corresponde à l’état. De la même manière, le dispositif émet périodiquement l’état de l’aiguille. On parle également de communication par variables rafraichies.

La première manière a l’avantage de la sobriété, deux messages seulement sont échangés mais elle possède également deux sérieux inconvénients :

  1. si un message est ponctuellement perdu, l’ordre sera perdu. Il faudra donc gérer cela du côté du Gestionnaire : vérifier que les messages d’acquittement sont arrivés, mettre en place un mécanisme de time-out pour émettre de nouveau le message après un certain temps sans acquittement, etc ;
  2. si un Satellite est débranché puis branché ou s’il est redémarré pour une raison quelconque, par exemple parce qu’on vient de flasher une nouvelle version du logiciel, il faudra émettre de nouveau tous les messages permettant de le remettre dans l’état où il était avant d’être redémarré.

On voit là tout l’intérêt du second mode de communication : les variables d’états représentant l’état du réseau : position des aiguilles, occupation et feux, sont diffusées périodiquement. Si un message est perdu ponctuellement, cela ne se traduira que par un petit retard dans l’actualisation de l’état global et le message suivant remettra les choses en ordre. Si l’un des dispositifs est redémarré, il réacquiert automatiquement son état et débrancher ou redémarrer un Satellite peut se faire à chaud et sans complication.

Bien évidemment ceci a un coût en communication mais ce coût reste raisonnable. Prenons par exemple 100 Satellites sur un bus CAN permettant de communiquer à 100m de distance avec un débit de 500kbits/s. Deux messages d’états transitent entre le Gestionnaire et chaque Satellite. Dans le pire cas, c’est à dire en considérant des trames CAN de longueur maximum, ces deux messages additionnés occupent le bus 540µs et par conséquent, la communication entre le Gestionnaire et 100 Satellites nécessite 54ms. On voit donc que la marge est confortable.

Le principe d’indépendance (relative) des entités du système de pilotage

On peut déduire de la figure 1 que chaque entité fait son travail dans son coin c’est à dire réalise des actions en fonctions des états reçus d’une autre entité et ces actions engendrent des changements d’état qui sont envoyés à d’autres entités.

  • la centrale DCC génère le signal DCC pour la traction (vitesse, direction) et les fonctions des engins roulant sur les voies. Elle reçoit les états désirés des locomotives du gestionnaire et les traduit en commandes DCC quand c’est le gestionnaire qui commande les locomotives. Elle envoie les états des commandes des opérateurs au gestionnaire quand cette centrale dispose de ses propres manettes : on parle de souhaits de vitesse dans ce cas et on peut se trouver en mode double commande. Si la centrale gère les accélérations et les ralentissements, il est indispensable que le gestionnaire connaisse la vitesse réelle à tout instant ;
  • le TCO affiche une représentation graphique du réseau, des appareils de voie et des engins roulants à partir des états des capteurs : détection d’occupation, franchissement de balise et position effective des aiguilles, transmis par les Satellites d’une part et l’état voulu des aiguilles et l’état des feux transmis par le Gestionnaire d’autre part ;
  • le Gestionnaire possède une modélisation du réseau et maintient un ensemble de paramètres décrivant l’état de tous les éléments (occupations, libérations, états des aiguilles, itinéraires, état des trains, etc..). Il commande les appareils de voie et la centrale DCC pour assurer la sécurité. Il gère les signaux. Il reçoit les états de tous les appareils et émet les états souhaités ;
  • le poste de pilotage anime une interface utilisateur de commande d’un ou plusieurs trains (manette, curseur, ..) et affiche le signal vu par le conducteur en bout de canton. Il est donc piloté par le Gestionnaire et lui envoie des souhaits de vitesse de train ;
  • Chaque Satellite, enfin, lit les capteurs qui lui sont associés, émet les états correspondant, reçoit les états souhaités des aiguilles et des feux du Gestionnaire et manœuvrent les aiguilles et les signaux en fonction.

Bien entendu il n’y a pas une seule forme de réalisation imposée de chaque entité, à part le fait qu’elle embarque au moins un Arduino et un programme. Il peut exister dans cette architecture plusieurs formes de réalisation de centrale DCC, de gestionnaire, une seule de chaque en principe, mais plusieurs possibles de TCO, de poste de conduite et de satellites.

Nous avons voulu garder toute la souplesse de réalisation qui permette de choisir sa façon de réaliser chaque entité.

Mais surtout, nous avons une architecture matérielle distribuée qui permet de minimiser le nombre de fils à brancher. Idéalement les seuls fils à courir le long du réseau sont :

  • le feeder du DCC ;
  • le CAN ;
  • l’alimentation 9V.

Tous les autres fils : capteurs, actionneurs, doivent être le plus court possible pour que l’architecture matérielle soit la plus claire possible comme montré à la figure 2.

Figure 2 : Allocation des Satellites sur le Locoduinodrome
Figure 2 : Allocation des Satellites sur le Locoduinodrome
Les Satellites sont figurés par des rectangle verts. Ils sont reliés par le bus CAN et sont connectés à des détecteurs de consommation de courant

, des balises de détection ponctuelles

, des signaux

ou

et des aiguilles

.

Les satellites - principes généraux

Hormis l’idée de faire du Satellite une carte multi-usages, nous avons voulu dès le départ fixer les principes suivants :

  • tous les satellites sont identiques sur le plan matériel (même schéma, mêmes composants). Ils sont placés topologiquement à proximité des appareils à gérer (aiguilles, capteurs, signaux) et selon le nombre et la nature des appareils, un Satellite peut se trouver sous-utilisé ;
  • tous les satellites sont chargés avec le même logiciel pour éviter les erreurs en téléversant un programme unique (seul le numéro du satellite est personnalisé au démarrage) ;
  • comme ils ne sont pas spécialisés, ni sur le plan matériel, ni sur le plan logiciel, mais que leurs fonctions sont hétérogènes, leur spécialisation est faite par le gestionnaire, via le bus CAN. Ces satellites sont des entrées/sorties déportées. Nous avons donc une architecture matérielle extensible à volonté ;
  • pour les gérer, une API sur le gestionnaire définit un ensemble d’objets. Ces objets représentent les objets physiques du réseau (zones, aiguillages, feux, comme des proxy). La façon dont ces objets communiquent avec les nœuds sur le réseau CAN n’est pas du ressort du gestionnaire, il ne voit que l’API Cette même API pourrait servir pour les autres moyens de contrôle du réseau. ;
  • la correspondance entre les entrées-sorties des satellites et les équipements de voie est totalement libre : c’est à dire, par exemple, qu’un feu à 9 ampoules pourrait être géré par 2 Satellites, l’un pour 4 ampoules, l’autre pour 5. Le fait de le voir comme une entité unique est de nature logicielle dans l’API, mais non matérielle ;
  • pas de configuration dans les satellites, ce qui élimine une grande partie de la complexité ;
  • on déploie les satellites sur le réseau ce qui donne un certain nombre de branchements pour les servos, les feux (plusieurs feux par nœud éventuellement) et on branche au plus court. Que telle ou telle LED appartienne à un signal ou à un autre n’est qu’une question de configuration du logiciel qui tourne avec le gestionnaire ;

Les avantages de cette architecture sont multiples :

  • chaque satellite n’a plus à connaître la notion d’objets aiguille, zone ou signal. Il gère seulement des ports. Il synchronise son état régulièrement avec des tables dans le gestionnaire via les messages périodiques qui circulent sur le CAN (dans les 2 sens) ;
  • la spécialisation des feux au niveau d’un satellite n’a pas lieu d’être. Un satellite c’est uniquement des LEDs avec 3 modes : allumé, éteint, clignote. Il n’y a pas de notion de signal dans un satellite. La notion de signal est dans l’API coté gestionnaire et dans la couche qui va traduire l’état d’un signal en états de LED ;
  • tous les types possibles de cibles sont possibles avec cette carte. Les LEDs des signaux sont toutes banalisées : elles auront toutes la même résistance série, l’intensité du signal étant réglée par PWM ;
  • l’application gestionnaire n’a pas à connaitre les formats des messages qui transitent sur le CAN, c’est du ressort de l’API uniquement.

Les évolutions

Cette première version, mise en œuvre sur le démonstrateur présenté à Orléans a permis de montrer la pertinence de l’approche. Mais elle a également été conçue à l’aune du Locoduinodrome et est donc perfectible. Notamment le choix de n’avoir qu’un seul servo et qu’une seule détection par consommation, si elle est adaptée au Locoduinodrome, présente des limites pour des réseaux plus complexes et conduit à un nombre de Satellites excessif et dont une partie des fonctions est inutilisée. Nous avons d’ores et déjà commencé à travailler sur une version 2 plus modulaire et permettant de limiter au minimum les fonctions non utilisées et de rendre le Satellite adaptable au plus grand nombre de situations. Elle disposera également de la possibilité d’identifier (et plus seulement détecter) des locomotives (et/ou des wagons) avec la technologie RFID. Cette seconde version nécessite une configuration qui est la conséquence de la modularisation. En effet, plusieurs fonctions mutuellement exclusives étant possibles, il faut décider de la fonction utilisée.

[1Contraction de LOCODUINO et de LOCODROME

[2Principalement unidirectionnel. On peut envisager de transmettre des informations vers la centrale en associant aux bits 0 et 1 une consommation plus ou moins élevée du dispositif émetteur mais ce mode de fonctionnement est réservé à la programmation des décodeurs, un seul à la fois sur voie de programmation. Il ne peut pas être utilisé pour la rétrosignalisation. Une seconde façon de faire est d’implémenter un système client-serveur où la centrale (le client) interroge un décodeur (le serveur) puis coupe le signal DCC. Le décodeur qui dispose d’une réserve d’énergie pour un court instant, répond sur le bus DCC. Ce système est connu sous le nom de Railcom. Ici aussi le débit est faible.

[35 bits qui auraient une valeur erronée