data-dictionary

FPSINPUT.GP_P_PRIORITY_DRUM

Data Dictionary

>

FPSINPUT Tables

> FPSINPUT.GP_P_PRIORITY_DRUM

Table FPSINPUT.GP_P_PRIORITY_DRUM"

See comments in GP_REF_P_PRIORITY_DRUM view.

  • Schema: FPSINPUT

  • Tablespace: FPSDATA

  • Primary key: FACILITY, ROUTE, STEP


Column

Type

Nullable

Comment

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)

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)

COMMON_STEP

VARCHAR2(50)

N

A display-friendly field that groups similar steps together for purposes of viewing the entire line. Typically the only duplicates within a single route will be optional ordered steps in the same segment. But we will often have steps across routes that share the same common step even though exact step definition is not identical. (* from FPSINPUT.RTG_COMMON_STEPS)

COMP_QTY_COMSTEP

NUMBER

COMP_QTY_COMSTEP_LONG

NUMBER

COMP_QTY_COMSTEP_RT_FAM

NUMBER

COMP_QTY_COMSTEP_RT_FAM_LONG

NUMBER

COMP_QTY_COMSTEP_RT_GRP

NUMBER

COMP_QTY_COMSTEP_RT_GRP_LONG

NUMBER

COMP_QTY_FINAL

NUMBER

COMP_QTY_FINAL_LONG

NUMBER

COMP_QTY_PROCESS

NUMBER

COMP_QTY_PROCESS_LONG

NUMBER

COMP_QTY_PROCESS_RT_FAM

NUMBER

COMP_QTY_PROCESS_RT_FAM_LONG

NUMBER

COMP_QTY_PROCESS_RT_GRP

NUMBER

COMP_QTY_PROCESS_RT_GRP_LONG

NUMBER

COMP_QTY_RT_STEP

NUMBER

COMP_QTY_RT_STEP_LONG

NUMBER

DRUM_CRITERIA

VARCHAR2(513)

This is the level of counting that will be multiplied by within the scheduler to dynamically score the drum rate as lots are placed on a schedule run

DRUM_GROUPING

VARCHAR2(24)

N

Allowed values are "ROUTE STEP", "ROUTE FAMILY COMMON STEP", "ROUTE GROUP COMMON STEP", "COMMON STEP", "ROUTE FAMILY PROCESS", "ROUTE GROUP PROCESS", and "PROCESS". This determines the level at which the drum is aggregated. ROUTE STEP means the drum calculation is evaluated within each route for each step. COMMON STEP means the drum calculation is evaluated across routes for each COMMON STEP, assuming common steps are shared across routes. PROCESS means the drum calculation is evaluated across routes for each PROCESS, assuming processes are shared across routes. (* from FPSAPP.GP_C_FACILITY)

DRUM_MV_FACTOR

NUMBER

This is the per move factor in which the drum rate will adjust for use in the scheduler to dynamically score the drum rate as lots are placed on a schedule run

DRUM_NORMALIZATION_GROUPING

VARCHAR2(32)

See comments on LB_NORMALIZATION_GROUPING. This field does the same thing for drum scoring (* from FPSAPP.GP_C_FACILITY)

DRUM_NORMALIZATION_METHOD

VARCHAR2(24)

See comments on LB_NORMALIZATION_METHOD. This field does the same thing for drum scoring (* from FPSAPP.GP_C_FACILITY)

DRUM_QTY_COMSTEP

NUMBER

DRUM_QTY_COMSTEP_LONG

NUMBER

DRUM_QTY_COMSTEP_RT_FAM

NUMBER

DRUM_QTY_COMSTEP_RT_FAM_LONG

NUMBER

DRUM_QTY_COMSTEP_RT_GRP

NUMBER

DRUM_QTY_COMSTEP_RT_GRP_LONG

NUMBER

DRUM_QTY_FINAL

NUMBER

DRUM_QTY_FINAL_LONG

NUMBER

DRUM_QTY_PROCESS

NUMBER

DRUM_QTY_PROCESS_LONG

NUMBER

DRUM_QTY_PROCESS_RT_FAM

NUMBER

DRUM_QTY_PROCESS_RT_FAM_LONG

NUMBER

DRUM_QTY_PROCESS_RT_GRP

NUMBER

DRUM_QTY_PROCESS_RT_GRP_LONG

NUMBER

DRUM_QTY_RT_STEP

NUMBER

DRUM_QTY_RT_STEP_LONG

NUMBER

DRUM_SCORE_COMSTEP

NUMBER

DRUM_SCORE_COMSTEP_LONG

NUMBER

DRUM_SCORE_COMSTEP_RT_FAM

NUMBER

DRUM_SCORE_COMSTEP_RT_FAM_LONG

NUMBER

DRUM_SCORE_COMSTEP_RT_GRP

NUMBER

DRUM_SCORE_COMSTEP_RT_GRP_LONG

NUMBER

DRUM_SCORE_FINAL

NUMBER

DRUM_SCORE_LINEAR

NUMBER

DRUM_SCORE_LOGISTIC

NUMBER

DRUM_SCORE_LONG

NUMBER

DRUM_SCORE_PROCESS

NUMBER

DRUM_SCORE_PROCESS_LONG

NUMBER

DRUM_SCORE_PROCESS_RT_FAM

NUMBER

DRUM_SCORE_PROCESS_RT_FAM_LONG

NUMBER

DRUM_SCORE_PROCESS_RT_GRP

NUMBER

DRUM_SCORE_PROCESS_RT_GRP_LONG

NUMBER

DRUM_SCORE_RT_STEP

NUMBER

DRUM_SCORE_RT_STEP_LONG

NUMBER

DRUM_SCORE_SHORT

NUMBER

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)

LONG_WINDOW_RATIO

NUMBER

OPERATION

VARCHAR2(50)

Operation is usually the primary level of routing in the MES and the level where the facility typically reports moves. FPS only allows one tool per step so our step is a lower level of routing than operation although both may be the same if the MES only allows one tool per operation. Note that because operation can include multiple steps and therefore multiple process families that we cannot have any association to equipment by operation. (* from FPSINPUT.RTG_OPERATIONS)

PERIOD_RATIO

NUMBER

PHOTO_LAYER

VARCHAR2(12)

The photo layer the step belongs to. (* from FPSINPUT.RTG_ROUTE_STEPS)

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

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)

PROCESS_MODULE

VARCHAR2(12)

N

WIP_MODULE is used to credit moves and set goals. See comments on the module column in GEN_MODULES for info on this column and how it relates to eqp_module and mnt_module. (* from FPSBASE.RTG_ROUTE_STEPS_PLUS)

ROUTE_FAMILY

VARCHAR2(36)

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)

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)

ROUTE_SECTION

VARCHAR2(32)

A large grouping of route steps used for line balance and should be set to contain at least a week of steps based on cycle time. Line balance uses this grouping instead of segment so that it can be configured independently from segment which is used in the Dashboard for display purposes, but they can also be set the same if desired. The section should be large in order to minimize the impact of short-term WIP distribution changes on step WIP targets because line balance calculates step WIP targets based on the WIP currently in each section. (* from FPSINPUT.RTG_ROUTE_STEPS)

ROUTE_SEGMENT

VARCHAR2(36)

Route_segment allows for clear hierarchical segment organization for Segment Summary and Line Viewer on Dashboard. This is often referred to as stage and typically will come from the MES (as opposed to facility_segment which we will typically have to define for our purposes). We recommend that all routes in the same route family have the same route segments in the same order so that the Line Viewer by route family will be consistent but if this is not the case then we approximate the order as best we can. (* from FPSINPUT.RTG_ROUTE_STEPS)

SAMPLE_RATIO

NUMBER

SCHED_GROUP

VARCHAR2(36)

This is the grouping of tools and processes which the FPS Scheduler schedules together. Since this is a parent of tool via tool->process_group and a parent of process via process->process_group, by definition each tool and each process can only be in one sched group. We need all related tools and processes to be in the same sched group for efficient scheduling. One example is sinks and furnaces because of queue times and batching. Another example is for smaller facilities like Assembly or Test where we might schedule the entire facility together. (* from FPSINPUT.RTG_PROCESS_GROUPS)