Data Dictionary
>
FPSAPP Views
> FPSAPP.WIP_WAFER_HIST_LOOP
View FPSAPP.DASH_REF_P_TOOL_WIP_METRICS
Base logic for NextMove Bay Performance pages. Metrics inlude; - Tool and Bay Curr WIP - Tool and Bay Completes - Tool and Bay Completes and wip targets - Tool and Bay Completes Pace - Tool and Bay Compliance Current WIP is sum of; -Any wip that has sched state ended, processing, reserved ... will be assigned to that tool -Any other WIP will be split between the allowable tools (rank P or A) in fab
|
Column |
Comment |
|---|---|
|
FACILITY |
Facility is included in almost every join in the DWH so this represents a definitive split. A route must have all steps on tools in the same facility. A tool must process all lots in the same facility. If your site has multiple buildings where lots run on routes using tools in multiple buildings then everything should be one facility. For example, multiple Fab buildings. But if your site has independent facilities like Fab and Test and Assembly where lot may progress from one to the next but on different routes then these should be different facilities. Since this column is in virtually every table it is critical that the value here is exactly matches what is in the MES if the MES has facility. Use facility_display for the display friendly name displayed in applications. See site_name comment for client/site/facility example. (* inherited from FPSINPUT.GEN_FACILITIES) |
|
TOOL |
Tool is generally just the main tool. The exception is when different entities on the tool run completely independently and it is physically impossible to run wafers of the same lot across multiple entities. In this exception case, we may want to assign the entities to different eqp_types and therefore we should define each entity as a tool. Please note that when we do this there is no indication whatsoever that these different entities are on the same tool. (* inherited from FPSINPUT.EQP_TOOLS) |
|
BAY |
A bay is a physical area within the building. The bay is important for estimating travel time for a carrier to reach its destination as we usually store these estimates as a matrix of bay-to-bay and assume that the estimated time from any location within one bay to any location within another bay is approximately the same. (* inherited from FPSINPUT.MHS_BAYS) |
|
GOAL_WIP_PCT_TO_TGT_BAY_PERF |
The plus / minus percentage of target WIP that is considered acceptable in the Bay Performance NMV pages. EG 20% gives acceptable WIP range of 80 to 120 on a target of 100. (* inherited from FPSINPUT.GEN_SITE) |
|
SHIFT_TGT_COMP |
|
|
SHIFT_CURR_COMP |
|
|
SHIFT_COMP_PACE |
|
|
SHIFT_TGT_COMP_BAY |
|
|
SHIFT_CURR_COMP_BAY |
|
|
SHIFT_COMP_BAY_PACE |
|
|
SHIFT_PCT_COMPLIANCE |
|
|
DAY_TGT_COMP |
|
|
DAY_CURR_COMP |
|
|
DAY_COMP_PACE |
|
|
DAY_TGT_COMP_BAY |
|
|
DAY_CURR_COMP_BAY |
|
|
DAY_COMP_BAY_PACE |
|
|
DAY_PCT_COMPLIANCE |
|
|
SHIFT_TGT_WIP |
|
|
SHIFT_CURR_WIP |
|
|
SHIFT_ASSIGNED_WIP |
|
|
SHIFT_TGT_WIP_BAY |
|
|
SHIFT_CURR_WIP_BAY |
|
|
SHIFT_ASSIGNED_WIP_BAY |
|
|
SHIFT_PCT_COMPLIANCE_BAY |
|
|
DAY_TGT_WIP |
|
|
DAY_CURR_WIP |
|
|
DAY_ASSIGNED_WIP |
|
|
DAY_TGT_WIP_BAY |
|
|
DAY_CURR_WIP_BAY |
|
|
DAY_ASSIGNED_WIP_BAY |
|
|
DAY_PCT_COMPLIANCE_BAY |