Data Dictionary
>
FPSAPP Tables
> FPSAPP.EQP_PORT_HIST
Table FPSAPP.EQP_PORT_HIST"
Log of all changes to EQP_PORTS populated by simple history trigger. You can query the state of the table at any time in the past by using t >= chg_timestamp and t < next_chg_timestamp.
-
Schema: FPSAPP
-
Tablespace: FPSDATAHIST
-
Primary key: CHG_TIMESTAMP, FACILITY, LOCATION
|
Column |
Type |
Nullable |
Comment |
|---|---|---|---|
|
CHG_TIMESTAMP |
TIMESTAMP(4) |
N |
For CHGLOG and automatic HIST tables, this is populated with SYSTIMESTAMP. This means that this record existed in the original table from this time until NEXT_CHG_TS. |
|
FACILITY |
VARCHAR2(6) |
N |
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. (* from FPSINPUT.GEN_FACILITIES) |
|
LOCATION |
VARCHAR2(32) |
N |
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. (* from FPSINPUT.MHS_RACK_LOCATIONS) |
|
ACTION |
VARCHAR2(1) |
For CHGLOG and automatic HIST tables, this is I for insert or U for updated or D for delete. |
|
|
CAPACITY |
NUMBER(3) |
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. (* from FPSINPUT.EQP_PORTS) |
|
|
CARRIER_CLASS |
VARCHAR2(13) |
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. (* from FPSINPUT.MHS_CARRIERS) |
|
|
IS_INTERNAL |
CHAR(1) |
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. (* from FPSINPUT.EQP_PORTS) |
|
|
NEXT_CHG_TS |
TIMESTAMP(4) |
For CHGLOG and automatic HIST tables, this is null when inserted and then updated with SYSTIMESTAMP of the next change. This means that this record existed in the original table from CHG_TIMESTAMP until this time. |
|
|
PORT |
VARCHAR2(5) |
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. (* from FPSINPUT.EQP_PORTS) |
|
|
PORT_GROUP |
VARCHAR2(12) |
Optional value if tool has different groups of ports, for example 150mm and 200mm. RQD_PORT_GROUP in RTG_TOOL_ASSIGNMENTS indicates what is required for each lot. (* from FPSINPUT.EQP_PORTS) |
|
|
PORT_MODE |
VARCHAR2(24) |
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. (* from FPSINPUT.EQP_PORT_MODES) |
|
|
PORT_MODE_OPERATOR |
VARCHAR2(64) |
Username of the operator who set the current port mode. (* from FPSINPUT.EQP_PORTS) |
|
|
TOOL |
VARCHAR2(16) |
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. (* from FPSINPUT.EQP_TOOLS) |