FPSINPUT.PERF_P_H_COMP_WIP_MONTH

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)

LOT_GROUP

VARCHAR2(8)

N

Lot_group is a grouping of lot_family and is the highest grouping in the lot type hierarchy. There should be only a few values for lot_group, i.e. Prod, Dev, TW. We group WIP and moves by lot_group on the dashboard and we group cycle time calculations by lot_group so this is an important field. (* from FPSINPUT.WIP_LOT_GROUPS)

PLAN_PRIORITY

VARCHAR2(7)

N

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

WIP_MODULE

VARCHAR2(12)

N

BANK

VARCHAR2(36)

N

Lots which are not on a route are considered in a bank and the bank name indicates why the lot is off route. Bank must be NA for lots which are on a route. Our standard filter for active lots is bank = NA. (* from FPSINPUT.RTG_BANKS)

ROUTE

VARCHAR2(256)

N

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

WAFER_SIZE

VARCHAR2(8)

N

If the facility only has one wafer size then this column should be null in both RTG_PRDS and EQP_TYPES. If the facility has more than one wafer size then a value of null in EQP_TYPES means that those tools can run all wafer sizes. See column IS_ANY_WAFER_SIZE for details. (* from FPSINPUT.GEN_WAFER_SIZES)

ROUTE_FAMILY

VARCHAR2(36)

N

Route_family indicates that all routes within the family have similar or even identical steps and have the same segments. At facilities where various prds share the same route it is likely that the route will be the route_family. This is sometimes referred to as the main process flow. It is used on Segment Summary and Line Viewer to group similar routes. (* from FPSINPUT.RTG_ROUTE_FAMILIES)

ROUTE_GROUP

VARCHAR2(36)

N

Route_group is the parent of route_family. Route_group is used on the Dashboard and other applications as a large grouping for filtering. At many sites this is referred to as technology. (* from FPSINPUT.RTG_ROUTE_GROUPS)

OPERATION_FAMILY

VARCHAR2(36)

N

Grouping of route-step that is completely dependent on routing information from MES. The primary use of this field is for filtering on Operations Dashboard. Unfortunately for our database structure and naming convention, this field no longer has any link to operation. This is because operation is used primarily for Oper Moves and it is normal for steps in an operation to belong to multiple MES routing groups. For example, a sink step and a furnace step and a measurement step are in the same operation but each step belongs to the appropriate sink/furnace/measurement MES routing groups which we store in operation family. Since Dashboard already uses both operation and operation_family extensively and independently, we decided not to rename either column but simply remove the link. Please note that operation family is similar to process family and in fact they are often the same. The key differences are that operation family has nothing to do with equipment and that comes straight from ETL with no complex logic. Process family is the link between routing and equipment for the Operations Dashboard and therefore has complex logic. (* from FPSINPUT.RTG_OPERATION_FAMILIES)

PROCESS_FAMILY

VARCHAR2(50)

N

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

LINE_SECTION

VARCHAR2(32)

N

Large grouping of the line, e.g. FEOL, BEOL, Cu, etc. There should be only a handful of values for the entire facility - or if the facility only has one section then we can leave this column blank. (* from FPSINPUT.RTG_LINE_SECTIONS)

IS_IGNORE_WIP

CHAR(1)

N

This flag is in both RTG_OPERATION_FAMILIES and RTG_PROCESSES. If the value is Y for either the operation family or the process then we do not count WIP at the route-step towards the total for the facility. Typically this is set for staging operations. (* from FPSINPUT.RTG_OPERATION_FAMILIES)

IS_IGNORE_MOVES

CHAR(1)

N

This flag is in both RTG_OPERATION_FAMILIES and RTG_PROCESSES. If the value is Y for the operation family then we do not count moves from those operations as oper moves. If the value is Y for either the operation family or the process then we do not count moves from the route-step as completes even if our normal logic suggests that it should be a complete. This logic can cause confusion so here are a few important notes. 1) Dashboard does not read the is_ignore_moves flag therefore we must set move_type to DSKIP rather than COMP and we must set is_oper_move to N in order to ignore the move. 2) This flag is often used for staging steps but it is independent of the is_staging_step flag so if you want to ignore staging steps then you need to set these flags appropriately. 3) The flag in RTG_PROCESSES does not directly affect the oper moves but it does affect it indirectly if the is_comp_rqd_for_oper_move is set to Y. In that case, if the only move during the operation is for a process which is ignored then we do not have a complete during the operation and therefore will not count the move from the operation as an oper move since a complete is required. (* from FPSINPUT.RTG_OPERATION_FAMILIES)

START_MONTH

DATE

N

AVG_WIP

NUMBER

END_MONTH

DATE

END_WIP

NUMBER

GOAL_COMPLETES

NUMBER

Completes goal for the current shift. Typically we calculate either completes or moves goal depending on the site logic and then either multiply moves by est_smp_pct to get completes or divide completes by est_smp_pct to get moves. (* from FPSINPUT.WIP_GOALS_PER_SHIFT)

GOAL_MOVES

NUMBER

Moves goal for the current shift means how many units we need to move through this step to progress towards our demand or due date. This could be either a complete or a skip. Typically we calculate either completes or moves goal depending on the site logic and then either multiply moves by est_smp_pct to get completes or divide completes by est_smp_pct to get moves. (* from FPSINPUT.WIP_GOALS_PER_SHIFT)

GOAL_OPER_MOVES

NUMBER

Oper moves goal for the current shift. This should be recorded at only one step of the operation at it can be at any step not necessarily the last one. Since we do not get an oper move if we skip the entire operation, this is typically the maximum goal completes for any step in the operation. Some sites might calculate goal oper moves independently and potentially even get goal moves and completes from the goal oper moves. (* from FPSINPUT.WIP_GOALS_PER_SHIFT)

GOAL_WIP

NUMBER

WIP goal for each shift. If you are using the GP logic in FPSAPP to get WIP goals for line balancing then you might want to pull those goals into this table to show on Dashboard. If not, this can be calculated by dividing the goal moves per day (from this logic) by the commit cycle time in days for the step (from CTM_SUMMARY_PLUS). (* from FPSINPUT.WIP_GOALS_PER_SHIFT)

LOT_GROUP_DISPLAY

VARCHAR2(24)

The name of the lot_group displayed on all dashboards and reports. We allow a longer more descriptive name here although often this will be the same as the lot_group. (* from FPSINPUT.WIP_LOT_GROUPS)

LOT_GROUP_SORT

NUMBER

MODULE_DISPLAY

VARCHAR2(20)

The name of the module displayed on all dashboards and reports. We allow a longer more descriptive name here although often this will be the same as the module. (* from FPSINPUT.GEN_MODULES)

MONTH

VARCHAR2(9)

NUM_SHIFTS

NUMBER

PRIORITY_DISPLAY

VARCHAR2(20)

The name of the priority displayed on all dashboards and reports. Typically priority is short like P1, P2 so we allow a longer more descriptive name here that should be more familiar to the users. (* from FPSINPUT.WIP_PRIORITIES)

PRIORITY_SORT

NUMBER

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

PROCESS_CLASS

VARCHAR2(12)

Top-level grouping of process groups with same general purpose (i.e. Process or Metrology or Nonwafer). Allowed values are defined by FPS and are listed in FPSADMIN.RTG_PROCESS_CLASSES. This field can also be defined in EQP_TOOLS using the ovr_process_class field if we do not know it for the process group. (* from FPSINPUT.RTG_PROCESS_GROUPS)

QTY_COMP

NUMBER

QTY_CREATED

NUMBER

QTY_MOVED

NUMBER

QTY_OPER_COMPS

NUMBER

QTY_OPER_MOVES

NUMBER

QTY_SCRAPPED_FULL

NUMBER

QTY_SCRAPPED_PARTIAL

NUMBER

QTY_SHIPPED

NUMBER

TOTAL_PROC_SEC

NUMBER

TOTAL_STEP_SEC

NUMBER

Total number of unit-seconds accumulated by lots on hold at this step during the period including lots which moved out during the period and lots which remain at the end of the period. For example, if a 25 wafer lot is on hold at the step for 2 hours then it accumulates 25 wafers * 7200 seconds = 180000 wafer-seconds of hold time. (* from FPSBASE.WIP_END_SHIFT_HIST)