Le besoin

Le superviseur de trafic commande un panneau comme il commande n’importe quel équipement du réseau de régulation : par des transactions DIASER, courtes, en texte, avec acquittement. Il décrit un panneau en termes de lignes, de caractères, de durée de validité, d’état et de défauts.

Le panneau, lui, attend des commandes LCR : un message par ligne, avec ses attributs de clignotement, d’alternance, de durée de validité et d’éclairage, et il répond à des interrogations d’état, de cellules photosensibles et de pixels. Les deux protocoles ne se ressemblent ni dans leur transport, ni dans leur vocabulaire. La passerelle doit donc faire plus que relayer des octets : elle traduit, tient un état et surveille le panneau.

Pourquoi une passerelle maison

Une passerelle est un maillon critique. Quand elle défaille, le superviseur perd la main sur le panneau, et un message d’alerte peut rester affiché, ou ne jamais s’afficher. Les problèmes de fiabilité rencontrés avec la passerelle du fabricant nous ont décidés à reprendre la maîtrise de la chaîne.

Écrire la passerelle nous-mêmes a donné trois choses :

• un comportement connu : nous savons ce qu’elle fait à chaque transaction, et nous pouvons le tracer ;
• un logiciel qui se corrige : un défaut observé sur le terrain se traite directement, sans attendre un tiers ;
• un déploiement simple : le même programme sert pour tous les panneaux, paramétré à son lancement.

Architecture

La passerelle est un unique programme en C, découpé en trois fils d’exécution (threads) qui ne se bloquent pas les uns les autres.

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#eef0ff','primaryTextColor':'#27262b','primaryBorderColor':'#5c5adc','lineColor':'#8a8da8','secondaryColor':'#f4f5ff','tertiaryColor':'#f4f5ff','edgeLabelBackground':'#eef0ff','clusterBkg':'#f4f5ff','clusterBorder':'#5c5adc'}}}%%
flowchart TB
    SUP["Superviseur de trafic"] <-->|"DIASER · UDP"| GW
    subgraph TRB["Boîtier industriel Teltonika TRB140"]
        GW["Fil DIASER<br/>répond au superviseur"] <--> ETAT[("État du panneau<br/>en mémoire")]
        ETAT <--> LCR["Fil LCR<br/>dialogue avec le panneau"]
        ETAT <--> DEF["Fil défauts<br/>analyse des réponses"]
    end
    LCR <-->|"LCR · TCP"| PMV["Panneau à messages variables"]
    style PMV fill:#fff4e0,stroke:#e9a23b,color:#27262b
    style ETAT fill:#e3f5ea,stroke:#2fb37a,color:#27262b

• Le fil DIASER écoute les transactions du superviseur en UDP, les décode, met à jour l’état du panneau en mémoire et répond aussitôt.
• Le fil LCR tient une connexion TCP permanente avec le panneau, lui envoie les messages à afficher et l’interroge régulièrement.
• Le fil défauts lit les réponses du panneau, en extrait les défauts, les cellules photosensibles et la synthèse de l’état technique, compare l’affichage réel au message demandé, et met à jour l’état en mémoire.

Le point clé est l’état tenu en mémoire. Tant que le panneau répond, le superviseur n’attend jamais lui : sa transaction est traitée à partir de ce que la passerelle sait déjà, et la réponse part immédiatement. Et quand le panneau ne répond plus, ou n’affiche pas ce qui lui est demandé, la passerelle ne répond plus non plus : c’est le silence qui avertit le superviseur (voir plus bas).

Les fonctions DIASER prises en charge

Les fonctions prises en charge couvrent l’application « Panneaux » de DIASER, identifiée par la lettre P. Une fonction de lecture se note en majuscule, sa forme d’écriture en minuscule.

Les fonctions qui n’ont pas de sens pour un panneau reçoivent le code d’erreur normalisé « code fonction non reconnu », plutôt qu’un silence qui laisserait le superviseur attendre.

Du message DIASER à la commande LCR

Un message à afficher arrive en DIASER sous la forme d’une durée de validité, d’un nombre de lignes, d’un nombre de caractères par ligne et du texte. La passerelle le découpe ligne par ligne et construit une commande LCR d’affichage, avec les attributs que le superviseur a demandés. Voici un exemple pour un panneau de deux lignes de quinze caractères, les points figurant des espaces (valeurs d’exemple) :

DIASER   Pe 0A 2 0F BOUCHON........RALENTISSEZ....
LCR      PA ID=... AM=1.1 AF="BOUCHON        " CL=0 DV=00:10:00 EC=AU
                       AM=1.2 AF="RALENTISSEZ    " CL=0 DV=00:10:00 EC=AU

Chaque ligne du panneau devient un message adressé (AM), avec son texte (AF), son clignotement (CL), sa durée de validité (DV) et son éclairage (EC). Un message alterné ajoute l’alternance (AT), avec les deux textes et leurs durées d’affichage.

Le message est envoyé une seule fois, avec sa durée de validité : c’est le panneau qui gère l’échéance. Si la passerelle ou le réseau devait s’interrompre, le panneau retire de lui-même le message à l’issue de sa durée de validité, au lieu de rester bloqué sur une information périmée.

Surveiller le panneau

Quand aucun message n’est en attente, le fil LCR ne reste pas inactif : il interroge le panneau, environ une fois par seconde, en alternant cinq questions. Elles s’appuient sur des commandes propres au fabricant du panneau, comme la commande ST STR, qui renvoie la synthèse de l’état technique.

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#eef0ff','primaryTextColor':'#27262b','primaryBorderColor':'#5c5adc','lineColor':'#8a8da8','secondaryColor':'#f4f5ff','tertiaryColor':'#f4f5ff','edgeLabelBackground':'#eef0ff','clusterBkg':'#f4f5ff','clusterBorder':'#5c5adc'}}}%%
flowchart TB
    MSG["Message à afficher<br/>reçu du superviseur"] --> LCR
    LCR["<b>Fil LCR</b> · une requête par seconde<br/>affichage, si un message est en attente<br/>sinon une interrogation à tour de rôle :<br/>défauts · état technique · cellules · pixels · affichage"] -->|"LCR · TCP"| PAN
    PAN["Panneau à messages variables"] -->|"réponses"| DEF
    DEF["<b>Fil défauts</b> · analyse des réponses<br/>pixels · alimentation · cellules<br/>fin de validité · affichage réel"] --> ETAT
    ETAT[("État du panneau en mémoire<br/>lu par le superviseur")]
    style LCR fill:#eef0ff,stroke:#5c5adc,color:#27262b
    style PAN fill:#fff4e0,stroke:#e9a23b,color:#27262b
    style ETAT fill:#e3f5ea,stroke:#2fb37a,color:#27262b

Le fil défauts exploite les réponses :

• Défauts de pixel : le panneau indique la position des pixels défaillants, que la passerelle convertit en défauts DIASER avec leur position.
• Synthèse technique : la réponse à la synthèse de l’état technique donne notamment l’état de l’alimentation. Un défaut de batterie ou d’alimentation devient un défaut DIASER d’alimentation.
• Fin de durée de validité : signalée au superviseur, pour qu’il sache qu’un message s’est éteint de lui-même.
• Cellules photosensibles : leurs mesures donnent le niveau de luminosité de jour, de nuit ou de surbrillance, que le superviseur lit dans l’état du panneau quand l’éclairage est laissé en mode local.

Dès que le nombre de défauts change, la passerelle lève un indicateur de changement : la prochaine lecture de l’état répond par la forme « changement », et le superviseur vient lire la liste des défauts. Il n’a pas besoin d’interroger les défauts en permanence pour ne rien rater.

Vérifier que le panneau affiche ce qui est demandé

Un panneau qui acquitte une commande ne prouve pas qu’il affiche le message : une erreur de module, une coupure d’alimentation ou une commande locale peuvent laisser un autre texte à l’écran. Un acquittement ne suffit donc pas, la passerelle doit relire l’affichage.

Elle mémorise le message demandé par le superviseur, puis, dans sa rotation d’interrogations, relit l’affichage réel du panneau avec la commande PE AM=*, qui renvoie une ligne par module avec son texte. La relecture est comparée au message attendu, ligne à ligne, en ignorant les espaces de fin.

• Concordance : rien à faire, le compteur de tentatives repart de zéro.
• Discordance : après un court délai laissé au panneau pour afficher, la passerelle renvoie le message, jusqu’à trois fois.
• Discordance persistante : si le panneau n’affiche toujours pas ce qui est demandé, la passerelle coupe la communication DIASER, comme pour une liaison perdue, et continue de renvoyer le message. Dès que l’affichage est conforme, la communication reprend d’elle-même.

Pourquoi couper plutôt que répondre par une erreur ? Parce que le fonctionnement est asynchrone : la réponse DIASER part avant que le panneau ait eu le temps d’afficher, on ne peut donc pas la conditionner à la relecture. En revanche, quand la discordance est établie, le silence est un signal que le superviseur sait déjà lire : la station est indisponible, il ne doit pas croire qu’un message est affiché.

Trois cas ne sont pas comparés, pour éviter les fausses alertes : un message dont la durée de validité est écoulée, un message alterné dont l’affichage change à chaque instant, et une lecture dont le nombre de modules ne correspond pas à la taille du panneau.

Quand le panneau ne répond plus

La liaison TCP avec le panneau peut tomber : coupure réseau, redémarrage du panneau, boîtier qui perd sa liaison. Plus insidieux encore, la connexion peut rester ouverte alors que le panneau ne répond plus. La passerelle surveille donc la date de la dernière réponse du panneau, quelle qu’elle soit.

Au-delà d’un délai de dix secondes sans réponse, la liaison est déclarée perdue. La passerelle fait alors deux choses :

• elle cesse de répondre aux transactions DIASER, sans les traiter et sans renvoyer de code d’erreur. Le superviseur interprète l’absence de réponse comme une station injoignable, ce qu’elle est : mieux vaut un silence franc qu’une réponse rassurante qui décrirait un état que la passerelle ne peut plus vérifier ;
• elle reconstruit la connexion : elle ferme la socket, attend cinq secondes, puis se reconnecte et reprend ses interrogations.

Dès que le panneau répond de nouveau, les transactions DIASER sont traitées comme avant, sans intervention.

Un banc d’essai pour tout voir

Une passerelle se met au point en regardant les trois acteurs en même temps : celui qui commande, celui qui exécute et celui qui traduit. Notre banc d’essai les met côte à côte.

Dans le journal de la passerelle, on suit chaque échange : la transaction DIASER reçue, la réponse renvoyée au superviseur, puis les requêtes envoyées au panneau et leurs acquittements. Quand le message commandé à gauche s’affiche à droite sur la page du panneau, la chaîne est validée.

Dans un boîtier Teltonika TRB140

Le programme est embarqué dans une passerelle industrielle Teltonika TRB140, un produit pensé pour héberger ce type d’application au plus près de l’équipement. Il se paramètre à son lancement : port d’écoute DIASER, adresse et port LCR du panneau, identifiant de la station, nombre de lignes et de caractères par ligne, niveau de journalisation. Le même programme sert donc pour des panneaux de tailles différentes.

Un mode bavard, activable au lancement, journalise chaque transaction DIASER et chaque échange LCR avec un horodatage à la milliseconde. C’est l’outil qui rend un défaut observé sur le terrain reproductible : on voit ce que le superviseur a demandé, ce que la passerelle a envoyé et ce que le panneau a répondu.

Technologies

C (threads POSIX, sockets UDP et TCP), Linux embarqué, boîtier industriel Teltonika TRB140, DIASER (UDP, application panneaux), LCR (TCP, NF P 99-341), panneaux à messages variables.

Me contacter

Le besoin

Le chantier porte sur l’automate, pas sur le capteur : les boucles inductives sont déjà dans la chaussée. Le remplaçant doit donc se brancher sur les détecteurs existants et continuer à dialoguer, en DIASER, comme l’équipement qu’il remplace.

Car un superviseur de trafic ne veut pas des signaux bruts d’une boucle, il veut des compteurs : un nombre de véhicules et un temps d’occupation, qu’il interroge à son rythme et dont il tire lui-même les débits et les taux d’occupation. La station a donc deux métiers : transformer des fronts électriques en compteurs fiables, et exposer ces compteurs dans le dialogue normalisé du trafic, sans que le superviseur ait à savoir que l’automate a changé.

De la boucle à l’entrée numérique

Chaque boucle est reliée à un détecteur, qui bascule à l’arrivée d’un véhicule puis revient à l’état libre à son départ. La sortie du détecteur est raccordée à une entrée numérique de l’IOT2050. Deux fronts portent toute l’information :

• le front montant : un véhicule entre sur la boucle ;
• le front descendant : il la quitte. La durée entre les deux est son temps de présence.

Une station gère dix entrées, soit autant de boucles ou de voies à surveiller en parallèle.

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#eef0ff','primaryTextColor':'#27262b','primaryBorderColor':'#5c5adc','lineColor':'#8a8da8','secondaryColor':'#f4f5ff','tertiaryColor':'#f4f5ff','edgeLabelBackground':'#eef0ff','clusterBkg':'#f4f5ff','clusterBorder':'#5c5adc'}}}%%
flowchart TB
    B["Boucles inductives<br/>sciées dans l'enrobé"] --> D["Détecteurs de boucle"]
    D -->|"contacts · fronts montants / descendants"| IN
    subgraph IOT["Siemens IOT2050 · Debian"]
        IN["Entrées numériques"] --> TH["Un thread par entrée<br/>attente passive des fronts"]
        TH --> CP["Compteurs<br/>véhicules · occupation"]
        CP --> SRV["Serveur DIASER<br/>application M · UDP"]
    end
    SRV <-->|"questions / réponses"| SUP["Superviseur de trafic"]

Sur le terrain, la station tient dans une armoire installée en bordure de chaussée. Quant à la boucle, elle est invisible : une fois le sillon scié dans l’enrobé puis rempli, il n’en reste que le tracé.

Acquisition par événements

La tentation, avec des entrées numériques, est de les lire en boucle à intervalle fixe. Ce serait gaspiller le processeur et, surtout, risquer de rater un front court, par exemple celui d’une moto ou d’un véhicule rapide sur une petite boucle.

Le logiciel de la station procède autrement. Chaque entrée est exposée par le noyau Linux et configurée pour signaler les deux fronts. Un thread dédié par entrée s’endort sur un select(), donc sans consommer de CPU, et n’est réveillé que par un changement d’état. À ce moment seulement, il lit la nouvelle valeur et prend l’horloge. Un mutex protège l’état de chaque capteur, partagé avec le thread qui répond au superviseur.

Le résultat est une acquisition pilotée par les événements, qui ne dépend pas d’une période de scrutation et ne coûte rien tant qu’aucun véhicule ne passe.

Des compteurs bruts, comme le veut la norme

La norme DIASER fixe une règle simple et exigeante : la station ne transmet jamais de quotient, seulement des compteurs cumulatifs, non remis à zéro à la lecture. Le superviseur calcule le débit ou le taux d’occupation par différence entre deux relevés.

La station entretient donc deux familles de compteurs :

• le comptage : un véhicule détecté sur le front montant, c’est une unité ajoutée ;
• l’occupation : le temps pendant lequel la boucle est occupée, cumulé par pas de 0,25 s, l’unité d’échange de la norme.

Chaque compteur est échangé sur un octet et boucle donc à 256. Ce n’est pas un défaut : le superviseur travaille par différence, y compris au passage du zéro, à condition d’interroger la station assez souvent pour que le compteur ne fasse jamais plus d’un tour entre deux relevés. C’est une contrainte de dimensionnement à garder en tête, côté période de scrutation comme côté trafic attendu.

Le choix d’un compteur sans remise à zéro rend aussi le système tolérant : si un relevé est perdu, rien n’est perdu avec lui, le suivant rattrape la différence.

Le dialogue DIASER

Toute la station se pilote par l’application « Mesure du trafic » de DIASER, identifiée par la lettre M. Chaque transaction est une question suivie d’une réponse, encadrée par les caractères de début et de fin de trame et un caractère de contrôle, avec des valeurs codées en hexadécimal ASCII. Le logiciel de la station répond en UDP.

Les fonctions prises en charge couvrent le cycle de vie complet d’une station. Une fonction de lecture se note en majuscule et sa forme d’écriture en minuscule, comme le veut DIASER.

Fonctions communes à toutes les applications (*)

Fonctions de l’application Mesures (M)

Les autres fonctions de l’application Mesures, comme la classification, les comptages différés ou la lecture multiple, ne sont pas encore prises en charge. La station y répond par le code d’erreur normalisé « code fonction non reconnu » plutôt que de rester muette, ce qui permet au superviseur de le détecter proprement.

Voici un échange typique, où le superviseur déclare un compteur de comptage sur la première entrée, puis le lit (valeurs données à titre d’exemple) :

Question  Mb 00 B1 00      déclare le compteur 0 : comptage, 1 entrée, entrée 0
Réponse   M!               acquittement
Question  MA               lecture des compteurs
Réponse   MA 02 1F 0C      2 compteurs : le premier à 0x1F, le second à 0x0C

La configuration et les valeurs des compteurs sont enregistrées dans des fichiers et restaurées au démarrage : un redémarrage de la passerelle ne fait ni perdre la programmation reçue du superviseur, ni repartir les compteurs de zéro.

Industrialiser la passerelle

Le logiciel se compile directement sur la passerelle, qui embarque son propre compilateur sous Debian. Pour déployer, nous préparons une image de référence une fois, puis nous la clonons sur la mémoire eMMC de chaque station en réglant l’ordre de démarrage dans le chargeur de démarrage. Une nouvelle station est ainsi prête sans reconfiguration manuelle, ce qui compte quand on en multiplie le nombre.

La suite : le débit classifié

Avec un couple de boucles par voie, on peut aller plus loin que le simple comptage et ranger chaque véhicule dans une classe de vitesse ou de longueur. C’est le développement que nous étudions, et la norme comme l’automate que nous remplaçons en fixent le principe.

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#eef0ff','primaryTextColor':'#27262b','primaryBorderColor':'#5c5adc','lineColor':'#8a8da8','secondaryColor':'#f4f5ff','tertiaryColor':'#f4f5ff','edgeLabelBackground':'#eef0ff','clusterBkg':'#f4f5ff','clusterBorder':'#5c5adc'}}}%%
flowchart LR
    V(["Véhicule<br/>sens de circulation"]) ==> P
    subgraph VOIE["Une voie de mesure"]
        direction LR
        P["Boucle principale<br/>entrée n"] ==>|"distance inter-boucles"| A["Boucle associée<br/>entrée n+1"]
    end
    A ==> F(["Fin de zone"])
    style V fill:#fff4e0,stroke:#e9a23b,color:#27262b
    style F fill:#f4f5ff,stroke:#8a8da8,color:#27262b
    style P fill:#e3f5ea,stroke:#2fb37a,color:#27262b
    style A fill:#eef0ff,stroke:#5c5adc,color:#27262b

• La vitesse découle du temps séparant les deux fronts montants, sur la boucle principale puis sur la boucle associée, rapporté à la distance qui les sépare.
• La longueur découle du temps de présence sur la boucle principale, combiné à cette vitesse.
• La prise en compte du véhicule se déclenche sur le front descendant de la boucle principale : c’est à cet instant que le compteur est incrémenté et que la classe est déterminée.

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#eef0ff','primaryTextColor':'#27262b','primaryBorderColor':'#5c5adc','lineColor':'#8a8da8','secondaryColor':'#f4f5ff','tertiaryColor':'#f4f5ff','edgeLabelBackground':'#eef0ff','clusterBkg':'#f4f5ff','clusterBorder':'#5c5adc'}}}%%
flowchart LR
    subgraph SV["1 · Mesure de la vitesse"]
        direction TB
        T1["t1<br/>front montant<br/>boucle principale"] --> T2["t2<br/>front montant<br/>boucle associée"]
        T2 --> VIT["Vitesse<br/>distance ÷ (t2 - t1)"]
    end
    subgraph SL["2 · Mesure de la longueur"]
        direction TB
        T3["t3<br/>front descendant<br/>boucle principale"] --> LON["Longueur<br/>présence × vitesse"]
    end
    SV ==> SL
    SL ==> PRI(["3 · Prise en compte<br/>compteur + 1<br/>classe de vitesse<br/>classe de longueur"])
    style T1 fill:#e3f5ea,stroke:#2fb37a,color:#27262b
    style T2 fill:#e3f5ea,stroke:#2fb37a,color:#27262b
    style T3 fill:#fde8e8,stroke:#e5484d,color:#27262b
    style VIT fill:#eef0ff,stroke:#5c5adc,color:#27262b
    style LON fill:#eef0ff,stroke:#5c5adc,color:#27262b
    style PRI fill:#fff4e0,stroke:#e9a23b,color:#27262b

Le superviseur ne déclare que l’entrée principale, l’entrée associée étant par convention la suivante. Il programme ensuite des histogrammes : chacun est rattaché à un compteur source et à un critère, classe de vitesse en km/h ou classe de longueur en décimètres, avec des bornes croissantes, la dernière classe n’ayant pas de limite haute. Le superviseur lit ces histogrammes en continu ; comme les compteurs de classes sont cumulatifs, il en tire le débit par classe par différence entre deux relevés, exactement comme pour le comptage simple.

Deux points de conception se dégagent :

• Les paramètres physiques restent locaux. La distance inter-boucles et la longueur de boucle ne passent pas par DIASER : l’automate d’origine les fait saisir dans son outil de programmation, par point de mesure. Notre station doit donc offrir sa propre configuration locale pour ces deux valeurs.
• La géométrie est un compromis. Une boucle longue améliore la précision, mais si elle est trop longue, deux véhicules qui se suivent de près l’occupent en même temps et faussent la mesure.

Une dernière particularité vaut d’être notée : la norme n’est pas parfaitement cohérente avec elle-même sur le codage du nombre de classes, selon qu’on lit le texte ou son exemple, et les automates du marché ont chacun leur convention. Une station de remplacement doit donc être validée contre le superviseur réel, en relisant systématiquement la configuration qu’il vient d’écrire.

Technologies

Siemens SIMATIC IOT2050, Debian (aarch64), C (threads POSIX, select(), sockets UDP), boucles inductives et détecteurs, DIASER (NF P 99-071, application Mesure du trafic).

Me contacter

Sur le terrain

À l’entrée de chaque trémie, une barrière automatique ferme la voie. À côté d’elle, des feux rouges clignotants de type R24 signalent l’interdiction d’accès, accompagnés du panneau « Rouge clignotant, accès interdit ». Ces feux sont raccordés à la barrière : le contrôleur se contente d’en déclencher le clignotement par un relais. Une caméra de vidéosurveillance, sur le réseau de la régulation, permet de vérifier l’état de l’ouvrage à distance.

Le matériel se résume à peu de choses : une barrière dont la lisse mesure 3 mètres, 8 mètres pour l’une des cinq trémies, un coffret de commande avec ses relais, un transformateur et des protections électriques, un commutateur industriel avec sa liaison fibre. Quatre coffrets suffisent pour cinq trémies, deux barrières voisines partageant le même.

Un contrôleur de feux utilisé comme automate

Le cœur d’un coffret est un contrôleur de feux. Mais ici il ne pilote aucun feu de circulation : il joue le rôle d’automate programmable qui commande la barrière. Conçu à l’origine pour la régulation du trafic, ce matériel implémente le protocole DIASER : il s’intègre ainsi au réseau de la régulation et se supervise comme n’importe quel autre contrôleur.

Cet usage particulier se voit dans sa configuration. On lui déclare deux lignes de feux fictives, sans charge, avec une matrice de dégagement nulle. Aucun rack de puissance n’est installé, puisqu’aucune ligne de feux réelle n’est pilotée : la gestion de la barrière n’en a pas besoin.

Ses entrées et sorties se limitent à l’essentiel :

La logique de la barrière tient en une phrase : un ordre à ON descend la barrière, un ordre à OFF la remonte. C’est la variable de commande, écrite par le portail, qui porte cet ordre.

Le portail de contrôle-commande

Le portail est l’unique point d’entrée pour commander les barrières. Deux familles d’utilisateurs s’en servent, chacune avec ses droits :

• le poste central de régulation, qui commande la descente de la barrière en cas d’urgence, de maintenance ou d’événement ;
• des intervenants externes, comme la police municipale ou une entreprise intervenant sur l’ouvrage, qui disposent d’un accès limité à la trémie qui les concerne.

Derrière le portail, un programme de pilotage dialogue avec chacun des contrôleurs.

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#eef0ff','primaryTextColor':'#27262b','primaryBorderColor':'#5c5adc','lineColor':'#8a8da8','secondaryColor':'#f4f5ff','tertiaryColor':'#f4f5ff','edgeLabelBackground':'#eef0ff','clusterBkg':'#f4f5ff','clusterBorder':'#5c5adc'}}}%%
flowchart TB
    subgraph USR["Utilisateurs"]
        REG["Poste central<br/>de régulation"]
        EXT["Intervenants externes<br/>police municipale · entreprises"]
    end
    subgraph DED["Portail de contrôle-commande · Debian"]
        WEB["Portail web PHP"] --> DB[("PostgreSQL")]
        DB <--> PIL["Programme de pilotage<br/>en C"]
    end
    subgraph TRE["Coffret de trémie"]
        CTL["Contrôleur<br/>utilisé comme automate"] --> REL["Relais"]
    end
    REL --> BAR["Barrière<br/>+ feux R24"]
    REG --> WEB
    EXT --> WEB
    PIL <-->|"DIASER · UDP · variable de commande"| CTL
    style BAR fill:#fde8e8,stroke:#e5484d,color:#27262b
    style DB fill:#e3f5ea,stroke:#2fb37a,color:#27262b

Le déroulé d’une fermeture

Pour chaque ordre reçu, le contrôleur déroule la même séquence. Un préavis de 6 secondes laisse aux usagers le temps de voir l’interdiction : les feux R24 clignotent avant que la barrière ne descende, jamais l’inverse.

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#eef0ff','primaryTextColor':'#27262b','primaryBorderColor':'#5c5adc','lineColor':'#8a8da8','secondaryColor':'#f4f5ff','tertiaryColor':'#f4f5ff','edgeLabelBackground':'#eef0ff','clusterBkg':'#f4f5ff','clusterBorder':'#5c5adc'}}}%%
flowchart LR
    subgraph ORD["1 · Ordre"]
        direction TB
        PORT["Portail<br/>variable DIASER"]
    end
    subgraph SEQ["2 · Séquence du contrôleur"]
        direction TB
        CTL["Contrôleur"] --> R24["Feux R24<br/>clignotement alterné"]
        R24 -->|"après 6 s"| REL["Relais de commande<br/>fermeture / ouverture"]
        REL --> BAR["Barrière automatique"]
    end
    subgraph RET["3 · Retour"]
        direction TB
        BUT["Butée basse ou haute<br/>atteinte"] --> RIN["Relais de retour<br/>d'information"]
        RIN --> VAR["Variable de retour<br/>lue par le portail"]
    end
    ORD ==> SEQ
    SEQ ==> RET
    style R24 fill:#fde8e8,stroke:#e5484d,color:#27262b
    style BAR fill:#fde8e8,stroke:#e5484d,color:#27262b
    style VAR fill:#e3f5ea,stroke:#2fb37a,color:#27262b

Le retour d’information est ce qui fait la différence entre un ordre envoyé et une barrière réellement en position : le portail lit la position atteinte, et non le simple fait que la commande a été émise.

Le pilotage : programme et interface

Un programme qui dialogue avec chaque contrôleur

Un programme écrit en C fait le lien entre la base de données du portail et le terrain. Il tourne en boucle, avec un cycle d’environ sept secondes. À chaque cycle, il relit la table des trémies, puis lance un fil d’exécution (thread) par trémie pour deux échanges successifs en DIASER sur UDP :

1. une lecture d’état du contrôleur, retentée trois fois à une demi-seconde d’intervalle avant de conclure à un défaut ;
2. l’envoi de la commande voulue par l’opérateur : blocage en ouverture ou en fermeture.

Les trames DIASER sont stockées en base, trémie par trémie. Modifier un ordre ou raccorder une sixième trémie ne demande pas de recompiler le programme.

Un journal qui ne garde que l’utile

Le programme ne journalise que les changements d’état, sous la forme « commande ouverture vers commande fermeture » ou « défaut de communication ». La date de dernière mise à jour ne change, elle aussi, que lorsque l’état change : un opérateur qui regarde l’écran sait depuis quand la barrière est dans cet état, et non l’heure du dernier échange.

L’interface

Pour chaque barrière, le portail affiche trois retours : le statut (absence de forçage ou forçage en fermeture), le retour de mode et le retour de communication (en service ou en défaut). Deux boutons commandent le blocage en ouverture ou en fermeture, chacun derrière une fenêtre de confirmation qui rappelle la conséquence de l’ordre avant tout envoi. L’écran se rafraîchit toutes les deux secondes, et chaque consultation ou commande est inscrite au journal de bord.

Ce que cela apporte

Une seule interface de contrôle-commande simplifie l’exploitation : un seul endroit pour commander, un seul journal, un seul retour d’état. Le portail ouvre un accès maîtrisé aux intervenants externes, avec des droits par rôle, et garde la trace de chaque commande, de chaque état et de chaque défaut de communication. Comme tous les ordres suivent le même chemin vers le même contrôleur, l’état réel de la barrière reste unique et sans ambiguïté.

Technologies

Contrôleur de carrefour à feux utilisé comme automate programmable, DIASER (UDP), barrière automatique et feux R24, relais 24 V, commutateur industriel et fibre optique, caméra IP, C (threads POSIX, sockets UDP), PHP, PostgreSQL, nginx, Debian.

Me contacter

Le besoin

Une caméra dotée d’une analyse vidéo embarquée sait compter les véhicules à l’arrêt dans une zone qu’on lui définit. Mais un compte de véhicules n’est pas un signal d’exploitation : MiVisu, le superviseur qui pilote le panneau d’alerte, attend un état net et stable, dans un protocole industriel. DAB fait ce travail de traduction : il reçoit les détections de la caméra, décide s’il y a bouchon, et expose le résultat en Modbus TCP.

DAB ne traite aucune image. Toute l’intelligence de détection reste dans la caméra ; DAB ne gère que la décision, l’historique et l’exposition.

La détection, dans la caméra

La règle de détection se programme directement dans l’interface d’analyse de la caméra, une SWISSTRAFFIC AI. On y dessine sur l’image la zone à surveiller, puis on assemble des opérateurs sous forme de graphe : la zone alimente un filtre de catégorie de véhicule, puis un opérateur de durée d’arrêt. Un véhicule qui reste immobile dans la zone plus longtemps que la durée programmée, 5 secondes dans cette configuration, déclenche une détection. C’est ce nombre de véhicules détectés que la caméra remonte à DAB.

Architecture

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#eef0ff','primaryTextColor':'#27262b','primaryBorderColor':'#5c5adc','lineColor':'#8a8da8','secondaryColor':'#f4f5ff','tertiaryColor':'#f4f5ff','edgeLabelBackground':'#eef0ff','clusterBkg':'#f4f5ff','clusterBorder':'#5c5adc'}}}%%
flowchart TB
    CAM["Caméra SWISSTRAFFIC AI<br/>zone de détection<br/>véhicule à l'arrêt > durée programmée"] -->|"HTTP POST JSON<br/>(webhook)"| WEB
    subgraph SRV["Serveur DAB · Debian"]
        WEB["nginx + PHP-FPM<br/>logique de décision"] -->|"écriture"| DB[("SQLite<br/>mode WAL")]
        DB -->|"lecture toutes les secondes"| MB["dab-modbus<br/>serveur Modbus C · libmodbus"]
        UI["Interface web<br/>supervision · historique<br/>forçage · rôles"] <--> DB
    end
    MB -->|"Modbus TCP · fonction 2<br/>1 bit par site"| MIV["MiVisu<br/>superviseur · LABOCOM"]
    MIV -->|"LCR"| PAN["Panneau de police dynamique<br/>pictogramme BOUCHON"]

Côté DAB, la chaîne tient en quatre maillons :

• La caméra notifie DAB par un message JSON qui porte l’identifiant du site et le nombre de véhicules détectés.
• L’ingestion est assurée par nginx (POST uniquement, taille des requêtes bornée) puis PHP-FPM. Un identifiant de site inconnu est rejeté : seuls les sites déclarés dans l’interface sont acceptés.
• L’état est stocké dans SQLite en mode WAL, partagé entre PHP et le serveur Modbus : une ligne par site pour l’état courant, une table d’historique à part.
• L’exposition est confiée à un logiciel dédié, écrit en C, qui lit l’état et le publie sur le port Modbus.

Une décision asymétrique

La règle de décision tient en deux phrases : dès qu’au moins un véhicule à l’arrêt est détecté, le site passe en BOUCHON immédiatement ; il ne retombe en LIBRE qu’après un délai sans aucune détection, de l’ordre de la minute et réglable dans l’interface.

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#eef0ff','primaryTextColor':'#27262b','primaryBorderColor':'#5c5adc','lineColor':'#8a8da8','secondaryColor':'#f4f5ff','tertiaryColor':'#f4f5ff','edgeLabelBackground':'#eef0ff','clusterBkg':'#f4f5ff','clusterBorder':'#5c5adc'}}}%%
flowchart LR
    LIBRE(["LIBRE"]) -->|"véhicule à l'arrêt détecté<br/>(immédiat)"| BOUCHON(["BOUCHON"])
    BOUCHON -->|"nouvelle détection :<br/>le délai repart à zéro"| BOUCHON
    BOUCHON -->|"aucune détection pendant<br/>le délai d'hystérésis"| LIBRE
    style LIBRE fill:#e3f5ea,stroke:#2fb37a,color:#27262b
    style BOUCHON fill:#fde8e8,stroke:#e5484d,color:#27262b

L’hystérésis ne porte donc que sur la retombée. Sans elle, un véhicule qui redémarre, une occultation passagère ou une mesure à zéro entre deux voitures ferait osciller le bit, et donc l’affichage du panneau. Avec elle, DAB ne retarde jamais l’alerte, et seul le retour à la normale est lissé.

Trois détails de conception comptent :

• Le retour à LIBRE est géré côté serveur. En plus de la logique du webhook, le serveur Modbus vérifie lui-même chaque seconde si le délai d’hystérésis est écoulé : un site ne reste donc pas bloqué en BOUCHON si la caméra cesse d’émettre.
• La vie de la caméra est suivie, à titre informatif. Chaque trame reçue, y compris une simple trame de vie sans comptage de véhicules, rafraîchit l’horodate du site. L’interface en déduit un état (en ligne, silencieuse, hors ligne) d’après l’âge de la dernière trame, visible dans la surveillance et dans la table de correspondance Modbus. Cet indicateur alerte l’exploitant mais n’agit pas sur le bit exposé, qui ne dépend que des détections et du forçage.
• Seules les transitions sont journalisées, pas chaque mesure. L’historique reste compact et chaque ligne correspond à un événement qu’un exploitant peut lire.
• Un forçage manuel par site (automatique, libre ou bouchon) prend le pas sur la détection, y compris sur le bit exposé en Modbus. Il est réservé au rôle administrateur, protégé contre le CSRF, et tout changement d’état qu’il provoque est tracé dans l’historique. Il permet par exemple de tester la chaîne de bout en bout avec le superviseur sans attendre un vrai bouchon, ou de neutraliser un site le temps d’une intervention.

Le serveur Modbus en C

Modbus TCP demande un serveur à l’écoute en permanence sur le port 502, avec des connexions persistantes : ce n’est pas le métier de PHP-FPM. D’où un logiciel dédié, écrit en C et construit sur libmodbus.

Il tient une boucle select() qui sert plusieurs clients simultanés, relit la base chaque seconde, et alimente deux tables en mémoire : les Discrete Inputs (fonction 2), un bit par site à l’adresse choisie dans l’interface, et un miroir en Holding Registers (fonction 3) pour tolérer un client Modbus mal configuré qui interrogerait en lecture de registres. Voici l’échange pour huit sites, où seul le site d’adresse 0 est en BOUCHON (unit id 1 à titre d’exemple) :

Requête   00 01 00 00 00 06 01 02 00 00 00 08   lecture de 8 entrées à partir de l'adresse 0
Réponse   00 01 00 00 00 04 01 02 01 01         1 octet de données : bit 0 à 1

Quelques choix d’exploitation :

• Le statut du serveur (PID, durée de fonctionnement, dernière lecture de la base, nombre de sites) est écrit dans un fichier JSON de façon atomique, par écriture dans un fichier temporaire puis renommage, pour que l’interface web ne lise jamais un fichier à moitié écrit.
• Il s’arrête proprement sur SIGTERM et ignore SIGPIPE, pour qu’une déconnexion brutale d’un client ne le fasse pas tomber.
• L’unité systemd est durcie : utilisateur non privilégié, NoNewPrivileges, PrivateTmp, système de fichiers en lecture seule hors des deux répertoires de travail, et la capacité CAP_NET_BIND_SERVICE pour écouter sur le port 502 sans être root.

En aval : MiVisu et le panneau

DAB ne pilote aucun panneau : il ne connaît ni l’équipement ni son protocole. C’est le superviseur MiVisu, édité par la société LABOCOM, qui s’en charge. MiVisu scrute l’état de chaque site de détection en Modbus TCP auprès de DAB, puis commande en LCR un panneau de police dynamique. Quand un site passe en BOUCHON, le panneau affiche à l’attention des usagers un pictogramme de danger représentant une file de véhicules, avec la mention BOUCHON.

Cette séparation garde DAB indépendant du panneau : changer d’afficheur n’oblige pas à toucher à la détection.

L’interface d’exploitation

L’interface web, en PHP, couvre l’ensemble de la vie du système :

• un tableau de bord : sites surveillés, bouchons actifs, voies libres, état du serveur Modbus ;
• une surveillance en temps réel, rafraîchie toutes les 5 secondes, avec l’état de chaque caméra ;
• un historique des transitions avec graphiques ;
• une page Interface Modbus : paramètres d’écoute et table de correspondance entre chaque adresse et l’état du site, avec la valeur réellement exposée ;
• la configuration des sites (identifiant de la caméra, nom, adresse Modbus, unique par site) et le réglage de l’hystérésis ;
• la gestion des utilisateurs avec trois rôles : administrateur, opérateur, lecteur.

Côté réseau, nginx limite le débit des tentatives de connexion et des appels d’API, applique HSTS, et refuse l’accès direct à la configuration et aux fichiers cachés.

Technologies

Analyse vidéo embarquée (caméra SWISSTRAFFIC AI), HTTP (webhook JSON), Modbus TCP (fonctions 2 et 3), LCR (panneau, via MiVisu), nginx, PHP-FPM, SQLite (WAL), C (libmodbus), systemd, Debian.

Me contacter

Le besoin

Le parking est découpé en trois zones : Collaborateur, Visiteur et PMR. Sans visibilité sur les places libres, on tournait pour rien, surtout aux heures d’affluence. L’idée de départ était simple : un capteur par place, un panneau à l’entrée qui indique combien de places restent dans chaque zone.

La solution

Chaque place reçoit un capteur LoRaWAN à détection magnétique et radar 60 GHz (référence SPS200, IP68, IK7), qui combine les deux techniques pour fiabiliser la détection quelle que soit la météo, et remonte son état par radio avec sa charge de batterie, jusqu’à dix ans d’autonomie annoncés. Les trames sont captées par une antenne fibre de verre omnidirectionnelle 8 dBi, IP67, reliée à une passerelle LoRaWAN qui fait aussi office de concentrateur sur site (modèle OptimaGate, alimentée en PoE). Ces mesures arrivent ensuite sur notre superviseur, qui les enregistre et recalcule en continu le nombre de places libres par zone. Un panneau d’affichage à l’entrée du site montre ce compte en temps réel, zone par zone, jusqu’à afficher « COMPLET » quand il n’y a plus de place.

flowchart LR
    A["Capteur LoRaWAN<br/>magnétique + radar 60 GHz<br/>SPS200 · IP68 / IK7"] -->|"LoRaWAN 868 MHz"| B["Antenne 8 dBi<br/>omnidirectionnelle · IP67"]
    B --> C["Passerelle LoRaWAN<br/>OptimaGate · PoE"]
    C -->|"HTTP webhook"| D["Superviseur<br/>nginx + PHP + PostgreSQL<br/>VM Debian 13 sur Proxmox VE"]
    D -->|"TCP 4001 · LCR NF P99-341"| E["Panneau d'affichage<br/>3 modules × 7 caractères"]

Comment ça fonctionne

Le capteur envoie une trame à chaque changement d’état (véhicule détecté ou parti), pas en continu : ça préserve sa batterie, pensée pour durer plusieurs années. Côté serveur, chaque trame devient une ligne dans une table d’événements, jamais écrasée : on peut ainsi reconstruire l’historique d’occupation d’une place, pas seulement son état du moment. Ce service tourne dans une VM Debian 13, sur un hyperviseur Proxmox VE.

Le panneau d’affichage, lui, pose un problème différent : il doit toujours montrer une valeur juste, même si le réseau a un accroc. Il est composé de trois modules de sept caractères, un par zone, pilotés en TCP par le protocole LCR (Langage de Commande Routier, norme NF P99-341), chez le fabricant TTS. Le panneau ne fait aucune intelligence : il affiche tel quel ce qu’on lui envoie, une trame texte par zone :

PA AM=1.0 AF="9 LIBRE" EC=AU AT=0 CL=0 AM=2.0 AF="1 LIBRE" EC=AU AT=0 CL=0 AM=3.0 AF="COMPLET" EC=AU AT=0 CL=0

Cette trame est renvoyée toutes les 3 secondes, qu’elle ait changé ou non : c’est ce battement régulier, plus que le calcul d’occupation lui-même, qui garantit qu’un panneau ne reste jamais figé sur une ancienne valeur après un accroc réseau.

Maintenir cet affichage synchronisé, sans jamais laisser une ancienne valeur s’y figer, s’est révélé être la partie la plus délicate du projet, bien plus que le calcul d’occupation lui-même : un panneau qui affiche une information fausse est pire qu’un panneau éteint.

Ce qu’on en a retenu

Ce premier déploiement, grandeur nature et sur notre propre terrain, a posé des questions qu’on n’aurait pas anticipées sur le papier : que faire d’un capteur dont la batterie faiblit ? Comment distinguer un capteur en maintenance d’un capteur en panne ? Comment garantir qu’un panneau ne reste jamais bloqué sur une ancienne valeur ?

Ce sont ces questions, pas la technologie LoRa elle-même, qui ont façonné la suite : un compteur de places libres est un cas particulier d’un problème plus général, celui de superviser n’importe quel équipement de terrain de façon fiable.

Et aujourd’hui

Cette première brique a donné naissance à CiteosVision, la même plateforme qui supervise aujourd’hui notre éclairage public. Le principe reste le même : un cœur générique qui ne connaît que des équipements, des mesures et des commandes, et des connecteurs qui dialoguent chacun dans le protocole du terrain, qu’il s’agisse d’un capteur de parking, d’un point lumineux ou d’une caméra.

Le parking, lui, continue de tourner : la carte ci-dessous montre l’état de chaque place en temps réel, capteur par capteur.

Technologies

LoRaWAN, HTTP (webhook), TCP, LCR (NF P99-341), nginx, PHP, C, PostgreSQL, Debian, Proxmox VE.

Me contacter

Mon métier a une particularité : il se situe entre l’ingénierie de trafic et le développement logiciel. Peu de gens font les deux, et c’est pourtant là que naissent les solutions les plus utiles. Quand on comprend le terrain et qu’on sait aussi écrire le logiciel, on peut construire l’outil exact dont les exploitants ont besoin, au lieu de contourner celui qu’on nous vend.

Je voudrais donc partager ici :

• des retours d’expérience sur des projets de régulation, de supervision et d’équipements de voirie ;
• des idées de conception : comment rendre une supervision fiable, comment faire cohabiter plusieurs protocoles, comment tenir quand la liaison coupe ;
• des essais et des passions : ce que je construis parce que j’ai envie de comprendre, pas parce qu’on me l’a demandé.

Ce que vous ne trouverez pas ici

Aucune donnée confidentielle : ni données de clients ou d’utilisateurs, ni informations d’exploitation sensibles, ni secrets d’accès. Je reste sur le terrain technique : les architectures, les protocoles et les choix de conception.

La suite

Les prochains articles parleront de supervision, de protocoles et de choix techniques faits sur des projets réels. Si un sujet vous intéresse, ou si vous travaillez sur des problèmes proches, contactez-moi via la page Contact : les meilleures idées viennent souvent d’une conversation.

Me contacter