SBPO 2026 · PÔSTER / POSTER

Otimização do Mix de Alocação da Manutenção de Vagões em Ferrovias de Carga por Programação Linear Inteira

Optimization of Wagon Maintenance Mix Allocation in Freight Railways Using Integer Linear Programming
📑 Ler o artigo completo nos anais do SBPO 2026proceedings.science · Optimization of Wagon Maintenance Mix Allocation in Freight Railways Using Integer Linear Programming 📑 Read the full paper in the SBPO 2026 proceedingsproceedings.science · Optimization of Wagon Maintenance Mix Allocation in Freight Railways Using Integer Linear Programming
39 → 9backlog final (vagões)final backlog (wagons)
−54,4%backlog acumuladocumulative backlog
−25,4%custo total do sistematotal system cost
< 1 stempo de soluçãosolve time
Qual problema o modelo resolve?

Decide, mês a mês, em qual posto de manutenção cada vagão (por região, tipo e escopo) deve ser atendido e quanto deixar em backlog, respeitando capacidade em homem-hora, elegibilidade técnica e custos logísticos e de indisponibilidade.

Por que programação linear inteira?

Vagões não podem ser fracionados. A relaxação linear atendeu 995,32 vagões e deixou 8,68 em backlog — quantidades fisicamente impossíveis. O gap entre a relaxação e o ótimo inteiro foi de 0,82%.

De onde vem o ganho? Por que o backlog caiu de 39 para 9?

Do gargalo do PM2. Ele é o único posto que faz as revisões pesadas (VR4 e VRG), e a demanda pesada do ano (6.593 HH) já supera sua capacidade efetiva (6.525 HH). A heurística local-first ainda manda para o PM2 119 vagões de escopo leve (103 VMC e 16 VR1) só porque são da região dele, consumindo horas que deveriam ir para os pesados: resultam apenas 40 revisões VR4 no ano e 216 vagões-mês de VR4 em backlog.

O modelo ótimo faz o contrário: envia só 34 vagões leves ao PM2, desloca o trabalho leve para PM1 e PM3 (que tinham folga) e usa as horas liberadas para 75 revisões VR4. O backlog acumulado cai de 274 para 125 vagões-mês, quase todo na VR4 (216 → 41). Por isso o resultado depende de olhar capacidade por escopo e por posto, não a folga agregada de 7,6%.

Se a capacidade total tem folga de 7,6%, por que a heurística deixa 39 vagões parados?

Porque a folga está nos postos e nos meses errados. PM1 e PM3 sobram horas, mas não podem fazer VR4 nem VRG; o PM2, que pode, fica saturado. Além disso, a capacidade mensal varia com férias e reparos de equipamento, então há meses em que nem a demanda leve cabe localmente. Uma regra que olha um mês e uma região de cada vez não enxerga esse desencontro; o modelo, que decide os 12 meses de uma vez, antecipa e distribui.

Como o custo total caiu 25,4% se o modelo gasta mais em transporte?

O custo de serviço (manutenção + logística + indisponibilidade + retenção) sobe de 112,5 mil para 122,9 mil MU (+9%), porque há 401 movimentos remotos contra 306. Em troca, a penalidade de backlog cai de 116,1 mil para 47,8 mil MU (−59%). O saldo é 228,7 mil → 170,7 mil MU. Cada transferência extra só é feita quando custa menos que deixar o vagão esperando.

Por que o plano ótimo faz mais transferências e mesmo assim custa menos?

O modelo só transfere um vagão para outra região quando o custo composto (manutenção + logística + indisponibilidade + retenção) é menor que a penalidade de mantê-lo parado no backlog. O custo de serviço sobe ~9%, mas a penalidade de backlog cai ~59%.

Qual a heurística de comparação? Ela foi enfraquecida?

Não. É uma regra “local-first” com as mesmas restrições do modelo: preenche carga mínima, envia primeiro ao posto local elegível, depois a outros postos por custo crescente, e carrega o resto para o mês seguinte. Os dois métodos diferem apenas na qualidade da decisão.

Os dados são reais?

A instância é anonimizada e reprodutível (1.004 intervenções, 12 meses, 3 regiões, 3 postos, gôndolas GDT e GDU). Custos são normalizados; os ganhos não são previsão para uma concessionária específica.

O que são VR1, VR2, VR4, VRG e VMC?

VR1 e VR2: revisões leves. VR4: revisão pesada quadrienal. VRG: revisão geral. VMC: manutenção corretiva. VR4 e VRG só podem ser feitas no posto PM2, que tem o equipamento necessário.

O modelo escala para uma frota real?

Instâncias replicadas com até 11.520 variáveis foram resolvidas em menos de 6 segundos com o solver HiGHS — rápido frente a um ciclo de planejamento mensal.

Quais os próximos passos?

Incerteza na demanda, capacidade detalhada da malha, idade do backlog e disponibilidade de estoque MRO, usando dados de concessionárias.

What problem does the model solve?

Month by month, it decides which maintenance post should service each wagon (by region, type and scope) and how much to keep in backlog, under person-hour capacity, technical eligibility, and logistics and unavailability costs.

Why integer programming?

Wagons cannot be split. The LP relaxation serviced 995.32 wagons and left 8.68 in backlog — physically impossible quantities. The relaxation gap was 0.82%.

Where does the gain come from? Why did final backlog drop from 39 to 9?

From the PM2 bottleneck. PM2 is the only post able to perform heavy reviews (VR4 and VRG), and annual heavy demand (6,593 HH) already exceeds its effective capacity (6,525 HH). The local-first heuristic still sends 119 light-scope wagons (103 VMC and 16 VR1) to PM2 just because they belong to its region, consuming hours that heavy scopes needed: only 40 VR4 reviews are completed in the year and VR4 accumulates 216 wagon-months of backlog.

The optimal plan does the opposite: it sends only 34 light wagons to PM2, shifts light work to PM1 and PM3 (which had slack) and uses the freed hours for 75 VR4 reviews. Cumulative backlog falls from 274 to 125 wagon-months, almost all of it in VR4 (216 → 41). That is why the result hinges on capacity per scope and per post, not on the 7.6% aggregate slack.

If total capacity has 7.6% slack, why does the heuristic leave 39 wagons waiting?

Because the slack sits in the wrong posts and months. PM1 and PM3 have spare hours but cannot do VR4 or VRG; PM2, which can, is saturated. Monthly capacity also varies with staff leave and equipment repair, so in some months even light demand does not fit locally. A rule that looks at one month and one region at a time cannot see this mismatch; the model decides all 12 months at once, anticipates it and redistributes.

How can total cost fall 25.4% if the model spends more on transfers?

Service cost (maintenance + logistics + unavailability + retention) rises from 112.5k to 122.9k MU (+9%), because there are 401 remote movements instead of 306. In exchange, the backlog penalty drops from 116.1k to 47.8k MU (−59%). Net: 228.7k → 170.7k MU. Each extra transfer is made only when it costs less than leaving the wagon waiting.

Why does the optimal plan move more wagons yet cost less?

It transfers a wagon to another region only when the composite cost (maintenance + logistics + unavailability + retention) is lower than the backlog penalty. Service cost rises ~9%, but the backlog penalty falls ~59%.

What is the baseline heuristic? Was it weakened?

No. It is a local-first rule under the same constraints: fill minimum workloads, send demand to the local eligible post first, then to other posts by increasing cost, and carry the rest to the next month. Both methods differ only in decision quality.

Is the data real?

The instance is anonymized and reproducible (1,004 interventions, 12 months, 3 regions, 3 posts, GDT and GDU gondolas). Costs are normalized; savings are not a forecast for a specific railway.

What are VR1, VR2, VR4, VRG and VMC?

VR1 and VR2: light reviews. VR4: four-year heavy review. VRG: general heavy review. VMC: corrective maintenance. VR4 and VRG can only be done at post PM2, the one with the required equipment.

Does it scale to a real fleet?

Replicated instances with up to 11,520 variables solved in under 6 seconds with HiGHS — fast relative to a monthly planning cycle.

What comes next?

Demand uncertainty, detailed network capacity, backlog age and MRO inventory availability, using railway-specific data.

MateriaisMaterials
📄 Pôster em português (PDF, 90 × 140 cm)📄 Poster in Portuguese (PDF, 90 × 140 cm)
📄 Pôster em inglês (PDF)📄 Poster in English (PDF)
🖥️ Slides da apresentação em português (PDF)🖥️ Presentation slides in Portuguese (PDF)
🖥️ Slides da apresentação em inglês (PDF)🖥️ Presentation slides in English (PDF)
💻 Código-fonte e dados do experimento (GitHub)💻 Source code and experiment data (GitHub)
ContatoContact
Carmo Crediney Melo — Universidade Católica de Petrópolis (UCP)
LinkedIn · carmo.42640028@ucp.br
Coautores: José Cristiano Pereira, Luciano M. S. Varricchio, Prudente J. T. Aguiar, Felipe M. Lopes, Bruno M. O. Jordão. Co-authors: José Cristiano Pereira, Luciano M. S. Varricchio, Prudente J. T. Aguiar, Felipe M. Lopes, Bruno M. O. Jordão.