Maintenance Management System (CMMS)

Sensor data from META Smart I/O devices or existing PLCs. Vibration, temperature, current and cycle counts are typical inputs.

Yes, work orders, checklists and machine history are available on phones, tablets and MSF panels.

Yes. Downtime reasons recorded in MES automatically create maintenance notifications.

Preventive plans on dates or counters, work orders, spare parts reservations and machine history all run on records alone, with no sensor input at all. The first months give you failure coding, plan compliance and a downtime history, which is also the baseline any later condition monitoring gets judged against. Classifying twelve months of your own unplanned stops is what tells you which assets would justify an accelerometer.

Anything that fails without a progressive, measurable warning. Control boards, I/O cards and most discrete sensors fail close to randomly, and collisions, setup errors and operator damage are events rather than processes. A protective device such as a relief valve or an interlock emits nothing until the event it guards against arrives, so there is nothing to monitor and it is proof-tested on an interval. Vibration and current read rotating mechanical wear well and those modes not at all.

Less than a model-led proposal implies, because the first useful thresholds come from engineering rather than history: bearing defect frequencies from geometry and shaft speed, a pressure drop across a filter, a temperature rise above the machine's own normal at the same load. Anomaly detection needs enough healthy running to cover normal variation of product, speed and shift. Remaining-useful-life estimates need run-to-failure examples that most plants simply do not have.

Budget for a named owner on the maintenance side rather than a share of everybody's week. The heavy part is front-loaded: asset hierarchy, preventive plans that match what you really do, and a failure coding scheme agreed once. After go-live the recurring work is triaging alerts and closing out orders with structured findings, parts consumed and counter readings. Tune alert volume to what one person can actually investigate, or the alerts stop being opened.

MTBF is operating time divided by failure count, MTTR is total repair time divided by number of repairs, both built from work order fields: notification time, repair start and finish. Without an hour counter or an MES run signal only calendar time between failures is available, so an idle asset flatters its own MTBF. A repair figure also means different things timed from notification, which includes waiting and parts, or from repair start, which is wrench time.

No, it runs standalone. Operators raise notifications from an HMI or a browser, and the plans, work orders and spare parts side needs nothing else installed. What APS adds is that an agreed maintenance window reaches the planner as a scheduling constraint, so it no longer depends on a corridor conversation someone forgets. Without it you agree windows with production by hand, which is how plenty of plants start and a reasonable place to stay.

Rarely on its own. A warning only helps if it reliably exceeds the supplier lead time for that part, and unknown failure timing is just one reason safety stock exists. Lead-time variability, minimum order quantities and one part number covering several assets are all still there. The module reserves parts against the work order and raises a purchase when stock is short. Convert warnings into planned windows first and revisit stock levels after a year of evidence.