Definition
Maintenance Schedule (Maintenance Plan) defines the cycles and tasks of equipment upkeep and inspection, supporting triggers based on cycles (day/week/month) or conditions such as RUL. In conjunction with Maintenance Window, OTA and maintenance tasks can be executed within specified time windows, and it can interface with CMMS.
Schedule Types and Triggers
Maintenance schedules can be based on fixed cycles (e.g., every 30 days, every 1000 operating hours) or condition-based triggers (e.g., RUL falls below a threshold, Device Health Score decreases). Schedule content may include inspection items, maintenance items, OTA upgrades, configuration deployment, etc. After being triggered, a Work Order can be generated or remote tasks can be executed directly; execution times can be restricted within the Maintenance Window. When integrated with Preventive Maintenance and Predictive Maintenance, it forms a complete maintenance strategy system.
Integration with DMP
Device Management Platform provides functions such as schedule configuration, trigger engine, work order linkage, and execution tracking. Plans can be associated with Device Grouping to enable batch scheduling; integration with CMMS and EAM allows plans and work orders to be synchronized with the asset system. The platform can dynamically calculate the next scheduled time based on device operation data (such as last maintenance time and cumulative operating hours) and supports evolution from fixed-cycle to on-demand maintenance.
Use Cases
It is suitable for periodic maintenance of industrial equipment, inspection of energy facilities, and scheduling of T-Box software upgrades in connected vehicles. Maintenance planning is an important part of the full lifecycle management of equipment and can significantly reduce unplanned downtime and maintenance costs.
A planned trigger versus an emergency repair
A maintenance schedule is a trigger rule written in advance, plus a set of work to do. The rule can watch the calendar, such as a given week each quarter, or it can watch runtime or output the device itself has accumulated. When the point arrives, it creates a task or a work order. It does not wait until someone remembers and then backfills a ticket. The difference from a breakdown repair is that the repair is driven by a fault that has already happened, while the schedule is driven by a due point that has not. The schedule should state the scope, the work, whether a stop is required, and the counter to write back when the work is done. The four words "regular service" do not tell the person doing it which items to check or what counts as finished. If an upgrade sits on the same schedule, mark whether this replaces an image or is only an inspection. The way back is not the same. If an over-the-air update is triggered by the schedule, it still has to obey version matching and window limits. "The day has come" does not skip those checks. The schedule itself does not predict remaining life. It only lays the work out on the agreed beat.
Records that automatic tasks depend on
A calendar schedule needs one time zone and a clear rule for whether decommissioned devices are included. A runtime schedule needs a cumulative value that can be trusted, and the reading at the last completion. With no write-back of completion, the next round either never arrives or is generated again on every evaluation. If a condition uses a health or life estimate, "below a threshold" has to be a rule that can be checked again, and there has to be a rule for when the estimate is missing: postpone, or fall back to the calendar. When a bulk schedule expands by group, devices in the group were not installed on the same day. They cannot share one "first execution day" with no offset. Before a task is generated, an open unfinished order should be avoided, so the same device does not carry two orders with the same content. Work that can be finished remotely and work that requires a visit have to be split, or the dispatch is missing the site conditions. While telemetry is interrupted, runtime should not be treated as zero, and it should not keep being extrapolated at the last rate for too long. A long extrapolation moves the schedule earlier or later to a date that has no basis.
Runtime hours and calendar days mixed into one rule
Writing "every 30 days or every 1,000 hours, whichever comes first" into one rule, without recording which condition actually hit, means the next baseline cannot be updated. Using the work-order creation time as the completion time, rather than the time the work finished on site, moves the calendar forward and shortens the service interval. After a controller is replaced and the cumulative time returns to zero, the schedule treats it as a new device and schedules work that was just done. Or it inherits the old device's cumulative value, and the new unit shows as overdue at once. Devices that are decommissioned or still in stock are still named by the calendar, and orders are generated that cannot be carried out. Calculating the time zone from where the platform sits puts "the first of the month" for a device in another region on a different local date. Changing the period without anchoring past completions makes the system recompute the new period from a very early installation date and backfill a long string of overdue tasks. Sharing one completion flag between an upgrade schedule and an inspection schedule means checking the inspection off also closes the upgrade.