This article explains how you can use ArchFX tools (Global KPIs Solution, Sessions Reports, and Real-time Dashboards) together to identify lines needing optimization and potential sources of poor performance for investigation.
Look at Key Performance Indicators in the Global KPIs Solution
The ArchFX Global KPIs Solution presents KPIs such as Line Utilization (LU), Overall Equipment Effectiveness (OEE), and Machine Utilization (MU) in a standard way across machines, lines, areas, and sites. So you can start by sorting the lines in your area of responsibility (an area, a site, globally, etc.) by LU or OEE and looking for lines that have excessively low performance. That gives you a hint about which lines you want to drill down on.
Run a Process Capacity-Based Sessions Report (Basic) for your site
Next, run a Process-Capacity-Based Sessions Report (Basic) for your site.
- If your site has a mixture of P&P machines from different vendors, you'll need to run one sessions report for each vendor's machines.
- Set the report duration to the last seven days. ArchFX Live Dashboards keep data for the last seven days, so you want to be able to compare what you see in the Sessions Report with what you will see in the ArchFX Live Dashboards for the same period of time.
On the "Performance of Production Sessions" chart, look for large chunks of productivity loss. For example, in the below chart, you can see that Lines 23 and 25 have a lot of Operations (Ops) Loss, while Lines 17 and 2 have a lot of Upstream Loss (caused by machines before the P&Ps). So the sessions report begins to give you insights about WHY a line has low utilization.
In the above screen shot:
- Performance is the time during which the line is building product.
- Transfer Loss is due to excessive time (more than rated transfer speed) spent on transferring units from one machine to another.
- Upstream Loss is structural recurring loss caused by machines before the P&Ps.
- Downstream Loss is structural recurring loss caused by machines after the P&Ps.
- External Loss is caused by machines other than P&Ps, but it couldn't be determined whether it was Upstream or Downstream.
- Operational Loss ("Ops") is due to fluctuations in the performance of the line that cause Mean Takt Time for the Line to be greater than Line Achievable Takt Time. Includes various potential causes that are not broken out individually such as machine stops, transient upstream Problems (starvation) or downstream problems (blocking) that don't consistently recur, slow cycles, and uneven cycles.
Look on the Real-time Dashboards for more detailed sources of loss
Make sure to set the absolute time range to the the Last 7 days so you can cross-check your results against the results from the sessions analysis report.
"Lines with the Same PnP as Takt Time and Cycle Time Bottleneck" dashboard
Start with the "Lines with the Same PnP as Takt Time and Cycle Time Bottleneck" dashboard. That identifies any P&Ps that have the limiting takt time and are also the cycle time bottleneck for their lines across all recipes that ran on their lines. Any such P&P is worth investigating because if you reduce its cycle time and takt time, you should reduce the imbalance loss on that line. Look for lines on which the limiting P&P has a takt time that is significantly longer than the next-slowest P&P's takt time so that you start by working on optimizing a P&P and/or set of recipes for which these is potentially a significant performance gain to be achieved.
You can then drill down in your analysis using the Takt Time Inspection, Cycle Time Inspection, and Machine Program Details dashboards.
Key concepts and definitions for takt time analysis
- Cycle Time is the active time that a machine actually spent building the product. It excludes transfer time.
- Takt Time is the observed time between 2 products passing a given point in the line, e.g. exiting a particular machine. It includes transfer time.
- Achievable Takt Time is defined as the fastest takt time you could get in reality for a given machine for a specific recipe based on its loading time, any required communication delays (e.g. checking a barcode synchronously with the MES before starting work), etc. Achievable Takt Time is one of the hardest things to measure and generally must be calculated because there is not data available on all of the delays / steps inside of each machine (as well as between machines).
- Takt time (observed) is an upper bound on achievable takt time but doesn't tell you if you could have done better.
- Cycle time (measured) is a lower bound on achievable takt time but doesn't include all necessary time spent by the machine (such as transfer time) to make the product.
- Achievable Throughput on the Line is determined by the bottleneck machine's Achievable Takt Time. By definition, the line can emit product no faster than the slowest machine on the line emits product.
- Balance Rate on the line compares achievable takt time on each machine against the bottleneck machine's takt time to find structural idle periods of time that could, in some cases, be improved with better workload distribution.
Detailed machine analysis
Once you identify the bottleneck machine based on achievable takt time, then you do a detailed breakdown of how the machine spends its time. There are several major components:
- External Transfer Time is any conveyor movement time outside of the machine that cannot be parallelized with machine activity.
- Internal Loading Time is the time required from when a panel enters the machine until when the machine is ready to begin work.
- MES Validation Delay occurs if there is a synchronous call to the MES after barcode scan before work starts. This is also a part of the achievable takt time.
- Actual Cycle Time is the time spent doing useful work. This is normally what is reported by the machine as its "cycle time" with some variation that depends on the vendor's choice of what they chose to include in this metric.
- Internal Unloading Time is often parallelized with loading in the next panel, so it's not a separate loss.
You can divide the above activities into two groups:
- value-added work (e.g. cycle time)
- intrinsic delays (machine not doing valuable work but this delay is thought to be required, such as transfer time)
There are two goals at this point:
- make the ratio of value added work to intrinsic delays high on the bottleneck machine (so loading time divided by cycle time should be small, for example)
- when you have multiple identical machines capable of the same process step, make sure their cycle times are the same so they are parallelizing the work as much as possible
Observations from actual practice
- Loading times vary widely across machines and configurations. For example, the inline X-Ray loading time standard at some manufacturers is 10 seconds, but a Fuji NXT with 2 conveyors could be 0-1 seconds since loading is happening in parallel. So just looking at cycle time alone on a line will incorrectly identify the bottleneck because often you need to add 10 seconds for the X-Ray, but that could be 0s for Fuji. A Fuji cycle time of 20 seconds is faster than X-Ray cycle time of 15 seconds in that case.
- Depending on the line setup, the loading times for a given machine are not constant. The biggest one is single vs. dual conveyor lines. Dual conveyor lines on P&P machines can cut loading time to near 0.
- Manufacturing Execution System (MES) barcode checks are surprisingly common and slow. We have repeatedly seen situations where a line was losing several seconds on its X-Ray machine (which is already a 10 second loading time and a common bottleneck) because the machine stopped to wait for the MES to approve its scanned barcode after loading but before it would start work. This is a common pattern to make sure the right product is running on the line. Manufacturers in this case can put in place a fix to make the check asynchronous (so it runs in parallel with the X-ray inspection). Since the board isn't changed by the X-ray process, it is safe to detect the wrong barcode after X-ray vs. before.
Comments
0 comments
Please sign in to leave a comment.