Simulação de eventos discretos do eVTOL alimentador do hub (integração a voo convencional de partida rígida) — processo BPMN 2.0, parâmetros estocásticos e plano de experimentos.
Enunciado do problema simulado — o eVTOL como alimentador do hub:
do pouso no vertiporto à chegada ao TPAX, contra o relógio do voo convencional.
Enunciado
A integração ao hub, do pouso à chegada ao TPAX — contra um relógio rígido
O Cenário 04 representa o eVTOL como alimentador (feeder) do
aeroporto de São José dos Campos (SBSJ): dois voos eVTOL pousam no
vertiporto do outro lado da pista — planejados às
07:15 e 08:20, quatro passageiros cada — e os
oito passageiros precisam se integrar a um voo convencional da
companhia aérea. Escopo simulado: a jornada vai do pouso à
chegada ao TPAX (estado ENTREGUE_TPAX); o
processo convencional a partir do check-in não é simulado — o
check-in convencional é premissa documental e fundamenta a
antecedência recomendada de 1h30. Relógio de referência:
partida do VC1 às 10:15, encerramento da aceitação às
09:45 (chegada ao TPAX até lá) e deadline de antecedência às
08:45. O simulador é um motor de eventos discretos
reproduzível por seed.
A jornada começa no pouso do alimentador (desvio Normal de
±120 s, vertipad único). Após o desembarque
sequencial (60 s por pessoa), o eVTOL recarrega e decola de
retorno sem passageiros — a recarga não trava ninguém, mas ocupa o pad
por cerca de 44 ± 10 min (desembarque + resfriamento + recarga); por isso os
pousos são espaçados de 65 min: um acoplamento entre voos por
recurso, não por fila.
Aqui a travessia de pista acontece na chegada e é
consolidada: a van de apoio (capacidade 4, uma
viagem por voo) leva os passageiros do vertiporto ao terminal numa única etapa
travessia_chegada LN(300, 120) s por viagem — precedida do embarque na
van, etapa própria de 60 s por pessoa (os boxes T03–T05/G01 no BPMN documentam a
topologia). A chegada ao TPAX encerra a jornada simulada: o
passageiro é ENTREGUE ao TPAX — o check-in
convencional segue como premissa documental, fora do escopo simulado.
O que o estudo mede é a antecedência de 1h30: para
cada passageiro registra-se a chegada ao TPAX (fim da travessia) e
compara-se com o deadline (partida − 1h30 = 08:45). A
folga de antecedência e a taxa de conformidade são
as KPIs centrais — é métrica, não regra dura: ninguém é cancelado por antecedência.
A única perda simulada é a conexão perdida (sem chegada ao TPAX
até o encerramento da aceitação, 09:45).
Não há atraso de partida nem folga no gate a medir: o processo convencional a
partir do check-in está fora de escopo. As perguntas são outras — quanta
antecedência a programação dos alimentadores garante, e onde a margem
quebra primeiro: na travessia, no embarque da van, no acoplamento do pad (a recarga
do V1 empurra o pouso do V2) ou no atraso de quem chega.
Premissa de identidade · invariante
O que define este cenário — e não pode ser alterado
O sandbox mantém cenários complementares com identidades fixadas: o
Cenário 04 é a integração eVTOL → voo
convencional — o eVTOL alimenta o hub e a jornada simulada vai do pouso
à chegada ao TPAX (estado ENTREGUE_TPAX); o processo convencional,
do check-in em diante, está fora do escopo simulado. As identidades vizinhas: C01 =
aeroporto integrado com canal ARS; C02 = terminal dedicado sem canal expresso;
C03 = conexão UAM com custódia e turnaround. Sob a mesma infraestrutura de sítio
(vertipad único, recarga, travessia de pista), cada cenário isola uma política
de facilitação distinta.
Regra de desenho experimental: nenhum experimento altera a
identidade do cenário — aqui no C04 varia-se o embarque na van
(E02: 60 → 180 s), a travessia consolidada (E03: 300 → 480 s), a
recarga (E04: 1800 → 2700 s, acoplamento do pad) e o atraso do
alimentador (E05: N(0, 120) → N(300, 180)).
Saídas do modelo
O que cada execução mede
Cada réplica produz a folga de antecedência de cada passageiro
(deadline − chegada ao TPAX, média e mínima), a taxa de antecedência
conforme, o tempo pouso → chegada ao TPAX (pouso efetivo →
ENTREGUE_TPAX), a espera do embarque na van, a utilização da van e do
vertipad e a taxa de
perda de conexão — com a contabilidade fechada dos oito
passageiros (entregues + conexões perdidas = 8) e a
seed registrada para auditoria. O detalhamento está nas demais abas: o processo
em Processo (BPMN) e Fluxograma, a
correspondência nó-a-nó em Rastreabilidade, e os modelos em
Modelagem e Distribuições.
Plano de experimentos do Cenário 04 — as variações testadas sobre a operação
nominal, as perguntas que respondem, os parâmetros estimados e a estratégia
de validação das premissas.
Desenho experimental
Cinco experimentos, cinco perguntas
Todos os experimentos rodam dentro do Cenário 04 — mesmo papel
de alimentador do hub, mesmo processo BPMN, mesmo motor e mesma população. O que
varia é uma premissa operacional por vez, declarada como overlay
YAML (experimentos/C04-E0X.yaml). Cada cenário do sandbox é isolado:
C01, C02 e C03 têm seus próprios painéis e planos de experimentos.
Experimento
Variação sobre o nominal
Pergunta que responde
C04-E01
Baseline — parâmetros nominais, sem alterações
Qual a folga de antecedência e o tempo pouso → chegada ao TPAX de referência?
C04-E02
Van lenta: embarque na van 60 s → 180 s
A fricção do embarque na van de chegada corrói a antecedência?
C04-E03
Travessia degradada: travessia consolidada 300 s → 480 s
A travessia lenta atrasa a chegada ao TPAX contra o deadline?
C04-E04
Recarga lenta: 1800 s → 2700 s — acoplamento via pad
O acoplamento via pad (recarga do V1 atrasa o pouso do V2) degrada a antecedência?
O atraso de quem chega destrói a antecedência (e gera perda de conexão)?
Parâmetros estimados
O que as réplicas Monte Carlo produzem
Cada experimento é executado em réplicas independentes (seeds distintas), gerando
estimativas com intervalo de confiança de 95%:
Folga de antecedência (média e mínima) e taxa de antecedência conforme — a KPI central.
Tempo pouso → chegada ao TPAX por passageiro (pouso efetivo → ENTREGUE_TPAX): média, mediana e p95.
Tempo e comprimento de fila do embarque na van.
Utilização dos recursos: van de apoio e vertipad (acoplamento do pad).
Taxa de perda de conexão (chegada ao TPAX após o encerramento da aceitação, 09:45).
Validação das premissas
Consulta a especialistas e análises estatísticas
Não há, nesta fase, dados de campo de operação eVTOL no Brasil — portanto a
validação estatística contra dados observados está descartada por
construção. A validação das premissas será feita por consulta
estruturada a especialistas (validade de face): profissionais de
facilitação, segurança da aviação e operações airside examinam tempos,
probabilidades e regras adotadas, e cada parâmetro é referendado ou ajustado
a partir desse parecer.
Os testes estatísticos aplicam-se ao que a simulação de fato produz — a
comparação entre as saídas simuladas dos experimentos, que não
requer dados de campo:
Comparação entre experimentos (t pareado por seed / Wilcoxon — CRN, com FDR de Benjamini–Hochberg): a premissa alterada muda o tempo pouso → chegada ao TPAX ou a folga de antecedência — por exemplo, E05 (pouso atrasado) × E01 (baseline)?
Efeito global (Friedman, bloqueado por seed): os cinco experimentos produzem distribuições de tempo estatisticamente distintas?
Verificação interna: a taxa simulada de perda de conexão e a contabilidade dos 8 passageiros (entregues + conexões perdidas = 8) reproduzem as regras parametrizadas? (verificação do motor, não validação do modelo).
Convergência: estabilidade dos estimadores com o número de réplicas (semilargura do intervalo de confiança como critério de parada).
Quando houver dados de campo, testes de aderência (Kolmogorov–Smirnov /
qui-quadrado) serão incorporados ao plano. Até lá, o parecer dos especialistas
é o que realimenta a calibração dos parâmetros — mantendo modelo e evidência
em ciclo fechado.
Resultados das réplicas Monte Carlo dos experimentos C04-E01…E05 —
tabelas com IC 95%, convergência por variável e testes de hipótese.
Como executar
Reproduzindo os experimentos
Com o venv do projeto ativo, a partir de
simulador/cenario_04/experimentos/:
python cenario_04_experimentos.py --list # lista os experimentos
python cenario_04_experimentos.py C04-E03 -n 500 # um experimento, 500 réplicas
python cenario_04_experimentos.py --all -n 1000 # todos + testes de hipótese
python cenario_04_gerar_resultados.py # regenera esta aba
Cada experimento é um overlay declarativo (C04-E0X.yaml) sobre os
parâmetros nominais — criar um experimento novo é escrever um YAML, sem tocar em
código. A réplica i usa a seed seed_base + i, então toda
rodada é integralmente reproduzível. As saídas numéricas ficam em CSV em
experimentos/resultados/.
92%
Visão integral do BPMN canônico (Fit) — todo o processo em uma tela. Use Ler para ampliar e arraste para navegar.
LADO AR / CHEGADA · VAN · TRAVESSIA
TPAX PÚBLICA (CHEGADA AO TPAX · CHECK-IN COMO PREMISSA)
TPAX RESTRITA (fora do escopo simulado — vazia)
Fluxograma executivo derivado do mesmo conteúdo do BPMN canônico, com layout otimizado para leitura e interpretação do processo.
100%
Chegada eVTOLVan / travessiaTPAX pública
Catálogo dos códigos renderizados no BPMN, IDs oficiais do XML e associação com as etapas do motor de eventos discretos (cenario_04_motor.py). São 9 nós, 9 fluxos e 3 raias: a raia TPAX Restrita é mantida vazia (a área restrita está fora do escopo simulado) e o check-in convencional (T06) é box documentacional. Regras transversais não representadas como nós: encerramento da aceitação (chegada ao TPAX até 09:45) e partida de referência (10:15, close_rule) do voo convencional, antecedência de 1h30 como métrica (deadline 08:45), pad exclusivo com recarga de retorno e travessia de chegada consolidada.
Nós: 0Fluxos: 0Etapas mapeadas: 0
Fonte: cenario_04_bpmn_draw.bpmn e cenario_04_motor.py
Blocos renderizados
Código oficial por nó BPMN
Código
ID BPMN oficial
Tipo
Raia
Nome renderizado
Etapa estatística
Modelo estatístico
Status
Conectores
IDs oficiais dos fluxos BPMN
ID fluxo
Origem
Destino
Rótulo
Cartões na ordem do fluxo: nós BPMN modelados, estados determinísticos
e modelo operacional do eVTOL usado pelo motor.
Fonte: cenario_04_parametros_est.yaml.
Playback visual 2D em Canvas inspirado na camada Pygame original do simulador.
A visualização é didática: não altera YAML, runs salvas ou métricas do motor.