FPSBASE.ECTA_B_STANDALONE_BASE

Data Dictionary

FPSBASE Views

> FPSBASE.WIP_WAFER_HIST_LOOP

View FPSAPP.ECTA_B_STANDALONE_BASE

NOTE: This was our original and likely future ECTA_REF_P_BASE view but we decided to use CTM_SUMMARY -> CTA_P_BASE for all of our fill-in logic in the first round of ECT. This view is how we would build everything from scratch if we want to completely replace CTM_SUMMARY with the logic coming from ECT_HIST. This current version is also quite slow at some sites so it will have to be sped up to use in production. We will also need to improve the fill-in logic as well as add the commit/target logic similar to CTM_SUMMARY. This table stores the base table for all non-trend Cycle Time Analyzer data using the ECT logic. Here we get all of the steps for routes where we have data for at least one step and use some rudimentary fill-in logic. This logic does not use CTM_SUMMARY (except for a few random columns) but it does not replace CTM_SUMMARY, at least not yet. This logic only does the minimum necessary to feed the CTA. If we are going to continue down the path of replacing CTM_SUMMARY with ECT logic there are a bunch of things that we must do but first and foremost would be better fill-in logic. The fill-in logic in this view is terrible but it gives some result and the first place we want to focus is the high runners and this allows us to do that. Please note that the ECTA queries must filter module, process family, and process at the very end in order to weight properly by route. This means that there is no reason to have indexes on any of these columns.

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)
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)
ROUTE	Route that has threading requirements (* inherited from FPSINPUT.RTG_STEP_THREADING)
BANK	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. (* inherited from FPSINPUT.RTG_BANKS)
PRTY_CTM_GROUP	This is one of the primary keys of our CTM tables. We use this group rather than the priority because we often have several different priorities which are close and are expected to have the same cycle time. (* inherited from FPSINPUT.WIP_PRIORITIES)
LOT_GROUP	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. (* inherited from FPSINPUT.WIP_LOT_GROUPS)
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)
QTY_COMP_FULL
QTY_MOVED_FULL
NUM_LOTS_MOVED_FULL
PROC_STATE_AVG_WIP_FULL
WHY_PROC_FULL
WHY_OTHERS_FULL
WHY_SKIP_BANK_FULL
ABORT_SEC_FULL_WAVG
BLOCK_SEC_FULL_WAVG
DISP_SEC_FULL_WAVG
DOWN_SEC_FULL_WAVG
ENDED_SEC_FULL_WAVG
HOLD_SEC_FULL_WAVG
LONGH_SEC_FULL_WAVG
PROC_SEC_FULL_WAVG
RESRV_SEC_FULL_WAVG
SHUTD_SEC_FULL_WAVG
STG_SEC_FULL_WAVG
WAIT1_SEC_FULL_WAVG
WAIT2_SEC_FULL_WAVG
WAIT3_SEC_FULL_WAVG
QTY_COMP_LONG
QTY_MOVED_LONG
NUM_LOTS_MOVED_LONG
PROC_STATE_AVG_WIP_LONG
WHY_PROC_LONG
WHY_OTHERS_LONG
WHY_SKIP_BANK_LONG
ABORT_SEC_LONG_WAVG
BLOCK_SEC_LONG_WAVG
DISP_SEC_LONG_WAVG
DOWN_SEC_LONG_WAVG
ENDED_SEC_LONG_WAVG
HOLD_SEC_LONG_WAVG
LONGH_SEC_LONG_WAVG
PROC_SEC_LONG_WAVG
RESRV_SEC_LONG_WAVG
SHUTD_SEC_LONG_WAVG
STG_SEC_LONG_WAVG
WAIT1_SEC_LONG_WAVG
WAIT2_SEC_LONG_WAVG
WAIT3_SEC_LONG_WAVG
QTY_COMP_7D
QTY_MOVED_7D
NUM_LOTS_MOVED_7D
PROC_STATE_AVG_WIP_7D
WHY_PROC_7D
WHY_OTHERS_7D
WHY_SKIP_BANK_7D
ABORT_SEC_7D_WAVG
BLOCK_SEC_7D_WAVG
DISP_SEC_7D_WAVG
DOWN_SEC_7D_WAVG
ENDED_SEC_7D_WAVG
HOLD_SEC_7D_WAVG
LONGH_SEC_7D_WAVG
PROC_SEC_7D_WAVG
RESRV_SEC_7D_WAVG
SHUTD_SEC_7D_WAVG
STG_SEC_7D_WAVG
WAIT1_SEC_7D_WAVG
WAIT2_SEC_7D_WAVG
WAIT3_SEC_7D_WAVG
QTY_COMP_2D
QTY_MOVED_2D
NUM_LOTS_MOVED_2D
PROC_STATE_AVG_WIP_2D
WHY_PROC_2D
WHY_OTHERS_2D
WHY_SKIP_BANK_2D
ABORT_SEC_2D_WAVG
BLOCK_SEC_2D_WAVG
DISP_SEC_2D_WAVG
DOWN_SEC_2D_WAVG
ENDED_SEC_2D_WAVG
HOLD_SEC_2D_WAVG
LONGH_SEC_2D_WAVG
PROC_SEC_2D_WAVG
RESRV_SEC_2D_WAVG
SHUTD_SEC_2D_WAVG
STG_SEC_2D_WAVG
WAIT1_SEC_2D_WAVG
WAIT2_SEC_2D_WAVG
WAIT3_SEC_2D_WAVG
TARGET_CT
COMMIT_CT
EST_TRANSIT_SEC
ESTIMATED