Data Dictionary
>
FPSAPP Views
> FPSAPP.WIP_WAFER_HIST_LOOP
View FPSAPP.CTR_REF_B_RRS_FOR_SAME_FAC_SEQ
This view generates a table which is used in CTR_P_WIP_STEP_HIST when the prd is a plus-delimited list from a same_fac_seq. Since CTM_FINISHED_LOT_HIST records the main route of the prd and the main route of the lot, we want to join WIP_STEP_HIST by lot+step and not by main_route. If we added main_route to the join then we would get no data when the main_route of the prd was different than of the lot. However it is normal for a few steps to appear on both routes in the sequence, usually logistics or staging or similar. So we compromise by joining on route_segment which should be different for the two routes in the sequence but should be similar for both the main_route of the prd and of the lot. However occasionally the same combination of route_segment+step occurs on both routes in the same sequence. We would prefer to avoid that and the solution is to modify your ETL for route_segment to add some type of a prefix indicating the type of route in the facility sequence. This will be generic like FOL/EOL or FAB/PROBE or AL/CU or similar so it would also be useful to have this prefix which viewing route_segment. Having said that, if we have duplicates then we pick one here to avoid failing to load. If you make a change to CTM_SUMMARY and want it to reflect here immediately then it takes awhile: exec adm_load_object('CTM_SUMMARY'); exec adm_load_object('CTM_FOR_ROUTE_STEPS'); exec adm_load_object('RTG_ROUTE_STEPS_PLUS'); exec adm_load_object('CTR_B_RRS_FOR_SAME_FAC_SEQ');
|
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) |
|
COMBINED_ROUTE |
|
|
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) |
|
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) |
|
COMMIT_STEP_SEC |
|
|
TARGET_STEP_SEC |
|
|
COMBINED_SEQ_NUM |
|
|
86400 |
|
|
TOTAL_COMMIT_CT_DAYS |
|
|
86400 |
|
|
TOTAL_TARGET_CT_DAYS |
|
|
COMMIT_STEP_SEC_TO_EOL |
|
|
TARGET_STEP_SEC_TO_EOL |
|
|
ORIG_ROUTE |
|
|
ORIG_SEQ_NUM |
|
|
ROUTE_USED_FOR_FILLIN |