Downtime

Downtime detects unplanned stops automatically, and records why they happened and what they cost. It answers "when did my stations stop during planned production, for how long, and why?" Operators give reasons in the Operator Interface, or devices send status codes.

Downtime is an unplanned stop during scheduled production time. Idle time outside scheduled production, such as planned maintenance or breaks in a non-production schedule, is recorded separately and is not downtime.

How it works

Detection methods

You choose how Busroot detects stops with the station's Downtime Detection Mode in Admin > Station.

Downtime Detection Mode	Needs	A stop is recorded when
Utilisation Monitoring (default)	A productive status: see Asset Utilisation	The station is not productive for at least the Utilisation Downtime Threshold.
Production Cycle Monitoring	Production counts and a performance target: see Production Tracking	No production is recorded for longer than the cycle time × the SKU's Downtime Duration Threshold Multiplier.
Line Speed Monitoring (Slow Detection)	A line speed signal and a Line Speed Target	The line speed stays below 80% of the Line Speed Target. See Slow production.
Off	Nothing	Never. Busroot records no downtime for the station.

Utilisation Monitoring and Production Cycle Monitoring look for stops only while a production schedule is running and the station is in shift. Slow Detection looks at any in-shift time.

Utilisation Monitoring

Busroot looks only at the productive status. If the station is in shift, running a production schedule, connected, and not productive for at least the Utilisation Downtime Threshold (mins), the time is downtime.

• The threshold is in whole minutes. The default is 60 minutes, which is usually worth lowering.
• A station that sends no signal at all shows as Connection Lost, not as downtime.
• This method suits processes with long cycle times, where you want to react faster than a gap in production would show. It uses the same threshold whatever SKU is running.

Production Cycle Monitoring

Busroot knows the planned cycle time of the SKU being produced. If no production is recorded for much longer than that, it assumes the station is down.

• The threshold is the cycle time × the SKU's Downtime Duration Threshold Multiplier. The default multiplier is 1.5 (150%). For example, for a SKU with a cycle time of 2 minutes, downtime starts to be recorded 3 minutes after the last unit. With a multiplier of 2, it would be 4 minutes.
• The threshold is never shorter than 30 seconds, even for SKUs with very short cycle times.
• If Busroot cannot find a cycle time for the SKU or the station, it uses a threshold of 1 hour.
• The cycle time comes from the schedule's cycle time override if one is set, then the SKU's performance target, then the station's. Set these in Admin > SKU and Admin > Station.
• This method gives quick detection on stations that make a range of SKUs with different cycle times, because the threshold changes with the SKU.
• A schedule that has reached the account's maximum production count records nothing more, so Busroot does not look for stops on it until it ends. See Maximum production count.

How downtime is counted

Once a stop passes the threshold, the whole stop counts as downtime, including the threshold time. For example, with a 5 minute threshold, a stop of 7 minutes counts as 7 minutes of downtime. A stop of 4 minutes counts as none.

With Production Cycle Monitoring, the downtime starts at the last recorded unit.

Slow production

On a station with the Line Speed Monitoring (Slow Detection) mode, Busroot records a downtime with the type Slow when the line speed stays below 80% of the Line Speed Target, in shift, for longer than the slow duration threshold (1 minute by default). The Line Speed Target comes from the SKU of the running schedule, or from the station.

Planned time is not downtime

Scheduled non-production time, and time declared by the non_production_reason signal, is planned. It is never downtime and it does not lower OEE availability. See Scheduling.

Manual downtime

An operator can mark a station as down from the Operator Interface, with a reason. The API can do the same. Use it when the machine still sends signals but is not really available, for example while maintenance work is done on it.

While a manual downtime is running:

• The station's production and productive signals are recorded as zero.
• The time counts as availability loss against any production schedule running at the same time.
• Any automatically detected downtime already open on the station is closed, and automatic detection is paused until the manual downtime ends.
• It is costed in the same way as automatically detected downtime. See Downtime cost.

Manual downtime is off by default. It is turned on with the Allow Manual Downtime feature flag, which can be set for the account, a plant, a station group or a station. See the account manifest.

Downtime reasons

Operators give each stop a reason in the Operator Interface. A reason can require a note before it is accepted. See Require Notes in Admin > Reasons.

Status codes and automatic reasons

A device can send a status_code signal with the station's current status, for example an error code from the machine's own controller. Busroot records the code against each minute of the station's data. See Station signals.

Downtime can be given a reason automatically from the device's status code, so operators do not have to enter it.

Set it up

1. Set up the productive status (Asset Utilisation) or production counting (Production Tracking), depending on the detection method you want.
2. In Admin > Station, set the Downtime Detection Mode.
3. Set the threshold:
   • Utilisation Monitoring: set the Utilisation Downtime Threshold (mins) to the shortest stop you want recorded as downtime.
   • Production Cycle Monitoring: give every SKU a performance target in Admin > SKU, and change its Downtime Duration Threshold Multiplier if 150% does not suit it.
4. Make sure a production schedule runs on each station while you want stops detected. The simplest option is a Continuous schedule. See Scheduling and Gantt & Schedules.
5. Add your downtime reasons in Admin > Reasons.
6. Optional: to cost downtime, set a Value on each SKU and an Idle Cost Per Minute on each station.
7. Optional: to receive emails when stations stop, set your notification preferences.

Note

A station can instead treat all its shift time as planned production, without a schedule. This is the forceAllShiftTimeAsPlannedProduction station setting in the account manifest. Contact support if you need it.

Where you see it

• Operator Interface: operators give each stop a reason.
• Alerts: emails when a station stops, when an operator escalates, and a daily downtime summary.
• Cockpit: which stations are down now.
• Downtime List & Analysis: every stop with its reason, and a breakdown of downtime by reason, with its cost.
• OEE Analysis: downtime as availability loss, broken down by reason.
• Trend Viewer: Total Downtime and Downtime by Reason over time.
• Hierarchy Explorer: stops count, total downtime, MTBF, MTTR and downtime cost, rolled up from station to plant.
• Pulse Chart: stops shown against the schedule, window by window.

Metrics

Total downtime

minutes

The total time of unplanned stops during scheduled production.

• Notes The Hierarchy Explorer also shows it as a percentage of scheduled production time.

Downtime by reason

minutes

The downtime recorded against a reason and its sub-reasons.

• Notes If you choose a parent reason, its sub-reasons are included. You can also choose All Reasons. The Trend Viewer's Unassigned option covers downtime that was never given a reason, and downtime recorded against a reason that has since been deleted. See Why does "Unassigned" differ between pages?

Stops

count

The number of downtime events.

• Notes Downtime in back-to-back minutes counts as one stop.

MTBF

minutes

Mean Time Between Failures: the average time the station runs between stops.

MTBF = total running time ÷ number of running periods

• Notes Running time is scheduled production time with no downtime. Busroot shows MTBF only when the range has at least one running period and one stop.

MTTR

minutes

Mean Time to Repair: the average time it takes to get the station running again after a stop.

MTTR = total downtime ÷ number of stops

• Notes Like MTBF, it needs at least one running period and one stop in the range.

Downtime cost

account currency (£)

The lost opportunity cost of downtime.

Downtime cost = downtime minutes × the SKU's Value, or × the station's Idle Cost Per Minute when the SKU has no value

• Notes Manual downtime is costed in the same way as detected downtime. Downtime cost is the availability part of Lost production cost. Set the SKU value in Admin > SKU and the idle cost in Admin > Station.

FAQs

When is Slow Production triggered, and how can I stop it?

Slow applies only to stations tracked by line speed with the Line Speed Monitoring (Slow Detection) mode. Busroot flags Slow when the speed drops below 80% of the Line Speed Target. The 80% is fixed. To stop Slow being recorded, choose a different Downtime Detection Mode for the station, or remove its Line Speed Target.

Why do downtime notifications keep appearing when the machine is running?

Check the thresholds on the station in Admin > Station: the Downtime Detection Mode, the Utilisation Downtime Threshold, and the Productive Hold On Time. For Production Cycle Monitoring, also check the SKU's performance target and Downtime Duration Threshold Multiplier. A threshold that is shorter than the machine's normal gaps between signals makes every gap a stop.

Can I set the Utilisation Downtime Threshold to 4.5 minutes?

No. Busroot works in whole minutes, so choose 4 or 5 minutes.

Can I add downtime reasons when no schedule is running, for example on a Saturday out of shift?

Busroot records downtime only while a production schedule is running, so there is nothing to give a reason to in real time. To see the data afterwards, add a schedule for that period and select Extend Shift when you create it. This lets the schedule record production outside shift times.

Is downtime without a reason removed from the Operator Interface?

Yes. The Operator Interface shows unreasoned downtime from the last 72 hours. Older downtime stays in Busroot, where you can still give it a reason from the Downtime List.

The Operator Interface also keeps at most 50 unanswered downtime notifications for each station. When there are more, the oldest is removed each time a new one is added.

Why does "Unassigned" differ between pages?

The Trend Viewer's Unassigned option covers downtime that was never given a reason, plus downtime recorded against a reason that has since been deleted. OEE Analysis and Downtime Analysis show a deleted reason under its original code instead. So their "Unknown" or "Unassigned" figures cover only downtime that never had a reason.