Quando li essa notícia no Olhar Digital sobre os testes com táxis aéreos elétricos no Texas, a primeira coisa que pensei não foi “uau, carros voadores”. Foi: isso é, antes de tudo, um problema de software com consequências físicas. E a forma como os EUA estão regulando (ou deixando de regular) antes mesmo das regras saírem diz muito sobre o momento que estamos vivendo na engenharia de sistemas críticos.
O que está realmente acontecendo no Texas
Desde quinta-feira (10), o Texas sediou a primeira rodada pública de testes com três fabricantes de eVTOL — Joby, Beta e Wisk. O programa é federal, tocado pela Casa Branca em conjunto com a FAA, e selecionou oito projetos estaduais ainda no início do ano. Esses voos de uma semana não levam passageiros. O objetivo é mostrar que as aeronaves conseguem operar no espaço aéreo real, integradas ao sistema de controle de tráfego aéreo texano, com rotas ligando cidades e aeroportos regionais — incluindo o DFW.
O detalhe que pouca gente comenta: as fabricantes precisam provar ao governo que seus modelos estão aptos a receber a certificação de tipo. Sem ela, ninguém decola comercialmente com passageiro pago. É aqui que a coisa fica interessante para quem programa sistemas embarcados, IoT crítico ou qualquer coisa com implicação em safety.
Por que isso importa para quem programa
Na minha experiência, a maioria dos devs olha para aviação autônoma como se fosse “um Uber com hélices”. Não é. Estamos falando de sistemas onde um bug de software mata gente. A comparação que costumo fazer é com carros autônomos da Waymo ou Tesla FSD: mesmo no chão, com redundância física, ainda temos notícias semanais de falhas. Agora imagine subir isso a 300 metros de altitude, com 4G/5G intermitente e zero margem para erro.
Para nós, da engenharia de software, três pontos merecem atenção:
- Certificação de software embarcado: qualquer linha de código que roda nesses veículos precisa seguir padrões como DO-178C (nível de design assurance). Isso muda completamente a forma como você escreve, testa e documenta software — esqueça o “vai que funciona”.
- Integração com ATC (Air Traffic Control): o teste texano existe justamente para ver como o sistema atual lida com mais densidade de tráfego. APIs legadas, latência, fallback procedures. Problemas clássicos de integração corporativa, só que com aviões.
- Telemetria e gêmeos digitais: toda essa operação depende de simulação massiva antes do voo real. Quem trabalha com digital twins em chão de fábrica sabe do que estou falando — agora multiplique por 1.000 em termos de risco.
A pilha tecnológica por trás de um eVTOL
Quando você olha o stack de uma empresa como a Joby ou a Wisk, percebe que a “aeronave” é só a parte visível. Por baixo tem:
- Firmware de controle de voo rodando em MCUs redundantes (geralmente triplex, com votaçãomajoritária entre três canais independentes).
- Planejador de missão que decide rota, altitude e consumo em tempo real, parecido com o que vemos em solvers de roteirização (OR-Tools, Gurobi), mas com física de aerodinâmica no meio.
- Comunicação com ATC usando protocolos como CPDLC (Controller-Pilot Data Link Communications) e ADS-B — pense neles como o “HTTP da aviação”, só que com décadas de legacy.
- Sistemas de monitoramento de bateria com thermal runaway prediction, que nada mais é do que um modelo de ML rodando em tempo real com tolerância zero a falso negativo.
A parte chata — e que devs odeiam — é que cada um desses subsistemas precisa ser certificável. Isso significa: rastreabilidade de requisitos, cobertura de teste formal, análise de código estático rigorosa e processo documentado. Não tem “deploy em sexta”.
Na Prática — simulando lógica de voo com Python
Não dá pra decolar um eVTOL no seu notebook, mas dá pra brincar com a lógica de decisão que esses sistemas usam. Um planejador de missão básico, com priorização de portos de pouso e consumo de bateria, ficaria mais ou menos assim:
from dataclasses import dataclass
from heapq import heappush, heappop
@dataclass
class Vertiport:
name: str
lat: float
lon: float
has_charger: bool
@dataclass
class Aircraft:
battery_pct: float # 0 a 100
consumption_per_km: float # % de bateria por km
def haversine_km(a: Vertiport, b: Vertiport) -> float:
from math import radians, sin, cos, asin, sqrt
R = 6371.0
lat1, lon1, lat2, lon2 = map(radians, [a.lat, a.lon, b.lat, b.lon])
dlat, dlon = lat2 - lat1, lon2 - lon1
h = sin(dlat/2)**2 + cos(lat1) * cos(lat2) * sin(dlon/2)**2
return 2 * R * asin(sqrt(h))
def plan_route(origin: Vertiport, destinations: list[Vertiport],
aircraft: Aircraft, reserve_pct: float = 15.0):
"""Retorna a rota mais barata em bateria respeitando margem de segurança."""
queue = [(0.0, origin, [origin.name])] # (custo, vertiport, path)
best = None
while queue:
cost, current, path = heappop(queue)
if cost > aircraft.battery_pct - reserve_pct:
continue
if current != origin and current.has_charger:
cost = max(0, cost - 40) # recarga parcial no vertiporto
if not destinations:
best = (cost, path)
continue
for d in destinations:
if d.name in path:
continue
leg = haversine_km(current, d) * aircraft.consumption_per_km
heappush(queue, (cost + leg, d, path + [d.name]))
return best
# Exemplo simples
dfw = Vertiport("DFW", 32.8998, -97.0403, has_charger=True)
austin = Vertiport("Austin-Bergstrom", 30.1945, -97.6699, has_charger=True)
houston = Vertiport("Houston Hobby", 29.6459, -95.2789, has_charger=False)
aircraft = Aircraft(battery_pct=85.0, consumption_per_km=0.25)
print(plan_route(dfw, [austin, houston], aircraft))
Esse é um toy problem — não voa nada de verdade. Mas o ponto pedagógico é importante: o planejador precisa respeitar a margem de segurança (15% de bateria reserva), priorizar vertiports com carregador e nunca aceitar uma rota que exceda o orçamento energético. Em produção, esse mesmo “raciocínio” tem que considerar vento, temperatura, tráfego aéreo e falhas de motor. Tudo em tempo real. Tudo determinístico.
Erros comuns que devs cometem quando olham para eVTOL
Já vi muita gente cometendo essas confusões em fóruns, Twitter e LinkedIn. Anota aí:
- Confundir eVTOL com drone de entrega. São categorias regulatórias completamente diferentes. Um DJI Mavic é hobby; um Joby S4 é aeronave certificada com type rating.
- Achar que “autônomo” significa “sem piloto”. Nos primeiros anos, esses veículos vão voar com piloto a bordo ou sob comando remoto supervisionado. Autonomia plena em espaço aéreo compartilhado ainda é ficção regulatória.
- Ignorar a parte de infraestrutura urbana. Vertiports (os “estacionamentos” verticais) precisam de aprovação municipal, reforço estrutural nos edifícios, sistemas contra incêndio específicos para baterias de lítio e integração com helipontos existentes. Nada disso é software, mas tudo isso atrasa o software.
- Subestimar a latência da rede. 5G atual em zona urbana não cobre cenário aéreo com a mesma densidade. O link de comando C2 (Command and Control) precisa de fallback via satélite ou link próprio — o que adiciona mais uma camada de complexidade.
- Tratar certificação como “burocracia”. Não é. É engenharia de processo. Quem trabalha em medical devices (FDA) ou automotivo (ISO 26262) já entende. Quem vem só de web/mobile vai chorar.
Comparação com alternativas reais
Se o seu objetivo é mobilidade urbana eficiente, eVTOL não é a única promessa. Coloco lado a lado o que existe ou está próximo de existir:
- Carros elétricos autônomos (Waymo, Cruise, Tesla): já rodam em escala limitada. Mais maduros, mais baratos de escalar, mas presos ao trânsito e ao plano 2D.
- Trem de alta velocidade / maglev: para distâncias de 200–800 km, ganha em quase tudo: energia por passageiro, segurança, custo de infraestrutura por km. Só não resolve a última milha.
- Helicópteros elétricos (ex.: Airbus CityAirbus): tecnologia mais tradicional, sem decolagem vertical pura, mas com cadeia regulatória mais simples e menos barulho relativo.
- Drones logísticos (Zipline, Wing): Já operam comercialmente em alguns países. Menor risco porque não carregam pessoas, mas mesmo assim esbarram em regras rígidas de BVLOS (Beyond Visual Line of Sight).
Para o programador brasileiro, a lição honesta é: táxi aéreo elétrico é legal no PowerPoint, mas a chance de você pegar um em São Paulo antes de 2035 é baixa. Mais útil é acompanhar como a regulação evolui, porque o mesmo framework (DO-178C, SOTIF, ISO 21448) vai chegar aos carros que você programa.
O que observar nos próximos 12 meses
Se você quer acompanhar esse mercado com olhar de dev, foque em três coisas:
- Part 135 e Part 108 da FAA: as regras que vão definir operação comercial de eVTOL e BVLOS respectivamente. Sai ainda em 2026.
- Joby, Archer e Beta Technologies: os relatórios trimestrais dessas três mostram não só caixa, mas roadmap de certificação — que é o que de fato importa.
- Acidentes e incidentes: a FAA publica relatório de cada ocorrência. Vale ler como quem analisa post-mortem de incidente em produção. Toda falha é didática.
FAQ — perguntas que devs reais fariam
1. Qual linguagem de programação é usada no software de voo de um eVTOL?
A maioria mistura C/C++ no firmware crítico (controle de motores, flight control), Python ou MATLAB/Simulink para simulação e geração de código certificado, e algumas camadas em Rust crescendo (pela segurança de memória). Ada ainda aparece em sistemas legados da Airbus e Boeing, mas é raro em startups.
2. Como funciona a certificação de software em uma aeronave?
Segue o DO-178C, que define níveis de criticalidade (A até E). Software de controle de voo é nível A — o mais alto — exigindo cobertura estrutural de 100% das instruções, decisões e condições modificadas, além de revisão por pares e análise de dados/fluxo de controle.
3. Um eVTOL pode ser hackeado?
Teoricamente, sim. Existem pesquisas acadêmicas sobre spoofing de GPS, jamming de rádio e ataques à cadeia de suprimentos de firmware. Setor trabalha com criptografia AES-256 nos links C2, módulos HSM a bordo e assinaturas digitais de firmware — mas o ataque zero-day sempre é uma ameaça real.
4. Quando esses veículos vão operar comercialmente nos EUA?
Joby e Archer falam em 2025–2026 para rotas limitadas (geralmente aeroporto ↔ cidade). Operação ampla depende do Part 135 + certificação de tipo finalizada. Expectativa realista: serviço comercial incipiente em 2026, escalável só depois de 2028.
5. Tem trabalho para dev nisso?
Tem, e vai ter mais. As fabricantes contratam engenheiros de software de simulação, perception, GNC (Guidance, Navigation and Control), DevSecOps para pipelines certificados e integradores de sistemas. Portais como jobs.jobyaviation.com e archer.com/careers são o melhor lugar para começar.
Se você está construindo sistemas embarcados, IoT crítico ou apenas curioso sobre o futuro da mobilidade, esse é um daqueles temas onde o hype jornalístico esconde um problema de engenharia fascinante. Vale acompanhar de perto.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.