data-dictionary

FPSINPUT.EQP_LAST_EV_OLDER_1HR

Data Dictionary

>

FPSINPUT Tables

> FPSINPUT.EQP_LAST_EV_OLDER_1HR

Table FPSINPUT.EQP_LAST_EV_OLDER_1HR"

See comments in EQP_LAST_EV_OLDER_1HR_CUSTOM procedure.

  • Schema: FPSINPUT

  • Tablespace: FPSDATA

  • Primary key: INST, FACILITY, LOGGED_ENTITY, TOOL, EVENT, EVENT_TYPE, SEQ_WITHIN_SEC, SOURCE_TABLE


Column

Type

Nullable

Comment

INST

DATE

N

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

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)

LOGGED_ENTITY

VARCHAR2(36)

N

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)

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)

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)

SEQ_WITHIN_SEC

NUMBER(6,2)

N

SOURCE_TABLE

VARCHAR2(30)

N

ACTUAL_MACHINE_RECIPE

VARCHAR2(100)

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

CURR_SETUP

VARCHAR2(100)

The current setup of the entity. This can be set by a lot processing event from WIP_EVENT_HIST or by an event on the entity from EQP_EVENT_HIST. For example if an Implant tool processes a Boron lot then the curr_setup will be Boron. Or if an event is logged to the tool that says the setup changed to Boron then the curr_setup will be Boron. Please note that the curr_setup value populated in EQP_EVENT_HIST must match exactly with the rqd_setup value in RTG_TOOL_ASSIGNMENTS in order for the setup penalty logic to apply correctly. (* from FPSINPUT.EQP_EVENT_HIST)

EQP_STATE

VARCHAR2(48)

Client equipment state taken directly from their MES or from their existing tool state model. For EQP_MNT_FUTURE, this is the state that we estimate the entity will be in during the maintenance which is often set to a generic PM state if we do not have detailed information. (* from FPSINPUT.EQP_L6_DETAILED_STATES)

EVENT_COMMENT

VARCHAR2(512)

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

JOB_ID

VARCHAR2(64)

Automatically set by trigger when the first lot of a job logs an event to the tool. (* from FPSBASE.WIP_LOT_HIST)

LOT_LIST

VARCHAR2(106)

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)