Synchronous transport solutions

When capital efficiency of a fab takes second place in favor of cycle time considerations, a greater degree of synchronization of the processes is considered. Ideally, each WIP move is initiated when that WIP is assured the availability of the next process tool at the time of its arrival. Missing target times of arrival retards tool operations and throws the system out of synchronization.

Choreographing synchronized transport is difficult with an aggregate of discrete move devices, such as vehicles. While their interdependence (their limited capacity requires them to share delivery tasks) is a detriment with asynchronous fabs, that interdependence is not strong enough for synchronized fabs (they cannot be “chained” together – as if in a single cell – because delivery paths are multiple with a high degree of branching). I.e. this interdependence is not enough to make them step with a single tack time. Variability of wait times for pick up make this so. (The same variability that is detrimental in asynchronous fabs.) Conveyor systems do not have wait times. Their availability to initiate a wip move can be configured to be 100%. As a result, delivery times are predictable, because these mainly depend on calculated travel times.

To what degree synchronization can be achieved in a project is largely dependent on the semiconductor process, and the flexibility of the capital budget for balancing process flow. For certain, that goal is relatively easy to achieve within each cell, where tool cycle times can better be balanced. With a conceptually in-line conveyor system this can be assured. Inter cell movements are more difficult in terms of variability of WIP arrivals, and some degree of randomness may occur. However, here too, after the balance between the cells is approximated, the conveyor delivery can promote its maintenance. Middlesex does not posses software to synchronize inter-cell transport. We must place reliance on customer algorithms directing our software. Our anticipation is that inter-cell moves, in general, will be synchronous only to a degree, giving way to some extent to asynchronous WIP flow.

The embedded dispatch in the conveyor network controller can, however help. In this case, the natural pull- to-destination dispatch of the system can be suppressed to favor the alternate push to destination dispatch. In the pull dispatch the CCM selects the most readily available tool set to promote the fastest time through the next process step. In the push dispatch, the CCM delivers the WIP to a target designated by the host, while minimizing the interference to that push by other WIP in the network. In attempting to synchronize the process cells, use of the push dispatch algorithm is advised.

When a WIP enters the conveyor domain (stocker and conveyor network) the WIP is assigned a priority by Middlesex via an algorithm. The Fab host provides a target arrival time for each WIP and a target cell (output port of the conveyor stocker). The CCM software then calculates transit time for the WIP, and compares values to other WIP destination target times. On this basis, after input to the conveyor domain, a WIP may be held at the input stocker to prevent its interference at merge conveyor nodes with a WIP of higher priority. (There is no interference on linear sections of travel, and the FOUP flow density can be high.)