Aurora SIGER — Fase 3: Operação Energética da Colônia

← Voltar para Aurora SIGER

O cenário

A colônia que pousou na Fase 2 agora precisa durar. Os doze módulos que desceram em sequência — comando, suporte de vida, habitação, energia, comunicações, suporte médico — estão no solo marciano, e a pergunta crítica deixou de ser pontual. Não é mais é seguro decolar? nem este módulo pode pousar agora?. É uma pergunta com eixo temporal: vamos ficar sem energia daqui a quantas horas?

A Fase 3 simula a operação da colônia ao longo de 7 sóis marcianos — 168 horas, passo a passo de uma hora. A cada hora o sistema gera energia (solar, eólica, nuclear), consome-a (carga base de cada módulo somada a um termo térmico físico), armazena o saldo em bateria e decide como distribuir potência quando ela é escassa. É o terceiro ato do arco do Aurora SIGER — decolagem → pouso → operação — e o que muda é a natureza do problema: a energia de uma colônia é exatamente o tipo de grandeza em que o "agora" engana e o "depois" importa.

A contribuição conceitual da fase é essa transição: de um controle puramente reativo (cortar carga depois que falta energia) para um controle preditivo (antecipar a queda e agir antes), preservando o reativo como rede de segurança.

Como funciona

A simulação é determinística. Toda fonte de aleatoriedade — clima e falhas de equipamento — passa pelo mesmo gerador congruencial linear (LCG) seed-aware injetado no estado. A mesma seed reproduz a história hora a hora, bit a bit: duas execuções de run_simulation(seed=42) produzem o mesmo histórico, verificado por diff. Num sistema que se quer auditável, determinismo não é detalhe — é garantia de projeto.

Três peças sustentam cada passo de hora:

A colônia como duas árvores sobre os mesmos dados

A colônia é uma lista plana de 13 módulos (os 12 que pousaram na Fase 2 — mesmos nomes e prioridades — mais um gerador eólico acrescentado agora; a continuidade narrativa é deliberada). Sobre essa lista, o sistema constrói duas árvores N-árias que referenciam os mesmos objetos de módulo: uma agrupa por função (energia, suporte de vida, comando, operações), outra por criticidade (Vital → Sustento → Expansão). Alterar o modo de um módulo é imediatamente visível por qualquer das árvores — não há cópia nem sincronização. A árvore de criticidade é a que o alocador percorre quando a energia falta: rebaixa modos de baixo para cima, e Vital nunca desliga.

Geração, consumo e o termo térmico

O nuclear é a base estável; solar e eólica são a contribuição variável que oscila com o ciclo dia-noite e o vento. Do lado do consumo, cada módulo tem uma carga base por modo de operação — mas a ela se soma um termo térmico que segue o modelo físico de perda por envelope, Q = U·A·ΔT. Esse termo é somado mesmo com o módulo desligado: habitats pressurizados em Marte não podem congelar. Abaixo de cerca de −86 °C o aquecimento elétrico entra, e é aí que o consumo dispara.

Clima e falhas, com realismo

O clima é uma máquina de estados: tempestades de poeira que degradam o fator dos painéis (via opacidade atmosférica tau) e frentes frias que derrubam a temperatura por janelas de horas. Cada módulo ativo tem ~0,5 %/hora de chance de falhar; ao falhar, sai da geração e do consumo e entra em reparo automático temporizado. Na execução canônica houve até 3 módulos quebrados simultaneamente, com pelo menos um em reparo em 108 das 168 horas, e a temperatura chegou a −97,7 °C.

Déficit instantâneo ≠ emergência

Aqui está o resultado mais revelador da fase, e o que justifica todo o resto. Em 93 das 168 horas a geração instantânea ficou abaixo do consumo — pelo critério do instante, "risco". Mas apenas 7 horas dispararam alerta real de emergência.

A diferença é a bateria. À noite o solar zera e só o nuclear sustenta a base, então o consumo instantâneo supera a geração — mas a bateria absorve o vale e recarrega ao longo do dia seguinte. O gráfico abaixo mostra os dois fatos juntos: em cima, geração e consumo se cruzando hora a hora; embaixo, a bateria respirando — drenando à noite, enchendo de dia — sem nunca esvaziar de fato.

É a tradução numérica do argumento central: o "agora" (déficit instantâneo) assusta; o estado real (bateria mais tendência) tranquiliza. Decidir só pelo instantâneo seria reagir a um falso alarme 93 vezes. Decidir pela tendência é o passo preditivo.

Do reativo ao preditivo

O instrumento da antecipação é deliberadamente modesto: uma regressão linear por mínimos quadrados, em forma fechada, implementada à mão — sem numpy nem scikit-learn.

a = Σ(x−x̄)(y−ȳ) ⁄ Σ(x−x̄)², b = ȳ − a·x̄

A mesma função serve a dois propósitos. O primeiro é previsão direta: treinada sobre os pares (vento, geração eólica) acima do cut-in, a reta prevê a potência eólica a partir do vento. Na execução canônica o modelo ajustado foi energia ≈ 2,50·vento − 7,50 (kW) — o ajuste quase perfeito que se vê abaixo.

O segundo uso é o que dá poder preditivo ao sistema. A mesma regressão, treinada sobre a janela recente dos deltas de energia (geração menos consumo, hora a hora), devolve o slope — a inclinação da tendência, em kW por hora. O slope não diz onde a bateria está; diz para onde ela vai.

A peça que fecha o raciocínio é o rótulo de energia. O estado de saída da colônia — CRITICAL → LOW → NOMINAL → HIGH → SURPLUS — não controla os módulos: é o rótulo computado de bateria% + slope. Uma bateria a 60 % com inclinação estável é NOMINAL; a mesma bateria a 60 % despencando a −3 kW/h é rebaixada um degrau, para LOW, porque o sistema projeta que, mantida a tendência, ela cruzará o patamar crítico antes do próximo ciclo de carga. Em 21 das 168 horas o slope esteve abaixo de −0,5 kW/h, e nessas janelas o rótulo antecipou o problema em vez de constatá-lo. O estado deixa de ser uma leitura e vira uma projeção — esse é, em uma frase, o salto reativo→preditivo.

A escolha da OLS de forma fechada, em vez de gradiente descendente, é parte do argumento: ela é exata, não tem taxa de aprendizado para calibrar, não diverge e não precisa de clamp anti-explosão. Para uma janela curta de poucas dezenas de pontos, é mais barata, mais previsível e mais fácil de explicar a quem audita. Sofisticação aqui seria ruído.

Controle em duas camadas

A síntese da fase não escolhe entre reagir e prever — estratifica as duas em defesa em profundidade:

1. Camada preventiva e graduada — power_factor: conforme a bateria cai, estrangula suavemente o alvo de consumo de cada módulo, numa escala contínua de 1,0 a 0,2. Começa a economizar cedo, quando ainda é barato, sem saltos binários.
2. Camada de contingência — load shedding em 4 estágios: percorre a árvore de criticidade e, quando a oferta ainda não cobre a demanda já atenuada, rebaixa modos de baixo para cima — desligando Expansão antes de tocar em Sustento, e Sustento antes de Vital. É a rede de segurança estrutural.

O cuidado de engenharia foi evitar a dupla-contagem: o power_factor escala os alvos de consumo, e a alocação então decide os modos contra a oferta usando esses alvos já reduzidos — uma ordem de operações, não duas correções competindo. O preditivo (o slope, que informa quão agressivo ser) e o reativo (o shedding, que garante que Vital nunca apaga) operam sobre a mesma grandeza sem se atropelar.

Por que importa

Seria desonesto encerrar sem nomear o que a previsão não entrega. Uma OLS linear sobre janela curta extrapola mal sob regime não-estacionário: quando uma tempestade de poeira derruba o fator de painel ou uma frente fria dispara o consumo térmico, a tendência recente vira uma péssima testemunha do futuro imediato — a reta aponta para um lugar onde a física já não está.

A previsão é uma hipótese, não uma certeza. Um sistema maduro a trata como tal: o slope informa a decisão, não a substitui.

É por isso que o reativo permanece. O load shedding e o power_factor não são resquícios de uma fase anterior a ser superada — são a fundação sobre a qual a previsão pode se dar ao luxo de às vezes errar. Esse é o eco direto da reflexão ética da Fase 1: automação em sistemas críticos amplia o operador, não o aposenta. A reta antecipa para que o humano decida com mais folga, não para decidir por ele. A reflexão completa está no ensaio Do reativo ao preditivo.

Qualidade e rigor

A Fase 3 expande o pacote aurora_siger para a versão 0.3.0, mantendo o monolito incremental do projeto: a operação vive em aurora_siger.operations, e tanto o notebook quanto o CLI importam dessa fonte única — nunca lógica inline. O sistema tem dois front-ends sobre o mesmo núcleo determinístico: o notebook narrativo (run_simulation() com gráficos) e o CLI aurora, um dashboard TUI ao vivo de 6 abas — incluindo uma que desenha a árvore de criticidade em tempo real (o item de hierarquia visualizado).

Os testes cobrem a regressão pura (ajuste exato sobre dados sintéticos), a separação entre física, rótulo e apresentação, o determinismo (dois runs com a mesma seed batem), e a ausência de dupla-contagem no controle em duas camadas — verificado numericamente que o consumo real após a alocação cabe sob a oferta. A regra de decisão (evaluate_rules) é uma função pura, testável sem instanciar a simulação; a simulação é testável sem mockear a regra.

---

Projeto desenvolvido coletivamente pela equipe de Ciência da Computação (online) da FIAP — 2026. Explore o código-fonte no repositório GitHub, leia o relatório técnico ou execute a simulação completa no notebook interativo no Google Colab.