FPSAPP.DASH_P_WIP_LOTS_BANK

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)

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)

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)

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)

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)

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)

BEG_PROC_INST

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

BLOCK_OR_DOWN_REASON

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)

CARRIER_DISPLAY

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)

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_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_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

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)

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)

END_PROC_INST

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

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

Each tool is assigned an EQP_TYPE and all tools in the same type are identical meaning that they should run at the same throughput when running the same process with the same chamber type count. We also expect similar availability since these tools are identical. However tools in the same EQP_TYPE may have different chamber configurations and may run different groups of processes. (* inherited from FPSINPUT.EQP_TYPES)

EST_BEG_INST_TOOL_FOR_TTS

EST_DISP_INST_TOOL_FOR_TTS

EST_END_INST_TOOL_FOR_TTS

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)

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_WEEK

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_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_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_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)

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)

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)

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_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)

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

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_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_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_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_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_HOLD_INST

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

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_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_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)

LOGICAL_RECIPE

Used for infomational purpose and is populated if known otherwise it will match the recipe. (* inherited from FPSINPUT.WIP_EVENT_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_ROUTE_SEGMENT

MAIN_RT_COMMON_STEP

MAIN_RT_PROCESS

MAIN_RT_PROC_STATE

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)

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)

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)

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)

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)

OUT_INST_EXPECTED

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)

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_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

PROCESS_STATE

Process state is the most commonly used level of our Enhanced Cycle Time hierarchy. This displays on Dashboard, Scheduler, Cycle Time Analyzer, and Finished Lot Cycle Time Reporter. Process state is the parent of ECT state, however, there is configuration for when to show the process state of Reserved in each application which is done in WIP_ECT_STATES. (* inherited from FPSADMIN.WIP_PROCESS_STATES)

PROCESS_STATE_DETAILS

PROCESS_STATE_DISPLAY

PROCESS_STATE_INST

PROCESS_STATE_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

PULL_POINT_DETAILS

PULL_POINT_INST

PULL_POINT_INST_W_FILLIN

PULL_POINT_DETAILS_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)

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)

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)

ROUTE

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

ROUTE_DISPLAY

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)

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)

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

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_QTY_IN_JOB

SCHED_START

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

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

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

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)

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_NUM_HOLDS

STEP_SEC_CURR_DAY

STEP_SEC_CURR_SHIFT

THP_IGNORE_REASON

TIME_TO_NEXT_MOVE

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)

TTS_BAY

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

TTS_PROCESS_FAMILY

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)

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)

VEHICLE_SUB_ROUTE

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

VEHICLE_TYPE

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)

WSFS_JOB_ID