data-dictionary

FPSADMIN.WIP_STEP_FUTURE

Data Dictionary

>

FPSADMIN Tables

> FPSADMIN.WIP_STEP_FUTURE

Table FPSADMIN.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: FPSADMIN

  • 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)