Data Dictionary
>
FPSINPUT Tables
> FPSINPUT.SCH_W_H_S_LOTS
Table FPSINPUT.SCH_W_H_S_LOTS"
This table is used to store the historical run data on lots
-
Schema: FPSINPUT
-
Tablespace: FPSSCHEDHIST
|
Column |
Type |
Nullable |
Comment |
|---|---|---|---|
|
CARRIER |
VARCHAR2(32) |
RFID of the cassette or FOUP the lot is currently in. (* from FPSINPUT.MHS_CARRIERS) |
|
|
COULD_CHANGE_SETUP |
CHAR(1) |
||
|
CREATE_INST |
DATE |
||
|
CRITICAL_RATIO |
NUMBER(5,3) |
The critical ratio (days until due / days of CT left) for the lot |
|
|
CURR_DISPATCH_INST |
DATE |
||
|
CURR_LOCATION |
VARCHAR2(32) |
store the curr location of the lot |
|
|
CURR_PRIORITY |
VARCHAR2(7) |
The priority at the current step. As the lot moves along the route after LAST_STEP_CURR_PRTY it will revert to PLAN_PRIORITY. For example, timelink or sendahead priority is only temporary. (* from FPSINPUT.WIP_LOTS_STATIC) |
|
|
CURR_PRIORITY_DISPLAY |
VARCHAR2(20) |
N |
|
|
CURR_PROCESS |
VARCHAR2(50) |
||
|
CURR_PROCESS_STATE_DETAILS |
VARCHAR2(600) |
||
|
CURR_PROC_BEG_INST |
DATE |
||
|
CURR_PROC_END_INST |
DATE |
||
|
CURR_RECIPE |
VARCHAR2(100) |
The current/last used recipe for the scheduler, incorporating the ignore capability from EQP_PROCESS_CHG_TO_IGNORE (* from FPSBASE.ETP_STATUS) |
|
|
CURR_SETUP |
VARCHAR2(100) |
The current setup of the entity. This can be set by a lot processing event from WIP_EVENT_HIST or by an event on the entity from EQP_EVENT_HIST. For example if an Implant tool processes a Boron lot then the curr_setup will be Boron. Or if an event is logged to the tool that says the setup changed to Boron then the curr_setup will be Boron. Please note that the curr_setup value populated in EQP_EVENT_HIST must match exactly with the rqd_setup value in RTG_TOOL_ASSIGNMENTS in order for the setup penalty logic to apply correctly. (* from FPSINPUT.EQP_EVENT_HIST) |
|
|
CURR_STATION |
VARCHAR2(32) |
See column comment on STATION in FPSINPUT.MHS_STATION_ALTERNATES for more information. (* from FPSINPUT.MHS_DELIVERY_NEXT) |
|
|
CURR_TOOL |
VARCHAR2(16) |
||
|
CUSTOM_TARGET |
NUMBER |
||
|
DISPATCH_ENABLED |
CHAR(1) |
||
|
DRUM_CRITERIA |
VARCHAR2(513) |
This is the level of counting that will be multiplied by within the scheduler to dynamically score the drum rate as lots are placed on a schedule run (* from FPSAPP.GP_P_PRIORITY_DRUM) |
|
|
DRUM_MV_FACTOR |
NUMBER |
This is the per move factor in which the drum rate will adjust for use in the scheduler to dynamically score the drum rate as lots are placed on a schedule run (* from FPSAPP.GP_P_PRIORITY_DRUM) |
|
|
DRUM_RATE |
NUMBER |
||
|
EARLIEST_STEP_BEG_INST |
DATE |
||
|
EST_CURR_PROC_END_INST |
DATE |
||
|
EST_SMP_PCT |
NUMBER |
Smp_pct tells you what percentage of the lots complete on a tool. Some sites skip steps by jumping over them so we see the lot move from step 3 to step 5 and we only know that it jumped step 4 because step 4 is on the route between 3 and 5. Other sites skip steps by moving lots into them and then moving them out a second later so we see a move from 3 to 4 at 11:11:11 and a move from 4 to 5 at 11:11:12. We do not care how it is done but just that the lot did not process at step 4 -- and to be more specific that no tool capacity is required to process this lot at step 4 and no cycle time is accumulated at step 4. (* from FPSBASE.WIP_GOAL_LOT_SHIFT) |
|
|
FACILITY |
VARCHAR2(6) |
N |
Facility is included in almost every join in the DWH so this represents a definitive split. A route must have all steps on tools in the same facility. A tool must process all lots in the same facility. If your site has multiple buildings where lots run on routes using tools in multiple buildings then everything should be one facility. For example, multiple Fab buildings. But if your site has independent facilities like Fab and Test and Assembly where lot may progress from one to the next but on different routes then these should be different facilities. Since this column is in virtually every table it is critical that the value here is exactly matches what is in the MES if the MES has facility. Use facility_display for the display friendly name displayed in applications. See site_name comment for client/site/facility example. (* from FPSINPUT.GEN_FACILITIES) |
|
IS_CURR |
CHAR(1) |
Boolean flag where Y indicates this row is for the current main route or product. Same as flush_seq_num = 1. (* from FPSBASE.WIP_FLUSH) |
|
|
IS_HIGHLIGHTED_PRTY |
CHAR(1) |
This flag indicates if this priority should be highlighted on the dashboard. When we sort all priorities by priority_sort all Y should be first followed by all N. (* from FPSINPUT.WIP_PRIORITIES) |
|
|
IS_HOLD |
CHAR(1) |
This field indicates the lot is on hold after the event is logged. In other words, this will always be Y if is_hold_start is Y and always N if is_hold_end is Y. (* from FPSINPUT.WIP_EVENT_HIST) |
|
|
IS_SCHED |
CHAR(1) |
This flag indicates that lots in this group should be scheduled. This flag additionally causes TW groups to be included in WIP_STEP_FUTURE which they are normally not. (* from FPSINPUT.WIP_LOT_GROUPS) |
|
|
IS_SCHED_BLOCKED |
CHAR(1) |
to indicate if there is any preceding steps UNSCHED |
|
|
IS_STAGING_STEP |
CHAR(1) |
We expect large amounts of WIP and long cycle times at staging steps. We still calculate cycle time like any other step but the important difference is that lots currently at a staging step are not counted as normal coming lots to future steps. Instead we show them in a special column labeled From Staging. (* from FPSINPUT.RTG_ROUTE_STEPS) |
|
|
IS_START |
CHAR(1) |
Boolean flag where Y indicates the lot is an upcoming start and not an existing lot. (* from FPSBASE.WIP_FLUSH) |
|
|
IS_WIP_STOPPED |
CHAR(1) |
||
|
LATE_DAYS_LOGISTIC_SLOPE |
NUMBER(4,2) |
The steepness of the S-curve function for lot days late. Larger numbers mean steeper curves - i.e. closer to a step function change. (* from FPSAPP.SCH_C_GROUP_LOT_PRIORITIES) |
|
|
LINE_BALANCE_RATIO |
NUMBER |
||
|
LOT |
VARCHAR2(32) |
A lot is a group of units that process together. Usually lot_id or lot_number in MES. All units in a lot are in the same carrier but there may be multiple lots in a carrier. (* from FPSINPUT.WIP_LOTS_STATIC) |
|
|
LOT_DAYS_LATE |
NUMBER |
||
|
LOT_DUE_INST |
DATE |
the due date of the lot |
|
|
LOT_GROUP |
VARCHAR2(8) |
Lot_group is a grouping of lot_family and is the highest grouping in the lot type hierarchy. There should be only a few values for lot_group, i.e. Prod, Dev, TW. We group WIP and moves by lot_group on the dashboard and we group cycle time calculations by lot_group so this is an important field. (* from FPSINPUT.WIP_LOT_GROUPS) |
|
|
LOT_RANK |
NUMBER |
||
|
LOT_TYPE |
VARCHAR2(24) |
This Column stores the lot type. |
|
|
MAIN_ROUTE_GROUP |
VARCHAR2(36) |
Route group of main route. Often referred to as technology. (* from FPSBASE.WIP_FLUSH) |
|
|
MIN_STEP_SEC |
NUMBER(7) |
the minimum step cycle time |
|
|
MIN_STEP_SEC_TO_EOL |
NUMBER(11) |
Total minimum step cycle time to the end of line |
|
|
NUM_STEPS_AWAY |
NUMBER(4) |
Number of steps away not including steps which we know will be skipped nor those which we estimate will be skipped at least x pct of the time. This x value is configurable in GEN_FACILITIES using the smp_pct_for_num_steps_away column. (* from FPSBASE.WIP_STEP_FUTURE) |
|
|
NWSCH_BACKLOAD_INST |
DATE |
This Column indicates that the lot has been backloaded (Scheduled to Track In Early), This column should only have a value when the track in |
|
|
NWSCH_BATCH_CRITERIA |
VARCHAR2(140) |
||
|
NWSCH_CARRIER |
VARCHAR2(64) |
||
|
NWSCH_CH_TO_USE |
VARCHAR2(24) |
||
|
NWSCH_COMMENT |
VARCHAR2(4000) |
||
|
NWSCH_DISP_INST |
DATE |
||
|
NWSCH_DURABLE |
VARCHAR2(64) |
||
|
NWSCH_EARLY_START |
DATE |
This Column stores the estimated earliest sched start for a lot. To be used for NextMove or dispatching |
|
|
NWSCH_END |
DATE |
||
|
NWSCH_EXTL_MODEL_ID |
VARCHAR2(128) |
||
|
NWSCH_EXTL_MODEL_STATE |
VARCHAR2(128) |
||
|
NWSCH_FIND_SCHED_FOR_LOT_COUNT |
NUMBER(7) |
||
|
NWSCH_IS_EXCLUSIVE_CHAMBER |
CHAR(1) |
||
|
NWSCH_IS_RESERVED |
CHAR(1) |
||
|
NWSCH_JOB_ID |
VARCHAR2(64) |
||
|
NWSCH_JOB_SEQ |
VARCHAR2(64) |
The sequence of sched job on the lot step level |
|
|
NWSCH_LOT_TRANSIT_SEC |
NUMBER(6) |
||
|
NWSCH_MATCHED_PATTERN |
VARCHAR2(2000) |
This Column stores the pattern that was matched by placing this lot on the schedule |
|
|
NWSCH_MAX_HIST_PATTERN |
VARCHAR2(2000) |
This Column stores the total history required to check on the tool. The scheduler calculation only looks back as far as the longest allowed pattern configured |
|
|
NWSCH_MIN_HIST_PATTERN |
VARCHAR2(2000) |
This Column stores the history including this lot that matched the pattern in nwsch_matched_pattern column |
|
|
NWSCH_PATTERN_UNIT_TYPE |
VARCHAR2(8) |
This Column stores the unit type used for pattern matching. For now, value can be either LOT or JOB. |
|
|
NWSCH_POD_FIRST_DISP_INST |
DATE |
||
|
NWSCH_POD_KIT_READY_INST |
DATE |
||
|
NWSCH_POD_KIT_START_INST |
DATE |
||
|
NWSCH_PREV_SCHED_ORDER |
NUMBER(5) |
||
|
NWSCH_PRE_BATCH_ID |
VARCHAR2(64) |
||
|
NWSCH_PROCESS_CHANGE_SEC |
NUMBER(6) |
||
|
NWSCH_QUEUE_START_DELAY_INST |
DATE |
||
|
NWSCH_RECIPE |
VARCHAR2(100) |
||
|
NWSCH_RQD_PORT_GROUP |
VARCHAR2(12) |
||
|
NWSCH_SCORE |
NUMBER(20,4) |
||
|
NWSCH_SCORE_DETAILS |
VARCHAR2(4000) |
||
|
NWSCH_SETUP |
VARCHAR2(64) |
||
|
NWSCH_SORT_ON_TOOL |
NUMBER(4) |
||
|
NWSCH_START |
DATE |
||
|
NWSCH_STEP_BEG_INST |
DATE |
||
|
NWSCH_TOOL |
VARCHAR2(16) |
||
|
NWSCH_UPDATED_INST |
DATE |
||
|
NWSCH_ZONE_TO_USE |
VARCHAR2(1) |
The assigned tool zone for this lot |
|
|
OPERATION |
VARCHAR2(50) |
Operation for each step |
|
|
OPERATION_ENT_INST |
DATE |
Enter time for this operation |
|
|
ORIG_LOT_DUE_INST |
DATE |
the original due date of the lot |
|
|
PRD |
VARCHAR2(64) |
N |
Prd determines the route which is used to process the lot in the facility and what tools, recipes, durables, etc. can be used at each step. Prd also determines the next facility for the lot when it finishes its route. For detailed information on prd vs. planprd see table comments in RTG_PLANPRDS. (* from FPSINPUT.RTG_PRDS) |
|
PROCESS |
VARCHAR2(50) |
Process defines what occurs at a step. Different steps can share the same process if they are identical. Process should normally determine allowed tools and recipe although it can be overridden by step, route, prd, lot, and experiment for exceptions. Each process is dynamically assigned to one or more eqp_type-process_family combinations with use_pct. One process_family is determined to be primary. If grouping is done correctly, a process should only be one eqp_group with no crossover. (* from FPSINPUT.RTG_PROCESSES) |
|
|
PROCESS_GROUP |
VARCHAR2(36) |
Process group is the critical field where tools and processes come together for the purposes of Scheduler. Process group is in both EQP_TOOLS for the tools and in RTG_PROCESSES for processes. Ideally all tools that run the same set of processes with no crossover including back-up and emergency tools would be in the same process group but it is important to note that this is not technically required for Scheduler as long as all process groups are in the same sched group. (* from FPSINPUT.RTG_PROCESS_GROUPS) |
|
|
PRODUCT_SCORE |
NUMBER(2) |
Scheduler Evaluation slider value for product priority slider (* from FPSINPUT.RTG_PRDS) |
|
|
QTY |
NUMBER(6) |
Quantity of units in the lot according the qty_unit defined for the facility. It is required for all lots in each facility to have their qty defined in the same units therefore the change in the unit is critical to defining the facility. For example, a pretest facility might have a sort step in the middle where we learn the qty of die. Prior to this step we know only the wafer qty but after this step we know both wafer and die. Since wafer is the only qty we know throughput the flow then wafer must be defined as the qty unit for this facility. Die can then be populated as sec_qty when it is known. Similarly the wafer saw facility might have a step in the middle where we cut the wafers into die. After this step we no longer know the number of wafers which means that die must be the qty unit for this facility and wafers can be the sec_qty prior to the saw step. Please note that a lot with qty of 0 is allowed but only if the sec_qty is greater than 0. This is unusual but one case is where we know the wafers will be scrapped but cannot be scrapped quite yet. (* from FPSINPUT.WIP_EVENT_HIST) |
|
|
RESERVE_JOB_ID |
VARCHAR2(64) |
||
|
RESERVE_TOOL |
VARCHAR2(16) |
||
|
ROUTE |
VARCHAR2(256) |
N |
Route that has threading requirements (* from FPSINPUT.RTG_STEP_THREADING) |
|
ROUTE_FAMILY_SCORE |
NUMBER(2) |
Scheduler Evaluation slider value for route family priority slider (* from FPSINPUT.RTG_ROUTE_FAMILIES) |
|
|
ROUTE_SCORE |
NUMBER(2) |
Scheduler Evaluation slider value for route priority slider (* from FPSINPUT.RTG_ROUTES) |
|
|
RUN_ID |
VARCHAR2(50) |
N |
the run id from the last successful scheduler (* from FPSAPP.SCH_W_SCHED_GROUP_STATUS) |
|
SCHED_CARRIER |
VARCHAR2(32) |
||
|
SCHED_CH_TO_USE |
VARCHAR2(24) |
Please note that the Scheduler often populates this with M which indicates the main tool therefore we often should filter out a value of M when using this value since that it not a valid chamber combination. When this is populated with any value other than M then we use this as est_ch_used rather than calculating with GET_CH_ALLOWED_STATUS or GET_CH_PATH_STATUS. (* from FPSBASE.WIP_STEP_FUTURE_SCHED) |
|
|
SCHED_COMMENT |
VARCHAR2(4000) |
||
|
SCHED_DISP_INST |
DATE |
||
|
SCHED_DURABLE |
VARCHAR2(129) |
||
|
SCHED_END |
DATE |
||
|
SCHED_EXTL_MODEL_ID |
VARCHAR2(128) |
to indicate the external model id of the tool that this lot is scheduled to (* from FPSBASE.WIP_STEP_FUTURE_SCHED) |
|
|
SCHED_EXTL_MODEL_STATE |
VARCHAR2(128) |
to indicate the external model state of the tool that this lot is scheduled to (* from FPSBASE.WIP_STEP_FUTURE_SCHED) |
|
|
SCHED_GROUP |
VARCHAR2(36) |
N |
This is the grouping of tools and processes which the FPS Scheduler schedules together. Since this is a parent of tool via tool->process_group and a parent of process via process->process_group, by definition each tool and each process can only be in one sched group. We need all related tools and processes to be in the same sched group for efficient scheduling. One example is sinks and furnaces because of queue times and batching. Another example is for smaller facilities like Assembly or Test where we might schedule the entire facility together. (* from FPSINPUT.RTG_PROCESS_GROUPS) |
|
SCHED_IS_EXCLUSIVE_CHAMBER |
CHAR(1) |
to indicate if the chamber is exclusive on the tool where this lot scheduled to (* from FPSBASE.WIP_STEP_FUTURE_SCHED) |
|
|
SCHED_IS_RESERVED |
CHAR(1) |
||
|
SCHED_JOB_ID |
VARCHAR2(64) |
||
|
SCHED_LOT_TRANSIT_SEC |
NUMBER(6) |
to indicate the transit time needed to move the lot to the scheduled tool (* from FPSBASE.WIP_STEP_FUTURE_SCHED) |
|
|
SCHED_NOTES |
VARCHAR2(128) |
The notes will be used to be displayed in scheduler in lot list report on the lot level (* from FPSINPUT.WIP_STEP_FUTURE_OVR) |
|
|
SCHED_POD_FIRST_DISP_INST |
DATE |
||
|
SCHED_POD_KIT_READY_INST |
DATE |
||
|
SCHED_POD_KIT_START_INST |
DATE |
||
|
SCHED_PRE_BATCH_ID |
VARCHAR2(64) |
||
|
SCHED_PROCESS_CHANGE_SEC |
NUMBER(6) |
to indicate the process change time needed to run this lot (* from FPSBASE.WIP_STEP_FUTURE_SCHED) |
|
|
SCHED_QUEUE_START_DELAY_INST |
DATE |
to indicate the earliest time that to start to process the queue-start-step (* from FPSBASE.WIP_STEP_FUTURE_SCHED) |
|
|
SCHED_RANK |
NUMBER |
||
|
SCHED_RANK_DISPLAY |
VARCHAR2(500) |
||
|
SCHED_RQD_PORT_GROUP |
VARCHAR2(12) |
to indicate the required port group information of the tool that this lot scheduled to (* from FPSBASE.WIP_STEP_FUTURE_SCHED) |
|
|
SCHED_SCORE |
NUMBER(20,4) |
||
|
SCHED_SCORE_DETAILS |
VARCHAR2(4000) |
||
|
SCHED_SORT_ON_TOOL |
NUMBER(4) |
||
|
SCHED_START |
DATE |
The first start time for the durable to be used (* from FPSBASE.RTG_DURABLE_FUTURE_SCHED) |
|
|
SCHED_STATE |
VARCHAR2(7) |
||
|
SCHED_TOOL |
VARCHAR2(16) |
the tool from the first lot that scheduled (* from FPSAPP.SCH_W_SCHED_DURABLE_INSPECT) |
|
|
SCHED_ZONE_TO_USE |
VARCHAR2(1) |
While zone restricted batch scheduling is enabled, this column will be populated with the zone assignment corresponding to the ZONE in EQP_ZONES for the scheduled tool. (* from FPSBASE.WIP_STEP_FUTURE_SCHED) |
|
|
SEQ_NUM |
NUMBER(7,2) |
Sequence number of step in route (* from FPSINPUT.RTG_ROUTE_STEPS) |
|
|
SHOULD_SCHEDULE |
CHAR(1) |
Indicates if it should force scheduler to schedule this step or not. Setting this value to Y also forces a TAKE decision for this step in WIP_STEP_FUTURE. (* from FPSINPUT.WIP_STEP_FUTURE_OVR) |
|
|
SHOULD_USE |
CHAR(1) |
This flag determines if the scheduler should use this data or not |
|
|
STAGING_SEC |
NUMBER(7) |
||
|
STEP |
VARCHAR2(256) |
N |
A single processing step within a route representing a single tool visit. Step is often a very complex string and should rarely be displayed. Instead we should use process_display. (* from FPSINPUT.RTG_ROUTE_STEPS) |
|
STEP_BEG_BAY |
VARCHAR2(12) |
||
|
STEP_BEG_INST |
DATE |
||
|
STEP_BEG_LOCATION |
VARCHAR2(32) |
||
|
STEP_BEG_STATION |
VARCHAR2(32) |
||
|
STEP_DUE_INST |
DATE |
||
|
STEP_GOAL_INST |
DATE |
||
|
STEP_PRIORITY |
VARCHAR2(7) |
this will allow to override the priority at this step (* from FPSINPUT.WIP_STEP_FUTURE_OVR) |
|
|
STEP_QTY |
NUMBER(7) |
this will allow to override the qty at this step. we placed this here for future development first (* from FPSINPUT.WIP_STEP_FUTURE_OVR) |
|
|
STEP_SEC |
NUMBER(7) |
Step Sec |
|
|
STEP_SEC_TO_EOL |
NUMBER(11) |
Total Step sec to the end of line |
|
|
WAIT_SEC_TO_SCHED |
NUMBER(7) |
The lot may be scheduled but must not be allowed to dispatch or start until this number of seconds has elapsed. (* from FPSINPUT.WIP_LOTS_STATIC) |