data-dictionary

FPSBASE.NMV_P_CARRIERS

Data Dictionary

>

FPSBASE Views

> FPSBASE.WIP_WAFER_HIST_LOOP

View FPSAPP.NMV_P_CARRIERS

Carrier data for NextMove

Column

Comment

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)

CARRIER

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

CARRIER_DISPLAY

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)

CARR_CATEGORY

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

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)

LOCATION_TYPE

LOCATION_INST

Time when the carrier arrived at the location. (* inherited from FPSINPUT.MHS_CARRIERS)

STATION

The rack, bay, building, tool, cart, or stocker which has alternately acceptable stations (* inherited from FPSINPUT.MHS_STATION_ALTERNATES)

STATION_TYPE

BAY

A bay is a physical area within the building. The bay is important for estimating travel time for a carrier to reach its destination as we usually store these estimates as a matrix of bay-to-bay and assume that the estimated time from any location within one bay to any location within another bay is approximately the same. (* inherited from FPSINPUT.MHS_BAYS)

BUILDING

Building is the top of our MHS hierarchy at each site. It is independent of facility which is at the top of our EQP/RTG hierarchy. It is possible for a building to include multiple facilities and for a facility to include multiple buildings but we do not even need to define these relationships because EQP_TOOLS determines this by the combination of the facility and bay columns (since bay points to building). (* inherited from FPSINPUT.MHS_BUILDINGS)

LAST_KNOWN_LOCATION

Often when a carrier is in transit we do not know exactly where it is but we only know where it came from. In this case we might set the location to something generic like TRANSIT and the last known location to where it came from. (* inherited from FPSINPUT.MHS_CARRIERS)

LAST_KNOWN_LOCATION_INST

Time when the last_known_location was originally updated as the location of this carrier. This column and last_known_location are both updated by trigger. (* inherited from FPSINPUT.MHS_CARRIERS)

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)

AMHS_VEHICLE

The vehicle used to move a carrier when in transit or when a move is requested. This is an optional input value that comes from the AMHS. It is not the cart which should be used which we decide in MHS_DELIVERY_NEXT. (* inherited from FPSINPUT.MHS_CARRIERS)

AMHS_DESTINATION

The destination of a carrier when in transit or when a move is requested. This is an optional input value that comes from the AMHS. It is not where the carrier needs to go which we decide in MHS_DELIVERY_NEXT but rather where it is already going in the AMHS. If this value is blank then we know the carrier has no move requested. (* inherited from FPSINPUT.MHS_CARRIERS)