- Dialogue standard pour les équipements de régulation
-
DIAlogue Standard pour les Equipements de Régulation de trafic (DIASER) est une norme de communication pour dialoguer principalement avec des contrôleurs de carrefours à feux, utilisés en régulation de trafic. Elle est également utilisée pour communiquer simplement avec des panneaux à messages variables, certaines stations de comptages en milieu urbain, et pour des parcs de stationnement.
Sommaire
Histoire
Avant la création de ce protocole série, généralement les échanges avec l'extérieur se faisaient avec des liaisons dites "fils-à-fils" à-savoir par l'intermédiaire d'entrées/sorties physiques tout-ou-rien (l'antique norme NF P 99-110 définissait des prises DB25 pour ce genre d'échanges). Ceci limitait les possibilités, mais permettait tout de même l'essentiel, à-savoir:
- les commandes: prise en coordination/tops de fins de phases, mode clignotant, choix de plan de feux (parfois appelé structure)
- et les retours: coordonné, clignotant, extinction, numéro de plan de feux, ouvertures (verts) de lignes de feux, etc.
La première mise en œuvre du standard DIASER a été faite lors de la réalisation du nouveau Poste Central SITER des Hauts-de-Seine (92) en 1998.
Depuis de nombreuses villes lors des rénovations de leurs postes centraux ont adopté ce standard, tous les contrôleurs de carrefours actuels du marché supportant ce protocole dorénavant.
Pour les liaisons permanentes, quel que soit le mode de transmission utilisé (cuivre, fibre optique, radio…) au final sur les contrôleurs on est connecté sur une liaison série (à 9600 bits/sec classiquement).
Le premier cas d'utilisation d'IP nativement de bout en bout en liaison permanente, a été réalisé sur le Poste Central du tramway des Maréchaux à Paris avec à la fois le PC et les différents contrôleurs connectés à un réseau local indépendant à-base de fibre optique mono-mode. Sur la ligne, en plus les contrôleurs bavardent entre eux pour s'échanger les informations d'approches (détections) des rames tramways, connues de chacun (en UDP broadcast). Ces informations permettent d'assurer la priorité tramway aux feux. L'utilisation du mode UDP (non connecté) permet également d'avoir en parallèle certains postes bureautiques venant à la demande interroger des contrôleurs.
Protocole
Le document de norme est disponible en France à l'AFNOR sous la référence NF P 99-071.
Le protocole, tel que décrit dans la norme, est prévu pour fonctionner sur des liaisons séries. Il consiste en de classiques couples de question/réponse. Les questions sont posées à l'initiative d'un PC maître des échanges (généralement une supervision), et les réponses renvoyées par l'appareil terrain tenant le rôle d'esclave. Le contrôle des réponses est effectué par le PC, qui a à sa charge de renvoyer les requêtes pour lesquelles il n'a pas eu de réponse (si nécessaire, ou d'attendre la prochaine interrogation prévue).
Mode IP
Ce protocole peut-être également utilisé pour de la communication en IP de manière générale, sur ethernet, en Wimax, ou autre (GPRS) avec le même principe que décrit précédemment. Certaines applications l'utilisent nativement avec l'un ou l'autre des deux modes possibles, à-savoir:
- des datagrammes en UDP (non connecté).
- un flux en TCP (connecté).
Le mode UDP est bien adapté pour ce type d'échanges temps-réel (conçu à l'origine pour fonctionner en liaison série en prenant en compte les acquittements au niveau du protocole). Chaque couple indépendant de question/réponse tient dans une unique trame ethernet : tous les messages Diaser étant définis pour tenir sur 256 caractères, alors que par défaut ethernet dispose d'un MTU pour les paquets IP généralement fixé à 1 500 octets.
Implicitement comme chaque échange (couple question/réponse) est indépendant (pas de notion de connexion maintenue), ce mode permet à de multiples PCs de venir à tour de rôle très rapidement interroger un appareil (voire un autre appareil pour échanger avec lui des données), sans nécessité de sa part d'aucun traitement particulier.
Le mode TCP est classiquement utilisé par de nombreux appareils de communications et notamment les convertisseurs Série↔IP, même si la possibilité de pouvoir exploiter l'UDP pour ses avantages commence à apparaitre sur de nombreux modèles afin d'éviter certaines contraintes (latences non maîtrisées liées à TCP, délimitation des trames dans un flux, gestion des connexions…) . Typiquement les appareils n'autorisent qu'une unique connexion avec un PC (gestion possible d'un seul flux ouvert simultanément).
Contenu des messages
Chaque trame échangée respecte la décomposition suivante (avec l'enrobage/encapsulation de base dit "standard"):
- un caractère d'enrobage de début : STX (valeur ASCII 02)
- un code application
- un code fonction
- les données concernant l'application/fonction
- un caractère d'enrobage de fin : ETX (valeur ASCII 03)
- un caractère de somme de contrôle de la trame appelé BCC (ou exclusif de tous les caractères de la trame après le STX).
Il existe plusieurs applications distinctes se traduisant par un code caractère différent:
- Code application '*' : communs à toutes.
- Code application 'C' et 'D' à 'K' : carrefours à feux. 'C' concerne l'ensemble des carrefours et 'D' à 'K' concerne les carrefours 0 à 7, un contrôleur pouvant gérer jusqu'à 8 carrefours indépendants.
- Code application 'M' : mesure du trafic.
- Code application 'P' : affichage de messages sur des panneaux.
- Code application 'T' : télésurveillance, pour des liaisons non permanentes (de type RTC ou GSM), avec liste d'événements empilés (dépilés ultérieurement lors de la lecture par UN poste central).
- Code application 'V' : gestion du suivi des Véhicules de Transports en Commun (principalement utilisé pour assurer la priorité des bus en "local", échanges directs bus ↔ contrôleur de carrefour).
- Code application 'R' : recueil de données.
- Code application 'S' : parcs de stationnement.
Ensuite chaque application, dispose de codes fonctions permettant d'assurer les différentes questions/réponses utiles à l'application.
L'application d'ensemble '*' (concernant toutes les applications) dispose de codes fonctions communs utiles (lecture/écriture de l'horodate et du type de jour, lecture de l'identification de la station…)
Chaque type de contrôleur supporte un certain nombre d'applications et de codes fonctions (au moins toutes les classiques). Malheureusement, l'expérience montre que même si le format des champs est bien défini, parfois sur leur interprétation, il peut exister des divergences… tous ces problèmes ayant tendance à s'atténuer au fil du temps et des mises à jour. Mais cela peut cependant rester problématique pour d'anciens contrôleurs dont le logiciel n'évolue plus.
Voir aussi
Wikimedia Foundation. 2010.
