a34ed6b340
- C1 alterado: z[nid] <= 1 -> z[nid] == 1 para todas as missoes; toda missao deve ser coberta por exatamente 1 aeronave (sem missoes descobertas). - n_missoes padrao reduzido de 50 para 20 (n_evam de 5 para 4): garante factibilidade do MIP com Set Partitioning no envelope de 4 aeronaves. - Time limit padrao do solver CBC fixado em 120 s (era ilimitado): evita travamento ao tentar provar infeasibility. - Corrigido display "Not Solved": status de L1 preservado quando PuLP redefine mdl.status apos setObjective() em L2. - f0_cenario_insp_grande.json revisado: apenas 2803 com f0=595h em INSP 2A (F_max=600h, downtime=4 dias); demais matriculas com f0=0. - Gerado planejamento_insp_grande.html: Gantt exibe INSP 2A visivelmente; 20/20 missoes cobertas; CBC Optimal em < 15 s. - changelog.md e LOG.md atualizados com limitacoes detalhadas para contribuidores: escopo validado, bugs de display, riscos numericos do big-M com LRT < 5h e comportamento de 2811 ociosa. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
227 lines
12 KiB
Markdown
227 lines
12 KiB
Markdown
# Changelog
|
||
|
||
Todas as versões significativas do Arara OAMRP devem ser registradas aqui. O `LOG.md` guarda o diário operacional detalhado; este arquivo resume mudanças por versão.
|
||
|
||
Formato:
|
||
|
||
```text
|
||
## v<versão> — <Autor ou tag> — <YYYY-MM>
|
||
|
||
### Adicionado / Alterado / Corrigido / Removido
|
||
|
||
- Descrição objetiva.
|
||
```
|
||
|
||
---
|
||
|
||
## v0.10 — VTO — 2026-06
|
||
|
||
### Alterado
|
||
|
||
- **Set Covering → Set Partitioning (C1):** a restrição de cobertura de missões foi alterada de `Σ_k y_entrada ≤ 1` (Set Covering — missão opcional) para `Σ_k y_entrada = 1` (Set Partitioning — toda missão obrigatória). Isso reflete a premissa operacional de que cada missão deve ser realizada por exatamente uma aeronave, sem possibilidade de missões descobertas. A distinção anterior entre missões "hard" (EVAM) e "opcionais" foi eliminada.
|
||
- **Número padrão de missões sintéticas reduzido de 50 para 20** (`--n-missoes`, `n_evam` de 5 para 4): Set Partitioning é mais restritivo e, com janelas de tempo fixas e restrições de inspeção simultâneas, 50 missões tornavam o MIP difícil de resolver ou inviável. Com 20 missões, a factibilidade é garantida na margem operacional de 4 aeronaves.
|
||
- **Time limit padrão do solver CBC fixado em 120 s** (era ilimitado). O solver agora nunca trava indefinidamente; retorna a melhor solução encontrada dentro do prazo. O CLI mantém `--time-limit` para ajuste.
|
||
- **Correção de display do status do solver:** PuLP redefinía `mdl.status` para "Not Solved" ao reutilizar o modelo em L2 (após `setObjective`). O status de L1 é agora preservado quando L2 reporta 0, evitando exibição enganosa.
|
||
- **Cenário `f0_cenario_insp_grande.json` revisado:** apenas a matrícula 2803 recebe `f0=595h` para INSP 2A (F_max=600h, downtime=4 dias), forçando a inspeção aparecer no Gantt. As demais matrículas partem com `f0=0` (plena disponibilidade), evitando que o problema se torne inviável por múltiplos relógios apertados simultaneamente.
|
||
|
||
### Adicionado
|
||
|
||
- `db/processed/planejamento_insp_grande.html`: visualização Gantt + mapa + tabela para o cenário com inspeção de 4 dias (INSP 2A — INSP CHECK 2A, 96 h de solo).
|
||
|
||
### Limitações conhecidas (para contribuidores)
|
||
|
||
1. **Escopo validado restrito:** Set Partitioning foi validado apenas para o cenário sintético com 20 missões, seed 42, 4 aeronaves e somente uma matrícula (2803) com LRT apertado. Fora desse envelope, o MIP pode ser infeasible ou ultrapassar o time limit sem solução.
|
||
2. **Missões sintéticas incluem bases fora da Amazônia** (SBBR, SBGL, SBYS etc.) geradas aleatoriamente pelo seed. Para estudos de caso realistas, o gerador deve ser restrito ao conjunto de bases do Esquadrão Arara.
|
||
3. **Folga negativa no relatório:** quando uma aeronave realiza inspeção dentro do horizonte, o campo `folga` exibido (`LRT_ini − horas_celula_total`) pode ser negativo porque não desconta o reset do relógio pós-inspeção. Isso é um bug de display; a restrição `H ≤ F_max` está correta no modelo.
|
||
4. **LRT muito curto (< 5 h) pode gerar instabilidade numérica no big-M:** o cenário foi configurado com LRT_ini=5 h para 2803, que está próximo do limiar onde o big-M deixa de ser eficaz. Valores menores podem permitir que o solver ignore a restrição por tolerância numérica (ε ≈ 1 e-4 do CBC).
|
||
5. **Aeronave 2811 fica ociosa neste cenário:** o solver atribui todas as 20 missões a 3 aeronaves. Isso é matematicamente ótimo, mas pode não ser desejável operacionalmente. Considerar restrição de equilíbrio de carga em versões futuras.
|
||
6. **Status "Not Solved" após L2:** a correção atual usa o status de L1 como proxy. Se L1 retornar apenas uma solução feasível (não ótima, por time limit), o modelo pode ser reportado como "Optimal" quando não é. Monitorar o campo `prio_otima` para validar.
|
||
|
||
---
|
||
|
||
## v0.2 — VTO — 2026-06
|
||
|
||
### Adicionado
|
||
|
||
- Diretório `software/` com o primeiro protótipo `software/oamrp_v1.py`.
|
||
- Modelo MIP compacto em PuLP para atribuição de aeronaves a missões opcionais.
|
||
- Regras de `.gitignore` para caches Python.
|
||
|
||
### Alterado
|
||
|
||
- Estrutura de dados reorganizada para `db/raw/`, `db/pre_process/` e `db/processed/`.
|
||
- Documentação atualizada para refletir a separação entre dados (`db/`) e modelos (`software/`).
|
||
- Nome técnico do projeto padronizado como Arara OAMRP nos documentos principais.
|
||
|
||
---
|
||
|
||
## v0.1 — VTO — 2026-06
|
||
|
||
### Adicionado
|
||
|
||
- Repositório Git inicial.
|
||
- Estrutura de dados com `raw/`, `pre_process/` e `processed/`.
|
||
- Arquivo `README.md` na raiz com guia de uso do repositório.
|
||
- Arquivo `CONTEXTO.md` com orientações permanentes do projeto.
|
||
- Arquivo `LOG.md` com rastreabilidade operacional por data, hora e tag de autor.
|
||
- Pré-processamento inicial do relatório de ciclo de inspeções do C-105 matrícula 2805.
|
||
- Saídas intermediárias em texto, JSON e CSV.
|
||
- Campos discretos para `zera_tso`, letra, nível, duração, horas de voo, meses contínuos e pousos.
|
||
- Documentação em `docs/about.md`, `docs/authors.md` e `docs/changelog.md`.
|
||
|
||
### Alterado
|
||
|
||
- Projeto renomeado para `arara_oarmp`.
|
||
- Repositório remoto migrado para `https://git.ppgao.ita.br/vitorcesavc/arara_oarmp.git`.
|
||
- Documentação reorganizada para separar guia inicial, contexto, autoria, histórico de versão e log operacional.
|
||
|
||
### Corrigido
|
||
|
||
- Interpretação da coluna `Zera TSO`, que passou a ser tratada como coluna única.
|
||
- Mapeamento dos níveis `B`, `P` e `O` para Base, Parque e Orgânico.
|
||
|
||
### Observações
|
||
|
||
- O parser atual foi calibrado para o primeiro PDF processado.
|
||
- A grafia original do documento fonte foi preservada, inclusive ocorrências de `INPEÇÃO`.
|
||
## v0.3 - VTO - 2026-06
|
||
|
||
### Adicionado
|
||
|
||
- Pre-processamento da `Planilha 2025.xlsx` para registro de voo limpo.
|
||
- Saidas em CSV/XLSX sem mesclas e CSV OAMRP com `id,orig,dest,partida_utc,chegada_utc,prioridade`.
|
||
- Resumo JSON com contagens, campos faltantes e criterios de conversao.
|
||
|
||
### Alterado
|
||
|
||
- Criado arquivo final `db/processed/registro_voo_2025.csv`.
|
||
|
||
### Observacoes
|
||
|
||
- `SEGMTO` foi preservado da planilha original; cruzamento de 00Z foi registrado em campo separado.
|
||
- Colunas entre `REAL` e `COM2` foram descartadas.
|
||
## v0.3.1 - VTO - 2026-06
|
||
|
||
### Alterado
|
||
|
||
- Registro de voo 2025 regenerado removendo a linha original 793, aeronave 2806.
|
||
- Consolidado passou para 1267 trechos e registro limpo para 1420 linhas.
|
||
- Documentacao atualizada em `README.md`, `docs/about.md`, `LOG.md` e relatorio de validacao.
|
||
|
||
### Observacoes
|
||
|
||
- A remocao foi aplicada no script de pre-processamento para manter reprodutibilidade.
|
||
|
||
## v0.9 — VTO — 2026-06
|
||
|
||
### Adicionado
|
||
|
||
- Flag `--escala` na CLI: carrega missões reais da Escala de Voo Modelo 1 (CSV com separador `;`), com parser de data DD/MMM, horários UTC e prioridade derivada do código de missão (69TV→1, 50TT/05TF→3).
|
||
- `BASES_COORDS` expandido de 10 para 26 bases (inclui SBMQ, SBOI, SBBR, SBGL, SBCY, SWEI, SWCA, SWKO, SBUY e outras rotas reais).
|
||
- Cenários de f0 em JSON: `f0_cenario_esquadrao.json` (dados realistas do esquadrão) e `f0_cenario_insp_grande.json`.
|
||
|
||
### Corrigido
|
||
|
||
- Gantt: FAB 2800 (y=0) estava invisível — corrigido com `yaxis range=[-0.5, n-0.5]`.
|
||
- Gantt: barras não renderizavam (`shapes type="rect"`) — substituídas por `go.Scatter mode="lines"` que renderiza garantido no eixo de datas.
|
||
- Largura mínima de 2h por barra no Gantt para voos curtos ficarem visíveis.
|
||
|
||
### Alterado
|
||
|
||
- `--time-limit` default alterado de 60s para 300s (5 minutos).
|
||
- Imports `timedelta` e `date` consolidados no topo do módulo (era importado localmente em funções).
|
||
|
||
### Resultado validado
|
||
|
||
Rodada `--sintetico --n-missoes 30 --f0 f0_cenario_esquadrao.json` → 30/30 Optimal; FAB 2809 com 1 inspeção (CHECK 300) visível no Gantt.
|
||
|
||
---
|
||
|
||
## v0.8 — VTO — 2026-06
|
||
|
||
### Adicionado
|
||
|
||
- Visualização combinada em HTML único: Gantt (Plotly) + mapa (Folium em iframe) + tabela de voos com filtros JS interativos.
|
||
- Título "Planejamento de Diagonal de Manutenção" no HTML gerado.
|
||
- Exportação de inspeções no CSV de resultado com timestamps UTC reais.
|
||
- Filtros na tabela: aeronave, status, prioridade, base e busca livre; ordenação por coluna.
|
||
- Flag `--time-limit` na CLI do solver (padrão era 60s).
|
||
|
||
---
|
||
|
||
## v0.7 — VTO — 2026-06
|
||
|
||
### Corrigido
|
||
|
||
- Bug crítico de conservação de fluxo em nós de inspeção (`oamrp_v3.py`): o solver criava unidades de fluxo fantasma nesses nós, fazendo o relatório exibir 50/50 enquanto o CSV real tinha apenas 16 missões cobertas. Corrigido adicionando C2 para nós `tipo == "inspecao"`.
|
||
- Bug de restrição C6 Fase 1 simplificada removida: somava horas totais sem respeitar resets de inspeção, tornando EVAMs 2809 e 2811 artificialmente ociosas. As variáveis `H[k,seq,nid]` com reset já impõem o limite corretamente.
|
||
|
||
### Adicionado
|
||
|
||
- Flag `--aleatorio` na CLI: sorteia `f0` entre 10% e 90% de `F_max` por aeronave e tipo de inspeção.
|
||
- Tabela OFRAG em `db/processed/ofrag.csv` com 50 ordens sintéticas (prioridades 1–5, tipo de missão, OM).
|
||
- Script `software/gerar_ofrag.py` para gerar ou regen a tabela OFRAG de forma reprodutível.
|
||
- Flag `--ofrag` na CLI: carrega prioridades do CSV ao gerar missões sintéticas.
|
||
- Visualização interativa `db/processed/mapa_rotas.html` via Folium, com uma camada por aeronave, missões não cumpridas tracejadas e popup com detalhes.
|
||
- Script `software/visualizar_resultado.py` para gerar o mapa a partir do CSV de resultado.
|
||
|
||
### Alterado
|
||
|
||
- Nomenclatura alinhada com Al-Thani (2016): `lrt_h` → `f_max`; `horas_iniciais` → `f0`; `orcamento_h()` → `lrt_inicial()`; `horas_iniciais_aleatorias()` → `gerar_f0_aleatorio()`; `carregar_horas_iniciais()` → `carregar_f0()`; CLI `--horas-iniciais` → `--f0`.
|
||
- Relatório imprime `F_max=`, `f0=` e `LRT_ini=` para cada aeronave, alinhado com a formulação do artigo de referência.
|
||
|
||
### Resultado validado
|
||
|
||
Rodada `--sintetico --seed 42 --aleatorio --ofrag db/processed/ofrag.csv` → 50/50 missões cumpridas, solver CBC Optimal, todas as 4 EVAMs com voos e ferry.
|
||
|
||
---
|
||
|
||
## v0.6 - VTO - 2026-06
|
||
|
||
### Adicionado
|
||
|
||
- Gerador de missões sintéticas cross-base (`gerar_missoes_sinteticas()`): 50 missões entre 10 bases com durações calculadas via haversine ÷ velocidade C-105 (430 km/h); flag `--sintetico`, `--n-missoes`, `--n-evam` na CLI.
|
||
- Fase 3: arcos de ferry em `construir_rede()` — arcos `inicio`, `missao_missao`, `missao_insp` e `insp_missao` agora permitem bases distintas com tempo de ferry calculado automaticamente.
|
||
- Ferry consome horas de célula no relógio de inspeção (C6: `carga = v.carga_h + a.horas_ferry`).
|
||
- Relatório imprime segmentos `[FERRY base1->base2 Xh]` na linha do tempo de cada aeronave.
|
||
- Resultado `db/processed/resultado_oamrp_sintetico.csv` para 50 missões sintéticas.
|
||
|
||
### Alterado
|
||
|
||
- Dicionário `BASES_COORDS` com coordenadas (lat, lon) das 10 bases operacionais do C-105.
|
||
|
||
## v0.5 - VTO - 2026-06
|
||
|
||
### Adicionado
|
||
|
||
- Modelo `software/oamrp_v3.py` — reescrita do zero com rede espaço-tempo (No/Arco) e variável unificada `y[k,arco]`.
|
||
- Fase 1 (C1–C6): fluxo de conservação, cobertura de missões, restrição de voo ativo, orçamento de horas por inspeção.
|
||
- Fase 2 (C7–C11): nós e arcos de inspeção na rede; variáveis `H[k,i,nid]` para relógio de horas com reset; C9 downtime; C11 slot único via variáveis disjuntivas `oo`.
|
||
- Documento `HANDOFF_arara_oamrp.md` com formulação matemática, decisões de calibração (Q1–Q5) e plano de build incremental.
|
||
- Resultado `db/processed/resultado_oamrp_v3.csv` para janeiro/2025.
|
||
|
||
### Alterado
|
||
|
||
- TAT corrigido para 1,5h (era 1,0h em v2).
|
||
- Top-10 bases por frequência no registro de voo 2025 (Q4).
|
||
- Missões EVAM marcadas como obrigatórias (Q2).
|
||
- Objetivo L2 definido como maximizar horas voadas (= minimizar folga ao fim do horizonte mensal) (Q3).
|
||
|
||
### Corrigido
|
||
|
||
- Bug de escopo de arco: arcos de início/fim agora carregam `aeronave_id` e só entram na variável `y` do aircraft correto.
|
||
- Bug `NameError tat_h` em C9b: substituído pela constante global `TAT_H`.
|
||
- Bug `AttributeError` em `escrever_resultado`: filtro por `n.tipo == "missao"` antes de acessar `n.missao`.
|
||
|
||
## v0.4 - VTO - 2026-06
|
||
|
||
### Adicionado
|
||
|
||
- Modelo `software/oamrp_v2.py` para rodar o OAMRP com o registro de voo 2025 consolidado.
|
||
- Resultado inicial `db/processed/resultado_oamrp_jan_2025.csv`.
|
||
|
||
### Observacoes
|
||
|
||
- Rodada padrao usa janeiro/2025, aeronaves reais `2800`, `2803`, `2809` e `2811`, base inicial provisoria `SBMN`, base de manutencao `SBMN` e prioridade uniforme 1.
|
||
- Primeira execucao retornou solucao otima com 50 de 61 missoes cumpridas.
|