Objetivo de la validación
La validación de una biblioteca de software es crítica porque el código de la biblioteca está vinculado a la aplicación e instalado en el dispositivo de destino. Si un componente de la biblioteca es defectuoso, la seguridad funcional de toda la aplicación se verá comprometida.
Cada estándar de seguridad funcional tiene sus propios objetivos concretos por lo que se refiere al uso de bibliotecas de software, pero en general todos ellos comparten una meta común: verificar que la implementación de la biblioteca se ajusta a su especificación. ISO 26262 ofrece dos vías para validar la biblioteca, detalladas por separado en ISO 26262 Parte 8 e ISO 26262 Parte 6. SuperGuard C Library Safety Qualification Suite se puede utilizar en ambos casos.
ISO 26262 Parte 8, Cláusula 12: validación de los componentes de software
Para su clasificación como productos COTS (commercial off-the-shelf), las bibliotecas quedan cubiertas por la Parte 8, Cláusula 12: “Validación de los componentes de software”. Esta cláusula aborda la necesidad de validar los componentes de software existentes, como las bibliotecas, “con el fin de demostrar que son idóneas para su reutilización”. Menciona en concreto las “bibliotecas de software suministradas por terceros”, que claramente incluyen las bibliotecas estándar suministradas con SDK comerciales. La cláusula también se aplica al software interno reutilizado y al software de código abierto.
La Parte 8, Cláusula 12, establece que un requisito previo para la validación es una exposición de los requisitos del componente de software. También sugiere que la prueba de que un componente de software cumple estos requisitos debería “tomar como referencia principalmente pruebas basadas en los requisitos”, lo cual se puede llevar a cabo por medio de la “aplicación de un paquete de prueba de validación especializado” que debería “abarcar tanto las condiciones normales de funcionamiento como la respuesta si se produce un fallo” y no debería “mostrar errores que pudieran llevar a incumplir los requisitos de seguridad”.
Afortunadamente, la especificación de la biblioteca para los lenguajes C y C++ existe y es accesible para el público, por lo que ya hay un punto de partida para una comprobación rigurosa basada en los requisitos. De hecho, la existencia y la capacidad de prueba tanto del lenguaje como de la especificación de la biblioteca constituyen una de las razones por las que los lenguajes de programación C y C++ están tan extendidos en la comunidad de desarrolladores. Ahora bien, la especificación del lenguaje no está escrita como una lista de requisitos. Una característica clave del paquete de prueba SuperGuard de Solid Sands es que todas sus pruebas de la biblioteca se basan firmemente en los requisitos derivados de la definición del lenguaje ISO C.
Para cumplir el requisito de que el paquete de prueba cubra tanto condiciones normales como de fallo, debería poner en práctica cada función tanto dentro de sus condiciones límite como fuera de ellas, y verificar el manejo de errores de la función. Entre los requisitos derivados de la especificación ISO C para crear SuperGuard se encuentran la verificación de la respuesta exigida ante fallos según lo definido en la especificación.
La prueba fiable de la inexistencia de errores que pueda provocar el incumplimiento de los requisitos de seguridad no solo depende de unas pruebas efectivas basadas en requisitos sino también en la cobertura estructural del código para ASIL D (Automotive Safety Integrity Level D), el máximo nivel de integridad para aplicaciones del automóvil. Para garantizar la demostración de su integridad, SuperGuard proporciona una elevada cobertura de código estructural y una alta MC/DC (Modified Condition/Decision Coverage).
SuperGuard también incorpora análisis y comprobación de clases de equivalencia y valores límite, así como estimación de errores dependiendo de los mejores conocimientos disponibles y de la experiencia de la respuesta a una función de la biblioteca.
