FPSBASE.ECT_HIST

LOT

VARCHAR2(32)

A lot is a group of units that process together. Usually lot_id or lot_number in MES. All units in a lot are in the same carrier but there may be multiple lots in a carrier. (* from FPSINPUT.WIP_LOTS_STATIC)

ECT_FROM_INST

DATE

ECT_HIST_SEQ_WITHIN_SEC

NUMBER(4)

ALLOWED_TOOL_LIST

VARCHAR2(512)

BANK

VARCHAR2(36)

N

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

CARRIER

VARCHAR2(32)

N

RFID of the cassette or FOUP the lot is currently in. (* from FPSINPUT.MHS_CARRIERS)

CURR_PRIORITY

VARCHAR2(7)

N

The priority at the current step. As the lot moves along the route after LAST_STEP_CURR_PRTY it will revert to PLAN_PRIORITY. For example, timelink or sendahead priority is only temporary. (* from FPSINPUT.WIP_LOTS_STATIC)

ECT_STATE

VARCHAR2(42)

N

ECT state is the lowest level state of our Enhanced Cycle Time hierarchy and the value which is stored in WIP_LOTS_REALTIME and ECT_HIST. We can lookup all information about the ECT state including process state in ECT_STATE_DIAGRAM. (* from FPSADMIN.WIP_ECT_STATES)

ECT_STATE_CHG_EVENT

VARCHAR2(48)

N

ECT_STATE_CHG_EVENT_TYPE

VARCHAR2(12)

N

ECT_STATE_CHG_INST

DATE

N

ECT_STATE_IF_WAIT

VARCHAR2(12)

N

ECT_TO_INST

DATE

See comments on WIP_LOT_HIST.NEXT_INST.

ECT_TO_INST_NOT_NULL

DATE

See column comments for WIP_LOT_HIST.NEXT_INST.

ECT_UPDATED_BY

VARCHAR2(30)

N

ECT_UPDATED_COMMENT

VARCHAR2(512)

ECT_UPDATED_TIME

TIMESTAMP(6)

N

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)

FAC_SHUTD_PCT

NUMBER(3)

FAC_SHUTD_PCT_CHG_INST

DATE

HIST_INSERTED_TIME

TIMESTAMP(6)

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)

HOLD_FOR

VARCHAR2(48)

The user responsible for the hold lot. Note this is different than the user who put the lot on hold. This is the person who needs to address the hold and potentially release it. (* from FPSINPUT.WIP_EVENT_HIST)

HOLD_GROUP

VARCHAR2(36)

Grouping of hold_type for reporting purposes. (* from FPSINPUT.WIP_HOLD_GROUPS)

HOLD_NOTE

VARCHAR2(512)

Comment or note entered when the lot went on hold. Normally this should match the comment which was entered in the hold event. The logic to determine the hold note can get tricky when a subsequent comment event is logged to a lot already on hold because we do not know whether to update the hold note with the new comment or keep the comment from the original event that put the lot on hold. Our solution is to not update the hold_note by trigger with this comment event and leave the decision to our logic in WIP_LOTS_VERIFY. If you want to use the subsequent comment then populate it as the hold_note in WLV otherwise keep the original comment in WLV. Then our logic in CHK_WIP_LOTS_REALTIME is that if the hold_note written in WIP_LOTS_VERIFY differs from the hold_note populated by trigger while the hold_type and hold_for agree then we waive the normal 20 minute waiting period and update the hold_note immediately with a MISS-HOLDNOTE event. (* from FPSINPUT.WIP_LOTS_VERIFY)

HOLD_TYPE

VARCHAR2(24)

Generally hold_type will come directly from the MES. (* from FPSINPUT.WIP_HOLD_TYPES)

IS_CURR_RECORD

CHAR(1)

IS_ECT_STATE_CHG

CHAR(1)

N

IS_FAC_SHUTD_PCT_CHG

CHAR(1)

N

IS_HOLD

CHAR(1)

N

This field indicates the lot is on hold after the event is logged. In other words, this will always be Y if is_hold_start is Y and always N if is_hold_end is Y. (* from FPSINPUT.WIP_EVENT_HIST)

IS_INACTIVE_STEP

CHAR(1)

N

Since we now use RTG_ROUTE_STEPS_INACTIVE table, we should only include the active steps on each route in RTG_ROUTE_STEPS. Therefore this value must be set to N in the RTG_ROUTE_STEPS table but will be set appropriately to Y for inactive steps in the RTG_ROUTE_STEPS_PLUS table. (* from FPSINPUT.RTG_ROUTE_STEPS)

IS_LAST_RECORD_FOR_STEP

CHAR(1)

IS_MHS_STATE_CHG

CHAR(1)

N

IS_NONSTD

CHAR(1)

N

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. (* from FPSBASE.WIP_LOT_HIST)

IS_STAGING_STEP

CHAR(1)

N

We expect large amounts of WIP and long cycle times at staging steps. We still calculate cycle time like any other step but the important difference is that lots currently at a staging step are not counted as normal coming lots to future steps. Instead we show them in a special column labeled From Staging. (* from FPSINPUT.RTG_ROUTE_STEPS)

LOT_TYPE

VARCHAR2(24)

N

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

MAIN_ROUTE

VARCHAR2(256)

N

Primary route used by the prd. Excludes rework and alternate routing. We allow this column to be null in WIP_LOTS_VERIFY because we may not be certain what the main route is when we fix for missed events. In that event we trust the WIP_EVENT_HIST triggers has loaded the correct information into WIP_EVENTS_CURR_STEP. (* from FPSINPUT.WIP_EVENT_HIST)

MHS_STATE

VARCHAR2(29)

MHS_STATE_CHG_INST

DATE

MHS_STATE_CHG_STATION

VARCHAR2(32)

OPERATION

VARCHAR2(50)

Operation is usually the primary level of routing in the MES and the level where the facility typically reports moves. FPS only allows one tool per step so our step is a lower level of routing than operation although both may be the same if the MES only allows one tool per operation. Note that because operation can include multiple steps and therefore multiple process families that we cannot have any association to equipment by operation. (* from FPSINPUT.RTG_OPERATIONS)

PLANPRD

VARCHAR2(64)

N

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

PLAN_PRIORITY

VARCHAR2(7)

N

Permanent priority of the lot set in the MES generally by planning. (* from FPSINPUT.WIP_EVENT_HIST)

PRD

VARCHAR2(64)

N

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

PROCESS

VARCHAR2(50)

Process defines what occurs at a step. Different steps can share the same process if they are identical. Process should normally determine allowed tools and recipe although it can be overridden by step, route, prd, lot, and experiment for exceptions. Each process is dynamically assigned to one or more eqp_type-process_family combinations with use_pct. One process_family is determined to be primary. If grouping is done correctly, a process should only be one eqp_group with no crossover. (* from FPSINPUT.RTG_PROCESSES)

PROCESS_FAMILY

VARCHAR2(50)

See https://help.inficonims.com/display/DW/Guide+to+Process+Families. (* from FPSINPUT.RTG_PROCESS_FAMILIES)

PROCESS_MODULE

VARCHAR2(12)

WIP_MODULE is used to credit moves and set goals. See comments on the module column in GEN_MODULES for info on this column and how it relates to eqp_module and mnt_module. (* from FPSBASE.RTG_ROUTE_STEPS_PLUS)

PROC_STATE_EVENT_ONLY

VARCHAR2(5)

N

The proc_state_event_only column is the process state derived exclusively from lot and wafer events. This is the parent of process_state and it is equal to process_state when the value is ENDED, PROC, PAUSE, ABORT, DISP, and STUCK because these process states come only from events. When the value is HOLD then we look at the hold groups to determine if the process state is HOLD or LONGH. And when the value is WAIT then we look at the complex ect_state_if_wait column to determine if the process state is STG, INHIB, BLOCK, DOWN, WAIT1, WAIT2, or WAIT3. The link between process_state and proc_state_event_only in the ECT diagram is not used in the logic in WIP_LOTS_REALTIME or GET_PROC_STATE_EVENT_ONLY but the values should always match. (* from FPSBASE.WIP_LOTS_REALTIME)

PROC_STATE_EV_ONLY_CHG_INST

DATE

N

QTY

NUMBER(7)

N

Quantity of units in the lot according the qty_unit defined for the facility. It is required for all lots in each facility to have their qty defined in the same units therefore the change in the unit is critical to defining the facility. For example, a pretest facility might have a sort step in the middle where we learn the qty of die. Prior to this step we know only the wafer qty but after this step we know both wafer and die. Since wafer is the only qty we know throughput the flow then wafer must be defined as the qty unit for this facility. Die can then be populated as sec_qty when it is known. Similarly the wafer saw facility might have a step in the middle where we cut the wafers into die. After this step we no longer know the number of wafers which means that die must be the qty unit for this facility and wafers can be the sec_qty prior to the saw step. Please note that a lot with qty of 0 is allowed but only if the sec_qty is greater than 0. This is unusual but one case is where we know the wafers will be scrapped but cannot be scrapped quite yet. (* from FPSINPUT.WIP_EVENT_HIST)

RESERVE_SOURCE

VARCHAR2(5)

RESERVE_TOOL

VARCHAR2(16)

ROUTE

VARCHAR2(256)

N

Route that has threading requirements (* from FPSINPUT.RTG_STEP_THREADING)

RT_STEP_BANK_ENT_INST

DATE

N

If the lot is at a step then this is the time when it entered the current route-step. If the lot is at a bank then this is the time it entered the current bank. (* from FPSBASE.WIP_LOTS_REALTIME)

SCHED_GROUP_BEST_TOOL_IF_OTHER

VARCHAR2(36)

STEP

VARCHAR2(256)

N

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

STEP_ENT_INST

DATE

N

Time when the lot entered the step. (* from FPSBASE.WIP_LOT_HIST)

TCT_SEC

NUMBER(7)

Theoretical cycle time in seconds (* from FPSBASE.WIP_LOT_HIST)