Por Ann Keffer, Arun Gogineni y James Kim
Los automóviles que implementan funciones ADAS y AV dependen de complejos sistemas digitales y analógicos para realizar aplicaciones críticas en tiempo real. La gran cantidad de fallas que deben probarse en estos diseños automotrices modernos hace que realizar la verificación de seguridad utilizando una sola tecnología no sea práctico.
Sin embargo, desarrollar una metodología de seguridad optimizada con listas de fallas específicas enfocadas automáticamente para simulación, emulación y formalización es un desafío. Otro desafío es consolidar los resultados de resolución de fallas de varias ejecuciones de inyección de fallas para el cálculo métrico final.
La buena noticia es que la interoperabilidad de los motores de inyección de fallas, las técnicas de optimización y un flujo automatizado pueden reducir efectivamente el tiempo total de ejecución para cerrar rápidamente el ciclo desde el análisis de seguridad hasta la certificación de seguridad.
La Figura 1 muestra algunas de las técnicas de optimización en un flujo de seguridad. Se pueden implementar metodologías avanzadas, como análisis de seguridad para optimización y eliminación de fallas, simulación de fallas concurrentes, emulación de fallas y análisis formal para validar los requisitos de seguridad para un SoC automotriz.
Fig. 1: Culpa lista optimización técnicas.
Prueba de concepto: un SoC para automoción
Utilizando un caso de prueba a nivel de SoC, demostraremos cómo este flujo automatizado de múltiples motores maneja la gran cantidad de fallas que deben probarse en diseños automotrices avanzados. El diseño de SoC que utilizamos en este caso de prueba tenía aproximadamente tres millones de puertas. Primero, utilizamos motores de inyección de fallas tanto de simulación como de emulación para completar de manera eficiente las campañas de fallas para las métricas finales. Luego realizamos un análisis formal como parte del final de la inyección de fallas general.
Fig. 2: Automotriz SoC nivel superior bloquear diagrama.
La Figura 3 es una representación del bloque de islas de seguridad de la Figura 2. Las áreas codificadas por colores muestran dónde se utilizaron motores de simulación, emulación y formales para la inyección y clasificación de fallas.
Fig. 3: Hay una isla de seguridad bloquear diagrama.
La inyección de fallos mediante simulación consumía demasiado tiempo y recursos para el núcleo de la CPU y los bloques de memoria caché. Esos bloques estaban destinados a la inyección de fallas con un motor de emulación para lograr eficiencia. El núcleo de la CPU está protegido por una biblioteca de prueba de software (STL) y la memoria caché está protegida por ECC. La interfaz de bus requiere protección de extremo a extremo donde se determinó que la inyección de fallas con simulación es eficiente. La unidad de gestión de fallos no formó parte de este experimento. La inyección de fallas para la unidad de gestión de fallas se completará utilizando tecnología formal como siguiente paso.
La Tabla 1 muestra el recuento de registros de los bloques en la isla de seguridad.
Tabla 1: Recuento de registros de bloque.
Las listas de fallas generadas para cada uno de estos bloques se optimizaron para centrarse en los nodos críticos para la seguridad que tienen mecanismos/protección de seguridad.
Se ejecutó SafetyScope, una herramienta de análisis de seguridad, para crear las listas de fallas para los FM tanto para la aplicación Veloce Fault (emulador de fallas) como para el simulador de fallas y se escribieron las listas de fallas en la base de datos de seguridad funcional (FuSa).
Para los bloques de CPU y memoria caché, el emulador ingresa los bloques sintetizados y las redes de inyección/detección de fallas (FIN/FDN). A continuación, ejecutó el estímulo y capturó los estados de todas las FDN. Los estados se guardaron y utilizaron como referencia "dorada" para compararlos con ejecuciones de inyección fallidas. Para cada falla incluida en la lista de fallas optimizada, se emuló el comportamiento defectuoso y los FDN se compararon con los valores de referencia generados durante la ejecución dorada, y los resultados se clasificaron y actualizaron en la base de datos de fallas con atributos.
Fig. 4: Clúster de CPU. (Fuente en https://developer.arm.com/Processors/Cortex-R52)
Para cada una de las subpartes que se muestran en el diagrama de bloques, generamos una lista de fallas optimizada utilizando el motor de análisis. Las listas de fallos se guardan en sesiones individuales en la base de datos de FuSa. Utilizamos el muestreo aleatorio estadístico de las fallas generales para generar la muestra aleatoria a partir de la base de datos FuSa.
Ahora veamos lo que sucede cuando tomamos una muestra aleatoria durante todo el proceso de inyección de fallas usando la emulación. Sin embargo, para que esto cierre completamente la inyección de falla, procesamos N muestras.
Mesa 2: detectado fallas by la seguridad mecanismos.
La Tabla 3 muestra que la distribución general de fallas para el total de fallas está en línea con la distribución de fallas de las fallas muestreadas aleatoriamente. La tabla captura además el total de fallas detectadas de 3125 de un total de 4782 fallas. También pudimos modelar las fallas detectadas por subparte y proporcionar una proporción general de fallas detectadas del 65.35 %. Con base en las fallas en la muestra aleatoria y nuestra meta de cobertura del 90%, calculamos que el margen de error (MOE) es ±1.19%.
Mesa 3: Resultados de la inyección de fallas en CPU y memoria caché.
El total de 3125 fallas detectadas (observadas + no observadas) proporciona una clasificación de fallas clara. Los observados no detectados también proporcionan una clasificación clara de fallas residuales. Hicimos un análisis más detallado de fallas no detectadas, no observadas y no inyectadas.
Mesa 4: Culpa clasificación después de culpa inyección.
Utilizamos muchas técnicas de depuración para analizar las 616 fallas no detectadas y no observadas. Primero, utilizamos un análisis formal para verificar el cono de influencia (COI) de estas fallas UU. Las fallas que estaban fuera del COI se consideraron seguras y hubo cinco fallas que se eliminaron del análisis. Para las fallas que estaban dentro del COI, utilizamos juicio de ingeniería con justificación de varias configuraciones como ECC, temporizador, memoria flash relacionada, etc. Finalmente, usando juicio formal y de ingeniería pudimos clasificar aún más las fallas 616 UU en fallas seguras y restantes. Fallas UU en fallas conservadoramente residuales. También revisamos las 79 fallas residuales y pudimos clasificar 10 fallas en fallas seguras. Las fallas no inyectadas también se probaron con el modelo de simulación para verificar si algún estímulo adicional puede inyectar esas fallas. Dado que ningún estímulo fue capaz de inyectar estas fallas, decidimos eliminarlas de nuestra consideración y, en consecuencia, contra el margen de error. Con este cambio nuestro nuevo MOE es ±1.293%.
Paralelamente, el simulador de fallos extrajo las listas de fallos optimizadas para los modos de fallo del bloque de bus y ejecutó simulaciones de fallos utilizando estímulos de verificación funcional. El conjunto inicial de estímulos no proporcionó suficiente cobertura, por lo que se prepararon estímulos de mayor calidad (vectores de prueba) y se ejecutaron campañas de fallas adicionales con los nuevos estímulos. Todas las clasificaciones de fallas se escribieron en la base de datos FuSa. Todas las ejecuciones fueron paralelas y simultáneas para lograr eficiencia general y alto rendimiento.
El análisis de seguridad mediante SafetyScope ayudó a proporcionar más precisión y reducir la iteración de la simulación de fallas. La CPU y la memoria caché después de la emulación en varias pruebas dieron como resultado un SPFM general de más del 90 % como se muestra en la Tabla 5.
Mesa 5: En general resultados.
En este momento no se habían completado todas las pruebas para el bloque BUS (protección de extremo a extremo) que realizaban la simulación de falla. La Tabla 6 muestra que la primera prueba inicial pudo resolver el 9.8% de las fallas muy rápidamente.
Mesa 6: Porcentaje de fallos detectados para el bloque BUS por E2E SM.
Estamos integrando más pruebas que tienen mucho tráfico en el BUS para imitar el estado de funcionamiento en tiempo de ejecución del SoC. Los resultados de estas inyecciones de fallas independientes (simulación y emulación) se combinaron para calcular las métricas finales en los bloques anteriores, y los resultados se muestran en la Tabla 7.
Mesa 7: Postanálisis final de clasificación de fallas.
Conclusión
En este artículo, compartimos los detalles de una nueva metodología de seguridad funcional utilizada en un caso de prueba automotriz a nivel de SoC y mostramos cómo nuestra metodología produce un flujo de trabajo de seguridad escalable y eficiente utilizando técnicas de optimización para la inyección de fallas utilizando motores de verificación formal, de simulación y de emulación. . Realizar un análisis de seguridad antes de ejecutar la inyección de fallas fue muy crítico y ahorró tiempo. Por lo tanto, la interoperabilidad para utilizar múltiples motores y leer los resultados de una base de datos FuSa común es necesaria para un proyecto de esta escala.
Para obtener más información sobre este flujo de seguridad funcional altamente eficaz para diseños automotrices ADAS y AV, descargue el documento técnico de Siemens EDA. Los mecanismos de seguridad complejos requieren interoperabilidad y automatización para la validación y el cierre de métricas..
Arun Gogineni es director de ingeniería y arquitecto de seguridad funcional de circuitos integrados en Siemens EDA.
James Kim es líder técnico en Siemens EDA.
- Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
- PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
- PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
- PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
- PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
- Fuente: https://semiengineering.com/interoperability-and-automation-yield-a-scalable-and-efficient-safety-workflow/
