FPSADMIN.EQP_MNT_FUTURE_ALL_INSTANCES

FACILITY

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

TOOL

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

LOGGED_ENTITY

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

CHAMBER

Chambers belong to a main tool, have a state which is independent of the main tool and other chambers on the same tool, and can have events logged against it. The difference between a chamber and a port is that a chamber processes lots while port is just a location. (* inherited from FPSINPUT.EQP_CHAMBERS)

EQP_STATE

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

OPPORTUNITY_STATE

FPS Enhanced Tool Performance group assigned to each transition_state and to each etp_family. This assignment determines the default grouping on all Tool Performance charts and determines the color on all views including Dashboard and Gantt charts. (* inherited from FPSINPUT.EQP_L5_TRANSITION_STATES)

E10_STATE

MNT_GROUP

Grouping field for upcoming maintenance on Dashboard and Mnt Viewer. This can be any value and should be formatted for display. (* inherited from FPSINPUT.EQP_L5_TRANSITION_STATES)

MNT_NAME

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

EST_MNT_DURATION_SEC

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

EST_MNT_WORK_SEC

See column comment for est_mnt_duration_sec. (* inherited from FPSINPUT.EQP_MNT_FUTURE)

EST_MNT_WAIT_SEC

See column comment for est_mnt_duration_sec. (* inherited from FPSINPUT.EQP_MNT_FUTURE)

EST_MNT_QUAL_SEC

See column comment for est_mnt_duration_sec. (* inherited from FPSINPUT.EQP_MNT_FUTURE)

EVENT_ID

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

INSTANCE_ID

ACTUAL_START_INST

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

MNT_SCHED_STATUS

EARLY_INST

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

MNT_DUE_INST

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

ADJUSTED_START_INST

LATE_INST

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

EST_END_INST

IS_NEXT_INSTANCE

INSTANCE_NUM

MNT_INTERVAL_SEC

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`. (* inherited from FPSINPUT.EQP_MNT_FUTURE)

HAS_COUNTER

COUNTER_NAME

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

COUNTER_UNITS

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

COUNTER_CURR

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

COUNTER_READ_INST

Time when the current counter value was reported. (* inherited from FPSBASE.EQP_MNT_COUNTER_CURR)

COUNTER_EARLY

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

COUNTER_DUE

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

COUNTER_LATE

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

COUNTER_REMAINING

COUNTER_CHG_PER_DAY

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

COUNTER_INTERVAL

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

OPERATOR

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

MNT_CREATED_INST

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

LAST_START_INST

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

LAST_END_INST

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

LAST_END_OPERATOR

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

MNT_TECH_USERNAME

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

IS_WAITING_FOR_PARTS

If this is set then the maintenance event is effectively on hold waiting for parts. (* inherited from FPSINPUT.EQP_MNT_FUTURE)

IS_HIDDEN_BY_DEFAULT

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

NUM_TECHS_RQD

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

OPTIONAL_DASH_ORDER

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`. (* inherited from FPSINPUT.EQP_MNT_FUTURE)

ENT_OR_CARR_OR_DUR

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