Latency and Accuracy in Downtime Tracking Applications

ArchFX React accurately measures the percentage of downtime and idle time on machines and lines it is monitoring. Using React, manufacturers can identify underutilized assets and prioritize steps to improve utilization and throughput and decrease costs. At the end of a shift, day, or week, manufacturing operations staff can review ArchFX React analytics and get an accurate picture of how much their line was idle or down, when it was down, and the reasons why. However, it is important for customers to understand for that any downtime tracking application (including ArchFX React), at a given moment, data shown in the downtime tracking application is only as up-to-date and accurate as the data the downtime tracking application has received at that moment from the machines it is monitoring.

When using a downtime tracking application such as React to monitor an SMT or Back End Assembly line, you choose one machine on the line to act as the “pacemaker machine.” The downtime tracking application monitors the stream of product completion events coming from that machine. If the delay between two product completion events exceeds the downtime detection threshold that was defined for the current job, the downtime tracking application flags a downtime.

If manufacturing machines consistently reported product completion events without delay, a downtime tracking application would always receive an accurate and up-to-date picture of the state of the line. However, manufacturing machines sometimes have a delay on the order of seconds to up to 1 minute between when a product completion event occurs and when the machine writes that event to the API or log file that the downtime tracking application is monitoring. This means that downtime tracking applications must factor in machine reporting latency as a consideration in when to flag a downtime event.

An example of a machine reporting delay and its effects

Let’s say that a job has a 60 second takt time target and a 72 second (20%) downtime detection threshold and that normally, the pacemaker machine reports product completion events with one second of latency. Normally, the ArchFX platform will receive data providing a view of the line’s state that is one second behind reality due to the pacemaker machine’s built-in latency. Data processing through the ArchFX React system will introduce up to ten seconds of additional latency. So when viewing the ArchFX React UI, the operator will be viewing the state of the line as it was 11 seconds ago.

However, sometimes, the chosen pacemaker machine experiences a 30-second delay in reporting “product completion” events. So “product completion” event #1 happened at 06:00:00, and product completion event #2 happened on schedule at 06:01:00, but due to an internal delay within the pacemaker machine, it doesn’t report that second “product completion” event until 06:01:30.

In that situation, at 06:01:12, ArchFX React will detect a downtime because it has not received a “product completion” in the last 72 seconds. The ArchFX React Summary tab and Overhead Display will show “Unknown downtime” starting at 06:01:12. At 06:01:31 (after the 30-second delay and 1-second machine latency), the ArchFX platform will receive the delayed “product completion” event. At 06:01:41 (after up to 10 seconds of processing latency), the ArchFX React UI will remove the “downtime event” it temporarily showed because its line model will now correctly show that no downtime event occurred.

This is an example of how downtime applications need to be configured to take into account data collection latency in order to avoid temporarily showing a downtime that is later removed when data arrives.

Minimizing variation in reported takt times

On SMT lines, to minimize variation in reported takt times, Arch recommends that customers choose the last Pick and Place machine on the line as the pacemaker machine rather than picking any quality machine (AOI, AXI, SPI, ICT). Once a P&P machine is done, it emits the board and a product completion event without delay. When a board fails inspection on a quality machine, the board may be sent to a buffer for the human operator to review and mark the board as "no fault found" / "no trouble found" (NFF/NTF, i.e. a false error report) or to confirm that the board was faulty. The length of time it will take a human operator to go to the buffer and review the board is highly variable. Therefore, customers can simplify downtime tracking and analysis by choosing a P&P machine as the pacemaker machine instead of a quality machine.

ArchFX React compared to vendor machine notifications

SMT manufacturing machines already have many built-in features to notify operators when an error has occurred or operator action is needed. Andon lights visibly show the state of the machine as a whole. Audible alarms signal that action is needed. Lights may draw the operator’s attention to a specific component like a feeder that is running out of parts and must be spliced quickly.

ArchFX React complements and does not replace these vendor machine features. Operators can continue to pay attention to the notifications from individual machines on the line to determine what actions they must take to keep the line running in its current configuration. ArchFX React determines whether the line as a whole is running at the speed intended and, when downtimes occur, empowers the operator to record the reason to support later analysis and prioritization of manufacturing and maintenance engineer effort to increase uptime.

Managing manufacturing machine reporting delays

ArchFX React is adding a number of features to help manufacturers optimize their configuration to handle manufacturing machine reporting delays as they see fit.

• ArchFX React is putting in place logging and monitoring to study reporting delays on a per-machine and per-machine-class basis so that customers can understand the reporting delays their machines commonly produce.
• Some manufacturers place a priority on preventing “false positive” displays of downtime events on the ArchFX React UI. To support these manufacturers, ArchFX React will support a customer-configurable “downtime notification threshold,” in which a downtime event will only be shown on the ArchFX React UI if ArchFX React still believes a delay has occurred after the specified “downtime notification threshold.” If the manufacturer defines a “downtime notification threshold” of 60 seconds, ArchFX React would only show a downtime event in the UI if it still believes 60 seconds after the expiration of the target takt time that a downtime event has occurred. In the above example, no downtime event would ever have been shown in the ArchFX React UI because at 06:02:00, the delayed “product completion” event would already have been received and processed and ArchFX React would realize that no downtime event had occurred; it was just a reporting delay.
• In the future, ArchFX React may also add a feature that automatically updates “downtime notification thresholds” for each line based on observed reporting delays for the line.

In these ways, ArchFX React empowers manufacturers to strike the right balance between notification speed and notification accuracy based on the behavior of their particular machines and their business needs. Email help@archsys.io if you want help in configuring your ArchFX React deployment to optimally meet your needs.