Reference · built on requestOperator by FibricProduction & maintenance

Line Downtime

Pins each unplanned stop to a station and cause from PLC faults and operator reason codes. Proposes work orders for repeat stops.

Request accessPricing ↗

About

A line stops. The PLC raised a fault word, the operator typed a reason code, and the alarm journal logged a timestamp. Line Downtime joins those three records into one stop with a station, a start, an end, and a cause. It reads run and stop bits and fault codes over OPC UA subscriptions, alarms as OPC UA Alarms and Conditions, and reason codes from the HMI, the Ignition alarm journal, or an MES table.

When the same station and fault code stop the line more often than the threshold you set, it proposes a work order in your CMMS with the stop list attached. Where a stop has no reason code, or the code contradicts the fault, it proposes a classification for the supervisor to accept or change.

This is a reference listing. It documents what Fibric would read from Line Downtime 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 and stop bits per station over OPC UA subscriptions, or from tag history in Ignition or KEPServerEX
  • Fault codes and fault words from the PLC at the moment a station stops, mapped to causes with the table you supply
  • Controller alarms as OPC UA Alarms and Conditions, with ActiveState, Acknowledge, Confirm, and Comment, as SIMATIC S7-1500 CPUs expose them
  • Operator reason codes from the HMI, Ignition alarm journal entries with source and timestamp, or Tulip table records
  • Downtime annotations and machine states in MachineMetrics for lines already monitored there
  • Open work orders on the same asset in Fiix, MaintainX, UpKeep, or Limble CMMS, so a repeat stop is not proposed twice

Proposed actions

  • Target capability: propose a CMMS work order for a station whose same fault code has stopped the line past your count, with the stops attached
  • Target capability: propose a reason code for a stop the operator left blank, taken from the PLC fault code map, for the supervisor to accept
  • Target capability: propose a reclassification where the operator's reason code and the PLC fault disagree, showing both
  • Target capability: propose a shift summary to a Microsoft Teams or Slack channel: top stops by station and cause, with durations
  • Target capability: propose a downtime annotation in MachineMetrics for a stop the machine monitor recorded without a reason

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

What you can build

  • Same fault, again

    A guard-door fault has stopped one station repeatedly this week. Line Downtime proposes a Fiix work order on the station with each stop, its duration, and the PLC code behind it.

    With OPC UA, Fiix

  • Fill in the blank reason codes

    Many night-shift stops carry no reason code. Each blank with a matching PLC fault gets a proposed code from the map, and the supervisor approves them in one pass from a Tulip table.

    With Ignition, Tulip

  • Alarms straight from the S7

    An S7-1500 raises ProDiag supervisions as OPC UA alarms. The operator reads ActiveState and the alarm text, ties each to a station, and proposes a MaintainX work order when one keeps returning.

    With SIMATIC S7-1500, MaintainX

  • One shift note per line

    At shift end it proposes a Teams post: the longest stops per line, the station, the cause, and which of them already have a work order open, with MachineMetrics states as the source.

    With MachineMetrics, Microsoft Teams

Requirements

  • An OPC UA, SIMATIC S7-1500, Ignition, or KEPServerEX connector with run state and fault code tags per station on its allow-list
  • A fault code map: which PLC code means which cause, per station, maintained by you
  • One CMMS connector with the stations as assets: Fiix, MaintainX, UpKeep, or Limble CMMS
  • A source of operator reason codes: HMI tags, the Ignition alarm journal, a Tulip table, or MachineMetrics annotations
Authentication
Line Downtime carries no credentials. It reads tags and alarms through your OPC UA, Ignition, or PLC connector and writes work orders and notes through the CMMS and messaging connectors under their scopes.

Limits

  • Attribution stops at the fault code map. A station that exposes only a run bit gets a stop and a duration, not a cause.
  • A stop shorter than the subscription's sampling interval can be missed or merged with its neighbor.
  • It never acknowledges or confirms an alarm and never writes to a PLC.
  • Reason codes are what people entered. The operator proposes a different one; it does not overwrite a code without approval.

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 Line Downtime ↗

Questions and answers

What does a person approve?
Every work order, reason code, reclassification, and channel post. The proposal shows the station, the stops behind it, the PLC code, the operator code, and any open work order on the asset. Approve, edit the cause or the assignee, or dismiss. A dismissed pattern is proposed again only when a new stop joins it.
What record does a stop leave?
One stop record per event: station, start, end, PLC fault, operator reason, and the classification that stood at the end. Every proposal leaves a receipt: what was proposed, who approved, what was written to the CMMS, and how to undo it.
What does it never do on its own?
It never files a work order, changes a reason code, acknowledges an alarm, or posts to a channel without approval. It never writes a tag. If the fault code map has no entry, it proposes nothing and marks the stop unclassified.
Ask about Line Downtime

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