Data Dictionary
>
FPSBASE Views
> FPSBASE.WIP_WAFER_HIST_LOOP
View FPSAPP.SCH_P_BASE_TOOL_EVENTS
the tools sched event. this base view will feed the data to - sch_p_curr_tool_events for scheduler to use - sch_p_tool_events for user to display the list of events
|
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) |
|
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) |
|
TOOL |
Tool is generally just the main tool. The exception is when different entities on the tool run completely independently and it is physically impossible to run wafers of the same lot across multiple entities. In this exception case, we may want to assign the entities to different eqp_types and therefore we should define each entity as a tool. Please note that when we do this there is no indication whatsoever that these different entities are on the same tool. (* inherited from FPSINPUT.EQP_TOOLS) |
|
ENTITY |
The lowest level of the equipment hierarchy that an event can be logged against. Tools, subtools, shared parent tools, chambers, ports are all entities. Load locks are also included although we consider them as ports. (* inherited from FPSINPUT.EQP_STATUS_VERIFY) |
|
CH |
A single character to identify the chamber which must be unique with the tool. We concatenate the CH to get the string for CH_USED so it is helpful for diagnostic purposes if this single character is representative of the chamber (i.e. A for ET12CHA or 1 for MD27C1) because then the CH_USED string makes sense. However it is not required and if the chamber naming is inconsistent we might get use 1, 2, 3, etc. for the CH. (* inherited from FPSINPUT.EQP_CHAMBERS) |
|
CH_TYPE |
This column is critical for sequential chamber tools where a wafer goes through multiple chambers. It identifies the type of chamber so two chambers with the same ch_type are identical and wafers can use either one. See comment on mfg_pct_per_ch column for an example. For independent chamber tools where all chambers are the same and each wafer goes to only one chamber then ch_type should be set to the default value CH so that ch_type_cnt is 1CH, 2CH, 3CH, etc. (* inherited from FPSINPUT.EQP_CHAMBERS) |
|
EVENT_TYPE |
Event Type (* inherited from FPSINPUT.EQP_SCHED_EVENTS_MANUAL) |
|
EVENT_CATEGORY |
to store the event_category, e.g., NOT_TO_SCHEDULE, NOT_TO_START etc. (* inherited from FPSAPP.SCH_W_TOOL_SCHED_EVENTS) |
|
EVENT |
This is the event registered in the MES. This is for the historical record and display only. Each event is mapped to an FPS event_type and the event_type is what is used by FPS applications. (* inherited from FPSINPUT.WIP_EVENTS) |
|
EVENT_DESC |
Event Description (* inherited from FPSINPUT.EQP_SCHED_EVENTS_MANUAL) |
|
SCH_START_INST |
|
|
SCH_END_INST |
|
|
EARLY_DUE_INST |
to store the early due time of the floating PM tool event, i.e., the early start time of the floating PM could be calculated via substracting the EST_DURATION_SEC value (* inherited from FPSAPP.SCH_W_TOOL_SCHED_EVENTS) |
|
LATE_DUE_INST |
to store the late due time of the floating PM tool event, i.e., the late start time of the floating PM could be calculated via substracting the EST_DURATION_SEC value (* inherited from FPSAPP.SCH_W_TOOL_SCHED_EVENTS) |
|
86400 |
|
|
EST_DURATION_SEC |
Estimate of the duration of the future hold if known. If blank we use the estimate for the hold_type. (* inherited from FPSINPUT.WIP_HOLD_FUTURE) |
|
ACTUAL_START_INST |
Time when maintenance was started if it is currently in progress. This should be null for all upcoming events which have not started yet which means that this will be null for the majority of records. (* inherited from FPSINPUT.EQP_MNT_FUTURE) |
|
OTHER_NOTE |
Some description for this scheduler (* inherited from FPSINPUT.RTG_SCHED_GROUPS) |
|
IS_EDITABLE |
|
|
DATA_SOURCE |