¿Se puede utilizar el paso de mensajes para una construcción de redundancia de CPU y equilibrio de carga?

En sistemas embebidos tipo simple o RTOS mínimo con múltiples procesadores, ¿es posible tener un programa idéntico ejecutándose en cada procesador que use la interfaz de paso de mensajes (MPI) para proporcionar equilibrio de carga y también redundancia en caso de falla del procesador? Tal como una máquina de estado que cambia las acciones que realizan otras CPU en función de los mensajes pasados, por ejemplo, pedirle a otro procesador que se haga cargo de alguna parte del bucle del sistema para equilibrar la carga o enviar mensajes vivos periódicos y recordar de qué es responsable cada CPU en la medida en que Redundancia de CPU.

En este diagrama de ejemplo, las partes reales del ciclo completo del sistema que están "abiertas" podrían ser sistemas distintos. No podría haber cooperación, solo la capacidad de abrir y / o cerrar partes del bucle completo del sistema que se ejecuta en cada CPU en una especie de multiprocesamiento asimétrico muy primitivo. La "migración de proceso" a otra CPU se desencadenaría por una solicitud de otra CPU para abrir esa parte del bucle del sistema, después de lo cual la CPU solicitante cierra su parte, o una falta de respuesta de otra CPU cuando se le consulta si está viva durante algún tiempo .

Se ha propuesto como una solución para posibles fallas del procesador y una solución para el equilibrio de carga, ya que no podemos portar un sistema operativo incorporado para realizar realmente un multiprocesamiento simétrico o asimétrico en la placa personalizada, y parece que es teóricamente posible, pero un diseño increíblemente pobre idea. Además, no he podido encontrar ningún patrón de diseño o algoritmo para usar el envío de mensajes de esta manera.

Algunos antecedentes importantes para las decisiones de ingeniería de software: un proyecto de CubeSat para estudiantes (no calificado o para una clase), tenemos un pequeño equipo de desarrollo de software con estudiantes en su mayoría jóvenes con poco o ningún conocimiento del diseño de sistemas operativos. Por diversas razones, no podemos hacer ninguna de las muchas soluciones del mundo real sobre las que he leído. Si bien parece que es posible, parecerá que introducirá demasiada complejidad para el equipo, e incluso si se puede hacer, causará un diseño terrible que conducirá a un problema que convertirá al CubeSat en una roca en órbita.

Ni siquiera estoy seguro de que podamos implementar el envío de mensajes de una manera lo suficientemente confiable para el carenado espacial, ni siquiera he podido encontrar protocolos de comunicación listos para la producción que puedan usarse para pasar mensajes en un bus con un sistema operativo pequeño o simple metal como lo necesitamos. Pero también tengo curiosidad por saber si esta solución propuesta para la migración de procesos, la redundancia de la CPU y el equilibrio de carga es incluso viable para un sistema crítico de seguridad. Parece que podría conducir a un estado en el que dos CPU ejecutan el mismo "Proceso" o parte del bucle del programa si uno se despierta y sería difícil de detectar.

embedded-systems message-passing space-technology

— 8bit.wappen
fuente

Algunas preguntas: (1) ¿cómo se pasan los datos? ¿Hay una red o bus de paso de datos entre procesadores? Es poco probable que todos los procesadores puedan compartir el acceso a los mismos bancos de memoria al mismo tiempo, a diferencia de los procesadores de propósito general (escritorio / servidor). (2) ¿Cómo lidiar con equipos (sensores y actuadores) que están conectados a un solo procesador?

— rwong

Los datos tendrían que pasarse usando UART o I2C, si usáramos memoria compartida también podríamos hacer SMP, pero las cosas que leí sobre la implementación (preferiblemente sobre SPI) como las barreras de memoria ni siquiera están cubiertas en nuestro curso de sistemas operativos de pregrado y mucho menos implementación de mutex, semáforo, etc. El equipo de ingeniería eléctrica e informática me ha asegurado que cada CPU se conectaría a cada dispositivo periférico, pero el diseño de la placa no está completo.

— 8bit.wappen

No veo cómo puede lograr la redundancia de la CPU y el equilibrio de carga al mismo tiempo. Si distribuye diferentes tareas a cada CPU, entonces no hay redundancia (si la CPU falla, puede dejar de responder, pero lo más probable es que haga algo al azar, generalmente debido a los efectos de la radiación, pero sigue respondiendo). Por redundancia, todas las tareas deben ejecutarse en todos los procesadores. Si el equilibrio de carga es más importante que la redundancia, entonces su esquema parece bastante simple, simplemente implementaría cada parte como una tarea diferente en lugar de ramas de una sola tarea (suponiendo que su RTOS sea multitarea).

— André Sassi

@ AndréSassi: AFAICT comienza con redundancia y un cierto equilibrio de carga, y, si algo sale mal con algunas de las CPU, migra las tareas a otras CPU, lo que resulta en una mayor carga por CPU, y tal vez incluso un rendimiento reducido para un menor tareas prioritarias, o mayor tasa de error no crítico. Esto es aún mejor que fallar por completo.

— 9000

¿Cuál es la ventaja de este sistema en lugar de ejecutar todas las tareas en todos los procesadores?

— user253751

Excelentes preguntas porque en realidad resolví algo de esto a mediados de los 90. Las naves espaciales son caras y es difícil modificar el software una vez en órbita. Pensé en una variante de este problema al pensar cómo los recursos de software de naves espaciales podrían reasignarse en función de los requisitos cambiantes de la misión. Hasta donde lo llevamos en el laboratorio (VxWorks):

Estime la carga de tareas para lo esencial para cada procesador según los requisitos.
Estime la carga de tareas para el conjunto de tareas de sub misión. Esta es la nueva configuración deseada basada en proporcionar las tareas necesarias por procesador requeridas para cumplir con los requisitos de misión más importantes. Básicamente sin lo que no puedes vivir.
Para cada procesador, ahora tenemos un modelo de misión principal y variantes del mismo en función de otros estados de procesamiento a los que tendremos que cambiar lo más rápidamente posible. Esta es una simple adaptación planificada. Nada especial, solo diferentes conjuntos de modelos de tareas que intervienen en algunos estímulos. El equilibrio de carga en mis experimentos fue esencialmente planificado previamente. Utilizamos la programación básica de RMA para esta operación. Básicamente, este es un gran cambio de contexto en un nivel de modelo de tareas de todo el sistema.

Actualizaciones del programa en la estación bajo un RTOS. Básicamente, conecte un nuevo conjunto de tareas, conecte la red de colas e inicie nuevamente el flujo de datos.
Entonces, en esta implementación simple, suspendemos o eliminamos algunas tareas y permitimos que otras se ejecuten. Lo llevamos un poco más allá en lo que llamamos la técnica de "trasplante de corazón". Esto fue para actualizaciones de software en la estación. Podríamos desconectar y redirigir las redes de colas dentro del modelo de tareas. Básicamente desconecte la tarea y elimínela si así lo desea, elimine las colas y vuelva a conectar la nueva tarea (corazón) y las arterias (red de colas). Hicimos este tiempo de juego en 1995/96. No solo quería la capacidad de agregar funcionalidad, sino también eliminarla, ya que la memoria es un recurso muy limitado. No sé mucho sobre MPI, nunca lo usé. ¿Es determinista? Usando la teoría de la información, no necesita mucho para enviar una señal de mantener vivo. Usa bits mínimos. La información más común como "mantener vivo" toma solo un bit, verdadero o falso. Los eventos que ocurren con una probabilidad mucho más baja necesitan más bits para representar. Elimine cualquier sobrecarga de software que pueda. Sigue el principio de KISS (Keep It Simple..Stupid!).

Ahora protección contra la radiación de algún tipo. Proyecto estudiantil significa probablemente CMOS volando. Al menos pondría controles CRC en la memoria y ejecutaría un perro guardián para detectar errores como que la radiación de los bloqueos hace cosas extrañas a la electrónica. Los efectos molestos de un solo evento pueden mitigarse utilizando CRC en la memoria. El enclavamiento requiere un reinicio de encendido.

Sugeriría probar algo como FreeRTOS y ver qué características puede doblar a su voluntad. El espacio es un entorno muy desafiante. Que te diviertas.

— Vimyixen
fuente