E2TS da Embraer: como funciona a decolagem automática certificada

Quando a Embraer anunciou que vai receber da Anac, entre setembro e outubro, a primeira certificação do mundo para decolagem 100% automática — o sistema E2TS (Embraer Enhanced Take-Off System) — minha primeira reação não foi como passageiro. Foi como engenheiro: quero entender o pipeline de software, a fusão de sensores, os limites de falha e o estado da máquina que decide “rota de decolagem liberada”. Segundo o Olhardigital.com.br, o Brasil pode se tornar o primeiro país a autorizar oficialmente essa tecnologia, com reconhecimento em cascata nos EUA e na Europa via CMT (Certification Management Team).

Em mais de uma década escrevendo sistemas distribuídos, pipelines de IA e integrações críticas, aprendi que o problema nunca é fazer a coisa funcionar — é garantir que ela falhe com elegância. Decolagem automática é o limite disso. Vamos dissecar.

O que é o E2TS e por que ele é diferente do autothrottle clássico

Muita gente confunde decolagem automática com “empurrar o manche para frente e deixar o avião acelerar”. Não é. O E2TS vai além do autothrottle que já existe em Boeing e Airbus. O sistema orquestra aceleração dos motores, configuração de flaps, direção do nariz e, o ponto crítico, a decisão de abortar a decolagem se algo degrada durante a corrida na pista.

Tecnicamente, estamos falando de três blocos:

• Percepção: fusão de dados de IRS (Inertial Reference System), GPS, radar de pista, anemômetro, sensores de temperatura do motor e parâmetros de peso/balanceamento calculados em tempo real.
• Decisão: um sistema determinístico — não um modelo generativo — que compara a trajetória prevista versus a real, e dispara ações de correção ou aborto dentro de janelas de tempo curtíssimas (milissegundos).
• Atuação: controle sobre thrust, freios autobrake, configuração de slats/flaps e yoke eletrônico via fly-by-wire.

O ponto-chave para quem é dev: nenhum desses blocos pode rodar em rede neural estocástica. A Anac exige que cada decisão seja auditável, repetível e deterministicamente testável. Aprenda isso antes de subir qualquer modelo para produção crítica.

O pipeline de certificação que a Anac está aplicando

Quando você envia um sistema de pagamento, faz deploy canário e monitora taxa de erro. A Anac exige o mesmo — só que em outro nível de rigor. O processo de certificação segue o DO-178C (nível de software) e DO-254 (hardware) com Design Assurance Level (DAL) tipicamente DAL-A para funções de decolagem, que é o mais alto: falha catastrófica = perda da aeronave.

Isso muda completamente a forma como o time da Embraer escreve código:

• Cada branch precisa de requisito rastreável.
• Cobertura estrutural exigida: MC/DC (Modified Condition/Decision Coverage) tipicamente 100% nas funções críticas.
• Zero recursão dinâmica, zero alocação dinâmica de memória em tempo de execução nas funções DAL-A.
• Toolchain qualificada — até o compilador precisa ser homologado.

Se você trabalha com sistemas médicos, fintech de alta disponibilidade ou carros autônomos (ISO 26262 ASIL-D), a sensação é familiar. Se não trabalha, eu recomendo fortemente estudar pelo menos o DO-178C capítulo 6 — é a melhor escola de defensive programming que existe.

Na Prática: modelando a malha de decisão de decolagem em código

Para visualizar o que acontece dentro do E2TS, montei abaixo um state machine simplificado em Python representando a fase de decolagem. Não é código de voo real — é didático, mostrando os pontos de verificação e gatilhos de aborto que precisam rodar em tempo real. Em produção, isso seria C/C++ com RTOS, mas a lógica é a mesma.

from enum import Enum
from dataclasses import dataclass

class TakeoffPhase(Enum):
    IDLE = "idle"
    LINEUP = "lineup"
    ROLL = "roll"
    ROTATE = "rotate"
    AIRBORNE = "airborne"
    ABORTED = "aborted"

@dataclass
class SensorSnapshot:
    speed_kts: float
    runway_remaining_m: float
    engine_thrust_pct: float
    n1_stable: bool
    wind_shear_detected: bool

class TakeoffDecisionEngine:
    V1_SPEED = 140.0   # decisão de aborto (em nós)
    VR_SPEED = 155.0   # rotação
    V2_SPEED = 160.0   # segurança após airborne
    REJECT_BEFORE_V1 = True

    def __init__(self):
        self.phase = TakeoffPhase.IDLE

    def evaluate(self, snap: SensorSnapshot) -> TakeoffPhase:
        # Fase 0 a 1: alinhamento e configuração
        if self.phase == TakeoffPhase.IDLE:
            if snap.engine_thrust_pct > 95 and snap.n1_stable:
                self.phase = TakeoffPhase.LINEUP
            return self.phase

        # Fase crítica: corrida na pista
        if self.phase == TakeoffPhase.ROLL:
            # Wind shear ou falha de motor ANTES de V1 -> aborta
            if snap.wind_shear_detected and self.REJECT_BEFORE_V1:
                self.phase = TakeoffPhase.ABORTED
                return self.phase

            # Pista acabando sem velocidade -> aborta
            if snap.runway_remaining_m < 200 and snap.speed_kts < self.V1_SPEED:
                self.phase = TakeoffPhase.ABORTED
                return self.phase

            # Velocidade de rotação atingida
            if snap.speed_kts >= self.VR_SPEED:
                self.phase = TakeoffPhase.ROTATE

        if self.phase == TakeoffPhase.ROTATE:
            self.phase = TakeoffPhase.AIRBORNE

        return self.phase

# Exemplo de simulação
engine = TakeoffDecisionEngine()
samples = [
    SensorSnapshot(0, 2400, 100, True, False),
    SensorSnapshot(80, 2100, 100, True, False),
    SensorSnapshot(130, 1600, 100, True, False),
    SensorSnapshot(150, 1600, 100, True, False),  # atinge VR
    SensorSnapshot(160, 1600, 100, True, False),
]

for s in samples:
    print(f"speed={s.speed_kts}kts runway={s.runway_remaining_m}m -> {engine.evaluate(s).value}")

Repare em três detalhes que devs juniors costumam ignorar:

1. Decisão V1 é irreversível. Depois desse ponto, mesmo com falha de motor, abortar é mais perigoso que decolar. É o mesmo princípio de “irreversible commitment” em deploys — depois do merge para main em horário de pico, rollback é mais caro do que tocar para frente.
2. Tempo é um recurso. Toda essa avaliação roda a ~50Hz em sistemas reais. Em Python, se rodasse 1x por segundo, um Airbus A380 já teria percorrido 80 metros na pista.
3. Estado é explícito. Nada de flag implícita. Nada de “se está null, assume true”. Cada transição precisa estar coberta por teste unitário com requisito rastreável.

Comparação: como o E2TS se posiciona frente ao que existe hoje

Não estou dizendo que a Embraer é melhor — estou dizendo que ela é a primeira a fechar o loop inteiro de decolagem com certificação civil. Airbus e Boeing têm décadas de know-how em fly-by-wire, mas o conservadorismo regulatório europeu e americano trava inovações desse tipo. A Anac, mais ágil, abriu espaço.

Erros Comuns que devs cometem quando tentam replicar lógica crítica

Se você está mexendo com sistemas críticos — seja carro autônomo, drone, robô industrial ou trading automatizado — evite estes pontos que vi acontecerem em código real:

• Confiar em média, não em cauda longa. Testes só com cenários “felizes”. A certificação exige cenários de falha em todos os cantos do espaço de estados. Cobertura de linha ≠ cobertura de comportamento.
• Relógio monotônico ignorado. Se você usa time.time() em vez de time.monotonic(), um NTP sync pode fazer seu loop de controle pular ou rodar duas vezes. Em voo isso é tragédia.
• Logs assíncronos em caminhos críticos. “Ah, é só um print”. Não. Em sistemas DAL-A, até um printf pode violar tempo de execução determinístico. Aprenda a usar buffer lock-free ou periféricos de telemetria separados.
• Atualizar firmware em voo. Vi startups tentando. A Anac não permite, e com razão. Updates têm que vir com plano de rollback testado e janela de tempo fora de operação.
• Assumir que o hardware não mente. Sensores falham, dão leituras congeladas (stuck-at), invertem sinal. O código de voo precisa de votação majoritária entre fontes redundantes — exatamente como Three-Node Consensus em sistemas distribuídos.

O que isso significa para a comunidade dev brasileira

O Brasil não é só consumidor de tecnologia — está gerando IP de classe mundial em automação crítica. Para devs, isso abre três frentes reais:

1. Embarque aeroespacial: Embraer, Embraer Defesa, AEL, Avibras e um ecossistema crescente em São José dos Campos contratam devs com mentalidade de safety-critical. Treine DO-178C e embedded C/C++ — é nicho e paga bem.
2. Certificação de IA: O próximo passo é usar ML para otimização de rota e consumo de combustível. Quem souber aliar modelos com garantias formais (formal verification, neurosymbolic AI) vai estar 5 anos à frente.
3. Exportação de regulação: Se a Anac homologar primeiro, empresas brasileiras podem vender “stack certificada” para os EUA e Europa com processo acelerado via CMT. É mercado de software regulado, similar a医療機器 no Japão.

FAQ — Perguntas que devs realmente fazem

1. Qual linguagem a Embraer usa no E2TS?

Predominantemente C/C++ com MISRA-C como base de codificação, rodando em RTOS (VxWorks ou INTEGRITY). Ada também é usada em sistemas legados. Python aparece só em ferramentas de simulação e HIL (Hardware-in-the-Loop), nunca no código embarcado de voo.

2. O E2TS substitui o piloto?

Não. A certificação é para decolagem automática assistida, com piloto monitorando e podendo assumir a qualquer instante. Pouso automático já existe há décadas (CAT III) e ainda assim dois pilotos seguem obrigatórios. O mesmo valerá aqui por muito tempo.

3. Posso treinar um modelo de IA para fazer isso sozinho?

Tecnicamente sim, mas regulatoriamente não. Modelos estocásticos não passam em auditoria DO-178C. O caminho moderno é usar IA em otimização offline (gerar parâmetros de decolagem ideais por aeroporto/clima) e manter o controle online determinístico.

4. Como estudar safety-critical programming?

Comece com o MISRA-C:2012 (guidelines), leia o DO-178C capítulo 6 (software considerations), e pratique com projetos de drone open-source (PX4/ArduPilot). Depois avance para ISO 26262 se quiser migrar para automotivo.

5. Isso é relevante para web devs?

Diretamente não, mas o mindset é. Web moderna lida com idempotência, retries, fallbacks. Tudo que aviação faz há 50 anos. Quando você implementa um sistema de pagamento que não pode cobrar duas vezes, está aplicando a mesma lógica de “decisão irreversível antes do V1”.

Se você chegou até aqui, já tem mais contexto que 90% das matérias que vi circulando por aí. A Embraer está fazendo história técnica — e devs brasileiros que entenderem o movimento agora vão surfar a próxima década de sistemas críticos made in Brazil.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.