Data Dictionary
>
FPSINPUT Tables
> FPSINPUT.WIP_STEP_FUTURE
Table FPSINPUT.WIP_STEP_FUTURE"
Future steps for all lots including time to arrival and the goal on when to complete that step. See comment in UPDATE_WIP_STEP_FUTURE procedure for info on the logic. This also includes the current step since we need the goal for the current step. Please note facility is part of the primary key because the future step could be in a different facility than where the lot is currently.
-
Schema: FPSINPUT
-
Tablespace: FPSDATA
|
Column |
Type |
Nullable |
Comment |
|---|---|---|---|
|
LOT |
VARCHAR2(128) |
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) |
|
|
STEP |
VARCHAR2(256) |
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) |
|
|
ROUTE |
VARCHAR2(256) |
Route that has threading requirements (* from FPSINPUT.RTG_STEP_THREADING) |
|
|
FACILITY |
VARCHAR2(6) |
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) |
|
|
CURR_COMP_TO_EARLIEST_ARRV_SEC |
NUMBER(10) |
N |
The comment on CURR_COMP_TO_EXPECTED_ARRV_SEC applies here too. The only difference is that this column is what we consider the earliest possible arrival rather than the expected arrival. |
|
CURR_COMP_TO_EARLIEST_COMP_SEC |
NUMBER(10) |
N |
|
|
CURR_COMP_TO_EXPECTED_ARRV_SEC |
NUMBER(10) |
N |
We use this numeric field rather than the date field EXPECTED_ARRV_INST but the date field depends on the estimated complete of the current step which depends on the current time. Therefore in order for EXPECTED_ARRV_INST to be accurate we would have to change it every second! Instead we use this field to store the seconds from the complete of the current step to the arrival which only needs to be updated when the lot changes steps. Then we do the calculations to get EXPECTED_ARRV_INST using the current time in the WIP_STEP_FUTURE_PLUS view. For all steps which are one step away, this value is always 0 which makes sense because the complete of the current step is the same as the arrival of the next step. |
|
CURR_COMP_TO_EXPECTED_COMP_SEC |
NUMBER(10) |
N |
|
|
CURR_PRIORITY |
VARCHAR2(7) |
N |
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_REASON |
VARCHAR2(128) |
An optional description of why the priority is set as it is. This is typically shown as additional information on pages related to priority lots. (* from FPSINPUT.WIP_LOTS_STATIC) |
|
|
EARLIEST_STEP_SEC |
NUMBER(9) |
||
|
EST_QTY_AT_ARRV |
NUMBER(7) |
N |
This column degrades the current qty by the estimated line yield at steps between the current step and future step so this represents the expected qty of the lot when it arrives to the future step. This is unlikely to be different than the current qty in a Fab but is quite important for Test/Sort/Assembly. |
|
EST_SMP_PCT |
NUMBER(5,2) |
N |
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) |
|
EXPECTED_STEP_SEC |
NUMBER(9) |
||
|
FIRST_FUT_HOLD_NOTE |
VARCHAR2(512) |
||
|
FIRST_FUT_HOLD_NUM_STEPS_AWAY |
NUMBER(4) |
||
|
FIRST_FUT_HOLD_STEP |
VARCHAR2(256) |
||
|
FIRST_FUT_HOLD_TYPE |
VARCHAR2(24) |
||
|
FUT_HOLD_NOTE_AT_STEP |
VARCHAR2(512) |
||
|
FUT_HOLD_SEC_AT_STEP |
NUMBER(7) |
N |
|
|
FUT_HOLD_SEC_TO_ARRV |
NUMBER(10) |
N |
|
|
FUT_HOLD_TYPE_AT_STEP |
VARCHAR2(24) |
||
|
GOAL_BEGIN_INST |
DATE |
Time when the lot has to complete the current step to remain on schedule. (* from FPSBASE.WIP_STEP_HIST) |
|
|
GOAL_COMMENT |
VARCHAR2(512) |
||
|
GOAL_COMP_INST |
DATE |
||
|
IS_BANK |
CHAR(1) |
||
|
IS_IN_NMV_PICK_LIST |
CHAR(1) |
Set to Y if lot-step is within range to be displayed in NextMove Pick List according to hours/steps_to_schedule fields in GEN_FACILITIES |
|
|
IS_IN_PRTY_GANTT |
CHAR(1) |
N |
|
|
IS_NEXT_STEP |
CHAR(1) |
||
|
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_STEP_AFTER_LOT_ASGN |
CHAR(1) |
||
|
LINE_YIELD_PCT_TO_ARRV |
NUMBER(6,3) |
N |
|
|
NUM_SEQ_AWAY |
NUMBER(4) |
N |
Number of steps away including all steps which will or might be skipped. We name this column seq because it is just the delta in seq_num between the current step and the future step. |
|
NUM_SEQ_AWAY_W_DECIMAL |
NUMBER(6,2) |
||
|
NUM_SEQ_TO_RETURN |
NUMBER(4) |
||
|
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. |
|
|
NUM_STEPS_TO_RETURN |
NUMBER(4) |
||
|
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) |
N |
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_FAMILY |
VARCHAR2(50) |
See https://help.inficonims.com/display/DW/Guide+to+Process+Families. (* from FPSINPUT.RTG_PROCESS_FAMILIES) |
|
|
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) |
|
|
SCHED_GROUP |
VARCHAR2(36) |
Sched group is populated only if lot-step is within range to be scheduled according to hours/steps_to_schedule fields in RTG_SCHED_GROUPS. Index is on sched_group only and not facility because a row will not be indexed if all the indexed columns are null. Leaving out facility which is always not null means the index will be much smaller which will improve query speed. |
|
|
SEQ_NUM |
NUMBER(7,2) |
N |
Sequence number of step in route (* from FPSINPUT.RTG_ROUTE_STEPS) |
|
SMP_RESULT |
VARCHAR2(4) |
Either TAKE or SKIP (* from FPSINPUT.WIP_SMP_FUTURE) |
|
|
TIMER_ID_END_STEP |
NUMBER(9) |
This indicates that this step is in the middle of a queue timer. Inner join with RTG_QUEUE_TIMERS using timer_id as there is no foreign key because the timer_id record might get deleted from RTG_QUEUE_TIMERS. |
|
|
TIMER_ID_MID_STEP |
NUMBER(9) |
This indicates that this step is the end of a queue timer. Inner join with RTG_QUEUE_TIMERS using timer_id as there is no foreign key because the timer_id record might get deleted from RTG_QUEUE_TIMERS. |
|
|
TIMER_ID_START_STEP |
NUMBER(9) |
This indicates that this step is the start of a queue timer. Inner join with RTG_QUEUE_TIMERS using timer_id as there is no foreign key because the timer_id record might get deleted from RTG_QUEUE_TIMERS. |
|
|
TRG_TIME |
TIMESTAMP(6) |
N |
|
|
UPDATED_INST |
DATE |
N |
Time when the record was updated according to the source data. Note this is not the time when the record was actually updated in this table - it will almost always be earlier. (* from FPSINPUT.GEN_FACILITIES) |
|
UPDATE_LATER_WHEN_CAUGHT_UP |
CHAR(1) |
||
|
WAIT_SEC_TO_SCHED_QUEUE |
NUMBER(7) |