Le SCADA sans bibliothèque de symboles

L’écran ci-dessous représente une station de relevage des eaux usées : une fosse, deux pompes, une vanne de refoulement, le débit et la pression en direct, des commandes opérateur avec étape de confirmation, une liste d’alarmes et une tendance de niveau. Le tout tient dans un seul Custom Widget, sur un dashboard TagoIO. TagoAI l’a écrit à partir d’une description rédigée, et l’ensemble du montage, y compris le simulateur qui l’anime, a pris un après-midi.

Cet article présente ce que montre l’écran, la façon dont les données et les commandes circulent dans la plateforme, et comment construire la même chose sur votre propre compte. Le premier prompt que nous avons donné à TagoAI figure plus bas : servez-vous-en comme point de départ et remplacez nos équipements par les vôtres.

Pourquoi TagoIO n’a pas de bibliothèque de symboles

Depuis des décennies, on dessine les écrans SCADA de la même façon : une bibliothèque de symboles (cuves, pompes, vannes), un canevas à coordonnées fixes et une boîte de dialogue de liaison pour chaque symbole. C’est la bibliothèque qui fixe la limite. Chaque équipement que l’éditeur n’a pas dessiné devient un chantier de développement, en général de l’édition SVG plus une couche de script que seul cet outil comprend.

TagoIO n’a jamais proposé de bibliothèque de symboles, et nous n’en proposerons pas. Un Custom Widget peut être un composant React que la plateforme empaquette et héberge, avec des hooks qui livrent les données des appareils en direct et qui écrivent les commandes en retour. Depuis juillet 2026, TagoAI écrit ces composants à partir d’un prompt, dans son panneau de chat sur le dashboard. Un P&ID devient une description : “une fosse avec deux pompes, une vanne de refoulement et un transmetteur de pression sur le collecteur”. L’équipement atypique qu’exploite votre client devient une phrase de plus. Le synoptique s’adapte seul à la place disponible parce que c’est du SVG dans un seul widget : aucune grille à colonnes fixes à gérer.

Le compromis est clair. Vous n’obtenez pas 100 symboles à faire glisser. Vous obtenez un écran dessiné pour votre procédé, dans le style qu’attendent vos opérateurs, et que vous modifiez en décrivant la modification.

Ce que montre l’écran

Le synoptique suit les principes de l’IHM haute performance : un fond neutre, des équipements gris et la couleur réservée aux états. Le cyan signale le liquide, l’écoulement, une vanne ouverte ou un moteur en marche. L’ambre et le rouge sont réservés aux alarmes, aux seuils d’alarme et aux avertissements, si bien qu’un problème se détache de tout le reste de l’écran.

Fosse. Le remplissage de la fosse suit le niveau, avec une petite vague en surface. Des lignes en pointillés marquent la consigne (SP) et les seuils d’alarme haut et bas (HH, LL). Le grand chiffre est la mesure du transmetteur de niveau LT-101.

Pompes P-101 et P-102. La roue tourne tant que la pompe est en marche, et l’étiquette affiche le courant moteur. En cas de défaut, la pompe passe au rouge avec un anneau pulsant, et le bouton Reset fault remplace les boutons Start et Stop.

Vanne V-101 et collecteur. Une pompe en marche anime ses propres conduites, et le collecteur ne s’anime que lorsque la vanne est ouverte. Arrêtez les deux pompes et le collecteur s’immobilise. PT-101 affiche la pression de refoulement, FT-102 le débit sortant, et une pression supérieure à 5,5 bar fait passer l’instrument à l’ambre.

Commandes opérateur. Start et Stop pour chaque pompe, Open et Close pour la vanne, et un réglage pas à pas de la consigne. Chaque commande demande une confirmation, puis une commande de pompe ou de vanne affiche PENDING jusqu’à ce que le terrain renvoie le nouvel état ou que 20 secondes se soient écoulées. Les commandes d’équipement sont verrouillées tant que la station est en AUTO ; la consigne reste modifiable.

Alarmes et tendance. Les alarmes actives sont déduites des valeurs en direct : niveau au-dessus de HH, niveau sous LL, pompe en marche vanne fermée, défaut variateur ou aucune donnée depuis 30 minutes. En dessous figure l’historique des alarmes avec leur état d’acquittement, et un bouton Acknowledge dans l’en-tête du panneau acquitte toutes les entrées d’un coup. La tendance affiche les quatre dernières heures de niveau, avec les mêmes repères SP, HH et LL.

En-tête. Le commutateur AUTO/MANUAL, un indicateur de fraîcheur des données qui affiche l’âge de l’enregistrement le plus récent reçu par le widget, et un compteur d’alarmes qui clignote tant qu’une alarme de gravité élevée est active.

Comment ça fonctionne

Tout ce qui apparaît à l’écran est une variable de l’appareil, et chaque commande est un enregistrement de l’appareil. Le widget ne se fie jamais à son propre clic sur une pompe ou une vanne : il passe l’équipement en PENDING et attend que l’état revienne du terrain.

L’appareil Pump Station 01 contient toutes les valeurs affichées : wet_well_level avec sa consigne et ses seuils, inflow, outflow, discharge_pressure, l’état, le courant et le temps de fonctionnement de chaque pompe, valve_state, station_mode, et les événements d’alarme avec leurs acquittements. Le widget lit ces variables, telles qu’elles sont liées dans ses sources de données, avec le hook useRealtimeData du SDK Custom Widget de TagoIO. Au chargement, il reçoit les derniers enregistrements stockés, dans la limite du nombre d’enregistrements fixée sur le widget, puis chaque nouvel enregistrement dès son arrivée : la tendance, les alarmes actives et les marqueurs PENDING sont tous calculés à partir d’un seul flux.

Les commandes font le chemin inverse. Quand l’opérateur confirme Start sur P-102, le widget appelle sendData du hook useSendData avec { variable: "pump_2_cmd", value: "start" }. Le dashboard écrit cet enregistrement sur l’appareil et, comme le widget est configuré pour exécuter une Analysis quand il envoie des données, lance Pump Station Controller avec cet enregistrement comme scope. C’est dans l’Analysis que se trouve la vraie commande terrain : une publication MQTT, un downlink LoRaWAN, une commande TagoTiP via MQTT ou un appel HTTP vers une passerelle. Dans la démo, elle simule aussi la réponse du procédé, si bien que le niveau bouge et que les pompes changent d’état sans aucun matériel.

Les alarmes reposent sur les mêmes enregistrements. À chaque exécution, l’Analysis écrit un événement d’alarme pour toute condition devenue vraie depuis son exécution précédente ; l’alarme d’absence de données reste gérée par le widget. Le widget déduit la liste des alarmes actives des valeurs en direct et marque une entrée de l’historique comme acquittée quand un enregistrement alarm_ack est plus récent que l’événement.

Construisez votre propre IHM

Il vous faut un compte TagoIO avec TagoAI activé sur le profil (Profile Settings, Services, AI Provider), et environ une heure. Aucun matériel n’est nécessaire pour un premier essai : l’Analysis simule la station.

1. Créez l’appareil. Pour une station simulée, choisissez Custom HTTPS : il ne demande aucun numéro de série, et son parser laisse vos enregistrements tels que vous les envoyez. Optez pour le stockage mutable afin de pouvoir modifier les valeurs à la main par la suite. Envoyez un premier jeu d’enregistrements avec les noms de variables qu’utilise ce montage : wet_well_level, level_setpoint, level_high_alarm, level_low_alarm, inflow, outflow, discharge_pressure, pump_1_state, pump_1_speed, pump_1_current, pump_1_runtime, les quatre mêmes pour la pompe 2, valve_state, station_mode, alarm, alarm_ack et alarm_state. Quelques dizaines de points wet_well_level répartis sur les dernières heures donnent à la tendance de quoi tracer.
2. Créez un dashboard Normal et ouvrez le panneau TagoAI. Collez le prompt ci-dessous en y indiquant le nom de votre appareil, puis envoyez-le. TagoAI crée le Custom Widget, écrit le code et configure ses sources de données. Affinez ensuite par chat : “agrandis les pompes”, “place les alarmes au-dessus de la tendance”, “utilise nos noms de tags”.
3. Vérifiez les liaisons. Ouvrez les réglages du widget et assurez-vous que les sources de données listent chaque variable que l’écran lit et chaque commande qu’il écrit (pump_1_cmd, pump_2_cmd, pump_1_reset, pump_2_reset, valve_cmd, level_setpoint, station_mode, alarm_ack), et qu’elles chargent assez d’enregistrements pour remplir la tendance sur quatre heures. Une variable non liée est perdue sans avertissement quand le widget l’envoie.
4. Créez l’Analysis de pilotage. Runtime Deno ou Node, avec le token de l’appareil en variable d’environnement. Lisez la dernière valeur de chaque variable d’état, appliquez les commandes reçues dans le scope, envoyez la commande terrain et réécrivez le nouvel état. Sélectionnez cette Analysis dans l’option “Run analysis when sending data” du widget. Pour une démo, ajoutez une étape de simulation afin que le niveau réagisse aux pompes.
5. Ajoutez un widget Input Control sous l’IHM, avec des champs texte pour les variables de procédé. Saisir fault dans pump_1_state ou 90 dans wet_well_level est le moyen le plus rapide de tester à l’écran les états des équipements et des alarmes.
6. Dimensionnez le widget. Pleine largeur et environ 800 px de haut, avec Background réglé sur transparent, Disable shadow activé et Header visibility sur Show only buttons. Un bouton d’en-tête qui exécute l’Analysis avec un scope vide constitue une commande pratique pour “faire avancer la simulation”.

Le prompt dont nous sommes partis, prêt à être adapté :

Crée une IHM de type SCADA pour une station de relevage des eaux usées, sous la forme d'un seul widget qui occupe tout le dashboard, pour l'appareil Pump Station 01. Style IHM haute performance en thème sombre : fond neutre, équipements gris, couleur réservée aux états et aux alarmes.

Dessine un synoptique SVG du procédé : une fosse qui affiche wet_well_level sous forme de remplissage, avec une ligne de consigne (level_setpoint) et des lignes d'alarme haute et basse (level_high_alarm, level_low_alarm) ; une conduite d'arrivée avec inflow ; deux pompes centrifuges P-101 et P-102 dont l'affichage suit pump_1_state et pump_2_state (running, stopped, fault), avec une roue qui tourne quand la pompe est en marche et des étiquettes pump_1_current / pump_2_current ; un collecteur de refoulement avec la vanne V-101 (valve_state open ou closed), le transmetteur de pression PT-101 (discharge_pressure) et le débitmètre de sortie FT-102 (outflow). N'anime l'écoulement que dans les conduites où le fluide circule.

Ajoute un panneau opérateur : boutons Marche et Arrêt pour chaque pompe (envoie pump_1_cmd ou pump_2_cmd = start ou stop), Ouvrir et Fermer pour la vanne (envoie valve_cmd), un réglage pas à pas de la consigne qui envoie level_setpoint, et un commutateur AUTO/MANUAL (envoie station_mode) qui verrouille les commandes d'équipement en AUTO. Chaque commande passe par une étape de confirmation, puis par un état EN ATTENTE jusqu'à ce que l'appareil renvoie la nouvelle valeur.

Ajoute un panneau d'alarmes : les alarmes actives déduites des valeurs en direct (niveau au-dessus du seuil haut, niveau sous le seuil bas, pompe en marche alors que la vanne est fermée, défaut pompe, aucune donnée depuis 30 minutes), et l'historique de la variable alarm avec l'état d'acquittement ; un bouton Acquitter envoie alarm_ack. Ajoute un bandeau de KPI (inflow, outflow, pression, courants moteur, heures de marche) et une tendance du niveau sur quatre heures, avec les mêmes lignes de consigne et de seuils.

Le résultat de TagoAI varie d’une exécution à l’autre, et la précision du prompt compte. Demandez une seule modification à la fois et gardez des noms de tags cohérents avec l’appareil : la plupart des ratés viennent d’une variable nommée d’une façon dans le prompt et d’une autre sur l’appareil.

De la démo à l’exploitation

Remplacez le simulateur. Gardez l’Analysis, supprimez l’étape de simulation et l’état qu’elle réécrit, et dirigez la commande terrain vers votre passerelle : un topic MQTT auquel l’automate (PLC) est abonné, un downlink LoRaWAN ou une commande TagoTiP via MQTT. L’appareil reçoit alors son état de l’automate, et l’écran ne change pas. Créez l’appareil de production en stockage Hybrid : un appareil mutable contient au maximum 50 000 enregistrements, alors qu’un appareil Hybrid envoie les mesures vers une partie immuable et garde les commandes et les consignes modifiables.

Servez tout un parc avec un seul écran. Construisez le même widget sur un Blueprint Dashboard. Le widget se lie à un appareil Blueprint et se résout sur la station que l’utilisateur sélectionne : une seule IHM couvre ainsi toutes les stations de relevage de l’exploitant. Affichez la station sélectionnée dans l’en-tête, et faites agir l’Analysis sur l’appareil dont provient chaque commande, pas sur un appareil fixe.

Donnez l’écran aux opérateurs dans TagoRUN. Les Custom Widgets fonctionnent dans les portails TagoRUN. Livrez l’IHM dans votre application à votre marque, avec Access Management pour décider quels utilisateurs voient quelles stations. Chaque commande envoyée par un opérateur est un enregistrement horodaté, stocké sur l’appareil : l’historique des commandes fait partie des données de la station elle-même.

Alertez au-delà de l’écran. Faites aussi exécuter l’Analysis par une Action sur la télémétrie entrante, pour que les enregistrements d’alarme soient écrits même quand personne ne clique. Une Action sur la variable alarm envoie alors une notification push, un webhook, ou des e-mails et des SMS via votre compte SMTP, SendGrid ou Twilio, dès qu’un nouvel enregistrement d’alarme est écrit. Une Action planifiée peut aussi exécuter l’Analysis pour déclencher l’escalade d’une alarme qui reste non acquittée.

Ne laissez pas l’écran mentir. Le widget affiche l’âge de l’enregistrement le plus récent qu’il a reçu et lève une alarme d’absence de données après 30 minutes sans enregistrement. Sur une vraie station, ne comptez que la télémétrie terrain dans le calcul de cet âge : une IHM qui paraît à jour alors que la liaison est coupée est pire qu’un écran vide.

Dessinez votre procédé

Ouvrez un dashboard Normal ou Blueprint, cliquez sur l’icône TagoAI, collez le prompt et remplacez nos tags par les vôtres. Un parc de réservoirs, une centrale d’eau glacée, un skid de compression ou une ligne de conditionnement suivent le même modèle : des variables en entrée, des commandes en sortie via une Analysis, et un écran décrit en langage courant.

Pour les détails, consultez la présentation du Custom Widget, le guide des IHM de type SCADA et la documentation TagoAI, puis publiez l’écran que vous aurez construit sur la communauté TagoIO. Nous avons hâte de le voir.