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.

ExperimentoVariação sobre o nominalPergunta 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?
C04-E05 Pouso atrasado: desvio N(0, 120) → N(300, 180) — alimentadores tardios 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 eVTOL Van / travessia TPAX 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: 0 Fluxos: 0 Etapas 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.