Em sistemas embarcados bare metal ou tipo RTOS mínimo com vários processadores, é possível ter um programa idêntico em execução em cada processador que usa MPI (Message Passing Interface) para fornecer balanceamento de carga e também redundância em caso de falha do processador? Como uma máquina de estado que altera as ações que outras CPUs executam com base em mensagens passadas, por exemplo, solicitando que outro processador assuma parte do loop do sistema para balancear a carga ou enviar mensagens ativas periódicas e lembrar o que cada CPU é responsável até Redundância de CPU.
Neste diagrama de exemplo, as partes reais do loop completo do sistema que estão "abertas" podem ser quaisquer sistemas distintos. Não poderia haver cooperação apenas a capacidade de abrir e / ou fechar partes do loop completo do sistema em execução em cada CPU em uma espécie de multiprocessamento assimétrico muito primitivo. A "migração de processo" para outra CPU seria acionada por uma solicitação de outra CPU para abrir a parte do loop do sistema após o qual a CPU solicitante fecha sua parte ou por uma falta de resposta de outra CPU quando consultada se estiver ativa por algum tempo .
Foi proposto como uma solução para falha potencial do processador e solução para balanceamento de carga, uma vez que não podemos portar um sistema operacional incorporado para executar verdadeiramente um multiprocessamento simétrico ou assimétrico na placa personalizada, e parece que isso é teoricamente possível, mas com um design incrivelmente ruim. idéia. Além disso, não consegui encontrar nenhum padrão ou algoritmo de design para usar a passagem de mensagens dessa maneira.
Alguns antecedentes importantes para as decisões de engenharia de software: Um projeto CubeSat de aluno (não classificado ou para uma turma), temos uma pequena equipe de desenvolvimento de software, composta principalmente por estudantes juniores, com pouco ou nenhum conhecimento em design de sistemas operacionais. Por várias razões, não podemos fazer nenhuma das muitas soluções do mundo real que já li. Enquanto isso, parece possível que isso introduza muita complexidade para a equipe lidar, e mesmo que isso possa ser feito, causará um design terrível que levará a algum problema que transforma o CubeSat em uma rocha em órbita.
Não tenho certeza de que poderíamos implementar a passagem de mensagens de maneira confiável o suficiente para realizar viagens espaciais, nem sequer consegui encontrar protocolos de comunicação prontos para produção que possam ser usados para passar mensagens em um barramento com um sistema operacional minúsculo ou simples. metal como precisamos. Mas também estou curioso para saber se esta solução proposta para migração de processos, redundância de CPU e balanceamento de carga é viável para um sistema crítico de segurança. Parece que isso pode levar a um estado em que duas CPUs estão executando o mesmo "Processo" ou parte do loop do programa, se uma acordar que seria difícil de detectar.
fonte
Respostas:
Excelentes perguntas, porque na verdade eu trabalhei nisso em meados dos anos 90. As naves espaciais são caras e é difícil modificar o software uma vez em órbita. Pensei em uma variante desse problema ao pensar em como os recursos de software de naves espaciais poderiam ser realocados com base nas mudanças nos requisitos das missões. No que diz respeito ao laboratório (VxWorks):
O On Station Program atualiza sob um RTOS. Basicamente, conecte um novo conjunto de tarefas, conecte a rede da fila e inicie o fluxo de dados novamente.
Portanto, nesta implementação simples, suspendemos ou removemos algumas tarefas e permitimos que outras fossem executadas. Nós levamos um pouco mais longe no que chamamos de técnica "Transplante de Coração". Isso era para atualizações de software da estação. Poderíamos desconectar e redirecionar as redes de filas dentro do modelo de tarefas. Basicamente, desconecte a tarefa e elimine-a, se desejado, elimine as filas e reconecte a nova tarefa (coração) e as artérias (rede de filas). Fizemos esse tempo de reprodução em 1995/96. Eu não apenas queria adicionar funcionalidades, mas também remover as que não são necessárias, pois a memória é um recurso muito limitado. Não sei muito sobre MPI, nunca o usei. É determinístico? Usando a teoria da informação, você não precisa de muito para enviar um sinal de manter vivo. Use bits mínimos. As informações mais comuns, como "manter vivo", levam apenas um pouco, verdadeiro ou falso. Eventos que ocorrem com uma probabilidade muito menor precisam de mais bits para representar. Elimine qualquer sobrecarga de software possível. Siga o princípio do KISS (Mantenha as coisas simples ... Estúpidas!).
Agora proteção contra radiação de algum tipo. Projeto do aluno significa provável vôo do CMOS. Eu pelo menos colocava verificações de CRC na memória e executava um cão de guarda para detectar erros como a radiação prolongada faz coisas estranhas na eletrônica. Efeitos de perturbação de evento único podem ser mitigados usando CRC na memória. A trava requer uma redefinição de inicialização.
Sugiro tentar algo como o FreeRTOS e ver quais recursos você pode curvar à sua vontade. O espaço é um ambiente muito desafiador. Diverta-se.
fonte