Data Dictionary
>
FPSBASE Tables
> FPSBASE.WIP_HOLD_TYPES
Table FPSBASE.WIP_HOLD_TYPES"
List of all possible hold types that can be assigned to various lots on hold.
-
Schema: FPSBASE
-
Tablespace: FPSDATA
-
Foreign keys: WIP_HOLD_TYPES_FK_GROUP: HOLD_GROUP REFERENCES FPSINPUT.WIP_HOLD_GROUPS (HOLD_GROUP)
|
Column |
Type |
Nullable |
Comment |
|---|---|---|---|
|
HOLD_TYPE |
VARCHAR2(24) |
Generally hold_type will come directly from the MES. |
|
|
CONSIDER_IN_BANK |
CHAR(1) |
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. (* from FPSINPUT.RTG_ROUTES) |
|
|
DESCRIPTION |
VARCHAR2(256) |
Tool desciption. This value is only used to display in the Dashboard. (* from FPSINPUT.EQP_TOOLS) |
|
|
HOLD_GROUP |
VARCHAR2(36) |
N |
Grouping of hold_type for reporting purposes. (* from FPSINPUT.WIP_HOLD_GROUPS) |
|
HOLD_PARM1 |
VARCHAR2(128) |
Four user-defined fields which can store anything the user would like to track relating to the hold type. |
|
|
HOLD_PARM2 |
VARCHAR2(128) |
See HOLD_PARM1. |
|
|
HOLD_PARM3 |
VARCHAR2(128) |
See HOLD_PARM1. |
|
|
HOLD_PARM4 |
VARCHAR2(128) |
See HOLD_PARM1. |
|
|
IS_ALLOWED_FOR_SCHED |
CHAR(1) |
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. |
|
|
IS_EXCLUDED_LINE_BALANCE |
CHAR(1) |
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. |
|
|
IS_RUNNING_HOLD_IF_PROC |
CHAR(1) |
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. |
|
|
OVR_ESTIMATED_HOLD_SEC |
NUMBER(7) |
Estimated hold is an estimate for the duration from when a lot goes on hold until when it is released. Our default values are calculated based on history in WIP_HOLD_ESTIMATES and CTM_SUMMARY. However we can override the calculated values with a specific value for the hold type by populating this field. Furthermore we can override for a specific lot by populating ovr_release_inst in WIP_LOTS_VERIFY. See comments on OVR_REMAINING_HOLD_SEC for an example on how estimated hold duration and remaining hold duration are used together. |
|
|
OVR_HOLD_MODULE |
VARCHAR2(12) |
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. |
|
|
OVR_REMAINING_HOLD_SEC |
NUMBER(7) |
Remaining hold is an estimate for the minimum duration from now until a lot on hold will be released. The default value is half of the estimated hold duration calculated based on history in WIP_HOLD_ESTIMATES and CTM_SUMMARY. However we can override the calculated default value with a specific value for the hold type by populating this field. Unless overriden by ovr_release_inst in WIP_LOTS_VERIFY, the release time for a lot on hold is the latest of the release time calculated using estimated hold duration and the release time calculated by remaining hold duration. This means that remaining hold duration must be less than estimated hold duration and that it becomes relevant when the lot is near or past its release time calculated using estimated hold seconds. Here is an example using a lot which went on hold at 1:00 with an estimated hold duration of 6 hours and a remaining hold duration of 2 hours. The release time calculated using estimated is 7:00. At any time before 5:00, the time using remaining is before the time using estimated so our release time is 7:00. When time passes 5:00 then the time using remaining is after the time using estimated so at 5:01 the release time is 7:01. At 6:00 the release time is 8:00 and this will continue to be pushed 2 hours from current time until the lot is released. If is_allowed_for_sched is Y then Scheduler will schedule the lot at the current step no earlier than this release time and will schedule future steps based on the estimated complete for the current step which uses this release time (and adds processing time if the lot has not yet been processed). There are some hold types which we want to ignore and pretend the lot is not on hold and schedule immediately. To do this, set ovr_remaining_hold_sec to 0 and ovr_estimated_hold_sec to 1. |