FPSBASE.DASH_P_MNT_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)

MNT_MODULE

MNT_MODULE is the module responsible for maintaining the tool and is a property of MNT_FAMILY. See comments on the module column in GEN_MODULES for how it relates to eqp_module and mnt_module. (* inherited from FPSINPUT.EQP_MNT_FAMILIES)

MNT_MODULE_DISPLAY

MNT_FAMILY

MNT_FAMILY is assigned to each EQP_TYPE. Tools in the same MNT_FAMILY are similar and share the same maintenance schedule. (* inherited from FPSINPUT.EQP_MNT_FAMILIES)

EQP_TYPE

Each tool is assigned an EQP_TYPE and all tools in the same type are identical meaning that they should run at the same throughput when running the same process with the same chamber type count. We also expect similar availability since these tools are identical. However tools in the same EQP_TYPE may have different chamber configurations and may run different groups of processes. (* inherited from FPSINPUT.EQP_TYPES)

EQP_MODULE

EQP_MODULE is the module responsible for operating the tool. See comments on the module column in GEN_MODULES for info on this column and how it relates to eqp_module and mnt_module. (* inherited from FPSBASE.EQP_TOOLS_PLUS)

EQP_MODULE_DISPLAY

PROCESS_FAMILY

See https://help.inficonims.com/display/DW/Guide+to+Process+Families. (* inherited from FPSINPUT.RTG_PROCESS_FAMILIES)

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)

BAY

A bay is a physical area within the building. The bay is important for estimating travel time for a carrier to reach its destination as we usually store these estimates as a matrix of bay-to-bay and assume that the estimated time from any location within one bay to any location within another bay is approximately the same. (* inherited from FPSINPUT.MHS_BAYS)

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

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)

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)

ETP_GROUP

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)

EST_DURATION_SEC

Estimate of the duration of the future hold if known. If blank we use the estimate for the hold_type. (* inherited from FPSINPUT.WIP_HOLD_FUTURE)

DURATION_DISP

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)

EST_END_INST

EARLY_INST

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

DUE_INST

To indicate the due date for this futuer start lot (* inherited from FPSINPUT.WIP_STARTS)

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)

IS_NEXT_INSTANCE

INSTANCE_NUM

INTERVAL_SEC

Unit_int_sec or batch_int_sec expected for the lot at the time of processing from our THP tables. (* inherited from FPSBASE.WIP_LOT_HIST)

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

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

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_READ_INST

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

COUNTER_REMAINING

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)

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)

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)

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)

HIDE_IN_DASH

Set to Y to hide this tool from the Dashboard and most other reports. (* inherited from FPSINPUT.EQP_TOOLS)

MNT_SCHED_STATUS

MNT_SCHED_STATUS_DISPLAY

MNT_SCHED_STATUS_DESC

MNT_SCHED_STATUS_SORT_ORDER

STATUS_BG_COLOR_HTML

STATUS_TEXT_COLOR_HTML

SHOW_IN_SUMMARY

REMAINING_DISP