FPSADMIN.NMV_P_RESERVED_SCHED_LOTS

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)

SCHED_GROUP

This is the grouping of tools and processes which the FPS Scheduler schedules together. Since this is a parent of tool via tool->process_group and a parent of process via process->process_group, by definition each tool and each process can only be in one sched group. We need all related tools and processes to be in the same sched group for efficient scheduling. One example is sinks and furnaces because of queue times and batching. Another example is for smaller facilities like Assembly or Test where we might schedule the entire facility together. (* inherited from FPSINPUT.RTG_PROCESS_GROUPS)

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)

LOT

A lot is a group of units that process together. Usually lot_id or lot_number in MES. All units in a lot are in the same carrier but there may be multiple lots in a carrier. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

ROUTE

Route that has threading requirements (* inherited from FPSINPUT.RTG_STEP_THREADING)

STEP

A single processing step within a route representing a single tool visit. Step is often a very complex string and should rarely be displayed. Instead we should use process_display. (* inherited from FPSINPUT.RTG_ROUTE_STEPS)

CARRIER

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

CARRIER_DISPLAY

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)

CURR_STATION

See column comment on STATION in FPSINPUT.MHS_STATION_ALTERNATES 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)

TOOL_BAY

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)

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)

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)

QTY

Quantity of units in the lot according the qty_unit defined for the facility. It is required for all lots in each facility to have their qty defined in the same units therefore the change in the unit is critical to defining the facility. For example, a pretest facility might have a sort step in the middle where we learn the qty of die. Prior to this step we know only the wafer qty but after this step we know both wafer and die. Since wafer is the only qty we know throughput the flow then wafer must be defined as the qty unit for this facility. Die can then be populated as sec_qty when it is known. Similarly the wafer saw facility might have a step in the middle where we cut the wafers into die. After this step we no longer know the number of wafers which means that die must be the qty unit for this facility and wafers can be the sec_qty prior to the saw step. Please note that a lot with qty of 0 is allowed but only if the sec_qty is greater than 0. This is unusual but one case is where we know the wafers will be scrapped but cannot be scrapped quite yet. (* inherited from FPSINPUT.WIP_EVENT_HIST)

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)

EXPECTED_STEP_ENT_INST

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)

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)

IS_HOLD

This field indicates the lot is on hold after the event is logged. In other words, this will always be Y if is_hold_start is Y and always N if is_hold_end is Y. (* inherited from FPSINPUT.WIP_EVENT_HIST)

PLAN_PRIORITY

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

CURR_PRIORITY

The priority at the current step. As the lot moves along the route after LAST_STEP_CURR_PRTY it will revert to PLAN_PRIORITY. For example, timelink or sendahead priority is only temporary. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

CURR_PRIORITY_DISPLAY

CURR_PRIORITY_SORT

CURR_PRIORITY_BG_COLOR

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)

CURR_PROCESS_STATE

CURR_PROCESS_STATE_SORT_ORDER

CURR_PROCESS_STATE_DISPLAY

CURR_BEG_PROC_INST

CURR_END_PROC_INST

EST_DISP_INST

EST_BEG_PROC_INST

EST_END_PROC_INST

EST_NEXT_JOB_BEG_INST

COMP_INST

DESTINATION

DESTINATION_BAY

NMV_SORT_INST

TIME_TO_NEXT_MOVE

IS_UNLOADED

Boolean indicating whether the lot has been unloaded. (* inherited from FPSINPUT.WIP_LOTS_OVR_EST_END_INST)

IS_READY_TO_UNLOAD

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)

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)

PROCESS_FAMILY

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

PREP_SEC

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

NMV_USE_DISP_INST

A flag that will help decided whether to use the start time or dispatch time. (* inherited from FPSINPUT.EQP_TYPES)

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)