data-dictionary

FPSAPP.WIP_EVENTS_CURR_STEP

Data Dictionary

>

FPSAPP Tables

> FPSAPP.WIP_EVENTS_CURR_STEP

Table FPSAPP.WIP_EVENTS_CURR_STEP"

Events at the current step of the lot. Trigger on WIP_EVENT_HIST inserts nonmove events and then deletes all and inserts an enter event for move events. Events in this table are used to build WIP_STEP_HIST and to calculate STEP_ENT_INST.

  • Schema: FPSAPP

  • Tablespace: FPSDATA


Column

Type

Nullable

Comment

INST

DATE

Time when the event occurred. (* 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(6,2)

For rows with identical timestamps, sequence records to get proper sequence (* from FPSINPUT.WIP_EVENT_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)

BATCH_CRITERIA

VARCHAR2(140)

Lots that can run on the same batch TOOL and have the same value of BATCH_CRITERIA can run together in a batch. Therefore this is a critical column for scheduling on batch tools. If BATCH_CRITERIA is not populated, Scheduler defaults to the assumption that any WIP with the same EST_MACHINE_RECIPE can be batched together. Keep in mind that many MESs have additional constraints on batching (for example, that all WIP in a batch has the same SCRIPT_ID) and these must be incorporated into BATCH_CRITERIA to ensure that the batches are allowed by the MES. (* from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

CURR_RANK

VARCHAR2(1)

Current rank is dynamically calculated based on the permanent rank, temporary rank, external rank, and current conditions like tool status and current setup. Cases when it is greater than permanent rank include when the required setup does not match or when APC thread is not qualified. The only way it could be less are when either the temporary rank or external rank are set. Curr_rank is populated in WIP_EVENT_HIST for each event logged to a tool by trigger with the value from WIP_STEP_FUT_ASSIGNMENTS at the time of the event. (* from FPSBASE.WIP_LOT_HIST)

EST_CH_USED

VARCHAR2(24)

Estimate of which chambers will used to process this lot based on assignments and status (* from FPSBASE.WIP_LOT_HIST)

EST_DURABLE_USED

VARCHAR2(129)

This field is populated with our estimate of what durable will be used based on information from the MES and/or Recipe Management System combined with the location and status of each durable. (* from FPSBASE.WIP_LOT_HIST)

EST_MACHINE_RECIPE

VARCHAR2(100)

Estimated machine recipe what we estimate will be the machine recipe based on information from the Recipe Management System. It is used in combination with process for throughput calculations and setup change penalty calculations. It is not necessary to estimate for all processes since this is always used in combination however it needs to be NA rather than blank since it is part of the primary key of most THP tables. Hopefully when this is not NA it should match the actual machine recipe logged for each lot during processing. (* from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

EVENT

VARCHAR2(48)

N

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_TYPE

VARCHAR2(12)

N

Event Type (* from FPSINPUT.EQP_SCHED_EVENTS_MANUAL)

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)

IS_EXPT_STEP

CHAR(1)

Flag set to Y if the experiment requires abnormal processing at this step. (* from FPSBASE.WIP_LOT_HIST)

IS_NONSTD

CHAR(1)

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)

LAST_HOLD_RELEASE_INST

DATE

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)

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)

OPERATOR

VARCHAR2(64)

N

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)

PERM_RANK

VARCHAR2(1)

Permanent rank is typically loaded by ETL from a combination of the MES, recipe management system, and existing preference logic already used at the site. Possible values are in FPSADMIN.RTG_PERM_RANKS. (* from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

PREV_END_PROC_INST

DATE

End_proc_inst of the previous job on the tool before the job including this lot. Subtracting this from the end_proc_inst of this job gives us the end-to-end time (EET) which is critical for throughput calculations. (* from FPSBASE.WIP_LOT_HIST)

PREV_PROCESS

VARCHAR2(50)

Process of the previous job on the tool before the job including this lot. Used in combination with prev_recipe to determine if this job cascaded and if it required a setup change. (* from FPSBASE.WIP_LOT_HIST)

PREV_RECIPE

VARCHAR2(100)

Recipe of the previous job on the tool before the job including this lot. Used in combination with prev_process to determine if this job cascaded and if it required a setup change. (* from FPSBASE.WIP_LOT_HIST)

PROC_PORT

VARCHAR2(5)

PROC_PORT_MODE

VARCHAR2(24)

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)

RCP_EXP_QTY_PER_BATCH

NUMBER(3)

RCP_MAX_BATCH_SIZE_CARRIERS

NUMBER(2)

RCP_MAX_BATCH_SIZE_LOTS

NUMBER(2)

RCP_MAX_BATCH_SIZE_UNITS

NUMBER(7)

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)

ROUTE

VARCHAR2(256)

N

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

RQD_SETUP

VARCHAR2(100)

Rqd_setup is determined by ovr_rqd_setup in RTG_TOOL_ASSIGNMENTS and use_process_as_rqd_setup and use_est_mach_rcp_as_rqd_setup from EQP_TYPES. The latter two columns allow us to easily specify for an eqp_type that setup times should be calculated by process or est_machine_recipe. For traditional setups that are a group of recipes we use ovr_rqd_setup. (* from FPSBASE.WIP_LOT_HIST)

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

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

THP_IGNORE_REASON_WEH

VARCHAR2(12)