Cut Downtime 35%: PM Work Orders by Runtime Recipe 2026

Calendar-based preventive maintenance was the best available approach when data was expensive and equipment runtime was hard to track. In 2026, runtime data flows from PLCs, SCADA systems, and IoT sensors in near-real time — and the manufacturers winning on equipment uptime have made one structural change: they trigger PM work orders by actual machine runtime, not by calendar date.

The difference matters because calendar-based maintenance creates two failure modes simultaneously. Over-maintenance: a machine serviced at week 4 even though it ran only 60 hours (spec says service at 250 hours) — wasted labor, unnecessary part consumption, and unneeded downtime. Under-maintenance: a high-volume line running 3 shifts a week reaching 250 hours in 17 days, but the calendar says service isn't due for another 13 days — preventable breakdowns.

Runtime-triggered PM automation eliminates both failure modes.

TL;DR: This recipe connects your runtime data source (PLC, OPC-UA, IoT sensor) to your CMMS or ERP to fire PM work orders automatically when a threshold is crossed — no scheduler required.

Key Takeaways

• Runtime-triggered PM eliminates the two failure modes of calendar PM: over-maintenance of lightly-used equipment and under-maintenance of equipment running multiple shifts

• The four-component architecture (runtime source, threshold monitor, work order creator, state manager) can be assembled from tools most mid-size manufacturers already own

• Plants shifting from calendar to usage-based PM reduce unplanned downtime by 31–38% within 18 months, per Aberdeen Group benchmarks

• The NOT exists duplicate guard and baseline-reset-on-completion webhook are the two most commonly skipped implementation steps — both are required for production reliability

• Per-asset thresholds outperform class-level thresholds because individual machine wear profiles diverge significantly even within the same model family

Who This Is For

This recipe is for maintenance engineers, plant managers, and operations directors at discrete and process manufacturers running 50+ pieces of trackable equipment, with an existing CMMS (Fiix, eMaint, UpKeep, or SAP PM) and at least one digital runtime data source.

Red flags: Skip this if your equipment runtime is not currently tracked digitally (paper logbooks require a data entry step that breaks real-time triggering), if your CMMS does not accept API-created work orders, or if your maintenance team is under 5 people (manual threshold tracking is manageable at that scale). Also skip if you are operating in an environment where your CMMS is air-gapped and cannot receive API calls from an external orchestration layer — on-premise integrations require a different architecture.

Why Runtime Beats the Calendar

According to the Aberdeen Group's Manufacturing Maintenance Benchmark (2024), plants that shifted from time-based to usage-based PM programs reduced unplanned downtime by an average of 31–38% within 18 months of implementation. The mechanism is straightforward: equipment that runs more than expected accumulates wear faster; equipment that runs less accumulates wear slower. A fixed calendar interval serves neither well.

Unplanned downtime cost in discrete manufacturing: $260,000/hr according to Vanson Bourne's 2024 Manufacturing Downtime Report for Siemens. Even a single avoided breakdown on a critical line pays for months of automation infrastructure.

According to the Association for Manufacturing Excellence (AME) 2024 Benchmarking Survey, manufacturers operating runtime-triggered PM programs saw average OEE improvement of 4–7 percentage points versus calendar-only PM programs, driven primarily by reduced unexpected stoppages.

According to the Plant Engineering 2024 Maintenance Reliability Survey, 62% of plants still schedule preventive maintenance exclusively by calendar interval despite acknowledging that actual runtime hours vary by 40–80% week-over-week during demand cycles — making calendar-based intervals a structural mismatch for variable-volume production.

Runtime-triggered PM programs recover an average of 4.2 additional production hours per asset per month versus calendar-only PM, per Aberdeen Group's 2024 Manufacturing Maintenance Benchmark. Plants implementing OPC-UA runtime feeds into their CMMS reduce PM labor costs by 10–15% per asset per year by eliminating unnecessary maintenance events.

The Architecture: Four Components

A runtime-triggered PM system has four components, each of which may already exist in your stack:

1. Runtime data source — A PLC counter, SCADA system, or IoT sensor that records operating hours (or cycles, or units produced) and exposes that data via OPC-UA, MQTT, or a REST API.

2. Threshold monitor — A process that reads runtime data on a polling interval (every 15 minutes is typical) and compares the current value against a stored threshold for each asset.

3. Work order creator — An API call to your CMMS that creates a new PM work order when the threshold is crossed, pre-populated with the asset ID, PM task template, assigned technician, and priority level.

4. State manager — A system that updates the asset's baseline after the PM is completed, resetting the counter for the next interval, and alerts if a PM is created but not completed within an SLA window.

Step-by-Step Recipe

Step 1: Catalog Your Assets and Thresholds

Start with a written list of every asset that will participate in runtime PM, along with its OEM-recommended service intervals. Express each interval in your primary runtime unit: hours for most equipment, cycles for stamping presses and injection molders, units-produced for process equipment with part counters.

Step 2: Expose Runtime Data via API

For PLC-connected equipment, an OPC-UA server (built into most modern PLCs) exposes runtime counters as addressable nodes. An OPC-UA client library reads the runtime value on a polling interval and writes it to a time-series database or directly to your integration middleware.

For IoT-connected equipment, MQTT is the common protocol. A sensor publishes runtime_hours to a topic like plant/floor2/cnc_01/runtime, and the middleware subscribes.

For equipment without digital runtime data, a low-cost IoT current monitor (Emporia Vue, for example) can infer runtime from power draw — if the machine is drawing power, it's running.

Step 3: Configure the Threshold Monitor

The threshold monitor is a polling process — a cron job, a workflow trigger, or an event-driven function — that reads current runtime for each asset and compares it against the stored threshold. The comparison logic is:

IF (current_runtime - last_pm_runtime) >= pm_threshold_hours
AND NOT exists(open_pm_work_order FOR asset_id)
THEN create_work_order(asset_id, pm_template_id)

The NOT exists guard prevents duplicate work orders if the threshold is crossed on two successive polls before the first order is acknowledged.

Step 4: Create the Work Order via CMMS API

Most modern CMMS platforms accept work order creation via REST API. In Fiix, the endpoint is POST /api/v3/workOrders. The payload includes:

{
  "assetId": "[asset_uuid]",
  "workOrderCode": "PM-[asset_id]-[timestamp]",
  "type": "Preventive",
  "priority": 2,
  "taskListId": "[pm_template_id]",
  "assigneeId": "[technician_id]",
  "dueDate": "[today_plus_SLA_days]",
  "description": "Runtime threshold reached: [current_hours] hr since last PM"
}

The key fields are assetId (links to the asset record), taskListId (pulls in the pre-built PM task checklist), and dueDate (sets the SLA clock).

Step 5: Reset the Baseline on Completion

When the technician completes the PM work order, the CMMS fires a workOrder.statusChanged webhook (available in Fiix, eMaint, and most enterprise CMMS platforms). The middleware receives that event and updates the stored baseline: last_pm_runtime = current_runtime. The threshold counter resets, and the cycle begins again.

Step 6: SLA Alert on Overdue PM

If a PM work order is not completed within the SLA window (commonly 48–72 hours for non-critical, 4–8 hours for critical equipment), the system fires an alert to the maintenance supervisor via email and SMS. The alert includes the asset ID, current runtime overage past threshold, and the overdue work order number. This closes the loop on the most common gap in manual PM programs: the work order that was created but never prioritized.

Worked Example: 14-Asset CNC Cell, 3-Shift Operation

Consider a CNC cell running 14 machining centers across 3 shifts, averaging 105 operating hours per machine per week. Each machine requires PM at 250 runtime hours — which means on average, the threshold is crossed every 2.4 weeks. Before automation, the maintenance scheduler reviewed runtime logs on Fridays and manually created work orders for any machine approaching 250 hours. On high-production weeks, machines would reach the threshold mid-shift and no order was created until the Friday review — meaning some machines ran 270–290 hours before a work order appeared.

After connecting the OPC-UA runtime_hours node on each Fanuc controller to a threshold monitor that polls every 30 minutes and fires a POST /api/v3/workOrders to Fiix when the (current_runtime - last_pm_runtime) crosses 250 hours, every PM work order is created within 30 minutes of threshold crossing — not on the next Friday. Average runtime overage at work order creation dropped from 22 hours to 0.4 hours. Over 14 machines running approximately 21 PM cycles per machine annually, the reduction in overage exposure corresponds to roughly 296 hours of high-wear runtime avoided per year. At an estimated $4,200 per spindle rebuild event (parts + 6-hour downtime), avoiding even 3 additional spindle events per year recovers $12,600 — on a monitoring infrastructure that costs under $2,000/year to operate.

Common Mistakes in Runtime-Triggered PM Programs

Using only the PLC's internal runtime counter without accounting for idle time. Most PLC "power on" counters include standby time when the machine is energized but not cutting. True cutting time is a different register — check your controller's address map for the specific operational counter.

Setting a single threshold per asset class instead of per-asset. A 2017 Haas VF-2 and a 2022 Haas VF-2 may have the same model but very different wear profiles. Per-asset thresholds based on historical data outperform class-level thresholds.

Not handling the "already past threshold" case on initial setup. When you first connect a machine that's been running on calendar PM, the current runtime since last PM may already exceed the threshold. Your threshold monitor needs to handle this gracefully — either create an immediate work order or prompt a one-time reset.

Skipping the NOT exists duplicate guard. On a 15-minute polling interval, a machine that crosses the threshold at minute 1 of the poll window will trigger on both the first and second poll before an order is created. Without a duplicate guard, you get two identical open work orders.

Benchmarks: Runtime PM vs Calendar PM

According to McKinsey & Company's 2024 Manufacturing Productivity Report, plants that have implemented usage-based maintenance triggers as part of a broader operational excellence program see 8–12% improvement in overall equipment effectiveness within 24 months, driven primarily by reduced unplanned stoppages and optimized PM interval alignment.

Implementation Cost and Payback Estimates

The infrastructure for runtime-triggered PM is lighter than most operations teams expect. The costs below are representative for a 20-asset deployment using OPC-UA-connected equipment and an existing CMMS with REST API access.

Tool Landscape for Runtime-Triggered PM

Several platforms handle parts of this workflow. The right combination depends on your equipment connectivity and CMMS maturity.

US Tech Automations connects to your existing CMMS API and your runtime data source via OPC-UA, MQTT, or REST — handling the threshold comparison, duplicate guard, work order creation, and SLA escalation as a single orchestrated flow. The platform is positioned as a peer integration layer alongside your CMMS and SCADA tools, not a replacement for either.

When NOT to use US Tech Automations: If your CMMS already supports meter-based PM scheduling natively (Fiix and SAP PM both do, for equipment with direct CMMS meter integration), and your equipment runtime data feeds directly into the CMMS meter, use the native feature. The orchestration layer adds value when your runtime data lives in a SCADA or IoT platform that doesn't have a native CMMS connector, or when your work order creation logic requires conditional branching (different PM templates by shift, by technician certification, or by production schedule) that the native CMMS scheduler doesn't support.

Glossary

• Runtime-triggered PM: Preventive maintenance work orders created when a machine's accumulated operating time (or cycles) reaches a preset threshold, as opposed to a fixed calendar interval.

• OPC-UA: Open Platform Communications Unified Architecture — the standard protocol for exchanging data between industrial equipment (PLCs, SCADA) and enterprise systems.

• CMMS: Computerized Maintenance Management System — software that manages work orders, asset records, and PM schedules (Fiix, eMaint, UpKeep, SAP PM).

• OEE: Overall Equipment Effectiveness — a composite metric of availability, performance, and quality (100% = perfect production).

• Baseline reset: Updating the "last PM" runtime value after a PM is completed, which restarts the counter for the next interval.

• SLA window: The elapsed time within which a PM work order must be completed before an escalation alert fires.

FAQs

How accurate does runtime data need to be for threshold-triggered PM?

Accuracy within ±2% is sufficient for most PM applications. A threshold set at 250 hours with runtime data accurate to ±5 hours is still dramatically better than a 14-day calendar interval for a machine that might run 100 hours or 300 hours in that window.

What if my machines don't have digital runtime counters?

Current-based IoT monitors (clamp-on sensors measuring amp draw) can infer runtime with 95%+ accuracy for machines with consistent load profiles. Installations start around $50–$150 per machine for the sensor, with data available via MQTT or REST. This is the lowest-cost path to digitizing runtime for older equipment.

Can I use this recipe with SAP PM?

Yes. SAP PM's Counter-Based Maintenance Plans natively support threshold triggering when runtime data is fed into SAP's PM_COUNTER object via integration. For runtime sources outside SAP's direct ecosystem, a middleware layer reads the counter and updates the SAP PM counter object via the standard IDocs or REST API, which then triggers the native SAP PM scheduling logic.

How do I handle multi-component PM (some parts at 250 hr, others at 500 hr)?

Use separate PM task templates for each interval, each with its own threshold. When the 250-hour threshold is crossed, the work order includes only the 250-hour tasks. When the 500-hour threshold is crossed (on a separate counter), the work order includes the full 500-hour task set. Most CMMS platforms support multiple meter-based PM schedules per asset.

What happens if the CMMS API is down when the threshold is crossed?

The middleware should implement a retry queue with exponential backoff — re-attempting the work order creation every 5, 15, and 60 minutes. If the CMMS is still unavailable after 60 minutes, the system fires an alert to the maintenance supervisor with the threshold crossing details so manual action can be taken. The event should be logged with timestamp for audit purposes.

How long does implementation typically take?

For a site with OPC-UA-connected equipment and an existing CMMS with REST API access, a basic implementation (single asset, single threshold, work order creation) can be running in under a week. Scaling to 50+ assets with per-asset thresholds, multiple PM templates, and SLA escalation takes 4–8 weeks depending on equipment heterogeneity and CMMS configuration maturity.

Next Steps

Runtime-triggered PM is one of the highest-ROI automation investments available to a manufacturing maintenance team — the infrastructure is lightweight, the payback is measurable in reduced downtime and avoided repair costs, and the implementation path is well-understood.

For manufacturers ready to connect their runtime data to their CMMS without building and maintaining custom integration code, explore how this workflow fits your stack at . For shift-level communication around PM events, see . For teams also looking to reduce manual data entry across ERP and CMMS systems, the broader manufacturing data integration recipe is at .

To see how the orchestration layer handles threshold monitoring, CMMS API calls, and SLA escalations for manufacturing environments, visit US Tech Automations pricing for a plan comparison by asset count and integration complexity.