Garantizar el comportamiento de sincronización del software en sistemas integrados críticos basados ​​en varios núcleos

Llegar a algún lugar de manera segura depende de algo más que buenos frenos, luces traseras que funcionen y alguien con excelentes reflejos al volante. Cada vez más, los componentes que mantienen su automóvil en la carretera y su avión en el aire no son solo humanos, o incluso mecánicos. Son piezas sofisticadas de software integrado que se ejecutan en procesadores multinúcleo heterogéneos complejos, controlando todo, desde el sistema de gestión de vuelo hasta la dirección asistida, y ejecutando estrictos plazos de tiempo medidos en microsegundos.

Aquí radica el desafío. El comportamiento de sincronización del software en un sistema multinúcleo se ve afectado no solo por el software que se ejecuta en él y sus entradas, sino también por el otro software que se ejecuta en otros núcleos.

Los sistemas integrados críticos requieren un inmenso esfuerzo e inversión (millones de euros / dólares y años de esfuerzo de ingeniería) para desarrollarse. La seguridad debe estar en el corazón de la arquitectura y el diseño, desde las primeras etapas del proceso de desarrollo de software. En particular, los diseñadores de sistemas deben comprender el comportamiento temporal de su software para garantizar que se pueda ejecutar dentro de plazos seguros.

Resolver el acertijo del análisis de tiempo multinúcleo (MTA)

Aunque la impresionante capacidad informática de un procesador multinúcleo debería (en teoría) hacer que los sistemas integrados sean más potentes y eficientes, el software que se ejecuta en un núcleo puede ralentizar la ejecución del software que se ejecuta en los otros núcleos. En esta situación, el software puede tardar más en ejecutarse debido a la interferencia causada por la contención de recursos compartidos como buses, memoria, cachés, dispositivos, FPGA y GPU que se comparten con tareas que se ejecutan en otros núcleos.

¿Cómo cuantifica los efectos de esta interferencia? ¿Cómo analiza, prueba y proporciona evidencia concreta de que su software crítico para la seguridad, cuando se ejecuta en una plataforma multinúcleo, siempre se puede ejecutar dentro de los plazos establecidos?

Los expertos del Barcelona Supercomputing Center (BSC), Rapita Systems Ltd (RPT), Raytheon Technologies (RTRC) y Marelli Europe (MAR) han estado investigando respuestas a estas preguntas durante muchos años. BSC y Rapita han estado desarrollando una solución que pronto se implementará en las industrias aeroespacial y automotriz. Herramientas especializadas y automatización, combinadas con una metodología basada en requisitos y centrada en la seguridad, fueron las claves para resolver el rompecabezas.

Este trabajo ha formado la base del proyecto MASTECS, un proyecto multidisciplinario de investigación y desarrollo financiado por la Comisión Europea y lanzado en diciembre de 2019. El proyecto MASTECS madurará las tecnologías y apoyará su uso para la certificación de sistemas de aviónica y automoción. Una parte clave del proyecto MASTECS es proporcionar una demostración del enfoque en dos industrias a través de estudios de casos implementados por RTRC y MAR.

Herramientas de última generación

Las herramientas disponibles comercialmente para respaldar el análisis de tiempos son efectivas para la electrónica simple (de un solo núcleo), pero no se escalan para cumplir con los nuevos requisitos y recomendaciones de certificación específicos de varios núcleos.

• Las soluciones de análisis de temporización estática [1] enfrentan un muro de complejidad y no pueden modelar de manera efectiva el hardware cada vez más complejo ni tratar de manera eficiente las características estructurales y sintácticas de funcionalidades de software excepcionalmente complejas.
• Las soluciones basadas en mediciones han alcanzado un buen nivel de penetración en el mercado de análisis de un solo núcleo (el conjunto de herramientas RVS de Rapita Systems se encuentra entre los más exitosos). Sin embargo, estas herramientas aún no pueden soportar por completo los desafíos planteados por la introducción de multinúcleos. Por lo general, se enfocan en escenarios de medición según lo determinado por estrategias de pruebas funcionales consolidadas, pero carecen de una metodología basada en la experiencia en hardware que ayude a derivar límites de tiempo confiables para las tareas que se ejecutan en múltiples núcleos con la evidencia de respaldo necesaria y un nivel adecuado de trazabilidad.

Hasta donde sabemos, no hay ninguna herramienta comercial disponible en el mercado, aparte de la que se está madurando en MASTECS, que sea capaz de analizar la sincronización del software en plataformas multinúcleo, con un fuerte enfoque en los estándares de seguridad aplicables y los requisitos de certificación emergentes.

Análisis y control de interferencias en acción

La clave para comprender la interferencia es una metodología de prueba estructurada, que utiliza expertos en hardware y software para producir evidencia sobre el comportamiento de temporización multinúcleo. Una tecnología especializada de BSC (conocida como tecnología de micro-benchmark multinúcleo o MμBT, comercializada por Rapita como RapiDaemons) permite a los diseñadores de sistemas analizar y cuantificar los efectos de la interferencia en una aplicación multinúcleo mediante la creación de escenarios de interferencia adicionales para realizar pruebas de estrés en diferentes partes de el procesador multinúcleo.

Los micro-benchmarks, en el corazón de MuBT, son piezas de código bien elaboradas que operan en la interfaz más baja entre hardware y software para enfatizar un recurso compartido específico. Los micro-benchmarks exponen el impacto de los canales de interferencia en la sincronización del software. Para hacerlo, se pueden implementar micro-benchmarks para causar una presión configurable y cuantificable en una aplicación específica. Los micro-benchmarks están diseñados específicamente para exhibir un comportamiento único y claramente definido con un efecto anticipado en un recurso de hardware específico, al tiempo que se evita en la medida de lo posible la generación de contención en otros canales de interferencia. Las características clave de las microcomparativas incluyen las siguientes:

1. Ejercen una presión cuantificable sobre un recurso compartido específico.
2. Su comportamiento se puede verificar mediante monitores de eventos.
3. Capturan requisitos específicos relacionados con el tiempo, por ejemplo, si las acciones de mitigación que implementa para dominar la contención son efectivas.

haz clic para ampliar la imagen

Figura 1:Uso de micro-benchmarks en análisis de interferencia. (Fuente:Autores)

Se ha desarrollado una amplia gama de micro-puntos de referencia para tener roles específicos, que incluyen igualar el nivel deseado de interferencia, maximizar la interferencia en el recurso o simplemente ser muy sensible a la contención ("víctimas").

Al analizar los efectos de la interferencia, el uso de MμBT es compatible con un modelo de contención de tareas (TCM) que proporciona estimaciones tempranas del retraso de la contención que pueden sufrir las tareas. Las herramientas de prueba y automatización de software RapiTest y RapiTime desarrolladas por Rapita se utilizan para escribir pruebas y ejecutarlas en el objetivo integrado.

Metodología de diseño

Al seguir un proceso de diseño de prueba de siete pasos junto con el proceso de desarrollo de software estándar "V" (Figura 2), los ingenieros pueden comprender mejor el impacto de la interferencia.

1. Ajuste de configuración crítica del procesador multinúcleo, canal de interferencia y análisis del monitor de eventos. Los expertos en hardware ayudan a identificar los ajustes de configuración críticos para establecer el marco en el que también se identifican los canales de interferencia junto con las medidas de mitigación. La identificación de los monitores de eventos de hardware también es fundamental para proporcionar un medio de verificación para todos los pasos siguientes.
2. Identifique los requisitos de tiempo. Ayude al usuario final a identificar sus necesidades específicas, requisitos de tiempo, riesgos y problemas de seguridad para el sistema. Por ejemplo, verifique el rendimiento de cualquier método de aislamiento de hardware para minimizar la interferencia.
3. Diseño de casos de prueba. Desarrollar casos de prueba específicos (descripción de una prueba) para verificar el conjunto de hipótesis que respaldan los requisitos del usuario, incluida la definición de los elementos MμBT que serán necesarios para proporcionar evidencia en el análisis del canal de interferencia. Esto implica la ejecución de forma aislada (sin interferencia), la ejecución contra micro-evaluaciones comparativas para evaluar el tiempo de ejecución de la aplicación y la sensibilidad del hardware a la interferencia en diferentes escenarios de estrés cuantificables.
4. Implementación de procedimientos de prueba. Actualmente, un proceso manual para ser automatizado en MASTECS, este paso construye los procedimientos de prueba que consisten en un marco de prueba, micro-benchmarks y sondas de medición para registrar / rastrear los resultados.
5. Recopilación de pruebas (pruebas). Los procedimientos de prueba se ejecutan en la plataforma para recopilar evidencia de prueba. Actualmente implica algo de trabajo manual, esto se automatizará en MASTECS utilizando el marco de automatización RapiTest para ejecutar esas pruebas y vincularlas a los requisitos de verificación.
6. Análisis de resultados. Una revisión de los resultados de la prueba por parte de expertos técnicos para verificar cómo los resultados de la prueba verifican (o no) los requisitos de verificación. Por ejemplo, la Figura 3 muestra una captura de pantalla de RapiTime sobre los tiempos de ejecución reportados para diferentes funciones de un programa.
7. Valide resultados y genere documentación. Revisión final de requisitos, generación de documentación y resultados de calificación para respaldar el argumento de seguridad del sistema. El cliente puede utilizar el conjunto completo de informes y artefactos de análisis directamente para la certificación del software que se ejecuta en multinúcleo.

haz clic para ampliar la imagen

Figura 2:Pasos de MTA en el proceso de desarrollo de software del modelo V. (Fuente:Autores)

Experiencia en hardware y proceso de análisis de tiempos

La inyección de experiencia en hardware (multinúcleo) es un rasgo clave en el enfoque MTA propuesto para su éxito en los multinúcleos complejos modernos. Durante las primeras etapas de desarrollo de software:

1. Los expertos en hardware identifican configuraciones multinúcleo (ajustes de configuración críticos en la jerga de la aviónica), ya que desempeñan un papel clave en la determinación del comportamiento funcional y de sincronización del software, y afectan en gran medida la cantidad de tareas de contención que se generan entre sí. Como ejemplo ilustrativo, los procesadores actuales implementan mecanismos de aislamiento y segregación que, si se implementan correctamente, pueden reducir considerablemente la contención.
2. Los expertos multinúcleo desempeñan un papel clave en la identificación de aquellos recursos en los que puede surgir la contención de tareas (estos se conocen como canales de interferencia en aviónica). La capacidad de los expertos en hardware para navegar por manuales de referencia técnica de procesadores de miles de páginas y formular las preguntas apropiadas sobre la información potencial que falta en los manuales para los proveedores de chips es fundamental para impulsar un proceso de MTA adecuado.
3. Una vez que se identifican los canales de interferencia, los expertos en hardware identifican los monitores de eventos que pueden usarse para rastrear la actividad que generan las tareas en esos canales de interferencia como una métrica de proxy para limitar la contención que las tareas pueden sufrir. La exactitud de esos monitores de eventos también debe verificarse [2] para lo cual se ha diseñado un conjunto especializado de micro-evaluaciones comparativas.
4. Por último, los expertos en hardware trabajan mano a mano con los expertos en análisis de tiempos para derivar, a partir de los requisitos del usuario, requisitos de alto y bajo nivel y pruebas específicas para validar las hipótesis que respaldan los requisitos del usuario. Cada prueba crea una instancia de uno o varios programas de micro-benchmark diseñados por expertos en hardware para poner el nivel deseado de carga en el (conjunto de) canales de interferencia objetivo.

Durante las últimas etapas del diseño:

1. Los expertos en hardware contribuyen con el análisis de los resultados de las pruebas para evaluar si confirman o rechazan las hipótesis.
2. Los expertos en hardware también contribuyen a establecer nuevas hipótesis y las pruebas correspondientes en caso de ser necesarias en base a los resultados obtenidos en el paso anterior.

haz clic para ampliar la imagen

Figura 3:Análisis de resultados (RapiTime). (Fuente:Autores)

El panorama general

El proceso de diseño de prueba de 7 pasos es solo una parte de una metodología de verificación multinúcleo más amplia que se mostró anteriormente en la Figura 2. Esta metodología, que continuará madurando como parte del proyecto MASTECS, está diseñada para lograr una trazabilidad completa, a partir de evidencia integral y resultados de nuevo a los requisitos y diseños correspondientes. La metodología está diseñada para cumplir con los objetivos definidos en CAST-32A, el documento de orientación clave emitido por las autoridades de certificación aeroespacial. También está específicamente alineado con ISO 26262, el estándar de seguridad para el sector automotriz, que aboga por la ausencia de interferencias.

CAST-32A fue publicado por el Equipo de Software de las Autoridades de Certificación (CAST) en 2016, e identifica factores que impactan la seguridad, el desempeño y la integridad de los sistemas de software aerotransportados que se ejecutan en procesadores multinúcleo. Si desea utilizar hardware multinúcleo en un sistema de aviónica, este es el documento de referencia. Proporciona objetivos destinados a orientar la producción de sistemas de aviónica multinúcleo seguros, incluidos objetivos relacionados con la identificación y delimitación del impacto de los canales de interferencia. Vea el documento de posición de CAST-32A aquí. EASA y FAA están trabajando en una adaptación del CRI genérico multinúcleo en un material AMC / AC común (AMC 20-193). Se espera que se publique "a finales de este año" [3].

La experiencia no se puede automatizar

Los efectos de interferencia son complejos. Para desentrañar sus misterios, necesita expertos que comprendan tanto los componentes de la arquitectura multinúcleo como los sistemas de programación y asignación de recursos del software. La colaboración entre expertos en hardware y software será una característica central del proyecto MASTECS a medida que avanza en el futuro. Pero si bien la colaboración conduce a grandes avances en la automatización y las herramientas de software, es importante recordar que no se puede automatizar cada paso de un proceso de validación, especialmente cuando se trata de un análisis de tiempo multinúcleo.

Necesita ingenieros experimentados que conozcan los sistemas en detalle. Por ejemplo, durante las primeras etapas, los expertos multinúcleo pueden identificar las configuraciones del procesador (también conocidas como configuraciones críticas de hardware) que determinan el comportamiento funcional y de temporización del software, así como los canales de interferencia potenciales. Cuando se trata de analizar los resultados de las pruebas, nada supera la aportación de un experto humano experimentado para revisar y evaluar las suposiciones originales hechas sobre la plataforma, y ​​utilizar su conocimiento para alimentar un nuevo ciclo de pruebas.

Referencias

[1] Reinhard Wilhelm. Sentimientos encontrados sobre la criticidad mixta. Taller sobre análisis del tiempo de ejecución en el peor de los casos, 2018.

[2] Enrico Mezzetti, Leonidas Kosmidis, Jaume Abella, Francisco J. Cazorla. Unidades de monitoreo de desempeño de alta integridad en chips automotrices para una sincronización confiable V&V. IEEE Micro 38 (1):56-65 (2018).

[3] https://www.aviationtoday.com/2020/02/28/easa-and-faa-to-issue-further-guidance-on-multicore-certification-this-year/