Predictive maintenance rarely fails at the algorithm first.
Many projects talk about model types too early. The real bottleneck comes earlier: which signals are reliable, do timestamps line up, is there enough context about load, shift, product variant, maintenance history and failures, and is the failure pattern clearly defined?
A central data lake can be useful long term, but it does not solve these questions automatically. If raw signals arrive too late, are aggregated too heavily or lack asset context, even a good model can only detect limited patterns.
The edge enforces the right order. It starts at the machine, meter, controller or gateway. Signals are evaluated, normalized and connected with operating events before they are used for AI.
What the edge sees better.
The edge sees short events that disappear in central reports: voltage dips, temperature spikes, communication interruptions, startup behavior, load changes, sensor noise or unusual repetitions. These patterns are often early indicators of failure.
This applies to charging infrastructure as well as industrial assets. A relay, communication module, fan, meter or connector often does not announce a problem through a clean error code. The hints lie in sequences of measurements, status changes and local events.
- Check, filter and enrich raw signals locally.
- Detect short-term patterns before they disappear in aggregates.
- Provide maintenance hints even with unstable connectivity.
- Synchronize relevant events centrally instead of transferring everything blindly.
OCPP and Industrial AI are closer than they look.
In charging sites, the signals are called StatusNotification, MeterValues, Heartbeat, ChargingProfile or FirmwareStatusNotification. In industrial plants, they are OPC UA, Modbus, PLC registers, historian tags or machine logs. The core problem is similar: technical events must be translated into an understandable operating model.
NeLeSo connects these worlds. Our work with OCPP, CPMS, Edge Controllers and Pipelet building blocks helps in Industrial AI projects because the recurring themes are robust data paths, local operating logic and traceable decisions.
A good pilot is small, but not arbitrary.
A reliable predictive-maintenance pilot does not need a whole factory. It needs one critical asset, a clear failure pattern, relevant signals and a measurable target. The target can be fewer unplanned stops, faster root-cause analysis or better maintenance prioritization.
The pilot should be designed as an operating building block from day one: monitoring, versioning, data quality, alarm rules, feedback from maintenance teams and a cloud path belong to it. Otherwise the maintenance project itself will not be maintainable.
AI does not replace maintenance. It prioritizes attention.
Predictive maintenance is not a promise to predict every failure perfectly. The practical value is better attention: which asset behaves differently than usual, which pattern led to downtime in the past, which warning is only noise?
At the edge, this prioritization can happen close to the process. The central platform then receives not just data, but pre-qualified events with context. This improves analytics and relieves operations teams.