The Calendar PM Problem
Every production facility runs maintenance on a calendar schedule. Change the oil at 250 hours or 3 months, whichever comes first. Inspect the conveyor belt monthly. Service the compressor quarterly. These intervals are set from manufacturer recommendations and industry standards — and they’re wrong for some percentage of the equipment they’re applied to.
Plant Engineering research consistently shows that approximately 82% of equipment failures are random — they don’t occur at predictable intervals relative to time or use. The failure of a bearing doesn’t know that 90 days have passed since the last inspection. The degradation of lubricant depends on operating temperature, load, contamination exposure, and starting condition — not the calendar.
Calendar PM produces three outcomes:
- Timely PM: The scheduled interval happens to align with when the equipment actually needed attention
- ==negative:Premature PM: The equipment is serviced before it needs it — wasting maintenance labor and parts,== and potentially introducing failure modes from the maintenance work itself (improper reassembly, torque errors, contamination during service)
- Late PM: The equipment was already developing a failure condition when the PM was performed — or developed one between inspections
Condition-based maintenance changes the paradigm: the sensor tells you when the equipment needs attention, not the calendar.
Why CMMS and IoT Are Usually Disconnected
The CMMS that most manufacturing operations use was built to manage work orders, labor, and parts. It knows what was done to which asset, when, and by whom. It’s excellent at the documentation side of maintenance management.
What most CMMS systems don’t do is know what the equipment is currently doing. The CMMS has no connection to the sensors that monitor the equipment. The alert that fires in the IoT monitoring system is invisible to the CMMS. The work order in the CMMS has no record of the sensor condition that should have triggered it.
The maintenance technician receives an alert on their phone, walks to the machine, assesses the condition, goes to the CMMS to create a work order, completes the repair, and closes the work order. The CMMS record shows the repair was performed. It has no record of the sensor reading that indicated the problem, the time between when the problem first appeared and when it was addressed, or whether the repair resolved the condition.
ArgusIQ’s integrated CMMS eliminates this gap. The CMMS and the IoT monitoring system are not separate systems connected by an API. They’re one system with one data model.
How ArgusIQ’s Integrated CMMS Works
Automatic Work Order Generation from Sensor Conditions
ArgusIQ’s Alarm Engine evaluates sensor readings against configured conditions. When a condition is met, it can trigger multiple simultaneous actions — and one of those actions is creating a CMMS work order.
The work order is created automatically, without requiring a human to see the alert, interpret it, and manually create a work order. The time between condition detection and work order creation is seconds, not the minutes to hours that a human-in-the-loop process requires.
The work order that’s created isn’t empty. It contains:
- The triggering sensor condition (what reading, at what value, compared to what baseline)
- The current sensor readings at the time of work order creation
- The asset identity record (machine, manufacturer, model, serial number, location)
- The maintenance history for this asset — every prior work order, every prior repair finding
- Recommended parts based on the asset’s maintenance history (if this condition has been resolved before, the parts used previously are surfaced)
- The work order type and priority, configured in the Alarm Engine rule
The technician assigned to the work order arrives at the machine with full context. They know what the sensor detected, how it compares to the asset’s normal operating baseline, and what was done the last time this condition appeared.
Condition Types for Work Order Triggers
ArgusIQ CMMS supports multiple condition trigger types:
Threshold exceedance: A reading above or below a configured value triggers a work order. “Bearing temperature above baseline + 15°F for more than 2 hours.”
Rate of change: A rapid change in a reading, regardless of absolute value, triggers a work order. “Vibration RMS increased by more than 0.4 g in a 6-hour window.”
Pattern match: Current readings match a historical pre-failure pattern. “Current vibration signature matches the pattern that preceded the bearing failure on March 15th.”
Operating hours: Accumulated operating hours from sensor data reach the PM service interval. “Motor has accumulated 500 operating hours since last bearing inspection.” This is different from calendar-based PM: the hours counter knows how much the machine has actually run, not just how many weeks have passed.
Sensor offline: A device stops reporting, which may indicate a sensor failure or — for equipment that should always be running — an unexpected process stoppage.
The Operating Hours-Based PM: Better Than Calendar
For equipment where PM intervals are properly measured in operating hours, ArgusIQ’s approach is materially better than calendar-based scheduling.
A motor that sits idle most of the time doesn’t accumulate hours on the calendar the way its 90-day PM interval assumes. A motor that runs two shifts instead of one accumulates hours twice as fast. Calendar PM either services both machines at the same interval — one too frequently, one not frequently enough — or requires manually adjusting schedules for each machine based on estimated usage.
ArgusIQ’s IoT Hub reads operating status from the motor (running/stopped from current sensor or vibration sensor) and accumulates operating hours in the asset record. The PM schedule triggers at the configured hour threshold — 500 hours, 1,000 hours, whatever the service interval should be — regardless of whether that threshold is reached in 3 months or 9 months based on actual usage patterns.
The motor that runs rarely gets its PM when it needs it. The motor that runs constantly gets its PM on time. Calendar PM services neither correctly.
Closing the Loop: What Good Documentation Makes Possible
The maintenance history that ArgusIQ accumulates — every condition that triggered a work order, every repair finding, every parts record, every post-repair sensor confirmation — is the foundation for progressively better maintenance decisions.
Pattern recognition: After 20 documented instances of a specific failure mode on a specific equipment type, the data shows what the sensor readings looked like 12, 24, 48, and 72 hours before the failure. That pattern becomes the template for early-warning detection on the same equipment type.
PM interval optimization: If PM work orders for a specific equipment type consistently show that the serviced component was in good condition — lubricant was still clean, bearing showed no wear — the PM interval may be set too short. The documented findings support the decision to extend the interval. If PM work orders consistently show degradation at the scheduled interval, the interval may be set too long.
True maintenance cost per asset: With work orders linked to specific assets and containing labor and parts costs, ArgusIQ calculates the total maintenance cost per asset, per asset type, and per production line. The compressor that costs 3× as much to maintain per operating hour as comparable units becomes visible — and becomes the candidate for replacement planning.
Resolution verification: When a work order is closed, ArgusIQ checks whether the relevant sensor readings returned to baseline range within 24 hours of closure. Work orders where post-repair readings remained anomalous are flagged for follow-up investigation — catching repairs that didn’t fully resolve the underlying condition.
Integration With Existing CMMS Systems
Not every organization deploying ArgusIQ is ready to migrate from their existing CMMS. For organizations with significant existing CMMS investments (SAP PM, IBM Maximo, ServiceMax), ArgusIQ provides bidirectional integration:
- Alert-to-ticket: ArgusIQ alarm conditions create tickets or work orders in the external CMMS via API
- Completion feedback: CMMS work order completions update ArgusIQ’s maintenance history record
- PM schedule sync: CMMS PM schedules are visible in ArgusIQ, and ArgusIQ can push operating hours back to the CMMS for hours-based PM triggering
The integration preserves the existing CMMS investment while adding the condition-based trigger capability that the CMMS alone doesn’t have.
For new deployments, ArgusIQ CMMS is the recommended path — one system, one data model, no integration to maintain.
Talk to our team about ArgusIQ CMMS for your maintenance operation.