FPSAPP.STD_WIP_REF_GOALS_PER_SHIFT

Data Dictionary

FPSAPP Views

> FPSAPP.WIP_WAFER_HIST_LOOP

View FPSINPUT.STD_WIP_REF_GOALS_PER_SHIFT

There are so many ways that you can set goals that we just let each site write their own logic. But here is some very simple logic to get started at a new site. This logic just sets goals based on what happened over the last seven days. It is verified to generate goals for completes which are 5% higher than your average completes per shift over the last seven days. If nothing else this makes the Dashboard fillup bars look reasonable immediately. We expect that you will replace this with your own goals logic, however, there are sections in this STD view which will likely be useful, including: --Converting completes to moves using smp_rate --Converting moves to WIP using cycle time --Dividing lot_group and prty_ctm_group into lot_type and plan_priority If you really want to use this exactly as is for startup then you can do this: CREATE VIEW FPSINPUT.WIP_REF_GOALS_PER_SHIFT AS SELECT (slash+asterisk) Using STD view for startup History: No history needed when using STD view (asterisk+slash) START_SHIFT, FACILITY, ROUTE, STEP, PRD, PLANPRD, LOT_TYPE, PLAN_PRIORITY, IS_NONSTD, GOAL_MOVES, GOAL_COMPLETES, GOAL_WIP, GOAL_OPER_MOVES FROM STD_WIP_REF_GOALS_PER_SHIFT;

Column	Comment
START_SHIFT	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. (* inherited from FPSINPUT.CAL_SHIFTS)
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)
PRD	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. (* inherited from FPSINPUT.RTG_PRDS)
PLANPRD	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. (* inherited from FPSINPUT.RTG_PLANPRDS)
LOT_TYPE	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. (* inherited from FPSINPUT.WIP_LOT_TYPES)
PLAN_PRIORITY	Permanent priority of the lot set in the MES generally by planning. (* inherited from FPSINPUT.WIP_EVENT_HIST)
IS_NONSTD	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. (* inherited from FPSBASE.WIP_LOT_HIST)
GOAL_MOVES	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. (* inherited from FPSINPUT.WIP_GOALS_PER_SHIFT)
GOAL_COMPLETES	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. (* inherited from FPSINPUT.WIP_GOALS_PER_SHIFT)
GOAL_WIP	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). (* inherited from FPSINPUT.WIP_GOALS_PER_SHIFT)
GOAL_OPER_MOVES	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. (* inherited from FPSINPUT.WIP_GOALS_PER_SHIFT)