Si algo caracteriza al desarrollo de software crítico es su importancia y su dificultad. Hablamos de sistemas en los que un fallo o error en su funcionamiento puede implicar pérdida de vidas humanas, del propio equipamiento o daños importantes en el entorno. Estos sistemas son conocidos como safety-critical system (SCS) o life-critical system.
Safety-critical systems en aeronáutica.
Uno de los sectores donde este tipo de software es más relevante es el aeronáutico, aunque también es común en otros tipos de industria como la automoción, medicina, nuclear, etc.
Dadas las implicaciones que podría tener un malfuncionamiento del software en un avión, éste se debe desarrollar con especial cuidado, inspeccionando, documentando, testando y verificando adecuadamente el sistema. El objetivo es mejorar la calidad del software de sistemas críticos para minimizar la posibilidad de que pueda aparecer un error que potencialmente pueda tener graves consecuencias.
El documento de referencia que utilizan las principales autoridades (como la FFA y EASA) para asegurar la calidad del software que se instala en aviones es el DO-178C. Las autoridades de certificación requieren que se cumpla el nivel de criticidad que este estándar especifica de acuerdo con el Design Assurance Level. Estos niveles establecen el rigor necesario para cumplir con DO-178C.
Niveles de criticidad según el Design Assurance Level (DAL).
El nivel de criticidad del software, conocido también como el Design Assurance Level (DAL) o Item Developement Assurance Level (IDAL) se fija en función de criterios de seguridad y análisis de riesgos, teniendo en cuenta las posibles consecuencias en caso un fallo en el sistema. Por lo tanto, el DAL cumple la función de definir el nivel de exigencia que debe aplicarse a los diferentes componentes del sistema electrónico. A mayor gravedad en las consecuencias, más seguro debe ser el sistema.
Esta gravedad y por tanto sus exigencias de seguridad asociadas se jerarquizan en 5 niveles, principalmente en función de las posibles consecuencias que el fallo podría tener tanto para el aparato como para las personas a bordo:
- Nivel A – Catastrophic: un fallo en los componentes afectaría de forma importante a la operatividad del avión (vuelo y aterrizaje) y podría causar su destrucción y la pérdida de vidas. Por ejemplo: un fallo en los controles de vuelo.
- Nivel B – Hazardous: un fallo en estos sistemas supondría una gran amenaza para la vida de los ocupantes. Además, afectaría a la capacidad de control del personal del aparato debido a que tendrían que trabajar bajo un enorme estrés y/o con una gran carga de trabajo. Todo ello podría ocasionar heridas graves en el pasaje o incluso la muerte. Por ejemplo: un fallo en los sistemas de frenado del avión.
- Nivel C – Major: un fallo en este sistema reduciría el margen de seguridad, aumentando significativamente la carga de trabajo del personal para poder operar el avión. Esto podría hacer que se produzcan molestias en el pasaje, o incluso heridas leves. Es similar al nivel anterior, pero en menor magnitud. Por ejemplo: un fallo en los sistemas backup.
- Nivel D – Minor: las consecuencias del fallo tendrían un efecto mínimo, no causando más que una molestia entre el pasaje o el personal, que podría poner solución a la situación. Podría implicar un cambio en el plan de vuelo. Por ejemplo: un fallo en los sistemas de navegación terrestres.
- Nivel E – No effect: un fallo no tendría efecto en la seguridad, la capacidad de operación del aparato o la carga de trabajo del personal. Por ejemplo: un fallo en los sistemas de entretenimiento del avión.
Niveles de criticidad y tasas de fallo.
En equipos de hardware es posible cuantificar la seguridad de un ítem calculando su probabilidad de fallo para un periodo de tiempo dado. Este tipo de medida no se puede aplicar para software.
Por lo tanto, en lugar de especificar las probabilidades de fallo del software crítico se establece una tasa por hora de vuelo en consonancia al nivel de DAL (niveles A – E). Como se puede observar a continuación, a mayor nivel, mayor exigencia en esta tasa de fallo:
- Nivel A – Catastrophic: probabilidad menor de 1×10-9 por hora de vuelo.
- Nivel B – Hazardous: probabilidad menor de 1×10-7 por hora de vuelo.
- Nivel C – Major: probabilidad menor de 1×10-5 por hora de vuelo.
- Nivel D – Minor: sin métrica de seguridad.
- Nivel E – No effect: sin métrica de seguridad.
Importancia de la integridad de los sistemas Safety-Critical.
El objetivo final del desarrollo de software crítico es alcanzar un nivel de seguridad tal que la ejecución y comportamiento de todas las funciones del software sean como se espera durante el funcionamiento del avión. Como se ha comentado, esta tarea es compleja por lo que desde el punto de vista del desarrollo es importante conseguirla dentro de unos plazos y costes razonables.
Esta tarea puede volverse incluso más compleja cuando varios sistemas interactúan entre sí. Por eso es importante analizar previamente tanto las funciones del software crítico como de los potenciales riesgos para realizar el desarrollo teniendo toda esta información en cuenta. Una vez realizado este proceso, todas las causas de posibles fallos y sus consecuencias estarán identificadas, evaluadas y eliminadas o, al menos, reducidas a niveles de seguridad aceptables.
Otros métodos empleados para establecer niveles de criticidad.
El Safety Integrity Level.
El Safety Integrity Level (SIL) o Nivel de Integridad de Seguridad es un sistema similar que mide las prestaciones requeridas para ciertos niveles de seguridad. Por ejemplo, en los estándares de seguridad europeos se definen 4 SILs, siendo el nivel 4 el más severo y el 1 el más bajo.
El SIL se determina teniendo en cuenta el proceso de desarrollo, la gestión del ciclo de vida de la seguridad, el análisis de riesgos, etc. De modo similar al DO-178C para cada nivel SIL se exige una probabilidad de aparición del fallo, llamada Probability of dangerous failure per hour (PFH).
El Level of Rigor.
El Level of Rigor (LOR) es una especificación que también se usa para definir la profundidad necesaria en el análisis, testing y verificación del software. Cada nivel de LOR definirá una serie de tareas que deberán realizarse para asegurar los requerimientos de calidad. A mayor rigor, más minuciosas deberán ser esas tareas. El objetivo es lograr un nivel de confianza que asegure que las funciones del software que afectan a la seguridad funcionarán de acuerdo a lo esperado.
Los diferentes niveles (LOR-1, LOR-2, etc.) se fijarán teniendo en cuenta tanto el potencial impacto en caso de error como la responsabilidad del propio software dentro de la respuesta del sistema.
Centum: expertos en desarrollo de software y hardware crítico.
Desde CENTUM contamos con una experiencia de más de 15 años proporcionando servicios de diseño, desarrollo y certificación tanto de hardware como de software Embebido, Crítico o en Tiempo Real (DO-178B/C, DO-254, ABD-0100, ABD-200, ARP4754, ARP4761). Contamos con nuestro propio laboratorio de software que funciona bajo un paradigma muy simple: el error no es una opción. Si necesita más información póngase en contacto con nosotros.
