Sistema de seguridad para el personal de un laboratorio de aceleradores de partículas

JLab (Thomas Jefferson National Accelerator Facility) es un laboratorio nacional de la Oficina de Ciencias del Departamento de Energía de EE. UU. Es sede de CEBAF (Continuous Electron Beam Accelerator Facility), que genera un haz de electrones utilizado para realizar investigaciones fundamentales en física nuclear. De principio a fin, los electrones pueden dar hasta cinco vueltas y media en el diseño de pista de carreras de la instalación mientras aceleran hasta 12 mil millones de electronvoltios (12 GeV).

Para garantizar que los riesgos para el personal que trabaja en las instalaciones se reduzcan al "nivel más bajo razonable" (ALARA), el Grupo de Sistemas de Seguridad de JLab (SSG) diseña, opera y mantiene un sistema de seguridad de personal (PSS). El PSS es responsable de una variedad de funciones de seguridad, incluida la prevención de la exposición directa a la radiación ionizante.

El PSS ayuda al personal a controlar el ingreso a áreas donde pueden existir riesgos de seguridad. Por ejemplo, existen varios riesgos de seguridad importantes dentro del sistema de túneles del acelerador cuando el haz está en funcionamiento. Estos riesgos incluyen radiación ionizante y no ionizante, radiación láser y conductores eléctricos de alto voltaje expuestos en los electroimanes utilizados para recircular el haz alrededor de los arcos del túnel (Figura 1). En el peor de los casos, la exposición directa a la radiación ionizante puede provocar una dosis letal en cuestión de minutos. El PSS ayuda a garantizar que los trabajadores se retiren del sistema de túneles del acelerador antes de la operación del haz y que no puedan ingresar físicamente a esas áreas hasta que se complete la operación del haz.

El PSS se encuentra actualmente en una importante fase de actualización que incluye la reescritura de todas las funciones de software desde cero. Seleccionamos un lenguaje gráfico de IEC 61131 denominado Function Block Diagramming (FBD) para desarrollar el software del PSS.

El diseño basado en modelos con Simulink^® desempeña un papel central en los flujos de trabajo de implementación y verificación para el desarrollo del software PSS. Todas las funciones del PSS se modelan primero en Simulink y luego se simulan utilizando casos de prueba generados por Simulink Design Verifier™. Elegimos Simulink para esta tarea debido a que proporciona una manera avanzada, rápida y bien respaldada de modelar las funciones gráficas necesarias y garantiza que los diseños sean lógicamente correctos antes de su implementación. Además, Simulink Design Verifier nos permite lograr, entre otros requisitos, una cobertura de pruebas del 100% de todas las funciones del programa y demostrar así que los diseños son seguros.

Es una ventaja significativa poder completar todas las actividades requeridas del ciclo de diseño, prueba y seguridad, incluidas las pruebas funcionales, la verificación de errores aritméticos, como infracciones de rangos enteros, y el análisis de cobertura, en un solo entorno.

Desafíos de alcance y complejidad

El PSS está diseñado para detectar y responder a dos amplias categorías de riesgos de nivel de integridad de seguridad 3: infracciones de control de acceso y infracciones de control de haz. Son dos aspectos de la misma situación. Si bien los eventos que los inician difieren, ambos tipos de infracción generan pérdida de separación entre las personas y el haz. Durante una infracción del control de acceso, si las personas ingresan a un área restringida dentro de las instalaciones, todos los peligros deben eliminarse en unos pocos segundos; es decir, antes de que las personas lleguen a los niveles inferiores de los túneles. Durante una infracción del control del haz, es posible que el haz se desvíe hacia un área accesible o un dispositivo de detención del haz que proporciona aislamiento para un área accesible. Debido a la alta potencia del haz (1 millón de vatios), en este último caso, el haz debe apagarse en apenas unos milisegundos.

El diseño y la verificación del PSS se complican por la complejidad y la escala del sistema. El PSS incluye más de 2.200 canales de E/S (incluidos sensores y actuadores) distribuidos en los nueve segmentos de la instalación. Los segmentos están separados por puertas y portones con enclavamientos. El PSS de cada segmento incluye un sistema de seguridad doblemente redundante basado en los PLC de seguridad Siemens^® de la serie 1500.

En total, el sistema contiene 18 PLC de seguridad distribuidos y 200 canales de comunicación entre PLC, utilizados para intercambiar datos. En cada ciclo, se leen datos de casi 2.000 sensores y se transmiten al centro de control principal a través de cables de fibra óptica para su procesamiento. Una vez calculados los resultados, se envían de vuelta al campo para controlar los distintos dispositivos de advertencia y apagado. Todo este ciclo se completa en apenas unos milisegundos y se ejecuta de forma continua. Alrededor del 50% del código dentro del PSS se utiliza para diagnóstico y autocontrol (es decir, detección de fallas).

Cualquier sistema de control de este alcance requiere una inversión de ingeniería sustancial. Pero los sistemas de seguridad pueden costar entre 3 y 10 veces más que los sistemas no destinados a seguridad cuando implementan la misma funcionalidad. El uso de PLC de seguridad de Siemens mediante el lenguaje de FBD excluyó el uso de Simulink PLC Coder™ para generar texto estructurado IEC 61131 directamente desde nuestros modelos de Simulink. En cambio, todos los bloques de función se diseñaron y verificaron primero en Simulink, antes de reimplementarlos manualmente utilizando el lenguaje de diagrama de bloques de funciones en TIA Portal (el entorno de desarrollo integrado de Siemens utilizado para el desarrollo y despliegue de PLC) (Figura 2).

Ampliación y optimización del flujo de trabajo tradicional

Dado el alcance y la complejidad del PSS, necesitábamos analizar cómo optimizar nuestro flujo de trabajo de desarrollo existente. En el flujo de trabajo tradicional, una vez que se define el comportamiento de un bloque de función en Simulink, es necesario establecer casos de prueba en Simulink, incluidos vectores de entrada (estímulos) y vectores de salida (objetivos). Los casos de prueba se ejecutan utilizando Simulink Test™ y la cobertura de pruebas se mide con Simulink Coverage™ (Figura 3, Ruta 1).

Este enfoque plantea dos cuestiones clave. En primer lugar, la tarea de generar manualmente casos de prueba para cada función puede consumir mucho tiempo, incluso para ingenieros de pruebas experimentados. En segundo lugar, si las pruebas no alcanzan una cobertura del 100% para la función sometida a prueba, puede ser muy difícil determinar si se debe a un error de diseño de la función misma o una deficiencia en el método de prueba, lo que requeriría definir y ejecutar más pruebas.

Para resolver estos problemas, utilizamos Simulink Design Verifier para generar automáticamente casos de prueba (con métodos formales) que logran una cobertura del 100%. Esto elimina la necesidad de definir casos de prueba manualmente. También resuelve el problema de cómo detectar errores de diseño en la función sometida a prueba. Si Simulink Design Verifier no puede lograr una cobertura del 100 %, resalta la ubicación del error de diseño en la función misma. Este flujo de trabajo supone una mejora sustancial respecto al método tradicional (Figura 3, ruta 2a).

Si bien el uso de Simulink Design Verifier ofrece beneficios sustanciales, introduce una nueva tarea a realizar. En el método tradicional, el ingeniero de pruebas generalmente diseña el comportamiento funcional deseado (objetivos) implícitamente en los casos de prueba a medida que se desarrollan. Si las pruebas pasan con éxito, se considera que la función se comporta correctamente. Sin embargo, cuando se utilizan generadores automáticos de casos de prueba, los algoritmos formales carecen de conocimiento sobre lo que se considera un comportamiento lógico correcto. Por este motivo, es necesario revisar los casos de prueba (y los resultados correspondientes) generados por Simulink Design Verifier para verificar la precisión del comportamiento, es decir, revisar las pruebas generadas para verificar que la función se comporta según lo previsto.

Esto se puede lograr revisando los casos de prueba (junto con los resultados esperados) directamente mediante diagramas de tiempo, simulación de casos de prueba y observación de resultados de la simulación basada en el tiempo en el modelo mismo. Ambas opciones pueden resultar complicadas y propensas a errores, especialmente en funciones con múltiples entradas y salidas. Estas pruebas requieren un ingeniero de pruebas experimentado con Simulink instalado y pueden ser propensas a errores de revisión cuando hay muchas funciones para revisar.

Debido a nuestro interés en que las revisiones de diseño se realizaran en un entorno colaborativo, estamos desarrollando un concepto denominado Listas de verificación de comportamiento para evaluar la precisión del comportamiento de las funciones de software. Desarrollamos un script de MATLAB^® que convierte los casos de prueba de Simulink en un formato procedimental facilita y agiliza la lectura e interpretación en comparación con diagramas de tiempo tradicionales (Figura 3, ruta 2b).

Detalles sobre las listas de verificación de comportamiento

Un elemento clave de nuestro nuevo flujo de trabajo es que los ingenieros pueden revisar la precisión del comportamiento de los bloques de función utilizando listas de verificación en lugar de leer diagramas de tiempos o ejecutar simulaciones. Estos métodos a menudo pueden consumir mucho tiempo y son propensos a errores, especialmente cuando se manejan un gran número de entradas y salidas. Para superarlo, se desarrollaron listas de verificación de comportamiento concisas y fáciles de leer, centradas en la información de interés. Los ingenieros pueden utilizar estas listas de verificación de forma individual o en grupos para evaluar cada bloque funcional y su respuesta a los cambios en los estímulos de entrada (Tabla 1), incluso si no utilizan Simulink regularmente o no está instalado. Esto permite la participación de un mayor número de expertos en la materia en el proceso de revisión de diseño y reduce la carga del ingeniero de pruebas. Dado que varias personas revisan los resultados offline, hay más probabilidad de detectar errores lógicos. Las listas de verificación se generan automáticamente utilizando scripts de MATLAB a partir de casos de prueba de Simulink, que a su vez se generan automáticamente utilizando Simulink Design Verifier.

Importación de casos de prueba de Simulink a TIA Portal

En la sección final de nuestro flujo de trabajo, los bloques de función se reimplementan y se prueban en el entorno de PLC objetivo. Comenzamos utilizando un segundo script de MATLAB para convertir los casos de prueba de Simulink en archivos de casos de prueba de Siemens (que son archivos de texto con una extensión .TAT) (Figura 4). También convertimos los diseños de bloques de función de Simulink a TIA Portal. Finalmente, ejecutamos los casos de prueba convertidos en el código PLC utilizando Siemens PLCSIM y Test Suite Advanced para garantizar la equivalencia en el objetivo.

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

Figura 4. Parte de un caso de prueba de Siemens generado por un script MATLAB a partir de un caso de prueba de Simulink.

Despliegue y aplicación del flujo de trabajo a otros proyectos

Los sistemas de seguridad de alta integridad como el PSS requieren flujos de trabajo de desarrollo rigurosos para minimizar el riesgo de que errores de software puedan dar lugar a situaciones inseguras o incluso catastróficas. Cuando se duplican componentes de software en unidades de procesamiento redundantes, esos riesgos se multiplican aún más, ya que un error se convierte en una causa común (CC). Por este motivo, la norma IEC 61508 pone énfasis en evitar que se introduzcan fallos sistemáticos a través del software en los sistemas de seguridad. Con el diseño basado en modelos y nuestro nuevo flujo de trabajo, hemos logrado un aumento en nuestra capacidad sistemática, tal como se define en IEC 61608, que proporciona un alto nivel de garantía de que hemos implementado un sistema seguro y sin errores.

Las etapas finales de despliegue del PSS actualizado en los últimos segmentos restantes del acelerador (Figura 5) tiene fecha de lanzamiento en el otoño de 2024. Después de completar el PSS, una de nuestras próximas prioridades de desarrollo es actualizar nuestro sistema de monitoreo de pérdida de haz (BLM), parte de nuestro sistema de protección de máquinas. En este proyecto utilizamos un flujo de trabajo muy similar al utilizado para el PSS. Sin embargo, dado que el objetivo del sistema BLM es un FPGA, planeamos utilizar HDL Coder™ para generar código HDL sintetizable directamente a partir de modelos de Simulink y evitar casi por completo la codificación manual en el objetivo. También esperamos utilizar las prestaciones de hardware-in-the-loop de HDL Verifier™ para simplificar y acelerar nuestro flujo de trabajo de verificación y validación en el dispositivo.