TMS-10: como devs simulam um avião supersônico na prática

Vi essa notícia no Sapo.pt e confesso que minha primeira reação não foi “uau, que legal” — foi pensar no absurdo computacional que está por trás desse projeto. Reduzir um voo de duas horas para 30 minutos voando a Mach 2 não é só um feito de engenharia aeronáutica. É um problema massivo de simulação, dinâmica de fluidos computacional (CFD), modelagem de materiais e otimização multiobjetivo que roda em supercomputadores por meses a fio. E como dev, isso me interessa mais do que o próprio avião.

Por que o TMS-10 me chamou atenção (e o que ele significa pra quem trabalha com tech)

O demonstrador TMS-10, desenvolvido pelo Laboratório Tianmushan com apoio da Universidade Beihang, está na fase final de montagem com voo de teste previsto até o final de 2026. Um modelo em escala 1:18 já voou em junho de 2025 a velocidades abaixo de Mach 0,2, validando descolagem, aterragem, estabilidade e controlo. Parece pouco? Não é. Cada um desses ensaios gera terabytes de dados de telemetria que precisam ser processados em tempo real.

A ambição é concreta: uma aeronave executiva para 10 a 15 passageiros, cruzeiro a Mach 2 e operação subsónica a Mach 0,95. Isso é o dobro da velocidade do som. Para colocar em perspectiva, o Concorde operava a Mach 2,02 — então tecnicamente estamos falando de recuperar uma capacidade que existiu e foi abandonada por questões económicas e de regulamentação sónica.

O verdadeiro desafio não é voar rápido — é voar rápido sem matar o ruído

O grande trunfo do projeto chinês está no foco em reduzir o estrondo sónico. Desde 1973, os EUA proíbem voo supersónico civil sobre território continental por causa do sonic boom. A NASA vem investindo pesado no X-59 QueSST justamente para demonstrar que é possível voar a Mach 1,4 com um “thump” de 75 dB em vez de um estrondo de 130 dB.

Como dev, penso imediatamente nos algoritmos de otimização topológica que estão sendo usados para redesenhar o nariz e a fuselagem. Estamos falando de:

• Simulações CFD com malhas de centenas de milhões de células rodando em clusters GPU
• Otimização por algoritmos genéticos para encontrar geometrias que minimizem ondas de choque
• Modelos de ordem reduzida (ROM) que aproximam soluções de Navier-Stokes em tempo quase real
• Digital twins sincronizados com dados de telemetria para prever fadiga estrutural

Na Prática: o pipeline computacional por trás de um avião supersónico

Quero mostrar como isso funciona na cabeça de quem programa. Quando a Universidade Beihang testa uma nova geometria de bico supersónico, o pipeline mais ou menos segue este fluxo:

1. Geração paramétrica da geometria — geralmente em OpenVSP, SU2 ou scripts Python com CadQuery
2. Malha CFD — usando Pointwise, Gmsh ou ICEM, com refinamento adaptativo na região da onda de choque
3. Solução numérica — solver RANS ou LES rodando em CUDA (OpenFOAM com petsc-cuda, ou ANSYS Fluent)
4. Pós-processamento — visualização em ParaView, cálculo de coeficientes aerodinâmicos
5. Otimização iterativa — loop que testa centenas de variantes até convergir

Um exemplo simples de como automatizar a avaliação de uma geometria via Python, integrando com um solver open-source:

import subprocess
import numpy as np
from pathlib import Path

class SupersonicEvaluator:
    """Pipeline simplificado para avaliar uma geometria de nariz supersónico."""

    def __init__(self, mach_cruise=2.0, altitude_m=15000):
        self.mach = mach_cruise
        self.altitude = altitude_m
        self.results = []

    def generate_geometry(self, nose_angle_deg, length_ratio):
        """Parametriza a geometria do nariz em formato SU2."""
        geo_template = f"""
        NPOINT = 17
        NMARK = 2
        MARKER_TAG= airfoil
        MARKER_ELEMENTS= 16
        (0.0, 0.0, 0.0)
        (1.0, {np.tan(np.radians(nose_angle_deg)):.4f}, 0.0)
        ({length_ratio:.2f}, 0.0, 0.0)
        """
        return geo_template

    def run_cfd(self, geometry_file):
        """Executa o solver SU2 — em produção, isso roda em cluster."""
        cmd = [
            "SU2_CFD",
            geometry_file,
            "-t", "8",  # 8 cores
            "--silent"
        ]
        result = subprocess.run(cmd, capture_output=True, text=True)
        return self._parse_output(result.stdout)

    def _parse_output(self, output):
        """Extrai coeficiente de arrasto e onda de choque do output."""
        drag = float([l for l in output.split("\n")
                      if "CD" in l and "|" in l][0].split("|")[2].strip())
        shock_strength = float([l for l in output.split("\n")
                               if "SHOCK" in l.upper()][0].split("=")[1])
        return {"drag": drag, "shock": shock_strength}

    def optimize(self, generations=20):
        """Loop de otimização evolutiva — bem simplificado."""
        for gen in range(generations):
            # Amostra candidatos
            candidates = [
                {"angle": np.random.uniform(5, 25),
                 "ratio": np.random.uniform(0.3, 1.5)}
                for _ in range(10)
            ]
            for c in candidates:
                geo = self.generate_geometry(c["angle"], c["ratio"])
                metrics = self.run_cfd("candidate.su2")
                # Minimiza drag + penalidade por onda de choque forte
                fitness = metrics["drag"] + 0.3 * metrics["shock"]
                self.results.append({**c, **metrics, "fitness": fitness})
            print(f"Geração {gen}: melhor fitness = "
                  f"{min(r['fitness'] for r in self.results[-10:]):.4f}")
        return min(self.results, key=lambda x: x["fitness"])

if __name__ == "__main__":
    evaluator = SupersonicEvaluator(mach_cruise=2.0)
    best = evaluator.optimize(generations=5)
    print(f"Melhor geometria: {best}")

Esse código é didático, mas o pipeline real é ordens de magnitude mais complexo. Uma única simulação LES de nariz supersónico pode consumir 50.000 core-hours. Quando você roda otimização com 500 variantes por geração, são milhões de core-hours por campanha. É por isso que empresas como a Boom Supersonic têm times inteiros só de engenheiros de software e HPC.

Comparação: TMS-10 vs. Concorrentes reais

Repare: o TMS-10 não está competindo em capacidade, mas em silêncio. É uma jogada estratégica inteligente. Se eles conseguirem um perfil acústico que permita operação supersónica sobrevoando áreas povoadas, abrem um mercado que a Boeing e Airbus simplesmente não conseguem atender hoje.

Erros comuns que devs cometem ao falar de aviação (e que me irritam profundamente)

Como vejo muita bobagem sendo compartilhada em LinkedIn e Twitter sobre aviação, deixa eu listar o que mais incomoda:

• Confundir Mach com velocidade absoluta. Mach 2 a 15 km de altitude não é 2.450 km/h em qualquer condição. A velocidade do som varia com temperatura: é ~1.060 km/h ao nível do mar, mas ~1.062 km/h em altitude padrão. Pequena diferença, mas existe.
• Achar que “supersónico é só aerodinâmica”. O maior gargalo do Concorde não foi a aerodinâmica — foi o aquecimento aerodinâmico. A fuselagem chegava a 127 °C em cruzeiro, o que limitava materiais e reduzia a vida útil.
• Ignorar regulamentação sónica. Não adianta ter a tecnologia se a ICAO/FAA/EASA não liberar operação comercial supersónica sobrevoando terra. Por isso o foco em ruído é tão crítico.
• Subestimar o impacto do software. Sem software moderno, esses aviões não saem do papel. Sistemas fly-by-wire, controle de voo digital, integração contínua entre simulações — tudo isso é engenharia de software.
• Tratar CFD como caixa-preta. Muitos devs rodam ANSYS sem entender a malha. Uma malha mal feita em região de choque gera resultados otimistas. Sempre valide com dados experimentais.

Implicações práticas para quem trabalha com tech

Se você é dev e trabalha em time distribuído, aviões supersónicos mudam sua vida. Hoje, ir de São Paulo a Berlim leva ~12h. Se isso virar 2h, a barreira geográfica para conferências, meetups presenciais e trabalho presencial temporário praticamente desaparece. Times distribuídos entre América e Ásia ganham muito.

E há demanda crescente por devs com perfil aeroespacial: Python + CFD, Rust para sistemas embarcados críticos, C++ para solvers numéricos, e sim, muito ML aplicado a otimização aerodinâmica. É um nicho bem pago e com pouca concorrência qualificada.

FAQ — Perguntas que devs realmente fazem sobre isso

1. O TMS-10 realmente vai entrar em operação comercial?

Provavelmente não até 2035. O demonstrador é só o começo. Após o voo de teste, vêm anos de certificação, desenvolvimento da versão de produção e validação de mercado. Mas a tecnologia validada pode virar produto real.

2. Por que o Concorde foi descontinuado se era viável tecnicamente?

Viável tecnicamente, inviável economicamente. O custo por passageiro era altíssimo, o ruído restringia rotas, o consumo de combustível era brutal, e o acidente de 2000 (Air France 4590) matou o programa de vez. A nova geração precisa resolver esses quatro problemas.

3. Como o ruído supersónico é simulado computacionalmente?

Equações de Burgers não-lineares para propagação de ondas de choque, acopladas a modelos de propagação atmosférica. Softwares como o sBOOM e PCBoom3 da NASA são referência. Os chineses provavelmente usam soluções proprietárias baseadas em métodos de diferenças finitas de alta ordem.

4. Existe código aberto para simulação supersónica?

Sim. SU2 (Stanford University Unstructured) é o mais usado em acadêmia e tem suporte a fluxos compressíveis. OpenFOAM também resolve, mas é mais verboso. Para análise modal e flutter, pyNastran é excelente.

5. Vale a pena entrar na área aeroespacial como dev?

Na minha experiência, vale se você gosta de problemas físicos reais e aceita o ritmo lento do setor. A barreira de entrada é alta (precisa entender mecânica dos fluidos pelo menos no nível introdutório), mas a remuneração e o impacto compensam. Comece estudando CFD com SU2 ou pelo curso “Computational Fluid Dynamics” do MIT OCW.

O que ninguém está dizendo sobre essa corrida

A verdadeira competição não é entre China, EUA e Europa por fazer o avião mais rápido. É por construir o pipeline de simulação mais eficiente. Quem conseguir rodar otimização multiobjetivo com IA de forma robusta, validada e certificada vai dominar o mercado aeroespacial das próximas décadas. E isso é, antes de tudo, um problema de software.

Enquanto isso, vou ficar de olho no voo de teste do TMS-10. Se eles conseguirem um sonic boom abaixo de 80 dB em cruzeiro supersónico, o jogo muda completamente. E como dev, é impossível não torcer por quem está atacando o problema do ruído de frente — é a mesma mentalidade que a gente usa pra otimizar consultas SQL: a velocidade bruta importa menos quando o gargalo está no overhead.

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