Garantizando temporización fiable en sistemas embebidos multicore críticos de seguridad

Vehículos y aeronaves modernos ya no dependen únicamente de componentes mecánicos. Su seguridad y rendimiento dependen de software embebido que corre en procesadores multicore heterogéneos complejos, gestionando todo desde control de vuelo a dirección asistida con deadlines de nivel microsegundo.

En un entorno multicore, el tiempo de ejecución de una tarea está influenciado no solo por su propio código sino también por otras tareas compartiendo los mismos recursos de hardware. Esta interferencia puede empujar un sistema más allá de sus márgenes de seguridad.

Desarrollar software embebido crítico de seguridad demanda un esfuerzo multi‑millón euro, multi‑año. Desde las etapas más tempranas de diseño, la seguridad debe estar arraigada en la arquitectura y el comportamiento de temporización de cada tarea debe entenderse rigurosamente para garantizar que se cumplan los deadlines.

Resolviendo el puzzle de análisis de temporización multicore

Mientras los procesadores multicore prometen mayor rendimiento, también introducen contención por recursos compartidos como buses, memoria, caches y aceleradores. Una tarea corriendo en un core puede ralentizar tareas en otros cores, creando variaciones de temporización impredecibles.

Preguntas clave surgen: ¿Cómo cuantificar el impacto de tal interferencia? ¿Cómo analizamos, testeamos y documentamos que software crítico de seguridad siempre terminará dentro de sus deadlines en una plataforma multicore?

Líderes de industria —Barcelona Supercomputing Center (BSC), Rapita Systems Ltd (RPT), Raytheon Technologies (RTRC) y Marelli Europe (MAR)— han pasado años abordando estos desafíos. BSC y Rapita están ahora entregando un conjunto de soluciones que pronto será adoptado across sectores aeroespacial y automotriz. El éxito depende de tooling especializado, automatización y una metodología orientada a seguridad, driven‑by‑requirements.

Este trabajo sustenta el proyecto MASTECS, una iniciativa multidisciplinaria de I+D financiada por la Comisión Europea lanzada en diciembre 2019. MASTECS madurará las tecnologías y proveerá un enfoque probado para certificar sistemas avionicos y automotrices, con casos de estudio de RTRC y MAR ilustrando impacto real‑world.

Herramientas state‑of‑the‑art

Herramientas comerciales destacan para análisis single‑core pero luchan con la complejidad de certificación multicore. Las limitaciones incluyen:

• Herramientas de análisis de temporización estático [1] chocan contra una pared de complejidad, incapaces de modelar hardware sofisticado o software extremadamente complejo.
• Soluciones basadas en medición —mientras prevalentes en testing single‑core (ej. toolset RVS de Rapita)— carecen de metodología expert‑hardware para producir bounds de temporización confiables para cargas de trabajo multicore con trazabilidad adecuada.

A la fecha, ninguna herramienta comercial fuera del esfuerzo de desarrollo MASTECS ofrece análisis de temporización multicore exhaustivo que alinee con estándares de seguridad y requisitos de certificación emergentes.

Análisis y control de interferencia en acción

La piedra angular de nuestro enfoque es una metodología de test estructurada que mezcla experiencia hardware y software para generar evidencia de comportamiento de temporización multicore. La tecnología de micro‑benchmark multicore de BSC (MμBT), comercializada por Rapita como RapiDaemons, permite a diseñadores crear escenarios de interferencia que estresan recursos compartidos específicos.

Micro‑benchmarks —pequeños snippets de código de bajo nivel— operan en la interfaz hardware‑software para imponer presión cuantificable en un recurso objetivo. Revelan el efecto de canales de interferencia y pueden adaptarse para inducir, medir o validar contención. Atributos clave incluyen:

1. Presión dirigida y cuantificable en un recurso compartido.
2. Comportamiento verificable a través de monitores de eventos.
3. Alineación con requisitos de temporización específicos, como testear efectividad de mitigación.

Una diversa librería de micro‑benchmarks existe para match niveles de interferencia deseados, maximizar impacto de recurso o actuar como tests "víctima" sensibles.

Al analizar interferencia, emparejamos MμBT con un Modelo de Contención de Tarea (TCM) que provee estimaciones tempranas de delays de contención. Rapita's RapiTest y RapiTime automatizan creación y ejecución de tests en el target embebido.

Metodología de diseño

Siguiendo un proceso de siete pasos integrado en el ciclo de vida de software V‑model (ver Figura 2), ingenieros ganan insight profundo en efectos de interferencia:

1. Configuración hardware & identificación de canales de interferencia. Expertos en hardware identifican settings críticos, vías de interferencia y opciones de mitigación, mientras seleccionan monitores de eventos para verificación.
2. Definir requisitos de temporización. Capturar necesidades usuario‑específicas, riesgos y restricciones de seguridad, y evaluar estrategias de aislamiento hardware.
3. Diseño de casos de test. Crear descripciones de test que validen hipótesis, especificando micro‑benchmarks necesarios para análisis de interferencia bajo condiciones aisladas y estresadas.
4. Implementar procedimientos de test. Ensamblar framework de test, micro‑benchmarks y sondas de medición. Actualmente manual, esto se automatizará dentro de MASTECS.
5. Recopilar evidencia. Ejecutar tests en la plataforma target, recopilando datos que se vinculan directamente a requisitos de verificación.
6. Analizar resultados. Expertos técnicos revisan outcomes contra requisitos. Por ejemplo, la Figura 3 muestra el desglose de tiempo de ejecución de RapiTime.
7. Validar & documentar. Revisión final, generación de reporte y artefactos de calificación listos para presentaciones de certificación.

Experiencia hardware y proceso de análisis de temporización

El insight de hardware es vital desde el inicio. La involucración temprana incluye:

1. Identificar configuraciones multicore que moldean comportamiento funcional y de temporización, y determinar mecanismos de aislamiento que reducen contención.
2. Detectar canales de interferencia navegando manuales de procesador complejos y consultando vendors para detalles faltantes.
3. Seleccionar monitores de eventos que capturan actividad de tarea en canales de interferencia, y validarlos con micro‑benchmarks dedicados [2].
4. Colaborar con analistas de temporización para derivar requisitos y diseñar tests que carguen canales de interferencia específicos.

En etapas posteriores, expertos de hardware evalúan resultados de test, refinan hipótesis y proponen tests adicionales según necesidad.

El panorama general

El proceso de diseño de siete pasos es parte de una metodología más amplia de verificación multicore (ver Figura 2). Entrega trazabilidad completa —desde evidencia y resultados hasta requisitos y diseño— soportando tanto CAST‑32A como ISO 26262. CAST‑32A, lanzado por el Certification Authorities Software Team (CAST) en 2016, esboza objetivos para avionics multicore seguros, incluyendo bounding de interferencia. EASA y FAA están trabajando en una adaptación unificada AMC/AC (AMC 20‑193) esperada para finales de este año.

La experiencia no puede automatizarse

La dinámica de interferencia es compleja; herramientas automatizadas solo pueden complementar, no reemplazar, ingenieros experimentados. Expertos multicore traen conocimiento profundo de configuraciones hardware y canales de interferencia, mientras analistas de software traducen requisitos en tests rigurosos. El insight humano es esencial para validar asunciones, interpretar resultados e iterar en diseños.

Referencias

1. Reinhard Wilhelm. Mixed Feelings about Mixed Criticality. Workshop on Worst‑Case Execution Time Analysis, 2018.
2. Enrico Mezzetti, Leonidas Kosmidis, Jaume Abella, Francisco J. Cazorla. High‑Integrity Performance Monitoring Units in Automotive Chips for Reliable Timing V&V. IEEE Micro 38(1): 56‑65 (2018).
3. EASA and FAA to issue further guidance on multicore certification this year.