FPSAPP.DASH_P_TOOL_CHAMBERS

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)

ENTITY

The lowest level of the equipment hierarchy that an event can be logged against. Tools, subtools, shared parent tools, chambers, ports are all entities. Load locks are also included although we consider them as ports. (* inherited from FPSINPUT.EQP_STATUS_VERIFY)

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)

IS_ASSIST_CHAMBER

This indicates that the chamber assists the other primary chambers. If an assist chamber is in ch_allowed then at one least chamber of the ch_type must be up but as long as this is true then we ignore the assist chambers. We send only the non-assist chambers to the schedule as ch_to_sched. (* inherited from FPSINPUT.EQP_CHAMBERS)

IS_VIRTUAL_CHAMBER

This flag determines whether a chamber is a virtual chamber on a tool. Virtual chambers are used for scheduling but are not tracked like real processing chambers or assist chambers in other applications. Virtual chambers exist in ETP but always contribute 0% towards the cluster calculation for the tool. An example of this usage would be to model each of the sources for an implanter as a virtual chamber, so the area would be able to log these chambers up and down as needed. When a source needs replacement, it can be logged down and the scheduler will not schedule lots needing that source, instead switching to one of the available sources. Another example would be modeling the robot as a virtual chamber on a tool. (* inherited from FPSINPUT.EQP_CHAMBERS)

IS_MAIN_TOOL

CH

A single character to identify the chamber which must be unique with the tool. We concatenate the CH to get the string for CH_USED so it is helpful for diagnostic purposes if this single character is representative of the chamber (i.e. A for ET12CHA or 1 for MD27C1) because then the CH_USED string makes sense. However it is not required and if the chamber naming is inconsistent we might get use 1, 2, 3, etc. for the CH. (* inherited from FPSINPUT.EQP_CHAMBERS)

CH_TYPE

This column is critical for sequential chamber tools where a wafer goes through multiple chambers. It identifies the type of chamber so two chambers with the same ch_type are identical and wafers can use either one. See comment on mfg_pct_per_ch column for an example. For independent chamber tools where all chambers are the same and each wafer goes to only one chamber then ch_type should be set to the default value CH so that ch_type_cnt is 1CH, 2CH, 3CH, etc. (* inherited from FPSINPUT.EQP_CHAMBERS)

CAP_ENTITY

SUBTOOL

A subtool is an entity in the MES to which events can be logged that is between TOOL and CHAMBER. Subtool is rarely used. One example is when a chamber is part of a side which is part of a main tool and it is possible to log the side down which means you cannot use any chambers on that side. The side would be a subtool. (* inherited from FPSINPUT.EQP_CHAMBERS)

MFG_PCT_PER_CH

This optional value is the mfg_pct of the tool when this chamber is the only chamber of its ch_type that is MFG (PRD or SBY) while all chambers of all other ch_types are MFG. This column applies to sequential chamber tools which have chambers of more than one ch_type and have multiple chambers with the same ch_type. The default if this column is not set is to assume that all ch_types are bottlenecks of the tool so if 3 of 4 chambers of one type are MFG then the mfg_pct for that type is 75. If 2 of 3 then 66.7% and so on. But typically one ch_type is the bottleneck which means that if a chamber of another type is NONMFG (ENG or UDT or SDT) then the mfg_pct of tool is better than the ratio. Let us say a tool has two clean chambers C1+C2 and three deposition chambers C3+C4+C5. C1+C2 have ch_type CLEAN while C3+C4+C5 are all DEP. If both C1+C2 are NONMFG then the mfg_pct of the tool is 0% regardless of the status of the DEP chambers because it has no CLEAN chamber. Similarly if all three of C3+C4+C5 are NONMFG then it is also 0%. Of course if all chambers are MFG then it is 100%. But if at least one chamber is MFG while at least one of the CLEAN chambers and at least one of the DEP chambers is MFG then the tool can still run albeit with a degraded throughput. By default if only one of C1+C2 is MFG then the mfg_pct of the ch_type CLEAN is 50%. Similarly if one of C3+C4+C5 is MFG then the mfg_pct of DEP is 33.3% and if two then 66.7%. Technically the default calculation is 100/n where n is the number of chambers of the ch_type. But if the CLEAN chambers are the bottleneck and only one DEP chamber is NONMFG then the throughput will exceed the default of 67% and this mfg_pct_per_ch value is an estimate of this. If the mfg_pct_per_ch for DEP is 40 that means the throughput will be 40% with one DEP chamber up and 80% with two DEP chambers up. So the mfg_pct of the ch_type is p * number of MFG chambers (but no more than 100 of course) and the mfg_pct of the tool is the minimum of the mfg_pct of each ch_type. One final note is that mfg_pct_per_ch is an approximation of the contribution of each chamber for all recipes but in reality each recipe can be different. If we know the throughput for the chamber combination for the recipe then we use that instead of the mfg_pct_per_ch. For example, if C4 is NONMFG, mfg_pct_per_ch tells us the tool mfg_pct is 80% and we use that 80% number if the tool is standby or if we do not know the throughput on C1+C2+C3+C5 for the recipe running. But if we know that recipe runs at 30 UPH with all five chambers but 27 UPH with C1+C2+C3+C5 then we set the tool mfg_pct to 90%. (* inherited from FPSINPUT.EQP_CHAMBERS)

SORT_ORDER_WITHIN_TOOL

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)

PROCESS_FAMILY

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

PROCESS_GROUP

Process group is the critical field where tools and processes come together for the purposes of Scheduler. Process group is in both EQP_TOOLS for the tools and in RTG_PROCESSES for processes. Ideally all tools that run the same set of processes with no crossover including back-up and emergency tools would be in the same process group but it is important to note that this is not technically required for Scheduler as long as all process groups are in the same sched group. (* inherited from FPSINPUT.RTG_PROCESS_GROUPS)

PROCESS_CLASS

Top-level grouping of process groups with same general purpose (i.e. Process or Metrology or Nonwafer). Allowed values are defined by FPS and are listed in FPSADMIN.RTG_PROCESS_CLASSES. This field can also be defined in EQP_TOOLS using the ovr_process_class field if we do not know it for the process group. (* inherited from FPSINPUT.RTG_PROCESS_GROUPS)

MODULE

Modules are departments of people who manage certain areas of the fab. The modules are assigned ownership of a set of tools to operate and maintain as well as steps on the route that they are responsible for executing. Since many of our tables include tool and step information together, we must distinguish between the owner of the step (WIP_MODULE), the owner of the operation of the tool (EQP_MODULE), and the owner of the maintenance of the tool (MNT_MODULE). WIP_MODULE is used to credit moves and set goals. Each route-step is assigned to a process family and then its wip_module is defined by the process family. EQP_MODULE is used to group tools particularly for tool performance reporting. Similar to WIP, each tool is dynamically assigned to a process family based on its assignments and then its eqp_module is defined by the process family. MNT_MODULE is usually the same as EQP_MODULE but unlike EQP_MODULE is not dependent on assignments but only on the EQP hierarchy. Each tool is assigned to an eqp_type and each eqp_type is assigned to a mnt_family and each mnt_family is assigned to a mnt_module. (* inherited from FPSINPUT.GEN_MODULES)

MODULE_DISPLAY

The name of the module displayed on all dashboards and reports. We allow a longer more descriptive name here although often this will be the same as the module. (* inherited from FPSINPUT.GEN_MODULES)

MODULE_SORT_ORDER

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)

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_MODULE_SORT_ORDER

CURR_SETUP

The current setup of the entity. This can be set by a lot processing event from WIP_EVENT_HIST or by an event on the entity from EQP_EVENT_HIST. For example if an Implant tool processes a Boron lot then the curr_setup will be Boron. Or if an event is logged to the tool that says the setup changed to Boron then the curr_setup will be Boron. Please note that the curr_setup value populated in EQP_EVENT_HIST must match exactly with the rqd_setup value in RTG_TOOL_ASSIGNMENTS in order for the setup penalty logic to apply correctly. (* inherited from FPSINPUT.EQP_EVENT_HIST)

SETUP_CHG_INST

SETUP_CHG_EVENT

SETUP_CHG_OPERATOR

SETUP_CHG_COMMENT

ETP_STATE

If entity is down then use eqp_state directly. If entity is up then determine etp_state from proc_state and sby_state. (* inherited from FPSBASE.ETP_STATUS)

ETP_STATE_NAME

ETP_STATE_SHORT_DISPLAY

STATE_CHG_INST

Time when the eqp_state changed for the entity. (* inherited from FPSINPUT.EQP_STATUS_VERIFY)

STATE_CHG_EVENT

STATE_CHG_OPERATOR

STATE_CHG_COMMENT

INC_BATCH_PCT

Percentage of the full batch size processed. For tool performance calculations, TOOL_PCT percentage productivity is calculated using INC_BATCH_PCT to factor in that the batch size is not fully utilized. (* inherited from FPSBASE.WIP_LOT_HIST)

TOOL_PCT

AVAILABILITY

AVAIL_INST

Time when the availability last changed, either came up or went down. (* inherited from FPSBASE.ETP_STATUS)

MFG_GROUP

MFG_GROUP_INST

Time when the mfg_group last changed. (* inherited from FPSBASE.ETP_STATUS)

HTML_BG_COLOR

HTML_TEXT_COLOR

LOG_TYPE

DESCRIPTION

Tool desciption. This value is only used to display in the Dashboard. (* inherited from FPSINPUT.EQP_TOOLS)

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)

TOOL_MFG_PCT_ALL_TYPE_NONMFG

This column indicates tool mfg_pct if all chambers of the ch_type are NONMFG. It works in combination with ch_type, mfg_pct_per_ch, and subtool to allow us to calculate tool_pct for what we currently believe are all cases of chamber combinations. The common example here is a Litho cell which can still run in track-only mode if stepper is NONMFG but cannot run anything if track is NONMFG. Our default is to take the minimum mfg_pct of each type which would result is 0% for the tool if stepper was NONMFG. This column overrides that so if we set it to 60 for the stepper then we would consider the tool 60% even though only the track was MFG. Technically we would assign a tool_pct of 60 to the MFG track and then the remaining 40% to the NONMFG stepper. Another use for this column is when we have an extra chamber of a different ch_type that has limited use, perhaps just for R+D. Here we would set tool_mfg_pct_all_type_nonmfg to 100% and essentially ignore the chamber when it is NONMFG. In this special case, we can also set mfg_pct_per_ch to 0 to completely ignore it in any state. (* inherited from FPSINPUT.EQP_CHAMBERS)

SHOW_ENTITY