data-dictionary

FPSBASE.RTG_PROCESS_SUBFAMILY_COMMENT

Data Dictionary

>

FPSBASE Views

> FPSBASE.WIP_WAFER_HIST_LOOP

View FPSBASE.RTG_PROCESS_SUBFAMILY_COMMENT

The best solution to avoid processes in multiple process families or tools in multiple process families is to make the process families wider so that it is rare to have this problem. Within each process family we have a concept called process subfamily which covers shared tools. Here is a short example of how this works: * Each tool should be in one primary process family which includes the processes they run regularly. This is not used by scheduling/dispatching so alternates which are rarely used can be in a different family and will be still scheduled/dispatched when appropriate although these rarely used alternates will still suffer from the problem which is the subject of this email. * Similarly each process should be in one primary process family which includes the tools where it runs regularly. * This means merging eqp types where there is significant crossover into a single process family. * Each process can be in only one process subfamily within the process family. Note that subfamily is optional and is only used for tools with crossover like we are discussing here. * Tools will be in multiple subfamilies and this is fully expected (and in fact automatically generated by what they are capable of running). * Goal Planner has a capacity for each family which is the capacity of all of the tools -- then it has a capacity for each subfamily based on the tools in each subfamily. Because of the nature of subfamily and how it is shared, the total capacity of the subfamilies will always be greater than the capacity of the family. If this was not true then the subfamilies would not be shared and we would just make them separate families! Are you confused yet? Let's go to the most simple example: * Family has two tools T1 and T2 and three processes P1, P2A, and P2B. * P1 can only run on T1. P2x can run on both T1 and T2. P1 is in subfamily S1 and P2x are in S2. * Processes run at the same throughput which is 10 WPH and both tools have utilization of 75% or 6 hours per shift. * The capacity of the family is 12 hours per shift which is 120 wafers. * The capacity of the subfamily S1 is 6 hours/60 wafers because it can only use T1 * The capacity of the subfamily S2 is 12 hours/120 wafers because it can use either tool. In this example, GP cannot ask for more than 120 wafers total and no more than 60 of S1. It could ask for 120 of S2 and 0 of S1. Or 90 of S2 and 30 of S1. Or 60 of each. But it cannot ask for 90 of S1 and 30 of S2 because that exceeds the capacity of the S1 subfamily. So how does the dashboard handle this: * Currently not particularly well but this will be improved soon. * Main page and operations will still show process family as now which will be the larger combined group of tools and processes when configured properly. * The process family page will have a section which breaks down WIP/Moves/Coming by subfamily. This will look similar to the family breakdown on the module page except that tools will appear more than once. What you will note that we are still missing is totals by tool within smaller groups of tools but there is a reason why this is missing and will probably remain missing at least on the dashboard. It's because it is impossible to set goals like this. You can only set goals where each process is assigned to one grouping and we can do this by subfamily and by family. But you can't set goals for each tool by any group smaller than family because you cannot set goals by groups which are shared.

Column

Comment

MESSAGE