DEV Community: Siandro Sena

Which fleet vehicle should I check first? Modeling a maintenance priority score

Siandro Sena — Mon, 31 Aug 2026 02:42:36 +0000

At a passenger river-transport operation with a garage in Barcarena, in the Brazilian Amazon, every vehicle in the fleet generates maintenance data all the time: tire tread depth, tire pressure, alignment, oil and filters, lubrication. That's a good thing — it means there's enough data to decide with information instead of gut feeling. The problem is that raw data isn't a decision. Someone still has to open 20 spreadsheet tabs, compare category by category, and decide off the top of their head which vehicle is most urgent. In practice, that turns into one of two things: an experienced mechanic deciding by instinct (which works fine until they take vacation or change jobs), or a list nobody looks at until a tire blows out on the road.

This article is about how I modeled that problem — it's not a code tutorial, it's about the engineering decisions behind two small, tested pieces: a wheel wear classifier, and a fleet priority engine. In my day-to-day work I solve this kind of problem with low-code — n8n, Google Apps Script, Google Sheets formulas — because that's what delivers value fastest to whoever actually has to use it. For this article and the public repository, I rewrote the same logic in plain Python: it's easier to read, test, and adapt for anyone not using my specific stack. The code is published, generalized and anonymized, at github.com/siandrosena/fleet-maintenance-priority-engine.

The first problem: the mechanic decides by instinct, and that doesn't scale

Take any tire in the fleet. You measure tread depth at 4 points across the tread: outer edge, outer center, inner center, inner edge. An experienced mechanic looks at those 4 numbers and knows instantly: "this tire is worn because it's misaligned" or "this one's a pressure problem." Those are two different physical problems with two different fixes (align vs. adjust pressure), and the pattern across the 4 points is what gives it away:

Wear concentrated on one edge (one edge with noticeably lower tread than the other) → the tire is "eating" on one side, a classic sign of a camber/alignment issue → needs alignment.
Wear concentrated in the center OR on both edges, symmetrically → classic sign of wrong pressure (an underinflated tire wears the edges faster; an overinflated tire wears the center faster) → needs a pressure adjustment.
Both patterns at once, or neither clearly → irregular wear, probably a different root cause (bearing, suspension) that this simple diagnosis doesn't cover.

The interesting part of modeling this in code isn't the math (it's subtraction and comparing averages) — it's deciding where the tolerance thresholds sit and what to do when both patterns show up at once. A tire with a 1mm difference between edges isn't misaligned, that's normal manufacturing/wear variation. I set 3mm as the alignment threshold and 2mm as the pressure threshold — not magic numbers, they're the point where a real mechanic would stop calling it "normal" and start calling it "a problem." And when both thresholds trip at the same time, the right move isn't to arbitrarily pick one — it's to admit the pattern is mixed (DESGASTE_IRREGULAR / irregular wear) and flag it for manual inspection, instead of giving a falsely confident diagnosis.

def diagnose_wheel(reading):
    delta_bordas = reading.borda_externa - reading.borda_interna
    delta_centro_bordas = reading.media_centro - reading.media_bordas

    desalinhado = abs(delta_bordas) >= 3.0
    pressao_errada = abs(delta_centro_bordas) >= 2.0

    if desalinhado and pressao_errada:
        return WheelVerdict.DESGASTE_IRREGULAR
    if desalinhado:
        return ALINHAR_ESQUERDA if delta_bordas < 0 else ALINHAR_DIREITA
    if pressao_errada:
        return CALIBRAR_MAIS if delta_centro_bordas > 0 else CALIBRAR_MENOS
    return OK

Seven tests cover all 6 possible verdicts, including the mixed case. The point isn't the code's complexity (it's low, on purpose) — it's that the business rule became something testable and reproducible, instead of "ask your experienced mechanic."

The second problem: not every maintenance category weighs the same

Solving the per-wheel diagnosis doesn't solve the real, fleet-wide problem: with 20 vehicles, each generating data across 5 different categories (tire pressure, tread, alignment, oil/filters, lubrication), whoever decides "I'm checking this vehicle today" has to compare things that aren't obviously comparable. Is a vehicle with tire pressure 20% off ideal more urgent than one with lubrication 20% overdue? Yes — and the reason isn't arbitrary: wrong tire pressure degrades the tire fast and affects braking/stability within days, while a lubrication delay has weeks of slack before it becomes a real problem.

That means the score can't be a simple average across categories. I modeled it as a weighted sum, where the weight reflects how fast ignoring that category turns into an expensive problem:

CATEGORY_WEIGHTS = {
    "calibragem": 5,       # tire pressure
    "sulco": 4,            # tread depth
    "alinhamento": 3,      # alignment
    "oleo_filtros": 2,     # oil/filters
    "lubrificacao": 1,     # lubrication
}
score = Σ (category weight × severity 0.0–1.0 in that category)

Each category's severity (0.0 to 1.0) can come from whatever criterion makes sense for it — days overdue, deviation from ideal range, whatever fits — the priority engine doesn't need to know where the number came from, only that it's already normalized. That separation (whoever computes severity ≠ whoever ranks by priority) is what lets you swap the criterion for one category without touching the ranking engine.

The actual result

Running against a fictional 7-vehicle fleet with deliberately messy data (each vehicle has a different problem):

TOP 5 — vehicles needing attention now:

1. VEHICLE-07 — score 15.0 (worst category: tire pressure)
2. VEHICLE-03 — score 6.4 (worst category: tread depth)
3. VEHICLE-01 — score 6.4 (worst category: tire pressure)
4. VEHICLE-05 — score 6.0 (worst category: tire pressure)
5. VEHICLE-02 — score 1.9 (worst category: tread depth)

This is the real output of the repository's example CLI, not an illustration. A list where "everyone needs something" turned into an ordered list with an explicit reason attached.

Why this matters for a real operation

The win isn't "having a nice dashboard" — it's taking a recurring, expensive decision (which vehicle do I check first, every day) out of one person's head and putting it into an explicit, auditable, consistent criterion. That matters for three concrete reasons:

The decision stops being a single point of failure. If the mechanic who "knows it by heart" gets sick, goes on vacation, or changes jobs, the operation doesn't lose its ability to prioritize — the criterion lives in the system, not just in someone's head.
The criterion becomes visible and debatable. When each category's weight is explicit in the code, you can question and adjust it ("should alignment weigh more than this for our specific operation?") instead of arguing about a decision nobody can explain the reasoning for.
Fewer unplanned breakdowns. The end goal isn't the score — it's the tire that doesn't blow out on the road because someone looked at it three days before, not three days after.

Trade-offs and limitations (on purpose, not hidden)

No system modeled in a few weeks is complete, and I'd rather say so than have someone find out the hard way:

The thresholds (3mm, 2mm) and weights (5,4,3,2,1) are fixed constants, calibrated from my domain understanding, not from statistical analysis of a large base of real failures. For a different operation (different vehicle type, climate, road conditions), those numbers likely need adjusting.
The wheel diagnosis covers 2 wear axes (edge-to-edge and center-vs-edges). A wear pattern that doesn't fit either one (say, caused by a bearing or suspension issue) falls into "irregular" without pointing at a root cause — the system can say "something's wrong," not always "what."
The priority score doesn't factor in cost, part/shop availability, or route criticality. It's an inspection-severity score — one piece of a larger decision system, not the final decision by itself. A vehicle can have the highest score and still not be the truly most urgent one if the part to fix it won't arrive until tomorrow regardless.
It trusts the input reading as true — if the tread/pressure data going in is wrong (measurement error, typo), the system propagates that error with the same confidence as correct data. That's exactly why I treat data extraction (reading a handwritten card via AI, in a different project in the same portfolio) as a separate layer, with its own validation, before anything reaches this one.

Why I rewrote this from scratch in Python instead of publishing the original system

The production version of this system isn't Python — it's native Google Sheets formulas and Google Apps Script, running inside a real client spreadsheet. That's a deliberate choice, not a limitation: when the person operating the system is a mechanic or a fleet manager, not a programmer, putting the logic directly into the tool they already use every day (the spreadsheet) removes an entire layer of friction — no deployment, no server, no "call IT to change it." My job as an engineer here wasn't "write as much code as possible," it was understanding the maintenance process closely enough to know WHICH rule to automate and WHERE it needed to live to actually get used.

Spreadsheet formulas tied to one client's specific spreadsheet structure aren't something I can publish, though (it's the client's, not mine to distribute), nor are they easy to read for anyone who can't open that exact spreadsheet. For the public repository, I rewrote the same decision logic from scratch in plain Python, tested in isolation, and generalized enough for any fleet operation to understand and adapt — with no company name, plate number, or any identifiable data from the original operation. The Python here is a portfolio translation, not the tool I'd reach for to solve this again from scratch in a real operation.

Repository: github.com/siandrosena/fleet-maintenance-priority-engine — Python, 14 tests, MIT license.

Siandro Sena — Production Engineer (background in Materials Engineering), MBA in Artificial Intelligence. Process automation with AI, data, and operational efficiency. LinkedIn

Qual veículo da frota precisa de manutenção HOJE? Priorização com pesos por criticidade (e por que meu dia a dia é low-code, não Python)

Siandro Sena — Fri, 28 Aug 2026 17:44:37 +0000

O problema

Numa frota com vários veículos, cada um gera dado de manutenção o tempo todo: sulco de pneu, calibragem, alinhamento, óleo, lubrificação. Sem um sistema, isso vira uma de duas coisas — decisão na intuição de um mecânico experiente (que erra, esquece, ou não está lá no dia daquela decisão), ou uma planilha manual que ninguém olha até o pneu estourar na estrada. Nos dois casos, quem decide "qual veículo eu vejo primeiro hoje" está adivinhando, não sabendo.

Isso é um problema real que estruturei para uma empresa de transporte rodofluvial de passageiros com garagem em Barcarena-PA (Brasil). Sem nome da empresa, placa ou qualquer dado identificável — o que compartilho aqui é a lógica de decisão, generalizada.

Um adendo importante: meu dia a dia é low-code, não Python

Antes de entrar no código: a versão que roda em produção não é Python. É uma automação em Google Sheets + Apps Script — leitura de sulco dispara um desenho automático de resumo visual pro mecânico (onEdit), e o dashboard de priorização da frota inteira é 100% fórmula nativa (QUERY, sem script rodando por trás).

Isso não é modéstia nem desculpa — é a ferramenta certa pro contexto: numa operação de frota pequena/média, quem mantém isso no dia a dia é quem já usa planilha, não quem sabe rodar pip install. Baixo custo de manutenção, zero servidor, qualquer um da operação abre e entende.

O repositório e este artigo reescrevem essa mesma lógica de decisão em Python puro, testado e isolado — como exercício de portfólio, pra mostrar o raciocínio de forma que rode em qualquer lugar e sirva de referência técnica. É tradução, não é como o sistema roda na vida real.

A solução

O sistema faz duas coisas, em sequência:

1. Olha os 4 pontos de sulco de cada roda e já diz o que fazer: o pneu está gasto porque está desalinhado, ou porque a calibragem está errada? São ações diferentes (alinhar vs. calibrar), e o padrão de desgaste denuncia qual — isso é física de pneu, não é chute:

Pneu desalinhado desgasta mais de UM lado → diferença grande entre as duas bordas (externa vs. interna)
Pneu com pressão errada desgasta o centro OU as bordas de forma simétrica → murcho gasta mais as bordas, cheio demais gasta mais o centro

2. Cruza essa leitura com as outras categorias de manutenção de toda a frota — calibragem, sulco, alinhamento, óleo/filtros, lubrificação, nem todas pesam igual — e devolve um ranking: comece por aqui.

Modelagem: pesos e limiares

A parte que importa não é o código, é a decisão de negócio por trás dele.

Limiares do diagnóstico de roda (regra fixa, em milímetros de diferença de sulco):

DIFERENCA_ALINHAMENTO_MM = 3.0   # diferença entre bordas externa/interna
DIFERENCA_CALIBRAGEM_MM = 2.0    # diferença entre média do centro e média das bordas

Pesos por categoria (referência: material educativo de segurança de pneus tipo NHTSA TireWise sobre o impacto de calibragem/sulco na frenagem e estabilidade — não é arbitrário, mas também não é uma constante universal):

CATEGORY_WEIGHTS = {
    "calibragem": 5,       # degrada rápido, barata de checar, ignorar é caro
    "sulco": 4,
    "alinhamento": 3,
    "oleo_filtros": 2,
    "lubrificacao": 1,     # tem mais folga de prazo
}

A lógica: calibragem errada não é tratada igual a lubrificação atrasada, porque na vida real elas não têm a mesma urgência nem o mesmo custo de ignorar. O score de cada veículo é a soma de peso × severidade de cada categoria (severidade de 0.0 a 1.0, saturando em 1.0 conforme os dias de atraso passam do prazo máximo daquela categoria).

Exemplo real de saída

Frota de 7 veículos, situação bagunçada — cada um com um problema diferente, ninguém sabe por onde começar:

$ python scripts/priority_report.py --input sample_data/frota_severidade.json --top 5

TOP 5 — veículos que precisam de atenção agora:

1. VEICULO-07 — score 15.0 (pior categoria: calibragem)
2. VEICULO-03 — score 6.4 (pior categoria: sulco)
3. VEICULO-01 — score 6.4 (pior categoria: calibragem)
4. VEICULO-05 — score 6.0 (pior categoria: calibragem)
5. VEICULO-02 — score 1.9 (pior categoria: sulco)

Uma lista de "todo mundo precisa de alguma coisa" virou uma ordem de prioridade com o motivo ao lado — sem ninguém abrir aba por aba da planilha.

Por que isso importa

Menos pneu estourando na estrada — o problema é sinalizado antes de virar parada não planejada, não depois.
A decisão para de depender de UMA pessoa — hoje, "qual veículo eu olho primeiro" muitas vezes só um mecânico experiente sabe responder de cabeça. Isso vira algo que qualquer pessoa da operação consegue rodar.
Cada categoria pesa o que realmente pesa — porque na vida real elas não têm a mesma urgência.

Limitações honestas

Nenhum sistema de regra fixa é perfeito, e eu prefiro deixar isso explícito em vez de vender como mágica:

O diagnóstico de roda confia na leitura de sulco como verdadeira — não valida se os 4 números fazem sentido físico (valor negativo, fora da faixa de um pneu novo/gasto). Garbage in, garbage out.
Os limiares (3mm alinhamento, 2mm calibragem) são constantes fixas, não calibradas por modelo/marca de pneu ou por eixo (dianteiro e traseiro desgastam diferente) — funcionam como regra geral, não como valor validado estatisticamente pra cada operação.
Só cobre 2 eixos de desgaste (borda-a-borda e centro-vs-bordas). Um padrão de desgaste diagonal (problema de rolamento/suspensão, por exemplo) cai em "desgaste irregular" sem indicar a causa real.
O score de prioridade não considera custo, disponibilidade de peça/oficina ou criticidade da rota — é um score de severidade de inspeção, não uma otimização operacional completa.
Categoria com nome digitado errado é ignorada em silêncio — um typo na severidade de entrada derruba a pontuação daquele veículo sem nenhum aviso. Isso é um risco real de qualquer sistema baseado em texto livre, incluindo o de planilha.

Stack

Em produção: Google Sheets + Apps Script (onEdit, QUERY)
Neste repositório (tradução pra portfólio): Python (stdlib, sem dependência externa) + pytest, 14 testes cobrindo os 6 vereditos de roda e o motor de score

Repositório completo, com código e testes: fleet-maintenance-priority-engine

Sou engenheiro (Produção/Materiais) com MBA em Inteligência Artificial, estruturando automação de processos com IA e dados pra operações reais. Se você lida com frota, manutenção preventiva ou só curte ver regra de negócio de verdade virar código, comenta aí — troco ideia.