Data Dictionary
>
FPSAPP Views
> FPSAPP.WIP_WAFER_HIST_LOOP
View FPSBASE.RTG_REF_MISSING_LOT_TOOL_ASGN
For records where the lot-route-step has at least one tool in RTAL/RTALP, this view lists all tools which are in RTG_TOOL_ASSIGNMENTS for the process but are not including in RTAL/RTALP. It is critical that these tools are not allowed for the lot-route-step so that only the tools in RTAL/RTALP are considered. For example, if RTA has ET11, 12, 13 as three primary tools and RTA_LOT has just ET11 as a primary tool for lot L1 then we must consider ET11 as the only allowed tool for this lot. Please note that for another lot which has no tools specified in RTAL/RTALP that we would consider all three tools as primary. Initially we included these "extra" tools (ET12 and ET13) in WIP_STEP_FUT_ASSIGNMENTS with rank I and the nice perm_rank_comment which still exists in this logic below. We found many cases where there could be a bunch of these "extra" tools and that including them slowed down our WSFA logic considerably for little benefit. Now these "extra" tools are in WFSA_UNIONS only and then are filtered out in WSFA_FILTERED. Therefore it does not really matter what we set as the perm_rank here but we set I or V for debugging purposes when previewing in WSFA_UNIONS. We refresh this separate table simply for speed purposes. By unioning this table in WSFA_UNIONS with the other four RTA tables we can partition by lot-route-step-tool which makes a filter by tool fast. Without this table we would have to partition by lot-route-step to check all tools which would make a filter by tool very slow because it would have to query all records.
|
Column |
Comment |
|---|---|
|
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) |
|
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) |
|
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) |
|
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) |
|
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) |
|
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) |
|
PERM_RANK_USER |
User or system who last updated permanent rank (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS) |
|
PERM_RANK_UPDATED_INST |
Datetime populated by trigger when permanent rank was last updated (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS) |
|
PERM_RANK_COMMENT |
Optional comment entered by user or system who last updated permanent rank (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS) |
|
EST_MACHINE_RECIPE |
Estimated machine recipe what we estimate will be the machine recipe based on information from the Recipe Management System. It is used in combination with process for throughput calculations and setup change penalty calculations. It is not necessary to estimate for all processes since this is always used in combination however it needs to be NA rather than blank since it is part of the primary key of most THP tables. Hopefully when this is not NA it should match the actual machine recipe logged for each lot during processing. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS) |
|
OVR_RQD_SETUP |
For eqp types where the setup is not the recipe or process, populate the setup with this value. Possible use cases are where multiple recipes or processes share the same setup or where we want to represent the setup with a shorter name than the long name of the recipe. This column has the ovr prefix because we have the ability to configure the eqp_type to use either the process or the recipe as the setup in EQP_TYPES. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS) |
|
BATCH_CRITERIA |
Lots that can run on the same batch TOOL and have the same value of BATCH_CRITERIA can run together in a batch. Therefore this is a critical column for scheduling on batch tools. If BATCH_CRITERIA is not populated, Scheduler defaults to the assumption that any WIP with the same EST_MACHINE_RECIPE can be batched together. Keep in mind that many MESs have additional constraints on batching (for example, that all WIP in a batch has the same SCRIPT_ID) and these must be incorporated into BATCH_CRITERIA to ensure that the batches are allowed by the MES. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS) |
|
STEP_ORDER |
The order in which the steps will be visited. Note that this is not the sequence number on the route. It is only for sorting within this table. This information may be used to determine upcoming sampling decision or deviations from standard routing. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT) |
|
RQD_QUAL_EVENT_ID |
Used when a recipe requires a certain qual in order to be allowed to run. Often multiple recipes will require the same qual. One example is in Litho where several recipes all require a certain track monitor to pass in order to be allowed to run. When the qual has not passed (either failed or expired) then the curr_rank will automatically be set to Q which indicates the recipe is permanently allowed but not currently qualified. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS) |
|
OVR_MAX_BATCH_SIZE_CARRIERS |
Override the default maximum batch size carriers from EQP_TYPES for this specific criteria (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS) |
|
OVR_MAX_BATCH_SIZE_UNITS |
Override the default maximum batch size units from EQP_TYPES for this specific criteria (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS) |
|
OVR_LABOR_ROLE |
Override labor role for this recipe (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS) |
|
OVR_LABOR_SEC_PER_BATCH |
Override labor batch time for this recipe (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS) |
|
OVR_LABOR_SEC_PER_CARR |
Override labor carrier time for this recipe (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS) |
|
OVR_LABOR_SEC_PER_UNIT |
Override wafer time for this recipe (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS) |
|
ASGN_PARM1 |
Four user-defined fields which can store anything the user would like to track relating to the assignment. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS) |
|
ASGN_PARM2 |
See ASGN_PARM1. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS) |
|
ASGN_PARM3 |
See ASGN_PARM1. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS) |