1 CSN Licensing of safety critical software for nuclear reactors. Common positions of seven European nuclear regulators and authorised technical support organisations J. YAGÜE (CSN) F. GALLARDO (CSN) SNE – Madrid a 22 de abril de 2009

2 CSN SNE Abril 2009 - Madrid Licensing of safety critical software for nuclear reactors. NRWG document  Origen del NRWG: La creación del grupo surge de la necesidad de comparar los procesos de licenciamiento de los diferentes paises de la Unión Europea con el objeto de alcanzar una harmonización progresiva de los requisitos de seguridad y criterios. - En 2000: la primera versión, EUR 19265. - En 2007: revisión de la anterior e inclusión de nuevos capítulos. Países que participan actualmente: -AVN, Bélgica -BfS, Alemania -ISTEC, Alemania -HSE, Nuclear Installations Inspectorate(NII), Reino Unido -SKI, Suecia -STUK, Finlandia -CSN, España J. Yagüe, F. Gallardo

3 CSN  Objeto: alcanzar consenso y posiciones técnicas comunes sobre ciertos aspectos importantes de licenciamiento en el diseño y la operación de sistemas basados en software usados en centrales nucleares.  El documento no debe ser entendido como una norma, o como nueva regulación europea.  Está orientado principalmente a “Safety Systems”. Excepto el capítulo 1.11 relativo a “Graded Requirements for New and Pre-Existing software of Safety Related Software”. SNE Abril 2009 - Madrid Licensing of safety critical software for nuclear reactors. NRWG document J. Yagüe, F. Gallardo

4 CSN ESTRUCTURA DEL DOCUMENTO  2 PARTES: -Parte 1: Generic Licensing Issues -Parte 2: Life Cycle Phase Licensing Issues  Capítulos: -Rationale -Issues Involved -Common Positions -Recommended Practices Licensing of safety critical software for nuclear reactors. NRWG document SNE Abril 2009 - Madrid J. Yagüe, F. Gallardo

5 CSN  Part 1: Generic Licensing Issues –1.1 Safety Demonstration –1.2 Safety Categories, Classes and Graded Requirements for Software –1.3 Reference Standards –1.4 Use and Validation of Pre-existing Software (PSW) –1.5 Tools –1.6 Organisational Requirements –1.7 Software Quality Assurance Programme and Plan –1.8 Security –1.9 Formal methods –1.10 Independent Assessment –1.11 Graded Requirements for New and Pre-existing Software (PSW) of Safety Related Systems –1.12 Software Design Diversity –1.13 Software Reliability –1.14 Use of Operating Experience Licensing of safety critical software for nuclear reactors. NRWG document SNE Abril 2009 - Madrid J. Yagüe, F. Gallardo

6 CSN  Part 2: Life Cycle Phase Licensing Issues –2.1 Computer Based System Requirements –2.2 Computer System Design –2.3 Software Design and Structure –2.4 Coding and Programming Directives –2.5 Verification –2.6 Validation & Commissioning –2.7 Change Control and Configuration Management –2.8 Operational requirements Licensing of safety critical software for nuclear reactors. NRWG document SNE Abril 2009 - Madrid J. Yagüe, F. Gallardo

7 CSN CLASIFICACIÓN DE SEGURIDAD  Se utiliza la clasificación de seguridad de los sistemas propuesta por la IAEA: Safety Systems, Safety Related Systems y Systems not Important for Safety (Capítulo 1.2).  Posición común: los requisitos aplicables a Safety Systems incluirán todos los requisitos “shall” establecidos por la IEC-60880.  Recomendación: ciertos requisitos de la IEC-60880 se pueden relajar si la fiabilidad requerida para el sistema de seguridad es baja (probabilidad de fallo a demanda del orden de 10 -1 o 10 -2 ).  Recomendación: El uso de la IEC-61226 para determinar la identificación de las funciones y sistemas que pertenecen a la clase de Safety Systems. SNE Abril 2009 - Madrid Licensing of safety critical software for nuclear reactors. NRWG document J. Yagüe, F. Gallardo

8 CSN  SAFETY PLAN y SAFETY DEMONSTRATION Se debe acordar desde el principio del proyecto un Safety Plan entre el titular y el regulador. Este plan identificará la forma en que se alcanzará la “safety demonstration”. Se identificarán el tipo de evidencias que serán consideradas, y el como y cuando se producirán estas evidencias. Se identifican tres tipos básicos independientes de evidencias que se deben de obtener: - Calidad del proceso de desarrollo; - Adecuación del producto; - Competencia y cualificación del personal involucrado en cada una de la fases del ciclo de vida del sistema. -En el caso de pre-existing software: se habrá de considerar también la experiencia operativa del sistema para soportar la safety demonstration. Licensing of safety critical software for nuclear reactors. NRWG document SNE Abril 2009 - Madrid J. Yagüe, F. Gallardo

9 CSN SAFETY DEMONSTRATION  Existen diferentes aproximaciones entre titular y regulador para alcanzar la safety demonstration: -Basada en reglas: Obtención de evidencias de que se cumple con una serie de reglas, normas y leyes. -Método de las tres patas: evidencias relativas a demostrar la Calidad en el diseño, calidad en la evaluación, calidad en las pruebas. -Aproximación probabilista: Se pueden utilizar evidencias de tipo probabilista. La combinación de las distintas aproximaciones también es posible. Ninguna de las aproximaciones está exenta de problemas.  De revisiones de los diferentes procesos de licenciamiento de los países de la Unión Europea, se observó que no existía un método sistemático definido para demostrar la seguridad de los sistemas basados en software. Licensing of safety critical software for nuclear reactors. NRWG document SNE Abril 2009 - Madrid J. Yagüe, F. Gallardo

10 CSN  Una aproximación sistemática y bien planificada puede contribuir a mejorar la calidad de la “safety demonstration” y reducir sus costes.  Beneficios: –Permitir a la partes involucradas centrar su atención en las cuestiones específicas de la seguridad de mayor relevancia para el sistema y en sus correspondientes requisitos del sistema que deben ser cumplidos. –Permitir realizar una priorización de los requisitos del sistema, y con ello una asignación de los recursos acorde a ella. –Organizar los requisitos del sistema para que los argumentos y evidencias se ajusten a lo que se entiende estrictamente necesario y suficiente por todas las partes involucradas. Licensing of safety critical software for nuclear reactors. NRWG document SNE Abril 2009 - Madrid J. Yagüe, F. Gallardo

11 CSN SAFETY DEMONSTRATION  Objeto: demostrar que se cumplen los requisitos del sistema, establecidos en la especificación de requisitos.  Definición: Conjunto de argumentos y evidencias que soportan un conjunto de premisas sobre confiabilidad- en particular la seguridad – de la operación de un sistema importante para la seguridad usado en el entorno de la planta. Las premisas identificarán las propiedades funcionales y/o no funcionales que debe satisfacer el sistema. Estas premisas se pueden descomponer en varias sub-premisas más simples, que a su vez pueden seguir descomponiéndose en más sub-premisas. Las premisas habrán de ser soportadas por evidencias: datos o hechos, sobre los que existe un acuerdo de aceptabilidad por todas las partes implicadas, sin necesitar más evaluación. Argumento: lo constituyen el conjunto de evidencias que soportan una premisa, junto con la especificación de las relaciones entre estas evidencias y la premisa. SNE Abril 2009 - Madrid Licensing of safety critical software for nuclear reactors. NRWG document J. Yagüe, F. Gallardo

12 CSN SNE Abril 2009 - Madrid Licensing of safety critical software for nuclear reactors. NRWG document J. Yagüe, F. Gallardo

13 CSN SAFETY DEMONSTRATION  La seguridad sólo puede ser analizada y demostrada mediante el uso de descripciones precisas que incluyan: -La arquitectura del sistema. -Diseño del hardware y software. -Comportamiento del sistema y sus interacciones con el entorno de la planta. -Modelos de accidentes postulados.  Estas descripciones deben ser entendidas y acordadas sin ambigüedades por todas las partes que tengan responsabilidades sobre la confiabilidad del sistema: usuarios, diseñadores y evaluadores. SNE Abril 2009 - Madrid Licensing of safety critical software for nuclear reactors. NRWG document J. Yagüe, F. Gallardo

14 CSN SAFETY DEMONSTRATION  “Safety demonstration” identificará un conjunto completo y consistente de requisitos que han de ser satisfechos. Habrá de incluir: -Validez de los requisitos funcionales y no funcionales del sistema y su adecuación en la especificación de diseño. -Corrección del diseño y la implantación del sistema digital de forma que se garantice que se comporta de acuerdo con la especificación. -Operación y mantenimiento del sistema para garantizar que se seguirán cumpliendo las premisas sobre seguridad y las condiciones limitativas de su entorno durante toda la vida del equipo. SNE Abril 2009 - Madrid Licensing of safety critical software for nuclear reactors. NRWG document J. Yagüe, F. Gallardo

15 CSN USO Y VALIDACIÓN DE PRE-EXISTING SOFTWARE (PSW) -El uso de PSW puede ser beneficioso para incrementar la seguridad si se introduce adecuadamente. -La principal ventaja: su experiencia operativa, cuando ésta puede ser evaluada y es suficientemente representativa para ser tenida en cuenta. -Se han desarrollado componentes con software de acuerdo con altos estándares de calidad de otras industrias, y es razonable que puede ser usado en aplicaciones nucleares, siempre que se garantice que se ha realizado una evaluación adecuada de los mismos. SNE Abril 2009 - Madrid Licensing of safety critical software for nuclear reactors. NRWG document J. Yagüe, F. Gallardo

16 CSN USO Y VALIDACIÓN DE PRE-EXISTING SOFTWARE (PSW)  Cuestiones a considerar: –Es dudoso que existan evidencias para demostrar que se ha seguido un proceso de desarrollo acorde a lo requerido por la IEC-60880. –La documentación y los datos sobre experiencia operacional no son del todo suficientes o adecuados para proporcionar evidencias de que pudieran compensar la carencia de conocimiento sobre el proceso de desarrollo seguido. –La experiencia operacional existente sobre el componente con PSW puede no estar en exacta correspondencia con la aplicación prevista en la planta. –Habría que considerar el impacto potencial de funciones residentes no documentadas o no usadas. SNE Abril 2009 - Madrid Licensing of safety critical software for nuclear reactors. NRWG document J. Yagüe, F. Gallardo

17 CSN USO Y VALIDACIÓN DE PRE-EXISTING SOFTWARE (PSW)  Posición Común: –Se identificarán claramente las funciones a realizar por los componentes con PSW, y evaluar el impacto en la seguridad de estas funciones. Realizar un análisis de fallos del PSW y prestar especial atención a los aspectos de interfases con el usuario y/o con otros componentes con software. –Identificar los componentes PSW a utilizar, incluyendo la versión de código. –Para Safety Systems, el PSW será sometido a una evaluación del producto final, igual que si fuese software nuevo desarrollado para la aplicación. Si es necesario se realizarán actividades de ingeniería inversa para cubrir deficiencias de documentación. –La información requerida para evaluar la calidad del producto PSW y de su proceso de desarrollo estarán disponibles. La información será suficiente para que se pueda demostrar que el PSW tiene e nivel de calidad requerido. –Si son necesarias modificaciones en los componentes PSW, la documentación de diseño y el código fuente habrán de estar disponibles. SNE Abril 2009 - Madrid Licensing of safety critical software for nuclear reactors. NRWG document J. Yagüe, F. Gallardo

18 CSN USO Y VALIDACIÓN DE PRE-EXISTING SOFTWARE (PSW)  Acciones a llevar a cabo para la aceptación: –Verificar que las funciones que realiza el PSW cumplen con los requisitos establecidos en la Especificación de requisitos del sistema y en la especificación software. –Verificar que las funciones que no son requeridas en la especificación de requisitos no son llamadas y no producen efectos adversos sobre las funciones requeridas (entradas erróneas, interrupciones,…) –Verificar que si hay funciones que son omitidas, que esta omisión no tenga efectos adversos. –Realizar un análisis de cumplimiento del diseño del PSW con ciertas normas aplicables (p.e: IEC-60880). –Las funciones requeridas serán validadas mediante pruebas. –Respecto a la experiencia operativa, ésta ha de ser referida a usos de los componentes PSW idénticos a los que se van a utilizar en la central, y ha de ser con la versión considerada en la aplicación, a no ser que se demuestre que el impacto de de versiones anteriores no cambia las partes utilizadas en la versión utilizada en la aplicación. SNE Abril 2009 - Madrid Licensing of safety critical software for nuclear reactors. NRWG document J. Yagüe, F. Gallardo

19 CSN Task Force on safety critical software Agenda 28th Meeting 3-4 March 2009 ISTec GmbH 85748 Garching bei München Forschungsgelände Start: Tuesday 3 March 09.00 Welcome and introductions Approval of agenda and minutes Review of actions Exchange of information on salient national and international developments and events [All] US NRC involvement France ASN involvement Discussions: CCF/Equipment properties – Action 08-08-6 refers [Germany – FS] Autocode generation - Action 08-03-4 refers [Germany – JM/FS] Development of common position document on licensing of “safety related software” for nuclear reactors – Action 08-08-11 refers [MB] Maintenance of 7 party common position report Inspection of digital I&C – Action 08-08-9 refers [Germany – FS] Comments received – Action 08-08-15 refers [UK – MB] Wednesday 4 March 09.00 New Chapter on SMART Sensors/actuators – Action 08-08-14 refers [Lead: UK – RLY] Date and place of next meeting Any other business SNE Abril 2009 - Madrid Licensing of safety critical software for nuclear reactors. NRWG document J. Yagüe, F. Gallardo

20 CSN ACCIONES FUTURAS  Nuevo documento: Common Position Document on Licensing of “Safety Related Software” for nuclear reactors.  Prácticas de Inspección de sistemas digitales de I&C.  Nuevo capítulo sobre SMART Sensors/actuators.  Participación de la NRC en el grupo ¿¿?? SNE Abril 2009 - Madrid Licensing of safety critical software for nuclear reactors. NRWG document J. Yagüe, F. Gallardo

21 CSN IS DEL CSN SOBRE CRITERIOS GENERALES DE DISEÑO DE CENTRALES NUCLEARES F. GALLARDO (CSN) J. YAGÜE (CSN) SNE – Madrid 22 de abril de 2009

22 CSN SNE Abril 2009 - Madrid IS del CSN sobre CGD IS CGD 1.8. Los sistemas digitales que se utilicen para realizar las funciones de seguridad, o que puedan afectar a su realización, deberán estar diseñados con las siguientes características: 1.Los sistemas serán diseñados, construidos, verificados, validados, probados y controlados de acuerdo con los más altos estándares de calidad reconocidos internacionalmente en el ámbito nuclear. 2.El proceso completo de desarrollo de los sistemas, incluyendo el control, pruebas y puesta en servicio de las modificaciones de diseño, deberá documentarse y revisarse de manera sistemática. 3.En aquellos casos en los que la fiabilidad de los sistemas no pueda demostrarse con un alto nivel de confianza, se dispondrá de un método alternativo para garantizar el cumplimiento de sus funciones de seguridad. Actualmente incluido en la Parte 1: “Requisitos Generales”, Criterio 1: “Diseño de las funciones de seguridad”. F. Gallardo; J.Yagüe

23 CSN SNE Abril 2009 - Madrid IS del CSN sobre CGD Comentarios Sector (UNESA): “La redacción del criterio en su totalidad, y en particular del punto 1, tiene sentido si se refiere al Sistema de Protección (RPS o ESFAS). Sin embargo, no queda claro si éste es el alcance que se pretende o aplicaría a cualquier componente importante para la seguridad. Si se quisiera ampliar el alcance a todos los sistemas o componentes importantes para la seguridad, se debería dar cabida a sistemas no diseñados “safety grade”, a los que se aplicaría lo que establecen para esos componentes las guías al efecto. En la redacción propuesta, no se da cabida a los procesos de dedicación. Sería más adecuado limitar este criterio a los sistemas de protección como hace WENRA, y generar nueva normativa aplicable a las modificaciones futuras que usen esta instrumentación”. F. Gallardo; J.Yagüe

24 CSN SNE Abril 2009 - Madrid IS del CSN sobre CGD Postura INEI: Se considera RAZONABLE lo reflejado por el sector. Propondrá mover el texto a los apartados dedicados a sistemas de protección (Parte 3: Sistemas de protección y control de la reactividad, Criterio 21: Fiabilidad y posibilidad de prueba del sistema de protección), sustituyendo “los sistemas digitales que se utilicen para realizar las funciones de seguridad…” por “… las funciones de protección ….”. Revisión inicial del texto por INEI: evitar la conclusión errónea de que requerimientos de calidad no son aplicables a todos los sistemas de seguridad y sólo a los de protección. En los comentarios se había incluido el matiz “… a los estándares de calidad reconocidos internacionalmente acorde a la relevancia de la función de seguridad a realizar”. El hecho de que como CGD se mencione expresamente “sistemas de protección” no significa que los “sistemas de seguridad” digitales no estén sometidos a requisitos de calidad, que ha de ser demostrada. F. Gallardo; J.Yagüe

25 CSN SNE Abril 2009 - Madrid IS del CSN sobre CGD F. Gallardo; J.Yagüe WENRA SRLs COMENTARIOS SECTOR IS CGD - CSN