Downtime
What is it?
The Downtime Manager is the FactryOS module that records and classifies production stops on your equipment. It combines automatic detection from PLC signals and shift calendars with manual operator input to build a complete picture of when equipment was not running, and why.
Why does it matter?
Without structured downtime registration, production losses stay invisible or get misattributed. You can't improve what you can't measure. The Downtime Manager gives operators, shift supervisors, and plant managers a shared, accurate record of every stop, its cause, and its duration. This is the foundation for meaningful OEE analysis and for prioritizing improvement actions.
How does it fit in the system?
The Downtime Manager sits on top of the equipment model in FactryOS. It connects to:
- Factry Historian for real-time signals (PLC alarms, speed tags, state signals)
- Shift calendars for planned stop detection
- Production orders for change-over detection
Each piece of equipment can have a state transition table assigned to it. That table defines how raw signals map to downtime states. When a stop is detected, it is linked to a downtime reason from a reason tree that is assigned per equipment. Users interact with detected events through the Downtime Overview screen.
Example
A conveyor line goes below 0.1 m/s at 13:12:20. The state transition table detects this as a production stop. At 13:18:05 the line restarts. A downtime event is created automatically:
- Asset: Line 3 Conveyor
- Start: 13:12:20
- End: 13:18:05
- Duration: 5 min 45 sec
- Category: Unplanned
- Reason: (pending operator input)
The operator receives a prompt to select a reason from the configured reason tree. They select "Insufficient feed material" and add a short comment. The event is now complete and available in OEE dashboards.
When you use it
You interact with the Downtime Manager when:
- Setting up a new production line and defining what counts as a stop
- Reviewing and classifying open downtime events at the end of a shift
- Investigating recurring stops to find root causes
- Reporting on availability and OEE for a line or site
Common misconceptions
- The Downtime Manager does not replace manual intervention. Automatic detection covers what signals allow. Operators always retain the ability to add, edit, split, merge, or reclassify events.
- Reason trees are not global. Different equipment can have different trees, so operators only see reasons relevant to their equipement.
- Planned stops are not the same as unplanned stops. Change-overs and scheduled maintenance are recorded separately, so they do not inflate your unplanned downtime figures.
Best practices
- Keep reason trees shallow. Two or three levels is usually enough. Deep trees slow down operators.
- Translate reason codes into all languages spoken by your operators. The system supports this per reason.
- Validate your state transition tables on a test line before rolling out to production.