Data Dictionary
>
FPSBASE Views
> FPSBASE.WIP_WAFER_HIST_LOOP
View FPSBASE.WIP_HOLD_TYPES_PLUS
This is a simple view to combine hold tables but this view is a good place to store our definitions for holds: - Current hold: A lot that is currently on hold. The cause could have been from a line hold or from a lot hold. - Future hold: A lot that we know will go on hold in the future when it reaches a particular step. Again the cause could be from a line hold or from a lot hold. - Line hold: A systematic hold that affects a defined group of lots. Line holds must include step and may also specify a route or product or lot type or other grouping. For example, you might place a line hold on any lot that arrives at step S100. Lots which are at this step and on hold would be considered current hold due to this line hold while lots which will arrive at this step soon would be considered future hold at this step due to line hold. - Lot hold: A hold that is specific to a particular lot id. A couple notes about these four definitions for clarity: - All holds are either current or future -- never both nor neither -- and a future hold changes to a current hold when the lot arrives at the particular step. - All holds are either line or lot -- never both nor neither. - Combining the two above gives that each hold is either current lot, current line, future lot, or future line.
|
Column |
Comment |
|---|---|
|
HOLD_TYPE |
Generally hold_type will come directly from the MES. (* inherited from FPSINPUT.WIP_HOLD_TYPES) |
|
DESCRIPTION |
Tool desciption. This value is only used to display in the Dashboard. (* inherited from FPSINPUT.EQP_TOOLS) |
|
HOLD_GROUP |
Grouping of hold_type for reporting purposes. (* inherited from FPSINPUT.WIP_HOLD_GROUPS) |
|
HOLD_GROUP_DESC |
|
|
COUNT_AS_LONG_HOLD_FOR_CTM |
When this flag is set to Y, time on hold in this hold_group is bucketed into the Long Hold process state to be grouped separately from the normal Hold time on CTA and FLCT. (* inherited from FPSINPUT.WIP_HOLD_GROUPS) |
|
IS_ALLOWED_FOR_SCHED |
Lots on hold are only scheduled if this flag for the hold type is set to Y. By default this is N which means that lots on hold are not scheduled. (* inherited from FPSINPUT.WIP_HOLD_TYPES) |
|
IS_EXCLUDED_LINE_BALANCE |
Lots on hold are excluded from line balance calculations if this flag for the hold type is set to Y. By default this is N which means that lots on hold of this type are included in line balance calculations. (* inherited from FPSINPUT.WIP_HOLD_TYPES) |
|
CONSIDER_IN_BANK |
Some sites want lots which are on certain routes and/or on hold with certain hold types to count as in bank rather than in active WIP. This flag tells WIP_LOTS_PLUS for route or hold_type to consider in bank. Please note this does not affect WIP_EVENT_HIST nor WIP_STEP_HIST but only the current WIP. (* inherited from FPSINPUT.RTG_ROUTES) |
|
OVR_HOLD_MODULE |
This field should be populated when the module responsible for lots on hold of this hold_type is different from the module of the current step. The most common example of this is a facility that has a separate METROLOGY module. It is quite common for a lot to go on hold at a step owned by the METROLOGY module but the hold_type is typically owned by a traditional module like LITHO, ETCH, DIFFUSION, etc. If populated for the hold_type then we set the hold_module to this value in WIP_LOTS_PLUS. If blank then we use the process_module. (* inherited from FPSINPUT.WIP_HOLD_TYPES) |
|
IS_RUNNING_HOLD_IF_PROC |
Normally when a lot goes on hold during processing we assume that it is no longer processing and we set the ECT state of the lot to HOLD and set the ETP state of the tool to SBY. But sometimes this can be a "running hold" which means that the lot continues processing and then will be on hold as soon as it finishes. There are two ways to indicate a running hold if put on hold during processing, either by this column for a hold_type or by the ignore_hold_for_proc_state column in EQP_TYPES for all tools in an eqp_type. The latter is normally used for metrology tools. This is an "or" condition so if a hold_type is Y that applies to all tools and if a tool is Y that applies to all hold types. When a lot goes on a running hold, we will set the ECT state of the lot to PRD-RUNHOLD and keep the ETP state of the tool in PRD. Then when the lot ends or moves to the next step, we will set the ECT state of the lot to HOLD and set the ETP state of the tool to SBY. Note that when we refer to setting the ETP state to SBY we technically mean that we use our normal END logic which will set to SBY unless a newer job has started then we keep ETP as PRD. (* inherited from FPSINPUT.WIP_HOLD_TYPES) |
|
HOLD_PARM1 |
Four user-defined fields which can store anything the user would like to track relating to the hold type. (* inherited from FPSINPUT.WIP_HOLD_TYPES) |
|
HOLD_PARM2 |
See HOLD_PARM1. (* inherited from FPSINPUT.WIP_HOLD_TYPES) |
|
HOLD_PARM3 |
See HOLD_PARM1. (* inherited from FPSINPUT.WIP_HOLD_TYPES) |
|
HOLD_PARM4 |
See HOLD_PARM1. (* inherited from FPSINPUT.WIP_HOLD_TYPES) |