Data Dictionary
>
FPSINPUT Views
> FPSINPUT.WIP_WAFER_HIST_LOOP
View FPSAPP.GP_REF_P_ROUTE_STEPS
This view joins base route/step information on itself and filters for upcoming steps that are within the designated horizon days or num steps away. It uses the current and target WIP information to determine current and future target WIP deltas and then weighted averages the future target WIP deltas (weighting nearer steps more heavily) to determine a single future target WIP delta. The current step's current to target WIP delta minus the future target WIP delta is the line balance qyt delta. There are separate views for each level of detail which was deemed easier to manage than using one larger query with many more partitions and joins at the different levels of detail. Changes made in one view section should likely be made in the others.
|
Column |
Comment |
|---|---|
|
FACILITY |
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. (* inherited from FPSINPUT.GEN_FACILITIES) |
|
ROUTE |
Route that has threading requirements (* inherited from FPSINPUT.RTG_STEP_THREADING) |
|
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) |
|
COMMON_STEP |
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. (* inherited from FPSINPUT.RTG_COMMON_STEPS) |
|
PROCESS |
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. (* inherited from FPSINPUT.RTG_PROCESSES) |
|
SEQ_NUM |
Sequence number of step in route (* inherited from FPSINPUT.RTG_ROUTE_STEPS) |
|
OPERATION |
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. (* inherited from FPSINPUT.RTG_OPERATIONS) |
|
PROCESS_MODULE |
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. (* inherited from FPSBASE.RTG_ROUTE_STEPS_PLUS) |
|
PROCESS_FAMILY |
See https://help.inficonims.com/display/DW/Guide+to+Process+Families. (* inherited from FPSINPUT.RTG_PROCESS_FAMILIES) |
|
PROCESS_GROUP |
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. (* inherited from FPSINPUT.RTG_PROCESS_GROUPS) |
|
PROCESS_CLASS |
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. (* inherited from FPSINPUT.RTG_PROCESS_GROUPS) |
|
SCHED_GROUP |
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. (* inherited from FPSINPUT.RTG_PROCESS_GROUPS) |
|
GP_SUBFAMILY |
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. (* inherited from FPSBASE.WIP_END_SHIFT_HIST) |
|
ROUTE_FAMILY |
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. (* inherited from FPSINPUT.RTG_ROUTE_FAMILIES) |
|
ROUTE_GROUP |
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. (* inherited from FPSINPUT.RTG_ROUTE_GROUPS) |
|
ROUTE_SECTION |
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. (* inherited from FPSINPUT.RTG_ROUTE_STEPS) |
|
ROUTE_SEGMENT |
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. (* inherited from FPSINPUT.RTG_ROUTE_STEPS) |
|
PHOTO_LAYER |
The photo layer the step belongs to. (* inherited from FPSINPUT.RTG_ROUTE_STEPS) |
|
ROUTE_SEGMENT_SORT |
|
|
SAMPLE_RATIO |
|
|
PROC_SEC |
|
|
POSTP_SEC |
|
|
STEP_CT_DAYS_TO_EOL |
|
|
STEP_TCT_DAYS_TO_EOL |
|
|
TCT_SEC |
Theoretical cycle time in seconds (* inherited from FPSBASE.WIP_LOT_HIST) |
|
DRUM_QTY_RT_STEP |
|
|
WIP_QTY_RT_STEP |
|
|
WIP_QTY_COMSTEP_RT_FAM |
|
|
WIP_QTY_COMSTEP_RT_GRP |
|
|
WIP_QTY_COMSTEP |
|
|
WIP_QTY_PROCESS_RT_FAM |
|
|
WIP_QTY_PROCESS_RT_GRP |
|
|
WIP_QTY_PROCESS |
|
|
WIP_QTY_PROCFAM_RT_FAM |
|
|
WIP_QTY_PROCFAM_RT_GRP |
|
|
WIP_QTY_PROCFAM |
|
|
WIP_QTY_PHOTO_LAYER_RT_GRP |
|
|
WIP_QTY_PHOTO_LAYER |
|
|
WIP_QTY_OPERATION_RT_GRP |
|
|
WIP_QTY_OPERATION |
|
|
WIP_QTY_ROUTE_SEG_RT_GRP |
|
|
WIP_QTY_ROUTE_SEG |
|
|
TARGET_WIP_QTY_RT_STEP |
|
|
TARGET_WIP_QTY_COMSTEP_RF |
|
|
TARGET_WIP_QTY_COMSTEP_RG |
|
|
TARGET_WIP_QTY_COMSTEP |
|
|
TARGET_WIP_QTY_PROCESS_RF |
|
|
TARGET_WIP_QTY_PROCESS_RG |
|
|
TARGET_WIP_QTY_PROCESS |
|
|
TARGET_WIP_QTY_PROCFAM_RF |
|
|
TARGET_WIP_QTY_PROCFAM_RG |
|
|
TARGET_WIP_QTY_PROCFAM |
|
|
TARGET_WIP_QTY_PHOTO_LAYER_RG |
|
|
TARGET_WIP_QTY_PHOTO_LAYER |
|
|
TARGET_WIP_QTY_OPERATION_RG |
|
|
TARGET_WIP_QTY_OPERATION |
|
|
TARGET_WIP_QTY_ROUTE_SEG_RG |
|
|
TARGET_WIP_QTY_ROUTE_SEG |
|
|
LB_HORIZON_DAYS |
Line Balance horizon in days of cycle time. Controls how far downstream from each step, expressed in days of cycle time, the line balance calculation includes. This is treated as an OR condition in conjunction with LBR_HORIZON_NUM_STEPS. (* inherited from FPSAPP.GP_C_FACILITY) |
|
LB_FUT_WIP_DELTA_CALC_TYPE |
Determines how future step WIP deltas are aggregated. Options are "SUM" and "WAVG". SUM means the straight sum is taken of the future step WIP deltas. WAVG means the weighted average of the future step WIP deltas is used. (* inherited from FPSAPP.GP_C_FACILITY) |
|
LB_WIP_DELTA_RATIO_CURR |
|
|
LB_WIP_DELTA_RATIO_FUT |
|
|
F_STEP |
|
|
F_COMMON_STEP |
|
|
F_PROCESS |
|
|
F_SEQ_NUM |
|
|
F_ROUTE_SEGMENT_SORT |
|
|
F_WIP_QTY_RT_STEP |
|
|
F_WIP_QTY_COMSTEP_RT_FAM |
|
|
F_WIP_QTY_COMSTEP_RT_GRP |
|
|
F_WIP_QTY_COMSTEP |
|
|
F_WIP_QTY_PROCESS_RT_FAM |
|
|
F_WIP_QTY_PROCESS_RT_GRP |
|
|
F_WIP_QTY_PROCESS |
|
|
F_WIP_QTY_PROCFAM_RT_FAM |
|
|
F_WIP_QTY_PROCFAM_RT_GRP |
|
|
F_WIP_QTY_PROCFAM |
|
|
F_WIP_QTY_PHOTO_LAYER_RT_FAM |
|
|
F_WIP_QTY_PHOTO_LAYER_RT_GRP |
|
|
F_WIP_QTY_PHOTO_LAYER |
|
|
F_WIP_QTY_OPERATION_RT_FAM |
|
|
F_WIP_QTY_OPERATION_RT_GRP |
|
|
F_WIP_QTY_OPERATION |
|
|
F_WIP_QTY_ROUTE_SEG_RT_FAM |
|
|
F_WIP_QTY_ROUTE_SEG_RT_GRP |
|
|
F_WIP_QTY_ROUTE_SEG |
|
|
F_TARGET_WIP_QTY_RT_STEP |
|
|
F_TARGET_WIP_QTY_COMSTEP_RF |
|
|
F_TARGET_WIP_QTY_COMSTEP_RG |
|
|
F_TARGET_WIP_QTY_COMSTEP |
|
|
F_TARGET_WIP_QTY_PROCESS_RF |
|
|
F_TARGET_WIP_QTY_PROCESS_RG |
|
|
F_TARGET_WIP_QTY_PROCESS |
|
|
F_TARGET_WIP_QTY_PROCFAM_RF |
|
|
F_TARGET_WIP_QTY_PROCFAM_RG |
|
|
F_TARGET_WIP_QTY_PROCFAM |
|
|
F_TARGET_WIP_QTY_PHOTO_LY_RF |
|
|
F_TARGET_WIP_QTY_PHOTO_LY_RG |
|
|
F_TARGET_WIP_QTY_PHOTO_LAYER |
|
|
F_TARGET_WIP_QTY_OPERATION_RF |
|
|
F_TARGET_WIP_QTY_OPERATION_RG |
|
|
F_TARGET_WIP_QTY_OPERATION |
|
|
F_TARGET_WIP_QTY_ROUTE_SEG_RF |
|
|
F_TARGET_WIP_QTY_ROUTE_SEG_RG |
|
|
F_TARGET_WIP_QTY_ROUTE_SEG |
|
|
F_SAMPLE_RATIO |
|
|
MAX_CURR_QTY_DELTA |
|
|
MIN_CURR_QTY_DELTA |
|
|
MAX_FUTURE_QTY_DELTA |