Simulation de systèmes cyber-physiques pour la validation des infrastructures critiques

Principaux enseignements

• Les systèmes cyber-physiques nécessitent une validation qui considère le logiciel, la synchronisation, les capteurs et le comportement de l'installation comme un seul et même circuit.
• Les tests des infrastructures critiques sont plus efficaces lorsque les scénarios sont classés en fonction de leurs conséquences opérationnelles et de leur impact sur la reprise des activités.
• Les critères d'acceptation n'ont d'importance que s'ils permettent de relier les résultats des tests à la sécurité des réponses, à la continuité du service et à la clarté pour l'opérateur.

La validation des infrastructures critiques ne fonctionne que si l'on teste la synchronisation, la détection et le contrôle comme un seul et même circuit fermé.

Les systèmes cyber-physiques relient la logique logicielle au comportement électrique, mécanique et des processus ; les défaillances surviennent donc souvent à la frontière entre le code et la physique. Environ 85 % des infrastructures critiques du pays appartiennent au secteur privé et sont exploitées par celui-ci. Ce mélange d’actifs hérités, de commandes personnalisées et de règles sectorielles signifie que vous ne pouvez pas vous fier à une vérification logicielle générique. Vous avez besoin de simulations et de tests qui reproduisent les signaux, les délais, les défaillances et les actions des opérateurs avant le déploiement.

« Une conception peut sembler correcte lors d'une analyse hors ligne, mais provoquer tout de même un déclenchement, un calage ou une oscillation en fonctionnement. »

Les systèmes cyber-physiques associent le calcul à la synchronisation des processus physiques

Les systèmes cyber-physiques associent informatique, communications et processus physiques dans des délais critiques pour la sécurité et la qualité du service. Un signal de commande qui arrive en retard peut modifier la position d'une vanne, l'activation d'un relais ou la force de freinage. Ce couplage étroit fait de la validation une tâche systémique. Les tests logiciels ne suffisent pas à eux seuls à en rendre compte.

Un relais de dérivation illustre parfaitement ce principe. Les signaux de courant sont transmis à un circuit d'entrée analogique, le circuit logique de protection calcule un déclenchement, et la bobine du disjoncteur doit se déclencher dans un délai prédéfini. Une station de pompage fonctionne de la même manière, car la pression, la vitesse du moteur et le temps de réponse du réseau sont pris en compte par le circuit logique de commande. Chaque chemin a des implications en termes de timing et de fonctionnement physique.

Vous devez modéliser l'installation et le contrôleur dans une seule boucle afin que le système se comporte comme il le fera en service. Cela implique de reproduire la résolution des capteurs, les limites des actionneurs, les fluctuations de communication et les transitoires de défaillance. Les équipes qui traitent séparément les aspects cybernétiques et physiques passent généralement à côté des défaillances combinées. Ces lacunes apparaissent tardivement, à un moment où les corrections coûtent plus cher et où la confiance sur le terrain est moindre.

La validation échoue lorsque les hypothèses relatives au timing n'ont pas été vérifiées

La validation échoue lorsque les ingénieurs considèrent le temps comme une constante plutôt que comme une variable de test. Les durées de balayage, la préemption des tâches, la latence du bus et la gestion des interruptions influent toutes sur la réponse du système de commande. Une conception peut sembler correcte lors d'une analyse hors ligne, mais présenter tout de même des blocages, des ralentissements ou des oscillations en fonctionnement. La synchronisation doit faire l'objet de tests directs.

Une boucle de régulation de compresseur illustre bien ce phénomène. Le modèle peut maintenir la pression dans les limites prévues lors d'un pas de 1 milliseconde, mais la cible embarquée peut ne pas respecter son délai d'exécution lors d'une rafale de communications et commander un état de vanne erroné. Ce défaut n'apparaîtra pas lors de la révision du code. Il se manifeste lorsque le temps d'exécution, les mises à jour d'E/S et la réponse de l'installation interagissent.

Les tests de performance ne se limitent pas aux chiffres de CPU dans le pire des cas. Il faut introduire de la latence, faire varier la charge du planificateur et noter le moment précis où la qualité du contrôle se dégrade. Cette approche permet de distinguer les retards sans conséquence de ceux qui modifient le comportement physique. Une fois cette limite identifiée, les modifications de conception deviennent concrètes et non plus hypothétiques.

La simulation du capteur doit correspondre au comportement réel en conditions de contrainte

La simulation des capteurs doit reproduire la manière dont les instruments de terrain peuvent donner des lectures erronées, saturer, dériver et se stabiliser à nouveau en situation de contrainte. Des signaux purs donnent des résultats fiables, mais les systèmes critiques fonctionnent rarement avec des signaux purs. Si vous souhaitez obtenir des données valides, vos signaux d'entrée de test doivent comporter les mêmes imperfections que celles qui influencent la réponse du contrôleur en service.

Un relais de distance alimenté par des formes d'onde de courant idéales semblera stable jusqu'à ce qu'un défaut provoque la saturation d'un transformateur de courant. Un régulateur de pression de pipeline peut paraître précis jusqu'à ce que le transmetteur génère du bruit après le démarrage d'une pompe. Ces cas ne sont pas des détails marginaux. Ils déterminent le moment du déclenchement, la qualité des alarmes et la confiance de l'opérateur.

Une bonne simulation de capteur doit prendre en compte les limites de plage, la quantification, les paquets manquants, les valeurs bloquées et les erreurs d'étalonnage. Il est également essentiel de définir une durée de défaillance appropriée, car une coupure de 20 millisecondes et un blocage de 2 secondes déclenchent des logiques différentes. La reproduction fidèle du comportement sur le terrain est plus importante que le volume de signaux. Un petit ensemble de défaillances de capteurs réalistes vous en apprendra bien plus que des milliers de tests parfaits.

Les tests des systèmes embarqués nécessitent une fidélité d'exécution en boucle fermée

Les tests des systèmes embarqués nécessitent une exécution en boucle fermée afin que le code, les E/S et la réponse du système interactent au même rythme. La lecture en boucle ouverte permet de vérifier les fonctions, mais elle ne met pas en évidence les problèmes de contrôle instable, les délais non respectés ou les transitions d'état dangereuses. La fidélité, dans ce contexte, signifie que le contrôleur perçoit immédiatement les conséquences. C'est ce qui transforme un simple test sur banc en une véritable validation.

Un contrôleur de moteur en illustre la raison. Un micrologiciel qui semble stable dans un débogueur logiciel peut présenter des oscillations dès lors que les mises à jour d'impulsions, l'échantillonnage du convertisseur analogique-numérique (ADC) et le couple de charge sollicitent le matériel avec une synchronisation précise. Les équipes ont souvent recours à des plateformes telles qu'OPAL-RT pour relier le matériel du contrôleur à un modèle d'installation et vérifier ces interactions avant un essai sur site. Cette configuration met en évidence la différence entre un code qui s'exécute et un système de contrôle qui tient la route.

La fidélité en boucle fermée ne consiste pas à reproduire un maximum de détails partout. Il faut une haute fidélité au niveau des interfaces qui déterminent la réponse du système de commande, notamment la synchronisation PWM, le traitement des interruptions, les échanges réseau et la logique de protection. Les sous-systèmes moins importants peuvent rester simplifiés s’ils ne modifient pas ces interfaces. Cet équilibre garantit la fiabilité des tests sans pour autant transformer le modèle en un fardeau en termes de maintenance.

La validation des infrastructures critiques commence par des scénarios fondés sur les conséquences

La validation des infrastructures critiques doit commencer par l'évaluation des conséquences, car toutes les défaillances ne justifient pas le même niveau de rigueur lors des tests. Une fausse alerte sur un panneau redondant n'est pas comparable à un déclenchement manqué sur une ligne d'alimentation ou à une commande d'ouverture erronée sur une vanne. L'étendue des tests dépend de l'impact. C'est ainsi que l'on tire le meilleur parti du temps de laboratoire, qui est limité.

La diversité des secteurs rend cette hiérarchisation nécessaire. Le Canada regroupe les infrastructures essentielles en 10 secteurs, et chaque secteur présente des processus, des coûts de défaillance et des délais d’intervention différents. Un contrôleur d’alimentation de secours dans un hôpital nécessite un ensemble de scénarios différent de celui d’une station de relevage des eaux usées. Les plans de test uniformes semblent bien ficelés sur le papier, mais échouent dans la pratique.

Un plan axé sur les conséquences classe les scénarios en fonction de la perte de service, des risques pour la sécurité, du temps de rétablissement et de la charge de travail des opérateurs. Ce classement vous aide à déterminer quelles défaillances nécessitent Simulation HIL, lesquelles requièrent des essais d'endurance plus longs, et lesquelles peuvent se contenter d'une révision du modèle. Vous n'éliminerez pas toutes les incertitudes, mais vous concentrerez vos efforts là où une hypothèse erronée aurait le coût le plus élevé.

« Les preuves en matière de sécurité doivent inclure les conséquences matérielles de l'incident cybernétique. »

La protection des réseaux électriques nécessite des études Simulation HIL

La protection des réseaux électriques nécessite des études Simulation HIL car les relais réagissent à des transitoires rapides, et non à un comportement moyen. Les seuils de déclenchement, la synchronisation logique et la coordination des disjoncteurs dépendent des formes d'onde exactes du courant et de la tension. Un modèle statique ne tiendra pas compte de ces détails. Les études de défauts doivent être réalisées à la vitesse de protection.

Un test de protection de ligne d'alimentation permet de simuler, en une seule séquence, un défaut unipolaire à la terre, la saturation d'un transformateur de courant, la défaillance d'un disjoncteur et un retard de la téléprotection. Le relais est alors confronté aux mêmes distorsions de forme d'onde et aux mêmes contraintes de synchronisation qu'il rencontrera sur le réseau. C'est là que les déclenchements prématurés, tardifs et intempestifs apparaissent. Des réglages qui semblaient prudents peuvent s'avérer instables dans des conditions de contrainte.

Les équipes du réseau doivent également tester la logique de rétablissement après le déclenchement. Les temporisations de réenclenchement, les contrôles de synchronisation et les signaux de blocage peuvent interagir de manière imprévisible après une perturbation. C'est pourquoi la validation des protections couvre l'ensemble de l'événement, depuis l'état stationnaire avant le défaut jusqu'au rétablissement après le défaut. Une validation fondée uniquement sur le déclenchement initial ne tient pas compte de la partie la plus risquée de la séquence.

Les tests de sécurité doivent mesurer la réponse déterministe en cas d'attaque

Les tests de sécurité des systèmes cyber-physiques doivent évaluer la réponse déterministe, et pas seulement la détection des intrusions. Une attaque est significative car elle modifie la synchronisation, la qualité des données ou l'état de contrôle à un moment précis. Si votre test ne permet pas de montrer comment l'installation réagit dans ce laps de temps, vous ne connaissez pas encore le risque opérationnel.

Imaginons une attaque par rejeu visant le flux de données de mesure d'une sous-station. Le contenu du paquet peut sembler valide alors que l'horodatage est périmé, ce qui peut maintenir un contrôleur dans un état dangereux ou retarder un déclenchement. Une unité de traitement de l'eau est confrontée à un problème similaire lorsqu'un signal de niveau falsifié empêche l'arrêt d'une pompe. Les preuves en matière de sécurité doivent inclure les conséquences physiques de l'incident cybernétique.

Les tests de réponse déterministe se concentrent sur des résultats bien délimités. Il convient de mesurer le délai maximal de sécurité, la perte de paquets maximale tolérable et le moment où la logique de repli prend le relais. Cette méthode fournit aux opérateurs des règles qu’ils peuvent appliquer en situation de crise. Elle permet également de lier les mesures de sécurité aux performances réelles de l’installation plutôt qu’à des scores de gravité abstraits.

Les critères d'acceptation doivent tenir compte des risques opérationnels avant le déploiement

Les critères d'acceptation doivent tenir compte des risques opérationnels avant le déploiement, car un test réussi n'a de valeur que s'il correspond aux objectifs en matière de service, de sécurité et de reprise. Il faut définir des seuils indiquant à partir de quand une erreur de synchronisation est acceptable, quand un écart de capteur est tolérable et quand le recours à un comportement de secours est obligatoire. C'est cette norme qui fait autorité.

Un ensemble de critères d'acceptation efficace doit être suffisamment précis pour détecter les failles d'une conception déficiente, tout en restant suffisamment simple pour que les équipes puissent l'appliquer de manière cohérente. Un test de relais peut par exemple réussir l'épreuve de vitesse de déclenchement, mais échouer à celle de la stabilité de réarmement après un verrouillage du disjoncteur. Un régulateur de pompe peut maintenir le débit dans les limites requises, tout en submergeant l'opérateur d'alarmes ambiguës. De bons critères doivent refléter l'ensemble de la séquence de fonctionnement, et non un simple instant isolé.

• Les limites de latence sont liées à la fonction de protection ou de contrôle qu'elles concernent.
• Les limites d'erreur des capteurs comprennent la dérive, la perte de signal et la saturation en cas de défaillance.
• Les modes de secours rétablissent un état sûr dans un délai de récupération défini.
• Les actions de l'opérateur restent claires lorsque des alarmes, des dérogations et des déclenchements se produisent simultanément.
• Pour que les résultats soient valides, les performances doivent être reproductibles tant en conditions normales qu'en conditions de contrainte.

Les équipes qui gardent ces critères à l'esprit acquièrent au fil du temps une meilleure capacité de jugement, car chaque résultat de test correspond à un risque opérationnel concret. Cette rigueur est bien plus importante qu'un long rapport rempli de notes de réussite isolées. OPAL-RT est utilisé dans de nombreux laboratoires précisément pour ce type de travail d'exécution, où le matériel de contrôleur, les modèles d'installation et les cas de défaillance doivent fonctionner comme un système synchronisé. La valeur ajoutée réside dans une conception rigoureuse des tests et des seuils d'acceptation réalistes, car c'est ce qui transforme la simulation en preuve tangible.