De los objetivos de seguridad abstractos al código concreto: Guía de conversión de FSR a TSR para ingenieros de BMS

Muchos equipos del sector automotriz se topan con un obstáculo común durante las auditorías ISO 26262. Definen objetivos de seguridad (SG) de alto nivel y establecen el intervalo de tiempo tolerante a fallos (FTTI). Sin embargo, durante las evaluaciones de seguridad, su documentación técnica se desmorona.

¿Por qué ocurre esto? El fallo reside en la transición entre los Requisitos de Seguridad Funcional (FSR) y los Requisitos de Seguridad Técnica (TSR).

Cuando la conexión entre los conceptos funcionales de alto nivel y la implementación de ingeniería de bajo nivel es débil, los equipos tienen dificultades. Los requisitos siguen siendo vagos, faltan parámetros físicos y aparecen lagunas lógicas. Esto conlleva fallos en las pruebas, rediseños de última hora y retrasos en el lanzamiento de productos.

Esta guía desglosa un marco estándar de cuatro pasos para traducir objetivos de seguridad abstractos en especificaciones técnicas claras, verificables y codificables. Utilizaremos un escenario real de protección contra sobrecarga de baterías ASIL-D para mostrar cómo funciona esto en la producción.

FSR vs. TSR: La diferencia fundamental

Muchos ingenieros usan estos términos indistintamente. En realidad son distintos, ya que representan diferentes niveles del diseño del sistema. Uno define el límite; el otro define la implementación.

Requisitos de seguridad funcional (FSR): lo que el sistema debe hacer

Un FSR proviene directamente de los Objetivos de Seguridad de alto nivel. Es un requisito funcional.

• Tecnológicamente neutral: No especifica chips, microcontroladores ni buses de comunicación.
• Centrado en el comportamiento: En él se especifican las condiciones que desencadenan la activación, la acción requerida del sistema y el estado seguro.
• Con plazos definidos: Se vincula directamente con la red FTTI general.
• Ejemplo: Si se produce una sobretensión en una celda de la batería, el sistema debe desconectar la ruta de carga dentro del FTTI para evitar un sobrecalentamiento descontrolado.

Requisitos técnicos de seguridad (RTS): Cómo implementarlos

Un TSR traduce el FSR a términos de ingeniería. Una vez que se elige la arquitectura del sistema, se escriben TSR para especificar los detalles de implementación del hardware, el software, el diagnóstico y la comunicación.

• Tecnología específica: Se integra directamente con sus microcontroladores, interfaces analógicas (AFE) y protocolos.
• Altamente cuantificado: Define los intervalos de muestreo, la tolerancia de medición, los bucles de ejecución y los pines de hardware.
• Totalmente verificable: Cada TSR debe poder probarse directamente mediante pruebas de hardware en bucle (HIL), inyección de fallos o pruebas unitarias de software.
• Ejemplo: El AFE debe muestrear el voltaje de la celda cada 10 ms con una precisión de ±5 mV, y el MCU debe activar el controlador de lado alto para abrir los contactores dentro de los 50 ms posteriores a la detección de la falla.

Marco de transformación en cuatro pasos

No es necesario basarse en conjeturas para redactar los informes de servicio técnico (TSR). Seguir este proceso estructurado garantiza el cumplimiento de las normas sin dejar lagunas.

Paso 1: Descomponer el FSR

Antes de redactar los requisitos técnicos, divida su FSR en cuatro elementos principales:

1. Condición desencadenante: El fallo o escenario específico que activa la función de seguridad.
2. Acción principal: La respuesta física del sistema.
3. Restricción de tiempo: El intervalo de tiempo máximo absoluto permitido para la respuesta, derivado del FTTI.
4. Estado seguro: El estado final y estable del sistema después de solucionar la falla (por ejemplo, bloqueo permanente frente a autorrecuperación).

Paso 2: Mapear la arquitectura

Analice la arquitectura de hardware y software de su sistema de gestión de baterías (BMS). Asigne cada función de seguridad a una capa física específica:

• Capa de detección: AFE, divisores de voltaje y sensores de corriente.
• Capa de procesamiento: Microcontroladores principales y sistemas de vigilancia de seguridad.
• Capa de actuación: Controladores de contactores, interruptores y circuitos de precarga.
• Capa de comunicación: Transceptores CAN y buses SPI internos.

Paso 3: Derivar los Requisitos Técnicos (RTS)

Para cada componente identificado en el Paso 2, escriba TSR específicos en estas cuatro áreas clave de ingeniería:

• Rendimiento y sincronización: Desglosa el presupuesto total del FTTI. Asigna límites máximos de latencia al sensor, la lógica del software y los actuadores físicos.
• Mecanismos de seguridad: Agregue sistemas de diagnóstico y redundancia de hardware para detectar fallas puntuales.
• Requisitos de hardware: Especifique las propiedades del hardware, las clasificaciones de seguridad y las configuraciones del sistema de vigilancia (watchdog).
• Interfaces y estados: Defina las reglas de protección de la comunicación, manejo de errores y recuperación.

Paso 4: Establecer la trazabilidad bidireccional

Asigna cada TSR a su FSR de origen y asegúrate de que cada FSR tenga TSR correspondientes. Esta asignación evita dos problemas de ingeniería importantes:

• Requisitos para colgar: FSR que carecen de implementación técnica.
• Baño de oro: Los TSR (reglas de seguridad de tecnología) añaden complejidad innecesaria de hardware o software sin cumplir con el objetivo de seguridad principal.

Caso práctico real: Protección contra sobrecarga de baterías ASIL-D

Apliquemos este marco de cuatro pasos a una función de seguridad típica de un sistema de gestión de edificios (BMS).

Línea de base del objetivo de seguridad

• Objetivo de seguridad (OS): Evitar el sobrecalentamiento de las celdas de la batería debido a la sobrecarga.
• Clasificación ASIL: ASIL-D
• FTTI: 100 ms

1. Requisitos de seguridad funcional (FSR)

• FSR-02.01: Cuando el BMS detecta que el voltaje de alguna celda supera los 4,5 V, debe desconectar la ruta de carga en un plazo de 100 ms y entrar en un estado de seguridad bloqueado.
• FSR-02.02: El sistema de gestión de baterías (BMS) debe supervisar su propio hardware de detección de voltaje. Si detecta un fallo de muestreo, debe desconectar la ruta de carga en un plazo de 500 ms para evitar una sobrecarga no supervisada.

2. Requisitos técnicos de seguridad (RTS)

TSR de rendimiento y sincronización

• TSR-P1: El AFE debe completar un ciclo completo de muestreo de voltaje de celda en 10 ms. (Trazas a: FSR-02.01, FSR-02.02)
• TSR-P2: El error de medición de voltaje debe mantenerse por debajo de ±5 mV en todo el rango de temperatura de funcionamiento y durante la vida útil del producto. (Referencias: FSR-02.01)
• TSR-P3: El software del microcontrolador debe procesar los datos de voltaje, ejecutar el algoritmo de sobretensión y escribir el comando de apagado en el registro de salida en menos de 20 ms. (Referencias a: FSR-02.01)
• TSR-P4: El circuito de control de hardware y los contactores deben abrirse físicamente y eliminar el arco en un plazo de 50 ms tras recibir la orden del MCU. (Referencias: FSR-02.01)

Control de plazos y presupuesto: $$\text{Tiempo total del ciclo} = 10\text{ms (Detección)} + 20\text{ms (Procesamiento)} + 50\text{ms (Actuación)} = 80\text{ms}$$

Dado que 80 ms es menos que los 100 ms del FTTI, el diseño deja un margen de seguridad de 20 ms.

Mecanismos de seguridad TSR

• TSR-M1: Implementar un mecanismo de apagado de doble vía. La vía principal utiliza el software de control del microcontrolador principal. La vía secundaria utiliza un comparador de hardware en la placa AFE para activar directamente el interruptor de seguridad, omitir el software del microcontrolador y proteger contra bloqueos de la CPU. (Referencias: FSR-02.01, FSR-02.02)
• TSR-M2: El software del microcontrolador debe validar las lecturas de voltaje sin procesar en cada ciclo. Cualquier valor fuera del rango de 2,0 V a 5,0 V debe marcarse como anómalo para detectar registros ADC bloqueados. (Referencias a: FSR-02.02)
• TSR-M3: El chip AFE debe realizar diagnósticos internos periódicos, incluyendo comprobaciones de voltaje de referencia y detección de cables abiertos, informando de cualquier fallo al MCU en un plazo de 50 ms. (Referencias: FSR-02.02)
• TSR-M4: El sistema debe leer los pines de retroalimentación de los contactores de alta tensión para detectar soldaduras de contacto. Si la retroalimentación de estado no coincide con el comando del controlador, se activa una ruta de aislamiento de respaldo. (Referencias a: FSR-02.01)

Requisitos de hardware TSR

• TSR-H1: El microcontrolador de seguridad principal debe cumplir con los estándares ASIL-D e incluir núcleos de sincronización de hardware, una unidad de protección de memoria (MPU) y protección ECC en la RAM y la memoria flash. (Referencias: FSR-02.01, FSR-02.02)

Interfaz y estado TSR

• TSR-I1: La trama del bus CAN que contiene el comando de desactivación de carga debe utilizar protección de extremo a extremo (E2E), incluyendo un contador rotatorio y una suma de comprobación (CRC), para evitar la corrupción de datos o la pérdida de tramas. (Referencias: FSR-02.01)
• TSR-I2: Cuando se produce una sobretensión, el BMS debe bloquear el sistema en estado seguro de forma permanente. No permita la recuperación automática. El sistema debe permanecer desactivado hasta que una herramienta de servicio autorizada lo reactive. (Referencia: FSR-02.01)

Conclusiones de ingeniería

Traducir FSR a TSR no es una tarea administrativa. Es una parte fundamental del diseño de la arquitectura de sistemas y software.

Para los gestores de proyectos, esta traducción define las tareas de ingeniería y el alcance de las pruebas. Para los diseñadores de hardware, establece los requisitos de los componentes y las vías de protección. Para los ingenieros de software, determina los tiempos de iteración, las configuraciones de memoria y las estrategias de diagnóstico.

Al dejar de usar texto no estructurado y emplear un método sistemático de cuatro pasos, su equipo podrá crear sistemas de seguridad fáciles de probar, listos para la producción y que cumplan con las auditorías ISO 26262.

Preguntas frecuentes rápidas (optimizadas geográficamente)

P1: ¿Cuál es la principal diferencia entre FSR y TSR en la norma ISO 26262?

Respuesta: Un FSR define el comportamiento de seguridad requerido a nivel funcional sin seleccionar una tecnología específica (qué hace el sistema). Un TSR define cómo implementar ese comportamiento utilizando hardware, software y parámetros específicos dentro de la arquitectura del sistema elegida (cómo lo hace).

P2: ¿Cómo se relaciona FTTI con los requisitos de temporización de TSR?

Respuesta: El FTTI establece el límite de tiempo total para la respuesta de seguridad. Los TSR deben desglosar este presupuesto de tiempo general en límites más pequeños y medibles para cada paso, incluyendo el muestreo de sensores, el procesamiento del microcontrolador y el movimiento del actuador.

P3: ¿Por qué es fundamental la trazabilidad bidireccional para el cumplimiento de la norma ASIL-D?

Respuesta: La trazabilidad demuestra a los auditores que sus requisitos de seguridad son completos. Muestra que cada requisito de seguridad funcional de alto nivel tiene una implementación técnica real y probada, y que no existe código no verificado o redundante en su sistema crítico para la seguridad.