Table des matières

Rechercher sur le site

Feux de signalisation (trafic routier)

#AutoTranslate

Description rapide

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

Description métier

Le protocole ne prend en charge que la diffusion des données. Aucun mécanisme de sélection des données de mesure n’est prévu. De même, il ne prend en charge que les données en ligne et non les requêtes d’archives.

Le protocole, inspiré de l’OCIT-C et de son prédécesseur l’OCIT-I, peut être considéré comme une version «light» de ce protocole.

Toutes les structures de données sont présentes Schémas au format XSD le transfert des données s’effectue toutefois sous un format JSON (JavaScript Object Notation), ce qui peut être déduit des structures XML pouvant être générées à l’aide des 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 impliquent la fourniture des données transmises,
  2. Données dynamiques, qui sont transmises périodiquement (p. ex. valeurs de comptage), en cas d’événements (p. ex. télégramme des transports publics) ou en cas de modification de la valeur (p. ex. états des groupes de signaux),
  3. Métadonnées décrivant et définissant 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. Il n’est pas conservé d’historique des descriptions passées, seules les données actuelles sont conservées. Les fichiers doivent comporter une datation dans leur contenu indiquant la date à partir de laquelle ils sont valables. La date de fin d’une validité est indiquée implicitement s’il existe un autre approvisionnement dont la date de début de validité est postérieure. Outre l’horodatage, un état des versions est également disponible.

Données statiques

Les données statiques (1) sont conservées dans une structure de fichiers indiquée pour l’adressage logique (cf. ci-dessous). Les fichiers sont formatés en XML et correspondent à un schéma XSD enregistré dans les métadonnées (3). Le schéma repose sur l’OCIT-C et l’OCIT-I. Les données sont écrites et interrogées via un protocole REST. Le protocole doit permettre de limiter, dans la requête, les couvertures souhaitées à «Area», «Intersection» et «Supply» (plage, nœud et valeurs de mesure); dans le cadre du provisionnement, l’adressage s’effectue via le contenu du fichier.

Les données statiques peuvent présenter des redondances (p. ex. numéro de l’objet et, pour une meilleure lisibilité, nom de l’objet). Les données statiques, également appelées données d’alimentation:

  • Se rapportent toujours à un domaine, p. ex. une ville ou un groupe thématique ou géographique de croisements ou de points de mesure.
  • Ou un nœud.

La référence à un groupe de nœuds est nécessaire p. ex. pour les temps de parcours entre les nœuds. Un tel groupe peut également se trouver dans tous les points de comptage d’une autoroute.

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

Données dynamiques

Le format des données dynamiques (2) s’inspire également de l’OCIT-C ou de l’OCIT-I. 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 dans JSON. Il est donc possible de générer un format XML pour leur transmission. La transmission à proprement parler a toutefois lieu en JSON.

Les données dynamiques ne doivent contenir aucune information redondante, en particulier sur les données de distribution (p. ex. noms de valeurs de mesure). Les données dynamiques sont réduites au strict nécessaire afin d’économiser la capacité de transmission et de maintenir la légèreté du contenu des télégrammes. Cela se reflète dans la dénomination des balises et la structure de la modélisation.

Métadonnées

Les métadonnées (3) correspondent aux données du schéma. À l’instar des données statiques, les fichiers de schéma peuvent avoir un début de validité. Ils doivent pouvoir être consultés, à la manière des données statiques.

Description technique

Adressage logique

Il existe trois niveaux d’adresse hiérarchiques:

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

Domaine

La ville ou une zone qui peut être assimilée à une ville n’est pas traitée spécifiquement dans l’OCIT. Pour les systèmes inter-villes, la «SystemNr» de l’adressage des nœuds.

Nous expliquons les «AreaID» obligatoire ici. Elle doit être univoque, pas seulement au sein d’une source de données. Si elle n’est pas attribuée automatiquement de manière univoque, elle doit l’être par un service central dans le monde entier. Tous les caractères alphanumériques de l’Unicode sont autorisés.

Une zone est ainsi identifiée via une «AreaID» comme clé primaire.

À titre informatif, les termes suivants s’appliquent:

  1. Une zone ou une ville peut avoir plusieurs noms dans différentes langues ou transcriptions.
  2. Un nom unique n’est pas nécessaire, car les noms de villes ne sont pas nécessairement uniques. Si un secteur ou une ville a plusieurs noms dans plusieurs langues, ils peuvent être saisis avec différentes abréviations de langues selon la norme ISO 639 ou RFC 17663 (du type «fr-CH»4).
  3. S’il n’y a qu’un seul nom dans la langue par défaut, celui-ci est saisi avec une abréviation de langue qui n’est alors pas utilisée dans le nom par défaut.

Nœuds

  • Le nœud est généralement traité par un numéro univoque au sein d’une zone qui «UnitID». Le nœud est le terme technique désignant un croisement de route.
  • Dans certaines villes, le même numéro de nœud a été attribué plusieurs fois. Dans ce cas, le numéro de nœud est complété par «UnitID» et «Provider».
  • Néanmoins, la désignation abrégée doit elle aussi être explicite.

Il y a donc, à l’intérieur d’une même unité

  • une clé primaire «UnitID» et facultatif «UnitID» et «Provider».

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’un domaine) sont abordés par leur type (données brutes des capteurs, valeurs des intervalles des signaux lumineux, groupes de signaux) et leur numéro de canal (p.ex. détecteur avec numéro de canal 2 – «D.2» ou groupe de signaux avec numéro de canal 3 – «S.3»).

Parallèlement, le point de données peut se voir attribuer un nom unique au sein du nœud («DR11.21»). Dans des cas exceptionnels, le point de données n’est univoque qu’au sein du type de données. Pour éviter tout malentendu, le numéro d’unité du nœud est généralement placé avant l’adressage et le nom: «184.D.2» (forme abrégée de l’adressage) et «184.DR11.21» (nom).

  1. Adressage de plusieurs valeurs mesurées du même type au sein du nœud:
    • Habituellement, les valeurs mesurées sont techniquement dans l’OCIT via «UnitID», type et numéro de canal adressés, p. ex. «184.D.2».
    • Il est également possible de procéder à l’adressage par «UnitID», type et nom, ce qui est confortable du point de vue du transport: Les postes de travail des ingénieurs des transports utilisent volontiers ce type d’adressage: 184.DR11.21.
  2. Adressage des valeurs mesurées n’existant qu’une fois par type:
    • Il est rare que l’adressage se fasse via le nœud et le type uniquement p. ex. 184.TX (seconde de roulement) ou 184.PrgNr (numéro de programme actuel), l’état d’exploitation ou le mode d’exploitation. Ici, techniquement, le numéro de canal 1 est attribué par défaut.
  3. Adressage des valeurs de mesure indépendantes des nœuds:
    • L’adressage à l’échelle d’un périmètre est également rare, p. ex. pour les points de communication des systèmes de détection des transports publics d’un Funkbake (Radio-téléphone). Dans ce cas, une valeur de 2 octets est utilisée comme adresse unique sur l’ensemble de la plage. Ex.: 37819.

Valeurs mesurées

Les valeurs mesurées sont des données dynamiques. Leur structure est définie dans les métadonnées.

Les valeurs mesurées peuvent être récupérées périodiquement par les clients connectés dans JSON via REST. Au début, le destinataire des données interroge toutes les données actuelles une seule fois. «inquireAll» et recueille toujours le delta des données avec GET à des intervalles pouvant être définis.

Extrait

Encl. «Snippet» est un résumé de valeurs mesurées:

  • «AreaID» est l’adresse du secteur.
  • «UnitID», «Provider» et «UnitID» contiennent l’adresse d’un nœud. «UnitID» est obligatoire, «UnitID» et «Provider» sont facultatives, mais peuvent être intégrées dans l’adresse univoque du nœud avec «UnitID» l’implication des personnes concernées.
  • L’horodatage indique la date et l’heure des valeurs de mesure suivantes.
  • Measurements ouvre la branche pour effectuer les mesures.

Dans la branche «Snippets» les valeurs mesurées. Les structures sont définies spécifiquement pour chaque type.

Cette première version C définit les types de valeurs de mesure suivants:

  • Level of Service (LOS): niveau de qualité pour les piétons, les véhicules à moteur ou les transports publics (p. ex. «A» jusqu’à «F»):
    • Le Level of Service peut être utilisée pour les piétons, les véhicules à moteur ou les transports publics. Le LOS est désigné par une lettre pour chaque catégorie:
      • À un moment donné, un point de mesure peut prendre la valeur d’une lettre, p. ex. «B»,
      • ou il est possible de transmettre un groupe de valeurs statistiques indiquant la fréquence des mesures en pourcentage pour chaque catégorie.
    • L’indication de l’intervalle peut être XSD être indiquées de manière plus restrictive que dans JSON. Il est important que soit «FixedInterval», «CycleInterval» voire en l’absence d’intervalle. Les commentaires relatifs aux balises ne sont pas répétés ici. Ils figurent dans le schéma XSD.
    • Il y a deux manières de LOS:
      • Transmission d’une lettre, comme «Letter»
      • ou deux longueurs égales Arrays transmis avec «Letters» et «Percentages».
  • SpillbackLength, Longueur de retenue en mètres:
    • Ici, une longueur de refoulement en mètres est transmise. 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. Par «Channel» une longueur est «Length» transmis.
    • Ici aussi, il est possible soit de définir une seule paire de valeurs «Channel» et «Length» ou deux de durée égale Arrays «Channels» et «Lengths».
  • GreenPercentage, pourcentage de vert par rapport au temps total disponible:
    • Dans ce cas, la part en vert d’un groupe de signaux est transmise 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. Par «Channel» un pourcentage est transmis.
    • Ici aussi, il est possible soit de définir une seule paire de valeurs «Channel» et «Percentage» ou deux de durée égale Arrays «Channels» et «Percentages».
  • ODCount, Contraintes source-objectif:
    • Valeurs de comptage par source (Origin) et objectif (Destination) transmis. Il peut s’agir d’une valeur actuelle ou d’un calcul périodique avec une durée de période constante ou variable. Par «Channel» nous utilisons une valeur de comptage «Count» transmis.
    • Ici aussi, il est possible soit de définir une seule paire de valeurs «Channel» et «Count» ou deux de durée égale Arrays «Channels» et «Counts».
  • DriveAwayHeadway, Valeur du temps nécessaire, calculée lors du démarrage:
    • L’intervalle de temps entre deux véhicules est appelé espace de temps brut. Lors du démarrage après un feu rouge, il est également question de la valeur du temps nécessaire. Il s’agit du temps écoulé entre deux véhicules qui se suivent. La valeur du temps nécessaire dépend de la capacité maximale d’un nœud, qui permet également de déterminer les accès critiques.
    • La valeur du temps nécessaire est déterminée ici en fonction de la position des véhicules dans la colonne de véhicules à l’approche. Les valeurs des différents véhicules peuvent être successivement inférieures à «Duration» dans la liste. Il est également possible d’en calculer le temps nécessaire moyen. Un «MeanDuration» soit en consultant les détails sous «Duration» avant ou seul, comme événement ou comme résultat d’un calcul sur un intervalle.

Il est possible de transmettre des événements ou des données statistiques:

  • Si les données de mesure ne comportent aucun intervalle, il s’agit d’une valeur actuellement mesurée.
  • Si un «FixedInterval» indiqué, il s’agit alors d’une valeur statistique calculée avec une périodicité constante.
  • Si un «CycleInterval» il s’agit alors d’une valeur statistique déterminée par roulement, généralement au début du rouge. Ces intervalles n’ont généralement pas une longueur constante.

Les données mesurées sont transmises via le type de la valeur mesurée et le Channel ou peuvent faire l’objet d’une «Supply» être retrouvées.

Informations complémentaires

Informations complémentaires «Snippet» se trouvent dans Schéma OpenAPI.

Les Traffic-Lights L’interface peut être testée directement dans notre OpenAPI: OpenAPI Trafficlight