Horodatage, dérive NTP et recalage des historiques : fiabiliser la chronologie des événements entre automates, télégestion et SCADA

Construire une chronologie d'événements fiable

Pourquoi le temps est une donnée d'exploitation

Dans un SI industriel distribué (automates/PLC, RTU de télégestion, capteurs IIoT, SCADA, historien, applications de reporting), la chronologie est une donnée métier : quel événement est survenu en premier, à quel instant, et selon quelle référence de temps. Cette question devient critique dès que l'on analyse des enchaînements rapides (front d'alarme, démarrage/arrêt d'équipement, bascule d'alimentation, ouverture/fermeture de vanne) ou que l'on doit reconstituer un incident.

En pratique, l'horodatage se fragilise lorsque l'architecture combine : équipements de générations différentes, liaisons radio/cellulaires, réseaux segmentés (VLAN, pare-feu, NAT, VPN), et plusieurs couches applicatives (acquisition, supervision, historisation, BI). On observe alors des dérives d'horloge, des resynchronisations brutales, des timestamps non comparables, et des historiques difficiles à exploiter.

Cet article présente les causes typiques des incohérences temporelles (NTP/PTP, latence, gigue, polling, buffers, pertes de liaison), puis une démarche robuste pour fiabiliser l'ordre des événements et recaler des historiques de manière traçable, notamment dans des contextes eau/assainissement et infrastructures où l'auditabilité est un prérequis.

Comprendre la dérive NTP sur le terrain

Multiples horloges et absence de gouvernance

Dans une chaîne typique, on trouve au minimum l'horloge de l'automate, celle du RTU/poste de télégestion, celle du serveur SCADA, celle de l'historien et parfois celle du client HMI (web). Sans politique claire (référence unique + contrôle), chaque composant « donne l'heure » avec sa propre dérive.

Les dérives des horloges locales (RTC) sont souvent sous-estimées. Température, vieillissement et qualité d'oscillateur peuvent générer des écarts suffisants pour inverser l'ordre apparent d'événements sur quelques jours (ex. déclenchement et retour d'alarme, microcoupures, transitions proches).

NTP : un protocole robuste, mais sensible au réseau

Le NTPv4 (RFC 5905) est largement utilisé, mais sa précision dépend fortement de la symétrie des temps de trajet aller/retour, de la stabilité de la latence (gigue) et de la disponibilité d'une source de temps fiable (stratum). En télégestion, l'UDP/123 peut être filtré, la connectivité peut être intermittente, et l'offset devient instable.

Conséquence opérationnelle : un client NTP peut appliquer un step (saut d'horloge) lors d'un rattrapage, ce qui crée des trous, des doublons ou des « retours en arrière » dans les historiques si l'historisation n'est pas conçue pour gérer ces discontinuités.

PTP/IEEE 1588 : très précis, mais exigeant

Le PTP est normalisé par IEEE 1588. Il permet des précisions sub-millisecondes, pertinentes pour les usages SOE (Sequence Of Events) et certains environnements (process, énergie). Toutefois, un déploiement bout-en-bout nécessite souvent des équipements réseau compatibles (boundary/transparent clocks) et une architecture maîtrisée. Dans une architecture mixte IT/OT, un seul segment non compatible peut dégrader ou interrompre la synchronisation PTP.

Mesure vs collecte : l'erreur classique

Deux instants différents, deux vérités différentes

De nombreuses architectures confondent : (1) le temps de mesure (quand la valeur ou l'événement est produit à la source) et (2) le temps de collecte (quand la supervision l'acquiert). En mode polling, le SCADA horodate souvent à la réception : si l'événement survient entre deux scrutations, il est daté au prochain cycle. Sur un réseau congestionné, l'événement est daté encore plus tard, ce qui fausse l'analyse de causalité (ex. niveau haut vs démarrage pompe).

Cas OPC UA : structurer les timestamps

Quand l'acquisition passe par OPC UA, la distinction est formalisée : SourceTimestamp (temps côté source) et ServerTimestamp (temps côté serveur). La spécification précise notamment la gestion du SourceTimestamp, ainsi que la présence des champs SourceTimestamp et ServerTimestamp dans les DataValue. Exploiter correctement ces deux dates est une base pour objectiver latence et qualité temporelle.

Buffers, store-and-forward et reconnect

Pourquoi les événements « arrivent en retard »

En télégestion multi-sites, les ruptures de communication sont normales. Les RTU ou passerelles appliquent souvent un buffer local et un mode store-and-forward : les événements sont stockés puis remontés en rafale à la reconnexion. Sans stratégie explicite, on obtient :

• des événements horodatés à la réception (tout semble simultané) ;
• des événements horodatés à la source mais avec une horloge dérivée ;
• des mélanges (inversions temporelles, doublons, trous) difficiles à expliquer en audit.

Traçabilité : exigences et cadre de preuve

Exploitation, audit et cohérence temporelle

Selon les secteurs, l'exploitant doit produire des analyses d'incident, des bilans d'exploitation et justifier des délais de réaction. Une chronologie contestable fragilise les KPI et les dossiers d'audit.

Important : l'horodatage « process/OT » (NTP/PTP interne) vise la cohérence technique des événements. Pour des exigences de preuve juridique liées à des transactions électroniques, le cadre européen règlement (UE) n° 910/2014 (eIDAS) décrit notamment l'horodatage électronique qualifié et ses effets. Ce n'est pas la cible principale d'un SCADA, mais c'est un repère utile pour distinguer « cohérence d'exploitation » et « service de confiance » (la doctrine et les exigences associées sont synthétisées côté France par l'ANSSI).

Mettre en place une synchronisation robuste

Définir une référence de temps et une hiérarchie

La première étape est une décision d'architecture : choisir une référence (NTP interne redondé, GNSS/GPS sur site critique, grandmaster PTP) et documenter une hiérarchie de synchronisation. Bonnes pratiques courantes :

• 2 serveurs NTP internes redondés avec supervision (offset, reachability) ;
• filtrage des NTP publics côté OT, et règles explicites pare-feu (UDP/123) ;
• synchronisation de tous les serveurs applicatifs (SCADA, historien, web) sur la même référence ;
• définition d'un SLA d'offset (seuils d'alerte adaptés au besoin métier).

Sur la partie cybersécurité et journalisation, l'ANSSI recommande l'usage de serveurs de temps internes et une synchronisation permettant la corrélation d'événements entre équipements, dans le cadre des recommandations pour l'architecture d'un système de journalisation. Sur les architectures OT, des recommandations existent également pour les équipements réseau industriels (commutateurs/pare-feu), incluant la synchronisation horaire (guide ANSSI industriel).

Gérer step/slew et tracer les resynchronisations

Quand c'est possible, une correction progressive (slew) est préférable à un saut (step) afin de limiter les discontinuités dans les historiques. Recommandations opérationnelles :

• mettre en place des seuils d'alerte d'offset (par exemple ±500 ms, ±2 s, selon criticité) ;
• journaliser les resynchronisations (avant/après, offset, source) ;
• éviter les recalages automatiques destructifs sur les équipements servant de référence SOE.

Chaîne SOE et recalage des historiques

Concevoir une filière « SOE-ready »

Pour les événements discrets (alarmes, changements d'état), une approche SOE limite les ambiguïtés :

• horodatage à la source au moment de la transition ;
• buffer circulaire local avec numéro de séquence ;
• transport fiable avec accusés et reprise sur incident ;
• réconciliation côté serveur : déduplication, détection de trous, contrôle d'ordre.

Recaler sans réécrire : la réconciliation traçable

Le recalage vise à restaurer une cohérence temporelle sans perdre la preuve d'origine. Une méthode robuste consiste à :

• conserver la donnée brute avec son timestamp d'origine ;
• estimer un offset par fenêtre (corrélations sur événements pivots : marche/arrêt, fronts d'alarme, impulsions compteur) ;
• publier un temps corrigé dans une vue dérivée : T_corrected = T_measure + offset(t) ;
• tenir un journal d'audit : version, paramètres, périmètre, impact.

Cette approche garantit la reproductibilité : on améliore l'exploitation sans altérer irréversiblement les données originales.

Indicateurs qualité (DQ) sur l'intégrité temporelle

Pour industrialiser, définir des KPI de « santé temporelle » :

• offset NTP par équipement (min/moy/max) ;
• fréquence de resynchronisation et ratio step/slew ;
• distribution des latences d'ingestion ;
• détection d'horodatages dans le futur / retours arrière ;
• taux d'événements hors ordre et taux de doublons.

Bonnes pratiques d'architecture SCADA

Arbitrer précision utile et complexité

Tout système n'a pas besoin de la microseconde. Le besoin doit piloter le choix :

• tendances énergie : la seconde (voire quelques secondes) est souvent suffisante ;
• alarmes process et diagnostic : la seconde est généralement un minimum ;
• séquences critiques : milliseconde, voire sub-millisecondes (PTP).

Limiter l'effet du polling et des scans non déterministes

Même en LAN, la charge serveur, l'I/O disque, la virtualisation et les scans non déterministes peuvent décaler l'acquisition. Une réponse pragmatique :

• augmenter la fréquence uniquement sur signaux critiques ;
• utiliser des mécanismes événementiels (report-by-exception) lorsque disponibles ;
• séparer les flux : temps réel (exploitation) vs temps différé (reporting) ;
• stocker et exploiter T_measure et T_ingest pour objectiver la latence.

Industrialiser avec des outils adaptés

Centraliser, qualifier et exploiter les données

Pour rendre ces principes opérationnels (collecte multi-sources, contrôle qualité des timestamps, indicateurs, bilans), CALASYS s'appuie notamment sur Diagbox, solution de traitement et d'exploitation des données issues des SI industriels. Selon l'architecture cible, l'intégration s'articule avec les briques SCADA et télégestion (acquisition, supervision, buffers d'événements, historisation), en maintenant une séparation claire entre données brutes, données corrigées et preuves de transformation.

Conclusion : fiabiliser le temps, fiabiliser l'exploitation

Ce qu'il faut retenir

Une chronologie fiable ne se suppose pas : elle se conçoit et se contrôle. Référence de temps gouvernée (NTP/PTP), distinction mesure vs ingestion, gestion SOE, stratégie de resynchronisation, et recalage non destructif avec journal d'audit sont les leviers qui transforment des historiques « discutables » en données exploitables.

Bénéfices : diagnostics plus rapides, analyses causales crédibles, KPI robustes, meilleure traçabilité en environnement réglementé.

Pour sécuriser votre chaîne temporelle (audit d'architecture, définition de la référence de temps, mise en place SOE, instrumentation DQ et recalage traçable), contactez CALASYS afin de demander un devis adapté à vos contraintes OT et à vos exigences de supervision.

Perspectives

Vers une observabilité OT plus complète

À moyen terme, la généralisation d'approches d'observabilité OT (métriques, journaux, traces) intégrant des indicateurs temporels (offset, gigue, out-of-order) devrait renforcer la maîtrise de la qualité de service des architectures multi-sites.