data-dictionary

FPSINPUT.WIP_GOAL_LOT_SHIFT

Data Dictionary

>

FPSINPUT Tables

> FPSINPUT.WIP_GOAL_LOT_SHIFT

Table FPSINPUT.WIP_GOAL_LOT_SHIFT"

Goal Planner information about each lot for current and future route-steps. Shift is the shift in which the data was loaded but lot schedules can also include future shifts as indicated by the earliest and goal shift columns. This table only has current and futute shift information whereas the hist version includes data loaded from prior shifts.

  • Schema: FPSINPUT

  • Tablespace: FPSDATA

  • Primary key: LOT, ROUTE, STEP


Column

Type

Nullable

Comment

LOT

VARCHAR2(32)

N

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)

ROUTE

VARCHAR2(256)

N

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

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)

BATCH_CRITERIA

VARCHAR2(140)

Lots that can run on the same batch TOOL and have the same value of BATCH_CRITERIA can run together in a batch. Therefore this is a critical column for scheduling on batch tools. If BATCH_CRITERIA is not populated, Scheduler defaults to the assumption that any WIP with the same EST_MACHINE_RECIPE can be batched together. Keep in mind that many MESs have additional constraints on batching (for example, that all WIP in a batch has the same SCRIPT_ID) and these must be incorporated into BATCH_CRITERIA to ensure that the batches are allowed by the MES. (* from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

BATCH_ID

VARCHAR2(150)

BATCH_PROC_MINS

NUMBER(7,2)

BATCH_PROC_MINS_EFF

NUMBER(7,2)

BATCH_PROC_MINS_EFF_REASON

VARCHAR2(200)

BATCH_QTY_EFF

NUMBER(3)

BUNCH_ID

VARCHAR2(17)

Chain lots together for Goal Planner (* from FPSINPUT.WIP_LOTS_STATIC)

CHAIN_PRIORITY

VARCHAR2(7)

DAYS_BEHIND

NUMBER(5,2)

DRUM_PRIORITY_SORT

NUMBER(3)

DRUM_PRIORITY_SORT_REASON

VARCHAR2(200)

DRUM_QTY_PLANPRD

NUMBER(7)

DRUM_QTY_ROUTE

NUMBER(7)

DUE_INST

DATE

To indicate the due date for this futuer start lot (* from FPSINPUT.WIP_STARTS)

EARLIEST_COMP_INST

DATE

EARLIEST_COMP_PERIOD_NUM

NUMBER(3)

EARLIEST_COMP_SHIFT

VARCHAR2(13)

EST_MACHINE_RECIPE

VARCHAR2(100)

Estimated machine recipe what we estimate will be the machine recipe based on information from the Recipe Management System. It is used in combination with process for throughput calculations and setup change penalty calculations. It is not necessary to estimate for all processes since this is always used in combination however it needs to be NA rather than blank since it is part of the primary key of most THP tables. Hopefully when this is not NA it should match the actual machine recipe logged for each lot during processing. (* from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

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.

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)

GOAL_BEGIN_INST

DATE

Time when the lot has to complete the current step to remain on schedule. (* from FPSBASE.WIP_STEP_HIST)

GOAL_CAP_COMP_INST

DATE

GOAL_COMP_INST

DATE

GOAL_COMP_PERIOD_NUM

NUMBER(3)

GOAL_COMP_SHIFT

VARCHAR2(13)

GOAL_NOCAP_COMP_INST

DATE

GOAL_NOCAP_COMP_PERIOD_NUM

NUMBER(3)

GOAL_NOCAP_COMP_SHIFT

VARCHAR2(13)

GOAL_QUEUE_SEC

NUMBER(9)

GP_PRIORITY_SORT

NUMBER(3)

GP_PRIORITY_SORT_REASON

VARCHAR2(200)

GP_SUBFAMILY

VARCHAR2(58)

GP_subfamily is used for Goal Planner and is an extension of process_family which can additionally include lot_group and an additional suffix. We populate GP_subfamily automatically based on process_family, process_subfamily, gp_subfamily_suffix, and add_lotgrp_to_gp_subfamily using the function GET_GP_SUBFAMILY. We build this starting with nvl(process_subfamily, process_family) followed by gp_subfamily_suffix if populated then followed by lot_group if add_lotgrp_to_gp_subfamily is set to Y. It is possible to have one or two or three parts. You might have values for process_family/process_subfamily/gp_subfamily_suffix/add_lotgrp of Furn/blank/blank/Y and that would give you gp_subfamilies of Furn/Prod and Furn/Dev. Or Furn/HighTemp/blank/Y would give you HighTemp/Prod and HighTemp/Dev. Or Sink/blank/FeedsOxFurn/N would give you Sink/FeedsOxFurn. And so on. (* from FPSBASE.WIP_END_SHIFT_HIST)

GP_SUBFAMILY_CAP_MINS

NUMBER(9,2)

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_NONSTD

CHAR(1)

Our column to indicate non-standard processing at the step. For example, an experiment or a chain that is only active at a particular step or set of steps and then goes back to being normal for the route. If an experiment is severe enough that it affects the final product and has to be planned separately then it will be its own prd or planprd. (* from FPSBASE.WIP_LOT_HIST)

IS_START_STEP

CHAR(1)

LB_PRIORITY_SORT

NUMBER(3)

LB_PRIORITY_SORT_REASON

VARCHAR2(200)

LOG_IS_OVER_MAX_GPSF_CAP

VARCHAR2(100)

LOG_IS_OVER_MAX_GPSF_RCPSETUP

VARCHAR2(100)

LOG_IS_OVER_MAX_PF_CAP

VARCHAR2(100)

LOG_IS_OVER_MAX_PSG_ALL

VARCHAR2(100)

LOG_IS_OVER_MAX_PSG_PLANPRD

VARCHAR2(100)

LOG_IS_OVER_MAX_PSG_RECIPE

VARCHAR2(100)

LOG_IS_OVER_MAX_PSG_ROUTE

VARCHAR2(100)

LOG_IS_UNDER_MIN_BATCH

VARCHAR2(100)

LOG_IS_UNDER_MIN_GPSF_RCPSETUP

VARCHAR2(100)

LOG_IS_UNDER_MIN_PSG_ALL

VARCHAR2(100)

LOG_IS_UNDER_MIN_PSG_PLANPRD

VARCHAR2(100)

LOG_IS_UNDER_MIN_PSG_RECIPE

VARCHAR2(100)

LOG_IS_UNDER_MIN_PSG_ROUTE

VARCHAR2(100)

LOG_PERIOD_NUM_PROPOSED

VARCHAR2(100)

LOT_PRIORITY

VARCHAR2(7)

N

LOT_PRIORITY_SORT

NUMBER(3)

LOT_TYPE

VARCHAR2(24)

Lot_type is the base of the hierarchy that determines lot_family then lot_group. Ideally lot_type will come straight from the MES with little modification. (* from FPSINPUT.WIP_LOT_TYPES)

PARENT_LOT

VARCHAR2(32)

The parent lot should ideally be the original parent but it could be the most recent parent if multiple splits have occurred. (* from FPSINPUT.WIP_LOTS_STATIC)

PLANPRD

VARCHAR2(64)

N

Planning product used for all planning purposes. All lots with the same planprd are interchangeable to ship to the customer regardless of their prd, route, technology, wafer size, etc. For detailed information on prd vs. planprd see table comments in RTG_PLANPRDS. (* from FPSINPUT.RTG_PLANPRDS)

PLAN_PRIORITY

VARCHAR2(7)

N

Permanent priority of the lot set in the MES generally by planning. (* from FPSINPUT.WIP_EVENT_HIST)

POSTP_SEC

NUMBER(7)

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_FAMILY

VARCHAR2(50)

See https://help.inficonims.com/display/DW/Guide+to+Process+Families. (* from FPSINPUT.RTG_PROCESS_FAMILIES)

PROCESS_FAMILY_CAP_MINS

NUMBER(9,2)

PROC_SEC

NUMBER(9)

QTY

NUMBER(2)

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)

QTY_EFF

NUMBER(2)

QUEUE_PCT

NUMBER(3)

QUEUE_PCT_EFF

NUMBER(3)

QUEUE_PRIORITY

VARCHAR2(7)

RQD_SETUP

VARCHAR2(100)

Rqd_setup is determined by ovr_rqd_setup in RTG_TOOL_ASSIGNMENTS and use_process_as_rqd_setup and use_est_mach_rcp_as_rqd_setup from EQP_TYPES. The latter two columns allow us to easily specify for an eqp_type that setup times should be calculated by process or est_machine_recipe. For traditional setups that are a group of recipes we use ovr_rqd_setup. (* from FPSBASE.WIP_LOT_HIST)

SCHED_PRIORITY_SORT

NUMBER(3)

SCHED_PRIORITY_SORT_REASON

VARCHAR2(200)

SEQ_NUM

NUMBER(7,2)

Sequence number of step in route (* from FPSINPUT.RTG_ROUTE_STEPS)

SEQ_NUM_OVERALL

NUMBER(7,2)

SHIFT

VARCHAR2(13)

Name of shift must be unique and can be in any format as long as it is display friendly since this is what we show everywhere. We prefer that other tables should reference start_shift rather than shift in case we want to change the naming convention for the shift. (* from FPSINPUT.CAL_SHIFTS)

SHIP_PRIORITY

VARCHAR2(7)

START_SHIFT

DATE

Shifts can be of any length and it is important that all queries get the shift length based on start_shift and end_shift rather than assuming a set number of hours. (* from FPSINPUT.CAL_SHIFTS)

TARGET_WIP_QTY_PLANPRD

NUMBER(7)

TARGET_WIP_QTY_ROUTE

NUMBER(7)

TWR_CURR_PLANPRD

NUMBER(8,2)

TWR_CURR_ROUTE

NUMBER(8,2)

TWR_FUTURE_PLANPRD

NUMBER(8,2)

TWR_FUTURE_ROUTE

NUMBER(8,2)