FPSBASE.WIP_LOTS_PLUS

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)

UPDATED_INST

Time when the record was updated according to the source data. Note this is not the time when the record was actually updated in this table - it will almost always be earlier. (* inherited from FPSINPUT.GEN_FACILITIES)

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)

REALTIME_ACTIVE_CODE

ACTIVE_CODE

BANK

Lots which are not on a route are considered in a bank and the bank name indicates why the lot is off route. Bank must be NA for lots which are on a route. Our standard filter for active lots is bank = NA. (* inherited from FPSINPUT.RTG_BANKS)

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)

ABORT_INST

When a lot has begun processing on a tool and an event with event_type of ABORT is logged, abort_inst captures the time of the abort. If multiple aborts happen to the same lot, the last abort_inst is used. See description of ABORT ect_state for more details. (* inherited from FPSBASE.WIP_STEP_HIST)

ACTIVE_ABORT_INST

ACTUAL_CH_USED

Here is where we can log the actual_ch_used directly if we know it. We have three ways to determine actual_ch_used in WIP_LOTS_REALTIME which populates WIP_STEP_HIST: 1) Log it directly in this colum for an event where the logged_entity is the main tool. 2) Log events to each of the chambers used in WIP_EVENT_HIST. 3) Log events to each of the chambers used in WIP_WAFER_HIST. (* inherited from FPSINPUT.WIP_EVENT_HIST)

ACTUAL_DURABLE_USED

Actual durable used as logged by the tool during processing of the lot. This can be a comma delimited string if multiple durables are used. (* inherited from FPSINPUT.WIP_EVENT_HIST)

ACTUAL_MACHINE_RECIPE

Machine recipe used to process the lot as logged during processing by the tool. (* inherited from FPSINPUT.WIP_EVENT_HIST)

ALLOWED_TOOL_LIST

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)

ASSIGNED_CARRIER

This column is needed for lot/carrier association for NextMove. When a lot is removed from its carrier to process on a tool, the now empty carrier can be moved independently of the lot. At this time the carrier field in WIP_LOTS_STATIC will be blank as the lot is no longer in the carrier however this column will keep track of the carrier to which the lot is assigned. This enables the ability to scan empty carriers on racks while the lot is processing on the tool. This column is strictly optional. All applications including NextMove will work as normal if this column is left blank. It should only be populated for sites using NextMove where empty carriers are allowed to leave the load port and remain assigned to lot(s) which are processing. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

BANK_IN_OR_OUT_INST

BEG_PROC_INST

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

BEG_PROC_INST_AUTO

BEG_PROC_INST_NOT_ABORTED

BEST_CURR_RANK_LONG_DETAILS

BEST_TOOL

BLOCK_OR_DOWN_REASON

BLOCK_SEC_COMP_FOR_WSF

BUNCH_ID

Chain lots together for Goal Planner (* inherited from FPSINPUT.WIP_LOTS_STATIC)

CANCEL_INST

Time when tool reservation or dispatch or perhaps even load or ready for the lot at the current step was cancelled. After cancel_inst the lot is available to any qualified tool immediately. (* inherited from FPSBASE.WIP_STEP_HIST)

CARRIER

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

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)

CARRIER_DISPLAY

CH_USED_DISP_SUFFIX

COMMON_STEP

A display-friendly field that groups similar steps together for purposes of viewing the entire line. Typically the only duplicates within a single route will be optional ordered steps in the same segment. But we will often have steps across routes that share the same common step even though exact step definition is not identical. (* inherited from FPSINPUT.RTG_COMMON_STEPS)

CREATED_INST

Time when the lot was created, either lot start or split. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

CRITICAL_RATIO

The critical ratio (days until due / days of CT left) for the lot (* inherited from FPSAPP.SCH_W_H_S_LOTS)

CURR_BAY

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

CURR_BUILDING

Current building of carrier. See column comment on BUILDING in FPSINPUT.MHS_BUILDINGS for more information. (* inherited from FPSINPUT.MHS_DELIVERY_NEXT)

CURR_PORT

CURR_PORT_MODE

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_BG_COLOR

CURR_PRIORITY_DISPLAY

CURR_PRIORITY_REASON

An optional description of why the priority is set as it is. This is typically shown as additional information on pages related to priority lots. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

CURR_PRIORITY_SORT

CURR_RANK

Current rank is dynamically calculated based on the permanent rank, temporary rank, external rank, and current conditions like tool status and current setup. Cases when it is greater than permanent rank include when the required setup does not match or when APC thread is not qualified. The only way it could be less are when either the temporary rank or external rank are set. Curr_rank is populated in WIP_EVENT_HIST for each event logged to a tool by trigger with the value from WIP_STEP_FUT_ASSIGNMENTS at the time of the event. (* inherited from FPSBASE.WIP_LOT_HIST)

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_STEP_EARLIEST_COMP_INST

CURR_STEP_EST_COMP_INST

CURR_STEP_EST_COMP_REASON

CUSTOMER

Customer who will accept shipment of the lot. Currently this only used for grouping and filtering but in the future we might want to allow a customer to view a Dashboard only including their products. (* inherited from FPSINPUT.GEN_CUSTOMERS)

DAYS_BEHIND

DEMAND_INST

Start of period when this qty of this planprd needs to finish. We automatically spread demand across each plan week in WIP_DEMAND_BY_WEEK which feeds WIP_FLUSH therefore this column can be the start of any time period less than or equal to plan week. It could be the demand for each shift or for each day or for each plan week but if the site has no preference then the easiest way to set this up is to write one row per plan week and let us spread across that week. It is important to note that we always spread across the plan week with our custom logic so even if this table is by day we might adjust it to another day within the same plan week. (* inherited from FPSINPUT.WIP_DEMAND)

DEST_STATION

The final destination the lot is required to move. Typically the reserved tool but also can be the scheduled tool if the client wants too, but this should be with caution as the scheduled tool can change (* inherited from FPSINPUT.MHS_DELIVERY_NEXT)

DIRECT_DELIVERY_BAY

DISPATCHED_BY

DISPATCH_INST

Time when the lot indicated in the MES that it will process on the tool. As opposed to reserve, dispatch cannot be automatically undone. (* inherited from FPSBASE.WIP_STEP_HIST)

DISP_SEC_COMP_FOR_WSF

DUE_INST

To indicate the due date for this futuer start lot (* inherited from FPSINPUT.WIP_STARTS)

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)

ECT_STATE

ECT state is the lowest level state of our Enhanced Cycle Time hierarchy and the value which is stored in WIP_LOTS_REALTIME and ECT_HIST. We can lookup all information about the ECT state including process state in ECT_STATE_DIAGRAM. (* inherited from FPSADMIN.WIP_ECT_STATES)

ECT_STATE_CHG_EVENT

ECT_STATE_CHG_INST

ECT_STATE_IF_WAIT

EET_SEC

End-to-end time in seconds (* inherited from FPSBASE.WIP_LOT_HIST)

EET_SEC_BATCH_FOR_TTS

EET_SEC_LOT_FOR_TTS

ENDED_SEC_FROM_THP

END_PROC_INST

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

END_PROC_INST_AUTO

ENGR_COMMENT

Special comments made by engineering about this lot. These comments are about the lot in general and not about a specific step. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

EQP_TYPE_OF_RS

EST_BEG_INST_TOOL

EST_BEG_INST_TOOL_FOR_TTS

EST_CH_USED

Estimate of which chambers will used to process this lot based on assignments and status (* inherited from FPSBASE.WIP_LOT_HIST)

EST_COMP_INST_BANK

EST_COMP_INST_CUM_MOVE

EST_COMP_INST_HOLD

EST_COMP_INST_IF_BEG_NOW

EST_COMP_INST_SCHED

EST_COMP_INST_SLOW

EST_COMP_INST_STAGING

EST_COMP_INST_TOOL

EST_DISP_INST_TOOL

EST_DISP_INST_TOOL_FOR_TTS

EST_DURABLE_USED

This field is populated with our estimate of what durable will be used based on information from the MES and/or Recipe Management System combined with the location and status of each durable. (* inherited from FPSBASE.WIP_LOT_HIST)

EST_END_INST_FROM_BEG

EST_END_INST_TOOL

EST_END_INST_TOOL_FOR_TTS

EST_END_TOOL_REASON

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)

EST_NEXT_BEG_INST_TOOL

EST_NEXT_BEG_TOOL_REASON

EST_RELEASE_INST

EST_SEC_TO_COMP_SLOW

EXPT_ID

Experiment identifier which indicates the lot will process differently that normal for its product on at least one step of the route. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

EXPT_INSTRUCTIONS

General instructions about the experiment performed on this lot. This is a long string field for display only. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

EXPT_VARIATION

Assigned to sibling lots to indicate which variation of the experiment will be performed on the lot. For example, variation 0 might get the normal recipe while variation 1 might get a different recipe then we can compare the different wafers in each split at a following measurement or test step. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

EXP_OUT_BY_ROUTE_DAYS_BEHIND

EXP_OUT_BY_ROUTE_INST

EXP_OUT_BY_ROUTE_START_WEEK

EXP_OUT_BY_ROUTE_WEEK

EXTL_DISP_INST

Time by when the external system recommends that the job must be dispatched. (* inherited from FPSBASE.WIP_STEP_FUTURE_SCHED)

EXTL_DO_NOT_MOVE

This column will decided whether NextMove will highlight to move or override it (* inherited from FPSBASE.WIP_STEP_FUTURE_SCHED)

EXTL_NEXT_STATION

EXTL_REQ_EXACT_DEST

This column will decided whether NextMove use alternates and station assignments or ignore them. (* inherited from FPSBASE.WIP_STEP_FUTURE_SCHED)

EXTL_RESERVE_INST

EXTL_SHOW_EXACT_DEST

This column will decided whether NextMove will show the destination Bay or the exact destination. (* inherited from FPSBASE.WIP_STEP_FUTURE_SCHED)

EXTL_START

Time by when the external system recommends that the job will begin processing. (* inherited from FPSBASE.WIP_STEP_FUTURE_SCHED)

EXTL_STATION_FOR_NEXT_STEP

EXTL_TIME_TO_NEXT_MOVE

Time provided by an external system to override the carrier time to move for racks. (* inherited from FPSBASE.WIP_STEP_FUTURE_SCHED)

EXTL_TRANSPORT_MODE

Name of the site transport mode which represents how material is moved from one location to another. (* inherited from FPSINPUT.MHS_EXTERNAL_TRANSPORT_MODES)

EXTL_TRANS_MODE_FOR_NEXT_STEP

EXTL_VEHICLE_SUB_ROUTE

EXTL_VEH_SUB_RT_FOR_NEXT_STEP

FACILITY_ENT_INST

FACILITY_OF_BANK

FACILITY_SEGMENT

Facility segment is the parent of common step and is used as the highest level grouping when we show WIP for a route group or the entire facility where we cannot use route segment. We would prefer somewhere between 8 and 20 facility segments. Typically we will have to define these (as opposed to route_segment which we will typically come from the MES). There is no RTG_FACILITY_SEGMENTS table because sorting of facility segments is determined by common_step_sort. A trigger on RTG_COMMON_STEPS ensures that facility segments are contiguous when the entire facility is sorted by common step. (* inherited from FPSINPUT.RTG_COMMON_STEPS)

FIRST_LOT_IN_JOB

The first lot in the job determined by the order of events. When this first lot logs the first tool event which is usually a reserve or dispatch then the job_id is created with only this lot. Then subsequent lots join this job. While we use job_id to identify lots that will process or are processing or processed together, first_lot_in_job is still a useful field. (* inherited from FPSBASE.WIP_LOT_HIST)

FIRST_UNIT_SEC

Time for one unit to process when the tool starts from a standby state. On a batch tool -- defined as a tool where all units process together and take the same time regardless of qty -- this is the time for the batch. See our complete throughput documentation for more details. (* inherited from FPSINPUT.THP_EXTERNAL)

FIRST_WFR_BEG_INST

Time when the first wafer of the job started processing. (* inherited from FPSBASE.WIP_STEP_HIST)

FIRST_WFR_END_INST

Time when the first wafer of the job finished processing. (* inherited from FPSBASE.WIP_STEP_HIST)

FUT_HOLD_TYPE

GBL_SORT

Sorting used for dispatching or allocation systems to sort future start lots based on priority, critical ratio, etc. (* inherited from FPSINPUT.WIP_STARTS)

HOLD_FOR

The user responsible for the hold lot. Note this is different than the user who put the lot on hold. This is the person who needs to address the hold and potentially release it. (* inherited from FPSINPUT.WIP_EVENT_HIST)

HOLD_FOR_DISPLAY

HOLD_GROUP

Grouping of hold_type for reporting purposes. (* inherited from FPSINPUT.WIP_HOLD_GROUPS)

HOLD_MODULE

HOLD_NOTE

Comment or note entered when the lot went on hold. Normally this should match the comment which was entered in the hold event. The logic to determine the hold note can get tricky when a subsequent comment event is logged to a lot already on hold because we do not know whether to update the hold note with the new comment or keep the comment from the original event that put the lot on hold. Our solution is to not update the hold_note by trigger with this comment event and leave the decision to our logic in WIP_LOTS_VERIFY. If you want to use the subsequent comment then populate it as the hold_note in WLV otherwise keep the original comment in WLV. Then our logic in CHK_WIP_LOTS_REALTIME is that if the hold_note written in WIP_LOTS_VERIFY differs from the hold_note populated by trigger while the hold_type and hold_for agree then we waive the normal 20 minute waiting period and update the hold_note immediately with a MISS-HOLDNOTE event. (* inherited from FPSINPUT.WIP_LOTS_VERIFY)

HOLD_PRTY_GROUP

This field determines the grouping of hold lots displayed on the Dashboard hold page. Typically the highlighted priorities will each be in their own group and all others will be in a group named OTHERS. We might want to separate low priority lots too. (* inherited from FPSINPUT.WIP_PRIORITIES)

HOLD_TYPE

Generally hold_type will come directly from the MES. (* inherited from FPSINPUT.WIP_HOLD_TYPES)

HOLD_TYPE_DISPLAY

INTERVAL_SEC

Unit_int_sec or batch_int_sec expected for the lot at the time of processing from our THP tables. (* inherited from FPSBASE.WIP_LOT_HIST)

IS_ALLOWED_FOR_SCHED

Lots on hold are only scheduled if this flag for the hold type is set to Y. By default this is N which means that lots on hold are not scheduled. (* inherited from FPSINPUT.WIP_HOLD_TYPES)

IS_COUNT_PRIORITY_PCT

This flag determines which priorities to include in our overall percentage of priority lots in the Dashboard spotlight. This is similar to is_highlighted_prty but it is possible that we might want to highlight a priority but not include it in the percentage. (* inherited from FPSINPUT.WIP_PRIORITIES)

IS_CURR_PRTY_HIGHLIGHTED

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)

IS_DURABLE_REQUIRED

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

IS_EVENT_AUTO

IS_EXPT_STEP

Flag set to Y if the experiment requires abnormal processing at this step. (* inherited from FPSBASE.WIP_LOT_HIST)

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)

IS_HOLD_DISPLAY

IS_IGNORE_WIP

This flag is in both RTG_OPERATION_FAMILIES and RTG_PROCESSES. If the value is Y for either the operation family or the process then we do not count WIP at the route-step towards the total for the facility. Typically this is set for staging operations. (* inherited from FPSINPUT.RTG_OPERATION_FAMILIES)

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)

IS_NEXT_MOVE_NEXT_STEP

IS_NMV_NOW

IS_NMV_PRIORITY

This flag indicates if this priority should be emphasized in NextMove (* inherited from FPSINPUT.WIP_PRIORITIES)

IS_NONSTD

Our column to indicate non-standard processing at the step. For example, an experiment or a chain that is only active at a particular step or set of steps and then goes back to being normal for the route. If an experiment is severe enough that it affects the final product and has to be planned separately then it will be its own prd or planprd. (* inherited from FPSBASE.WIP_LOT_HIST)

IS_PLAN_PRTY_HIGHLIGHTED

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_QUEUE_TIMER_EXPIRED

IS_RESERVED

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

IS_REWORK

Y indicates the lot is on a rework route after the event is logged. If a lot is reworked then returns to the main route and repeats some steps, is_rework will be N but we will count those steps as repeats. (* inherited from FPSINPUT.WIP_EVENT_HIST)

IS_SCHED

This flag indicates that lots in this group should be scheduled. This flag additionally causes TW groups to be included in WIP_STEP_FUTURE which they are normally not. (* inherited from FPSINPUT.WIP_LOT_GROUPS)

IS_STAGING_STEP

We expect large amounts of WIP and long cycle times at staging steps. We still calculate cycle time like any other step but the important difference is that lots currently at a staging step are not counted as normal coming lots to future steps. Instead we show them in a special column labeled From Staging. (* inherited from FPSINPUT.RTG_ROUTE_STEPS)

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)

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)

LAST_EVENT

LAST_EVENT_INST

LAST_EVENT_TYPE

LAST_HOLD_INST

Time when the lot was last placed on hold. (* inherited from FPSBASE.WIP_FLUSH)

LAST_KNOWN_BAY

LAST_KNOWN_BUILDING

LAST_KNOWN_DURABLE_LOC

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

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)

LAST_PROCESS_TOOL

For rework and scrap events we automatically look up the last process tool for the lot. Process tool is determined by the process class of the tool and excludes metrology and support tools. It is likely this was the cause of the rework or scrap although by no means certain. (* inherited from FPSBASE.WIP_LOT_HIST)

LAST_PROCESS_TOOL_BEG_INST

Time when the lot finished processing on the previous tool (excluding metrology). (* inherited from FPSBASE.WIP_LOT_HIST)

LAST_RELEASE_INST

Time the lot was previously released from hold. (* inherited from FPSBASE.WIP_STEP_HIST)

LAST_STEP_CURR_PRTY

The last step where the current lot_priority applies. After this step we assume the lot will return to its plan_priority. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

LAST_TOOL

For rework and scrap events we automatically look up the last tool where the lot processed including metrology tools. (* inherited from FPSBASE.WIP_LOT_HIST)

LAST_TOOL_BEG_INST

Time of the last event on the previous tool (including metrology) for the lot occurred. (* inherited from FPSBASE.WIP_LOT_HIST)

LAST_WFR_BEG_INST

Time when the last wafer of the job started processing. (* inherited from FPSBASE.WIP_STEP_HIST)

LAST_WFR_END_INST

Time when the last wafer of the job finished processing. (* inherited from FPSBASE.WIP_STEP_HIST)

LINE_SECTION

Large grouping of the line, e.g. FEOL, BEOL, Cu, etc. There should be only a handful of values for the entire facility - or if the facility only has one section then we can leave this column blank. (* inherited from FPSINPUT.RTG_LINE_SECTIONS)

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_INST

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

LOCATION_TYPE

LOGICAL_RECIPE

Used for infomational purpose and is populated if known otherwise it will match the recipe. (* inherited from FPSINPUT.WIP_EVENT_HIST)

LOTS_IN_JOB

Set to the number of lots in the job. The value in WIP_EVENT_HIST represents the number of lots 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 lots in the job. (* inherited from FPSBASE.WIP_LOT_HIST)

LOT_FAMILY

Lot_family is a grouping of lot_type which is mainly use for goal planning. We set goals by family and are allowed to switch goals for different lots of different types within the family. We also report goal performance by family. (* inherited from FPSINPUT.WIP_LOT_FAMILIES)

LOT_GROUP

Lot_group is a grouping of lot_family and is the highest grouping in the lot type hierarchy. There should be only a few values for lot_group, i.e. Prod, Dev, TW. We group WIP and moves by lot_group on the dashboard and we group cycle time calculations by lot_group so this is an important field. (* inherited from FPSINPUT.WIP_LOT_GROUPS)

LOT_SUBTYPE

This is an optional field to add a level to lot_type. This field is not used in logic but is displayed on hold and scrap pages of Dashboard. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

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)

LOT_TYPE_SORT_ORDER

MADE_CASCADE

MAIN_ROUTE

Primary route used by the prd. Excludes rework and alternate routing. We allow this column to be null in WIP_LOTS_VERIFY because we may not be certain what the main route is when we fix for missed events. In that event we trust the WIP_EVENT_HIST triggers has loaded the correct information into WIP_EVENTS_CURR_STEP. (* inherited from FPSINPUT.WIP_EVENT_HIST)

MAIN_ROUTE_FAMILY

Route family of the main route for the prd of the lot. (* inherited from FPSINPUT.WIP_OVR_OPER_MOVES_HIST)

MAIN_ROUTE_GROUP

Route group of main route. Often referred to as technology. (* inherited from FPSBASE.WIP_FLUSH)

MAIN_RT_COMMON_STEP

MAIN_RT_OPERATION

MAIN_RT_OPER_ENT_INST

MAIN_RT_PROCESS

MAIN_RT_PROC_STATE

MAIN_RT_REMAINING_DETAILS

MAIN_RT_REMAINING_PCT

On the Lots search page in the Dashboard 5.4, we show a bar from the time the lot started in the current facility until its due date. On this bar we show a red pace arrow as we do on all of our fill-up bars to show where the lot should be now to be on schedule based on the commit cycle time from the start to the due date. This red arrow is at a time we call pull_point_pace_inst and in order to calculate this time, we first calculate route_remaining_pct. Route_remaining_pct is the commit cycle time remaining divided by total commit cycle time. Then pull_point_pace_inst is that percentage remaining from facility_ent_inst to pull_point_inst. The calculation is facility_ent_inst + ((pull_point_inst - facility_ent_inst) * route_remaining_pct / 100). (* inherited from FPSBASE.WIP_LOTS_REALTIME)

MAIN_RT_SEQ_NUM

MAIN_RT_STEP

When lot is on a rework or alternate route, this is the step where it will return to the main route. We use this for planning purposes so we can calculate remaining steps. We allow this column to be null in WIP_LOTS_VERIFY because we may not be certain what the main route step is when we fix for missed events. In that event we trust the WIP_EVENT_HIST triggers has loaded the correct information into WIP_EVENTS_CURR_STEP. (* inherited from FPSINPUT.WIP_EVENT_HIST)

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)

MEAS_RESULT

Result of measurement. For facilities not using FPS Sampling this value is for display purposes only and can be pass/fail or a number or anything. For facilities using FPS Sampling this field is used to dynamically adjust the sampling rules and must be a letter grade A-F. (* inherited from FPSINPUT.WIP_EVENT_HIST)

MHS_STATE

MHS_STATE_CHG_INST

MHS_STATE_CHG_STATION

MPU

MPU is a commonly used abbreviation which stands for minutes per unit. It is often referred to as MPW which for minutes per wafer but MPU is better because the unit is not always wafer. (* inherited from FPSBASE.WIP_LOT_HIST)

NEXT_BEG_INST_TOOL_FOR_TTS

NEXT_STATION

NMV_SORT_INST

NMV_USE_DISP_INST

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

NUM_SIBLING_LOTS

A count of other lots that were also split from the same parent. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

NUM_WFRS_BEG

NUM_WFRS_ENDED

OPERATION

Operation is usually the primary level of routing in the MES and the level where the facility typically reports moves. FPS only allows one tool per step so our step is a lower level of routing than operation although both may be the same if the MES only allows one tool per operation. Note that because operation can include multiple steps and therefore multiple process families that we cannot have any association to equipment by operation. (* inherited from FPSINPUT.RTG_OPERATIONS)

OPERATION_DESCRIPTION

OPERATION_DISPLAY

All xxx_display columns are used in place of the column xxx for display purposes. The values of these columns can be changed at any time without having to worry about other tables referencing it. (* inherited from FPSINPUT.RTG_OPERATIONS)

OPERATION_FAMILY

Grouping of route-step that is completely dependent on routing information from MES. The primary use of this field is for filtering on Operations Dashboard. Unfortunately for our database structure and naming convention, this field no longer has any link to operation. This is because operation is used primarily for Oper Moves and it is normal for steps in an operation to belong to multiple MES routing groups. For example, a sink step and a furnace step and a measurement step are in the same operation but each step belongs to the appropriate sink/furnace/measurement MES routing groups which we store in operation family. Since Dashboard already uses both operation and operation_family extensively and independently, we decided not to rename either column but simply remove the link. Please note that operation family is similar to process family and in fact they are often the same. The key differences are that operation family has nothing to do with equipment and that comes straight from ETL with no complex logic. Process family is the link between routing and equipment for the Operations Dashboard and therefore has complex logic. (* inherited from FPSINPUT.RTG_OPERATION_FAMILIES)

OPER_ENT_INST

ORDER_ID

The customer order to which this lot belongs. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

ORIG_DUE_INST

Original Due Date of this lot (* inherited from FPSINPUT.WIP_STARTS)

ORIG_PLAN_OUT_INST

Original plan out date for this lot in the current facility which was set for the lot at its creation or when it entered this facility. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

OUT_INST_EXPECTED

OVR_IS_QUEUE_ALLOWED

We stop lots from starting the first step in a queue timer when WIP is too high but this flag allows this specific lot to start despite this. Use for priority lots or sendahead lots or when we want to trickle lots into the timer. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

OVR_STEP_COMP_INST

Specify a time when the lot will complete the step. We will use this mainly for banks and staging steps with a release plan. For steps that require processing on a tool, please use ovr_est_end_inst instead. (* inherited from FPSINPUT.WIP_LOTS_VERIFY)

PARENT_LOT

The parent lot should ideally be the original parent but it could be the most recent parent if multiple splits have occurred. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

PAUSE_INST

When a lot has begun processing on a tool and an event with event_type of PAUSE is logged, pause_inst captures the time of the pause. If multiple pauses happen to the same lot, the last pause_inst is used. See description of PAUSE ect_state for more details. (* inherited from FPSBASE.WIP_STEP_HIST)

PERM_RANK

Permanent rank is typically loaded by ETL from a combination of the MES, recipe management system, and existing preference logic already used at the site. Possible values are in FPSADMIN.RTG_PERM_RANKS. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

PLANPRD

Planning product used for all planning purposes. All lots with the same planprd are interchangeable to ship to the customer regardless of their prd, route, technology, wafer size, etc. For detailed information on prd vs. planprd see table comments in RTG_PLANPRDS. (* inherited from FPSINPUT.RTG_PLANPRDS)

PLAN_OUT_INST

Current planned out date for this lot in the current facility. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

PLAN_PRIORITY

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

PLAN_PRIORITY_BG_COLOR

PLAN_PRIORITY_DISPLAY

PLAN_PRIORITY_SORT

PRD

Prd determines the route which is used to process the lot in the facility and what tools, recipes, durables, etc. can be used at each step. Prd also determines the next facility for the lot when it finishes its route. For detailed information on prd vs. planprd see table comments in RTG_PLANPRDS. (* inherited from FPSINPUT.RTG_PRDS)

PREP_SEC

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

PREV_END_PROC_INST

End_proc_inst of the previous job on the tool before the job including this lot. Subtracting this from the end_proc_inst of this job gives us the end-to-end time (EET) which is critical for throughput calculations. (* inherited from FPSBASE.WIP_LOT_HIST)

PREV_RECIPE

Recipe of the previous job on the tool before the job including this lot. Used in combination with prev_process to determine if this job cascaded and if it required a setup change. (* inherited from FPSBASE.WIP_LOT_HIST)

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)

PROCESS_FAMILY

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

PROCESS_GROUP

Process group is the critical field where tools and processes come together for the purposes of Scheduler. Process group is in both EQP_TOOLS for the tools and in RTG_PROCESSES for processes. Ideally all tools that run the same set of processes with no crossover including back-up and emergency tools would be in the same process group but it is important to note that this is not technically required for Scheduler as long as all process groups are in the same sched group. (* inherited from FPSINPUT.RTG_PROCESS_GROUPS)

PROCESS_MODULE

WIP_MODULE is used to credit moves and set goals. See comments on the module column in GEN_MODULES for info on this column and how it relates to eqp_module and mnt_module. (* inherited from FPSBASE.RTG_ROUTE_STEPS_PLUS)

PROCESS_MODULE_DISPLAY

PROC_STATE_DASH

PROC_STATE_DASH_DETAILS

PROC_STATE_DASH_DISPLAY

PROC_STATE_DASH_CHG_INST

PROC_STATE_DASH_SORT_ORDER

PROC_STATE_EVENT_ONLY

The proc_state_event_only column is the process state derived exclusively from lot and wafer events. This is the parent of process_state and it is equal to process_state when the value is ENDED, PROC, PAUSE, ABORT, DISP, and STUCK because these process states come only from events. When the value is HOLD then we look at the hold groups to determine if the process state is HOLD or LONGH. And when the value is WAIT then we look at the complex ect_state_if_wait column to determine if the process state is STG, INHIB, BLOCK, DOWN, WAIT1, WAIT2, or WAIT3. The link between process_state and proc_state_event_only in the ECT diagram is not used in the logic in WIP_LOTS_REALTIME or GET_PROC_STATE_EVENT_ONLY but the values should always match. (* inherited from FPSBASE.WIP_LOTS_REALTIME)

PROC_STATE_SCH

PROC_STATE_SCH_DETAILS

PROC_STATE_SCH_DISPLAY

PROC_STATE_SCH_CHG_INST

PROC_STATE_SCH_SORT_ORDER

PROCESS_SUBFAMILY

Route step family is used for the Dashboard to separate processes in a process family based on shared but limited assignments. It is also the base for GP subfamily. (* inherited from FPSBASE.RTG_ROUTE_STEPS_PLUS)

PROC_PORT

PROC_PORT_MODE

PRTY_CTM_FACTOR

Factor to multiply cycle time for this priority group compared to other groups if not known. For example, if this factor is 1.5 and we know the CTM is 6 hours for another priority group whose factor is 1.0 then we would estimate it to be 9 hours for this group. (* inherited from FPSINPUT.WIP_PRTY_CTM_GROUPS)

PRTY_CTM_GROUP

This is one of the primary keys of our CTM tables. We use this group rather than the priority because we often have several different priorities which are close and are expected to have the same cycle time. (* inherited from FPSINPUT.WIP_PRIORITIES)

PULL_POINT_DETAILS

PULL_POINT_DETAILS_W_FILLIN

PULL_POINT_INST

PULL_POINT_INST_W_FILLIN

PULL_POINT_PACE_DETAILS

PULL_POINT_PACE_INST

PULL_POINT_START_WEEK

PULL_POINT_WEEK

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)

QTY_MEAS

Quantity of units measured at this metrology step. This is less than or equal to the qty_in_job. The standard case is where we have a 25 wafer lot so the qty_in_job is 25 but we only measure 3 wafers on the metrology tool so qty_meas is 3. (* inherited from FPSINPUT.WIP_EVENT_HIST)

QUEUE_STATUS

Display field showing the current status of this lot within a queue time sequence. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

QUEUE_TIMER_DESCRIPTION

QUEUE_TIMER_DISPLAY

QUEUE_TIMER_REMAIN_SEC

READY_INST

Time when the lot was ready to be processed (e.g. after recipe downloaded). (* inherited from FPSBASE.WIP_STEP_HIST)

RECIPE_DISPLAY

RECIPE_VERSION

This field is for historical tracking purposes only and is not used in any FPS calculation. (* inherited from FPSINPUT.WIP_EVENT_HIST)

REMAINING_HOLD_SEC

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)

RESERVE_SOURCE

RESERVE_TOOL

RN_BY_TOOL_FOR_TTS

ROUTE_DISPLAY

ROUTE_OF_PRD

ROUTE_SECTION

A large grouping of route steps used for line balance and should be set to contain at least a week of steps based on cycle time. Line balance uses this grouping instead of segment so that it can be configured independently from segment which is used in the Dashboard for display purposes, but they can also be set the same if desired. The section should be large in order to minimize the impact of short-term WIP distribution changes on step WIP targets because line balance calculates step WIP targets based on the WIP currently in each section. (* inherited from FPSINPUT.RTG_ROUTE_STEPS)

ROUTE_SEGMENT

Route_segment allows for clear hierarchical segment organization for Segment Summary and Line Viewer on Dashboard. This is often referred to as stage and typically will come from the MES (as opposed to facility_segment which we will typically have to define for our purposes). We recommend that all routes in the same route family have the same route segments in the same order so that the Line Viewer by route family will be consistent but if this is not the case then we approximate the order as best we can. (* inherited from FPSINPUT.RTG_ROUTE_STEPS)

ROUTE_SEGMENT_ENT_INST

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)

RQD_SETUP_DISPLAY

RT_STEP_BANK_ENT_INST

If the lot is at a step then this is the time when it entered the current route-step. If the lot is at a bank then this is the time it entered the current bank. (* inherited from FPSBASE.WIP_LOTS_REALTIME)

SAH_CHAMBERS

Send ahead chambers (* inherited from FPSINPUT.WIP_LOTS_STATIC)

SAH_TOOL

Send ahead tool (* inherited from FPSINPUT.WIP_LOTS_STATIC)

SAH_TYPE

Send ahead type is primarily used to set lot_priority. We often want to prioritize a sendahead lot only to the metrology tool so we can get metrology as soon as possible and start processing more lots. (* inherited from FPSINPUT.WIP_SAH_TYPES)

SCHEDULE_STATUS

SCHEDULE_STATUS_COLOR

SCHEDULE_STATUS_OFFSET_DAYS

If the expected out inst is more than this many days after the pull point (a.k.a. due or demand) inst then we consider the lot to be late. We also consider it late if it is in the next plan week even if less than this number of days behind. (* inherited from FPSINPUT.GEN_FACILITIES)

SCHED_CARRIER

SCHED_CARRIERS_IN_JOB

SCHED_CH_TO_USE

Please note that the Scheduler often populates this with M which indicates the main tool therefore we often should filter out a value of M when using this value since that it not a valid chamber combination. When this is populated with any value other than M then we use this as est_ch_used rather than calculating with GET_CH_ALLOWED_STATUS or GET_CH_PATH_STATUS. (* inherited from FPSBASE.WIP_STEP_FUTURE_SCHED)

SCHED_DISP_INST

SCHED_DURABLE

SCHED_END

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)

SCHED_GROUP_BEST_TOOL_IF_OTHER

SCHED_QTY_IN_JOB

SCHED_START

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

SCHED_WAIT_ETP_STATE

The only way for ETP to know that the Scheduler is asking to wait is for the Scheduler to populate this column indicating that the lot is scheduled but waiting for a particular reason. This column must be an exact etp_state value starting with SBY-IW so it has a check constraint and a foreign key on ETP_STATE_DIAGRAM. (* inherited from FPSBASE.WIP_STEP_FUTURE_SCHED)

SCH_CRITICAL_RATIO_OVR

This column allows for a user defined CRITICAL RATIO to be used by the scheduler. If this value is populated, it will be used by the scheduler instead of any value of CRITICAL RATIO that would be calculated by the FPS sytems. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

SCH_DAYS_LATE_OVR

Our normal days late calculation uses due_inst and changes over time as that date approaches. This value overrides that normal calculation with a fixed number of days late that does not change over time. A positive value means the lot is behind schedule. This only applies to the Scheduler. The normal use case is for important development lots where we do not really have a due date but we just want them to always count as two days late putting them ahead of normal lots that are less than two days late but behind normal lots that are more than two days late. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

SEC_BEG_PROC_INST

Time when processing on secondary tool started. (* inherited from FPSBASE.WIP_STEP_HIST)

SEC_END_PROC_INST

Time when processing on secondary tool finished. (* inherited from FPSBASE.WIP_STEP_HIST)

SEC_QTY

Quantity of units in the lot according the sec_qty_unit defined for the facility. See the column comment for the qty column for details and examples. (* inherited from FPSINPUT.WIP_EVENT_HIST)

SEC_TOOL

SEQ_NUM

Sequence number of step in route (* inherited from FPSINPUT.RTG_ROUTE_STEPS)

SHOULD_AUTO_HIDE

If the flag is set to Y then the module will be hidden on the Dashboard even if it has active WIP or moves. (* inherited from FPSINPUT.GEN_MODULES)

SHOULD_HIGHLIGHT_AGE_FOR_HOLD

SPLIT_FROM_LOT

STEP_ENT_INST

Time when the lot entered the step. (* inherited from FPSBASE.WIP_LOT_HIST)

STEP_HOLD_SEC

STEP_HOLD_SEC_CURR_DAY

STEP_HOLD_SEC_CURR_SHIFT

Time on hold at the current step during the current shift (* inherited from FPSBASE.WIP_STEP_HIST)

STEP_HOLD_SEC_RELEASED

STEP_NUM_HOLDS

STEP_SEC_CURR_DAY

STEP_SEC_CURR_SHIFT

STEP_SEC_FOR_CRIT_RATIO_TO_EOL

STEP_SEC_FOR_DAYS_BEH_TO_EOL

STEP_SEC_FOR_WSF_TO_EOL

STEP_SEC_NOHLD_RT_WSF_TO_EOL

TCT_SEC

Theoretical cycle time in seconds (* inherited from FPSBASE.WIP_LOT_HIST)

TCT_SEC_FOR_TTS

TIME_TO_NEXT_MOVE

TIME_TO_NEXT_MOVE_OVR

This column allows for sites to control the NextMove countdown timers. Normally we do not populate this but for certain use cases clients may want to change this value based on certain criteria. (* inherited from FPSINPUT.MHS_DELIVERY_NEXT)

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)

TOOL_FOR_NEXT_STEP

TOOL_FOR_TTS

TTS for tool is greatest(last start plus EET of last start, data_date). TTS for first lot not started is the same as the TTS for tool but we need to store TTS for tool because tool might not have any reserved lots. TTS for subsequent lots cums the EET of each lot after the first lot. (* inherited from FPSBASE.WIP_STEP_FUTURE_SCHED)

TRANSPORT_MODE

Name of the standard FPS transport mode which represents how material is moved from one location to another. (* inherited from FPSINPUT.MHS_EXTERNAL_TRANSPORT_MODES)

TRANSPORT_MODE_FOR_NEXT_STEP

TTS_BAY

Bay of the tool where this carrier is reserved or scheduled. (* inherited from FPSINPUT.MHS_DELIVERY_NEXT)

TTS_INST_FOR_NEXT_STEP

TTS_PROCESS_FAMILY

TTS_SOURCE

TW_RECYCLE_COUNT

Only applicable to TW lots. This is the number of times the test wafers have been reused (* inherited from FPSINPUT.WIP_LOTS_STATIC)

TW_USE_PURPOSE

Brief definition of the use of test wafers at this step (ex: Etch Rate or Nitride Dum). (* inherited from FPSINPUT.RTG_ROUTE_STEPS)

VEHICLE_SUB_ROUTE

Sub route associated to a cart or carts within a vehicle route. (* inherited from FPSINPUT.MHS_VEHICLE_SUB_ROUTES)

VEHICLE_TYPE

VERIFY_PARM1

Nine user-defined fields which can store anything the user would like to track relating to the lot and its status. Often this is a value needed for tool assignments ETL like a rework parameter. These columns will have the capability to be displayed in the Dashboard lot search and lot popup tables if configured in DASH_C_CATEGORY_TABLE_COLS. (* inherited from FPSINPUT.WIP_LOTS_VERIFY)

VERIFY_PARM2

See VERIFY_PARM1. (* inherited from FPSINPUT.WIP_LOTS_VERIFY)

VERIFY_PARM3

See VERIFY_PARM1. (* inherited from FPSINPUT.WIP_LOTS_VERIFY)

VERIFY_PARM4

See VERIFY_PARM1. (* inherited from FPSINPUT.WIP_LOTS_VERIFY)

VERIFY_PARM5

See VERIFY_PARM1. (* inherited from FPSINPUT.WIP_LOTS_VERIFY)

VERIFY_PARM6

See VERIFY_PARM1. (* inherited from FPSINPUT.WIP_LOTS_VERIFY)

VERIFY_PARM7

See VERIFY_PARM1. (* inherited from FPSINPUT.WIP_LOTS_VERIFY)

VERIFY_PARM8

See VERIFY_PARM1. (* inherited from FPSINPUT.WIP_LOTS_VERIFY)

VERIFY_PARM9

WAFER_SIZE

If the facility only has one wafer size then this column should be null in both RTG_PRDS and EQP_TYPES. If the facility has more than one wafer size then a value of null in EQP_TYPES means that those tools can run all wafer sizes. See column IS_ANY_WAFER_SIZE for details. (* inherited from FPSINPUT.GEN_WAFER_SIZES)

WAFER_SIZE_DISPLAY

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

WAIT_SEC_COMP_FOR_WSF

WAIT_SEC_TO_SCHED

The lot may be scheduled but must not be allowed to dispatch or start until this number of seconds has elapsed. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

WAIT_TO_SCHED_REASON

WAIT_TO_SCHED_REASON_ABORT

WLRT_CREATED_INST

WSFS_JOB_ID