data-dictionary

FPSBASE.NMV_P_RESERVED_SCHED_CARRIERS

Data Dictionary

>

FPSBASE Views

> FPSBASE.WIP_WAFER_HIST_LOOP

View FPSAPP.NMV_P_RESERVED_SCHED_CARRIERS

This very fast view shows the complete information for all carriers either reserved or scheduled to a tool. This one view will be used to built the combined reserved and scheduled lists in NextMove. This view takes advantage of the WIP_STEP_FUTURE index on tool_for_tts which is the reserved or scheduled tool. This view should be queried like this; select * from fpsapp.nmv_p_reserved_sched_carriers where facility = 'FFF' and tool = 'TTT' order by manl_reserve_order nulls last, weh_reserve_inst nulls last, sched_start nulls last;

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)

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)

TOOL_BAY

PROCESS_FAMILY

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

CARRIER

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

CARRIER_DISPLAY

LOT_LIST

NUM_LOTS_IN_CARRIER

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

CURR_STATION

See column comment on STATION in FPSINPUT.MHS_STATION_ALTERNATES for more information. (* inherited from FPSINPUT.MHS_DELIVERY_NEXT)

CURR_STATION_TYPE

Current station type of carrier. See view MHS_LOCATIONS for more information. (* inherited from FPSINPUT.MHS_DELIVERY_NEXT)

CURR_BAY

Current bay of carrier. See column comment on BAY in FPSINPUT.MHS_BAYS for more information. (* inherited from FPSINPUT.MHS_DELIVERY_NEXT)

NUM_STEPS_AWAY

Number of steps away not including steps which we know will be skipped nor those which we estimate will be skipped at least x pct of the time. This x value is configurable in GEN_FACILITIES using the smp_pct_for_num_steps_away column. (* inherited from FPSBASE.WIP_STEP_FUTURE)

IS_LOADED

IS_RESERVED

This flag indicates if the carrier has been reserved to a tool. (* inherited from FPSINPUT.MHS_DELIVERY_NEXT)

JOB_ID

Automatically set by trigger when the first lot of a job logs an event to the tool. (* inherited from FPSBASE.WIP_LOT_HIST)

SHORT_JOB_ID

QTY_IN_CARR

QTY_IN_JOB

The number of units in the job. For example a batch tool with 5 carriers each with a 25 wafer lot would have 125 in the job. This is also important for non-batch tools where we have multiple lots in a carrier as the job might include all lots or only selected lots. (* inherited from FPSBASE.WIP_LOT_HIST)

CARRIERS_IN_JOB

Set to the number of carriers in the job. The value in WIP_EVENT_HIST represents the number of carriers which have started processing in this job *so far*, while the value in WIP_STEP_HIST (written after the job completes processing) represents the total number of carriers in the job. (* inherited from FPSBASE.WIP_LOT_HIST)

IS_UNRESERVE_ALLOWED

WEH_RESERVE_INST

MANL_RESERVE_INST

The actual time the lot was manually reserved by NextMove will be helpful especially for compliance and debugging to have these columns. In the absence of the Scheduler this will also determine the order to run the reserved lots. (* inherited from FPSBASE.WIP_STEP_FUTURE_SCHED)

RESERVE_INST

Time when the lot was reserved to the tool either by Scheduler or external or manual reservation. As opposed to dispatch, reserve is only in the FPS DWH and therefore can be automatically undone. (* inherited from FPSBASE.WIP_STEP_HIST)

BATCH_CRITERIA

Lots that can run on the same batch TOOL and have the same value of BATCH_CRITERIA can run together in a batch. Therefore this is a critical column for scheduling on batch tools. If BATCH_CRITERIA is not populated, Scheduler defaults to the assumption that any WIP with the same EST_MACHINE_RECIPE can be batched together. Keep in mind that many MESs have additional constraints on batching (for example, that all WIP in a batch has the same SCRIPT_ID) and these must be incorporated into BATCH_CRITERIA to ensure that the batches are allowed by the MES. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

PROCESS

Process defines what occurs at a step. Different steps can share the same process if they are identical. Process should normally determine allowed tools and recipe although it can be overridden by step, route, prd, lot, and experiment for exceptions. Each process is dynamically assigned to one or more eqp_type-process_family combinations with use_pct. One process_family is determined to be primary. If grouping is done correctly, a process should only be one eqp_group with no crossover. (* inherited from FPSINPUT.RTG_PROCESSES)

PROCESS_DISPLAY

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

EST_MACHINE_RECIPE

Estimated machine recipe what we estimate will be the machine recipe based on information from the Recipe Management System. It is used in combination with process for throughput calculations and setup change penalty calculations. It is not necessary to estimate for all processes since this is always used in combination however it needs to be NA rather than blank since it is part of the primary key of most THP tables. Hopefully when this is not NA it should match the actual machine recipe logged for each lot during processing. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

RQD_SETUP

Rqd_setup is determined by ovr_rqd_setup in RTG_TOOL_ASSIGNMENTS and use_process_as_rqd_setup and use_est_mach_rcp_as_rqd_setup from EQP_TYPES. The latter two columns allow us to easily specify for an eqp_type that setup times should be calculated by process or est_machine_recipe. For traditional setups that are a group of recipes we use ovr_rqd_setup. (* inherited from FPSBASE.WIP_LOT_HIST)

SCHED_TOOL

the tool from the first lot that scheduled (* inherited from FPSAPP.SCH_W_SCHED_DURABLE_INSPECT)

SCHED_START

The first start time for the durable to be used (* inherited from FPSBASE.RTG_DURABLE_FUTURE_SCHED)

HAS_LOT_ON_HOLD

CURR_PRIORITY_SORT

PLAN_PRIORITY

Permanent priority of the lot set in the MES generally by planning. (* inherited from FPSINPUT.WIP_EVENT_HIST)

CURR_PRIORITY_DISPLAY

PRIORITY_HTML_BG_COLOR

BEG_PROC_INST

time when the lot started processing on the main tool. (* inherited from FPSINPUT.WIP_STEP_HIST_MANUAL)

END_PROC_INST

time when the lot finished processing on the main tool. (* inherited from FPSINPUT.WIP_STEP_HIST_MANUAL)

EST_BEG_PROC_INST

EST_END_PROC_INST

COMP_INST

IS_COMPLETE

Boolean indicating whether the lot has completed processing. (* inherited from FPSINPUT.WIP_LOTS_OVR_EST_END_INST)

DESTINATION

DESTINATION_BAY

DELIVERY_METHOD

CURRENT_PROCESSING_LOT

CURR_PROCESS_STATE

CURR_PROCESS_STATE_DISPLAY

EXPECTED_STEP_ENT_INST

NMV_SORT_INST

IS_HIGHLIGHTED_PRTY

This flag indicates if this priority should be highlighted on the dashboard. When we sort all priorities by priority_sort all Y should be first followed by all N. (* inherited from FPSINPUT.WIP_PRIORITIES)

IS_QUEUE_TIMER

Flag to display queue timer icon in NextMove if lot is in queue time loop. (* inherited from FPSINPUT.MHS_DELIVERY_NEXT)

IS_N2

Flag to display N2 icon in NextMove if lot requires N2 (nitrogen purged) storage. In a future version we will allow more generic AMHS-related flags but this is specific to N2 for now. (* inherited from FPSINPUT.MHS_DELIVERY_NEXT)

DURABLE_CARRIER

The durable carrier ID of the durable required for this carrier to process. (* inherited from FPSINPUT.MHS_DELIVERY_NEXT)

DURABLE_LOCATION

The location of the durable. (* inherited from FPSINPUT.MHS_DELIVERY_NEXT)

IS_DURABLE_REQUIRED

NextMove flag indicating if the carrier requires a durable to process. (* inherited from FPSINPUT.MHS_DELIVERY_NEXT)

IS_DURABLE_AT_DESTINATION

NextMove flag indicating if the durable location is the same as the tool the carrier needs to process on. (* inherited from FPSINPUT.MHS_DELIVERY_NEXT)

STATION

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

STATION_TYPE

STATION_CLASS

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)

TIME_TO_START

TIME_TO_END

STATUS

CURR_PROCESS_STATUS

PREP_SEC

The time in seconds required to prepare the lot before track in. (* inherited from FPSINPUT.EQP_TYPES)

USE_DISP_INST

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)

IS_TW

Our standard filter to exclude test wafers is is_tw = N but what we really mean with this filter is to exclude any lots that do not add value for the facility. Lots which add value including sellable, development, and engineering and these lot groups should have is_tw set to N. Lots which do not add value are commonly grouped together and named "test wafers" which is why this flag is named is_tw. These include true test wafers like monitors and quals and dummies but also could include virtual lots used for training or testing, bare wafers, or really anything else including in the MES as a lot which does not add value. All of these lot groups should have is_tw set to Y. You could argue that the is_tw field might be more accurately named is_value or is_valuable or is_prod_eng_dev but is_tw is generally clear to most people. Plus it has the advantage that it is short which is nice given how frequently we use the is_tw = N filter. (* inherited from FPSINPUT.WIP_LOT_GROUPS)

IS_TW_USE

Applicable to TW routes only. If N (default), then this step is part of the process of building the test wafer. If Y, then this step is one at which the TW is used for process characterization by the owning module. (* inherited from FPSINPUT.RTG_ROUTE_STEPS)

LOT_TYPE

Lot_type is the base of the hierarchy that determines lot_family then lot_group. Ideally lot_type will come straight from the MES with little modification. (* inherited from FPSINPUT.WIP_LOT_TYPES)

HIDE_ON_TOOLS

TO_SETUP_TEXT_COLOR_HTML

TO_SETUP_BG_COLOR_HTML