FPSADMIN.CHK_WIP_STEP_FUTURE_PLUS

PROBLEM

UPDATED_INST

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. (* inherited from FPSINPUT.GEN_FACILITIES)

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)

NUM_SEQ_AWAY

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. (* inherited from FPSBASE.WIP_STEP_FUTURE)

NUM_STEPS_AWAY

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. (* inherited from FPSBASE.WIP_STEP_FUTURE)

NUM_STEPS_TO_RETURN

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)

ROUTE

Route that has threading requirements (* inherited from FPSINPUT.RTG_STEP_THREADING)

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)

CURR_COMP_TO_EARLIEST_ARRV_SEC

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. (* inherited from FPSBASE.WIP_STEP_FUTURE)

CURR_COMP_TO_EXPECTED_ARRV_SEC

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. (* inherited from FPSBASE.WIP_STEP_FUTURE)

CURR_COMP_TO_EARLIEST_COMP_SEC

CURR_COMP_TO_EXPECTED_COMP_SEC

EARLIEST_STEP_ENT_INST

EARLIEST_COMP_INST

EXPECTED_STEP_ENT_INST

EXPECTED_COMP_INST

CURR_STEP_EARLIEST_COMP_INST

CURR_STEP_EST_COMP_INST

SCHED_START

The first start time for the durable to be used (* inherited from FPSBASE.RTG_DURABLE_FUTURE_SCHED)

SCHED_END

SQL_QUERY