FPSADMIN.MHS_CARRIER_ATTRIBUTE_HIST

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

CARRIER

VARCHAR2(32)

N

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

ACTION

VARCHAR2(1)

For CHGLOG and automatic HIST tables, this is I for insert or U for updated or D for delete. (* from FPSINPUT.EQP_PORT_HIST)

CAPACITY

NUMBER(3)

N

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)

N

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)

CARRIER_STATE

VARCHAR2(18)

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

CARRIER_STATE_DISPLAY

VARCHAR2(128)

The name of the carrier_state displayed on all dashboards and reports. Carrier_state must match the FPS list defined in MHS_CARRIER_STATES but this display field might be formatted in a more familiar way to the users in the facility. (* from FPSINPUT.MHS_CARRIERS)

CARR_CATEGORY

VARCHAR2(17)

N

Carrier category is used when lots in a certain of the line require a carrier in the specific category. This is usually required due to potential contamination. One example might be that an entire route is Copper and all lots at all steps on the routes must be in Copper carriers. Another example might be front-end-of-line (FEOL) and back-end-of-line (BEOL) where the first half of the route must use a FEOL carrier and the second half of the route might be a BEOL carrier. Whenever a route is split then there has to be a carrier transfer step on the route in between the sections which require each category. To define this, each route-step has a required carr_category and each carrier has a carr_category. (* from FPSINPUT.MHS_CARRIERS)

DB_MACHINE

VARCHAR2(64)

For CHGLOG and automatic HIST tables, this is populated with the HOST system variable from USERENV. (* from FPSINPUT.EQP_CHAMBERS_CHGLOG)

DB_OSUSER

VARCHAR2(30)

For CHGLOG and automatic HIST tables, this is populated with the OS_USER system variable from USERENV. (* from FPSINPUT.EQP_CHAMBERS_CHGLOG)

DB_USERNAME

VARCHAR2(30)

For CHGLOG and automatic HIST tables, this is populated with the USER system variable. (* from FPSINPUT.EQP_CHAMBERS_CHGLOG)

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)

NMV_ADDL_BADGE_COLOR

VARCHAR2(24)

This is the color of the additional badge on NextMove. See comment on NMV_ADDL_BADGE_LABEL for details. (* from FPSINPUT.MHS_CARRIERS)

NMV_ADDL_BADGE_LABEL

VARCHAR2(7)

By default, NextMove displays a badge next to the carrier indicating that it is a priority lot but this column allows us to show an additional badge indicating anything that we wish to highlight. (* from FPSINPUT.MHS_CARRIERS)

OVR_CARRIER_DISPLAY

VARCHAR2(32)

The ID of the carrier for application display purposes. For example, the internal/referential carrier ID might be a zero-padded hexidecimal number, while the human-readable labels on the carriers might be an unpadded decimal equivalent (e.g. CARRIER=A1B2, OVR_CARRIER_DISPLAY=41394). (* from FPSINPUT.MHS_CARRIERS)

PARENT_CARRIER

VARCHAR2(32)

The typical use of this field is when a carrier is in a box then we set this to the box. This is optional and we do not store any other information about the parent carrier. (* from FPSINPUT.MHS_CARRIERS)

POD_FAMILY

VARCHAR2(64)

This column is optional and only applies to pods/durables and not cassettes/lots. Certain durables must be stored in a specific group of pods and this is designated with this column. (* from FPSINPUT.MHS_CARRIERS)