Predictive maintenance of industrial equipment based on actual wear

A consumable part looks healthy right up until it halts the shop floor

At a steel, cement, or chemical plant, a small wearing part can determine whether an entire installation runs. As long as it keeps up, it goes almost unnoticed. A failure means an emergency shutdown, downtime penalties, and extra strain on the neighboring equipment.

Scheduled replacement, meanwhile, is often set by the datasheet, the calendar, or the engineer's experience. The actual operating regime of a specific part stays in the field inspectors' paper logs, and service reports appear after the fact. The plant does not want to replace a consumable that is still working and overpay for it. The service company does not want to wait for a breakdown. Without a shared picture, both sides argue about the same wear while relying on different data.

The platform's task begins with a deceptively simple question: how much life is left in a part that is running inside an installation right now? There is no dedicated sensor with a ready answer. It has to be inferred from temperature, pressure, frequency, running time, and other indirect signals.

First you have to hear the equipment inside a closed loop

Every site has control cabinets fitted with sensors. The plant should not have to open them up to inbound access from an external network, so the direction of the connection is reversed: the cabinet itself establishes a connection out of the protected loop and introduces itself to the platform gateway. After that, the gateway receives its polling plan and requests the registers over Modbus.

An unregistered cabinet is not polled. A new sensor added through the system enters the plan without restarting the gateway. Once every 60 seconds, the next batch of readings goes to the server; several times a day the platform recalculates wear and the forecast.

Telemetry is stored separately from the regular portal data. TimescaleDB is used for the time series, while a relational database holds companies, users, requests, and settings. Readings no longer depend on whether the field inspector reached the cabinet and managed to copy a number into the log.

The same register on two cabinets can mean different things

Cabinets are assembled for specific installations. One has five temperature sensors, another just one; the register addresses and the meaning of the values differ too. Modbus delivers bare 16-bit numbers that mean nothing to an engineer on their own.

The platform links a register to a physical quantity, a unit of measurement, and a conversion rule. The system provides for seven types of quantities, among them pressure, temperature, frequency, percentages, and discrete states. A linear conversion turns a register value into kPa, °C, Hz, or %, and status codes receive a clear interpretation. On screen the engineer sees "pressure drop of 2.4 kPa" rather than "register = 842".

This dictionary is not hardwired into the code forever. An administrator adds a new quantity to the reference table and describes a specific cabinet's map through settings. The next non-standard configuration is connected without a separate platform modification.

The forecast belongs to the part, not to the installation as a whole

Every wearing component has its own lifespan: an installation date and a removal date. That is why life is calculated from the data accumulated specifically during its time working at the facility. After a replacement, the new part starts its history from zero and does not inherit the wear of the previous one.

Several times a day the system processes the telemetry and estimates life by two independent physical mechanisms. For planning, it takes the conservative scenario - the one under which replacement is needed sooner. As output, the engineer receives four connected results:

The datasheet life remains a hard boundary. If actual running time has exceeded it, the platform creates a replacement itself, and the engineer is required to go out and install a new consumable. The forecast helps you act earlier, but it does not override the set operating limit.

Here is how the state of several sections might look in the portal; the values below illustrate the interface, not the project's metrics:

Uncertainty is shown next to the forecast

The cost of an error here cuts both ways. Too early an alarm sends a still-working part to the scrap heap. Too late an alarm leaves production facing the risk of an emergency shutdown. So a single tidy date with no assessment of data quality would create false confidence.

Each forecast gets a confidence level: high, medium, or low. If there is not enough data, the portal shows this outright. The engineer sees not only the model's result but also how confidently it can be relied on when planning a purchase and a visit.

This limitation was accepted explicitly rather than hidden inside the implementation. The platform distinguishes an absence of data from normal operation and does not present the earlier accuracy where the time series broke off.

The service and independent plants work on a single platform

The equipment manufacturer serves several companies, but a plant must not see a neighboring site's data. The structure begins with a company; inside it are facilities, and each facility holds units of equipment, and each unit has sensors and time series. Access rights are checked by the server on every request.

Five roles are split between the two sides. The service has an administrator, an in-house engineer, and a field engineer; the client has a company administrator and a staff member. The plant sees only its own sites, while the service personnel work with all facilities within the scope of their role. There is no self-registration: the closed system is populated by administrators.

A single user can belong to several companies. An engineer at a holding group who is responsible for several plants does not have to create a separate account for each legal entity.

A wear signal is carried forward by a service request

A plant employee submits a request straight from the equipment panel. On the manufacturer's side it becomes a service report with an assignee and a status. The engineer performs the work, writes off the spare parts used, and closes the report; the result appears in the client portal. The request does not dissolve between emails and phone calls.

Readings flow to the panels and charts as they are collected, so the plant and the service look at one current state. Each installation has its own pressure and temperature thresholds set: there is no universal set, since configurations and operating regimes differ. An exceedance feeds into the wear assessment and at the same time sends an email to those responsible. The same notification arrives with a new service request.

Some settings and routine operations are performed through the portal over the same protected channel. Where physical work on the equipment is not required, the engineer changes parameters without a separate trip to the site.

The history answers the question "who changed the threshold"

Every action that changes data goes into the log regardless of the author: a person or an automated routine. A threshold change, a configuration change, and even a setting entered on the device itself, bypassing the portal, are recorded. Telemetry is not duplicated into this log - the time-series database exists for that.

The administrator filters records by user, action, and time. When examining a disputed case, they reconstruct the state and history exactly as the user saw them at that moment. Instead of an email exchange about who changed a parameter, a concrete record with an author and a time remains.

Each unit's card comes with its documentation attached: datasheets, drawings, PDF and docx files, audio and video. The engineer opens the material they need next to the current readings and the service history of a specific cabinet.

Replacement becomes an event that can be planned

The plant and the service company get a shared picture of actual operation. The replacement date stops being an argument over paper logs, and the order date lands in the purchasing team's field of view in advance. The plant reduces the risk of an unplanned shutdown and downtime penalties; the service plans visits and part availability before an emergency call.

At the same time, the platform does not promise to know the future with equal accuracy in every situation. The forecast is limited by the completeness of the telemetry, the correctness of the sensor map, the physical models, and the datasheet limit. The confidence shown next to the result indicates where the decision already rests on a solid history and where the engineer needs to account for gaps.

Every day the system accumulates operating regimes and the actual lifespans of parts. The next step is to use this history to connect additional sensors and to train neural network models that refine material properties where engineering formulas are no longer enough. This layer can grow on top of the working data collection, service cycle, and storage without rebuilding the entire platform.