FPSADMIN.SCH_W_H_S_ENTITIES

AVAILABILITY

VARCHAR2(4)

BAY

VARCHAR2(12)

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. (* from FPSINPUT.MHS_BAYS)

BG_COLOR_HTML

VARCHAR2(7)

CH

VARCHAR2(1)

A single character to identify the chamber which must be unique with the tool. We concatenate the CH to get the string for CH_USED so it is helpful for diagnostic purposes if this single character is representative of the chamber (i.e. A for ET12CHA or 1 for MD27C1) because then the CH_USED string makes sense. However it is not required and if the chamber naming is inconsistent we might get use 1, 2, 3, etc. for the CH. (* from FPSINPUT.EQP_CHAMBERS)

CH_SHORT_DISPLAY

VARCHAR2(4)

Short display for the chamber displayed on Dashboard and reports as part of a list of chambers used. This should not include the tool name but only the chamber on the tool so if the chambers on ET11 are ET11CHA and ET11CHB1 and ET11CHB2 then this field should be A, B1, and B2. (* from FPSINPUT.EQP_CHAMBERS)

CH_TYPE

VARCHAR2(6)

This column is critical for sequential chamber tools where a wafer goes through multiple chambers. It identifies the type of chamber so two chambers with the same ch_type are identical and wafers can use either one. See comment on mfg_pct_per_ch column for an example. For independent chamber tools where all chambers are the same and each wafer goes to only one chamber then ch_type should be set to the default value CH so that ch_type_cnt is 1CH, 2CH, 3CH, etc. (* from FPSINPUT.EQP_CHAMBERS)

CREATE_INST

DATE

CURR_RECIPE

VARCHAR2(100)

The current/last used recipe for the scheduler, incorporating the ignore capability from EQP_PROCESS_CHG_TO_IGNORE (* from FPSBASE.ETP_STATUS)

CURR_RECIPE_INST

DATE

This DWH timestamp of the last recipe change for this entity

CURR_SETUP

VARCHAR2(100)

The current setup of the entity. This can be set by a lot processing event from WIP_EVENT_HIST or by an event on the entity from EQP_EVENT_HIST. For example if an Implant tool processes a Boron lot then the curr_setup will be Boron. Or if an event is logged to the tool that says the setup changed to Boron then the curr_setup will be Boron. Please note that the curr_setup value populated in EQP_EVENT_HIST must match exactly with the rqd_setup value in RTG_TOOL_ASSIGNMENTS in order for the setup penalty logic to apply correctly. (* from FPSINPUT.EQP_EVENT_HIST)

CURR_SETUP_COUNT

NUMBER

CURR_SETUP_INST

DATE

This DWH timestamp of the last setup change for this entity

DEFAULT_PROCESS_SEC

NUMBER

DEFAULT_RECIPE_CHG_COST

NUMBER

Default recipe change cost. See comments on USE_SETUP_CHG_AUTO_FOR_SCH for details on when this is used. (* from FPSINPUT.EQP_TYPES)

DEFAULT_RECIPE_CHG_SEC

NUMBER

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details. (* from FPSINPUT.RTG_PROCESS_GROUPS)

DEFAULT_SETUP_CHG_COST

NUMBER

Default setup change cost. See comments on USE_SETUP_CHG_AUTO_FOR_SCH for details on when this is used. (* from FPSINPUT.EQP_TYPES)

DEFAULT_SETUP_CHG_SEC

NUMBER

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details. (* from FPSINPUT.RTG_PROCESS_GROUPS)

ENTITY

VARCHAR2(19)

The lowest level of the equipment hierarchy that an event can be logged against. Tools, subtools, shared parent tools, chambers, ports are all entities. Load locks are also included although we consider them as ports. (* from FPSINPUT.EQP_STATUS_VERIFY)

EQP_STATE

VARCHAR2(48)

Client equipment state taken directly from their MES or from their existing tool state model. For EQP_MNT_FUTURE, this is the state that we estimate the entity will be in during the maintenance which is often set to a generic PM state if we do not have detailed information. (* from FPSINPUT.EQP_L6_DETAILED_STATES)

EQP_STATE_CHG_INST

DATE

Time when the eqp_state changed for this particular entity. If another entity on the same main tool changes state, eqp_inst will change for all entities on the tool even those whose state does not change. Therefore if eqp_inst is after state_chg_inst that means another entity changed state at eqp_inst but this entity has not changed since state_chg_inst. (* from FPSBASE.ETP_STATUS)

EQP_STATE_DISPLAY

VARCHAR2(48)

Display name for the equipment state which will be displayed on all Dashboards and reports. (* from FPSINPUT.EQP_L6_DETAILED_STATES)

EQP_STATUS_COMMENT

VARCHAR2(256)

An optional comment on the status of the entity that can be displayed in various application interfaces.

FACILITY

VARCHAR2(6)

N

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. (* from FPSINPUT.GEN_FACILITIES)

HOURS_SINCE_PROC

NUMBER(4,1)

Hours since the tool was last processing lots.

MAX_BATCH_SIZE_CARRIERS

NUMBER

Maximum number of carriers which can be loaded together in a batch. This column must be populated and is used for ETP and for scheduling to determines whether the tool loads in batches. Non-batch tools will have a value of 1 and batch tools limited by units will be populated according to the comment in max_batch_size_units. This is not used for throughput calculation because we can have tools which load multiple carriers at once but whose throughput is calculated per unit. (* from FPSINPUT.EQP_TYPES)

MAX_QTY_IN_JOB

NUMBER

Normally we assume that the maximum qty in a job for a non-batch tool is the max_qty_per_carrier for the facility. However sometimes the maximum per job is less than that and this column allows us to override. For example, the max_qty_per_carrier for the facility is 25 but a certain eqp type can do no more than 13 units per job. In this case, if the carrier has 13 wafers or less then we schedule normally but if it has more than 13 then we must ask for a split. (* from FPSINPUT.EQP_TYPES)

MAX_WAIT_TIME_EXTRA_LOTS_RQD

NUMBER(3)

to indicate how many more lots this priority is willing to wait to batch, this need to work with max_wait_time_pct; by default, 999 meaning not going to way, but the minimum is 1, additional lot required to wait

MAX_WAIT_TIME_PCT

NUMBER(3)

to indicate how much time this priority is willing to wait for the coming lots to batch, this need to work with max_wait_time_extra_lots_rqd; if value is 0, then it means not going to wait at all

MODULE

VARCHAR2(12)

Modules are departments of people who manage certain areas of the fab. The modules are assigned ownership of a set of tools to operate and maintain as well as steps on the route that they are responsible for executing. Since many of our tables include tool and step information together, we must distinguish between the owner of the step (WIP_MODULE), the owner of the operation of the tool (EQP_MODULE), and the owner of the maintenance of the tool (MNT_MODULE). WIP_MODULE is used to credit moves and set goals. Each route-step is assigned to a process family and then its wip_module is defined by the process family. EQP_MODULE is used to group tools particularly for tool performance reporting. Similar to WIP, each tool is dynamically assigned to a process family based on its assignments and then its eqp_module is defined by the process family. MNT_MODULE is usually the same as EQP_MODULE but unlike EQP_MODULE is not dependent on assignments but only on the EQP hierarchy. Each tool is assigned to an eqp_type and each eqp_type is assigned to a mnt_family and each mnt_family is assigned to a mnt_module. (* from FPSINPUT.GEN_MODULES)

NUM_PORTS

NUMBER

ONLY_KEEP_POD_IF_1_PORT_AVAIL

CHAR(1)

used to determine if it will only run the same pod rule when only 1 port available

PCT_PROC_TIME_WAIT_TO_BATCH

NUMBER

PROCESS_GROUP

VARCHAR2(36)

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. (* from FPSINPUT.RTG_PROCESS_GROUPS)

RESERVE_CAPACITY

NUMBER

RESERVE_SEC

NUMBER

RESERVE_SEC_FUTURE_PRTY_LOTS

NUMBER

RESERVE_STEPS_FUTURE_PRTY_LOTS

NUMBER

RUN_ID

VARCHAR2(50)

N

the run id from the last successful scheduler (* from FPSAPP.SCH_W_SCHED_GROUP_STATUS)

SCHED_GROUP

VARCHAR2(36)

N

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. (* from FPSINPUT.RTG_PROCESS_GROUPS)

SCH_IS_DE_RATE_LOT_AFT_RSV

CHAR(1)

To indicate if the scheduler will de-rate the lot score when it is outside of reservation window (* from FPSINPUT.RTG_SCHED_GROUPS)

SCH_IS_DE_RATE_TOOL_AFT_RSV

CHAR(1)

To indicate if the scheduler will de-rate the tool score when it is outside of reservation window (* from FPSINPUT.RTG_SCHED_GROUPS)

SHOULD_SCHEDULE

CHAR(1)

Indicates if it should force scheduler to schedule this step or not. Setting this value to Y also forces a TAKE decision for this step in WIP_STEP_FUTURE. (* from FPSINPUT.WIP_STEP_FUTURE_OVR)

SHOULD_UNRESERVE_DIFF_SETUP

CHAR(1)

SHOULD_USE

CHAR(1)

This flag determines if the scheduler should use this data or not

SORT_ORDER_WITHIN_TOOL

NUMBER

TEXT_COLOR_HTML

VARCHAR2(7)

TOOL

VARCHAR2(16)

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. (* from FPSINPUT.EQP_TOOLS)

TOOL_SORT

NUMBER

TOOL_TYPE

VARCHAR2(50)

the tool type from the first lot that scheduled (* from FPSAPP.SCH_W_SCHED_DURABLE_INSPECT)

WAIT_SEC_TO_RELEASE_DURABLE

NUMBER

WAIT_SEC_TO_SCHED

NUMBER

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

WAIT_SEC_TO_VERIFY_LONG_DOWN

NUMBER