FPSAPP.EQP_MNT_FUTURE

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)

EVENT_ID

VARCHAR2(64)

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.

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.

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.

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_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.

COUNTER_EARLY

NUMBER(12,3)

Counter value when the maintenance event will be early

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.

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.

COUNTER_NAME

VARCHAR2(64)

Name of the counter used for this maintenance event.

COUNTER_UNITS

VARCHAR2(18)

Unit for the maintenance counter. Common examples include wafers or hours or kWh.

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.

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.

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_MNT_DURATION_SEC

NUMBER(8)

N

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.

EST_MNT_QUAL_SEC

NUMBER(8)

See column comment for est_mnt_duration_sec.

EST_MNT_WAIT_SEC

NUMBER(8)

See column comment for est_mnt_duration_sec.

EST_MNT_WORK_SEC

NUMBER(8)

See column comment for est_mnt_duration_sec.

IS_FIXED_FOR_SCHED

CHAR(1)

Y indicates that this upcoming maintenance time is fixed and should be scheduled around by the Scheduler.

IS_HIDDEN_BY_DEFAULT

CHAR(1)

If this flag is set then this event is hidden by default on the Maintenance Dashboard to avoid clutter. There is an option to show hidden events.

IS_WAITING_FOR_PARTS

CHAR(1)

If this is set then the maintenance event is effectively on hold waiting for parts.

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.

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.

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.

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.

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.

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)

MNT_CREATED_INST

DATE

Time when this maintenance event_id was first created in the system.

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

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`.

MNT_NAME

VARCHAR2(128)

N

Name identifying the scheduled maintenance event which is unique for the `logged_entity`. For example, daily qual or weekly PM.

MNT_TECH_USERNAME

VARCHAR2(64)

Username of the maintenance technician who is performing or will perform the maintenance event. This is not the same as `operator` which is the username of the person who input the information about the maintenance event into the system, nor `last_end_operator` which is the username of the person who logged the last completed occurrence of the maintenance event.

NUM_TECHS_RQD

NUMBER(1)

We assume that each maintenance event requires one technician but this column allows us to indicate that more than one person is required to complete the event.

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)

OPTIONAL_DASH_ORDER

NUMBER(4)

Maintenance teams want to specify a certain sort order for maintenance events on each tool in the Gantt chart. For example, they want to put the most frequent or important ones first instead which ones have the earliest `mnt_due_inst`. If this order is not specified then it will use the default sorting which is by `mnt_due_inst`.