Aurora SIGER — Fase 2: Pouso e Estabilização

← Voltar para Aurora SIGER

O cenário

A primeira colônia humana em Marte não chega de uma vez. Doze módulos pré-fabricados precisam pousar em sequência, cada um com sua função: comando e controle, suporte de vida, habitação, energia solar, energia nuclear, comunicações, suporte médico, produção de alimentos, logística, ISRU (extração de recursos locais), oficina e laboratório científico. Cada módulo entra em órbita marciana em horários distintos, carrega cargas de criticidade variável e depende de janelas atmosféricas estreitas para descer com segurança.

Coordenar essa sequência manualmente é inviável. O atraso de comunicação entre Terra e Marte varia de 4 a 24 minutos por sentido, e a fase de pouso dura poucos minutos. Quando o operador no centro de controle terrestre vê que algo está errado, o módulo já pousou — ou já se quebrou. A decisão precisa ser tomada onde está o problema: a bordo, em segundos, automaticamente.

O MGPEB — Módulo de Gerenciamento de Pouso e Estabilização de Base — é o sistema embarcado que faz essa coordenação. É o projeto integrador da Fase 2 do curso de Ciência da Computação da FIAP, e materializa três disciplinas simultâneas: estruturas de dados (filas, vetores, pilhas), lógica e matemática computacional (álgebra booleana, funções elementares) e formação ética profissional (perspectiva ESG da exploração espacial).

Como funciona

O MGPEB tem três responsabilidades centrais, e cada uma é apoiada por uma escolha deliberada de estrutura de dados:

1. Organizar a fila

Os módulos não chegam na ordem em que devem pousar. Uma Queue (fila FIFO) gerencia quem está aguardando autorização, mas é reordenada antes da simulação por critério multivariado: primeiro pelo horário estimado de chegada (ETA), depois por prioridade de missão, e em última instância por urgência de combustível. O ETA não é armazenado como atributo — é calculado dinamicamente como eta = ⌈distance / speed⌉, evitando inconsistência entre dados redundantes.

2. Decidir Go/No-Go

A cada módulo na frente da fila, o sistema avalia uma expressão booleana que combina cinco condições do módulo e do ambiente. A expressão é simples o bastante para ser auditada manualmente, e estrita o bastante para bloquear cenários perigosos — exceto em emergências, quando uma sobreposição lógica permite que módulos críticos desçam mesmo com a zona de pouso ocupada.

3. Registrar para auditoria

Cada bloqueio empilha um Alert numa pilha LIFO. A política most-recent-first não é estética — é como sistemas de monitoramento operacional realmente funcionam: o operador quer ver primeiro o que acabou de quebrar, não o histórico arqueológico da missão.

O sistema em ação

Considere um cenário típico de simulação. Quatro módulos chegam à órbita marciana em sequência:

Note o último caso: a zona de pouso está ocupada, mas o módulo de Energia Nuclear é classificado com criticidade máxima — sua falha comprometeria toda a colônia. A regra permite que ele desça assim mesmo, sob a premissa de que o custo de adiar supera o de aceitar a sobreposição. Toda decisão, autorizada ou bloqueada, fica registrada na pilha de alertas com o motivo exato.

Lógica booleana inspecionável

A regra de autorização combina cinco variáveis booleanas:

A expressão de autorização é:

AUTORIZADO = F ∧ A ∧ (L ∨ E) ∧ S

Em palavras: o pouso é autorizado se e somente se houver combustível suficiente, atmosfera favorável e sensores íntegros — e se a zona estiver livre ou o caso for de emergência. A subexpressão (L ∨ E) é o ponto sutil da regra: ela permite que módulos de criticidade máxima desçam mesmo com a zona ocupada. Para todas as demais variáveis, a regra é estritamente conjuntiva — qualquer falha bloqueia o pouso.

A escolha de implementar a regra como expressão booleana — em vez de uma cascata de if/else — não é estética. Ela materializa o argumento central do projeto: decisões automatizadas precisam ser inspecionáveis. Uma expressão booleana cabe numa linha, pode ser lida em voz alta, e tem uma tabela-verdade finita que qualquer auditor consegue reproduzir no papel. Cinco variáveis geram 32 combinações possíveis — exauríveis. Uma cascata de if/else aninhados, com efeitos colaterais espalhados, não.

Estruturas lineares: do zero

O outro aspecto ambicioso da Fase 2 foi implementar Vector, Queue e Stack do zero — sem usar list.append(), collections.deque ou queue.Queue da biblioteca padrão. O módulo aurora_siger.landing depende apenas de math e random: nenhuma dependência externa, nenhum atalho de alto nível.

A herança Vector → Queue → Stack é deliberada: Vector carrega busca linear e ordenações (Bubble Sort e Selection Sort), e suas filhas adicionam apenas restrições de acesso. Queue permite inserir só no fim e retirar só do início (FIFO). Stack permite inserir e retirar só do topo (LIFO). A busca permanece disponível em todas — o que muda é o invariante de quem entra e sai por onde.

Modelagem matemática

Quatro fenômenos do pouso são modelados por funções elementares — escolhidas para ilustrar tipos diferentes de comportamento dinâmico:

• Altitude de descida: função quadrática que traduz a desaceleração progressiva conforme o módulo se aproxima da superfície.
• Consumo de combustível: decaimento exponencial — perda inicial rápida, estabilização tardia.
• Energia solar disponível: função periódica que reflete o ciclo dia-noite marciano.
• Temperatura externa: senoidal, oscilando entre os extremos térmicos da face solar e da sombra orbital.

Cada função tem domínio, contradomínio e parâmetros documentados; a derivação é mostrada passo a passo no relatório técnico. A escolha pedagógica é deliberada: ao implementar essas funções diretamente em Python (sem numpy.linspace ou bibliotecas científicas) o aluno enxerga a relação entre a fórmula matemática e a iteração computacional — algo que abstrações de alto nível tendem a esconder.

Por que importa

Coordenar o pouso de uma colônia automaticamente parece um problema de engenharia, mas é também um problema de governança. Quem decide quais módulos têm prioridade? Quem decide o que conta como "emergência" para acionar o bypass? Em última instância, quem se beneficia da expansão para Marte e quem paga o preço de uma falha?

A Fase 2 desdobra essas perguntas em dois ensaios complementares. A contextualização histórica traça a evolução do hardware embarcado — do AGC do Apollo (com 4 KB de RAM e arquitetura de prioridades hierárquicas) até os sistemas modernos — e mostra como cada geração transferiu propriedades não-funcionais para a próxima: tolerância a falhas, determinismo, auditabilidade. A reflexão ESG examina a colônia Aurora Siger sob as três dimensões da governança contemporânea: ambiental (consumo energético orbital, impacto da extração ISRU), social (hierarquia de prioridades como expressão de valores) e corporativa (auditoria, transparência das regras, prestação de contas).

Quando a regra cabe numa linha booleana, a discussão sobre por que essa regra e não outra fica explícita. Quando se esconde em mil linhas de código procedural, a discussão simplesmente desaparece — e o que parece ser uma decisão técnica passa a ser, na prática, uma decisão política tomada à revelia.

Qualidade e rigor

A Fase 2 expande o pacote aurora_siger para a versão 0.2.0, mantendo o monolito incremental do projeto. O módulo aurora_siger.landing é zero-dep no caminho de execução do CLI — usa apenas math e random da biblioteca padrão, refletindo a escolha pedagógica de não depender de NumPy para estruturas lineares.

Os testes cobrem não apenas o caminho feliz, mas todos os 32 estados da tabela-verdade, condições de fronteira (fuel_level == 20, cargo_criticality == 5), reordenação multi-critério com empates de ETA, e a separação entre regra pura e gestão de estado — authorization.evaluate() é uma função pura que retorna AuthorizationResult, enquanto o empilhamento de alertas é responsabilidade da LandingMission. A regra é testável sem instanciar a missão; a missão é testável sem mockear a regra.

O sistema também tem um CLI interativo (mgpeb) que permite operar a simulação manualmente, alterando condições ambientais e observando o impacto nas decisões — útil tanto para demonstração quanto para construir intuição sobre o espaço de estados da regra.

---

Explore o código-fonte no repositório GitHub ou execute a simulação completa no notebook interativo no Google Colab.