Modélisation logicielle d'un réseau

[Dominique]

Lorsqu'on conçoit un réseau, en plus des rails, des locos et des wagons, du choix DCC ou analogique (PWM), on fait le choix d'une centrale pour commander les convois et les aiguilles. Ensuite on arrive très vite à définir des cantons et choisir des détecteurs de rétrosignalisation pour organiser la circulation des trains avec des règles de sécurité (éviter les rencontres indésirables), installer des feux de signalisation et d'avertissement, gérer des itinéraires avec des gares de départ et d'arrivée, des horaires, des annonces sonores, etc…, tout en se réservant des possibilités de commande manuelle de convois pour des manoeuvres par exemple et pour le plaisir avant tout.

Pour mettre en oeuvre tout ce joli monde, la voie la plus facile, mais la plus onéreuse, consiste à acheter des produits du commerce (centrale, détecteurs, décodeurs) ainsi qu'un logiciel sur PC qui s'occupera de tout (TCO, pilotage, automatismes, cantons, signalisation, ..). L'ennui c'est que les limites du projet sont celles du logiciel.. et du porte-monnaie.

Pour réaliser quelques économies substantielles, on peut réaliser bon nombre des modules nécessaires par soi-même (DIY). Locoduino est là pour cela.

Pour les automatismes de circulation (bloc système, signalisation, itinéraires, ..), la solution du logiciel sur PC (TrainController, iTrain, …) reste tentante mais elle implique la remontée des signaux de rétrosignalisation vers le PC une l'interface entre le PC et la centrale.

Alors pourquoi ne pas tenter de se passer complètement du PC ?

On peut construire un vrai TCO plus agréable à regarder et plus facile à utiliser qu'un écran de PC, avec ses boutons, curseurs, et Leds bien réels. D'accord, il y a beaucoup de fils à souder, mais le résultat en vaut la peine !

Reste enfin le logiciel qui va gérer l'ensemble de la circulation, la rétrosignalisation, la sécurité, la signalisation : Est-ce possible avec un Arduino ?

L'expérience de mes 2 premiers minuscules réseaux m'a conduit à des solutions très spécifiques, pas généralisables vers des réseaux plus grands. Je cherche donc une modélisation logicielle plus sérieuse.

La lecture de quelques documentations des solutions du commerce me conduisent au principe suivant : La rétrosignalisation est caractérisée par un ensemble de procédures et de composants qui permettent à l’unité de commande du TCO de connaître ce qui se passe sur le réseau et, en conséquence, d’exécuter des actions paramètrées associées à ces évènements.

La modélisation ne serait donc qu'un simple (mais énorme) automate qui associe une ou plusieurs actions à chaque événement. Ce qui sous-entend un satané programme de configuration !

Pas si simple : il faut en outre une définition du réseau (cantons, aiguilles, signaux, distances, vitesses limites, priorités) sur laquelle se superpose les positions et les mouvements des trains (donc aussi une définition des trains). Les interactions sont très nombreuses !

Alors connaissez-vous de la littérature pour atteindre ce but, des documents même théoriques ou des bibliothèques logicielles qui pourraient m'aider ?

[DDEFF]

Bonsoir à tous,

Lorsqu'on conçoit un réseau, en plus des rails, des locos et des wagons, du choix DCC ou analogique (PWM), on fait le choix d'une centrale pour commander les convois et les aiguilles. Ensuite on arrive très vite à définir des cantons et choisir des détecteurs de rétrosignalisation pour organiser la circulation des trains avec des règles de sécurité (éviter les rencontres indésirables), installer des feux de signalisation et d'avertissement, gérer des itinéraires avec des gares de départ et d'arrivée, des horaires, des annonces sonores, etc…, tout en se réservant des possibilités de commande manuelle de convois pour des manoeuvres par exemple et pour le plaisir avant tout.

Pour mettre en oeuvre tout ce joli monde, la voie la plus facile, mais la plus onéreuse, consiste à acheter des produits du commerce (centrale, détecteurs, décodeurs) ainsi qu'un logiciel sur PC qui s'occupera de tout (TCO, pilotage, automatismes, cantons, signalisation, ..). L'ennui c'est que les limites du projet sont celles du logiciel.. et du porte-monnaie.

Disons que c'est sûr que c'est la voie (ah ah!) la plus onéreuse. Que ce soit la plus facile n'est, par contre, pas évident.
On présente toujours des cas très simples et, quand on creuse un peu, on se rend compte que la voie classique (DCC + rétro signalisation + logiciel) n'est pas si simple que ça.

De toutes façons, le problème est complexe et, quelque part, même si on le planque, il ressort toujours quelque part.

Pour réaliser quelques économies substantielles, on peut réaliser bon nombre des modules nécessaires par soi-même (DIY). Locoduino est là pour cela.

Oui

Pour les automatismes de circulation (bloc système, signalisation, itinéraires, ..), la solution du logiciel sur PC (TrainController, iTrain, …) reste tentante mais elle implique la remontée des signaux de rétrosignalisation vers le PC une l'interface entre le PC et la centrale.

J'ajouterai CdmRail, gratuit, mais je préfère l'Arduino.

Alors pourquoi ne pas tenter de se passer complètement du PC ?

Oui, bonne idée.

On peut construire un vrai TCO plus agréable à regarder et plus facile à utiliser qu'un écran de PC, avec ses boutons, curseurs, et Leds bien réels. D'accord, il y a beaucoup de fils à souder, mais le résultat en vaut la peine !

Oui !!

Reste enfin le logiciel qui va gérer l'ensemble de la circulation, la rétrosignalisation, la sécurité, la signalisation : Est-ce possible avec un Arduino ?

Oui, heureusement. De nombreux chercheurs sont déjà sur la piste. Les pistes devrais-je dire, d'ailleurs. Parce qu'un tel problème n'a pas qu'une seule solution.

L'expérience de mes 2 premiers minuscules réseaux m'a conduit à des solutions très spécifiques, pas généralisables vers des réseaux plus grands. Je cherche donc une modélisation logicielle plus sérieuse.

La lecture de quelques documentations des solutions du commerce me conduisent au principe suivant : La rétrosignalisation est caractérisée par un ensemble de procédures et de composants qui permettent à l’unité de commande du TCO de connaître ce qui se passe sur le réseau et, en conséquence, d’exécuter des actions paramètrées associées à ces évènements.

La modélisation ne serait donc qu'un simple (mais énorme) automate qui associe une ou plusieurs actions à chaque événement. Ce qui sous-entend un satané programme de configuration !

Disons que, pour résumer, il faut définir ce qui doit vraiment avoir lieu au niveau du canton et ce qui doit vraiment être centralisé. Et ce n'est pas aussi simple que ça.
Qui dit centralisation dit bus et celui qui se détache, c'est le bus CAN. C'est un point qui me parait clair. J'ai moi même essayé plein d'autres idées (plus folles les unes que les autres) et on n'en revient toujours au bus CAN.
Ce qui induit une certaine logique de fonctionnement (des buffers, etc ...) et une gestion des infos bidirectionnelles.

Pas si simple : il faut en outre une définition du réseau (cantons, aiguilles, signaux, distances, vitesses limites, priorités) sur laquelle se superpose les positions et les mouvements des trains (donc aussi une définition des trains). Les interactions sont très nombreuses !

Contrairement à ce que tu penses, la vraie difficulté n'est pas de décrire le réseau (c'est une table), gérer les signaux non plus (les règles sont simples : ça ne dépend que des occupations et des positions d'aiguilles).
Une fois que tu as les signaux, les vitesses maxi sont simples.
Et c'est même rapide à calculer (j'ai 7,5 millisecondes pour 19 cantons et 26 aiguilles).

Pour les distances d'arrêt, la solution classique est de prendre p.ex 4/5 de la longueur de la pleine voie du canton le plus court :
Si le train arrive à fond, à 4/5 de la longueur il est à la vitesse de ralenti. Vitesse qu'il garde jusqu'à la zone d'arrêt où il s'arrête vraiment.
Ce système permet un arrêt toujours au même endroit : au pied du signal.
Une amélioration serait de calculer l'endroit où le train doit commencer à freiner en fonction de sa vitesse initiale. Ce serait plus réaliste. C'est faisable, mais ça commence çà être costaud.
Reste à gérer les itinéraires. Faisable aussi. Plusieurs solutions.

Pour l'instant, ce qui me bloque, c'est de tester comment se font les échanges d'infos sur le bus CAN.

Alors connaissez-vous de la littérature pour atteindre ce but, des documents même théoriques ou des bibliothèques logicielles qui pourraient m'aider ?

Je t'ai joint mon programme. Il tourne sur un Uno, mais il sera mieux sur un Méga (je viens d'en recevoir un). Le plan de réseau correspondant.
C'est une piste parmi d'autres, avant le bus CAN. Et même avant d'avoir un réseau ... :-)
Tu verras les tables et comment elles se remplissent.
Je suis à ta dispo pour en parler.
Mais nos autres intervenants ont certainement bien d'autres idées.

[Thierry]

Joli programme, et joli but !

Comme l'a déjà dit Jean luc il y a quelque temps, la solution des problèmes complexes est souvent de diviser pour régner... A chaque fonctionnalité importante son Arduino. Il ne s'agit pas d'en mettre un par canton, mais un nano peut sans doute gérer quelques cantons, un autre peut gérer plusieurs signaux, etc... Avec un Mega au dessus, voire même un Due pour sa puissance, qui joue les chefs d'orchestre. Un ou plusieurs nano dans le TCO, un pour gérer chaque poignée de pilotage manuel... Tout ce petit monde communicant avec le bus Can qui fait l'unanimité !
C'est le sens de ma démarche actuelle de création de librairies pour chacun de ces usages. Aujourd'hui les accessoires avec UAD et le pilotage DCC et analogique avec DcDccControler en cours de dev. Demain avec la librairie TCO pour... le TCO, et RRS pour la Railroad Rétro Signalisation (nom provisoire...). Et pourquoi pas un programme comme le tien Denis ou s'inspirant du va et vient de Dominique pour tout chapeauter. Beaucoup de travail en perspective quoi...

En tout cas ton programme est impressionnant, et je pense que le monde objet t'apporterai une grosse simplification du code... Mais ça veut dire tout refaire. A réfléchir pour la version 2 !

[Jean-Luc]

Concernant ce qui doit être décentralisé sur les cantons, j’ai choisi de décentraliser la commande de la loco (je suis en analogique) et la détection de présence. La commande des aiguillages est compliquée à décentraliser sur les cantons car on peut avoir plus ou moins d’aiguillages par canton ce qui abouti à un code ou des données spécifiques dans chaque canton et un tas de problème de mantenance dans les mises à jour. Idem pour la signalisation.

Donc :

A) cartes de commande / détection de canton (pour moi une par canton mais il y a beaucoup de fonctions)
B) cartes de commande d’aiguillages
C) cartes de commande de signaux
D) carte de pilotage du réseau
E) carte TCO

Evidemment, en DCC, la carte A peut s’occuper de plusieurs cantons puisqu’elle a juste la détection à faire.

J’utilise 2 bus CAN, 1 pour la traction (cartes A), 1 pour les accessoires (B, C et E)
D doit donc avoir 2 contrôleurs CAN, c’est le cas de l’Arduino DUE.

Les cartes A reçoivent des commandes de D (vitesse de loco, sens de circulation, allumage/extinction des feux, affectation de convoi à un canton). Elle émettent à intervalles réguliers l’état d’occupation en pleine voie et en zone d’arrêt à destination de D. Elle émettent lorsqu’une machine passe d’un canton à l’autre la PWM et la composante intégrale de la loi de commande de manière à synchronise la  commande d’un canton à l’autre.

Les cartes B reçoivent les commandes de D (position des aiguilles) et émettent à destination de D la position effective lue via des fins de course.

Les cartes C reçoivent les commandes de D (signalisation)

La carte D connaît la topologie du réseau.

Elle reçoit de A l’état d’occupation en pleine voie et en zone d’arrêt et de B l’état des aiguillages. Elle reçoit également de E les commandes. Elle envoie à E les information de position des convois et des aiguillages.

La carte D connaît donc l’état global du réseau :
- convois présent, position de chaque convoi ;
- suivi des convois de canton en canton ;
- position des aiguilles.

Elle gère :
- affectation d’un poste de conduite à un convoi ;
- allumage/extinction des feux ;
- anti-collision ;
- positionnement des aiguillages ;
- gestion de la signalisation ;
- mémorisation des caractéristiques de loi de commande de chaque locomotive et envoi de ces caractéristiques aux cantons en fonction du suivi de convois.

Elle exécute :
Les commandes des postes de conduite;
Les commandes du TCO.

Dans les deux cas il y a filtrage : le fait qu’une commande d’un poste de conduite demande à entrer dans un canton occupé par un autre convoi est mis attente. De même le changement de position d’un aiguillage venant du TCO ou d’un poste de conduite alors que cet aiguillage est affecté à un autre convoi est mis en attente ou interdit.

Par la dessus, on peut mettre une circulation automatique en substituant un automate à un poste de conduite.

La carte E gère le TCO : changement de position d’aiguillage, réservation d’un itinéraire, affectation d’un convoi à un poste de conduite. Elle envoie ces ordres à D et reçoit de D le positionnement des convois et les positions des aiguilles.

La logique de fonctionnement n’est pas trop compliquée, il faut juste bien la spécifier et la vérifier.

Les données, par contre, sont touffues et des erreurs peuvent être cachées. Du coup je suis en train de faire un langage pour spécifier la topologie du réseau, affecter les alimentations et les aiguillages, spécifier la longueur des cantons et le graphe de cantons et y accrocher des règles. Un compilateur vérifie la description et génère les structures de données correspondantes. C’est en chantier mais je peux vous en parler plus en détails.

[DDEFF]

Concernant ce qui doit être décentralisé sur les cantons, j’ai choisi de décentraliser la commande de la loco (je suis en analogique) et la détection de présence. La commande des aiguillages est compliquée à décentraliser sur les cantons car on peut avoir plus ou moins d’aiguillages par canton ce qui abouti à un code ou des données spécifiques dans chaque canton et un tas de problème de mantenance dans les mises à jour. Idem pour la signalisation.

C'est la deuxième fois que tu dis "plus ou moins d'aiguillages par canton". J'aimerais que tu précises : tu "prolonges" les rails avec les contacts d'un relais ?
Parce que sinon, il faut bien détecter la présence des trains sur les aiguilles en carte B ?

Donc :

A) cartes de commande / détection de canton (pour moi une par canton mais il y a beaucoup de fonctions)
B) cartes de commande d’aiguillages
C) cartes de commande de signaux
D) carte de pilotage du réseau
E) carte TCO

Evidemment, en DCC, la carte A peut s’occuper de plusieurs cantons puisqu’elle a juste la détection à faire.

Je pense que le Nano de la carte canton peut effectivement gérer plusieurs cantons en DCC.
A mon avis, en DCC, il y a quand même autre chose à gérer au niveau du canton : le sens de déplacement sur le canton.

La loco reçoit de la centrale DCC son sens de déplacement via les rails, indépendamment de la carte canton.
En gros, l'info n'existe plus dans les cartes.

Mais, pour savoir dans quel sens va le train, sur ce canton précis, c'est plus dur :
    Soit on va le chercher dans la trame DCC, ce qui suppose un "sniffer" sur mesure (c'est à dire qui cherche l'info dans la trame DCC pour un train donné)
    Soit, au niveau de la carte D, on se rappelle du sens qu'on a demandé la dernière fois et qu'on garde donc en mémoire.
        Mais il faut, dans ces 2 cas, "traduire" ce sens de déplacement du train en sens de déplacement sur un canton donné.
    Dernière possibilité : le calculer au niveau du canton (vu qu'on a 3 zones)
Pas si facile, le DCC ... 

Et on a besoin de ce sens dans les enclenchements :
Classiquement, on interdit de bouger une aiguille quand l'un des 3 cantons adjacents est occupé.
Mais si un seul canton adjacent est occupé et que le train s'éloigne de l'aiguille, on ne va quand même pas bloquer l'aiguille.

A minima : tout est géré en carte D, en mémorisant les dernières demandes. Pourquoi pas ?

J’utilise 2 bus CAN, 1 pour la traction (cartes A), 1 pour les accessoires (B, C et E)
D doit donc avoir 2 contrôleurs CAN, c’est le cas de l’Arduino DUE.

Il y a une limite du nombre de cartes par bus CAN ?

Les cartes A reçoivent des commandes de D (vitesse de loco, sens de circulation, allumage/extinction des feux, affectation de convoi à un canton). Elle émettent à intervalles réguliers l’état d’occupation en pleine voie et en zone d’arrêt à destination de D. Elle émettent lorsqu’une machine passe d’un canton à l’autre la PWM et la composante intégrale de la loi de commande de manière à synchronise la  commande d’un canton à l’autre.

Les cartes B reçoivent les commandes de D (position des aiguilles) et émettent à destination de D la position effective lue via des fins de course.

Les cartes C reçoivent les commandes de D (signalisation)

La carte D connaît la topologie du réseau.

Elle reçoit de A l’état d’occupation en pleine voie et en zone d’arrêt et de B l’état des aiguillages. Elle reçoit également de E les commandes. Elle envoie à E les information de position des convois et des aiguillages.

La carte D connaît donc l’état global du réseau :
- convois présent, position de chaque convoi ;
- suivi des convois de canton en canton ;
- position des aiguilles.

Elle gère :
- affectation d’un poste de conduite à un convoi ;
- allumage/extinction des feux ;
- anti-collision ;
- positionnement des aiguillages ;
- gestion de la signalisation ;
- mémorisation des caractéristiques de loi de commande de chaque locomotive et envoi de ces caractéristiques aux cantons en fonction du suivi de convois.

Elle exécute :
Les commandes des postes de conduite;
Les commandes du TCO.

Dans les deux cas il y a filtrage : le fait qu’une commande d’un poste de conduite demande à entrer dans un canton occupé par un autre convoi est mis attente. De même le changement de position d’un aiguillage venant du TCO ou d’un poste de conduite alors que cet aiguillage est affecté à un autre convoi est mis en attente ou interdit.

Par la dessus, on peut mettre une circulation automatique en substituant un automate à un poste de conduite.

Parenthèse DCC pour ceux qui ont déjà une centrale du commerce :
Si on veut automatiser certaines actions, il faut faire une souris compatible XpressNet.
J'avais trouvé quelque chose chez Lenz (le Xpa, commandable par un téléphone). En gros, du bricolo, à 70 € quand même.
Puis je me suis souvenu du site de Paco où une souris XpressNet existe directement, mais avec un PIC. On passe à moins de 10 €.
Reste à faire la même chose en Arduino.
Évidemment, on ne peux pas passer d'un programme en HEX pour PIC à un programme Arduino. Il faut obligatoirement avoir le source du HEX ?

La carte E gère le TCO : changement de position d’aiguillage, réservation d’un itinéraire, affectation d’un convoi à un poste de conduite. Elle envoie ces ordres à D et reçoit de D le positionnement des convois et les positions des aiguilles.

La logique de fonctionnement n’est pas trop compliquée, il faut juste bien la spécifier et la vérifier.

Les données, par contre, sont touffues et des erreurs peuvent être cachées. Du coup je suis en train de faire un langage pour spécifier la topologie du réseau, affecter les alimentations et les aiguillages, spécifier la longueur des cantons et le graphe de cantons et y accrocher des règles. Un compilateur vérifie la description et génère les structures de données correspondantes. C’est en chantier mais je peux vous en parler plus en détails.

Alors, là, c'est grandiose !!
C'est vrai qu'il "suffisait" de créer un nouveau langage avec un compilateur !!!!!!!
Ben voyons !!
Oui, je veux bien des détails.   

Encore merci pour ce résumé très clair.

Amicalement

[Jean-Luc]

C'est la deuxième fois que tu dis "plus ou moins d'aiguillages par canton". J'aimerais que tu précises : tu "prolonges" les rails avec les contacts d'un relais ?
Parce que sinon, il faut bien détecter la présence des trains sur les aiguilles en carte B ?

Non, ce que je veux dire : mes cantons comprennent de 0 à N aiguilles. Comme je veux des cartes génériques pour pouvoir les faire fabriquer en série, elles sont indépendantes de la topologie d'un canton. C'est le logiciel qui fait le lien entre cantons et aiguillages et les manœuvre comme il faut. Par exemple voici ma gare terminus en pièce jointe. Chaque canton est d'une couleur différente :

A mon avis, en DCC, il y a quand même autre chose à gérer au niveau du canton : le sens de déplacement sur le canton.

La loco reçoit de la centrale DCC son sens de déplacement via les rails, indépendamment de la carte canton.
En gros, l'info n'existe plus dans les cartes.

Normalement si

A minima : tout est géré en carte D, en mémorisant les dernières demandes. Pourquoi pas ?

Tout à fait.

Il y a une limite du nombre de cartes par bus CAN ?

La limite est fixée par le transceiver. Le 2551 limite le nombre de nœuds à 112. Le Due a 2 CAN, autant les utiliser.

Les données, par contre, sont touffues et des erreurs peuvent être cachées. Du coup je suis en train de faire un langage pour spécifier la topologie du réseau, affecter les alimentations et les aiguillages, spécifier la longueur des cantons et le graphe de cantons et y accrocher des règles. Un compilateur vérifie la description et génère les structures de données correspondantes. C’est en chantier mais je peux vous en parler plus en détails.

Alors, là, c'est grandiose !!
C'est vrai qu'il "suffisait" de créer un nouveau langage avec un compilateur !!!!!!!
Ben voyons !!
Oui, je veux bien des détails.   

Ça vient

[Jean-Luc]

En deux mots, le langage permet de décrire la topologie du réseau et d'associer des attributs aux différents éléments.

On décrit des section de voie de la manière suivante :

Code: [Sélectionner]

section voie_entree_2 {
  in entree
  out sortie
  length 68.4
}

la section de voie est orientée avec une entrée, in et une sortie, out. entree et sortie sont les nom des deux extrémités de la section. length donne la longueur en mm.

La fait d'avoir :

Code: [Sélectionner]

section aiguille_entree_de_gare {
  in talon
  out directe
  out deviee
  length 159.5
}

et donc d'avoir 1 entrée et 2 sorties, définit un aiguillage.

les sections sont ensuite connectées :

Code: [Sélectionner]

connect voie_entree_2.sortie
     to aiguille_entree_de_gare.talon

Puis regroupées en cantons :

Code: [Sélectionner]

#------------------------------------------------------------------------------
# Canton d'entree de gare
#------------------------------------------------------------------------------
block grill_entree_gare {
  reverse stop {
    voie_entree_1
  }
  main {
    voie_entree_2, aiguille_entree_de_gare
  }
  normal stop {
    voie_vers_gauche | aiguille_vers_zone_marchandises
  }
  power 0:0
  color yellow
}

reserve stop, normal stop et main définissent respectivement les sections d'arrêt en marche arrière et en marche avant et la pleine voie.
power permet d'associer une alimentation (en analogique). color associe une couleur pour la sortie graphique

Pour l'instant le compilateur de fait pas grand chose à part vérifier que tout est cohérent et construire le graph au format graphviz. Ce qui donne le graphe en pièce jointe pour ma gare. Je joints également la description complète de ma gare. Ça ne correspond pas tout à fait aux cantons que j'ai placés dans mon message précédent : les tiroirs n'ont pas leur propre canton mais sont mis sous tension à la demande. J'ai changé d'idée car je souhaite pourvoir éclairer les feux dans les tiroirs. D'où une alimentation propre et un canton propre. Il faut que je mette ma description à jour.

Ça donne une représentation sur laquelle travailler pour générer les données du logiciel qui gérera le réseau.

[DDEFF]

Avant d'être dithyrambique avec Jean-Luc, je vais présenter ma solution pour cette gare.

En PJ, la gare numérotée.
Je considère un numéro par canton et un autre numéro par aiguille simple.
Une aiguille triple, c'est deux aiguilles qui se suivent et une TJD, deux aiguilles dos à dos.
Voilà donc la structure de table de ce circuit :

Code: [Sélectionner]

struct canton
  {
  byte precedent;
  byte courant;
  byte suivant_TD;
  byte suivant_DV;
  boolean occupation;
  boolean sens_train;
  byte pos_aig;        //  La position d'aiguille n'est pas boolean : il y a 3 positions.
  byte suivant_trigo;
  byte suivant_horaire;
  byte feu_trigo;
  byte feu_horaire;
  }
  Table_Cantons [] =
{ { 100,  1,  3,  2, false,false,2,0,0,0,0},
  {   1,  2,104,  9, false,false,3,0,0,0,0},
  { 105,  3,  0,  1, false,false,2,0,0,0,0},
  { 105,  4,106,  5, false,false,1,0,0,0,0},
  { 108,  5,  6,  4, false,false,1,0,0,0,0},
  {   5,  6,104,  7, false,false,1,0,0,0,0},
  { 103,  7,107,  6, false,false,1,0,0,0,0},
  {   9,  8,103,102, false,false,1,0,0,0,0},
  {   8,  9,101,  2, false,false,3,0,0,0,0},
  {   1,100,109,  0,  true, true,0,0,0,0,0},
  {   9,101,  0,  0, false,false,0,0,0,0,0},
  {   0,102,  8,  0, false,false,0,0,0,0,0},
  {   7,103,  8,  0, false,false,0,0,0,0,0},
  {   6,104,  2,  0, false,false,0,0,0,0,0},
  {   4,105,  3,  0,  true, true,0,0,0,0,0},
  {   0,106,  4,  0, false,false,0,0,0,0,0},
  {   0,107,  7,  0, false,false,0,0,0,0,0},
  {   0,108,  5,  0, false,false,0,0,0,0,0},
  { 100,109, 99,  0, false,false,0,0,0,0,0},
};

Évidemment, un objet C++ serait plus approprié, mais c'est ma prochaine étape.

Je décris mon processus de construction de la table :
ligne 0 = aiguille 1 :
Le precedent de l'aiguille 1, c'est le canton 100.
Le suivant_TD, c'est l'aiguille 3.
Le suivant_DV, c'est l'aiguille 2.
Et après, tout est à vide (pas là, mais on en reparlera).
On ne tient pas compte des sens pour l'instant;

Arrivent les cantons purs qui démarrent arbitrairement à 100.
Pour des questions de rapidité d'exécution, certains traitement ne concernent QUE les cantons (les feux, par exemple).
Donc on met les aiguilles avant les cantons dans la table.
Si c'étaient des objets, je pense qu'on pourrait se passer de cette "contrainte"

Les cantons sont orientés : sens_H (sens horaire). Ici, on décidera que le sens horaire est de gauche à droite.
Le canton 105 est donc encadré par 3 et 4, comme vous le voyez.
On repère facilement un canton au fait qu'il n'a pas de suivant_DV.
Pour le canton 100, j'ai dû inventer (on n'a pas tout le réseau).

Puis vient la table des itinéraires FORMES. Je n'ai jamais besoin de la description de tous les itinéraires possibles. Juste de ceux qui sont existants (formés).

Code: [Sélectionner]

Décrit tous les itinéraires formés. C'est une table résultat.
Table_Iti doit toujours être décrite dans le sens trigo, par définition

Colonne  0 = Canton départ
Colonne  1 = Aiguille  1
Colonne  2 = Aiguille  2
Colonne  3 = Aiguille  3
Colonne  4 = Aiguille  4
Colonne  5 = Aiguille  5
Colonne  6 = Aiguille  6
Colonne  7 = Aiguille  7
Colonne  8 = Aiguille  8
Colonne  9 = Aiguille  9
Colonne 10 = Aiguille 10
Colonne 11 = Aiguille 11
Colonne 12 = Aiguille 12
Colonne 13 = Aiguille 13
Colonne 14 = Aiguille 14
Colonne 15 = Aiguille 15
Colonne 16 = Canton arrivée
Colonne 17 = Ralenti : 1 = pas de ralenti, 2 = ralenti 60 km/h, 3 = ralenti 30 km/h
*/
byte Table_Iti [][18] =
{ { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
};

Pas dure à remplir ...

Vous noterez la dernière colonne qui donne la valeur de ralenti de l'itinéraire.

Je m'explique :
Si, dans un itinéraire, toutes les aiguilles sont TD, c'est à 1 et le train n'a aucune raison de ralentir.
Si, dans un itinéraire, une, au moins, des aiguilles est à 2, il ne faudra pas dépasser le 60 km/h.
Si, dans un itinéraire, une, au moins, des aiguilles est à 3, il ne faudra pas dépasser le 30 km/h.

D'où le fait que la carte d'aiguilles doit, en fournissant l'info TD/DV, qu'elle précise si c'est un ralenti 60 ou 30 km/h.
Cette info est "en dur" dans la carte et ne dépend que de la configuration physique de l'aiguilles.
La carte envoie donc 1 ou 2, ou alors 1 ou 3.
Et, avec ça, l'Arduino central se débrouille.

Comme je n'ai pas de réseau, j'ai rempli la Table_Cantons avec mes petites mimines la colonne pos.aig
De même, j'ai simulé 2 cantons occupés et leur sens : 100 et 105.
Sinon, c'est le réseau qui envoie ces informations, évidemment.

Dernière table, la table des trains :

Code: [Sélectionner]

struct train
  {
  byte canton__2;
  boolean occupation__2;
  byte canton__1;
  boolean occupation__1;
  byte canton_0;
  boolean occupation_0;
  boolean sens_0;
  byte canton_1;
  boolean occupation_1;
  byte canton_2;
  boolean occupation_2;
  byte erreur;
  byte feu;
  }
  Table_Trains [] =
{ { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
  { 0,false,0,false,0,false,false,0,false,0,false,0,0},
};

Pas dure à remplir non plus ... 

Le but est d'avoir deux cantons d'avance dans chaque sens.
Règle empirique de nommage :
Cn+1 se dit Cn__1
Cn-1 se dit Cn_1

Enfin, dans la Table_Cantons, les feux se calculent en fonction de tout ça, dans les 2 sens (horaire et trigo).

Je suis tout à fait d'accord avec Jean-Luc sur le fait que l'installation de feux à côté des rails est cosmétique. On n'en mets pas dans les gares cachées, etc...
Il n'en reste pas moins que le fait de calculer les feux, partout, dans les 2 sens, permet de donner une consigne de vitesse maxi du canton.
Et des vitesses maxi, dans une zone cachée, ça peut servir 

Feux gérés :

Code: [Sélectionner]

    /* Gestion des feux : on envoie à l'Arduino du canton un code sur 4 bits. C'est lui qui gèrera l'affichage effectif
   
                                                                                               | code pgm | code bus        |------|  | allumage feu
                                                                                               |          |                 |  07  |  |
                                                                                               |          |          |------|      |  |
     VL fixe                 (Voie Libre, vert ou blanc suivant l'endroit où il est implanté)  |     1    |    01    |  06     06  |  |  03 ou 04
      A fixe                 (Avertissement)                                                   |     2    |    02    |             |  |  01
      S fixe                 (Sémaphore)                                                       |     8    |    03    |  05     07  |  |  02
      C fixe                 (Carré, rouge ou violet suivant l'endroit où il est implanté)     |     9    |    04    |      |------|  |  05
     VL fixe + R  clignotant (Voie Libre + Ralentissement 60)                                  |    11    |    05    |  04  |         |  03 et 06
      A fixe + R  clignotant (Avertissement + Ralentissement 60)                               |    12    |    06    |      |         |  01 et 06
     VL fixe + R  fixe       (Voie Libre + Ralentissement 30)                                  |    21    |    07    |  03  |         |  03 et 06
      A fixe + R  fixe       (Avertissement + Ralentissement 30)                               |    22    |    08    |      |         |  01 et 06
     VL fixe + RR clignotant (Voie Libre et Rappel de Ralentissement 60)                       |   101    |    09    |  02  |         |  03 et 07
      A fixe + RR clignotant (Avertissement et Rappel de Ralentissement 60)                    |   102    |    10    |      |         |  01 et 07
     VL fixe + RR fixe       (Voie Libre + Rappel de Ralentissement 30)                        |   201    |    11    |  01  |         |  03 et 07
      A fixe + RR fixe       (Avertissement + Rappel de Ralentissement 30)                     |   202    |    12    |------|         |  01 et 07
    */

Il ne vous reste plus qu'à tester le .ino joint et d'analyser ce qui sort des Serial.print.

Moyennant quoi, je reste épaté par la souplesse de la proposition de Jean-Luc.
Et ça affiche un magnifique schéma.
Passer en objets C++ devrait fortement améliorer ma solution.

[Dominique]

Merci beaucoup à Jean-Luc et Denis pour ces descriptions détaillées : je commence à y voir clair dans la description du réseau (table des cantons et des itinéraires chez Denis), puis dans le suivi des trains (table des trains) ainsi que la gestion des feux qui découle des tables précédentes.

Une question simple : comment s'interface la retrosignalisation ?

J'ai l'impression que les besoins en retrosignalisation sont imposés par les descriptions dans les tables. Il faut bien des capteurs pour agir sur toutes ces données y compris des capteurs par défaut que sont les Time-out.

Je suis parti sur des capteurs de consommation pour suivre l'occupation des segments linéaires et des zones d'aiguille (j'ai bien compris qu'elles sont traitées comme des cantons), et j'ajouterai des capteurs RFID pour identifier les trains (pour connaître leur adresse DCC), puis des capteurs à effet Hall à des points précis (zone d'arrêt devant un feu, position d'arrêt en gare).

[DDEFF]

Ce que tu appelles la rétro-signalisation se traduit par des infos données par les Nano des cantons et les cartes d'aiguilles.
Et tout ça va dans les bus CAN qui sont bidirectionnels.
Je met au pluriel car il y a deux bus et que chaque carte est sur un bus.

Chez Jean-Luc, qui répondra mieux que moi sur ses cartes, ce sont les cartes A et B.

Chez moi, ce sera du même tonneau, mais j'essaierai d'y caser le DCC et, en rêvant, peut-être en même temps (on a le droit d'y croire ...  )
Si vous voulez voir la magnifique carte analogique de Jean-Luc, il y a une présentation dans "shields et modules" de votre forum favori.

Il en ressortira :
De la carte canton : l'occupation des voies (PV et ZA). Pour l'instant, c'est la carte canton qui, chez moi, sort le sens réel de déplacement sur la canton.
C'est peut-être redondant avec d'autres infos. Je verrais bien.

De la carte aiguille : la position réelle des aiguilles.
A ce sujet, j'ai eu une idée d'une navrante banalité, mais ce n'est plus du logiciel. Donc, je change de fil.

[Dominique]

Bonjour à tous,

J'ai démarré ce sujet qui me semblait absent des autres forums : j'ai été satisfait bien au delà de mes espérances si on se réfère aux 3 fils :

http://forum.locoduino.org/index.php?topic=166.0
http://forum.locoduino.org/index.php?topic=167.0
http://forum.locoduino.org/index.php?topic=211.0

et surtout aux articles complets de Pierre59 :

http://www.locoduino.org/spip.php?article154
http://www.locoduino.org/spip.php?article167
http://www.locoduino.org/spip.php?article172
http://www.locoduino.org/spip.php?article184

ceux de Denis :
http://www.locoduino.org/spip.php?article132
http://www.locoduino.org/spip.php?article134

qui maintenant cherche à résoudre la génération graphique de la modélisation

et ceux de Jean-Luc :

http://www.locoduino.org/spip.php?article155
http://www.locoduino.org/spip.php?article156
http://www.locoduino.org/spip.php?article157

pour le moment centrés sur une gare cachée.

Je suis maintenant complètement rassuré sur ce sujet et je vous encourage à vous en inspirer pour ne plus vous enfermer dans les logiciels tout faits, ne plus vous contenter des solutions fermées, comprendre et découvrir toute la richesse des techniques de la SNCF 

Votre expérience, présentée ici sera la preuve que Locoduino aura contribué au succès de votre réseau.

Personnellement je suis "en train" de développer la solution de Pierre59 :
http://forum.locoduino.org/index.php?topic=166.msg781#msg781

C'est une boite à outil tout à fait complète (et facile à compléter par soit même, car décrit en objets C++ qui restent petits et simples à comprendre) composée de zones, d'aiguilles, de signaux, d'itinéraires, de trains (et d'autres choses complémentaires bien utiles) qui s'interfacent facilement avec le matériel du réseau (la rétrosignalisation, la traction, les commandes d'aiguilles, un TCO, des manettes, etc..).

Je n'ai pas eu besoin de modifier mon architecture matérielle, le choix des modules Arduino qui, actuellement gèrent le TCO, la traction DCC, les aiguilles, et bientôt les signaux, ainsi que les capteurs de rétrosignalisation.

C'est très rassurant 

Cela m'a forcé à apprendre la programmation objet (l'IDE Arduino supporte pleinement le C++, qui se révèle à l'expérience plus agréable que la programmation classique).
Locoduino contient tout ce qu'il faut pour démarrer cet apprentissage :
http://www.locoduino.org/spip.php?id_mot=30&page=theme

Je vous ferai part de mon expérience (j'ai commencé sur le fil http://forum.locoduino.org/index.php?topic=166.msg781#msg781).

Amicalement
Dominique