FPSINPUT.DASH_B_H_ETP_7D

FACILITY

VARCHAR2(6)

N

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. (* from FPSINPUT.GEN_FACILITIES)

TOOL

VARCHAR2(16)

N

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. (* from FPSINPUT.EQP_TOOLS)

ENTITY

VARCHAR2(19)

N

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. (* from FPSINPUT.EQP_STATUS_VERIFY)

FROM_INST

DATE

N

Time from which this state was active. (* from FPSINPUT.GEN_FACILITY_SHUTDOWNS)

TO_INST

DATE

N

Time to which this state was active. (* from FPSINPUT.GEN_FACILITY_SHUTDOWNS)

BEG_PROC_CH_USED

VARCHAR2(24)

BEG_PROC_INST

DATE

time when the lot started processing on the main tool. (* from FPSINPUT.WIP_STEP_HIST_MANUAL)

BEG_PROC_JOB_ID

VARCHAR2(64)

BEG_PROC_PROCESS

VARCHAR2(50)

BEG_PROC_RECIPE

VARCHAR2(100)

BEG_PROC_RQD_SETUP

VARCHAR2(100)

CH_PROC_STATE

VARCHAR2(25)

DASH_INSERTED_TIME

TIMESTAMP(6)

E10_STATE

VARCHAR2(3)

N

EQP_OR_ETP_STATE

VARCHAR2(48)

N

EQP_STATE_CHG_INST_FOR_ETP

DATE

EQP_STATE_FOR_ETP

VARCHAR2(25)

GANTT_FROM_INST

DATE

HIST_INSERTED_TIME

TIMESTAMP(6)

N

Unlike just about every other history table, ETP_HIST does not have a single column that represents the inst associated with the record. For example, WIP_EVENT_HIST has inst, WIP_END_SHIFT_HIST has start_shift, THP_EQPTYPE_WEEK_HIST has start_week, and so on. These columns are consistent with the data in the entire table and sorting by them gives you a consistent order of the records in the table. When a record is inserted into ETP_HIST, it might be because of an EQP state change in which case eqp_to_inst would be the inst of the event that triggered the state change. But etp_to_inst would still be the old value. And vice versa for ETP state changes. Furthermore while usually either eqp_to_inst or etp_to_inst is relevant, we also insert records when the standby state changes without a EQP/ETP state change and in these cases sby_inst is relevant but both eqp_to_inst and etp_to_inst are old values. And the worst case is when the only change is a standby state of any entity on the tool which actually has no relevant inst. The only column which is always relevant is hist_inserted_time so we have no choice but to use this column as the purge_column_name in CFG_TABLES. By the nature of the logic, hist_inserted_time is always newer than all of the other inst values so we will never purge too many records. If the data is behind or loaded for a past period then we will purge too little but that is acceptable. (* from FPSBASE.ETP_HIST)

INC_BATCH_PCT

NUMBER(3)

Percentage of the full batch size processed. For tool performance calculations, TOOL_PCT percentage productivity is calculated using INC_BATCH_PCT to factor in that the batch size is not fully utilized. (* from FPSBASE.WIP_LOT_HIST)

IS_NST_HIDDEN_ON_HIST

CHAR(1)

N

If yes then do not include time in this NST state in the history. Most NST states should be Y unless there is a specific reason why the client wants it to be part of the total. An example calculation here is if a tool is PRD for 1 day, SBY for 1 day, SDT for 1 day, UDT for 1 day, and NST for 3 days then the totals for the week are 25% each for PRD, SBY, UDT, SBY because the NST is ignored. (* from FPSINPUT.EQP_L5_TRANSITION_STATES)

L6_STATE_BG_COLOR

VARCHAR2(24)

N

L6_STATE_BG_COLOR_CH

VARCHAR2(24)

N

MISS_CASC_INST

DATE

Time when the last cascade was missed or the current cascade will be missed. (* from FPSBASE.ETP_STATUS)

OPPORTUNITY_STATE_BG_COLOR

VARCHAR2(24)

N

OPPORTUNITY_STATE_BG_COLOR_CH

VARCHAR2(24)

N

OPPORTUNITY_STATE_DISPLAY

VARCHAR2(48)

N

OPPORTUNITY_STATE_DISPLAY_CH

VARCHAR2(48)

N

OVERALL_SORT_ORDER

NUMBER(3)

N

OVERALL_SORT_ORDER_CH

NUMBER(3)

N

PROC_STATE

VARCHAR2(25)

Current processing state of each entity. Updated by a trigger on WIP_EVENT_HIST. (* from FPSBASE.ETP_STATUS)

STATE_CHG_COMMENT

VARCHAR2(512)

STATE_CHG_EVENT

VARCHAR2(48)

N

STATE_CHG_INST

DATE

N

Time when the eqp_state changed for the entity. (* from FPSINPUT.EQP_STATUS_VERIFY)

STATE_DISPLAY

VARCHAR2(48)

N

STATE_DISPLAY_CH

VARCHAR2(48)

N

TOOL_PCT

NUMBER(7,4)

N