Downtime Analysis
Measure and report automatically detected downtime. Understand common causes.
Last updated
Measure and report automatically detected downtime. Understand common causes.
Last updated
One of the most fundamental capabilities of Busroot is its ability to automatically detect and record periods of downtime on stations.
Downtime is any significant stoppage during a period when the station is scheduled for production. Idle time outside of planned production is tracked separately and not referred to as 'downtime'. (i.e. unscheduled time, planning maintenance, etc.)
Each period of downtime can (and should) be assigned a reason. This can come automatically from the station (using the error code signal), or be assigned by the operator using the tablet interface.
Downtime can be detected in 1 of 2 ways:
As Busroot is aware of the planned cycle time of SKUs, if production output has not been observed for significantly longer than this time, downtime can be assumed.
By default, the threshold is set to 150% of cycle time. e.g. If an SKU has a cycle time of 2 minutes, downtime will be assumed after 3 minutes from the last observed production output.
This is a useful method for having reactive downtime detection on stations that produce a range of SKUs with differing cycle times.
By looking exclusively at the productive signal, a threshold of time can be set so that if the station is idle for longer than this time, it is considered downtime.
This is most useful for processes that have long cycle times, and we want to be more reactive than is possible by just looking at the production output.
It is a simpler method that cannot be varied based on SKU being produced.
