Feux de signalisation (trafic routier)

Bases

Ce Cookbook décrit un protocole de transmission de données de mesure du trafic routier urbain. Les données de mesure peuvent être liées à des intervalles rigides (comme les données de comptage) ou non (comme les points d’annonce des transports publics).

Le protocole ne prend en charge que la diffusion de données. Aucun mécanisme de sélection des données de mesure n’est prévu. Il ne prend également en charge que les données en ligne et ne permet pas de consulter les archives.

Le protocole s’inspire d’OCIT-C et de son prédécesseur OCIT-I et peut être considéré comme une version “light” de ce protocole.

Toutes les structures de données sont basées sur des schémas au format XSD, mais la transmission des données elles-mêmes est formatée en JSON (JavaScript Object Notation), ce qui peut être déduit des structures XML qui peuvent être générées selon les schémas XSD.

Concept de données

Le modèle de données comprend trois types de données et leur transmission:

1. Données statiques qui contiennent l’alimentation des données transmises,
2. Données dynamiques transmises périodiquement (p. ex. valeurs de comptage), en cas d’événements (p. ex. télégrammes TP) ou de modification de la valeur (p. ex. états de groupes de signaux),
3. les métadonnées qui décrivent et définissent les données statiques et dynamiques (p. ex. schémas).

Les données descriptives, qu’il s’agisse de données statiques ou de métadonnées, peuvent évoluer au fil du temps. Aucun historique des descriptions passées n’est conservé, seules les données actuelles sont conservées. Le contenu des fichiers doit être horodaté pour indiquer la date à partir de laquelle ils sont valables. La date de fin de validité est implicitement donnée lorsqu’il existe un autre approvisionnement avec une date de début de validité ultérieure. Outre l’horodatage, un état de version est également disponible.

Données statiques

Les données statiques (1) sont conservées dans une structure de fichiers qui suit l’adressage logique (voir plus loin). Les fichiers sont formatés en XML et correspondent à un schéma XSD qui est déposé dans les métadonnées (3). Le schéma s’inspire de celui d’OCIT-C et d’OCIT-I. Il s’agit d’une méthode d’évaluation de la qualité de l’eau. Les données sont écrites et également consultées via un protocole REST. Dans la requête, le protocole doit pouvoir limiter les approvisionnements souhaités à “Area”, “Intersection” et “Supply” (domaine, nœud et valeurs de mesure) ; dans l’approvisionnement, l’adressage se fait par le contenu du fichier.

Les données statiques peuvent présenter des redondances (par exemple, dans les liens, le numéro de l’objet et, pour une meilleure lisibilité, le nom de l’objet).

1. Les données statiques, également appelées données de couverture, se rapportent toujours à
   une zone, par exemple une ville ou un groupe thématique ou géographique d’intersections ou de points de mesure, ou
2. un nœud.

La référence à un groupe de nœuds est nécessaire, par exemple, pour les temps de trajet entre les nœuds. Ou un tel groupe peut être tous les points de comptage sur une autoroute.

Le fichier MAP peut également être enregistré dans les données statiques1. Le fichier MAP suit ses propres règles (ISO/TS 19091:2019).

Données dynamiques

Le format pour les données dynamiques (2) s’inspire également d’OCIT-C ou d’OCIT-I. Il s’agit d’un format de données qui permet d’obtenir des informations sur l’état de santé d’une personne. Leurs structures sont également définies via des schémas XSD avec des remarques sur la manière de procéder avec les types de tableaux en JSON. C’est pourquoi un format XML peut être créé pour leur transmission. La transmission proprement dite se fait toutefois en JSON.

Les données dynamiques ne doivent pas contenir d’informations redondantes, notamment sur les données d’alimentation (p. ex. noms des valeurs de mesure). Les données dynamiques sont réduites au strict nécessaire afin d’économiser la capacité de transmission et de garder le contenu des télégrammes léger. Cela se reflète également dans le choix des noms des tags et dans la structure des structures.

Métadonnées

Les métadonnées (3) sont les données du schéma. Les fichiers de schémas peuvent, comme les données statiques, avoir un début de validité. Les fichiers doivent pouvoir être conservés et consultés de manière similaire aux données statiques.

Adressage logique

Il existe trois niveaux hiérarchiques d’adresses:

1. Domaine,
2. Nœuds,
3. Type et numéro de canal.

Aire

La ville ou une zone pouvant être assimilée à une ville n’est pas particulièrement abordée dans OCIT. Pour les systèmes interurbains, le “SystemNr” de l’adressage des nœuds est utilisé à cet effet.

Nous déclarons ici que l’ID de domaine est obligatoire. Elle doit être unique, et pas seulement au sein d’une source de données. Elle doit être attribuée par un organisme central, si elle n’est pas donnée implicitement, de sorte qu’elle soit unique dans le monde entier. Elle est alphanumérique. L’Unicode est autorisé.

Un domaine est donc adressé par un ID de domaine comme clé primaire.

Le nom n’est donné qu’à titre informatif.

1. Un domaine ou une ville peut avoir plusieurs noms dans différentes langues ou transcriptions.
2. Il n’est pas nécessaire d’avoir un nom unique, car les noms des villes ne doivent pas être uniques. Si un domaine ou une ville devait avoir plusieurs noms dans plusieurs langues, ils peuvent être saisis avec des abréviations linguistiques différentes selon ISO 639 ou RFC 17663 (de type “fr-CH “4).
3. S’il existe un nom en langue standard (DefaultLanguage), il y est saisi avec l’abréviation de la langue, qui est alors supprimée dans le nom standard.

Nœud

• Le nœud est généralement adressé par un numéro unique au sein d’une plage, le numéro d’unité. “nœud” est le terme technique pour “croisement de routes”.
• Il y a des villes avec le même numéro de nœud qui a été attribué plusieurs fois. Le numéro de nœud y est complété par SystemNr et SubsystemNr.
• Néanmoins, l’abréviation doit également être claire.

Il existe donc, au sein d’un domaine

• une clé primaire composée du numéro d’unité et des numéros facultatifs SystemNr et SubsystemNr.

Type et numéro de canal

Tous les points de données à l’intérieur d’un nœud (ou éventuellement à l’intérieur d’une zone) sont adressés par leur type (données brutes du détecteur, valeurs d’intervalle du détecteur, groupes de signaux) et leur numéro de canal (p. ex. détecteur avec le numéro de canal 2 – “D.2” ou groupe de signaux avec le numéro de canal 3 – “S.3”).

En même temps, il est possible d’attribuer au point de données un nom qui doit être unique au sein du nœud (“DR11.21”). Dans des cas exceptionnels, il n’est unique qu’à l’intérieur du type de données. Pour éviter tout malentendu, l’adressage et le nom sont généralement précédés du numéro d’unité du nœud : “184.D.2” (forme abrégée de l’adressage) et “184.DR11.21” (nom).

1. Adressage de plusieurs valeurs de mesure du même type au sein du nœud
   • Habituellement, les valeurs de mesure sont adressées techniquement dans OCIT via le numéro d’unité, le type et le numéro de canal, par exemple “184.D.2”.
   • Alternativement, l’adressage peut se faire par le numéro d’unité, le type et le nom, ce qui est confortable du point de vue de la technique de circulation : les postes de travail des ingénieurs de circulation utilisent volontiers ce type d’adressage : 184.DR11.21.
2. Adressage de valeurs de mesure qui n’existent qu’une seule fois par type
   • Il est rare que l’adressage se fasse par le nœud et le type seul, p. ex. 184.TX (seconde de rotation) ou 184.PrgNr (numéro de programme actuel), l’état de fonctionnement ou le mode de fonctionnement. Le numéro de canal 1 est attribué par défaut
3. Adressage des valeurs de mesure indépendantes du nœud
   • De même, l’adressage à l’échelle de la zone est rare, par exemple pour les points de signalisation des systèmes de détection des TP selon la technologie radio des balises. Dans ce cas, une valeur de 2 octets est utilisée comme adresse, qui est unique dans toute la plage : 37819.

Valeurs de mesure (JSON)

Les valeurs de mesure sont des données dynamiques. Leur structure est consignée dans les métadonnées.

Les valeurs de mesure peuvent être récupérées périodiquement en JSON via REST par les clients connectés. Au début, le preneur de données demande une fois toutes les données actuelles (“inquireAll”) et va ensuite toujours chercher le delta de données (“get”) à des intervalles de temps librement définissables. Le nombre d’acheteurs simultanés dépend du système.

Snippet

Un “snippet” est un résumé de valeurs mesurées.

• AreaId est l’adresse de la zone.
• SystemNr, SubsystemNr et UnitNr contiennent l’adresse d’un. UnitNr est obligatoire, SystemNr et SubsystemNr sont facultatifs, mais peuvent être inclus dans l’adressage unique du nœud avec UnitNr.
• Timestamp indique le moment des valeurs de mesure suivantes.
• Measurements ouvre la branche pour les mesures.

La branche “Measurements” contient les valeurs de mesure. Les structures sont définies spécifiquement pour chaque type.

Les types suivants de valeurs mesurées sont définis dans cette première version C:

• Level of Service (LOS): niveau de qualité pour les piétons, les véhicules motorisés ou les transports publics (p. ex, «A» à «F»),
  • Le niveau de service (LOS) peut être utilisé pour les piétons, les véhicules motorisés ou les transports publics. La LOS est désignée par une lettre pour chaque catégorie.
    • À un moment donné, un point de mesure peut prendre la valeur d’une lettre, par ex «B»,
    • ou il est possible de transmettre un groupe de valeurs statistiques indiquant quelle catégorie a été mesurée et à quelle fréquence (en pourcentage).
  • L’indication de l’intervalle ne peut pas être représentée de manière aussi restrictive en JSON qu’en XSD. Il est important de préciser que l’intervalle peut être “FixedInterval”, “CycleInterval” ou pas du tout. Les commentaires sur les tags ne sont pas répétés ici – ils se trouvent dans le schéma XSD.
  • Il y a deux possibilités pour la LOS:
    • Soit une lettre est transmise “Letter
    • ou deux tableaux de même longueur sont transmis avec “Letters” et “Percentages”.

 

• SpillbackLength : longueur de la retenue en mètres,
  • Une longueur de retenue en mètres est transmise ici. Comme toujours, il peut s’agir d’une valeur actuelle ou d’un calcul périodique avec une durée de période constante ou variable. Une longueur “Length” est transmise par “Channel”.
  • Ici aussi, il y a la possibilité de transmettre soit une seule paire de valeurs “Channel” et “Length”, soit deux tableaux de même longueur “Channels” et “Lengths”.

 

• GreenPercentage : pourcentage de vert par rapport au temps total disponible,
  • La part de vert d’un groupe de signaux est transmise ici en pourcentage du temps total disponible. Ici aussi, il peut s’agir d’une valeur actuelle ou d’un calcul périodique avec une durée de période constante ou variable. Pour chaque “canal”, un pourcentage “Percentage” est transmis.
  • Ici aussi, il y a la possibilité de transmettre soit une seule paire de valeurs “Channel” et “Percentage”, soit deux tableaux de même longueur “Channels” et “Percentages”.

 

• ODCount : Charges source-objectif,
  • Ici, les valeurs de comptage sont transmises par source (Origin) et par destination (Destination). Il peut s’agir d’une valeur actuelle ou d’un calcul périodique avec une durée de période constante ou variable. Une valeur de comptage “Count” est transmise par “Channel”.
  • Ici aussi, il y a la possibilité de transmettre soit une seule paire de valeurs “Channel” et “Count”, soit deux tableaux de même longueur “Channels” et “Counts”.

 

• DriveAwayHeadway : valeur du temps nécessaire, déterminée au démarrage.
  • L’écart de temps entre deux véhicules est appelé écart de temps brut. Lorsque l’on démarre après un feu rouge, on parle en outre de la valeur du temps nécessaire. C’est le temps qui s’écoule entre deux véhicules qui se suivent. La capacité maximale d’un nœud dépend de la valeur du temps nécessaire et permet également de déterminer les accès critiques.
  • La valeur du temps nécessaire est ici déterminée en fonction de la position des véhicules dans la colonne de véhicules en approche. Les valeurs des différents véhicules peuvent être énumérées l’une après l’autre sous “Duration”. Il est également possible de calculer une valeur moyenne de temps nécessaire à partir de ces données. Il est transmis dans “MeanDuration”, soit précédé du détail sous “Duration”, soit seul – comme événement ou comme résultat d’un calcul sur un intervalle.

 

Des événements ou des données statistiques peuvent être transmis.

• Si aucun intervalle n’est indiqué dans les données de mesure, il s’agit d’une valeur actuellement mesurée.
• Si un “FixedInterval” est indiqué, il s’agit d’une valeur statistique qui est déterminée avec une périodicité constante.
• Si un “CycleInterval” est indiqué, il s’agit d’une valeur statistique qui est déterminée “par tour”, généralement au début du rouge. De tels intervalles n’ont généralement pas une longueur constante.

Les données de mesure sont

• sur le type de valeur de mesure
• et s’adresse au channel

ou peuvent être retrouvés en dessous dans les soins.

Swagger

Des informations complémentaires sur le snippet sont disponibles dans le schéma JSON ou directement dans le cadre Swagger ci-dessous.