OEE is Availability times Performance times Quality. Availability is run time over planned production time. Performance is ideal cycle time times total count over run time. Quality is good count over total count. OEE Loss takes each input from the system that holds it: good and reject counters from the PLC over OPC UA or from Ignition Tag Historian, planned time and breaks from the MES or the ERP work order, and the ideal cycle time from the routing or a sheet you keep.
At shift end it proposes one OEE row per line for your log in Google Sheets, Microsoft Excel, or Smartsheet. Where the operator's handwritten count or downtime minutes differ from the counters by more than your tolerance, it proposes a correction that shows both figures, and the supervisor decides which stands.
This is a reference listing. It documents what Fibric would read from OEE Loss 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.
What it reads
Good count and reject count tags per station over OPC UA subscriptions, or from Ignition Tag Historian, which stores values on change with millisecond timestamps
Run and stop state per line, from which run time and stop time for the shift are derived
Planned production time and breaks per shift from Plex or Tulip, or the work order's AM Planned Start Date and work center in NetSuite
Ideal cycle time per assembly from the manufacturing routing's operation steps and run rates, or from a sheet you maintain
Operator production logs in Google Sheets, Microsoft Excel, or Smartsheet: counts, downtime minutes, and scrap entered by hand
Production rollups from the MachineMetrics Production endpoint for lines it already monitors
Proposed actions
Target capability: propose a shift OEE row per line, with Availability, Performance, and Quality and their inputs, appended to your log sheet
Target capability: propose a count correction where the logged good count differs from the PLC counter beyond your tolerance, showing both
Target capability: propose a downtime correction where logged stop minutes and the PLC's stop time disagree
Target capability: propose a review of an ideal cycle time when a line's Performance exceeds one, since the ideal on file is then too slow
Target capability: propose a Microsoft Teams note per line naming the largest of the three losses for the shift
Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.
What you can build
Counters against the clipboard
The PLC counted more parts than the operator wrote down. OEE Loss proposes a correction to the Google Sheets log with both figures and the difference, for the supervisor to accept.
Counts and run state already sit in Ignition Tag Historian. The operator computes the shift from history and appends the row to the Excel workbook the plant reports from.
Planned production time comes from the Plex job, counters from the line. The Teams note names the shift's largest loss: stops, slow cycles, or rejects.
A line reports Performance above one for a week. Rather than cap it, the operator proposes a routing review in Smartsheet, with the observed cycle time from MachineMetrics attached.
An OPC UA, Ignition, or KEPServerEX connector with good and reject counters and a run state per line on its allow-list
Scheduled time per shift from an MES or ERP connector: Plex, Tulip, or NetSuite work orders with routing
An ideal cycle time per part, from the routing or a sheet you keep
A log to write to: Google Sheets, Microsoft Excel in Microsoft 365, or Smartsheet, with the columns agreed
Authentication
OEE Loss holds no credentials of its own. Counters come through your OPC UA or Ignition connector, schedules through the MES or ERP connector, and rows are appended through the spreadsheet connector's scopes.
Limits
A counter that resets mid-shift breaks the arithmetic. The operator flags that shift for review rather than filling the gap.
Without an ideal cycle time for the part, Performance cannot be computed, and the row carries Availability and Quality only.
A station with no reject counter takes Quality from the operator log alone.
It appends rows and proposes corrections. It does not change counters, recipes, schedules, or the formulas in your sheet.
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.
Each OEE row before it is appended, and each correction. The proposal shows the three factors, the counter values, the scheduled time used, and the operator's figures beside them. Approve, edit a value, or dismiss. A dismissed correction is not proposed again for that shift.
What record is left?
The row in your sheet, with the inputs it was computed from. And a receipt per proposal: the counters read, the schedule source, the tolerance applied, who approved, what was written, and how to remove the row.
What does it never do without approval?
It never appends a row, overwrites an operator's entry, or posts a note on its own. It never edits a formula in your sheet, and it never changes a counter, a recipe, or a schedule anywhere.
Ask about OEE Loss
Ask about the capabilities and requirements in this listing.
This agent 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