Data Dictionary
>
FPSBASE Views
> FPSBASE.WIP_WAFER_HIST_LOOP
View FPSBASE.RTG_REF_QUEUE_MULTI_AREA_STEPS
This table has each step in the timer sequence after the start step for every lot and timer_id. It is used as a base for both RTG_QUEUE_MULTI_AREA_WIP and RTG_QUEUE_MULTI_AREA_PATH. We use left join on WIP_STEP_FUTURE so we only calculate WIP for all timers even with no lots coming. This is because the timer could be full of lots inside even with none coming and we want to start any lot that unexpectedly arrives at the start step. Our logic to use this will first look for the specific lot+route+start_step which allows us to set wait_sec_to_sched by lot so we can slowly release lots based on WIP conditions. But if we have no information on the specific lot then we will stop any lot.
|
Column |
Comment |
|---|---|
|
TIMER_ID |
Unique number representing the queue timer to index with other tables. Automatically populated with RTG_QUEUE_TIMERS_ID_SEQ sequence. (* inherited from FPSINPUT.RTG_QUEUE_TIMERS) |
|
FACILITY |
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. (* inherited from FPSINPUT.GEN_FACILITIES) |
|
ROUTE |
Route that has threading requirements (* inherited from FPSINPUT.RTG_STEP_THREADING) |
|
START_STEP |
Start step that will impact the future thread step rank in RTG_TOOL_ASSIGNMENT_LOT (* inherited from FPSINPUT.RTG_STEP_THREADING) |
|
END_STEP |
The step upon move out where the WIP balance limit is no longer applied (* inherited from FPSINPUT.RTG_STEP_BALANCE) |
|
EXPIRED_SEC |
Seconds from the start event until queue time restriction is expired. After expiration, the lot must rework or scrap or otherwise be evaluated. (* inherited from FPSINPUT.RTG_QUEUE_TIMERS) |
|
WARN_SEC |
Seconds from the start event until warning limit for queue time restriction. Lots that remain in the timer sequence longer than this warning limit should be prioritized to prevent them from expiring. (* inherited from FPSINPUT.RTG_QUEUE_TIMERS) |
|
RWK_IF_EXPIRED |
Indicates whether rework is required after queue timer expires. If allowed, we need to specify the route and step that we expect the lot to move into for rework. (* inherited from FPSINPUT.RTG_QUEUE_TIMERS) |
|
FEED_IF_LESS_THAN_SEC |
If WIP in the queue sequence as measured by total seconds of EET is below this number then we should prioritize lots entering the sequence. (* inherited from FPSINPUT.RTG_QUEUE_TIMERS) |
|
MIN_WAIT_SEC |
All lots must wait at least this many seconds at the step before processing. This column is the opposite of the others and can only be populated if the others are null. Also start_step and end_step must be the same since this can only apply at a single step. (* inherited from FPSINPUT.RTG_QUEUE_TIMERS) |
|
OVR_IS_QUEUE_STOPPED |
This is Y if we know from the customer logic that lots cannot start the first step in the queue because their logic has determined that there is too much WIP already in the queue sequence. In the future, we will also use our own logic for this so we stop lots if this is Y or if our logic says to stop. In both cases, we can allow specific lots to go through using ovr_is_queue_allowed in WIP_LOTS_STATIC. (* inherited from FPSINPUT.RTG_QUEUE_TIMERS) |
|
OVR_WAIT_SEC_TO_SCHED |
|
|
LOT |
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. (* inherited from FPSINPUT.WIP_LOTS_STATIC) |
|
START_NUM_STEPS_AWAY |
|
|
QTY |
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. (* inherited from FPSINPUT.WIP_EVENT_HIST) |
|
SCHED_START_AT_START_STEP |
|
|
PRIORITY_SORT |
Unique sort of priority. Sort ascending gives the order from highest to lowest priority. Therefore the smallest number in priority_sort is the highest priority. (* inherited from FPSINPUT.WIP_PRIORITIES) |
|
GBL_SORT |
Sorting used for dispatching or allocation systems to sort future start lots based on priority, critical ratio, etc. (* inherited from FPSINPUT.WIP_STARTS) |
|
START_SEQ_NUM |
|
|
END_SEQ_NUM |
|
|
SCHED_GROUP_OF_START_STEP |
|
|
STEP |
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. (* inherited from FPSINPUT.RTG_ROUTE_STEPS) |
|
SEQ_NUM |
Sequence number of step in route (* inherited from FPSINPUT.RTG_ROUTE_STEPS) |
|
PROCESS_FAMILY |
See https://help.inficonims.com/display/DW/Guide+to+Process+Families. (* inherited from FPSINPUT.RTG_PROCESS_FAMILIES) |
|
PROCESS_SUBFAMILY |
Route step family is used for the Dashboard to separate processes in a process family based on shared but limited assignments. It is also the base for GP subfamily. (* inherited from FPSBASE.RTG_ROUTE_STEPS_PLUS) |
|
SCHED_GROUP |
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. (* inherited from FPSINPUT.RTG_PROCESS_GROUPS) |
|
MPU_FOR_EST_MOVE |
|
|
SCHED_START |
The first start time for the durable to be used (* inherited from FPSBASE.RTG_DURABLE_FUTURE_SCHED) |
|
EST_SMP_PCT |
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. (* inherited from FPSBASE.WIP_GOAL_LOT_SHIFT) |
|
SCHED_GROUP_LIST |
|
|
NON_TIMER_WIP_PCT |
When calculating the time required to process WIP through a queue timer segment, we normally consider both WIP on queue timers, as well as non-queue-time-limited WIP in the same area, equally in terms of their impact on the available capacity of the tools required to run the segment. If this is set to <100%, then we under-weight the impact of the non-queue-time-limited WIP accordingly. We strongly recommend keeping it at 100%, because setting it to a low value can cause scheduler to prioritize excessive queue timer WIP, and delay running non-queue-time-limited WIP. (* inherited from FPSINPUT.RTG_QUEUE_TIMERS) |
|
IS_STAGING_STEP |
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. (* inherited from FPSINPUT.RTG_ROUTE_STEPS) |
|
ALWAYS_ALLOW_Q_WHEN_DOWN |
Normally we do not allow lots to start at the first step in a queue timer sequence if there is a step in the sequence that has no tools available. But if this flag is set to Y then we will allow lots to start even when all tools are down at this process. Typically this is used for a process that we know we can skip but the est_smp_pct might be above the smp_pct_to_allow_q_when_down threshold set for the facility in GEN_FACILITIES. (* inherited from FPSINPUT.RTG_PROCESSES) |