FPSAPP.DASH_P_TOOL_PORTS

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)

PORT

Port is the short name of the port on the tool like P1 or LLA. This field is unique within the given tool and is used to save space when we already know the tool, for example in the dashboard tool hover where we show the status of each port. This column is in contrast to the location field which is the full name of the port. Location is unique within the entire facility and almost always includes the tool name like ET99P1 or ET99LLA. In addition, location is usually available from the MES or AMHS as this must be an exact match with the location in MHS_CARRIERS if this gets set when a carrier is placed on the port. On the other hand, the shorter port column is often not available in the MES so we either populate manually or with some complex if-then logic in the ETL based on the naming standards. (* inherited from FPSINPUT.EQP_PORTS)

LOCATION

Location of a carrier or lot or durable which comes directly from the tracking system used at the site. This could be a port or internal tool location or tool or rack or stocker or zero footprint storage or room or really anywhere. Many non-automated sites allow users to manually enter locations into their system. Therefore unless we know for sure that the source data implements a size limitation, it is recommended to always trim the value in the ETL to 32 characters to fit into the column size and avoid load errors. For ports, location is the full name of the port which is unique across the entire site and usually includes the tool name. Please see the comment in the port column which explains the difference between location and port. Rack locations are similar. (* inherited from FPSINPUT.MHS_RACK_LOCATIONS)

CARRIER

RFID of the cassette or FOUP the lot is currently in. (* inherited from FPSINPUT.MHS_CARRIERS)

NUM_PORTS_ON_TOOL

PORT_MODE

PORT_MODE is the port equivalent to EQP_STATE. Examples might be AUTOMATIC, MANUAL, SEMI-AUTOMATIC, or DOWN. If configured in GEN_FACILITIES, the view DASH_P_TOOL_PORTS can overlay whether the port is occupied along with its carrier and the WIP processing states over the port modes as long as the port mode has is_up set to Y. Therefore it is not necessary to reflect occupied or empty when developing the ETL logic to populate the EQP_PORTS table. (* inherited from FPSINPUT.EQP_PORT_MODES)

PORT_MODE_DISPLAY

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

BG_COLOR

Background color assigned. BG_COLOR is in English like red or blue or light green and we look up the HTML color like #FF0000 in the GEN_COLORS table. BG_COLOR must be set manually but the FPSADMIN view BLD_POPULATE_COLORS will generate queries to randomly set bg_color for all values in a table. (* inherited from FPSINPUT.GEN_CUSTOMERS)

HTML_BG_COLOR

HTML_TEXT_COLOR

PORT_MODE_OPERATOR

Username of the operator who set the current port mode. (* inherited from FPSINPUT.EQP_PORTS)

IS_AUTO

This field shows if the port mode is set to automatically deliver material. If the facility either has automated delivery (aka 300mm) or is using semi-automated delivery (aka NextMove) then a port set to a port_mode where this is N but is_up is Y is considered manual. A manual port means that the delivery system cannot use this port. If all ports are manual then rank will be M (Ports Manual) and ETP will set the state to SBY-RANKM (Standby With All Ports in Manual). In addition, we report auto_pct by summarizing the port states in auto and manual. (* inherited from FPSINPUT.EQP_PORT_MODES)

IS_UP

This field shows if the port mode of the stations is considered up or down. If all ports are down then rank will be R (Ports Down) and ETP will set the state to SBY-RANKR (Standby With All Ports Down). (* inherited from FPSINPUT.EQP_PORT_MODES)

CAPACITY

In EQP_PORTS, capacity is the number of carriers allowed on the port, which is usually 1. In MHS_CARRIERS, when carrier_class is set to POD then capacity is the number of durables that the pod can hold, which is usually either 1 or 6. This field is only used in MHS_CARRIERS for pods therefore when CARRIER_CLASS is CAST then capacity should be set to the default value of 1. (* inherited from FPSINPUT.EQP_PORTS)

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)

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)

PROCESS_FAMILY

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

CARRIER_CLASS

Carrier class indicates what the carrier is able to carry. It is also an important field in EQP_PORTS but each port has a single defined carrier class and only carriers of this class should go to the port. The value must be one of those defined by FPS in FPSADMIN.MHS_CARRIER_CLASSES which include POD or CAST or BOX. This would be used as a filter 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 select the best carrier in the carrier_class of CAST. But if we need to unload a reticle then we select the best carrier in the carrier_class of POD. (* inherited from FPSINPUT.MHS_CARRIERS)

IS_INTERNAL

Set to Y if the location is internal to the tool. For example, a bath inside a sink. This is critical to NextMove since we cannot direct a carrier to move to this port. (* inherited from FPSINPUT.EQP_PORTS)

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