Reference · built on requestOperator by FibricFacilities & comfort

Service Interval

Turns equipment run hours into due dates and proposes preventive maintenance work orders in your CMMS on working days.

Request accessPricing ↗

About

Pumps, fans, compressors, and drives are serviced by run hours or by calendar, whichever comes first. The hours sit in a controller or a drive; the plan sits in the CMMS; the two rarely meet. Service Interval reads run-hour counters over BACnet/IP or from drive registers over Modbus TCP, and the preventive maintenance plan for each asset from your CMMS.

From the rate at which hours accrue, it projects when each interval will be reached, and proposes the work order on a working day before that date, skipping public holidays. It also proposes the hour readings themselves, so the CMMS meter matches the machine. You approve each order and each reading.

This is a reference listing. It documents what Fibric would read from Service Interval and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Run-hour and start-count accumulators on equipment controllers over BACnet/IP, or run state where no counter exists
  • Run hours and fault codes from drive and motor controllers over Modbus TCP, on the registers you map per device
  • Scheduled maintenance in Fiix, preventive maintenance templates in UpKeep, meter triggers in MaintainX, or PM tasks in Limble, with their intervals
  • Meter readings already recorded in the CMMS against each asset, so a proposed reading continues the series
  • Public holidays for the site's country by year from the Nager.Date holidays endpoint
  • Open and completed work orders on the asset, so an interval already serviced restarts from the completion date

Proposed actions

  • Target capability: propose a run-hour meter reading against the asset in your CMMS, at the cadence you set
  • Target capability: propose a preventive maintenance work order dated to a working day before the projected interval, for your approval
  • Target capability: propose moving a calendar-based task earlier when hours are accruing faster than the plan assumed
  • Target capability: propose deferring a calendar-based task when the hours show the unit barely ran, for a person to decide
  • Target capability: propose a check on an asset whose counter stops moving while its run state shows it running

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Service a pump on hours, not on a guess

    Run hours from a pump drive are read over Modbus TCP and proposed as Fiix meter readings. When the interval nears, the operator proposes the work order on the last working day before it, clear of the holiday.

    With Modbus TCP, Fiix, Holidays & FX Reference

  • Move a task that will arrive early

    A rooftop unit has run through a hot month. The BACnet/IP counter shows the interval will fall before the UpKeep template's date, so the operator proposes bringing the task forward.

    With BACnet / IP, UpKeep

  • Give Maximo the hours it plans on

    Compressor hours from the controller are proposed as meter readings on the IBM Maximo Manage asset, so the preventive maintenance plan there runs on the same hours the machine keeps.

    With Modbus TCP, IBM Maximo Manage

  • Notice a counter that stopped

    A fan shows running in Niagara while its hours stand still. The operator proposes a MaintainX work order to check the counter before the interval is missed.

    With Tridium Niagara, MaintainX

Requirements

  • A BACnet/IP connector with run-hour points on its allow-list, or a Modbus TCP connector with a register map for each drive or controller
  • One CMMS connector: Fiix, UpKeep, MaintainX, Limble CMMS, or IBM Maximo Manage, with the assets and their intervals
  • A service interval per asset in hours, calendar time, or both, from the maker's guidance or your own plan
  • The country and subdivision of each site, for the holidays feed
Authentication
Service Interval keeps no credentials. Counters are read through your BACnet/IP or Modbus TCP connector, and readings and work orders are written through the CMMS connector, each under the scopes you granted that connector.

Limits

  • Where a controller has no counter, hours are accrued from run state at the polling interval, and short runs between polls are missed.
  • Modbus register maps differ by device and maker. Each drive needs its map supplied before its hours can be read.
  • Intervals come from your records. The operator projects a date; it does not decide what an interval should be.
  • It proposes readings and work orders only. It writes nothing to a controller or drive.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Service Interval ↗

Questions and answers

What does a person sign off on?
Every meter reading and every work order. The proposal shows the asset, the hours read, the rate, the projected date, the plan in the CMMS, and the working day chosen. You can approve, move the date, or dismiss. Deferrals are always a person's decision.
What record is kept per asset?
A receipt per proposal: the counter value and its source, the projection, the holiday calendar consulted, who approved, and what was written to the CMMS. Readings the operator proposed are marked as such, so a technician's own readings stay distinct.
Can it reset a counter or change a plan on its own?
No. It reads counters and plans and proposes readings and orders. It never writes to a controller or drive, never edits an interval, and never closes a work order. If a plan should change, it proposes the change and a person makes it.
Ask about Service Interval

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy