FPSBASE.EQP_MNT_HIST

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)

EVENT_ID

VARCHAR2(64)

N

Field that uniquely identifies the maintenance task definition in the facility. `Event_id` is usually a number or code from the maintenance system, but it could also be defined as `logged_entity` concatenated with `mnt_name`, since that combination also uniquely represents an event. It is important to ensure that our definition of `event_id` represents repeated instances of the same maintenance event with the same `event_id`. For example, if we have a monthly PM on tool T1, there will be instances of this event each month. The field used as `event_id` could be something like T1 monthly PM; it should *not* be something like T1 monthly PM Jan, T1 monthly PM Feb, etc., since this would cause the `event_id` to change every month. (* from FPSINPUT.EQP_MNT_FUTURE)

ACTUAL_START_INST

DATE

Time when maintenance was started if it is currently in progress. This should be null for all upcoming events which have not started yet which means that this will be null for the majority of records. (* from FPSINPUT.EQP_MNT_FUTURE)

ACTUAL_START_OPERATOR

VARCHAR2(64)

Username of the user that logged actual start occurrence of this maintenance if known. It is common for this field to be null for all records. (* from FPSINPUT.EQP_MNT_FUTURE)

CARRIER_STATE

VARCHAR2(18)

Carrier state indicates the current state of the carrier. The value must be one of those defined by FPS in FPSADMIN.MHS_CARRIER_STATES. This is a very short list of simple states like OK or WARN or DOWN in contrast to the complex options available for equipment states. This would be used as a filter/sort on what carriers could be selected when a carrier is needed. For example, when a lot is split we need to find another carrier for the split lot and we would prefer one with state of OK then WARN but we could not choose one which was DOWN. (* from FPSINPUT.MHS_CARRIERS)

COUNTER_CHG_PER_DAY

NUMBER(13,4)

Average change in the counter per day calculated by linear regression and used to estimate the time for a counter-based maintenance (* from FPSBASE.EQP_MNT_COUNTER_CURR)

COUNTER_CURR

NUMBER(12,3)

Current counter value read at counter_read_inst (* from FPSBASE.EQP_MNT_COUNTER_CURR)

COUNTER_DIRECTION

VARCHAR2(4)

COUNTER_DUE

NUMBER(12,3)

Counter value when the maintenance event will be due or expected. See `counter_early` and `counter_late` for the window of values in which the maintenance can be performed. (* from FPSINPUT.EQP_MNT_FUTURE)

COUNTER_EARLY

NUMBER(12,3)

Counter value when the maintenance event will be early (* from FPSINPUT.EQP_MNT_FUTURE)

COUNTER_FOR_COMPARE

NUMBER(12,3)

The counter value used for comparing to the due date, this could either be the counter_curr or the counter_pre_reset_value, but should be more reliable than either of the two independently.

COUNTER_INTERVAL

NUMBER(12,3)

Indicates the frequency of future occurrences of this maintenance. For example, a qual required every 250 wafers will be listed once with counter_due set to the next occurrence and `counter_interval` set to 250 so we know to plan for it to occur again 250, 500, 750, etc. wafers after the counter_due. (* from FPSINPUT.EQP_MNT_FUTURE)

COUNTER_LATE

NUMBER(12,3)

Counter value when the maintenance event will be late. In most systems, the entity in question will be mandatorily logged down if the maintenance is not started before the counter reaches this value. (* from FPSINPUT.EQP_MNT_FUTURE)

COUNTER_NAME

VARCHAR2(64)

Name of the counter used for this maintenance event. (* from FPSINPUT.EQP_MNT_FUTURE)

COUNTER_PRE_RESET_INST

DATE

The inst the last time the counter value was reset. (* from FPSBASE.EQP_MNT_COUNTER_CURR)

COUNTER_PRE_RESET_VALUE

NUMBER(12,3)

If a counter has been reset recently then this will be the min or max value depending on the counter direction before the counter was reset. A null value means that there were no resets within the min_used_counter_read_inst (* from FPSBASE.EQP_MNT_COUNTER_CURR)

COUNTER_UNITS

VARCHAR2(18)

Unit for the maintenance counter. Common examples include wafers or hours or kWh. (* from FPSINPUT.EQP_MNT_FUTURE)

CURR_COUNTER_READ_INST

DATE

DURABLE_STATE

VARCHAR2(36)

Durable state indicates the current state of the durable The value must be one of those defined by FPS in FPSADMIN.MHS_CARRIER_STATES. This is a short list of simple states like OK or WARN or DOWN in contrast to the complex options available for equipment states. This would be used as a filter/sort on what durables could be used for scheduling. For example, if there are two durables in the durable_family and one is OK and the other is DOWN then we schedule using the OK durable. But if there is only one durable in the family then we cannot schedule any lots which require this family if that lone durable is DOWN. (* from FPSINPUT.RTG_DURABLES)

EARLY_INST

DATE

Earliest time when maintenance can be started. (* from FPSINPUT.EQP_MNT_FUTURE)

ENT_OR_CARR_OR_DUR

VARCHAR2(1)

Upcoming maintenance for entities, carriers, and durables is included together in this table. An E here indicates that the `logged_entity` field in this table is an entity, C for carrier, and D for durable. (* from FPSINPUT.EQP_MNT_FUTURE)

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)

EST_DUE_INST

DATE

Best guess at when the mnt event was due. For non-counter-based values chances are this came from the ETL. For counter-based values we use the rate of change.

EST_MNT_DURATION_SEC

NUMBER(8)

Est_mnt_duration_sec is the estimate of the total duration of the maintenance in seconds including work time, wait time, and qual time. Est_mnt_duration_sec is required then if desired, this total can be broken down into est_mnt_work_sec, est_mnt_wait_sec, and est_mnt_qual_sec. These three breakdown columns are optional but if any of those three columns are populated then they must sum to the value of est_mnt_duration_sec. Only est_mnt_duration_sec is used in FPS applications. The other three are available for informational purposes and to use for custom reporting but are not currently used in any FPS application. (* from FPSINPUT.EQP_MNT_FUTURE)

EST_START_INST

DATE

Best guess at when the mnt event started. If actual_start_inst is provided it will be that value otherwise it will be the inst - est_mnt_duration_sec

EVENT_TIMELINESS

VARCHAR2(56)

N

For this occurrence of the event, how timely was it executed relative to the early, due and late values. May be used for linking to ETP_MNT_EPISODE_HIST.

EVENT_TIMELINESS_NOTE

VARCHAR2(200)

A quality metric for the event_timelessness column noting if the data is good or bad or has a warning with a small note on why it has the quality it does.

EVENT_TIMELINESS_QUALITY

NUMBER(1)

A quality metric for the event_timelessness column noting if the data is good or bad or has a warning. 1 = we have good data,and everything is great, 2 = small warning but we think we have what we need, 3 = bad, we are missing key data, 9 = we may have encountered an error.

HISTORY_SOURCE

VARCHAR2(36)

The reason why this history was written. What caused us to think that this mnt event was finished. Values starting with U are triggered from updating in EQP_MNT_FUTURE. Values starting with D are from being deleted from EQP_MNT_FUTURE, values start with C are triggered from a counter reset in EQP_MNT_COUNTER_CURR.

LAST_END_INST

DATE

Time when the last occurrence of this maintenance was completed if known. It is common for this field to be null for all records. (* from FPSINPUT.EQP_MNT_FUTURE)

LAST_END_OPERATOR

VARCHAR2(64)

Username of the user that logged last completed occurrence of this maintenance if known. It is common for this field to be null for all records. (* from FPSINPUT.EQP_MNT_FUTURE)

LAST_START_INST

DATE

Time when last completed occurrence of this maintenance started if known. It is common for this field to be null for all records. (* from FPSINPUT.EQP_MNT_FUTURE)

LAST_START_OPERATOR

VARCHAR2(64)

Username of the user that logged last started occurrence of this maintenance if known. It is common for this field to be null for all records. (* from FPSINPUT.EQP_MNT_FUTURE)

LATE_INST

DATE

Latest time when maintenance can be started. In most systems, the entity in question will be mandatorily logged down if the maintenance is not started by this time. (* from FPSINPUT.EQP_MNT_FUTURE)

MNT_CREATED_INST

DATE

Time when this maintenance event_id was first created in the system. (* from FPSINPUT.EQP_MNT_FUTURE)

MNT_DUE_INST

DATE

Time when the next occurrence of a time-based maintenance is due or expected. See `early_inst` and `late_inst` for the window of time in which the maintenance can be performed (* from FPSINPUT.EQP_MNT_FUTURE)

MNT_INTERVAL_SEC

NUMBER(9)

Indicates the frequency of future occurrences of this maintenance. For example, a daily PM will be listed once with due_inst set to the next occurrence and `mnt_interval_sec` set to 86400 so we know to plan for it to occur again 24, 48, 72, etc. hours after `mnt_due_inst`. (* from FPSINPUT.EQP_MNT_FUTURE)

MNT_NAME

VARCHAR2(128)

Name identifying the scheduled maintenance event which is unique for the `logged_entity`. For example, daily qual or weekly PM. (* from FPSINPUT.EQP_MNT_FUTURE)

MNT_TECH_USERNAME

VARCHAR2(64)

The unique identifier of a technician that also needs to exist in GEN_USERS. (* from FPSINPUT.MNT_TECHNICIANS)

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)