Predictive Machinery Maintenance Before the Line Stops

How predictive maintenance works for workshop machinery

Predictive maintenance for machinery reads wear signals before a failure stops production. In practice, vibration, temperature, power consumption, and work cycle data are compared against the machine's normal behavior. When the deviation exceeds a defined threshold, an operational alert arrives, not an alarm after the line has already stopped. For a small or medium-sized enterprise without an internal IT department, the point is not to buy another dashboard: it is to connect the data already available to a clear intervention procedure.

In many Italian workshops, the internal information system, meaning the management software, the shift supervisor's spreadsheet, and the paper log, only records interventions after a failure has already occurred. What is usually missing is the exact time of the first unusual noise, the load at the moment of the performance drop, and the history of parts actually used on that specific machine serial number. The result is a machine stoppage that arrives as a surprise, even though the signals had been there for days. Those who produce on order pay for this with interrupted batches, overtime, and deliveries that need to be renegotiated.

The problem only becomes visible when the line has already stopped

Sudden stoppages occur because the company records the intervention, not the weak signals that precede it.

The shift supervisor hears an unusual noise, the operator notices a part out of tolerance, the control panel shows a strange power draw. Those facts stay in a chat message, on a sticky note, or in the memory of whoever was on shift. The next day the machine stops and the race begins: finding the spare part, calling the external technician, and recovering the schedule. This is not negligence: it is a workflow that treats maintenance as an event rather than as continuous data.

Those who have little time for daily inspection rounds

Those who have little time for the daily shop floor routine do visual walkthroughs, perhaps at the start of a shift, and then return to production. The inspection only captures what is already obvious: oil on the floor, a visibly worn belt, a flashing alarm. It does not capture a slow temperature increase on a bearing or a cycle that lengthens by a few seconds. Without automatic data collection, the human eye arrives late, especially on machines running across multiple shifts.

Those who produce on order and cannot interrupt a batch

Those who produce on order experience stoppages at the worst possible moment, in the middle of a batch with a delivery date already communicated. The cost is not only the technical downtime: it is the retooling, the scrap, the call to the customer. In these cases, preventing machinery failures is not a topic reserved for large industrial groups. It is the difference between closing the week in margin or in recovery mode. The same mechanism appears in the hidden costs that erode margins in manufacturing, where time lost on the shop floor does not appear as a line item but eats into the result.

Why calendar-based maintenance does not prevent sudden stoppages

Scheduled maintenance reduces the disorder of deadlines, but it does not read the actual condition of the machine between one visit and the next.

The calendar is useful: oil, filters, belts, periodic checks. It remains blind to an unusual load, a more abrasive batch than usual, or a part fitted incorrectly after the last intervention. A machine can meet its scheduled service date and break down the following day, because the plan was based on time, not on usage. Those who want to keep track of deadlines can already find a guide on scheduled maintenance and deadline management; the topic here is different, because a deadline alone does not describe wear.

In practice, five recurring gaps remain in the transition from calendar-based to real-condition monitoring:

• the intervention history is not linked to the machine serial number, so recurring failures on the same unit go unnoticed;
• spare parts are reordered from memory, without a minimum threshold tied to the average time between stoppages;
• the post-repair inspection report does not feed back into the management system, so the next cycle starts from scratch;
• different shifts describe the same noise with different words, and the signal is lost;
• the external supplier intervenes, issues a report, and that report stays in a folder disconnected from the production plan.

A calendar-based plan keeps deadlines in order; it does not read the machine on the day when the load, the part, or the environment changes.

How artificial intelligence can anticipate a failure before it happens

Artificial intelligence compares the machine's current behavior against its normal pattern and flags the deviation while it is still manageable.

No research laboratory is needed. What is needed is a clean time series: working hours, alarms already issued by the control panel, temperatures if a sensor is present, parts produced, scrap, stoppages already recorded. The model, even a simple one, learns the range in which that machine operates well. When vibration or cycle time moves outside that range, the alert goes to whoever can stop the machine in an orderly way, not to the entire company in a panic. Predictive AI maintenance, in a small or medium-sized enterprise, is exactly this: an operational threshold, a responsible person, a planned action.

A realistic path, even in 2026, follows short and verifiable steps:

1. Choose two or three critical machines, those whose stoppage stops the rest of the line.
2. List the data already available (control panel, management system, parts counter, repair reports) before buying sensors.
3. Define what is "normal" for each machine, together with the shop floor supervisor, not based on a generic catalog average.
4. Establish who receives the alert, during which time window, and which intervention is authorized without a meeting.
5. Measure, after a few weeks, whether alerts arrive before the stoppage and whether there are too many or too few.

What to actually monitor, from machine data to wear signals

The variables to monitor are those that change before a failure, not every number the machine is capable of emitting.

The typical risk is saturating the dashboard with unreadable curves. Fewer series, each linked to an intervention, work better. Vibration on the assembly that has historically broken down. Temperature on the gearbox that has already caused problems. Cycle time relative to the part being machined. No-load power consumption, which often anticipates friction. Scrap count on a specific operation. In this sense, automating maintenance means getting those numbers to the decision-maker, in the same place where orders and shifts are already managed.

• Serial number and working hours, always, otherwise the history cannot be accumulated.
• Last intervention and part used, to see whether the same component returns too soon.
• Current load or recipe, because a harder batch explains a spike that is not a failure.
• Post-repair inspection result, to close the loop.
• Alert with a responsible person and a time window, otherwise the signal dies overnight.

Common mistakes in the transition from reactive to predictive maintenance

The first mistake is copying a dashboard from a much larger plant, with dozens of analog inputs, and then having no one to read it. The second is treating every spike as an emergency, until alerts are ignored. The third is leaving data inside the machine builder's software, disconnected from the management system, so production and maintenance continue to communicate verbally. The fourth is asking artificial intelligence to "predict everything" without having defined what an acceptable stoppage is and what is not.

How to get started without an internal IT department

You start with the machines that stop the line, the data already available in-house, and a written intervention rule, not an endless IT project.

A small or medium-sized enterprise owner typically does not have a dedicated systems manager for diagnostics. They can still ask the machine builder which alarms the control panel already exposes, organize the repair reports, and have a three-line procedure written down: if the temperature of assembly X exceeds the agreed range, stop at the next batch changeover and call the technician. Automation comes later, to avoid depending on the memory of whoever is on shift. Off-the-shelf workshop tools, when they remain isolated, stall at exactly this point: the data is there, the workflow is not. This is the same issue described in the piece on custom software for manufacturing SMEs when off-the-shelf tools hold you back.

A workshop with many machines

A workshop with many machines cannot instrument its entire fleet in the first month. It chooses the three machines that, if they stop, also stop the others. For those three, it aligns serial number, hours, recent spare parts, and alarms already present. After a real production cycle, not a lab test, it becomes clear whether alerts arrive in advance. Only then does the scope expand. This order avoids turning predictive maintenance into a project that no one in production has time to follow.

Without a threshold, a responsible person, and a planned action, machine data remains an archive: it does not become maintenance.

What Leomat can do for workshop maintenance

Leomat works on software automation, not industrial automation (machinery, systems, and factory robotics): it designs custom automations in pure code and management systems built around the company, so that the data already available, serial numbers, and interventions all sit within the same workflow.

The philosophy is straightforward to state and serious to apply: artificial intelligence should not remain a privilege of large plants. For an Italian small or medium-sized enterprise, this means visible rules, no bloated processes, and a partner that writes software around the way the workshop already operates. The current approach is development in pure code, chosen to maintain control of the workflow without depending on third-party visual tools. Where a governance system is needed, the development of a custom ERP for the company comes into play, with machine records, interventions, and production all in the same place.

One example, in a different process but with the same logic of recovered time, is ERP Costruzioni, in the construction sector: preparing a quote went from 8 hours to 5 clicks in 30 days. The parallel in a workshop is clear. The value lies in removing manual steps between signal, decision, and document, not in adding a decorative dashboard. Leomat designs and builds custom web software, with transparency about what is truly needed and what would only complicate the shift.

This post was created with AI

What is the difference between scheduled and predictive maintenance?

Scheduled maintenance follows a date or a number of hours, regardless of the machine's actual condition at that moment. Predictive maintenance reads wear signals (vibration, temperature, cycle time, scrap) and proposes an intervention when the deviation becomes significant. The two complement each other: the calendar remains for oil changes and legally required checks, while predictive maintenance covers the failures that the calendar does not see between one visit and the next.

What data is needed to get started in a small enterprise without new sensors?

Working hours, alarms already issued by the control panel, parts produced, scrap, repair reports, and spare parts used on the serial number are often enough. You start with the machines whose stoppage stops the line. New sensors come later, only for the variables that existing data does not cover. Without a serial number and a person responsible for the alert, even an expensive sensor goes unused.

How can you prevent alerts from being ignored by the shift?

You define a threshold together with the shop floor supervisor, decide who receives the alert and during which time window, and write down the authorized action (stop at the next batch changeover, inspect, call the technician). If every spike becomes an emergency, the shift stops reading the alerts. Fewer alerts linked to a real intervention work better than a flood of notifications with no operational consequence.

Can predictive maintenance be done without an internal IT department?

Yes, if the scope is small and the workflow is written down. Two or three critical machines are chosen, the data already available in-house is used, and the intervention rule is set. On the software side, a partner that develops custom automations in pure code can connect the available data, the management system, and the alerts without asking the business owner to become a systems administrator; access to the control panel data must be agreed upon with the machine builder. The mistake is opening a large project before having measured even a single avoided stoppage.