Los procesos para realizar la definición conceptual del diseño y la implementación se ilustran en la Figura 29. En esta fase 6 del ciclo de vida del desarrollo bajo norma EN-50126, se diseñan e implementan los subsistemas que componen el desarrollo y que se ajusten a los requisitos RAMS, se demuestra que los subsistemas desarrollado se ajustan a los requisitos RAMS, se establecen los planes de fabricación, instalación, operación y mantenimiento y finalmente se elaboran los casos de seguridad que permiten demostrar el cumplimiento de los requisitos globales RAMS del sistema.
1. DISEÑO DE LOS SUBSISTEMAS QUE SE AJUSTEN A LOS REQUISITOS RAMS
El proceso para diseñar subsistemas que se ajusten a los requisitos RAMS del sistema se debe llevar a cabo después de la especificación de requisitos y de la distribución de esos requisito en los diferentes subsitemas. Si hacemos una lista de tareas a realizar podríamos encontrar una como la siguiente:
Las tareas no necesariamente se realizan en el orden enumerado, se puede definir un ciclo de vida para el hardware (Figura ....) y otro para el software (figura ....).
Desarrollo del hardware
NOTA: Parte de este documento ha sido extraído del "Fondo de Información y Documentación para la Industria" – Cuaderno de trabajo Número 05 “Proceso de desarrollo de sistemas embebidos y aseguramiento de la calidad”, Autor: Dr. Leonardo R. Chapela Castañares. Noviembre de 2013a) Diseño de Hardware
Este proceso considera tres componentes:
b) Semiconductores
Este proceso considera la elección de la tecnología a utilizar y para ello se podrá optar sobre diferentes tipos de circuitos integrados, como por ejemplo:
c) Estándares del Hardware
Este proceso considera la utilización de elementos tales como los siguientes:
d) Proceso: Prototipado de Hardware
Este proceso considera cinco componentes con sus respectivos subprocesos:
Desarrollo del software
En referencia al desarrollo del software, la norma EN 50128 nos muestra un ciclo de vida para el desarrollo del sistema, el cual se muestra en la siguiente figura.
Tomaremos de la norma IEC 51511 y de AADECA dos modelos de ciclo de vida del software específico de la seguridad funcional.
La interpretación del Modelo V es la siguiente:
Gestión y organización del desarrollo del software
Un requisito ineludible para lograr la certificación de un nivel SIL, sera la certificación de al menos las partes relativas a la organización y gestión del personal y sus responsabilidades, según la norma ISO 9001.
La estructura organizativa, según el nivel SIL que se pretende alcanzar sera como se muestra en la figura .... (Fuente EN 50128- Figura 2: Estructura organizativa preferida)
Estándares del software
En este apartado se definen tres componentes: Sistema Operativo, Middleware y Firmware.
Software de Aplicación
El desarrollo de la aplicación considera cinco componentes: Modelado, Generación de Código, Prototipo, Verificación y Pruebas así como Diseño del Reuso. Se puntualizan las tareas:
Un software seguro se logra utilizando:
El ecosistema de herramientas para el desarrollo de software
Siguiendo La norma EN 50128, para el desarrollo de software es necesario contar con un conjunto de herramientas que asistan en la construcción del sistema.
El ecosistema de calidad de software está compuesto por tres subsistemas lógicos que se mencionan a continuación:
● Ecosistema de gestión y modelado: instrumenta la gestión documental, la planificación de las tareas para los proyectos, el seguimiento y control, los reportes y la trazabilidad. Incluye también las herramientas de modelado y diseño.
● Ecosistema de integración continua: instrumenta la gestión de los análisis y la integración del código fuente elaborado a partir de un ciclo de vida iterativo e incremental. Materializa las buenas prácticas de mantenibilidad, fiabilidad, disponibilidad y seguridad, y permite el establecimiento de umbrales con los que controlar la evolución de sistema software. Busca mantener las buenas prácticas y comunicar rápidamente los desvíos.
● Ecosistema de ensayos: instrumenta la gestión de los ensayos manuales, asistidos y automáticos; tanto su especificación como la elaboración de informes y la gestión de los usuarios encargados de realizarlos.
En la Figura se presenta un esquema del ecosistema. A continuación se describe cada herramienta y se detalla su necesidad de uso en base a la norma EN 50128 así como la relación entre las mismas.
La herramienta Redmine [https://www.redmine.org/] funciona como gestor de trabajo colaborativo de fuente abierta.
Uso:
gestionar las tareas a ser llevadas adelante a lo largo de un proyecto de desarrollo de software para un sistema crítico ferroviario. Archivar los registros documentales del proyecto y la relación entre las tareas y el código fuente.
Relación con la norma EN 50128:
● Gestión de la documentación del proyecto.
● Marco para lograr la trazabilidad entre las diferentes transformaciones de los elementos, desde los requisitos hasta el sistema final, incluyendo los modelos, diseños, documentos, pruebas y ensayos.
La herramienta Testlink [https://www.testlink.org] se utiliza como gestor de prueba y ensayos.
Uso:
gestionar los ensayos a lo largo de un proyecto de desarrollo de software para un sistema crítico ferroviario. Mantener el histórico de informes de ensayos.
Relación con norma EN 50128:
● Gestión de los roles y responsabilidades para los ensayos.
● Especificación de los ensayos.
● Planificación de los ensayos.
● Ejecución de los ensayos.
● Comunicación de los defectos.
● Gestión de los informes de ensayos.
La herramienta Eclipse Process Framework (EPF) [https://www.eclipse.org/epf/] se utiliza para la construcción de la metodología de trabajo con el cual se desarrollará el software.
Uso:
construir la metodología de trabajo según la EN 50128 para que sea accesible y adaptable.
Relación con norma EN 50128:
● Construcción del Sistema de Gestión de Calidad.
● Construcción de los procedimientos generales.
● Comunicación de los procedimientos, formularios y guías.
Se utiliza la herramienta SONAR [https://www.sonarsource.com/] para el análisis estático del código fuente y Jenkins [https://www.jenkins.io] como servidor de integración continua.
Uso:
gestionar los análisis estático, dinámicos, pruebas, cobertura, instalación y despliegue para ensayos de los sistemas software.
Relación con norma EN 50128:
● Gestión de los ensayos.
● Verificación y validación.
● Análisis del código fuente.
Finalmente, como herramienta aglomeradora se utiliza el GIT [https://git-scm.com/] como controlador de versiones del código fuente y de los procedimientos. Se la usa para gestionar la colaboración para el desarrollo del código fuente y la metodología de trabajo. Y como entorno de desarrollo se utiliza la herramienta Eclipse IDE [https://www.eclipse.org].
2. DEMOSTRAR QUE LOS SUBSISTEMAS SE AJUSTAN A LOS REQUISITOS RAMS
El proceso para demostrar que los subsistemas se ajustan a los requisitos RAMS del sistema se describe en la Figura.
La verificación del software tiene como objetivo llegar a una conclusión, basada en pruebas, de que los elementos de salida de una fase del desarrollo, cumplen con los requisitos, corrección y coherencia. Se hará en base a un plan de verificación del software y se documentara lo realizado en uno o mas informes de verificación. Este plan debe incluir al menos:
Las pruebas de aceptación de fábrica (FAT, Factory Acceptance Test) del sistema lógico y su software asociado tienen como objetivo asegurar que se satisfacen lo requerimientos definidos en las especificaciones de seguridad, antes de su instalación definitiva.
El número de participantes de las pruebas dependerá del tamaño del sistema pero en términos generales participa el personal involucrado con el diseño y la implementación, debiéndose definir las responsabilidades.
En estas pruebas FAT se debe probar:
Las pruebas deben ser documentadas. Los criterios más usuales (no únicos) para la realización de las pruebas, podemos mencionar:
Si durante las pruebas FAT se detectan errores y se requieren modificaciones, ha de estudiarse el impacto de estas sobre la integridad del sistema de seguridad y se deberá recalcular la probabilidad de falla en demanda (PFD).
La importancia de realizar unas pruebas de la lógica antes de la instalación, conlleva una serie de beneficios:
La verificación del hardware, al igual que el software, debe hacer referencia a un plan de verificación de cada fase del ciclo de vida del desarrollo, para garantizar que se cumple con los requisitos específicos.
La documentación de la fase de diseño se podrá componer de algunas de las siguientes técnicas (Fuente EN 50129, Tabla E.8):
Algunas de las técnicas de verificación del hardware, serán (Fuente EN 50129, Tabla E.9):
Verificación del nivel de integridad de seguridad (SIL)
Para cumplir con el SIL objeto no basta con adquirir componentes con el distintivo “SIL certified” y asumir que de este modo se consiga la conformidad predefinida. Una propuesta de plan de cara al cumplimiento normativo sería cumplir con los requisitos de las normas directa o indirectamente relacionadas. Esto incluye verificar (entre otras):
• Requisitos de comportamiento del sistema al detectar un fallo: Debe especificarse el comportamiento del sistema al detectar un fallo. Puede detallarse, por ejemplo, en la especificación de requisitos de seguridad o en las especificaciones de diseño.
• Tolerancia a fallos de hardware: Se requiere una evaluación cuantitativa respecto a la fracción de fallos seguros (SFF) y a las restricciones arquitectónicas.
• Selección de componentes y de subsistemas: La selección de componentes y de subsistemas puede basarse en una evaluación de idoneidad.
La evaluación del proveedor debe incluir los sistemas de gestión de calidad del fabricante y de gestión de configuración, y deben formar parte de la evidencia de la idoneidad presentada en la especificación de diseño funcional.
• Dispositivos de campo: La documentación de especificación debe mostrar que el componente cumple con los requisitos específicos en términos de funcionalidad para todos los procesos y todas las condiciones medioambientales y la especificación de diseño funcional debe confirmar esto en tal caso. La especificación de diseño funcional también debe confirmar que todos los circuitos de entrada/salida discretos de energización a disparo deben aplicar un método para garantizar la integridad del circuito y de la fuente de alimentación eléctrica, p. ej., un monitorización de línea.
Los sensores inteligentes deben contar con protección frente a escritura para evitar la modificación inadvertida desde una ubicación remota, a menos que una revisión de seguridad apropiada permita el uso de lectura/escritura.
• Interfaces del usuario, de mantenimiento y de comunicación con el sistema instrumentado de seguridad: El diseño de la interfaz de comunicación del sistema instrumentado de seguridad debe garantizar que cualquier fallo de esta interfaz no afecte de forma negativa la capacidad del sistema instrumentado de seguridad de llevar el proceso a un estado de seguridad. Esto debe confirmarse en la documentación de diseño.
La documentación también debe confirmar:
• Requisitos de diseño relativos al mantenimiento o a las pruebas: El diseño del sistema debe prever y permitir pruebas de tal forma que la prueba pueda llevarse a cabo de forma integral o por partes.
• Probabilidad de fallo de las funciones instrumentadas de seguridad;
• Software de aplicación: Se debe verificar y garantizar que:
3. ESTABLECER PLANES PARA FUTURAS TAREAS RAMS DEL CICLO DE VIDA
El proceso para establecer planes para futuras tareas RAMS del ciclo de vida se describe en la secuencia de tareas de la Figura.
3.1 Plan de Instalación.
Un plan para la instalación de los sistemas relacionados con la seguridad E/E/PE, comprende:
3.2 Plan de puesta en servicio.
El sistema instrumentado de seguridad debe ponerse en servicio de conformidad con la planificación y con los procedimientos. Deben facilitarse registros con los resultados de las pruebas e indicando si se han cumplido los criterios de aceptación definidos durante la fase de diseño. Los fallos deben ser objeto de investigación y registro. En caso de que se establezca que la instalación actual no cumple con la información de diseño, debe investigarse la divergencia y determinarse el impacto sobre la seguridad.
Los procedimientos de validación deben incluir todos los modos de operación del proceso y del equipo asociado y deben incluir:
Además, la validación del software de aplicación debe incluir:
La validación debe garantizar que el sistema instrumentado de seguridad funcione en todos los modos de servicio y que no se vea afectado por la interacción del sistema básico de control de proceso (BPCS) y otros sistemas conectados. La validación de rendimiento debe garantizar que todos los canales redundantes funcionen, así como las funciones de omisión, las anulaciones de puesta en marcha y los sistemas de cierre manual.
Debe llegarse al estado definido, o seguro, en caso de pérdida de energía, p. ej., energía eléctrica o hidráulica o aire de instrumentación. Las funciones de alarma de diagnóstico definidas en la especificación de requisitos de seguridad deben funcionar y ofrecer un rendimiento tal y como se especifica en variables de proceso no válidas, p. ej., entradas fuera de rango. Después de la validación deben facilitarse registros apropiados y se deben identificar el elemento de prueba, el equipo de prueba, los documentos de prueba y los resultados de prueba además de cualquier discrepancia y análisis o solicitudes de cambio que surjan al respecto.
3.3 Plan de operación y mantenimiento.
El objetivo de los requerimientos de esta sub-cláusula es el desarrollo de un plan para la Operación y Mantenimiento del sistema E/E/PE relacionado con seguridad, para garantizar que la seguridad funcional requerida es mantenida durante la operación y el mantenimiento.
Operación
Los requisitos para la operación y mantenimiento deben definirse en el plan de operación y mantenimiento. Los procedimientos de operación y mantenimiento definen las operaciones rutinarias que han de llevarse a cabo para mantener la seguridad funcional del sistema instrumentado de seguridad.
Estas operaciones deben incluir requisitos para:
Deben desarrollarse procedimientos de pruebas de calidad, de tal manera que cada función instrumentada de seguridad se ponga a prueba a fin de sacar a la luz fallos peligrosos que no sean detectados mediante diagnósticos (pruebas de calidad).
Se requieren procedimientos de mantenimiento para el diagnóstico y la reparación de fallos, y la revalidación del sistema tras una reparación, acciones que deben tomarse tras discrepancias entre el comportamiento esperado y el comportamiento real, la calibración y el mantenimiento del equipo de prueba y la generación de informes de mantenimiento.
Se requieren procedimientos de generación de informes para informar sobre fallos, analizar fallos sistemáticos y por causas comunes, y para dar seguimiento al rendimiento del mantenimiento.
Formación para la operación y mantenimiento
La formación del personal de operacion y mantenimiento se debe planificar y realizar oportunamente, de manera que se pueda llevar a cabo el funcionamiento y el mantenimiento del sistema instrumentado de seguridad de acuerdo con la especificación de requisitos de seguridad (SRS).
La formación debe incluir:
Mantenimiento
La fiabilidad y disponibilidad de una instalación dependen sin duda alguna del mantenimiento que se realice en ella. Si el mantenimiento es básicamente correctivo, atendiendo sobre todo los problemas cuando se presentan, es muy posible que a corto plazo esta política sea rentable pero si no se hace nada desde un punto de vista preventivo, puede llegar un momento en el que el equipo o sistema no pueda ser reparado y o su reparación resulte tan cara como adquirir un nuevo producto o sistema.
La ocasión perfecta para diseñar un buen mantenimiento programado que haga que la disponibilidad y la fiabilidad de un sistema sea muy alta, es durante la construcción de éste.
Un buen plan de mantenimiento es aquel que ha analizado todos los fallos posibles, y que ha sido diseñado para evitarlos. Eso quiere decir que para elaborar un buen plan de mantenimiento es absolutamente necesario realizar un detallado análisis de fallos de todos los sistemas que componen la planta.
La elaboración de un Plan de Mantenimiento implica definir aspectos tales como:
Algunos errores habituales al elaborar planes de mantenimiento son:
Estrategias de mantenimiento
Existen diversas estrategias de mantenimiento, las que se clasifican principalmente según el momento en que se lleva a cabo el proceso de mantención y el objetivo que este tiene. Además, es importante señalar que no existe una misma estrategia de mantención óptima para todos los sistemas, sino que depende de cada caso particular.
En cada caso, actúan diversos factores que abarcan el ámbito operacional, seguridad ambiental y de los trabajadores, los costos de mantenimiento, la frecuencia de fallas, entre otras. Estos factores cobrarán mayor o menor importancia considerando el objetivo impuesto por la empresa para la mantención. La estrategia puede estar enfocada a asegurar la operación de un equipo o en la minimización de los costos ocasionados por la falla mediante la disminución de la cantidad de fallas.
En términos generales, las estrategias de mantenimiento son las siguientes [1]:
Análisis de criticidad
Existen diversas formas de definir la criticidad de los equipos. Sin embargo, y de manera independiente de la forma en que se realice, este análisis es crucial para obtener un buen plan de mantenimiento. Definiendo de manera correcta los equipos y/o modos de falla (Maneras posibles en las que puede fallar un equipo) es posible saber en qué enfocar el mantenimiento.
Confiabilidad
La Confiabilidad (R(t)) se define como la probabilidad de que el equipo o componente no falle en un intervalo de tiempo determinado. Por otra parte, se define la Probabilidad de falla (F(t)) como la probabilidad de que un equipo o componente falle en el intervalo de tiempo determinado. Además se precisa el concepto de Densidad de probabilidad de falla (f(t)) y corresponde a la probabilidad instantánea de que un equipo o componente que no ha fallado sí lo haga en un intervalo [t, t+dt]. [1] En este mismo contexto, un concepto muy importante es la Tasa de Falla que corresponde a la cantidad esperada de fallas para un equipo o componente por unidad de tiempo.
Por otra parte, se define el concepto de Tiempo Medio Para Fallar (Mean Time To Failure -MTTF) y corresponde al tiempo esperado para que un equipo o componente fallen. También es conocido como la vida media. [1]
Otros términos importante en la vida de los componente son el tiempo que transcurre entre cada una de las fallas (MTBF: Mean Time Between Failure) y el tiempo que tarda cada detención (MDT: Mean Detention Time). El MDT se compone a su vez del tiempo en que tarda la reparación (MTTR: Mean Time To Repeair) y el tiempo de espera aparejado a, por ejemplo, retrasos en entrega de repuestos (MWT: Mean Waiting Time). Entonces, un ciclo de un componente sería como el presente en el siguiente esquema. [1]
Tasa de fallas (𝝀, Failure rate).- Número de fallas por unidad de tiempo.
𝝀 = 1 / MTTF
Tasa de reparación (µ, Failure rate).- Número de fallas por unidad de tiempo.
𝝁 = 1 / MDT
Estructura de costos
A la hora de hablar de la definición de un plan de mantenimiento resulta vital establecer los costos asociados a cada ítem presente en el proceso de mantenimiento.
De manera general, los costos asociados al proceso de mantenimiento son los siguientes:
Frecuencia óptima de inspecciones
Para definir las frecuencias óptimas de inspección en primer lugar es necesario determinar qué tan sensibles son las tasas de falla a la realización de las inspecciones.
De ser sensibles se debe seleccionar el modelo adecuado (por ejemplo, deben considerar si domina el costo de falla mínimo o la disponibilidad). Luego se calculan los costos globales con el objetivo de minimizarlos. Finalmente, se selecciona la estrategia óptima.
La frecuencia óptima de inspección está dada por la expresión [2]:
𝑓 ∗ = √( 1 / 𝛼(1+ 1/ 𝛽 ) )* (𝑀𝑇𝑇𝑅/ 𝑀𝑇𝑇𝐼) * ( (𝐶𝑓+𝐶𝑖,𝑟)/ 𝐶𝑖,𝑖 )
Donde:
MTTR es el tiempo medio para reparar,
MTTI es el tiempo medio de intervención,
Cf es el costo a falla,
Ci,r es el costo de intervención reparaciones
Ci,i es el costo de intervenciones de inspección.
β > 0 es el parámetro de forma.
Modificación de funciones instrumentadas de seguridad (SIF)
Antes de proceder a cualquier modificación, deben existir procedimientos para la autorización y el control de los cambios. Esto se gestiona generalmente con una nota de solicitud de cambio (CRN), que normalmente forma parte de un sistema de gestión de calidad (QMS).
Cualquier solicitud de cambio debe describir el cambio requerido y las razones para la solicitud. Esto lo puede proponer el personal de operación y mantenimiento como resultado de incidentes durante el funcionamiento o el mantenimiento. El proceso de aprobación habitual de solicitudes de cambio debe englobar a distintos departamentos dentro de una organización para determinar el impacto del cambio relativo al diseño, la base instalada y la implementación requerida.
Una vez que una organización está involucrada en la seguridad funcional, cualquier solicitud de cambio debe además ser revisada por una persona competente, p. ej. la autoridad de seguridad (SA), para determinar si el cambio puede afectar la seguridad y, en tal caso, se requiere un análisis de impacto adecuado.
Análisis de impacto
Los resultados del análisis pueden requerir una nueva inspección de las primeras partes del ciclo de vida y, por ejemplo, puede ser necesario revisar los peligros identificados y las evaluaciones de riesgos. Las actividades de modificación no pueden empezar sino hasta que este proceso haya sido completado y la autoridad de seguridad haya autorizado el cambio.
El impacto de los cambios relativos a las funciones instrumentadas de seguridad puede afectar consecuentemente al personal de operación y mantenimiento y podría ser necesaria formación adicional.
3.4 Definir un proceso de fabricación - verificación.
Se debe asegurar que los supuestos de diseño no se vean comprometidos durante el proceso de fabricación. Se deben especificar las precauciones en la fabricación y prever auditorias a cargo del responsable de la seguridad de la organización.
4. ELABORAR UN CASO DE SEGURIDAD GENÉRICO Y DE APLICACIÓN
Un caso de seguridad es la demostración documentada de que un producto cumple con los requisitos de seguridad especificados [UE-50126-1].
El caso de seguridad es un documento estructurado para demostrar o evidenciar la seguridad de un producto genérico, una aplicación genérica o específica. Es necesario cuando un peligro no puede ser corregido de inmediato y un análisis deberá demostrar si el riesgo es aceptable. En caso contrario, se demostrará que con una solución alternativa mantendrá el nivel de seguridad operacional dentro de los límites aceptables y no afectará excesivamente la capacidad operacional del sistema o producto.
En base a las consideraciones previas, este documento tiene como objeto establecer un procedimiento para la confección de un Caso de Seguridad, abarcando los siguientes aspectos:
Descripción del procedimiento
Los casos de seguridad son evidencias documentales que indican que se han cumplido las normas, procedimientos y requisitos asociados al proyecto bajo revisión. Esta evidencia se prepara con el fin de ser presentada a la autoridad ferroviaria competente para obtener la aprobación de la seguridad de un producto genérico.
Los casos de seguridad se estructuran en 6 partes según el siguiente detalle:
Apertura del Caso de Seguridad
La apertura del caso de seguridad se realizará a los efectos de solicitar la aprobación de la seguridad a la Autoridad de aplicación, o cuando no se alcanzó el nivel de seguridad deseado o por quejas y reclamos de los usuarios del sistema.
La apertura del caso de seguridad, debe incluir la descripción de peligro que genera el Caso de Seguridad, mostrando las diferencias con las normas vigentes, e indicando eventuales situaciones donde los riesgos son potenciales, además se deberán relacionar y anexar, si es el caso, los documentos y comentarios en los cuales aparece reportado el peligro, tales como informes de verificación o auditorías, las influencias externas que afectan al sistema o producto, la legislación aplicable, etc.
La Figura describe este proceso. Los recuadros punteados representan las diferentes fuentes que pueden dar origen a un caso de seguridad.
Parte 1: Definición del sistema
Se deberá definir o hacer referencia con precisión al sistema / subsistema/ producto al que se refiere el caso de seguridad, incluyendo los números de versión y las modificaciones a los requisitos.
Se deben describir y documentar las evidencias que posteriormente serviran a las conclusiones.
Parte 2: Informe sobre Gestión de la Calidad
Se deben incorporar las evidencias sobre gestión de la calidad. Todo sistema, subsistema o producto debe ser controlado por un sistema eficiente de gestión de la calidad durante todo su ciclo de vida.
El cumplimiento de los requisitos de gestión de la calidad son obligatorios para los niveles de integridad de la seguridad que van del nivel 1 al nivel 4, no obstante las evidencias presentadas serán acordes al nivel SIL del sistema / subsistema / producto.
Los requisitos para nivel de integridad de la seguridad del nivel 0 están fuera del objeto del presente trabajo.
NOTA: En los procesos de recopilación de evidencias, no es necesario crear grandes tomos de documentación. Se recomienda incluir referencias precisas sobre los documentos y especificar claramente los conceptos y los planteamientos adoptados.
Parte 3: Informe sobre gestión de la seguridad
El sistema debe ser gestionado por un sistema de gestión de la seguridad. El propósito de este proceso es reducir la incidencia de errores humanos relacionados con la seguridad, durante todo el ciclo de vida.
El cumplimiento de los requisitos de gestión de la seguridad son obligatorios para los niveles de integridad de la seguridad que van del nivel 1 al nivel 4. No obstante las evidencias presentadas serán acordes al nivel SIL del sistema / subsistema / producto.
Los requisitos del nivel 0 están fuera del objeto del presente trabajo.
El ciclo de vida de la seguridad debe constar de un número de fases y actividades conectadas entre sí para formar el ciclo de vida de la seguridad. Este debe ser consecuente con el ciclo de vida del sistema / subsistema / producto.
NOTA: En los procesos de recopilación de evidencias, no es necesario crear grandes tomos de documentación. Se recomienda incluir referencias precisas sobre los documentos y especificar claramente los conceptos y los planteamientos adoptados.
Parte 4: Caso de seguridad técnica y funcional
Antes de que un sistema / subsistema o producto, pueda ser aceptado como seguro, se debe presentar evidencia técnica sobre la seguridad del diseño.
El cumplimiento de los requisitos de gestión de la seguridad son obligatorios para los niveles de integridad de la seguridad que van del nivel 1 al nivel 4. No obstante las evidencias presentadas serán acordes al nivel SIL del sistema / subsistema / producto.
Los requisitos del nivel 0 están fuera del objeto del presente trabajo.
Un caso de seguridad técnica se compone de 6 secciones:
En la sección 1 "Descripción del diagrama en bloques del diseño y principios de seguridad técnica" se ofrece una referencia a los principios de seguridad de los que depende el sistema y el grado de seguridad adoptado.
En la sección 2 "Recopilación de evidencias del buen funcionamiento del sistema/equipo" se debe constar todas las evidencias necesarias para demostrar el funcionamiento correcto bajo condiciones normales, sin averías.
La sección 3 "Demostración de funcionamiento correcto aun en presencia de fallas" debe documentar cuál es la seguridad intrínseca del sistema, es decir, como el sistema sigue cumpliendo con sus requisitos específicos frente a fallas aleatorias de hardware.
Para sortear con éxito este requerimiento, se recomienda la adopciòn de la técnica de “Estructura electrónica sencilla con ensayos automáticos y supervisión”. No obstante se debe verificar si la misma es recomendada para el nivel de seguridad adoptado.
El método de seguridad intrínseca inherente se aplica sobre algunos de los componentes, como por ejemplo: Transformadores, Transductores, Circuitos integrados, etc. Pudiendo aplicarse seguridad intrínseca compuesta en los sensores o actuadores si así se lo considera necesario en el proceso de diseño (Ejemplo: colocar dos sensores para determinar el estado de barrera rota).
En la sección 4, "Demostración de funcionamiento correcto bajo influencias externas" se deben considerar las influencias externas entre ellas las siguientes: Tensión eléctrica de red, vandalismo y ambientales (rayo-inundaciones-temperatura- insectos-acumulación de suciedad). Se deberá especificar el ámbito de competencia del producto ante este tipo de incidentes y la forma de mitigarlos.
En la sección 5, "Especificar o hacer referencia a las reglas condiciones o restricciones que se deben observar" se deben especificar o hacer referencia a las reglas, restricciones y condiciones que se deben observar en la aplicación del sistema. Debe incluir las condiciones especificadas en la apertura del caso de seguridad.
En la sección 6 "Evidencia del éxito de los ensayos" se debe incluir evidencia de la finalización con éxito de los ensayos relacionados con la seguridad.
Parte 5: Referencias a Informes de seguridad
Se hará referencia a todos los documentos e informes de seguridad de los que depende el “Caso de Seguridad” (subsistemas o equipos de los que depende)
NOTA: En los procesos de recopilación de evidencias, no es necesario crear grandes tomos de documentación. Se recomienda incluir referencias precisas sobre los documentos y especificar claramente los conceptos y los planteamientos adoptados.
Parte 6: Conclusiones
Habiéndose documentado el caso de seguridad, corresponde emitir conclusiones y para ello se seguirá el proceso de la figura 8. Se incluirán conclusiones sobre el diseño, la implementación y finalmente se deberá dictaminar sobre la aprobación o no de la seguridad.
Análisis de las evidencias
Sobre las evidencias documentadas se procederá al análisis de las características técnicas del sistema / subsistema o producto.
Se verificarán los requisitos y nivel aceptable de seguridad, confiabilidad y otras cualidades de la seguridad.
Se realizarán tantos reportes de evidencias como sean necesarios. La numeración de las planillas será consecutiva iniciando en 001 para cada Caso de Seguridad.
Evaluación del diseño del Hardware
Se debe contar con una descripción general del diseño del sistema/subsistema/ equipo. Definición de las interfaces.
Para demostrar el cumplimiento de las especificaciones de los requisitos del sistema, se debe verificar como el diseño cumple con los requisitos funcionales operativos. Además se deben incluir principios y cálculo de diseño, especificaciones y resultados de los ensayos y validación, entre otros posibles.
Para demostrar el cumplimiento de las especificaciones de los requisitos de seguridad, se debe verificar como el diseño cumple con los requisitos funcionales de seguridad, y se deben incluir principios y cálculo de diseño, especificaciones y resultados de los ensayos y análisis de seguridad y resultados, entre otros posibles.
Evaluación del diseño del software
Se realizará una revisión de especificaciones del software. Las propiedades del software se podrán analizar utilizando la norma ISO 25010, a excepción de la seguridad.
El nivel de integridad en la seguridad del software se evaluará según los requisitos del capítulo 5 de la norma EN 50128 denominado “Niveles de integridad de la seguridad del software”
Evaluación de la implementación del hardware
Se debe describir la arquitectura del hardware y explicar cómo el sistema alcanza la integridad requerida por la especificación de requisitos y por cualquier norma aplicable, en lo concerniente a fiabilidad, disponibilidad, mantenibilidad y seguridad.
Se analizará el efecto de las averías, tanto individuales del sistema, de los componentes y de las averías múltiples. Se evaluará las medidas que se toman después de la detección de las averías.
La garantía de funcionamiento del hardware debe describir cómo el diseño alcanza los requisitos de fiabilidad, disponibilidad, mantenibilidad y seguridad, analizando los siguientes aspectos:
Evaluación de la implementación del software
El software debe poseer un Plan de Verificación que permita analizar, probar y verificar. Se verificarán las entradas y salidas, algoritmos y estructuras de datos.
El lenguaje escogido deberá satisfacer los requisitos de seguridad, según norma EN 50128.
Cada módulo deberá tener una especificación de ensayo y características que faciliten el mantenimiento.
Evaluación de las condiciones de aplicación relacionadas con la seguridad
Para el análisis de las condiciones de aplicación relacionadas con la seguridad, se tendrá en cuenta:
Dictamen del diseño
Una solución tiene por objetivo eliminar el Peligro. En caso de no existir una solución que sea posible, deberán adoptarse medidas mitigadoras de riesgo, reduciendo la probabilidad de que ocurra un accidente o incidente y reducir las consecuencias cuando ocurran. En general será necesario establecer un equilibrio entre seguridad operacional y capacidad operativa.
El dictamen deberá identificar los procedimientos y/o intervenciones a ser modificadas para la eliminación del Peligro o mitigación del riesgo asociado, identificar los bloques asociados al riesgo y estimar el impacto si una alternativa puede ser implementada.
Dictamen de la implementación
Dictamen de la seguridad. Conclusiones
Basado en los dictámenes particulares del diseño y la implementación, el equipo de trabajo elaborar un dictamen final sobre si se considera alcanzado el nivel de seguridad o no.