FPSINPUT.WIP_EVENT_ERROR_HIST

ACTUAL_CH_USED

VARCHAR2(24)

Here is where we can log the actual_ch_used directly if we know it. We have three ways to determine actual_ch_used in WIP_LOTS_REALTIME which populates WIP_STEP_HIST: 1) Log it directly in this colum for an event where the logged_entity is the main tool. 2) Log events to each of the chambers used in WIP_EVENT_HIST. 3) Log events to each of the chambers used in WIP_WAFER_HIST. (* from FPSINPUT.WIP_EVENT_HIST)

ACTUAL_DURABLE_USED

VARCHAR2(129)

Actual durable used as logged by the tool during processing of the lot. This can be a comma delimited string if multiple durables are used. (* from FPSINPUT.WIP_EVENT_HIST)

ACTUAL_MACHINE_RECIPE

VARCHAR2(100)

Machine recipe used to process the lot as logged during processing by the tool. (* from FPSINPUT.WIP_EVENT_HIST)

BANK

VARCHAR2(36)

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)

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

CURR_PRIORITY

VARCHAR2(7)

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)

EVENT

VARCHAR2(48)

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

EVENT_COMMENT

VARCHAR2(512)

Comment associated with the event. (* from FPSINPUT.WIP_HOLD_FUTURE)

EVENT_INST1

DATE

User-defined field which can store any instant relevant to the event. Description of use should be noted in WIP_EVENTS table. (* from FPSINPUT.WIP_EVENT_HIST)

EVENT_INST2

DATE

User-defined field which can store any instant relevant to the event. Description of use should be noted in WIP_EVENTS table. (* from FPSINPUT.WIP_EVENT_HIST)

EVENT_INST3

DATE

User-defined field which can store any instant relevant to the event. Description of use should be noted in WIP_EVENTS table. (* from FPSINPUT.WIP_EVENT_HIST)

EVENT_NUM1

NUMBER(10)

User-defined field which can store any number relevant to the event. Description of use should be noted in WIP_EVENTS table. (* from FPSINPUT.WIP_EVENT_HIST)

EVENT_NUM2

NUMBER(10)

User-defined field which can store any number relevant to the event. Description of use should be noted in WIP_EVENTS table. (* from FPSINPUT.WIP_EVENT_HIST)

EVENT_NUM3

NUMBER(10)

User-defined field which can store any number relevant to the event. Description of use should be noted in WIP_EVENTS table. (* from FPSINPUT.WIP_EVENT_HIST)

EVENT_PARM1

VARCHAR2(128)

User-defined parameter which can store any value relevant to the event. Description of use should be noted in WIP_EVENTS table. (* from FPSINPUT.WIP_EVENT_HIST)

EVENT_PARM2

VARCHAR2(128)

User-defined parameter which can store any value relevant to the event. Description of use should be noted in WIP_EVENTS table. (* from FPSINPUT.WIP_EVENT_HIST)

EVENT_PARM3

VARCHAR2(128)

User-defined parameter which can store any value relevant to the event. Description of use should be noted in WIP_EVENTS table. (* from FPSINPUT.WIP_EVENT_HIST)

EVENT_PARM4

VARCHAR2(128)

User-defined parameter which can store any value relevant to the event. Description of use should be noted in WIP_EVENTS table. (* from FPSINPUT.WIP_EVENT_HIST)

EVENT_PARM5

VARCHAR2(128)

User-defined parameter which can store any value relevant to the event. Description of use should be noted in WIP_EVENTS table. (* from FPSINPUT.WIP_EVENT_HIST)

FACILITY

VARCHAR2(6)

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)

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_TYPE

VARCHAR2(24)

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

INSERTED_TIME

TIMESTAMP(6)

N

Timestamp field set by trigger storing SYSTIMESTAMP when record was inserted in the table. (* from FPSINPUT.WIP_EVENT_HIST)

INST

DATE

Time when the event occurred. (* from FPSINPUT.WIP_EVENT_HIST)

IS_HOLD

CHAR(1)

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_HOLD_END

CHAR(1)

Event ended hold (* from FPSINPUT.WIP_EVENT_HIST)

IS_HOLD_START

CHAR(1)

Event started hold (* from FPSINPUT.WIP_EVENT_HIST)

IS_REWORK

CHAR(1)

Y indicates the lot is on a rework route after the event is logged. If a lot is reworked then returns to the main route and repeats some steps, is_rework will be N but we will count those steps as repeats. (* from FPSINPUT.WIP_EVENT_HIST)

IS_REWORK_END

CHAR(1)

Event ended rework (* from FPSINPUT.WIP_EVENT_HIST)

IS_REWORK_START

CHAR(1)

Event started rework (* from FPSINPUT.WIP_EVENT_HIST)

IS_SCRAP_EVENT

CHAR(1)

If the event results in any number of units in the lot to be scrapped then this field is set to Y. It is common to have scrap occur not only from a scrap event but also from a move event where the lot loses some but not all units. Therefore we cannot just look at scrap events and this flag tells what to count as scrap for this particular facility. (* from FPSINPUT.WIP_EVENT_HIST)

IS_SHIP_EVENT

CHAR(1)

This flag tells us what to count as a ship for a particular facility. Related to the ship event is the finish event which is the last event for a facility-prd which either changes facility or changes prd or terminates the lot by changing the qty to 0 without merging. Often the ship event is the same event as the finish event. But when the ship event is different and logged prior to the finish event, we write a record to CTM_FINISHED_LOT_HIST when the ship event is logged with finish_inst blank. This record is include in Dashboard Ships Summary but not in Finished Lot Cycle Time. Then later when the lot finishes, we update the record keeping the ship_inst and populating the finish_inst so it is then including in Finished Lot Cycle Time. Technically this "insert at ship then update at finish" process is the same regardless of how far the ship is before the finish but it is most critical when the the ship is quite some time before the finish, for example, when wafer test is part of the same route but we want to count the ship when the lot finishes the fab steps. (* from FPSINPUT.WIP_EVENT_HIST)

LOGGED_ENTITY

VARCHAR2(36)

Entity to which event is logged in the MES. This could be a main tool, subtool, entity, or port. In MNT tables this could be a vehicle or durable as well which is why the column width is wider. If main tool or port, we apply the event to all entities. If subtool we apply to all within the subtool. If entity we apply only to the entity. (* from FPSINPUT.EQP_EVENT_HIST)

LOGICAL_RECIPE

VARCHAR2(100)

Used for infomational purpose and is populated if known otherwise it will match the recipe. (* from FPSINPUT.WIP_EVENT_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)

LOT_SEQ_WITHIN_SEC

NUMBER(2)

For rows with identical timestamps, sequence records to get proper sequence (* from FPSINPUT.WIP_EVENT_HIST)

LOT_TYPE

VARCHAR2(24)

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)

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)

MAIN_RT_STEP

VARCHAR2(256)

When lot is on a rework or alternate route, this is the step where it will return to the main route. We use this for planning purposes so we can calculate remaining steps. We allow this column to be null in WIP_LOTS_VERIFY because we may not be certain what the main route step 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)

MEAS_RESULT

VARCHAR2(1)

Result of measurement. For facilities not using FPS Sampling this value is for display purposes only and can be pass/fail or a number or anything. For facilities using FPS Sampling this field is used to dynamically adjust the sampling rules and must be a letter grade A-F. (* from FPSINPUT.WIP_EVENT_HIST)

MERGE_INTO_PRD

VARCHAR2(64)

This is the prd of the lot into which this lot is merged if that prd is different than the prd of this lot. Typically this is an assembly step. This is important to track the prd flow from individual components into the final shipped prd. (* from FPSINPUT.WIP_EVENT_HIST)

MERGE_LOT_LIST

VARCHAR2(512)

Lot (or list of lots) merged with this lot by this merge event. A value here indicates this was a merge event. (* from FPSINPUT.WIP_EVENT_HIST)

NEXT_BANK

VARCHAR2(36)

Event moved the lot to this new bank (* from FPSINPUT.WIP_EVENT_HIST)

NEXT_FACILITY

VARCHAR2(6)

Event moved the lot to this new facility (* from FPSINPUT.WIP_EVENT_HIST)

NEXT_MAIN_ROUTE

VARCHAR2(256)

Event moved the lot to this new main route (* from FPSINPUT.WIP_EVENT_HIST)

NEXT_MAIN_RT_STEP

VARCHAR2(256)

Event moved the lot to this new step on the main route (* from FPSINPUT.WIP_EVENT_HIST)

NEXT_PLANPRD

VARCHAR2(64)

If this event results in the planprd of the lot changing the new value is stored here. (* from FPSINPUT.WIP_EVENT_HIST)

NEXT_PRD

VARCHAR2(64)

Event moved the lot to this new prd (* from FPSINPUT.WIP_EVENT_HIST)

NEXT_ROUTE

VARCHAR2(256)

Event moved the lot to this new route (* from FPSINPUT.WIP_EVENT_HIST)

NEXT_STEP

VARCHAR2(256)

Event moved the lot to this new step (* from FPSINPUT.WIP_EVENT_HIST)

OPERATOR

VARCHAR2(64)

In history tables, this is the username of the person or system who logged the event. In EQP_MNT_FUTURE, this is the username of the person who input the information about the maintenance event. Usernames can be looked up in GEN_USERS to get full names, email address, etc. Please note that the existence of each username in GEN_USERS is optional, meaning that it is never required for the username logged in the operator column to be in GEN_USERS. (* from FPSINPUT.WIP_EVENT_HIST)

OPT_SORT_WITHIN_SEC

NUMBER(21,6)

This number is the order of the event within the same second for the same lot (WEH) or wafer (WWH) or entity (EEH). If the event is logged with a sequence number then this value should be that sequence number (and it is fine if this is an overall sequence number even though it only matters compared to other events in the same second). Otherwise if the event time includes milliseconds then this can be the milliseconds. Otherwise just choose the best sort order. This value does not need to be 1, 2, 3, etc. (* from FPSINPUT.WIP_EVENT_HIST)

OVR_JOB_ID

VARCHAR2(64)

Allows us to specify the job_id in the ETL if the MES already provides this. In the normal case when this value is not populated, the standard logic to define job_id based on events is used. (* from FPSINPUT.WIP_EVENT_HIST)

PLANPRD

VARCHAR2(64)

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)

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

PORT

VARCHAR2(5)

Port is the short name of the port on the tool like P1 or LLA. This field is unique within the given tool and is used to save space when we already know the tool, for example in the dashboard tool hover where we show the status of each port. This column is in contrast to the location field which is the full name of the port. Location is unique within the entire facility and almost always includes the tool name like ET99P1 or ET99LLA. In addition, location is usually available from the MES or AMHS as this must be an exact match with the location in MHS_CARRIERS if this gets set when a carrier is placed on the port. On the other hand, the shorter port column is often not available in the MES so we either populate manually or with some complex if-then logic in the ETL based on the naming standards. (* from FPSINPUT.EQP_PORTS)

PORT_MODE

VARCHAR2(24)

PORT_MODE is the port equivalent to EQP_STATE. Examples might be AUTOMATIC, MANUAL, SEMI-AUTOMATIC, or DOWN. If configured in GEN_FACILITIES, the view DASH_P_TOOL_PORTS can overlay whether the port is occupied along with its carrier and the WIP processing states over the port modes as long as the port mode has is_up set to Y. Therefore it is not necessary to reflect occupied or empty when developing the ETL logic to populate the EQP_PORTS table. (* from FPSINPUT.EQP_PORT_MODES)

PRD

VARCHAR2(64)

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)

QTY

NUMBER(7)

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)

QTY_DELTA

NUMBER(7)

Difference in number of wafers due to an event that changes lot quantity (* from FPSINPUT.WIP_EVENT_HIST)

QTY_MEAS

NUMBER(7)

Quantity of units measured at this metrology step. This is less than or equal to the qty_in_job. The standard case is where we have a 25 wafer lot so the qty_in_job is 25 but we only measure 3 wafers on the metrology tool so qty_meas is 3. (* from FPSINPUT.WIP_EVENT_HIST)

RECIPE_VERSION

VARCHAR2(12)

This field is for historical tracking purposes only and is not used in any FPS calculation. (* from FPSINPUT.WIP_EVENT_HIST)

RN_DESC_OF_STEP_MOVES

NUMBER(3)

If a lot moves through multiple steps within one loop of the WIP_EVENT_HIST load then there is no reason to call UPDATE_WIP_STEP_FUTURE for each step. If WIP_APD_EVENT_HIST includes more than one step move for a lot then we can skip the call to UPDATE_WIP_STEP_FUTURE for all but the last move. This column is automatically populated in the ADM_LOAD_EVENT_HIST_VIA_APD procedure. Then in the triggers, we skip the call to UPDATE_WIP_STEP_FUTURE if the value is greater than 1. (* from FPSINPUT.WIP_EVENT_HIST)

ROUTE

VARCHAR2(256)

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

SCRAP_CATEGORY

VARCHAR2(64)

A optional categorization field for scrap events which can be defined for the facility. (* from FPSINPUT.WIP_EVENT_HIST)

SCRAP_MODULE

VARCHAR2(12)

Responsible module for the scrap event. (* from FPSINPUT.WIP_EVENT_HIST)

SCRAP_OWNER

VARCHAR2(48)

Engineer responsible for analyzing and recording this scrap event. (* from FPSINPUT.WIP_EVENT_HIST)

SEC_QTY

NUMBER(7)

Quantity of units in the lot according the sec_qty_unit defined for the facility. See the column comment for the qty column for details and examples. (* from FPSINPUT.WIP_EVENT_HIST)

SEC_QTY_DELTA

NUMBER(7)

Difference in number of die due to an event that changes lot quantity (* from FPSINPUT.WIP_EVENT_HIST)

SPLIT_LOT_LIST

VARCHAR2(512)

Lot (or list of lots) split along with this lot by this merge event. A value here indicates this was a split event. (* from FPSINPUT.WIP_EVENT_HIST)

STEP

VARCHAR2(256)

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)