Auteur Sujet: Les grandes lignes de mon projet d'automate DCC  (Lu 4297 fois)

patrick

  • Newbie
  • *
  • Messages: 43
    • Voir le profil
Les grandes lignes de mon projet d'automate DCC
« le: décembre 23, 2016, 03:23:45 am »
Sur la demande de Dominique, je vous présente mon projet en quelques lignes. Je pourrais en parler longuement, mais je veux avant tout vous donner l'idée générale.

En fait, je pourrais résumer mon projet en trois mots: machine à états. Chaque noeud est une machine à états qui reçoit des évènements, réagit en effectuant une action et renvoie un autre message au système. Jusque là, rien de bien sorcier...

Ensuite: le système est répartit entre plusieurs noeuds, ce qui permet de gérer suffisamment de code sans nécessiter l'utilisation d'un ordi ou un logiciel externe. Pour le moment, j'en suis environ à 1500/1600 lignes de code pour chaque arduino. Et c'est là tout l'avantage de ce système: de petites fonctionnalités un peu partout et finalement tout tient dans quelques arduinos.

Le système fonctionne grâce au CanBus configuré à 500kbit/s. Ce qui est rapide (si on fait le calcul, cela représente quasiment 4000 messages à la seconde). J'ai fait des tests à plus basse vitesse et il y a encore de la marge... Disons que je n'ai pas encore rencontré de situation qui nécessite cette vitesse aussi rapide.

Pour les noeuds: comme je l'ai déjà mentionné sur mon blog, le tout s'organise autour de 4 types de noeuds:
- le DCC, gestionnaire de la position des trains et de la topologie du réseau (rails). Il génère aussi les messages DCC.
- le LOCO, il contient le script de la loco. C'est lui qui va demander au système s'il peut aller de tel à tel canton, demander l'état de la signalisation au modules CANTON, etc...
- le CANTON, il a la responsabilité d'un canton (3 zones de détection) et de la signalisation (2 feux complexes)
- enfin, les autres noeuds: aiguillages, animations, etc...

Un exemple de fonctionnement: un train entre sur une zone, le canton le détecte et met à jour la signalisation. Celui-ci envoie l'info d'occupation au DCC qui sauvegarde la position et autorise la poursuite du script si rien ne s'y oppose. Le module train, une fois entré dans un canton, demande l'état de la signalisation et ajuste sa vitesse en fonction... etc...

A chaque fois, il s'agit d'évènement qui entraine une action puis une réaction (nouveau message...). Le secret: bien manager le principe de message/réponse de façon atomique, et ne pas envoyer plein de messages dans tous les sens et espérant que les noeuds pourront gérer le tout en parallèle... Mon premier prototype semblait "plus intelligent" mais je me retrouvais dans des situations de "dead lock" parce que deux messages attendaient deux réponses simultanées et le système perdait les pédales...

A part cela, mon réseau une fois équipé devrait compter une douzaine de cantons, mais pas tous avec signalisation complète. Certaines branches de manoeuvres n'en utilisant pas.

Voilà, difficile d'en dire plus, ou alors ce serait vraiment beaucoup plus...

Si vous avez des questions sur des détails bien précis, je pourrai essayer d'y répondre.
Au plaisir,
Patrick
« Modifié: décembre 23, 2016, 04:19:57 pm par patrick »

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1081
  • 100% Arduino et N
    • Voir le profil
Re : Les grandes lignes de mon projet d'automate DCC
« Réponse #1 le: décembre 23, 2016, 10:16:11 am »
Merci beaucoup Patrick,

Voilà un projet d'ensemble 100% Arduino comme on les aime, qui va en intéresser beaucoup sur Locoduino.

J'ai passé un moment sur ton blog hier soir et l'explication que tu donnes ici est très claire pour moi parce que j'imagine assez bien ce que font les nœuds, d'autant que tu nous décrits quelque chose que tu as réalisé et qui marche (c'est même une 2ème version).

Je t'encouragerais donc à continuer la description sur Locoduino si tu es d'accord.


Mais c'est Noël d'abord et je te souhaite de bonnes fêtes.
Cordialement
Dominique

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1081
  • 100% Arduino et N
    • Voir le profil
Re : Les grandes lignes de mon projet d'automate DCC
« Réponse #2 le: décembre 26, 2016, 10:37:07 am »
Bonjour Patrick,

Tu dis :
Citer
Chaque noeud est une machine à états qui reçoit des évènements, réagit en effectuant une action et renvoie un autre message au système qui est répartit entre plusieurs noeuds.

Cela sous-entend que tu n'as pas réalisé une modélisation centralisée de ton réseau comme le décrivent Jean-Luc, Pierre59 et DDEF dans cette partie du Forum.

Je suppose (en me trompant peut-être) que chaque noeud correspond à un canton et, dans ce noeud, la connexion aux noeuds adjacents est décrite quelque part pour permettre de suivre les trains et de gérer localement la signalisation.

Ta solution me semble originale et devrait intéresser un certain nombre de modélistes qui pensent aussi "mettre un Arduino par Canton".

Cordialement
Dominique

patrick

  • Newbie
  • *
  • Messages: 43
    • Voir le profil
Re : Les grandes lignes de mon projet d'automate DCC
« Réponse #3 le: décembre 26, 2016, 09:22:20 pm »
Salut,

En fait, oui et non... Le système global n'est pas vraiment centralisé, mais il reste que le module DCC est un peu le point central du système. Beaucoup de messages passent par ce module avant d'être re-dispatcher aux autres modules mais sans sauvegarder d'états particuliers... Aussi, il a la connaissance de toute la topologie du réseau. Il permet quasi-exclusivement de sauvegarder la position des locos ou manager les priorités entre les trains... Dans un sens, c'est un point central, mais il ne connait rien de la signalisation.

Les cantons, quant à eux, sont totalement autonomes. Dès qu'un évènement de zone est détecté, il est "broadcasté" à tous les autres modules cantons afin de mettre à jour la signalisation et au module DCC pour le suivi des trains. Bien évidemment, comme tu le mentionnes, chaque canton a connaissance de ses voisins. Cela évite une fois de plus de passer par le module DCC pour gérer la signalisation.

Pour résumer, je dirais qu'un point important est d'éviter de sauvegarder trop d'états, mais au contraire, d'envoyer des requêtes d'infos auprès des autres modules lorsque nécessaire. Cela augmente le trafic CanBus, mais l'ensemble du système est plus autonome et plus robuste face aux bugs (décalage entre réalité du réseau et états des sauvegardes dans les différents modules). Par exemple, un module Canton A sauvegarde les signaux dont il a le contrôle. Si un voisin B veut mettre à jour ses propres signaux, il lance une requête vers A pour lui demander la position d'un signal et récupère la réponse. DCC n'a aucune connaissance de cet échange.

Voilà, j'espère que cela vous éclaire un peu plus ;-)
Au plaisir, et bonnes fêtes!
Patrick

DDEFF

  • Sr. Member
  • ****
  • Messages: 424
    • Voir le profil
Re : Les grandes lignes de mon projet d'automate DCC
« Réponse #4 le: décembre 27, 2016, 11:27:01 am »
Bonjour Patrick,

Tu pourrais mettre ton lien dans ce fil, pour que ce soit facile d'y accéder ?
Par certains côtés, ça me rappelle la CS90 de JC (dans Loco Revue en 1990  ;)), mais en plus moderne.

Une question :
Tu gères avec le DCC. OK. Normal.
Mais serait-il envisageable de gérer avec une alimentation analogique quelconque ?

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1081
  • 100% Arduino et N
    • Voir le profil
Re : Les grandes lignes de mon projet d'automate DCC
« Réponse #5 le: décembre 27, 2016, 03:11:40 pm »
Bonjour Patrick,

Tes explications sont très claires, mais je te pose encore une question :

Si le canton gère la signalisation, mais pas la traction DCC, comment peux-tu imposer à une loco de respecter un R60 ou un RR30, ou un arrêt devant un sémaphore ?
Il faudrait que le canton puisse envoyer un message à la traction mais s'il ne connait pas le N° DCC de la loco, ce sera difficile !
Ou bien je n'ai pas assez de détails, car je pense que tu as dû le prévoir.

Amicalement
Dominique

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1081
  • 100% Arduino et N
    • Voir le profil
Re : Re : Les grandes lignes de mon projet d'automate DCC
« Réponse #6 le: décembre 27, 2016, 03:13:36 pm »
Tu pourrais mettre ton lien dans ce fil, pour que ce soit facile d'y accéder ?
Par certains côtés, ça me rappelle la CS90 de JC (dans Loco Revue en 1990  ;)), mais en plus moderne.

http://jurasecondairen.blogspot.fr

Ca vaut le coup de tout visiter !

patrick

  • Newbie
  • *
  • Messages: 43
    • Voir le profil
Re : Re : Les grandes lignes de mon projet d'automate DCC
« Réponse #7 le: décembre 27, 2016, 04:54:54 pm »
Une question :
Tu gères avec le DCC. OK. Normal.
Mais serait-il envisageable de gérer avec une alimentation analogique quelconque ?
L'avantage du DCC dans ce cas-là est de centraliser la gestion des messages DCC dans un seul module. Je m'explique: avec l'analogique, il faut alimenter chaque canton au travers de chaque module canton... Du coup, on augmente le trafic de messages et la logique de communication. Cela s'éloigne du modèle que j'ai développé... Gérer la signalisation est faisable mais la traction, je ne suis pas sûr dans l'état. Bref, il faudrait y réfléchir sérieusement...

patrick

  • Newbie
  • *
  • Messages: 43
    • Voir le profil
Re : Re : Les grandes lignes de mon projet d'automate DCC
« Réponse #8 le: décembre 27, 2016, 05:31:04 pm »
Si le canton gère la signalisation, mais pas la traction DCC, comment peux-tu imposer à une loco de respecter un R60 ou un RR30, ou un arrêt devant un sémaphore ?
Il faudrait que le canton puisse envoyer un message à la traction mais s'il ne connait pas le N° DCC de la loco, ce sera difficile !
Ou bien je n'ai pas assez de détails, car je pense que tu as dû le prévoir.
Je me rends compte que si je veux tout expliquer, il faudrait que j'écrive un diagramme d'états complet avec plus de 80 à 100 messages différents... Cela me prendrait un temps certain  :( Je vais donc répondre aux questions au coup par coup... Désolé... Mais ce n'est pas perdu. J'ai le projet de rédiger un petit site web pour décrire complètement mon projet, mais cela reste encore une idée en l'air... En fait, tout le temps que je mets dans la rédaction ne va pas sur le projet. Des fois, je n'ai pas le courage de le faire et je préfère travailler sur mes Arduino  ;)

Ceci étant dit, je retourne à ta question. Une idée du fil de messages (va-et-vient). N'oublie pas que je passe des paramètres dans les messages (par exemple, le loco id ou le zone id...):
- (canton) détection zone & mise à jour de la signalisation & envoi du message au dcc
- (dcc) gestion des positions des locos & envoi d'une requête de vitesse au canton
- (canton) envoi de la directive de vitesse à la loco
- (loco) en fonction de son script et de la signalisation, déduit la vitesse voulue & envoi de la directive au dcc
- (dcc) message DCC

Dans cet exemple, on peut voir que de nombreux messages sont impliqués dans cette résolution (le double en réalité). Et cela se multiplie très rapidement, d'où la grandeur du diagramme d'états... Chaque module a un diagramme d'environ une douzaine d'états, avec plusieurs états ré-entrant... Pour chaque message, il faut aussi considérer sa réponse (ou ACK) ce qui double quasiment le nombre. Etc...

J'espère que cela t'éclairera un peu plus.
Patrick



DDEFF

  • Sr. Member
  • ****
  • Messages: 424
    • Voir le profil
Re : Les grandes lignes de mon projet d'automate DCC
« Réponse #9 le: décembre 27, 2016, 06:46:49 pm »
On a tous le même problème de gérer la rédaction "d'articles" et la programmation  ;D

J'ai lu la quasi totalité de ton blog, qui mérite effectivement le détour...
Il y a de très bonnes choses, c'est sûr.

En fait, avec un Arduino par canton, c'est un peu comme si tu avais un objet C++ par canton, sauf que, là, l'objet, tu peux le tenir dans la main ! ;)

Je note avec bonheur qu'il n'y a finalement que peu de fils sous le plateau, puisque tous les liens sont dans le CAN.
La gestion de la signalisation est finalement totalement indépendante du DCC.

Au travers des messages que tu cites :

Citer
- (canton) détection zone & mise à jour de la signalisation & envoi du message au dcc
- (dcc) gestion des positions des locos & envoi d'une requête de vitesse au canton
- (canton) envoi de la directive de vitesse à la loco
- (loco) en fonction de son script et de la signalisation, déduit la vitesse voulue & envoi de la directive au dcc
- (dcc) message DCC

je remarque un certain mix entre la centralisation et la décentralisation.
Et je pense que, suivant la façon dont on voit les choses, on pourrait changer la programmation en augmentant la décentralisation.

1°) Le décodeur de la loco est du commerce (surtout en N, comme pas mal d'entre nous)

2°) On construit une centrale DCC dont le but est de générer un signal DCC à l'attention des locos, uniquement.
Deux actions possibles sur cette vitesse :
- le conducteur donne une vitesse de consigne (j'aimerais bien rouler à 100 km/h)
- le réseau lui envoie un ordre prioritaire (non, ici, tu ne dois pas dépasser le 30 km/h)

En fait, la centrale DCC n'a aucune raison de savoir où est le train. 8)

Et ce, d'autant plus qu'on va gérer les aiguilles, la signalisation, ... hors DCC, via le CAN.

3°) La gestion de l'occupation, de la signalisation, de la position des aiguilles n'a que faire de l'id DCC du train qu'elle gère.

Le seul qui doive connaitre l'id DCC du train, c'est l'Arduino qui a ce train sur le canton qu'il gère. 8)

C'est juste pour qu'il puisse dire à la centrale : mets le train n°3 à 30 km/h.
Et aussi, pour refiler ce n° DCC de train à l'Arduino qui gère le canton suivant.

Plus je réfléchis, moins je trouve d'arguments à la centralisation des informations.
Je suis presque certain qu'on peut tout décentraliser si on met un Arduino par canton.

A creuser. :-*


patrick

  • Newbie
  • *
  • Messages: 43
    • Voir le profil
Re : Les grandes lignes de mon projet d'automate DCC
« Réponse #10 le: décembre 27, 2016, 07:32:00 pm »
Il faut préciser que j'ai rassemblé le noeud DCC et la centrale DCC dans le même module. Mais on pourrait totalement mettre de côté la messagerie DCC/booster et utiliser une centrale comme le Zephyr que je possède. Ainsi, le module "central" serait un pont vers Loconet.

En fait, la centrale DCC n'a aucune raison de savoir où est le train. 8)

Hmmm... Pas tout à fait. Il te faut un point central pour résoudre les conflits et gérer les trajets (aiguillages)... Par exemple, deux locos demandent l'accès au même canton. Il faut pouvoir gérer les réservations sans propager de nouveaux messages CAN et que la commande reste "atomique". Si tu propages une nouvelle série de messages pour résoudre le conflit (demander où se trouve telle loco sur le réseau) tu risques de laisser passer l'évènement et de te retrouver dans une situation "en retard", les deux locos se retrouvant sur le même canton! etc... Ce n'est peut-être pas très clair, mais si tu essaies de faire le design de cette situation sur le papier, tu arriveras probablement à la même conclusion. En tout cas, tu as raison, cela mérite une petite réflexion...

Aussi, ça peut paraître étonnant, mais on pourrait supprimer totalement le booster central DCC, et mettre un mini booster sur chaque canton (transistor plus petit puisque seul une loco est alimentée). Et là, le seul équipement se résume aux modules cantons pour gérer les messages DCC! On diminue ainsi le trafic Can. C'est la suite de mon projet... Mais je veux d'abord finir et valider la première phase courante. Cela ne supprime pas non plus les noeuds Loco et potentiellement le noeud de résolution de conflits.

J'ai encore pas mal d'idées dans ma boite ;)
Patrick


patrick

  • Newbie
  • *
  • Messages: 43
    • Voir le profil
Re : Les grandes lignes de mon projet d'automate DCC
« Réponse #11 le: décembre 27, 2016, 07:33:54 pm »
Ah, je viens de te relire... Tu dis "centrale"... mais j'ai compris "noeud central"... Ok, tu as raison, la centrale pourrait être supprimée comme mentionné à la fin de mon précédent message...
« Modifié: décembre 27, 2016, 08:05:03 pm par patrick »

DDEFF

  • Sr. Member
  • ****
  • Messages: 424
    • Voir le profil
Re : Les grandes lignes de mon projet d'automate DCC
« Réponse #12 le: décembre 27, 2016, 08:27:42 pm »
Oui, j'ai bien mis "centrale DCC". C'est sûr.
Mais tu n'étais pas loin : je réfléchis à supprimer aussi le nœud central  ::)

Autre idée, très importante pour moi : je propage le n° DCC de canton en canton, avec un canton d'avance.
Dit autrement, un canton peut être occupé "par une source", sans train dedans. Pour être précis "pas encore dedans".
Et, si tu gères comme ça, tu peux anticiper le cas de deux trains allant en sens contraire, y compris la gestion des signaux.

Autre chose :
Pourquoi veux-tu savoir où est la loco ayant le code DCC n°3 ?
Pas pour la signalisation, pas pour l'occupation des voies, pas pour gérer les itinéraires. Toutes ces questions sont globales :
Ex : Sémaphore si le canton suivant est occupé, ... par n'importe quel train.

On ne pourra peut être pas se passer complètement d'un peu de centralisation. Mais ça vaut le coup d'y réfléchir.   :P
« Modifié: décembre 27, 2016, 08:38:30 pm par DDEFF »

patrick

  • Newbie
  • *
  • Messages: 43
    • Voir le profil
Re : Re : Les grandes lignes de mon projet d'automate DCC
« Réponse #13 le: décembre 27, 2016, 08:57:54 pm »
Autre idée, très importante pour moi : je propage le n° DCC de canton en canton, avec un canton d'avance.
Dit autrement, un canton peut être occupé "par une source", sans train dedans. Pour être précis "pas encore dedans".
Et, si tu gères comme ça, tu peux anticiper le cas de deux trains allant en sens contraire, y compris la gestion des signaux.
C'est ce que je fais dans le module central: un canton peut être libre, occupé ou réservé. A y réfléchir, c'est vrai que je pourrais pousser cette logique dans le canton et ne rien laisser dans le module central. Il faudrait que j'approfondisse l'idée.

Citer
Autre chose :
Pourquoi veux-tu savoir où est la loco ayant le code DCC n°3 ?
Pas pour la signalisation, pas pour l'occupation des voies, pas pour gérer les itinéraires. Toutes ces questions sont globales :
Ex : Sémaphore si le canton suivant est occupé, ... par n'importe quel train.
Hmmm... c'est surtout pour gérer les conflits. Mais en développant un peu plus loin l'idée précédente, il est probable de pouvoir supprimer cette info. Par élimination, elle ne doit plus être utile... Encore une fois, à approfondir...

Patrick

DDEFF

  • Sr. Member
  • ****
  • Messages: 424
    • Voir le profil
Re : Les grandes lignes de mon projet d'automate DCC
« Réponse #14 le: décembre 27, 2016, 10:49:25 pm »
Je ne suis pas dépositaire de LA solution. Loin de là. Je ne sais pas où ça mène vraiment.
Mais ton système m'a fait réfléchir tout haut.

Bonne soirée.