Mise en œuvre d'un système de sécurité pour le personnel travaillant sur un accélérateur de particules

Le Thomas Jefferson National Accelerator Facility (JLab) est un laboratoire national de l’U.S. Department of Energy Office of Science. Il abrite l'accélérateur d’électrons à faisceaux continus (Continuous Electron Beam Accelerator Facility ou CEBAF), qui produit un faisceau d'électrons utilisé pour mener des recherches fondamentales en physique nucléaire. Au total, les électrons effectuent jusqu'à cinq tours et demi autour du circuit de l’accélérateur atteignant une énergie allant jusqu'à 12 milliards d'électrons-volts (12 GeV).

Pour garantir que les risques pour le personnel travaillant dans l’installation ont été réduits à « un niveau aussi bas que raisonnablement possible » (ALARA), le JLab Safety Systems Group (SSG) conçoit, exploite et entretient un système de sécurité du personnel (PSS) intégré. Le PSS est responsable d'une série de fonctions de sécurité, notamment la prévention de l'exposition directe aux rayonnements ionisants immédiats.

Le PSS aide au contrôle d’entrée du personnel dans les zones où des risques pour la sécurité peuvent exister. Par exemple, plusieurs risques de sécurité importants existent dans le système de tunnel de l'accélérateur lorsque le faisceau est en fonctionnement. Il s’agit notamment des rayonnements ionisants et non ionisants, du rayonnement laser et des conducteurs électriques haute tension exposés sur les électroaimants utilisés pour faire recirculer le faisceau autour des arcs du tunnel (Figure 1). Dans le pire des cas, l’exposition à un rayonnement ionisant immédiat peut entraîner une dose mortelle en quelques minutes. Le PSS aide le personnel à s'assurer que les travailleurs sont évacués des zones du système de tunnel de l'accélérateur avant le fonctionnement du faisceau et que les membres du personnel sont ensuite physiquement empêchés de pénétrer dans ces zones tant que le faisceau est en fonctionnement.

Le PSS fait actuellement l’objet d’une mise à niveau majeure qui comprend la réécriture de toutes les fonctions du logiciel à partir de zéro. Nous avons sélectionné un langage graphique de la norme IEC 61131 appelé Function Block Diagramming (FBD) pour développer le logiciel du PSS.

L’approche Model-Based Design avec Simulink^® joue un rôle central dans les workflows d’implémentation et de vérification que nous utilisons pour créer le logiciel PSS. Toutes les fonctions du PSS sont d’abord modélisées dans Simulink puis simulées à l’aide de cas de test générés par Simulink Design Verifier™. Nous avons choisi Simulink pour ce projet car il fournit une méthode mature, rapide et bien supportée, pour modéliser les fonctions graphiques nécessaires, et ensuite vérifier que les designs sont logiquement corrects avant l’implémentation. De plus, Simulink Design Verifier nous permet d'atteindre, entre autres exigences, une couverture de test de 100 % de toutes les fonctions du programme, démontrant ainsi que les designs sont sûrs.

C'est un avantage considérable de pouvoir réaliser toutes les activités requises au cours du cycle de vie, qu'il s'agisse du design, des tests ou de la sécurité, y compris les tests fonctionnels, la vérification des erreurs arithmétiques (par exemple, les violations de plage d'entiers) et l'analyse de couverture, dans un seul environnement.

Défis de portée et de complexité

Le PSS est conçu pour détecter et répondre à deux grandes catégories de risques de niveau 3 d'intégrité de sécurité : les violations du contrôle d'accès et les violations du contrôle des faisceaux. Ces deux catégories représentent deux aspects d’un même enjeu. Bien que les événements déclencheurs diffèrent, les deux types de violation entraînent une perte de séparation entre les personnes et le faisceau. En cas de violation du contrôle d'accès, si des personnes pénètrent dans une zone d'exclusion au sein de l'installation, tous les dangers doivent être arrêtés en quelques secondes (c'est-à-dire avant que des personnes n'atteignent les niveaux inférieurs des tunnels). Lors d'une violation du contrôle du faisceau, le faisceau peut être mal dirigé vers une zone accessible ou vers un dispositif d'arrêt de faisceau qui assure l'isolation d'une zone accessible. Dans le cas de ce deuxième scénario, en raison de la puissance élevée du faisceau (1 million de watts), celui-ci doit être arrêté en quelques millisecondes seulement.

Le défi dans le design et la vérification du PSS est augmenté par la complexité et l’envergure du système. Le PSS comprend plus de 2 200 canaux d'E/S (y compris des capteurs et des actionneurs) répartis sur les neuf segments de l'installation. Les segments sont séparés les uns des autres par des portes et des portails à verrouillage mutuel. Le PSS, pour chaque segment, comprend un système de sécurité à double redondance basé sur des automates de sécurité Siemens^® de la série 1500.

Au total, le système contient 18 automates de sécurité distribués et 200 canaux de communication inter-automates, qui sont utilisés pour échanger des données. À chaque cycle d'horloge, les données de près de 2 000 capteurs sont collectées et transmises au centre de contrôle principal via des câbles à fibre optique pour traitement. Une fois les résultats calculés, ils sont renvoyés sur le terrain pour contrôler et au besoin déclencher les différents dispositifs d’alerte et d’arrêt. L’ensemble de ce cycle s’effectue en quelques millisecondes seulement et se déroule en continu. Environ 50 % du code du PSS est utilisé à des fins de diagnostic et d'autosurveillance (c'est-à-dire de détection de pannes).

Tout système de contrôle de cette envergure nécessiterait un investissement technique substantiel. Mais les systèmes de sécurité peuvent coûter 3 à 10 fois plus cher que les systèmes non liés à la sécurité lorsqu’ils mettent en œuvre la même fonctionnalité. Le ciblage des automates de sécurité Siemens à l'aide du langage FBD a empêché l'utilisation de Simulink PLC Coder™ pour générer du texte structuré IEC 61131 directement à partir de nos modèles Simulink. En conséquence, tous les blocs fonctionnels ont d'abord été conçus et vérifiés dans Simulink, avant d'être réimplémentés manuellement à l'aide du langage Function Block Diagram dans TIA Portal (l'environnement de développement intégré de Siemens utilisé pour le développement et le déploiement des API) (Figure 2).

Extension et amélioration du workflow traditionnel

Compte tenu de la portée et de la complexité du PSS, nous devions réfléchir à la manière d’optimiser notre workflow de développement existant. Dans le workflow traditionnel, une fois le comportement d'un bloc fonctionnel défini dans Simulink, il serait nécessaire de définir des cas de test dans Simulink, y compris des vecteurs d'entrée (stimuli) et des vecteurs de sortie (objectifs). Les cas de test seraient exécutés à l’aide de Simulink Test™ et la couverture des tests mesurée à l’aide de Simulink Coverage™ (Figure 3, Route 1).

Cette approche pose deux problèmes essentiels. Tout d’abord, la tâche de générer manuellement des cas de test pour chaque fonction peut prendre énormément de temps, même pour les ingénieurs de test expérimentés. Deuxièmement, si les tests n’atteignent pas une couverture de 100 % pour la fonction testée, il peut souvent être très difficile de déterminer si cela est dû à une erreur de design dans la fonction elle-même ou à une déficience dans la méthode de test où davantage de tests devraient être définis et exécutés.

Pour résoudre ces problèmes, nous avons utilisé Simulink Design Verifier afin de générer automatiquement des cas de test (à l’aide de méthodes formelles) qui atteignent une couverture à 100 %. Cela élimine la tâche de définition manuelle des cas de test. Cela résout également le problème de la détection des erreurs de design dans la fonction testée. Si Simulink Design Verifier ne peut pas atteindre une couverture de 100 %, il met en évidence l'emplacement de l'erreur de design dans la fonction elle-même. Ce workflow constitue une amélioration substantielle par rapport à la méthode traditionnelle (Figure 3, itinéraire 2a).

Bien que l’utilisation de Simulink Design Verifier offre des avantages substantiels, elle introduit une nouvelle tâche à effectuer. Dans la méthode traditionnelle, l'ingénieur de test intègre généralement le comportement fonctionnel souhaité (objectifs) de manière implicite dans les cas de test au fur et à mesure de leur développement. Si les tests réussissent, on dit que la fonction se comporte correctement. Cependant, lors de l’utilisation de générateurs automatiques de cas de test, les algorithmes formels n’ont aucune connaissance de ce qui est considéré comme un comportement logique correct. Pour cette raison, il est nécessaire d'examiner les cas de test (et les résultats correspondants) générés par Simulink Design Verifier pour vérifier l'exactitude du comportement, c'est-à-dire d'examiner les tests générés pour vérifier que la fonction se comporte comme prévu.

Cela peut être réalisé soit en examinant les cas de test (avec les résultats attendus) directement à l'aide de diagrammes temporels, soit en simulant les cas de test et en observant les résultats de la simulation basée sur le temps sur le modèle lui-même. Les deux options peuvent être quelque peu compliquées et sujettes à des erreurs, en particulier lorsque les fonctions ont de nombreuses entrées et sorties. De tels tests nécessitent un ingénieur de test expérimenté ayant Simulink installé et peuvent être sujets à un manque de visibilité lorsqu'il y a de nombreuses fonctions à examiner.

Comme nous souhaitions que nos revues de design soient réalisées par un groupe dans un environnement de type réunion, nous développons un concept appelé Listes de contrôle de vérification comportementale pour vérifier l'exactitude comportementale de nos fonctions logicielles. Nous avons créé un script MATLAB^® qui convertit les cas de test Simulink en un format procédural pour les rendre plus rapides et plus faciles à lire et à interpréter que les diagrammes de synchronisation traditionnels (Figure 3, itinéraire 2b).

Un examen plus approfondi des listes de contrôle de vérification comportementale

Un aspect central de notre nouveau workflow est la possibilité pour les ingénieurs de vérifier l’exactitude comportementale des blocs fonctionnels à l’aide de listes de contrôle plutôt qu’en lisant des diagrammes de synchronisation ou en exécutant des simulations. Ces méthodes peuvent souvent prendre du temps et être sujettes à des erreurs, en particulier lorsque le nombre d’E/S est important. Pour résoudre ce problème, des listes de contrôle de vérification comportementale ont donc été élaborées pour être concises et facilement lisibles, en se concentrant sur les informations qui intéressent le plus les évaluateurs. Les ingénieurs peuvent utiliser ces listes de contrôle de manière indépendante ou en groupe pour évaluer chaque bloc fonctionnel et la manière dont il réagit aux changements de stimuli d'entrée (tableau 1), même s'ils n'utilisent pas régulièrement Simulink ou ne l'ont pas installé. Cela permet d’impliquer un plus grand nombre d’experts en la matière dans le processus d’examen du design et réduit la charge de travail de l’ingénieur de test. Étant donné que les résultats sont examinés hors ligne par plusieurs personnes, la probabilité de détecter des erreurs logiques augmente. Les listes de contrôle sont générées automatiquement à l'aide de scripts MATLAB à partir de cas de test Simulink, qui sont à leur tour générés automatiquement à l'aide de Simulink Design Verifier.

Importation de cas de Simulink Test dans TIA Portal

Dans la dernière section de notre workflow, nous réimplémentons et testons les blocs fonctionnels dans notre environnement PLC cible. Nous commençons par utiliser un deuxième script MATLAB pour convertir les cas de test Simulink en fichiers de cas de test Siemens (qui sont des fichiers texte avec une extension .TAT) (Figure 4). Nous traduisons également les designs de blocs fonctionnels de Simulink vers TIA Portal. Enfin, nous exécutons les cas de test convertis sur le code PLC à l’aide de Siemens PLCSIM et Test Suite Advanced pour garantir l’équivalence sur la cible.

TEST_CASE “TEST_OUTPUT_TEST_CASE_1”
 
PROPERTY
AUTHOR : “METCALF”
VERSION : “1.0”
COMMENT : “Test Case 1 for TEST_OUTPUT function block.”
SCOPE : “PSS_PLC”
END_PROPERTY
 
VAR
TEST_INITIAL_CONDITIONS : TEST_OUTPUT_IDB.TEST_INITIAL_CONDITIONS := FALSE;
TEST_CONFIGURED : TEST_OUTPUT_IDB.TEST_CONFIGURED := TRUE;
TEST_REQUESTED : TEST_OUTPUT_IDB.TEST_REQUESTED := FALSE;
TEST_CONTINUOUS_CONDITIONS : TEST_OUTPUT_IDB.TEST_CONTINUOUS_CONDITIONS := TRUE;
MINIMUM_TEST_DURATION : TEST_OUTPUT_IDB.MINIMUM_TEST_DURATION := T#74ms;
TEST_OUTPUT : TEST_OUTPUT_IDB.TEST_OUTPUT;
END_VAR
 
STEP : “STEP_1”
RUN(CYCLES := 1);
ASSERT.Equal(TEST_OUTPUT,FALSE);
RUN(CYCLES := 399);
END_STEP
 
STEP : “STEP_2”
TEST_CONFIGURED := FALSE;
TEST_CONTINUOUS_CONDITIONS := FALSE;
MINIMUM_TEST_DURATION := T#0ms;
RUN(CYCLES := 1);
ASSERT.Equal(TEST_OUTPUT,FALSE);
RUN(CYCLES := 199);
END_STEP
 
STEP : “STEP_3”
TEST_REQUESTED := TRUE;
RUN(CYCLES := 1);
ASSERT.Equal(TEST_OUTPUT,FALSE);
RUN(CYCLES := 199);
END_STEP
. . . 
. . . 
. . . 
END_TEST_CASE

Figure 4. Partie d'un cas de test Siemens généré par un script MATLAB à partir d'un cas de test Simulink.

Déploiement et application du workflow à d'autres projets

Les systèmes de sécurité à haute intégrité comme le PSS nécessitent des workflows de développement stricts pour minimiser le risque d'erreurs logicielles pouvant entraîner des conséquences dangereuses, voire potentiellement catastrophiques. Lors de la duplication de composants logiciels sur des unités de traitement redondantes, ces risques sont encore multipliés puisque toute erreur deviendra une cause commune (CC). Pour ces raisons, la norme CEI 61508 met fortement l'accent sur la nécessité d'éviter que des défauts systématiques ne soient introduits dans les systèmes de sécurité par le biais des logiciels. Grâce à l’approche Model-Based Design et à notre nouveau workflow, nous avons réussi à augmenter notre Capacité systématique—tel que défini dans la norme CEI 61608—à un niveau qui offre un niveau d’assurance très élevé dans la mise en œuvre d’un système sûr et sans erreur.

Nous sommes actuellement dans les dernières étapes du déploiement du PSS amélioré sur les derniers segments d’accélérateur restants (figure 5), avec une date d’achèvement prévue à l’automne 2024. Une fois le PSS terminé, l’une de nos prochaines priorités de développement sera la mise à niveau de notre système de surveillance de perte de faisceau (BLM), qui fait partie de notre système de protection des machines (Machine Protection System). Pour ce projet, nous avons l'intention d'utiliser un workflow très similaire à celui utilisé pour le PSS. Cependant, étant donné que la cible du système BLM sera un FPGA, nous prévoyons d’utiliser HDL Coder™ pour générer du code HDL synthétisable directement à partir de nos modèles Simulink et éviter presque entièrement le codage manuel sur la cible. Nous espérons également utiliser les capacités hardware-in-the-loop de HDL Verifier™ pour simplifier et accélérer notre workflow de vérification et de validation sur l’équipement.