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.
fuente
Respuestas:
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):
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.
fuente