La complejidad de los sistemas de control mediante SW en dominios tan exigentes como automoción, aeronáutica y ferroviario está creciendo de forma rápida en las últimas décadas. Además, el coste de desarrollo y su homologación/certificación tiene que tender a bajar para que los sistemas sean competitivos en el mercado. Actualmente, los costes (dinero y tiempo) de certificación son muy elevados. Los costes de certificación no son únicamente los relacionados con el propio desarrollo del sistema sino el alto coste que supone seguir la norma respecto a la correcta documentación, la creación de artefactos requeridos por la norma y la propia gestión del proyecto. En estos ámbitos en los que los sistemas tienen que tener un nivel de fiabilidad/integridad elevado, las técnicas y procesos utilizados a la hora de desarrollar los sistemas han sido hasta ahora los tradicionales y el cambiar las técnicas de desarrollo e innovar en todo el proceso requiere un esfuerzo importante. Estos últimos años, se habla cada vez más sobre la reusabilidad de componentes SW/HW para poder alcanzar los costes y tiempos objetivo. Cada vez están cogiendo más importancia las técnicas de diseño y desarrollo de sistemas SW basados en Modelos y el desarrollo basado en Componentes que hasta hace poco no eran nada habituales en estos dominios tan críticos.
Para realizar el estudio, se han tenido en cuenta los estándares de los dominios ferroviario (CENELEC 5012x), el de automoción (ISO 26262) y también la norma genérica IEC 61508. Se han elegido estas normas porque tienen unas características interesantes y diferentes: la IEC 61508 porque es la genérica y se considera como la base del resto de normas. Las normas del sector ferroviario, se han elegido porque es un sector que se basa en la norma IEC 61508 pero tiene sus propias características del sector, además de ser un sector con gran trayectoria respecto a sistemas críticos de seguridad (safety). De esta forma, se detectan diferencias/características del dominio que la norma genérica no contempla. Por último, se ha elegido la norma de automoción ISO 26262 ya que es una norma nueva y pionera.
De forma resumida se presentarán los resultados de dicho estudio:
1) Reusabilidad del Safety Case
Para que un sistema crítico pueda ser comercializado y utilizado en equipos cuyo funcionamiento afecta directamente a personas o pueda dañar de forma considerable el entorno, tiene que pasar ciertos trámites hasta que una entidad de certificación homologada lo certifica. Diferentes dominios, tienen sus peculiaridades a la hora de presentar la documentación para lograr la certificación pero dos de los que se han considerado en este estudio (ISO26262 y CENELEC 5012x) y otras (ej. nuclear, aeroespacial) coinciden en que todo el ciclo de vida del sistema se tiene que recoger en un “Safety Case” (SC). Dicha documentación será la clave para la obtención de la certificación y el realizarlo es un trabajo costoso. Por lo tanto, el cómo gestionar y realizar el SC es un punto importante a considerar a la hora de desarrollar sistemas con un alto nivel de integridad.
Timothy Patrick Kelly, es un investigador referente en la materia y define el Safety Case como:
“A Safety Case should communicate a clear, comprehensive and defensible argument that a system is acceptably safe to operate in a particular context”
A la hora de plantear la reusabilidad de componentes SW como ahorro en tiempo y costes, una de las alternativas a considerar es sin duda la reusabilidad de los SC: cómo aprovechar la documentación/artefactos en diferentes proyectos. En cierta medida, por ejemplo CENELEC 50129 ya ha tenido en cuenta la reusabilidad al plantear la Parte 5 del SC y al considerar los tres tipos de SC: GPSC, GASC y SASC.
En la línea de cómo agilizar el proceso del SC, se lleva años investigando y ya hay resultados que se están aplicando en la industria. El profesor Tim Kelly de la Universidad de York es uno de los investigadores que ha trabajado en este aspecto y pionero en proponer nuevas técnicas y notaciones a la hora de elaborar el SC. Así, en el año 1998 ya presentó su tesis doctoral titulada “Arguing Safety- A Systematic Approach to Managing Safety Cases”. En ella, lo que propone y resuelve es lo siguiente: proporciona un método y una notación gráfica para presentar los argumentos “Safety” de un sistema crítico. La tesis demuestra cómo utilizando este enfoque, la elaboración del safety case resulta menos costosa y soporta el desarrollo, mantenimiento y la reusabilidad de los argumentos safety. Estos resultados son referencia en la norma ISO26262.
Kelly propone el uso de la notación GSN (Goal Structured Notation) para la elaboración de los Safety Case. Mediante esta notación pretende unir de forma simple y gráfica los objetivos y requisitos del sistema con las evidencias utilizando para ello los argumentos.
2) PROVEN in USE
El concepto “Proven in Use / Probado en Uso” (PU) (Componente que presenta un nivel de confianza alto debido a su uso anterior en otro(s) sistema(s)) es un concepto que se tiene en cuenta en los diferentes estándares o normativas.
Cada una de las normativas consideradas, proponen restricciones a la hora de aplicar dicho concepto, pero todas señalan cuestiones como el cambio de contexto o medio en el que se va a utilizar el componente ya que esto puede llevar a que el componente no se comporte como anteriormente lo hizo pudiendo crear situaciones catastróficas ej. Ariane 5 Flight 501.
3) SEooC(Safety Element Out Of Context) y CROSS ACCEPTANCE
El término SEooC es un término que viene definido en la norma ISO26262. Su definición es la siguiente:
“A SEooC is a safety-related element which is not developed for a specific item”
Características:
- Los requisitos de alto nivel permanecen en estado de “asumido/supuesto” y se confirman cuando el SEooC se va a utilizar en un sistema/ítem/vehículo concreto.
- La implementación correcta de ese requisito en estado “asumido” será verificado durante el desarrollo del SEooC, pero la validación tendrá lugar cuando se desarrolle el sistema/ítem/vehículo donde se aloje el SEooC.
- Los requisitos no funcionales pueden estar en el estado “asumido” mientras que al mismo nivel, los requisitos funcionales se encuentran en estado de “aceptadas”.
Todo esto quiere decir que los componentes genéricos (subsistemas, componentes HW, componentes SW) para los cuales en su fase de desarrollo no tenemos definidas ninguna aplicación concreta, ni objetivos de seguridad concretos pueden ser desarrollados según la norma ISO26262 como SEooC. Como en este caso los requisitos de seguridad (safety) no son conocidos, se tendrán que definir y documentar todos los supuestos de acuerdo con la norma.
Aunque en la normativa del dominio ferroviario no se habla directamente de este término, si definen otro término relacionado llamado “Cross Acceptance”: es un aspecto del proceso técnico y legal principalmente con el objetivo de establecer el camino más rápido para llegar al despliegue de productos, sistemas o procesos en un nuevo contexto. El subapartado 9.9 de 50126-2 proporciona una breve introducción sobre el “Cross Acceptance”. Se puede encontrar información más detallada y guías en PD CLC/TR 50506-1:2007 ‘Railway applications. Communications, signalling and processing systems. Application guide for EN 50129. Cross-acceptance’.
Un producto, sistema o proceso considerado para “Cross Acceptance” generalmente se supone que satisface la calificación de fiabilidad, tolerancia de seguridad (safety) y eficiencia de operación en su entorno original. Normalmente se aplica en productos genéricos o aplicaciones genéricas. Para aceptar en una aplicación específica, se tiene que cumplir que el nuevo entorno y aplicación son idénticos a la original.
4) Nueva Norma Reusabilidad : IEC/ PAS 62814
La nueva norma que trata sobre la Reusabilidad de Sistemas Críticos, IEC/PAS 62814 (Dependability of software products containing reusable components – Guidance for functionality and tests), en realidad es una guía considerada como pre estándar.
Promueve el desarrollo basado en la reusabilidad y está enfocado en requisitos, funcionalidades y tests de productos software que tienen componentes software reusables independientes de dominio (conocidos como componentes de Cross-Domain). Una contribución interesante de esta prenorma es quedefinen dos aspectos de la reutilización de componentes:
- “Build-for-reuse” (producción planificada de componentes reusables
- “Build-by-reuse” (producción planificada de sistemas utilizando componentes reutilizables)
