Flujo de trabajo ISO 26262 para aplicaciones de conducción autónoma con MATLAB: Pautas y prácticas recomendadas

El uso de Simulink^® y Stateflow^® para el desarrollo de software YO ASI^® 26262 está bien establecido para ECU de automóviles. Existe una tendencia creciente, particularmente en aplicaciones de conducción automatizada, hacia la implementación de diseños de software utilizando funciones de MATLAB^®, así como bloques de Simulink y gráficos de Stateflow. Este artículo ofrece las mejores prácticas para utilizar un flujo de trabajo centrado en MATLAB para verificar el cumplimiento de los estándares de software ISO 26262 [1]. Estas mejores prácticas complementan el flujo de trabajo de referencia ISO 26262 utilizando el diseño basado en modelos ilustrado en IEC Certification Kit.

Patrón de modelado recomendado

En este artículo, utilizamos un patrón de desarrollo de software en el que un modelo de Simulink incorpora un bloque MATLAB Function (Figura 1). El modelo de Simulink de capa superior incluye todos los ajustes de configuración para la generación de código. El bloque MATLAB Function llama a funciones de MATLAB externas.

Este patrón de modelado aprovecha todas las herramientas de verificación y validación disponibles para los modelos de Simulink y al mismo tiempo permite implementar la funcionalidad utilizando el lenguaje de MATLAB [2]. También aprovecha las amplias capacidades disponibles en MATLAB. Por ejemplo, el desarrollo de SAAC normalmente se implementa utilizando MATLAB porque la funcionalidad matemática compleja se puede expresar de una manera concisa y elegante.

Hay formas alternativas de utilizar MATLAB [3] en un entorno de desarrollo de productos de seguridad crítica, que no se mencionan en este artículo.

Flujo de trabajo de referencia de MATLAB ISO 26262: Visión general

Como se mencionó anteriormente, el flujo de trabajo descrito en este artículo se basa en el flujo de trabajo de referencia ISO 26262 en el IEC Certification Kit (Figura 2).

El flujo de trabajo basado en MATLAB incluye recomendaciones adicionales para las siguientes actividades de verificación y validación:

• Creación de requisitos y verificación de arquitectura
• Análisis estático de modelos
• Pruebas MIL y pruebas SIL o PIL consecutivas
• Análisis estático de código
• Documentación

Creación de requisitos y verificación de arquitectura

ISO 26262 requiere evidencia de que todos los requisitos se han implementado y probado. En el flujo de trabajo de referencia ISO 26262, las actividades de verificación de arquitectura y creación de requisitos resaltadas en la Figura 3 proporcionan esta evidencia.

Vincular requisitos al código de MATLAB

Con Requirements Toolbox™, puede vincular requisitos a líneas de código en funciones de MATLAB de la misma manera que vincula requisitos a bloques de Simulink. La diferencia es que la verificación existente de requisitos ausentes no verifica el código de MATLAB externo. La recomendación es que implemente comprobaciones en Model Advisor que busque contenedores de MATLAB que no estén vinculados a un requisito. Un contenedor suele ser el archivo MATLAB externo o una función MATLAB, según el tamaño del archivo.

Análisis estático de modelos

Se debe verificar que cada componente del modelo de implementación sea legible, comprensible y comprobable (Figura 4). Simulink Check™ se utiliza para evaluar la conformidad del modelo con ISO 26262 y directrices de alta integridad de MathWorks.

Subconjunto de lenguajes

La programación en MATLAB puede implicar el uso de funciones de varias toolboxes diferentes. Dado que MATLAB es un lenguaje potente con un alto grado de abstracción, puede desarrollar funciones complicadas con unas pocas líneas de código. En algunos casos, una sola línea de código de MATLAB puede dar lugar a muchas líneas de código C, lo que dificulta la verificación total del código generado. Es importante determinar que la funcionalidad que se está implementando se puede probar. ISO 26262 estipula el uso de un subconjunto de lenguajes (Tabla 1 en ISO 26262) según el tipo de funciones que esté utilizando.

Recomendamos que siga los siguientes pasos para cumplir con el requisito de subconjunto de lenguajes:

• Evalúe las funciones de MATLAB utilizadas para garantizar que ninguna de ellas requiera un gran esfuerzo de verificación. Model Advisor se puede utilizar para identificar el uso de funciones no recomendadas debido a la complejidad del código.
• Reemplace funciones de MATLAB no recomendadas con implementaciones más simples. Estas funciones más simples serán más fáciles de monitorear y probar.

Si las funciones no se pueden reemplazar, es necesario probarlas por separado.

• Verifique la función realizando pruebas unitarias separadas con alta cobertura. Cuando se haya logrado la cobertura, justifique el uso de estas funciones haciendo referencia a las pruebas unitarias externas.

Tipificación estricta de datos

ISO 26262 requiere que todas las variables estén estrictamente tipificadas. Model Advisor comprueba los modelos de Simulink en busca de bloques estrictamente tipificados, incluida la interfaz del bloque MATLAB Function, pero no se comprueban las funciones externas de MATLAB. Para superar este obstáculo, escriba una comprobación para verificar que todas las funciones de MATLAB estén estrictamente tipificadas. Es especialmente importante comprobar el tipo y la dimensión de los datos.

Pruebas MIL y pruebas SIL o PIL consecutivas

Las pruebas consecutivas (equivalencia) permiten demostrar que el código generado se comporta de la misma manera que el modelo, según lo recomendado en la Tabla 7 de ISO 26262, Métodos para la verificación de unidades de software. Para el código objeto, utilice pruebas de procesador en bucle (PIL) y para el código C generado, utilice software en bucle (SIL) (Figura 5). Los casos de prueba deben ser los mismos que los utilizados en las pruebas de modelo en bucle (MIL). Para la verificación de la unidad, utilice SIL. Para las pruebas de integración, se recomienda ejecutarlas también en el hardware objetivo para verificar toda la cadena de herramientas de desarrollo.

Prevención de funcionalidad no deseada

Para demostrar que no se agregó ninguna funcionalidad no deseada durante la generación de código, mida la cobertura de la prueba durante las pruebas del modelo y del código. La cobertura de las pruebas generalmente se realiza mediante pruebas consecutivas con Simulink Coverage™. La cobertura se utiliza, según ISO 26262, para evaluar la integridad de la verificación y proporcionar evidencia de que se logran los objetivos de las pruebas unitarias.

Según ISO 26262, el código con déficit de cobertura debe revisarse y justificarse. Cuando se desarrolla utilizando bloques de Simulink, las justificaciones se pueden conectar al modelo, lo que significa que se mantienen entre ejecuciones de verificación. Esta opción no está disponible para funciones externas de MATLAB. Para justificar la falta de cobertura para una función de MATLAB, agregue un filtro de cobertura al código y luego conéctelo al arnés de prueba o al archivo de prueba en Simulink Test™. Nuestra recomendación es conectar el archivo de filtro de cobertura al archivo de prueba (Figura 6).

Análisis estático de código

Como se establece en el estándar ISO 26262, los análisis estáticos incluyen actividades de búsqueda en el modelo o texto del código fuente de patrones que coincidan con fallas conocidas o el cumplimiento de pautas de modelado o codificación. Los análisis estáticos de código se realizan en el código generado (Figura 7).

Cumplimiento de MISRA C

Para evaluar el cumplimiento con MISRA^® C para el código generado desde MATLAB, utilice una herramienta de análisis estático de código como Polyspace Bug Finder™ para detectar código que no sea compatible con MISRA C e investigue los resultados manualmente. Si el código no compatible proviene de una función incorporada de MATLAB, tiene dos opciones:

• Reemplace la función incorporada de MATLAB con una función reescrita
• Escriba una justificación para la advertencia de MISRA C

Nuestra recomendación es reemplazar la función, si es posible. Para garantizar que la función reemplazada no sea utilizada por otros desarrolladores, implemente una comprobación de Model Advisor para funciones no recomendadas.

Documentación

En el caso de seguridad final que proporciona evidencia de conformidad con la norma ISO 26262, es necesario documentar cada paso del proceso de verificación, desde los requisitos hasta la verificación. La documentación debe incluir descripciones de diseño de la funcionalidad. La Figura 8 destaca algunas de las actividades que deben incluirse en la descripción del diseño.

Descripción del diseño del sistema

Simulink Report Generator™ incluye una plantilla de informe de diseño del sistema predefinida. Esta plantilla suele ser adecuada para documentar un componente desarrollado en Simulink, pero no para documentar funciones externas de MATLAB porque no están incluidas en la descripción de diseño del sistema predeterminada. Por lo tanto, recomendamos personalizar la plantilla para incluir el código de MATLAB externo.

Consideraciones sobre SOTIF

En sistemas complejos como SAAC, una función puede comportarse según lo previsto pero aun así provocar un comportamiento peligroso. Bajo la guía del estándar de seguridad de la funcionalidad prevista (SOTIF) ISO 21448, puede abordar este problema integrando actividades adicionales de verificación y validación en el diseño basado en modelos. Recomendamos agregar pruebas de condiciones de operación aleatorias para ampliar las pruebas e incluir casos de uso desconocidos. Estas pruebas aleatorias deberían verificar el comportamiento del modelo de implementación y el código objeto integrado en comparación con los requisitos del sistema.

El IEC Certification Kit incluye soporte para SOTIF. En cuanto a SOTIF, no existen grandes diferencias entre los flujos de trabajo de Simulink y MATLAB. El IEC Certification Kit actualizado incluye información sobre el uso de Automated Driving Toolbox™ para pruebas del sistema.

Resumen