Metodología estructural, escalable y flexible para la aplicación de mecanismos digitales de seguridad en sistemas críticos de seguridad funcional

Autor: Trifon Trifonov

Este artículo revisa una metodología unificada para aplicar mecanismos de seguridad (SM) en el diseño digital. La categorización de la lógica digital se ha realizado desde el diseño y la perspectiva de la Seguridad Funcional (FuSa). Se proponen diferentes SM para máquinas de estados finitos (FSM), lógica combinatoria y lógica secuencial de acuerdo con las recomendaciones de ISO26262. Se muestran fragmentos RTL de muestra para todos los SM en SystemVerilog (SV), pero los esquemas propuestos también se pueden implementar en VHDL. Se ha realizado un análisis comparativo basado en los resultados de la síntesis, mostrando el impacto en el área del chip con diferentes opciones de implementación. La metodología propuesta ha sido aplicada con éxito en varios productos automotrices comerciales.

Introducción

Los sistemas de control electrónico (ECS) integrados en los vehículos actuales están creciendo en escala y complejidad. Incluso considerando la fiabilidad que brindan las modernas tecnologías de semiconductores, la probabilidad de que ocurra un error en cualquiera de los sistemas electrónicos del vehículo se asume alta. Dependiendo del sistema en el que suceda el fallo, la vida del conductor o del pasajero podría estar en peligro. Para evaluar, evitar y mitigar este riesgo, la industria del automovil ha desarrollado el estándar FuSa eléctrico/electrónico (E/E) IEC 61508 y ha creado un estándar FuSa automotriz específico: ISO26262 [1][2][3][4][5]. Como resultado, se introdujo el Nivel de integridad de seguridad automotriz (ASIL) [1] y se impusieron requisitos específicos a los nuevos productos, tanto para el ciclo de desarrollo como para las capacidades de diagnóstico con respecto a posibles fallos aleatorios. Para cuantificar esto último, se introdujeron diferentes métricas de hardware, ya que estas dependen del objetivo ASIL del producto.

Para las aplicaciones ASIL C y D, las métricas de falla de punto único (SPFM) requeridas son 97 % y 99 % respectivamente, ya que casi cualquier error podría llevar a la violación del objetivo de seguridad (SG), por lo que debe detectarse con una alta cobertura de diagnóstico. Cumplir con los estrictos requisitos de la métrica probabilística para errores aleatorios de hardware (PMHF) también podría ser un desafío para un sistema complejo en el que también se consideran fallos transitorios.

Además, para diseños de circuitos integrados complejos, es posible que los análisis del sistema [1][4] no estén completos y listos antes del inicio del diseño. Sin el resultado de estos análisis, los diseñadores de circuitos integrados pueden verse obstaculizados para implementar la lógica de detección de fallos adecuada cuando corresponda, hasta las últimas etapas del proyecto. En esos casos, la metodología propuesta debe aplicarse por completo en el diseño digital. Cuando se completan los análisis y se identifican todas las funciones relacionadas con FuSa, los SM que ya están implementados pueden revisarse, actualizarse o incluso eliminarse si un bloque en particular está cubierto por otro SM.

El enfoque más fácil y directo para detectar fallos en la lógica digital es usar la redundancia. Esto no se evalúa en el artículo actual debido a que es trivial de implementar, pero es bastante costoso en términos de área (la lógica se duplica o triplica y se requiere una lógica de comparación). Siempre que se utilice la redundancia como SM, los efectos de los fallos por causa común deben considerarse en el análisis de fallos dependientes [4] y gestionarse en el diseño.

El artículo actual se centra en los SM que se pueden aplicar en todas partes en todo tipo de diseño digital. La metodología propuesta se puede aplicar total o parcialmente en función del análisis de FuSa, así como de los requisitos técnicos/de seguridad del hardware. Las técnicas descritas se aplican durante la codificación RTL, por lo que son independientes de la tecnología.

Categorización del diseño digital

En general, la lógica digital se puede dividir en dos clases principales: secuencial y combinatoria. La categorización principal se amplía aún más en la metodología propuesta. La categoría adicional se refina para la lógica FSM:

• Lógica de estado/transición de FSM: lógica combinatoria y secuencial relacionada únicamente con FSM.
• Lógica secuencial común: todos los registros o pestillos que no están relacionados con la lógica FSM.
• Lógica combinatoria común: toda la lógica combinatoria que no está relacionada con FSM.

La categorización recientemente introducida es necesaria ya que se proponen diferentes SM que se pueden aplicar de forma independiente entre sí.

Desde la perspectiva de FuSa, la lógica digital se puede dividir en:

• Lógica funcional principal: los modos de fallo en esta lógica podrían conducir directamente a la violación del SG o, en otras palabras, tener el potencial de violar directamente el objetivo de seguridad (PVSG).
• Lógica de detección de fallos: los modos de fallo en esta lógica solo podrían violar indirectamente el SG (generalmente en combinación con una falla en la lógica funcional principal). Esta lógica implementa mecanismos de seguridad en sí misma u otra lógica que directamente no puede violar la SG (por ejemplo, DFT).

Técnicas de detección de averías

Detección de fallo de máquina de estado finito

Dependiendo de los requisitos de ASIL, podría ser necesario detectar fallos de hasta 3 bits y, en algunos casos, corregir fallos de hasta 2 bits. Los estados de los FSM están codificados con una distancia de Hamming (HD) de 2 o 3 bits que permite la detección de hasta uno o dos bits defectuosos. La esencia de los SM propuestos es utilizar valores de estado codificados correctamente y reutilizar el estado FSM predeterminado.

La HD requerida entre los estados se puede lograr con una codificación caliente/fría ampliamente conocida [7]. Estos códigos son bastante costosos por áreas: la cantidad de registros necesarios es igual a la cantidad de estados. Con el mismo propósito, la paridad y los códigos de corrección de errores (ECC) se emplean para los valores de enumeración del estado, ya que son más eficientes y económicos. El estado de error en el RTL es el estado predeterminado que captura el número requerido de fallas de bits. Si se detecta una transición incorrecta, el FSM permanece en estado de error hasta que se restablece. Las salidas críticas se ponen en estado «seguro/inactivo». Las opciones de implementación alternativas, junto con las capacidades de autocorrección, se presentan en [6].

El siguiente esquema se implementa utilizando la función SV, proporcionando códigos Hamming con una distancia de 3 bits para estados FSM de hasta 32, donde Dx es el bit respectivo del número de estado codificado en binario y Px representa la suma de comprobación de paridad resultante:

• Palabra de código = {D4, 0, D3, D2, D1, 0, D0, 0, 0}
• Código resultante (estado) = {D4, P8, D3, D2, D1, P4, D0, P2, P1}

La técnica propuesta no exige un estilo de codificación FSM particular si los valores del estado de enumeración tienen el HD mínimo requerido entre dos estados cualesquiera y el estado de error es el predeterminado donde se activa el indicador de error. Podría usarse con la mayoría de los estilos de codificación e implementaciones propuestas aquí [7]. Se recomienda registrar todas las salidas de FSM o asegurarse de que las salidas de FSM dependan únicamente del estado actual.

Tabla 1. Estados codificados HD de 3 bits

El siguiente diagrama muestra los resultados de utilización del área para diferentes códigos HD y el número de estados FSM. En algunos casos, la sobrecarga de área alcanza el 300% con respecto a la codificación de estado binaria típica para el mismo número de estados.

Detección de fallo lógico secuencial común

Todos los registros funcionales (registros de salida FSM, registros mapeados en memoria, contadores, etc.) deben poder detectar una cantidad de fallos según los requisitos de FuSa, es decir, capacidades de detección de fallos de un solo bit (por medio de la suma de verificación de paridad) y fallas de múltiples bits. Capacidades de detección (mediante verificación de redundancia cíclica (CRC) o suma de verificación ECC). El mecanismo sugerido proporciona un control continuo de los bits de suma de comprobación del valor siguiente (combinatorio) y del valor actual (secuencial). Las fallas pueden ocurrir en la lógica del siguiente estado y no se detectarán, lo que se espera ya que se usa para toda la lógica aguas abajo. Debido a la naturaleza transitoria de las fallas de inversión de bits y al hecho de que hay un enmascaramiento eléctrico y lógico de las señales, el efecto real podría mitigarse, por lo que es aceptable para las métricas de FuSa. Un diagrama generalizado se muestra a continuación:

Detección de fallo de lógica combinatoria común

Dependiendo de la variedad de funciones combinatorias, se pueden usar diferentes esquemas para detectar fallas. Se pueden distinguir los siguientes grupos principales:

• Sumadores / restadores y cualquier tipo de aritmética general
• Comparadores
• Multiplexores/codificadores/decodificadores

Se propone el siguiente enfoque. Los multiplexores se colocan frente a la lógica combinatoria que se va a comprobar. Se pasan los vectores de prueba designados y el resultado se compara con el valor esperado. Según las funciones implementadas y el vector de prueba seleccionado, se puede lograr la cobertura de diagnóstico objetivo. En algunos casos, es necesario aplicar más de un vector de prueba para lograr la cobertura requerida.

Esta técnica se puede aplicar a una lógica combinatoria que no se usa continuamente, es decir, no se usa en cada ciclo de reloj. Dado que este SM se ejecuta periódicamente, se debe considerar el intervalo de tiempo de detección de fallas (FDTI) [5] para el sistema.

Detección de fallos latentes

Otra categoría que debe tenerse en cuenta en los productos relacionados con FuSa, según el grado ASIL (típicamente ASIL-C y D), son las fallas latentes. Uno de los principales contribuyentes son los fallos que ocurren en la propia lógica de detección de fallos. Por lo general, el método para manejar estos fallos es probar los SM en el encendido, de forma periódica o continua. Para respaldar eso, se puede implementar una interfaz simple que inyecta un error en el algoritmo de cálculo de la suma de verificación. Los resultados se comprueban en las salidas de la lógica de interés. En todas las muestras de RTL subsiguientes, se aprovisiona y admite la detección de fallos de errores latentes.

Implementación en RTL

Derivado de los esquemas propuestos para la detección de fallas, la implementación de RTL debe cumplir con un conjunto de pautas de codificación. Se adopta la siguiente convención para cada bloque que puede violar directamente la SG: se agregan tres parámetros de nivel superior para SV a lo largo de la jerarquía del diseño. Cada uno de ellos maneja e instancia condicionalmente la lógica requerida para detectar fallas en:

• Lógica secuencial – SM_FF.
• Lógica FSM – SM_FSM.
• Lógica combinatoria – SM_COMB.

Los parámetros anteriores admiten el siguiente conjunto de valores: 0, 1, 2 y 3. Definen respectivamente «No SM implementado» y «HD de 2, 3 o 4 bits».

Generalmente, la detección de fallas de doble bit (2) es suficiente para la mayoría de los casos de aplicación. Los valores de los parámetros HD se pueden ampliar aún más si es necesario.

Generación de conjuntos de ENU

Para la generación adecuada de valores de enumeración de los estados FSM, se introduce el siguiente par de prototipos de funciones:

• F_GET_EST(int seq_num, lógica [1:0] SM_FSM);
• F_GET_FW(int total_st, lógica [1:0] SM_FSM).

Los fragmentos de código SV se muestran a continuación:

El enfoque propuesto se puede utilizar para la enumeración de estados de FSM incluso para bloques que no son relevantes para FuSa con SM_FSM establecido en cero.

Registro detección de avería

Para encapsular y separar la lógica de detección de fallas, se introduce un bloque dedicado que debe instanciarse condicionalmente en cada bloque crítico de seguridad. Desde el punto de vista estructural, las partes secuenciales y combinatorias de la lógica deben estar separadas, es decir, codificadas en diferentes bloques siempre en SV. La definición del puerto del bloque se muestra a continuación, así como la instancia condicional de muestra. Con este tipo de módulo, el diseñador puede agregar/eliminar nuevas señales según las necesidades del proyecto y cambiar la cobertura de diagnóstico en consecuencia.

Detección de fallos de lógica combinatoria

Hay un par de enfoques que se pueden implementar durante la implementación de RTL.

El primer enfoque es tener módulos autónomos para el comparador, el sumador y el multiplexor que implementan toda la lógica de prueba, los patrones y los vectores requeridos. Para cada uno de estos módulos, a nivel de instancia, el diseñador define el número de patrones, sus valores y la(s) señal(es) de control para habilitar/deshabilitar las funciones de diagnóstico. Como se muestra a continuación, todo el código relevante de FuSa relacionado con la comparación debe reemplazarse con una descripción estructural utilizando las instancias de los siguientes módulos.

El otro enfoque es tener una(s) unidad(es) de control centralizadas que tengan vectores de prueba predefinidos para diferentes grupos de lógica combinatoria. Este enfoque es rentable en términos de área, pero es menos flexible. Requiere ajuste de la lógica de detección según patrones existentes.

Resultados y conclusiones

• Utilización del área: la metodología permite una estimación lo suficientemente temprana del impacto relacionado con FuSa en términos de puertas lógicas. Los diseñadores pueden evaluar el impacto del área al usar diferentes sumas de verificación y métricas respectivas. Con estos números, es posible juzgar si el IC se ajustará al presupuesto proyectado o no, y tomar medidas correctivas.

• Actualizaciones de diseño: un enfoque uniforme para aplicar SM comunes puede simplificar las actualizaciones de diseño durante el desarrollo del proyecto. También acelera la fase de diseño, permite un seguimiento más sencillo y facilita las revisiones de diseño. Hacer cumplir la metodología unificada es escalable, estructural y útil, especialmente en proyectos a gran escala.
• Mitigación de riesgos: el uso de una biblioteca con bloques verificados, que implementan SM dedicados en todo el diseño, reduce el riesgo general del diseño, como la implementación incorrecta de funciones o la exposición a errores.
• Flexibilidad: el enfoque propuesto permite modificaciones triviales a la parte del diseño, incluso en las últimas etapas de diseño. Se puede mejorar y ampliar aún más para adaptarse a diferentes SM comunes para abordar una amplia variedad de necesidades de diseño. La metodología se puede combinar con técnicas aplicadas en las herramientas de flujo de diseño de back-end (síntesis, lugar y ruta) para una mejor cobertura de diagnóstico y métrica ASIL.