data-dictionary

FPSAPP.EQP_MNT_FUTURE_PLUS

Data Dictionary

>

FPSAPP Views

> FPSAPP.WIP_WAFER_HIST_LOOP

View FPSBASE.EQP_MNT_FUTURE_PLUS

Adds estimated times for counter-based PM's using rate of change, is_early/due/late, counter_remaining, and other columns.

Column

Comment

UPDATED_INST

Time when the record was updated according to the source data. Note this is not the time when the record was actually updated in this table - it will almost always be earlier. (* inherited from FPSINPUT.GEN_FACILITIES)

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)

CH_SHORT_DISPLAY

Short display for the chamber displayed on Dashboard and reports as part of a list of chambers used. This should not include the tool name but only the chamber on the tool so if the chambers on ET11 are ET11CHA and ET11CHB1 and ET11CHB2 then this field should be A, B1, and B2. (* inherited from FPSINPUT.EQP_CHAMBERS)

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)

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)

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)

IS_QUAL

This should be set to Y if the state should count as a qual event and time spent in this state should count as qual time. The EQP_L5_QUAL_CHECK constraint ensures that this must be set to Y when mnt_group is QUAL. The is_qual column is critical for NMV_P_TOOL_QUAL_SUMMARY and this constraint is not perfect but it prevents the most obvious wrong case. (* inherited from FPSINPUT.EQP_L5_TRANSITION_STATES)

INCLUDE_IN_DASH_DOWN

This column will hide tools from the Down tools section of the Equipment Dashboard if set to N for this opportunity state (* inherited from FPSADMIN.ETP_L4_OPPORTUNITY_STATES)

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)

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)

MNT_SCHED_STATUS

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)

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)

ACTUAL_START_OPERATOR

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

EST_END_INST

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_START_OPERATOR

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. (* 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)

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)

CARRIER_STATE

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

DURABLE_STATE

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

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_FIXED_FOR_SCHED

Y indicates that this upcoming maintenance time is fixed and should be scheduled around by the Scheduler. (* 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)

MNL_IS_WAITING_FOR_PARTS

MNL_IS_FIXED_FOR_SCHED

MNL_EST_MNT_DURATION_SEC

ADJUSTED_START_INST

DISTINCT_PARTS

SUM_PARTS_RQD

SUM_PARTS_AVAIL

TECHS_CERTIFIED_POSSIBLE