Contrôle d'accès des trémies : un portail pour piloter les barrières
Une trémie est un passage routier en contrebas, sous un ouvrage ou une voie. Il faut pouvoir en interdire l’accès vite, à distance, sans qu’un agent ait à se déplacer : en cas d’urgence, pour une opération de maintenance ou à l’occasion d’un événement. Pour cinq trémies d’une métropole, nous avons déployé des barrières automatiques commandées par un contrôleur, et un portail de contrôle-commande pour les piloter à distance.
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 :
| Type | Désignation | Rôle |
|---|---|---|
| Entrée | Retour d’ouverture | Retour de position de la barrière, remonté au portail |
| Entrée | Commande manuelle locale | Permet à un agent d’agir sur place, sans passer par le réseau |
| Sortie | Relais d’ouverture / fermeture | Commande la montée ou la descente de la lisse |
| Sortie | Relais de clignotement | Active les feux R24 avant la descente de la barrière |
| Variable DIASER | Variable de commande | Ordre de montée ou de descente, écrit par le portail |
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
| Ordre | Étapes |
|---|---|
| Fermeture | 1. Les feux R24 se mettent à clignoter. 2. Après 6 secondes, le relais commande la fermeture et la barrière descend. 3. À la butée basse, le retour d’information remonte au portail. |
| Ouverture | 1. Le relais commande l’ouverture et la barrière monte. 2. À la butée haute, le retour d’information remonte au portail et les feux R24 s’éteignent. |
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 :
- une lecture d’état du contrôleur, retentée trois fois à une demi-seconde d’intervalle avant de conclure à un défaut ;
- 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.