Columns

ABORT_INST

DATE

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.

ACCEPTABLE_NUM_PER_HOUR

NUMBER(3)

Usually these known cases are infrequent. Enter a number that is above the normal level so that if we start logging significantly more events then we will warn.

ACTION

VARCHAR2(1)

For CHGLOG and automatic HIST tables, this is I for insert or U for updated or D for delete.

ACTIVE_DATE

DATE

The date when a new tool will become active and available for production. There is nothing wrong with keeping this set to a value in the past after the tool is active but this is irrelevant.

ACTIVE_VERSION

VARCHAR2(12)

The most recent version of the route.

ACTUAL_CH_USED

VARCHAR2(24)

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.

ACTUAL_DURABLE_USED

VARCHAR2(129)

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.

ACTUAL_MACHINE_RECIPE

VARCHAR2(100)

Machine recipe used to process the lot as logged during processing by the tool.

ACTUAL_START_INST

DATE

Time when maintenance was started if it is currently in progress. This should be null for all upcoming events which have not started yet which means that this will be null for the majority of records.

ACTUAL_START_OPERATOR

VARCHAR2(64)

Username of the user that logged actual start occurrence of this maintenance if known. It is common for this field to be null for all records.

ADD_LOTGRP_TO_GP_SUBFAMILY

CHAR(1)

If this is set to Y we split each subfamily into separate GP_subfamily values for each lot group. This usually means that we set goals by prod and dev separately.

ADD_MINS_TO_EXP_STEP_ENT

NUMBER(5)

The purpose of this column is to prepare an incoming lot from being scheduled within the first x minutes of the schedule unless it is a priority lot or is in the middle of a queue timer or is processing at the previous step when we have higher confidence in our arrival estimate. For all other lots that do not meet any of these criteria we add this many minutes to our normal estimated arrival. For purposes of determining the previous step we exclude skippable steps and staging steps so if the lot is processing at step 100 and step 101 is a skippable metrology step and step 102 is a staging step then we will not add this penalty to the expected arrival. Also please note that we must add the same penalty for the entire facility in order to maintain integrity of the order. If we added a different penalty for different sched groups then the lot could arrive at step 104 before step 103 which would cause trouble. Finally please note that we apply the penalty even if all steps are in the same sched group but that it does not matter to the Scheduler because the Scheduler only cares about the expected arrival to the first step in a contiguous group of steps in the same sched group. The Scheduler manages the arrival for all subsequent steps of the same sched group internally based on the scheduled end of the previous step.

ALARM_TEXT

VARCHAR2(48)

The actual alarm text for the fault.

ALERT_INTERVAL_MINS

NUMBER(4)

This is the interval in minutes between email alerts. It is normal for this to be larger than the check interval which means the web page is updated but we do not bombard everyone with alerts.

ALERT_MESSAGE

VARCHAR2(1000)

If this is populated then this record will be included in SYSMNTR_P_MISSING_LOTS view and alert. Therefore we can include anything here that we want to alert ourselves about regarding the assignments. For example, missing recipe or no setup.

ALERT_NAME

VARCHAR2(30)

Descriptive name should align with sysmonitor view using configuration. Example - ALERT_NAME = CHK_NEXTMOVE is used by CHK_NEXTMOVE view.

ALERT_SEC

NUMBER(6)

This column is used to determine how long the SysMonitor (Health Check Alert Application) will wait (since last successful run) before issuing an alert and sending text message or email to the recipients.

ALERT_TYPE

VARCHAR2(30)

Descriptive type definition should align with portion of associated ALERT_NAME view that is using these configurations. Example - ALERT_TYPE = scan_check is used for the portion of the CHK_NEXTMOVE view that looks at the recent scan rate of lots using Next Move.

ALERT_VALUE

NUMBER

Numeric configuration value.

ALLOWED_TO_SCAN

CHAR(1)

In order to scan a carrier on a rack or cart in NextMove, the carrier must be in NMV_P_CARRIER_SUMMARY because this view is used for identifying carriers and displaying the info once it has been scanned. This column should always be set to Y for LOT, CAST, and BOX and always set to N for DURABLE and TOOL. POD is normally set to N but at sites where we want to allow pods to be scanned this value would be changed to Y.

ALLOW_MERGE_VALID_FIN_CT

CHAR(1)

Normally lots that finish by merging into another lot are not counted as valid because they do not reach the end of the main route. But if a lot is merged at the last operation then we normally count this as a valid finished lot since it progressed through the entire route. Therefore the default value for this column is Y. If you do not want to count lots that merge at the last step as valid then set this to N.

ALLOW_RESRV_ON_PREV_DISPATCH

CHAR(1)

to allow to reserve the lot to the tool when the previous step is dispatched

ALLOW_RTG_PRDS_IN_OTHTAB

CHAR(1)

We have checks on the configuration of the RTG_PRDS table load as this is critical for RTG_ACTIVE_PRD_ROUTES. However at some older sites RTG_PRDS is loaded as part of another table so this flag causes us to ignore those checks which we will not do for new sites.

ALLOW_SCRAP_VALID_FIN_CT

CHAR(1)

If a lot is scrapped at the last operation then we normally count this as a valid finished lot since it progresses through the entire route. Therefore the default value for this column is Y. If you do not want to count lots that scrap at the last step as valid then set this to N.

ALTERNATE_STATION

VARCHAR2(32)

The rack, bay, building, tool, cart, or stocker which is alternately acceptable for delivery

ALWAYS_ALLOW_Q_WHEN_DOWN

CHAR(1)

Normally we do not allow lots to start at the first step in a queue timer sequence if there is a step in the sequence that has no tools available. But if this flag is set to Y then we will allow lots to start even when all tools are down at this process. Typically this is used for a process that we know we can skip but the est_smp_pct might be above the smp_pct_to_allow_q_when_down threshold set for the facility in GEN_FACILITIES.

ALWAYS_SBY_AFTER_DOWN

CHAR(1)

Normally when an entity comes up after a down state we set the ETP state to the proc_state if a lot is processing so that we return to PRD when the entity alarms during processing. However this introduces a risk if the lot aborts when the tool goes down and fails to properly log an abort in which case we will return to PRD when the lot is no longer processing. This flag allows you to avoid this risk for eqp types where you know that abort are not logged properly but it also means that these tools will never return to PRD after a short alarm so we prefer to have this set to N.

ALWAYS_USE

CHAR(1)

If N then we will only use this value when we do not have a valid automated calculated value for the eqp_type and process. If Y then we will always use this value even if we have a valid auto value.

ALWAYS_USE_DEFAULT_THP

CHAR(1)

For some tools (primarily metrology tools), logging of begin/end run times are not possible due to lack of automation capabilities - so throughput is based on dispatch/complete signals. This causes variation and frequent overestimation of estimated processing time due to operator dispatch/complete logging patterns. Throughput estimates can be overridden via the THP_MANUAL or THP_EXTERNAL tables but this requires an override at every possible process where the tool could be used. Now if you set the always_use_default_thp column to Y in EQP_TYPES we will always use the default throughput data unless there are overrides in THP_MANUAL or THP_EXTERNAL. For example, if for the VISUAL_INSPECT eqp_type that we set always_use_default_thp to Y and sch_first_unit_sec to 30 and sch_unit_interval_sec to 30 then the processing time will always be estimated at 30 seconds per wafer. So a lot with 25 wafers would have an estimated processing time of 12.5 minutes. This is independent of what step is being inspected.

AMHS_DESTINATION

VARCHAR2(24)

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.

AMHS_VEHICLE

VARCHAR2(24)

The vehicle used to move 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 the cart which should be used which we decide in MHS_DELIVERY_NEXT.

ANALYSIS_DETAIL

VARCHAR2(48)

The detail of the analysis being sent.

ANALYSIS_NAME

VARCHAR2(48)

The name of the analysis being sent.

APF_REP_PARM_W_COLON_DELIM

VARCHAR2(128)

We pass this value to the APF report as the parameter(s). The script replaces colon so we must use colon as the delimiter. This column works only for QE, CLR, CLRA and not ST because the dispatcher handles parameters differently.

APPEND_CUST_TO_PRD_FOR_SCRAP

CHAR(1)

This is a bit of hack to append the customer to the prd column in DASH_P_H_SCRAP for purpose of displaying customer on the Dashboard Scrap page. When that DASH-3715 is completed to make the columns on the Scrap page configurable, we should drop this column and remove the logic from DASH_P_H_SCRAP.

APPLICATION

VARCHAR2(30)

Application that the user is allowed or able to log events.

APPLICATION_ID

VARCHAR2(10)

The id of the application used for joining with other SEC tables. This field is a string field but we normally populate it with a number.

APPLICATION_NAME

VARCHAR2(50)

The name of the application used for display purposes only. Since we join by application_id, this can be changed as desired without any negative consequences to the behavior of the application or its security features.

APP_POOL

VARCHAR2(50)

This is the application pool that the application should be run under

ARE_ALL_STEPS_IN_WSF_PRTY_LOTS

CHAR(1)

By default, we include all future steps for priority lots but loading all future steps can take a few seconds which is significant during the RealTime job at slower sites. Setting this column to N will load the normal amount of steps for priority lots as defined in steps_for_wip_step_fut.

ARE_SYS_PRIVS_TEMPORARY

CHAR(1)

Setting this to Y indicates that the system privileges granted to FPSADMIN are temporary and will be revoked after an upgrade is complete. This tells BLD_PRIVS_AND_SYNONYMS to grant the proper standard privileges to FPSADMIN as if the system privileges did not exist. These privileges are unnecessary at the time but they will be in place when system privileges are revoked.

ARRIVAL_DATE

DATE

The date when a new tool is expected to arrive into the fab. There is nothing wrong with keeping this set to a value in the past after the tool arrives but this is irrelevant.

ASGN_INFO

VARCHAR2(512)

the unique identifier for the assignment to the counter info

ASGN_PARM1

VARCHAR2(128)

Four user-defined fields which can store anything the user would like to track relating to the assignment.

ASGN_PARM2

VARCHAR2(128)

See ASGN_PARM1.

ASGN_PARM3

VARCHAR2(128)

See ASGN_PARM1.

ASGN_PARM4

VARCHAR2(128)

See ASGN_PARM1.

ASGN_SCHED_SCORE1

NUMBER(2)

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score.

ASGN_SCHED_SCORE1_COMMENT

VARCHAR2(64)

This column should explain the score for ASGN_SCHED_SCORE1.

ASGN_SCHED_SCORE2

NUMBER(2)

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score.

ASGN_SCHED_SCORE2_COMMENT

VARCHAR2(64)

This column should explain the score for ASGN_SCHED_SCORE2.

ASGN_SCHED_SCORE3

NUMBER(2)

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score.

ASGN_SCHED_SCORE3_COMMENT

VARCHAR2(64)

This column should explain the score for ASGN_SCHED_SCORE3.

ASGN_SCHED_SCORE4

NUMBER(2)

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score.

ASGN_SCHED_SCORE4_COMMENT

VARCHAR2(64)

This column should explain the score for ASGN_SCHED_SCORE4.

ASGN_SCHED_SCORE5

NUMBER(2)

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score.

ASGN_SCHED_SCORE5_COMMENT

VARCHAR2(64)

This column should explain the score for ASGN_SCHED_SCORE5.

ASGN_SCHED_SCORE6

NUMBER(2)

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score.

ASGN_SCHED_SCORE6_COMMENT

VARCHAR2(64)

This column should explain the score for ASGN_SCHED_SCORE6.

ASGN_SCHED_SCORE7

NUMBER(2)

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score.

ASGN_SCHED_SCORE7_COMMENT

VARCHAR2(64)

This column should explain the score for ASGN_SCHED_SCORE7.

ASSIGNED_CARRIER

VARCHAR2(32)

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.

ASSIGNMENT_RANK

VARCHAR2(1)

this assignment rank will be used in the scheduler

ASSUME_ALL_CH_USED_ON_BEG

CHAR(1)

Normally when we log a BEGIN event in WIP_EVENT_HIST to a chamber, we assume that only that chamber is used and we set only that chamber to PRD and keep the other chambers on the tool in SBY. However in some rare cases, usually on Litho cells, we want to treat the BEGIN like it was logged to the main tool and assume all chambers used and set all chambers to PRD. This flag allows us to do that. Note this flag has to be set for the chamber that logs the BEGIN event rather than the other chambers that we are assuming will be used.

AVAIL_INST

DATE

Time when the availability last changed, either came up or went down.

AVG_CAL_SEC

NUMBER(6)

This is used to set how many seconds allowed to run the parallel calculation

AVG_KIT_SEC

NUMBER(7)

average kit time for pod kitting

AVG_QTY_PER_CARR_FOR_UPH

NUMBER(7)

Throughput calculations like EET, MPU, and UPH all include wafer_interval_sec which must be multiplied by wafer qty. When calculating for a specific lot, we can use its qty but when calculating generically we use this value which should be set close to the average lot size for the facility. This value can be overridden for an eqp type with exp_qty_per_job.

BADGE_COLOR

VARCHAR2(24)

This column is to indicate the badge color related to visibility on scheduler ganntchart, and the value should be corresponding to COLOR column in table GEN_COLORS

BADGE_ICON

VARCHAR2(50)

Bootstrap badge icon name to be used to display an icon rather than text. If this field is populated the badge_text column must be null.

BADGE_NAME

VARCHAR2(20)

Badge name associated to the lot.

BADGE_TEXT

VARCHAR2(12)

Text value to display in the badge. If this field is populated the badge_icon column must be null.

BADGE_TEXT_OVR

VARCHAR2(20)

Override text for an individual lot for a badge that is a text and not an image.

BALANCED_BATCH_QTY

NUMBER(7)

When configured for balanced batching, this represents the maximum delta in unit quantity for lots to be considered balanced.

BALANCED_BATCH_TYPE

VARCHAR2(8)

This parameter tells the scheduler whether and how the batch balance logic should be applied. Null means the logic is turned off. MATCH means that all lots in the balance group/pair must have unit quantities within this range. PREFER means that the scheduler should try to meet the criteria for MATCH, but if it cannot be met to add the next best lots to make a fuller batch. The maximum batch size for the process context must also be 4 lots/carriers if this value is not null.

BAL_WINDOW_LIMIT_RANK

VARCHAR2(1)

Rank to assign lots needing to process at the start step when the WIP balance window limit has been exceeded.

BANK

VARCHAR2(36)

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.

BARE_DRBL_CAPACITY

NUMBER(4)

Maximum number of bare durables that can be stored. Bare durables are durables which are not in a pod.

BARE_WFR_CAPACITY

NUMBER(4)

Maximum number of bare wafers that can be stored. Bare wafers are lots which are not in a cassette.

BATCH_CRITERIA

VARCHAR2(140)

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.

BATCH_SIZE_WEIGHTS_AT_OPER

NUMBER(7,2)

the batch score weight applied to the percent of lots that are at the batching operation

BATCH_SIZE_WEIGHTS_COMING

NUMBER(7,2)

the batch weights for the lots will arrive after the process starting

BATCH_SIZE_WEIGHTS_CURRENT

NUMBER(7,2)

the batch weights for the current batched lots

BATCH_SIZE_WEIGHTS_FULL

NUMBER(7,2)

the batch score bonus points for scheduling a full batch - either max size or all lots in scheduler window

BATCH_SIZE_WEIGHTS_FUTURE

NUMBER(7,2)

the batch weights for the lots will arrive before process starting

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.

BAY_TO_BAY_TRANSPORT_MODE

VARCHAR2(10)

Bay to bay transport mode. If no other mode is specified, this will be the value used to direct wip from bay to bay.

BEG_PROC_INST

DATE

time when the lot started processing on the main tool.

BEG_PROC_INST_OF_START_STEP

DATE

Time when the lot started processing on the tool at the step which starts the queue timer.

BG_COLOR

VARCHAR2(24)

Background color assigned. BG_COLOR is in English like red or blue or light green and we look up the HTML color like #FF0000 in the GEN_COLORS table. BG_COLOR must be set manually but the FPSADMIN view BLD_POPULATE_COLORS will generate queries to randomly set bg_color for all values in a table.

BLOCK_E_FOR_ECT

CHAR(1)

This flag determines the ect_state when the best tool is rank E for Emergency. If this is the default value of N then we set to WAIT1 or WAIT2 or WAIT3 based on the number of Emergency tools. If this is Y then we set to BLOCK-E.

BOTTLENECK_CASCADE_RATE

NUMBER(4,3)

This is the maximum fraction of total process time which overlaps with the previous job, within the same data set as used for effective_cascade_rate. We make the optimistic assumption that if this tool were truly a bottleneck, suboptimal cascades could be managed in such a way that they would all be optimal.

BOTTLENECK_TIER

NUMBER(1)

This field is used for scheduling to determine which group should be scheduled first.

BOTTOM_LEFT_BADGE

VARCHAR2(20)

The badge to display on the bottom left of the tool icon.

BOTTOM_RIGHT_BADGE

VARCHAR2(20)

The badge to display on the bottom right of the tool icon.

BUILDING

VARCHAR2(12)

Building is the top of our MHS hierarchy at each site. It is independent of facility which is at the top of our EQP/RTG hierarchy. It is possible for a building to include multiple facilities and for a facility to include multiple buildings but we do not even need to define these relationships because EQP_TOOLS determines this by the combination of the facility and bay columns (since bay points to building).

BUNCH_ID

VARCHAR2(17)

Chain lots together for Goal Planner

BURDEN_RATE

NUMBER(12,2)

Priority of the technician if a priority wants to be provided.

CALENDAR_DAY

DATE

When we choose this day on a website calendar we will associate with work_days of this day. Typically this is the day of the start_day but not always. For example, start_day might be 17:00 and represent the following calendar_day.

CALLING_PROCEDURE

VARCHAR2(30)

For load jobs ending in IF, CALLING_PROCEDURE is the ADM_LOAD procedure which is scheduled either as part of ADM_LOAD_EVENT_HIST_VIA_APD or in CFG_SCHED. This procedure calls the ADM_LOAD_START_SHIFT_OR_WEEK procedure which has logic common to all ADMA+IF jobs. It calls the objects in the ADMA job in a loop. If inserts are made to the table listed in CALL_IF_INSERTS_IN_TABLE then this procedure makes an external call to the IF job.

CALL_IF_INSERTS_IN_TABLE

VARCHAR2(30)

This is the name of a table which must be part of the corresponding ADMA job in CFG_SCHED. If inserts are made in this table during the ADMA job then the ADM_LOAD_START_SHIFT_OR_WEEK procedure makes an external call to the IF job.

CANCEL_INST

DATE

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.

CAN_MULTIPLE_JOBS_SHARE_DISC

CHAR(1)

For tools that run per disc, we need to know if a disc can combine wafers from multiple jobs (job is usually lot). If N, this means we can divide job qty by wafers per disc to get number of discs used for the lot. For the common case of 25 wafers per carrier and 13 wafers per disc then any lot with 1-13 wafers will use 1 disc and 14-25 wafers will use 2. If Y, it is more complicated. In the same common case, the first lot will use two discs 13+12 then a second cascading lot of the same recipe will use three discs 1+13+11 then third also three discs 2+13+10 and so on. This must be set along with WAFERS_PER_DISC.

CAPACITY

NUMBER(3)

In EQP_PORTS, capacity is the number of carriers allowed on the port, which is usually 1. In MHS_CARRIERS, when carrier_class is set to POD then capacity is the number of durables that the pod can hold, which is usually either 1 or 6. This field is only used in MHS_CARRIERS for pods therefore when CARRIER_CLASS is CAST then capacity should be set to the default value of 1.

CARRIER

VARCHAR2(32)

RFID of the cassette or FOUP the lot is currently in.

CARRIERS_IN_JOB

NUMBER(2)

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.

CARRIER_CLASS

VARCHAR2(13)

Carrier class indicates what the carrier is able to carry. It is also an important field in EQP_PORTS but each port has a single defined carrier class and only carriers of this class should go to the port. The value must be one of those defined by FPS in FPSADMIN.MHS_CARRIER_CLASSES which include POD or CAST or BOX. This would be used as a filter on what carriers could be selected when a carrier is needed. For example, when a lot is split we need to find another carrier for the split lot and we select the best carrier in the carrier_class of CAST. But if we need to unload a reticle then we select the best carrier in the carrier_class of POD.

CARRIER_INST

DATE

When the carrier was last populated with the event. Since we carry over the previous value of carrier we need to know this to compare to the updated_inst in WIP_LOTS_STATIC and use the newest information for carrier.

CARRIER_STATE

VARCHAR2(18)

Carrier state indicates the current state of the carrier. The value must be one of those defined by FPS in FPSADMIN.MHS_CARRIER_STATES. This is a very short list of simple states like OK or WARN or DOWN in contrast to the complex options available for equipment states. This would be used as a filter/sort on what carriers could be selected when a carrier is needed. For example, when a lot is split we need to find another carrier for the split lot and we would prefer one with state of OK then WARN but we could not choose one which was DOWN.

CARRIER_STATE_DISPLAY

VARCHAR2(128)

The name of the carrier_state displayed on all dashboards and reports. Carrier_state must match the FPS list defined in MHS_CARRIER_STATES but this display field might be formatted in a more familiar way to the users in the facility.

CARR_CATEGORY

VARCHAR2(17)

Carrier category is used when lots in a certain of the line require a carrier in the specific category. This is usually required due to potential contamination. One example might be that an entire route is Copper and all lots at all steps on the routes must be in Copper carriers. Another example might be front-end-of-line (FEOL) and back-end-of-line (BEOL) where the first half of the route must use a FEOL carrier and the second half of the route might be a BEOL carrier. Whenever a route is split then there has to be a carrier transfer step on the route in between the sections which require each category. To define this, each route-step has a required carr_category and each carrier has a carr_category.

CARR_CATEGORY_RQD

VARCHAR2(17)

Required carrier category which if set must match carr_category in MHS_CARRIERS

CARR_PARM1

VARCHAR2(128)

First parameter to store whatever value is desired for the site. These are often used for ETL of other carrier-related tables so that we do not need to have a separate LOAD_CARRIERS table.

CAST_CAPACITY

NUMBER(3)

Maximum number of cassettes that can be stored. We define cassette as a carrier for a lot.

CAST_EXPEDITE_TRANSIT_SEC

NUMBER(5)

Estimated expedite transit time to move a cassette between bays. Primarily used by the Scheduler to estimate shorter transit times for expedite lots to allow for earlier scheduling.

CAST_IDEAL_TRANSIT_SEC

NUMBER(5)

Ideal transit time to move a cassette between bays used in cycle time X-factor calculations.

CAST_TRANSIT_SEC

NUMBER(5)

Estimated transit time to move a cassette between bays. Primarily used by the Scheduler and NextMove to estimate lot transit times.

CERT

VARCHAR2(64)

Certifications or skills possible to perform on a specific Tool, or MNT task, or Event_ID from EQP_MNT_FUTURE.

CERT_DISPLAY

NVARCHAR2(1024)

User friendly details about the Certification

CERT_SKILL_LEVEL

NUMBER(4

The level of skill a tech has for a specific certification, can be from 1 - 10, 10 is the best, default value 10

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.

CHAMBER

VARCHAR2(19)

Chambers belong to a main tool, have a state which is independent of the main tool and other chambers on the same tool, and can have events logged against it. The difference between a chamber and a port is that a chamber processes lots while port is just a location.

CHAMBER_EACH_NA

VARCHAR2(19)

Define what chambers will be tracked in the MSO_RULE_COUNTER_HIST tables.

CHAMBER_MSO_GROUP_EACH_NA

VARCHAR2(64)

Define what chambers mso groups will be tracked in the MSO_RULE_COUNTER_HIST tables.

CHAMBER_MSO_GROUP_NA

VARCHAR2(64)

This is the counter definition value for chamber mso group. If chamber mso group is not part of the rule definition and included in the counter then it will be NA, otherwise it will have the chamber mso group value.

CHAMBER_NA

VARCHAR2(19)

This is the counter definition value for chamber. If chamber is not part of the rule definition and included in the counter then it will be NA, otherwise it will have the chamber value.

CHANGE_COST

NUMBER(9)

the cost it need to budget to have this change

CHANGE_EMAIL_LIST

VARCHAR2(512)

CFG_FILES table is currently not used.

CHANGE_FROM

VARCHAR2(100)

the value the process max usagess from

CHANGE_SEC

NUMBER(9)

the time it takes to have this change

CHANGE_TO

VARCHAR2(100)

the value the process max usagess to

CHANGE_TYPE

VARCHAR2(64)

the change for this process max usages. only allow setup, recipe, recipe_family, recipe_group

CHANGE_VALUE

VARCHAR2(100)

The value of the RECIPE or SETUP to ignore. We also have two special values for this field, Missing and No Setup. We insert a record for Missing for either RECIPE or SETUP if we want to ignore the recipe or setup change on the tool when the lot-route-step has no record in WIP_STEP_FUT_ASSIGNMENTS. We insert a record for No Setup only for SETUP if we want to ignore the setup change on the tool for a record with no setup information.

CHECK_INTERVAL_MINS

NUMBER(4)

This is the interval in minutes between calls to the view to check the status. The web page is always updated immediately after each call.

CHG_TIMESTAMP

TIMESTAMP(4)

For CHGLOG and automatic HIST tables, this is populated with SYSTIMESTAMP. This means that this record existed in the original table from this time until NEXT_CHG_TS.

CHILD_TO_MSO_PROCESS

VARCHAR2(100)

This linked to_mso_process will have the same decision as the parent_to_mso_process, based on the link type

CHK_UPD_COLUMN_NAME

VARCHAR2(30)

Our most important check on the DWH is the check for no recent day in key tables. For a table to be part of this check, enter the column to check here which must be a DATE and the number of minutes to warn in CHK_UPD_MINUTES. 30 minutes is a reasonable number for a table that is part of the 3min load which means we will send warning emails if the newest record is more than 30 minutes old.

CHK_UPD_MINUTES

NUMBER(5)

See CHK_UPD_COLUMN_NAME.

CH_ALLOWED

VARCHAR2(24)

List of chambers allowed using the single character CH from EQP_CHAMBERS. While the concepts of cap_entity (capacity entity) and ch_type are important to our logic we agreed that there is no RMS or EI or MES on the planet that understands these concepts. All of these systems go by tool and chambers allowed and therefore our input tables must do the same. We list all chambers that can run and then calculate subsets of these chambers based on CH_TYPE. If all chambers are the same type then we assume you can run on any one or more of the chambers allowed. If the chambers are different types then we assume that at least one chamber of each type is required to run. If you populate either RTG_TOOL_ASGN_LOT_xxx_PATH table then you can leave ch_allowed blank since it will not be used. However there is nothing wrong with populating ch_allowed as a backup plan.

CH_ASGN_RULES

VARCHAR2(128)

String with complicated syntax indicating which chambers can be used by the Scheduler. For example, (A|B|C) means the lot can only run on chamber A or B or C but not all of chambers. For example, if it runs on A then no wafer from the same lot can run on B nor C.

CH_PATH

VARCHAR2(24)

A path of chambers which can be used to process the lot on this tool. This is a concatenation of the single character CH from EQP_CHAMBERS similar to CH_ALLOWED. It is desired to list the chambers in order if there is an order however currently the order is not necessary and not used by Scheduler.

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.

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.

CH_TYPE_CNT

VARCHAR2(128)

This value is a summarizing of ch_used which we use for grouping of throughput. The assumption is that throughput will be the same if the same number of chambers of the same type are used.

CH_TYPE_CNT_INPUT

VARCHAR2(128)

This is the ch_type_cnt input into the GET_THP_VALUES function, often from actual_ch_used or est_ch_used.

CH_TYPE_CNT_THP

VARCHAR2(128)

This is the ch_type_cnt used from one of the THP tables, either THP_MANUAL or THP_EXTERNAL or THP_EQPTYPE_AUTO.

CLEANUP_IF_FREE_LESS_THAN

NUMBER(3)

If the free space at the rack (measured by total capacity of all locations minus carriers at all locations) is less than this number then we will move carriers away from this station to another storage location with more free space. If this value is 0 then we will never do this.

CLIENT_NAME

VARCHAR2(5)

Short company name of the client. See site_name comment for client/site/facility example.

CLIENT_NAME_DISPLAY

VARCHAR2(24)

Longer display friendly client name.

CM_SCENARIO

VARCHAR2(6)

This is the scenario to which the column should be added. Currently, the options are: STARTS, EQUIP, CALC for starts, equipment, and calculation scenarios respectively.

CM_THP_PARALLEL_FACTOR

NUMBER(1)

This is number of jobs that can run on the tool in parallel where the throughput logic does not account for cascading. Typically it is used for wet benches or plasma strip tools. This column is not used by the FPS CM but exists for sites to store this information to use for their own CM. In their CM, they will multiply the throughput by this factor.

COLOR

VARCHAR2(24)

The HTML CSS color name used in various FPSADMIN, FPSINPUT, and FPSAPP C and G tables to associate a color with a field. Usually the column name is bg_color. Each of these columns has a foreign key referencing GEN_COLORS which enforces that this must be one of the 140 standard HTML CSS color names.

COLOR_FAMILY

VARCHAR2(6)

The color family from HTML CSS standards which is one of ten basic colors.

COLUMN_NAME

VARCHAR2(30)

Name of the column in DWH. Note: The column may exist in more than one table and/or schema.

COMBINATION_ID

VARCHAR2(64)

User can use COMBINATION_ID to define multiple different combinations of durables for the same lot/process. For example, user can define durable A and C with COMBINATION_ID 1 and durable B and D with COMBINATION_ID 2, the scheduler will either schedule to use durable (A and C) or (B and D) to run this process on this tool. Meanwhile, if the durable assignment is defined for the certain lot/route/step/tool in this table, then the scheduler will also ignore the durable assignment from RTG_DURABLE_ASSIGNMENTS table.

COMMENTS

VARCHAR2(200)

A comment field allowing a user to document the source or reason of the values populated in the table

COMMENT_EXT

VARCHAR2(256)

Optional comment entered regarding the external throughput value.

COMMENT_MANL

VARCHAR2(256)

Comment referring to the interval and first unit values.

COMMENT_MPU

VARCHAR2(256)

Comment referring to the MPU value.

COMMIT_CT_DAYS

NUMBER(5,1)

Number of days of cycle time committed to the customer for the prd or bank. This commit is published externally. This should be greater than or equal to the target.

COMMON_END_STEP

VARCHAR2(50)

The common step upon move out where the wip balance limit is no longer applied.

COMMON_START_STEP

VARCHAR2(50)

The common step upon move out we apply the balance logic. Tied to all routes that share the common end and start steps. This is used for both the WIP window and daily input control limit to trigger WIP that is in the window limit and/or counted towards the daily limit.

COMMON_STEP

VARCHAR2(50)

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.

COMMON_STEP_SORT

NUMBER(7,2)

How to sort common_step when displaying together for multiple routes in the same view. This must be unique for the entire facility so that we know how to order common_step when viewing the entire facility.

COMP_INST_OF_START_STEP

DATE

Time when the lot completed (also referred to as moved out of) the step which starts the queue timer.

CONFIG_DESCRIPTION

VARCHAR2(2000)

Description of what the configuration is intended for.

CONFIG_ID

VARCHAR2(50)

This is used to tell which configuration the current sched-group is using

CONFIG_NAME

VARCHAR2(256)

Configuration key used in the UI.

CONSIDER_BEGIN_M_AS_DISPATCH

CHAR(1)

When set to Y, the WIP_EVENT_HIST_INSERT_BEF trigger will change EVENT_TYPE=BEGIN_M events to DISPATCH when the TOOL is expected to log a subsequent automated BEGIN event (based on EQP_TOOLS_PLUS.LOGS_AUTO_BEGIN). When set to N, the trigger will always leave BEGIN_M events as BEGIN_M events.

CONSIDER_IN_BANK

CHAR(1)

Some sites want lots which are on certain routes and/or on hold with certain hold types to count as in bank rather than in active WIP. This flag tells WIP_LOTS_PLUS for route or hold_type to consider in bank. Please note this does not affect WIP_EVENT_HIST nor WIP_STEP_HIST but only the current WIP.

CONSIDER_IN_POD_AS_ON_TOOL

CHAR(1)

When set to Y, the location of a durable in this pod will be considered to be the same as the tool for the pod family assignment, but only if the pod family is allowed for only one tool (i.e. dedicated pod family to tool.

CONSIDER_NONMFG_AS_UP_FOR_MAQT

CHAR(1)

There are some NONMFG states like QUAL and ALARM that we want to consider as up for the purposes of the Multi Area Queue Timer logic because we expect the entity to come up in the near future.

CONSUMABLE_TYPE

VARCHAR2(36)

For assembly only, this optional field stores what type of consumable is being assembled into another part.

CONTROL_LIMIT

NUMBER(12,3)

The control limit for the maintenance indicator value. Typically when the current value has hit the control limit, the tool or chamber will not be able to process additional material.

COORD_X

NUMBER(2)

This is the x coordinate position of the location within its station, in other words horizontal position. The maximum coord_x is the width of the station. This is optional and is often used for racks and sometimes for carts so we can determine the exact position of the carrier to make it easier to find.

COORD_Y

NUMBER(2)

This is the y coordinate position of the location within its station, in other words vertical position or shelf number. The maximum coord_y is the height of the station. This is optional and is often used for racks and sometimes for carts so we can determine the exact position of the carrier to make it easier to find.

COORD_Z

NUMBER(1)

This is the z coordinate position of the location within its station, in other words front-to-back position. This is usually 1. The maximum coord_z is the depth of the station. This is optional and is often used for racks and sometimes for carts so we can determine the exact position of the carrier to make it easier to find.

COPY_AS_TXT

CHAR(1)

CFG_FILES table is currently not used.

COPY_TO_ARCHIVE

CHAR(1)

CFG_FILES table is currently not used.

CORRESPONDING_START_WORK_MONTH

DATE

This is the start of the work month which most closely corresponds with this plan month. We prefer that plan and work calendars are identical so this would be equal to start_plan_month but if they are off we need to be able to match them as close as possible using this field.

CORRESPONDING_START_WORK_WEEK

DATE

This is the start of the work week which most closely corresponds with this plan week. We prefer that plan and work calendars are identical so this would be equal to start_plan_week but if they are off we need to be able to match them as close as possible using this field.

COST_PER_JOB

NUMBER(6)

Cost to process each job on a tool in this eqp type. In WIP_STEP_HIST we use this and cost per unit to record cost per lot after each complete on a tool.

COST_PER_UNIT

NUMBER(6)

Cost to process each unit on a tool in this eqp type. In WIP_STEP_HIST we use this and cost per job to record cost per lot after each complete on a tool.

COUNTER_CHG_PER_DAY

NUMBER(13,4)

Average change in the counter per day calculated by linear regression and used to estimate the time for a counter-based maintenance

COUNTER_CHG_STD_DEV

NUMBER(13,4)

Standard deviation is a measure of fit to the line. A lower value means a better fit.

COUNTER_CURR

NUMBER(12,3)

Current counter value read at counter_read_inst

COUNTER_DUE

NUMBER(12,3)

Counter value when the maintenance event will be due or expected. See `counter_early` and `counter_late` for the window of values in which the maintenance can be performed.

COUNTER_EARLY

NUMBER(12,3)

Counter value when the maintenance event will be early

COUNTER_EFFECTIVE_EVENT

VARCHAR2(5)

used for scheduler to indicate the what was the event that the counter was counted only three options now: 1. disp, it means the counter was counted at the time the lot dispatched to the tool 2. proc, it means the counter was counted at the time the lot process started on the tool 3. ended, it means the counter was counted at the time the lot process ended on the tool, default value

COUNTER_FOR_COMPARE

NUMBER(12,3)

The counter value used for comparing to the due date, this could either be the counter_curr or the counter_pre_reset_value, but should be more reliable than either of the two independently.

COUNTER_INFO

VARCHAR2(512)

the unique identifier for the counter associated with this assignment

COUNTER_INST_PERCENTILE

NUMBER(6,5)

Tolerance for use in prediction when counter based events will come do. Higher number means that a larger range of values will be included. Smaller values mean that the prediction will be more strict on the values to include in the estimation.

COUNTER_INTERVAL

NUMBER(12,3)

Indicates the frequency of future occurrences of this maintenance. For example, a qual required every 250 wafers will be listed once with counter_due set to the next occurrence and `counter_interval` set to 250 so we know to plan for it to occur again 250, 500, 750, etc. wafers after the counter_due.

COUNTER_LATE

NUMBER(12,3)

Counter value when the maintenance event will be late. In most systems, the entity in question will be mandatorily logged down if the maintenance is not started before the counter reaches this value.

COUNTER_LEFT

NUMBER(5)

the current available amount left of this counter

COUNTER_MAX

NUMBER(5)

the maximum usage of this counter

COUNTER_MSG

VARCHAR2(512)

the counter message on the durable

COUNTER_NAME

VARCHAR2(64)

Name of the counter used for this maintenance event.

COUNTER_PRE_RESET_INST

DATE

The inst the last time the counter value was reset.

COUNTER_PRE_RESET_VALUE

NUMBER(12,3)

If a counter has been reset recently then this will be the min or max value depending on the counter direction before the counter was reset. A null value means that there were no resets within the min_used_counter_read_inst

COUNTER_READ_INST

DATE

Time when the current counter value was reported.

COUNTER_UNITS

VARCHAR2(18)

Unit for the maintenance counter. Common examples include wafers or hours or kWh.

COUNTER_UNIT_TYPE

VARCHAR2(32)

the counter unit, can be wafer, lot, second, job

COUNTER_UNIT_WEIGHTS

NUMBER(3)

the weights will consume per each unit

COUNTER_VALUE

NUMBER(12,3)

Value of the counter at the inst.

COUNTER_VALUE_PERCENTILE

NUMBER(6,5)

See comment on COUNTER_INST_PERCENTILE, same idea but for the value.

COUNT_ALL_SHIPS_VALID_FIN_CT

CHAR(1)

Normally we do not count lots that have skipped the first operation as valid for finished lot CT. This configuration allows the user to count all shipped lots for FLCT even if they skipped the first operation.

COUNT_AS_COMP_IF_PROCESSED

CHAR(1)

By default we count a move of any event as a COMP if the lot processed on a tool during the step so the default value of this field is Y. But some facilities prefer to only count certain events so setting this to N means that a move of this event is never counted as COMP.

COUNT_AS_LONG_HOLD_FOR_CTM

CHAR(1)

When this flag is set to Y, time on hold in this hold_group is bucketed into the Long Hold process state to be grouped separately from the normal Hold time on CTA and FLCT.

COUNT_AS_OPER_MOVE

CHAR(1)

If the use_count_as_oper_move_flag is set to Y in GEN_FACILITIES then we use this flag to determine oper moves instead of using moves from one operation to another.

COUNT_JUMP_AS_ISKIP

CHAR(1)

Most sites want to count jumps recorded in WIP_JUMP_HIST with the move_type of ISKIP. But some sites specifically record their skips in WIP_EVENT_HIST and do not want to count jumps. This causes us to ignore jumps for these sites that set it to N.

COUNT_MV_TO_BANK_AS_OPER_MOVE

CHAR(1)

Some facilities count moves to bank as oper moves and some do not. The default when this flag is N is to not count these so set to Y if you wish to count them.

COUNT_SHIP_AS_OPER_MOVE

CHAR(1)

When is_ship_event is set to Y then the normal oper moves logic is ignored and we only use these two COUNT_SHIP flags. If the ship results in a qty greater than zero then we use this flag. Ships that also set qty to 0 and therefore terminate the lot are subject to COUNT_SHIP_TO_ZERO_AS_OPER_MV

COUNT_SHIP_TO_ZERO_AS_OPER_MV

CHAR(1)

Normally we do not count any move that results in terminating the lot as an oper move. However ships can be the exception to this rule. If this flag is Y then moves where is_ship_event is Y and qty is 0 are counted as an oper move.

COUNT_UDT_TO_PM_AS_FTR

CHAR(1)

When determining if a PM was performed first time right this flag will change if determine if a PM that is done to resolve a UDT counts as part of FTR or not. Specifically the GTG window has to start in a UDT state and then go directly to an SDT state that is a PM. Y means that the SDT PM will be evaluated for FTR, if N then FTR will be null, aka not evaluated.

CREATED_INST

DATE

Time when the lot was created, either lot start or split.

CRITICAL_RATIO

NUMBER(5,3)

The critical ratio (days until due / days of CT left) for the lot

CRITICAL_TOOL_HOURS

NUMBER(5)

to determine how many hours to calculate the critical tool score; when set to 6 ours, then the scheduler will only look into how many tool are available within 6 hours and how many lots will be able to run within 6 hours

CS_SORT_IN_RT_FAM_SEG

NUMBER(7

The full name of this column is override to common step sort within route family and route segment.

CTA_MIN_ACTIVE_NUM_LOTS_BY_PRD

NUMBER(2)

To reduce the size of CTA tables, we filter low runner prds where the number of active lots (not test wafers and not in bank) is less than this number. The default is 1 which means we keep all prds with any active lots. Setting this to 2 means we filter out prds with just a single active lot. Setting this to 0 means we keep all prds even without any active lots which may be desired at smaller sites. We count by prd rather than route so we are not affected by rework routes.

CTM_COLUMN_FOR_CRIT_RATIO

VARCHAR2(30)

This tells our Critical Ratio logic which column to use to estimate expected days remaining. We recommend using FIFO for Critical Ratio because this column is not impacted by the desired cycle time for the prd or route and therefore the highest priority lots will have the highest Critical Ratio. COMMIT and TARGET are also allowed.

CTM_COLUMN_FOR_DAYS_BEHIND

VARCHAR2(30)

This tells our Days Behind logic which column to use to estimate expected days remaining. We recommend using COMMIT for Days Behind because then a lot which is perfectly paced on its Commit cycle time plan will show 0 days behind. Note that does not necessarily mean that it should be prioritized ahead of another lot which is 1 day behind because the other lot might have a much slower expectation. Using FIFO would always prioritize the highest priority lots but it would show lots that are progressing evenly but driven to a faster cycle time as behind. TARGET is also allowed.

CTM_COLUMN_FOR_EST_SMP_PCT

VARCHAR2(30)

This tells our CTM_SUMMARY logic which column to use to estimate sampling percentage. This is either FULL or LONG or 7D. The Dashboard hover message shows this configuration but it is not linked so if you change this column then you need to update DASH_C_CATEGORY_TABLE_COLS to match using the query from DWH-2030.

CTM_COLUMN_FOR_WIP_STEP_FUT

VARCHAR2(30)

This tells our WIP_STEP_FUTURE logic which column to use from CTM_SUMMARY to estimate cycle time to future steps. FULL and LONG are configurable in GEN_FACILITIES but usually 4 weeks and 2 weeks except for small fabs where we make them longer. These as well as 7D and 2D are weighted averages for only time during the period. TARGET and COMMIT are two varieties of plan cycle time. The total for each prd is set by the client via ETL in RTG_PRDS then we adjust the wait time of each step so that the total CT adds up to the total for the prd in a reasonably intelligent balance based on the history. For example, if history was 20 days proc and 50 days wait and commit is 60 then we multiply the wait time of each step by 4/5 so the total wait adds up to 40 and the total cycle time adds up to the commit value of 60. FIFO is the average for the entire process family so this represents what the cycle time would be if we ran the entire fab in FIFO order without any priority.

CTM_FACTOR

NUMBER(3,2)

Factor to multiply cycle time for this lot 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 lot group whose factor is 1.0 then we would estimate it to be 9 hours for this lot group.

CTM_FIN_PERIOD_MONTH_OR_WEEK

VARCHAR2(5)

Most sites uses our standard progression of recent months then quarters then years as the periods in Finished Lot Cycle Time but some sites prefer to use weeks. Therefore the default value here is MONTH but sites using weeks will set to WEEK.

CTM_FORECAST_COMMIT_DAYS

NUMBER(5,1)

This column has the same meaning as COMMIT_CT_DAYS but it is a forecasted value starting at a specified time in the future.

CTM_FORECAST_TARGET_DAYS

NUMBER(5,1)

This column has the same meaning as TARGET_CT_DAYS but it is a forecasted value starting at a specified time in the future.

CTM_FULL_WINDOW_WEEKS

NUMBER(3)

Number of weeks covered by full cycle time columns, e.g. step_sec_wavg_full. Please note this includes the current week-to-date so a value of 4 means the last 4 weeks plus the current week-to-date and therefore will range from 28 to 35 days. Our default for this is 4 weeks but some smaller facilities might prefer an extended window. This should be coordinated with ctm_long_window_weeks.

CTM_IDEAL_TRANSIT_CALC_TYPE

VARCHAR2(8)

The type of calculation used to determine ideal transit time for cycle time X-factor. Best bay means we pick the most likely bay a lot would go to between steps based on the tool ranks assigned generically in the flow but not specifically for the lot. Wavg bay means we take the weighted average of all delivery time options between steps based on how many tools are allowed in each bay. For both calculations, if there is an option to stay in the same bay between steps then the intrabay delivery time is always used.

CTM_LONG_WINDOW_WEEKS

NUMBER(2)

Number of weeks covered by long cycle time columns, e.g. step_sec_wavg_long. Please note this includes the current week-to-date so a value of 2 means the last 2 weeks plus the current week-to-date and therefore will range from 14 to 21 days. Our default for this is 2 weeks but some smaller facilities might prefer an extended window. This should be coordinated with ctm_full_window_weeks.

CTM_SERIES

VARCHAR2(64)

This is a grouping across facilities for our Finished Lot Cycle Time application indicating prds which make up the same or similar final product to be shipped. Prds are allowed to be in multiple series - for example when a generic prd A is assembled together with various specific prds B1, B2, B3.

CTM_VALID_LOTS_2D

NUMBER(4)

Minimum number of lots over the 2 day period required for 2 day cycle time to be considered valid. This number includes both moved lots and lots in WIP at the end of the period. In addition you must have at least one lot moved.

CTM_VALID_LOTS_7D

NUMBER(4)

Minimum number of lots over the 7 day period required for 7 day cycle time to be considered valid. This number includes both moved lots and lots in WIP at the end of the period. In addition you must have at least one lot moved.

CTM_VALID_LOTS_FULL

NUMBER(4)

Minimum number of lots over the number of weeks defined in ctm_full_window_weeks required for full cycle time to be considered valid. This number includes both moved lots and lots in WIP at the end of the period. In addition you must have at least one lot moved.

CTM_VALID_LOTS_LONG

NUMBER(4)

Minimum number of lots over the number of weeks defined in ctm_long_window_weeks required for long cycle time to be considered valid. This number includes both moved lots and lots in WIP at the end of the period. In addition you must have at least one lot moved.

CTR_BANK1

VARCHAR2(36)

In Finished Lot Cycle Time we divide the time within a facility by process state like PROC, HOLD, etc. but for banks we can use these columns to have specific common banks be their own process state for this grouping. So rather than just seeing the average time in bank if we populate this with FAB-OUT then we can see the average time in the FAB-OUT bank separately.

CTR_BANK2

VARCHAR2(36)

See comment for CTR_BANK1.

CTR_BANK3

VARCHAR2(36)

See comment for CTR_BANK1.

CTR_BANK4

VARCHAR2(36)

See comment for CTR_BANK1.

CTR_BANK5

VARCHAR2(36)

See comment for CTR_BANK1.

CUM_PLANPRD_QTY_EOL

NUMBER(15,1)

Cumulative qty for the specified planprd of the specified main route or bank. This counts from the finish so if we have a several lots with 25 units then the closest to the finish would be 25 and the next closest would be 50 then 75 and so on. We match this with the demand for the prd to determine when each lot is needed to meet demand.

CURRENT_HEALTH

NUMBER(4,3)

The current measurement of health from -3 to 3.

CURRENT_VALUE

NUMBER(12,3)

The current numeric value of the maintenance indicator.

CURR_BAY

VARCHAR2(12)

Current bay of carrier. See column comment on BAY in FPSINPUT.MHS_BAYS for more information.

CURR_BUILDING

VARCHAR2(12)

Current building of carrier. See column comment on BUILDING in FPSINPUT.MHS_BUILDINGS for more information.

CURR_COMP_TO_EARLIEST_ARRV_SEC

NUMBER(10)

The comment on CURR_COMP_TO_EXPECTED_ARRV_SEC applies here too. The only difference is that this column is what we consider the earliest possible arrival rather than the expected arrival.

CURR_COMP_TO_EXPECTED_ARRV_SEC

NUMBER(10)

We use this numeric field rather than the date field EXPECTED_ARRV_INST but the date field depends on the estimated complete of the current step which depends on the current time. Therefore in order for EXPECTED_ARRV_INST to be accurate we would have to change it every second! Instead we use this field to store the seconds from the complete of the current step to the arrival which only needs to be updated when the lot changes steps. Then we do the calculations to get EXPECTED_ARRV_INST using the current time in the WIP_STEP_FUTURE_PLUS view. For all steps which are one step away, this value is always 0 which makes sense because the complete of the current step is the same as the arrival of the next step.

CURR_FACILITY

VARCHAR2(6)

Current facility of the lot.

CURR_FAC_BANK

VARCHAR2(36)

Current bank of the lot (NA if lot is currently on a route).

CURR_FAC_PRD

VARCHAR2(64)

Current product of the lot.

CURR_FAC_ROUTE

VARCHAR2(256)

Current main route of the lot (NA if lot is currently in a bank).

CURR_FAC_STEP

VARCHAR2(256)

Current step of the lot on its current main route (NA if lot is currently in a bank).

CURR_LOC

VARCHAR2(32)

Current location of carrier. See column comment on LOCATION in FPSINPUT.MHS_RACK_LOCATIONS for more information.

CURR_LOCATION

VARCHAR2(32)

store the curr location of the lot

CURR_LOC_TYPE

VARCHAR2(64)

Current location type of carrier. See view MHS_LOCATIONS for more information.

CURR_NUM_RUNS_FAIL

NUMBER(8)

WILL REMOVE SOON

CURR_NUM_RUNS_SUCCESS

NUMBER(8)

WILL REMOVE SOON

CURR_OFFROUTE

VARCHAR2(256)

If the current route of the lot is not the same as the main route then the lot is offroute and this is the current route.

CURR_OFFRT_STEP

VARCHAR2(256)

If the current route of the lot is not the same as the main route then the lot is offroute and this is the current step.

CURR_PATTERN

VARCHAR2(2000)

the comma delimited history of process sequences run on the tool. see table comments for ground rules

CURR_PRIORITY

VARCHAR2(7)

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.

CURR_PRIORITY_REASON

VARCHAR2(128)

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.

CURR_QTY

NUMBER(7)

Current qty of the lot using quantity unit of the current facility.

CURR_RANK

VARCHAR2(1)

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.

CURR_RECIPE

VARCHAR2(100)

The current/last used recipe for the scheduler, incorporating the ignore capability from EQP_PROCESS_CHG_TO_IGNORE

CURR_RECIPE_INST

DATE

The beg processing timestamp associated with CURR_RECIPE

CURR_RUN_MODE

VARCHAR2(36)

WILL REMOVE SOON

CURR_SEC_QTY

NUMBER(7)

Current secondary qty of the lot using secondary quantity unit of the current facility.

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.

CURR_SETUP_INST

DATE

This DWH timestamp of the last setup change for this entity

CURR_STATION

VARCHAR2(32)

See column comment on STATION in FPSINPUT.MHS_STATION_ALTERNATES for more information.

CURR_STATION_TYPE

VARCHAR2(32)

Current station type of carrier. See view MHS_LOCATIONS for more information.

CUSTOMER

VARCHAR2(64)

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.

CV_OF_AV

NUMBER(*,4)

This is the coefficient of variation of availability for the tool over the period of time defined by num_days_for_cv_of_av in gen_site.

DAILY_INPUT_LIMIT_RANK

VARCHAR2(1)

Rank to assign lots at the start step when the daily input limit for the assigned start step has been exceeded

DASH_COMING_HRS_COL1

NUMBER(2)

This column in combination with the other four columns 2, 3, 4, and 5 allow the number of hours in each of the five columns other than This Shift in the WIP Coming hover to be configurable by facility. For example, FAB might want 1 hr, 4 hr, 24 hr, 48 hr, and This Shift while TEST might want 4 hr, 12 hr, 24 hr, 48 hr, and This Shift. Note that all pages (Operations, Module, Toolset, etc.) for a given facility will show the same information.

DASH_COMING_HRS_COL2

NUMBER(2)

See DASH_COMING_HRS1.

DASH_COMING_HRS_COL3

NUMBER(2)

See DASH_COMING_HRS1.

DASH_COMING_HRS_COL4

NUMBER(3)

See DASH_COMING_HRS1.

DASH_COMING_HRS_COL5

NUMBER(3)

See DASH_COMING_HRS1.

DASH_COMING_HRS_COL_FOR_PAGE

NUMBER(3)

This indicates which WIP Coming column which shows on the page (i.e. without hover over) configurable by facility. For example, FAB might want to show This Shift while TEST might want to show 24 hr.

DASH_PROC_STATE_IF_NOT_RESRV

VARCHAR2(5)

This is the process state assigned to this ECT state on the Dashboard if the lot is not reserved. This value should never be modified.

DASH_PROC_STATE_IF_RESRV

VARCHAR2(5)

This is the process state assigned to reserved lots on the Dashboard. Opinions on what to show here are widely variable so this is clearly the most commonly configurable of the five proc_state columns in this table. Scheduler will nearly always show RESRV while CTA+FLCT will always show WAIT1/WAIT2/WAIT3/DOWN/BLOCK/INHIB. The default is RESRV but it will be common to modify this to match dash_proc_state_if_not_resrv.

DATABASE_NAME

VARCHAR2(256)

The database to which this host is relevant

DATA_DATE_VALUE

DATE

This column is unusually named DATA_DATE_VALUE to avoid confusion with the frequently used DATA_DATE function. Normally we just use the function but occasionally we might want to get the column from the table rather than the function and this allows us to do this.

DAYS_FOR_RTG_PRCS_RCP_TOOL

NUMBER(3)

Number of days of WIP_STEP_HIST to use in RTG_PROCESS_RCP_TOOL_7D table which is the base for RTG_PROCESS_RCP_EQPTYPES and EQP_TOOL_PROCESSFAMS. As anyone can guess from the table name, the default is 7 days.

DAYS_TO_EOL_2D_WAVG

NUMBER(8,4)

Days until the lot is estimated to finish the specified route/bank using weighted average cycle time from the last 2 days.

DAYS_TO_EOL_7D_MED

NUMBER(8,4)

Days until the lot is estimated to finish the specified route/bank using median cycle time from the last 7 days.

DAYS_TO_EOL_7D_WAVG

NUMBER(8,4)

Days until the lot is estimated to finish the specified route/bank using weighted average cycle time from the last 7 days.

DAYS_TO_EOL_COMMIT

NUMBER(8,4)

Days until the lot is estimated to finish the specified route/bank using Commit cycle time.

DAYS_TO_EOL_DUE

NUMBER(8,4)

Days until the due date. This column is poorly named.

DAYS_TO_EOL_FIFO

NUMBER(8,4)

Days until the lot is estimated to finish the specified route/bank using FIFO cycle time.

DAYS_TO_EOL_FULL_WAVG

NUMBER(8,4)

Days until the lot is estimated to finish the specified route/bank using weighted average cycle time from the Full period.

DAYS_TO_EOL_LONG_WAVG

NUMBER(8,4)

Days until the lot is estimated to finish the specified route/bank using weighted average cycle time from the Long period.

DAYS_TO_EOL_TARGET

NUMBER(8,4)

Days until the lot is estimated to finish the specified route/bank using Target cycle time.

DAYS_TO_KEEP_HIST

NUMBER(6,2)

This is used to determine how long to keep the historical data

DAYS_TO_KEEP_PRD_ACTIVE

NUMBER(4)

Number of days without activity for which a PRD should remain in FPSBASE.RTG_ACTIVE_PRD_ROUTES_BASE.

DAYS_TO_SHOW_EVENTS_IN_DASH

NUMBER(3)

Default 7 days to show the future events in Dashboard for this MNT_FAMILY, and users can define how many days to show this in Dashboard

DAY_OF_WEEK

VARCHAR2(3)

This should be Mon, Tue, etc.

DAY_TGT_COMPLETES_OVR

NUMBER(5)

Override for day completes WIP. When populated this will replace DAY_TGT_COMPLETES calulated in FPSBASE.EQP_WIP_COMP_TGTS

DAY_TGT_WIP_OVR

NUMBER(5)

Override for day target WIP. When populated this will replace DAY_TGT_WIP calulated in FPSBASE.EQP_WIP_COMP_TGTS

DB_MACHINE

VARCHAR2(64)

For CHGLOG and automatic HIST tables, this is populated with the HOST system variable from USERENV.

DB_OSUSER

VARCHAR2(30)

For CHGLOG and automatic HIST tables, this is populated with the OS_USER system variable from USERENV.

DB_USERNAME

VARCHAR2(30)

For CHGLOG and automatic HIST tables, this is populated with the USER system variable.

DECISIONS_TO_SEND

VARCHAR2(12)

Define what decisions are sent to the MES. Possible values are SKIP, TAG, or ALL. If you only want the rule to send TAG decision, then setting this to TAG would keep SKIP decisions from being sent to the MES.

DEFAULT_ADD_TO_GP_CUTOFF_MINS

NUMBER(3)

GP cutoff time is one TCT plus one EET plus this number of minutes before the end of the shift. This is usually one hour or less and might be 0.

DEFAULT_BACKLOAD_SEC

NUMBER(5)

Use for the Scheduler to determine the time the next batch/lot can start without missing the cascade

DEFAULT_BATCH_INT_SEC

NUMBER(6)

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details.

DEFAULT_BAY

VARCHAR2(12)

for each sched group it will have default bay. this is really for the durable location issue

DEFAULT_BUILDING

VARCHAR2(12)

For sites with multiple building, some of our MHS logic uses this as a default building if the building is unknown. Also create/update scripts might use this.

DEFAULT_CAST_PORT_DOWN_SEC

NUMBER(6)

the default wait seconds to sched when the port is down

DEFAULT_DURABLE_CHG_COST

NUMBER(6)

Default durable change cost. See comments on USE_SETUP_CHG_AUTO_FOR_SCH for details on when this is used.

DEFAULT_DURABLE_CHG_EXPENSE

NUMBER(4)

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details.

DEFAULT_DURABLE_CHG_SEC

NUMBER(6)

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details.

DEFAULT_FACILITY

VARCHAR2(6)

For sites with multiple facilities, applications will default to this facility upon opening. Also create/update scripts might use this.

DEFAULT_FIRST_UNIT_SEC

NUMBER(9,3)

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details.

DEFAULT_GROSS_DIE_PER_WFR

NUMBER(6)

Used if gross_die_per_wfr is not specified for the prd

DEFAULT_LINE_SECTION

VARCHAR2(32)

Default line_section to use if not otherwise specified so the line_section field is not null. This should be the most common line_section and some facilities might only have one.

DEFAULT_LOAD_SEC

NUMBER(4)

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details.

DEFAULT_LOT_TYPE

VARCHAR2(24)

Default lot_type which we should rarely use but is our last resort if an event is inserted for a new lot of a new prd which is not in WIP_STARTS. This should probably be the standard test wafer lot type although if you get to this point it is guaranteed to be wrong much of the time.

DEFAULT_MIN_DISP_SEC

NUMBER(6)

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details.

DEFAULT_MODULE

VARCHAR2(12)

Default wip_module to use if not otherwise specified so the wip_module field is not null. This will typically be LOGISTICS or OTHER or NONE or similar.

DEFAULT_NUM_RUNS_FAIL

NUMBER(4)

WILL REMOVE SOON

DEFAULT_NUM_RUNS_SUCCESS

NUMBER(4)

WILL REMOVE SOON

DEFAULT_PLANPRD

VARCHAR2(64)

The normal or most frequently used planprd for this prd. At most sites each prd will only use one planprd which is this default_planprd but multiple planprds is allowed. For detailed information, see table comments in RTG_PLANPRDS.

DEFAULT_PLAN_PRIORITY

VARCHAR2(7)

Default plan_priority to use if not otherwise specified so the plan_priority field is not null. This should be the normal or standard priority.

DEFAULT_PROCESS_CHG_COST

NUMBER(6)

Used for Scheduler. Default process change cost.

DEFAULT_PROCESS_CHG_SEC

NUMBER(6)

Used for Scheduler. Default process change seconds.

DEFAULT_PROCESS_FAMILY

VARCHAR2(50)

See https://help.inficonims.com/display/DW/Guide+to+Process+Families.

DEFAULT_PROCFAMGRP_FOR_EQP

VARCHAR2(36)

Default process_family as well as process_group for tools where nothing is assigned in RTG_TOOL_ASSIGNMENTS.

DEFAULT_PROC_CT_SEC

NUMBER(4)

See comment on DEFAULT_WAIT_CT_SEC column.

DEFAULT_QTY_MEAS

NUMBER(7)

Default number of wafers measured in a lot on the tool in the family. This is used if the number of wafers measured is not specified for a particular lot.

DEFAULT_RECIPE_CHG_COST

NUMBER(6)

Default recipe change cost. See comments on USE_SETUP_CHG_AUTO_FOR_SCH for details on when this is used.

DEFAULT_RECIPE_CHG_EXPENSE

NUMBER(4)

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details.

DEFAULT_RECIPE_CHG_SEC

NUMBER(6)

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details.

DEFAULT_SETUP_CHG_COST

NUMBER(6)

Default setup change cost. See comments on USE_SETUP_CHG_AUTO_FOR_SCH for details on when this is used.

DEFAULT_SETUP_CHG_EXPENSE

NUMBER(4)

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details.

DEFAULT_SETUP_CHG_SEC

NUMBER(6)

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details.

DEFAULT_SORT_COLUMN_ID

VARCHAR2(100)

The column used to sort the records in the table when the page is initially generated. This must be a column where should_display is set to Y. Sort direction is Ascending or Descending based on the value of default_sort_direction for this column in DASH_C_COLUMNS.

DEFAULT_SORT_DIRECTION

VARCHAR2(20)

This controls the default sort order for each column. For most numeric values like WIP, Completes, Pace, Targets, Scrap, and so on, it makes sense for the default sort direction to be Descending. For example, if you click on the column header to sort by Completes that you expect to see records with the most Completes on top. Of course it is still possible to click a second time to sort Ascending if you really want to see the records with the fewest Completes on top but that would be the exception.

DEFAULT_STEP_SEC

NUMBER(7)

This is used as the default for the process family in the fillin logic in CTM_SUMMARY.

DEFAULT_SYSMNTR_EMAIL_LIST

VARCHAR2(1000)

For SYSMNTR_P_CHK views which do not have specific configuration records in SYSMNTR_C_CHECKS we will send emails to this list. Typically it is fps-xxxdwhteam@inficon.com where xxx is the client or site name and obviously this must be a valid email address.

DEFAULT_UNAVAILABLE_SEC

NUMBER(6)

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details.

DEFAULT_UNIT_INT_SEC

NUMBER(9,3)

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details.

DEFAULT_UNLOAD_SEC

NUMBER(4)

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details.

DEFAULT_WAFER_SIZE

VARCHAR2(8)

Default wafer_size to use if not otherwise specified so the wafer_size field is not null. Facilities with only one wafer_size should just set this column and then not specify a value by prd. For facilities with more than one this should be the most common wafer_size in the facility.

DEFAULT_WAIT_CT_SEC

NUMBER(5)

The default cycle time for miscellaneous steps that are in process families with no valid cycle time are 10 minutes processing and 20 minutes waiting for a total of 30 minutes. This column along with default_proc_ctm_sec allows us to change these defaults. The most likely change would be to 0 seconds processing and 1 second waiting to essentially ignore all miscellaneous steps.

DEF_BAY_TO_BAY_TRANSPORT_MODE

VARCHAR2(10)

Default building level bay to bay transport mode. If no other mode is specified, this will be the value used to direct wip within a building from bay to bay.

DEF_CAST_TRANSIT_SEC_BAY_CART

NUMBER(5)

Default transit time for a cassette to move from a cart to any bay in the same building.

DEF_CAST_TRANSIT_SEC_DIFF_BLDG

NUMBER(5)

Default transit time for a cassette to move between different buildings.

DEF_CAST_TRANSIT_SEC_NEAR_BAY

NUMBER(5)

Default transit time for a cassette to move to a nearby bay.

DEF_CAST_TRANSIT_SEC_SAME_BAY

NUMBER(5)

Default transit time for a cassette to move to a different station in the same bay.

DEF_CAST_TRANSIT_SEC_SAME_BLDG

NUMBER(5)

Default transit time for a cassette to move to another bay in the same building.

DEF_POD_TRANSIT_SEC_BAY_CART

NUMBER(5)

Default transit time for a pod to move from a cart to any bay in the same building.

DEF_POD_TRANSIT_SEC_DIFF_BLDG

NUMBER(5)

Default transit time for a pod to move between different buildings.

DEF_POD_TRANSIT_SEC_NEAR_BAY

NUMBER(5)

Default transit time for a pod to move to a nearby bay.

DEF_POD_TRANSIT_SEC_SAME_BAY

NUMBER(5)

Default transit time for a pod to move to different station in the same bay.

DEF_POD_TRANSIT_SEC_SAME_BLDG

NUMBER(5)

Default transit time for a pod to move to another bay in the same building

DELIVERIES_PER_MIN

NUMBER(5,2)

The interpolated delivery rate per minute. A delivery will count only after the dropoff

DELIVERIES_THIS_SESSION

NUMBER(5)

Total deliveries for the user session

DELIVERY_STATE

VARCHAR2(32)

The carrier delivery state.

DELTA_TYPE

VARCHAR2(12)

Delta_type is the reason why the qty changed. It is populated with a value in WIP_DELTA_TYPES (SCRAP, SPLIT, etc.) for all records where qty_delta != 0. It is null for normal moves where is_next = Y and the qty does not change. The logic to populate this is in WIP_STEP_HIST_INSERT_BEF.

DEMAND_INST

DATE

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.

DEMAND_QTY

NUMBER(9)

Number of wafers committed in the demand.

DESCRIPTION

VARCHAR2(256)

Tool desciption. This value is only used to display in the Dashboard.

DEST_FACILITY

VARCHAR2(6)

Facility where the lot will go after it completes its route in the current facility.

DEST_PRD

VARCHAR2(64)

Prd which will the lot will assume after it completes its route in the current facility. This could be the same as the current prd.

DEST_PREFERENCE

NUMBER(3)

When a source product has multiple options for its next product this field indicates the preference. Usually this is 1.

DEST_STATION

VARCHAR2(32)

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

DETAILS

VARCHAR2(2000)

A concatenation of all the other fields that can be inserted by FabGuard Broker procedures.

DETECTION_SEC_AVG_LOWER_LIMIT

NUMBER(8)

Tool level limit that is used to highlight in the dashboard how many tools have an average time to detect under the lower limit value. The time to detect is the gap between each measurement, only considering measurments that clear a counter.

DETECTION_SEC_AVG_UPPER_LIMIT

NUMBER(8)

Tool level limit that is used to highlight in the dashboard how many tools have an average time to detect under the upper limit value. The time to detect is the gap between each measurement, only considering measurments that clear a counter.

DETECTION_SEC_MAX_LOWER_LIMIT

NUMBER(8)

Tool level limit that is used to highlight in the dashboard how many tools have a max time to detect under the lower limit value. The time to detect is the gap between each measurement, only considering measurments that clear a counter.

DETECTION_SEC_MAX_UPPER_LIMIT

NUMBER(8)

Tool level limit that is used to highlight in the dashboard how many tools have a max time to detect under the upper limit value. The time to detect is the gap between each measurement, only considering measurments that clear a counter.

DIRECTION_OF_INCREASE

VARCHAR2(8)

This column determines if an increase in the KPI Result value after a scenario run indicates a positive outcome. Value can be POSITIVE, NEGATIVE, or IGNORE. If set to IGNORE, Scheduler will ignore the change in result and not use a visual indicator.

DISPATCH_CAPACITY

NUMBER(4)

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details.

DISPATCH_INST

DATE

Time when the lot indicated in the MES that it will process on the tool. As opposed to reserve, dispatch cannot be automatically undone.

DISPATCH_INST_OF_START_STEP

DATE

Time when the lot was dispatched to the tool at the step which starts the queue timer.

DISPATCH_NUM_STEPS_AWAY

NUMBER(2)

used to determine how many steps away for the coming lots to become eligible to dispatch

DISPATCH_RULE

VARCHAR2(64)

Optional field to store the dispatch rule used for the equipment type if known. This is not used in our DWH logic. This field could be set for informational purposes from the dispatching configuration file/table or this could be the real source of the dispatch rule and the dispatch system could query this table.

DISPATCH_RULES

VARCHAR2(36)

used to define the order of dispatching: 0. timer lots, the timer lot at least needs to be nearby and in-danger 1. lot on tool; durable on tool 2. lot on tool; durable near tool (on tool or stocker) 3. lot near tool; durable on tool 4. lot near tool; durable near tool 5. lot on tool; 6. lot near tool; 7. sched-rank-1 lot, currently at the operation; 8. enable dispatch based on lot priority; for example, (1):(3):(2):(4) -> will dispatch 1 first and followed by 3 and then 2 and then 4; for example, (1):(2|3):(4) -> will dispatch 1 first and followed by (2 or 3) and then 4;

DISPATCH_SEC

NUMBER(6)

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details.

DISPLAY

VARCHAR2(32)

This is the short description to show on the scheduler web ui

DISPLAY_SORT

NUMBER(3)

Sort rank to display in NextMove. Lower numbered badges will display furthest to the left

DOWN_REASON

VARCHAR2(36)

A value from a reasonably short list of user-defined reasons why the entity went down.

DO_NOT_CHECK_DIFFS_LOOP

CHAR(1)

For tables loaded by ADM_TABLE_LOOP the default is to use a minus query to check for differences and only update the necessary rows. But if we know that all rows will change on each load then we can skip this check and just update all rows.

DO_NOT_COMMIT

CHAR(1)

If this is set to Y then we will not commit after this object. This allows an entire job consisting of multiple objects to run and then commit at the end. Our 3min job must have this flag set to Y.

DO_NOT_COUNT_OPER_MOVE_FROM

CHAR(1)

We might never want to count oper moves from certain special operations like staging or adhoc.

DO_NOT_COUNT_OPER_MOVE_TO

CHAR(1)

We might never want to count oper moves to certain special operations like staging or adhoc

DO_NOT_INS_HIST

CHAR(1)

If set to Y during an update, then the ETP_STATUS_AFTER trigger will *not* write the previous contents of the row to ETP_HIST. Default is N.

DO_NOT_WARN_FPSINPUT_DBPR

CHAR(1)

We strongly discourage use of DBPR for FPSINPUT tables because the refresh deletes and reinserts every row in the table. CHK_LOAD warns against this configuration. But there are certain cases where DBPR is appropriate, for example when the start date in WIP_STARTS changes almost every query in the customer data, so if this flag is set then we do not warn about this.

DRUM_COMP_HIST_ROLL_HOURS

NUMBER(3)

Number of rolling hours to check for completes that will be compared to the drum target to determine a delta to target and corresponding priority. This value only applies if the DRUM_COMP_HIST_TYPE is set to ROLLING.

DRUM_COMP_HIST_ROLL_HOURS_LONG

NUMBER(3)

This is the same as DRUM_COMP_HIST_ROLL_HOURS except for a longer period of time. Setting both values allows tracking of both a short and long period, such as shift and day drum or day and week drum. Use of this longer period is optional. Step priority is given based on the following hierarchy: 1) Missing both long and short periods, 2) Missing the long period, Missing the short period.

DRUM_COMP_HIST_TYPE

VARCHAR2(8)

The type of historical calculation that will be done for comparing completes to the drum target to determine a delta to target and corresponding priority. Allowed values are SHIFT, PLAN DAY, and ROLLING. SHIFT is from the start of the current shift to date. PLAN DAY is from the start of the current plan day to date. ROLLING is a rolling number of hours as defined in DRUM_COMP_HIST_ROLL_HOURS.

DRUM_CRITERIA

VARCHAR2(513)

This is the level of counting that will be multiplied by within the scheduler to dynamically score the drum rate as lots are placed on a schedule run

DRUM_GROUPING

VARCHAR2(24)

Allowed values are "ROUTE STEP", "ROUTE FAMILY COMMON STEP", "ROUTE GROUP COMMON STEP", "COMMON STEP", "ROUTE FAMILY PROCESS", "ROUTE GROUP PROCESS", and "PROCESS". This determines the level at which the drum is aggregated. ROUTE STEP means the drum calculation is evaluated within each route for each step. COMMON STEP means the drum calculation is evaluated across routes for each COMMON STEP, assuming common steps are shared across routes. PROCESS means the drum calculation is evaluated across routes for each PROCESS, assuming processes are shared across routes.

DRUM_MV_FACTOR

NUMBER

This is the per move factor in which the drum rate will adjust for use in the scheduler to dynamically score the drum rate as lots are placed on a schedule run

DRUM_NORMALIZATION_GROUPING

VARCHAR2(32)

See comments on LB_NORMALIZATION_GROUPING. This field does the same thing for drum scoring

DRUM_NORMALIZATION_METHOD

VARCHAR2(24)

See comments on LB_NORMALIZATION_METHOD. This field does the same thing for drum scoring

DRUM_QTY

NUMBER(5)

Desired shift run rate for a route section by route and process

DUE_INST

DATE

To indicate the due date for this futuer start lot

DURABLE

VARCHAR2(64)

Durables are either reticles for Litho or probe cards for Wet or Sort. A durable can either be in a carrier or at a location without a carrier.

DURABLE_CARRIER

VARCHAR2(32)

The durable carrier ID of the durable required for this carrier to process.

DURABLE_CLASS

VARCHAR2(36)

The class of the durable becomes important when we have multiple durables assigned in RTG_DURABLE_ASSIGNMENTS. If these durables are in different classes then we know that both of them are required. For example, a tester might require both a probe card and an electrical board. If these durables are in the same class then we use the is_multiple_required field to determine whether we will choose either or need both.

DURABLE_CLASS_ABBR

VARCHAR2(3)

Abbreviation of durable class like RET or PC.

DURABLE_FAMILY

VARCHAR2(64)

Durable_family indicates what durable is required by the process. When multiple durables are in a family any of them can be used. Typically there is only one reticle per family and therefore the durable and durable_family are the same. The exception would be a high running product with backup reticles. However for probe cards it is common to have several cards for each product so we have several durables with the same family.

DURABLE_GROUP

VARCHAR2(64)

Durable group is the parent of family and the child of class and its only use is to track the time to change durables. In many cases, group will be the same as class. An example where group would be different than class is where we have different reticles for different stepper manufacturers so the durable_group would be Nikon or Canon or ASML while the durable_class would be DURABLE.

DURABLE_LOCATION

VARCHAR2(32)

The location of the durable.

DURABLE_PARM1

VARCHAR2(128)

User-defined parameter which can store any value relevant to the durable. Description of use should be noted in the RTG_DURABLES ETL.

DURABLE_REQUESTED_INST

DATE

will be the time that the durable needed by the lot to process

DURABLE_STATE

VARCHAR2(36)

Durable state indicates the current state of the durable The value must be one of those defined by FPS in FPSADMIN.MHS_CARRIER_STATES. This is a short list of simple states like OK or WARN or DOWN in contrast to the complex options available for equipment states. This would be used as a filter/sort on what durables could be used for scheduling. For example, if there are two durables in the durable_family and one is OK and the other is DOWN then we schedule using the OK durable. But if there is only one durable in the family then we cannot schedule any lots which require this family if that lone durable is DOWN.

DURABLE_STATE_DISPLAY

VARCHAR2(128)

The name of the durable state displayed on all dashboards and reports. Durable_state must match the FPS list defined in MHS_DURABLE_STATES but this display field might be formatted in a more familiar way to the users in the facility.

DURABLE_THP_VARIATION

VARCHAR2(64)

When this column is populated that means that we have a choice of durable families and that processing time for the lot/recipe depends on which durable family is chosen. The most common use case is 8 pin and 16 pin probe cards. This will be blank for reticles and other cases where the throughput is not dependent on the durable. This is part of the primary key of our throughput logic where nulls are filled in as NA since PK columns cannot be null. In our first example, we have a recipe WAFER_TEST_1 that we use for a whole bunch of different prds. Each prd requires its own probe card but for throughput purposes we do not care about the prd. We just care about the recipe which is WAFER_TEST_1 and we would set duration_thp_variation to 8pin or 16pin. Then we would group all prds that use WAFER_TEST_1 and ran with an 8 pin probe card together in the same THP record. Our second example is similar to the first but for throughput purposes each prd will be different. We would set duration_thp_variation to the durable family for this case. In our third example, the recipe is different for each prd. In this case, we would set duration_thp_variation to either 8pin and 16pin or to the durable family and get the same result.

DURABLE_UNAVAILABLE_INST

DATE

will be the time when the durable becomes unavailable

DURATION_SEC

NUMBER(9)

Duration in seconds of the period to be used to run the APF report. Used only for CLR, CLRA, and QE.

E10_FROM_INST

DATE

Time when the entity was logged into the E10 state of the episode.

E10_TO_INST

DATE

Time when the entity was logged out of the E10 state of the episode.

E58_SUBSTATE

VARCHAR2(24)

Substate for SEMI E58 categorization. This is for reference and reporting only and can be left balnk

EARLIEST_DISP_INST

DATE

the earliest scheduled dispatch time that lots request to use this durable to process

EARLIEST_REQUESTED_INST

DATE

the earliest step enter time that lots request to use this durable to process

EARLIEST_SCHED_START

DATE

the earliest scheduled process start time that lots request to use this durable to process

EARLY_DUE_INST

DATE

to store the early due time of the floating PM tool event, i.e., the early start time of the floating PM could be calculated via substracting the EST_DURATION_SEC value

EARLY_INST

DATE

Earliest time when maintenance can be started.

ECTA_ECTFL_PROC_STATE

VARCHAR2(5)

This is the process state assigned to this ECT state on the CTA and FLCT. Since the Reserved process state is not used in CTA and FLCT (we always count the time when the lot is reserved in the appropriate WAIT1/WAIT2/WAIT3/DOWN/BLOCK/INHIB process state) then this should rarely be modified and should nearly always be the same as dash_proc_state_if_not_resrv except when using older versions of CTA which do not understand the newer states INHIB and STUCK.

ECT_STATE

VARCHAR2(42)

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.

ECT_TO_INST

DATE

See comments on WIP_LOT_HIST.NEXT_INST.

ECT_TO_INST_NOT_NULL

DATE

See column comments for WIP_LOT_HIST.NEXT_INST.

EET_SEC

NUMBER(7)

End-to-end time in seconds

EFFECTIVE_CASCADE_LENGTH

NUMBER(5,3)

This is the ratio of the total number of jobs to the number of non-cascading jobs. (Again, discarding outliers beyond the 10%-90% range for total process time.)

EFFECTIVE_CASCADE_RATE

NUMBER(4,3)

This is the weighted average of the fraction of total process time which overlaps with the previous job. This will always be less than or equal to the bottleneck_cascade_rate (outliers beyond 10%-90% for total process time are thrown out).

ELIGIBILITY_MESSAGE

VARCHAR2(4000)

This column stores eligibility messages for this tool assignment.

EMAIL

VARCHAR2(128)

Email address of the user.

EMAIL_ALERT_LIMIT

NUMBER

Send e-mail alert when the tablespace used data is greater than the percentage of the total space.

EMAIL_LIST

VARCHAR2(1000)

This field can contain on or more email addresses separated by spaces. To send text messages you enter the mobile phone number in email format which is dependent on the phone service provider.

ENABLE_DISPATCH

CHAR(1)

Enable/Disable Dispatch by Lot Priorities

ENABLE_GTG_AND_FTR_UPDATES

CHAR(1)

The merge statement to update GTG and FTR information which is the entirety of the UPDATE_ETP_MNT_EPISODE_HIST procedure was found to be very fast at some sites and extraordinarily slow at other sites. This parameter allows us to disable this at the slow sites.

ENABLE_SENDING_ALERT

CHAR(1)

To indicate if the scheduler will send the alert while scheduler run failed. SYSMONITOR will only send the alert when SCHED_GROUP_STATE = OFF and ENABLE_SENDING_ALERT = Y

END_AVAIL

DATE

Time stamp when the schedule_id ended.

END_BANK_SEQ_NUM

NUMBER(2)

Most products only have one end bank so this should almost always be set to 1. But we have seen prds that have multiple end banks and here is where we indicate the order of the banks.

END_BANK_STRUCTURE

VARCHAR2(11)

Indicates the ordering and structure of end-banks for a given PRD: if SEQUENTIAL, then WIP moves from the PRD route through the N end-banks in sequence (END_BANK_SEQ_NUM=1..N); if PARALLEL, then WIP moves from the PRD route to only of of the N end-banks (END_BANK_SEQ_NUM=1).

END_INST

DATE

The time the even is scheduled to end

END_PLAN_DAY

DATE

It is critical that this field equal the start_plan_day of the next plan day.

END_PLAN_MONTH

DATE

It is critical that this field equal the start_plan_month of the next plan month.

END_PLAN_QUARTER

DATE

It is critical that this field equal the start_plan_quarter of the next plan quarter.

END_PLAN_WEEK

DATE

It is critical that this field equal the start_plan_week of the next plan week.

END_PLAN_YEAR

DATE

It is critical that this field equal the start_plan_year of the next plan year.

END_PROC_INST

DATE

time when the lot finished processing on the main tool.

END_PROC_INST_OF_START_STEP

DATE

Time when the lot ended processing on the tool at the step which starts the queue timer.

END_REP_START_SHIFT

CHAR(1)

This column is obsolete and will be dropped from the table in the next DWH version.

END_ROUTE_IF_DIFF

VARCHAR2(256)

Most normal queue timers start and end on the same route and for these we leave this column blank. However some timers start on a rework route and ending on the main route so this column allows us to support this. We would populate the route column with the rework route (the start step would be on this rework route) and this end_route_if_diff column with the main route (the end step would be on this main route).

END_SHIFT

DATE

End of shift must be equal to the start of the next shift. Please note that the exact time which is both of the end of the previous shift and the start of the next shift is included in the next shift. In other words, start_shift <= inst < end_shift.

END_STEP

VARCHAR2(256)

The step upon move out where the WIP balance limit is no longer applied

END_WEEK

DATE

It is critical that this field equal the start_week of the next work work.

END_WORK_DAY

DATE

It is critical that this field equal the start_work_day of the next work day.

END_WORK_MONTH

DATE

It is critical that this field equal the start_work_month of the next work month.

END_WORK_QUARTER

DATE

It is critical that this field equal the start_work_quarter of the next work quarter.

END_WORK_YEAR

DATE

It is critical that this field equal the start_work_year of the next work year.

ENGR_COMMENT

VARCHAR2(128)

Special comments made by engineering about this lot. These comments are about the lot in general and not about a specific step.

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.

ENTITY_TYPE

VARCHAR2(12)

the entity type for this process max usages. only allow chamber, tool

ENT_OR_CARR_OR_DUR

VARCHAR2(1)

Upcoming maintenance for entities, carriers, and durables is included together in this table. An E here indicates that the `logged_entity` field in this table is an entity, C for carrier, and D for durable.

EOL_INST_2D_WAVG

DATE

Date/time when the lot is estimated to finish the specified route/bank using weighted average cycle time from the last 2 days.

EOL_INST_7D_MED

DATE

Date/time when the lot is estimated to finish the specified route/bank using median cycle time from the last 7 days.

EOL_INST_7D_WAVG

DATE

Date/time when the lot is estimated to finish the specified route/bank using weighted average cycle time from the last 7 days.

EOL_INST_COMMIT

DATE

Date/time when the lot is estimated to finish the specified route/bank using Commit cycle time.

EOL_INST_FIFO

DATE

Date/time when the lot is estimated to finish the specified route/bank using FIFO cycle time.

EOL_INST_FULL_WAVG

DATE

Date/time when the lot is estimated to finish the specified route/bank using weighted average cycle time from the Full period.

EOL_INST_LONG_WAVG

DATE

Date/time when the lot is estimated to finish the specified route/bank using weighted average cycle time from the Long period.

EOL_INST_TARGET

DATE

Date/time when the lot is estimated to finish the specified route/bank using Target cycle time.

EPISODE_FROM_INST

DATE

Start of the episode is when the last production lot missed the cascade unless there is no WIP then it is when the entity was logged into the E10 state of the episode.

EPISODE_TO_INST

DATE

End of the episode is when the first production lot started unless there is no WIP then it is when the entity was logged out of the E10 state of the episode.

EQP_E10_INST

DATE

Time when the e10_state of the eqp_state last changed.

EQP_FROM_INST

DATE

Time when the eqp_state changed for any entity on this main tool.

EQP_INC_BATCH_PCT

NUMBER(3,1)

If the input data already knows the incomplete batch percent then we can input it in this value with the event and we will use it for eqp_state calculations. Normally this is blank and we calculate etp_inc_batch_pct from the lot events.

EQP_MODULE

VARCHAR2(12)

EQP_MODULE is the module responsible for operating the tool. See comments on the module column in GEN_MODULES for info on this column and how it relates to eqp_module and mnt_module.

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.

EQP_STATE_CHG_COMMENT

VARCHAR2(512)

Comment with the event that last changed the eqp_state.

EQP_STATE_CHG_EVENT

VARCHAR2(48)

Event that last changed the eqp_state.

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.

EQP_STATE_CHG_OPERATOR

VARCHAR2(64)

Operator who logged the event that last changed the eqp_state.

EQP_STATE_DISPLAY

VARCHAR2(48)

Display name for the equipment state which will be displayed on all Dashboards and reports.

EQP_STATE_OWNER

VARCHAR2(48)

Person or department who owns each state. This is for reference and reporting only and can be left blank

EQP_STATUS_COMMENT

VARCHAR2(256)

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

EQP_TOOL_PCT

NUMBER(7,4)

Percentage contribution of this entity to the full tool using cluster tool calculations for eqp_state built in to DWH. This adds to 100 for all entities on a tool at each eqp_inst.

EQP_TYPE

VARCHAR2(50)

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.

ERROR_PRIORITY

VARCHAR2(10)

This is just informative and used in FPSRPT objects but this could be used in SYSMNTR in the future. It is a string field so it can be a word or a number.

ERR_IF_NO_ROWS

CHAR(1)

If set to Y then the job will error if no rows are inserted. This cannot be used with DBPM because the match logic frequently updates no rows.

EST_CH_USED

VARCHAR2(24)

Estimate of which chambers will used to process this lot based on assignments and status

EST_CURR_DIE_QTY

NUMBER(7)

Estimated die qty based on current qty and no yield loss. If the current die qty is unknown then the current wafer quantity is multiplied by gross die per wafer.

EST_DIE_QTY_AT_EOL

NUMBER(7)

The estimated die quantity when the lot finishes the route/bank listed. The calculation is based on line yield and sort yield from the current step to the end of the route/bank. If current die qty is unknown is calculated we estimate using gross_die_per_wfr.

EST_DUE_INST

DATE

Best guess at when the mnt event was due. For non-counter-based values chances are this came from the ETL. For counter-based values we use the rate of change.

EST_DURABLE_USED

VARCHAR2(129)

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.

EST_DURATION_SEC

NUMBER(8)

Estimate of the duration of the future hold if known. If blank we use the estimate for the hold_type.

EST_LINE_YIELD_PCT

NUMBER(6,3)

Estimated line yield percent for the route-step. Leave blank for the default of no loss expected. A value of 99.5 means we expected 1 unit out of 200 to be lost.

EST_MACHINE_RECIPE

VARCHAR2(100)

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.

EST_MFG_INST_IF_NONMFG

DATE

This is the forecast when the entity will return to a manufacturing state (PRD/SBY) after its current ENG/SDT/UDT/NST is completed. This value should only be populated when the eqp_state has the e10_state of ENG/SDT/UDT/NST.

EST_MNT_DURATION_SEC

NUMBER(8)

Est_mnt_duration_sec is the estimate of the total duration of the maintenance in seconds including work time, wait time, and qual time. Est_mnt_duration_sec is required then if desired, this total can be broken down into est_mnt_work_sec, est_mnt_wait_sec, and est_mnt_qual_sec. These three breakdown columns are optional but if any of those three columns are populated then they must sum to the value of est_mnt_duration_sec. Only est_mnt_duration_sec is used in FPS applications. The other three are available for informational purposes and to use for custom reporting but are not currently used in any FPS application.

EST_MNT_QUAL_SEC

NUMBER(8)

See column comment for est_mnt_duration_sec.

EST_MNT_WAIT_SEC

NUMBER(8)

See column comment for est_mnt_duration_sec.

EST_MNT_WORK_SEC

NUMBER(8)

See column comment for est_mnt_duration_sec.

EST_QTY_AT_ARRV

NUMBER(7)

This column degrades the current qty by the estimated line yield at steps between the current step and future step so this represents the expected qty of the lot when it arrives to the future step. This is unlikely to be different than the current qty in a Fab but is quite important for Test/Sort/Assembly.

EST_QTY_AT_EOL

NUMBER(8,1)

The estimated quantity when the lot finishes the route/bank listed in units of the facility listed. The calculation is based on line yield from the current step to the end of the route/bank listed. So if the route/bank is in the future then the upcoming routes/banks starting with the current one are included since we expect those wafers to be lost between now and the end of the future route/bank listed. This does not include sort yield.

EST_REWORK_PCT

NUMBER(5,3)

Estimated percentage of lots completing this step which will go to rework. This is used for capacity modeling.

EST_SMP_PCT

NUMBER(5,2)

Smp_pct tells you what percentage of the lots complete on a tool. Some sites skip steps by jumping over them so we see the lot move from step 3 to step 5 and we only know that it jumped step 4 because step 4 is on the route between 3 and 5. Other sites skip steps by moving lots into them and then moving them out a second later so we see a move from 3 to 4 at 11:11:11 and a move from 4 to 5 at 11:11:12. We do not care how it is done but just that the lot did not process at step 4 -- and to be more specific that no tool capacity is required to process this lot at step 4 and no cycle time is accumulated at step 4.

EST_SORT_YIELD_PCT

NUMBER(6,3)

Estimated sort yield percent for the product-step. Leave blank for the default of no loss expected. A value of 99.5 means we expected 1 unit out of 200 to be lost.

EST_START_INST

DATE

Best guess at when the mnt event started. If actual_start_inst is provided it will be that value otherwise it will be the inst - est_mnt_duration_sec

EST_USE_PCT

NUMBER(5,2)

Estimated use percentage is the percentage of units of this route-step that we expect to run on this eqp_type. Normally we use historical data to calculate this for the Capacity Model but entering a value in the OVR table manually overrides that historical number.

EST_USE_PCT_REASON

VARCHAR2(12)

This field explains which level of fill-in was used to calculate the est_use_pct.

ETL_LINK_OR_APF_OR_MIXED

VARCHAR2(5)

This is the mode of ETL used for the site. LINK means all tables are populated via APD/REF views using a database link. APF means all tables are populated via APF using Load_FPS_DWH.sh. MIXED means that we use some of each.

ETP_BEG_ACTION

VARCHAR2(24)

This is the action passed to the UPDATE_ETP_STATUS_BEG procedure and is useful for debugging ETP to see what action this event triggered.

ETP_FROM_INST

DATE

Time when the etp_state changed for any entity on this main tool.

ETP_INC_BATCH_PCT

NUMBER(3,1)

Incomplete batch percentage is only set for processing states. In the final calculation, the time processing an incomplete batch is divided into the production state and an incomplete batch state.

ETP_STATE

VARCHAR2(48)

If entity is down then use eqp_state directly. If entity is up then determine etp_state from proc_state and sby_state.

ETP_STATE_CHG_INST

DATE

Time when the etp_state changed for this entity.

ETP_TOOL_PCT

NUMBER(7,4)

Percentage contribution of this entity to the full tool using cluster tool calculations for etp_state built in to DWH. The main difference from eqp_tool_pct is this includes throughput estimates for partial chambers. This adds to 100 for all entities on a tool at each eqp_inst.

EVALUATE_FTR

CHAR(1)

This flag will determine if we should evaluate First Time Right (FTR) for these events, Y means we will report FTR, N means we will not report FTR.

EVALUATION_METHOD

VARCHAR2(8)

Used to define how the scheduler will evaluate each lot for scheduling if it has multiple steps to schedule once, for example for the timer lot. The available options: FIRST: it will take the first step of the sequence of steps to calcualte the lot score CURRENT: it will take the current step (the next step to schedule) of the sequence of steps to calcualte the lot score LAST: it will take the last step of the sequence of steps to calcualte the lot score AVERAGE: it will take the average score from each step in this sequence for the lot score MAX: it will take the maximum score from each step in this sequence for the lot score MIN: it will take the minimum score from each step in this sequence for the lot score for example, lot A has step 1, 2 3 to schedule, and currently the first lot to be scheduled is 2: FIRST: 1 CURRENT: 2 LAST: 3 AVERAGE: avg(1, 2, 3) MAX: max(1, 2, 3) MIN: min(1, 2, 3)

EVENT

VARCHAR2(48)

This is the event registered in the MES. This is for the historical record and display only. Each event is mapped to an FPS event_type and the event_type is what is used by FPS applications.

EVENT_CATEGORY

VARCHAR2(40)

to store the event_category, e.g., NOT_TO_SCHEDULE, NOT_TO_START etc.

EVENT_CLASS

VARCHAR2(128)

Event class is the highest level in the maintenance event hierarchy. This level could denote what team is responsible for the events. e.g. Maintenance, Operations

EVENT_COMMENT

VARCHAR2(512)

Comment associated with the event.

EVENT_CREATE_INST

DATE

Time when the hold event was created in the MES or other host system.

EVENT_DESC

VARCHAR2(500)

Event Description

EVENT_GROUP

VARCHAR2(128)

Event group is the second highest level in the maintenance event hierarchy it could be used to denote the group even maintenance definitions such as PMs, Adhoc tasks, OCAPS, Quals, or inspections. This grouping will be a collection of maintenance definitions.

EVENT_ID

VARCHAR2(64)

Field that uniquely identifies the maintenance task definition in the facility. `Event_id` is usually a number or code from the maintenance system, but it could also be defined as `logged_entity` concatenated with `mnt_name`, since that combination also uniquely represents an event. It is important to ensure that our definition of `event_id` represents repeated instances of the same maintenance event with the same `event_id`. For example, if we have a monthly PM on tool T1, there will be instances of this event each month. The field used as `event_id` could be something like T1 monthly PM; it should *not* be something like T1 monthly PM Jan, T1 monthly PM Feb, etc., since this would cause the `event_id` to change every month.

EVENT_INST1

DATE

User-defined field which can store any instant relevant to the event. Description of use should be noted in WIP_EVENTS table.

EVENT_INST1_DESC

VARCHAR2(128)

Description of the value written to the user-defined column event_inst1 in WIP_EVENT_HIST for this event_type.

EVENT_INST2

DATE

User-defined field which can store any instant relevant to the event. Description of use should be noted in WIP_EVENTS table.

EVENT_INST2_DESC

VARCHAR2(128)

Description of the value written to the user-defined column event_inst2 in WIP_EVENT_HIST for this event_type.

EVENT_INST3

DATE

User-defined field which can store any instant relevant to the event. Description of use should be noted in WIP_EVENTS table.

EVENT_INST3_DESC

VARCHAR2(128)

Description of the value written to the user-defined column event_inst3 in WIP_EVENT_HIST for this event_type.

EVENT_KEY

VARCHAR2(512)

EVENT_KEY needs to be populated with a unique value for each different future hold. The idea here is that if we have a line hold that all lots on hold for that same line hold have the same EVENT_KEY. Where the MES does not create a unique key for each line hold, we use EVENT_COMMENT as EVENT_KEY, and we hash it prior to passing it as a key to the web applications.

EVENT_NUM1

NUMBER(10)

User-defined field which can store any number relevant to the event. Description of use should be noted in WIP_EVENTS table.

EVENT_NUM2

NUMBER(10)

User-defined field which can store any number relevant to the event. Description of use should be noted in WIP_EVENTS table.

EVENT_NUM3

NUMBER(10)

User-defined field which can store any number relevant to the event. Description of use should be noted in WIP_EVENTS table.

EVENT_PARM1

VARCHAR2(128)

User-defined parameter which can store any value relevant to the event. Description of use should be noted in WIP_EVENTS table.

EVENT_PARM1_DESC

VARCHAR2(128)

Description of the value written to the user-defined column event_parm1 in WIP_EVENT_HIST for this event_type.

EVENT_PARM2

VARCHAR2(128)

User-defined parameter which can store any value relevant to the event. Description of use should be noted in WIP_EVENTS table.

EVENT_PARM2_DESC

VARCHAR2(128)

Description of the value written to the user-defined column event_parm2 in WIP_EVENT_HIST for this event_type.

EVENT_PARM3

VARCHAR2(128)

User-defined parameter which can store any value relevant to the event. Description of use should be noted in WIP_EVENTS table.

EVENT_PARM3_DESC

VARCHAR2(128)

Description of the value written to the user-defined column event_parm3 in WIP_EVENT_HIST for this event_type.

EVENT_PARM4

VARCHAR2(128)

User-defined parameter which can store any value relevant to the event. Description of use should be noted in WIP_EVENTS table.

EVENT_PARM4_DESC

VARCHAR2(128)

Description of the value written to the user-defined column event_parm4 in WIP_EVENT_HIST for this event_type.

EVENT_PARM5

VARCHAR2(128)

User-defined parameter which can store any value relevant to the event. Description of use should be noted in WIP_EVENTS table.

EVENT_SOURCE

VARCHAR2(36)

The source where the event happened for the lot. For example MES, EI, Dispatching, etc.

EVENT_TIME

TIMESTAMP(6)

We expect FDC applications to provide a timestamp field which we write to this column via either FPSAPP procedure or ETL. When we then import this data into the ETL via WIP_APD_xxx_HIST views, we will use this timestamp to populate the inst field without the fractional seconds and we will use the fractional seconds as opt_sort_within_sec.

EVENT_TIMELINESS

VARCHAR2(56)

For this occurrence of the event, how timely was it executed relative to the early, due and late values. May be used for linking to ETP_MNT_EPISODE_HIST.

EVENT_TIMELINESS_NOTE

VARCHAR2(200)

A quality metric for the event_timelessness column noting if the data is good or bad or has a warning with a small note on why it has the quality it does.

EVENT_TIMELINESS_QUALITY

NUMBER(1)

A quality metric for the event_timelessness column noting if the data is good or bad or has a warning. 1 = we have good data,and everything is great, 2 = small warning but we think we have what we need, 3 = bad, we are missing key data, 9 = we may have encountered an error.

EVENT_TYPE

VARCHAR2(12)

Event Type

EXCLUDE_HOLD_LOTS_IN_TIMER

CHAR(1)

This configuration will exclude any HOLD lots from queue timer consideration if set to Y.

EXPIRED_QUEUE_TIMER_WEIGHT

NUMBER(7,2)

how much weight to give lots with expired timers for example: A weight of 0 -> expired timers will all get the same score of 20. for example: A weight of 1 -> expired timers will get an additional point for every hour they are late

EXPIRED_SEC

NUMBER(7)

Seconds from the start event until queue time restriction is expired. After expiration, the lot must rework or scrap or otherwise be evaluated.

EXPIRE_INST

DATE

Time when the waiver is expired.

EXPIRY_DEACTIVATE_INST

DATE

Date column that automatically sets the tag condition to inactive once the date is past.

EXPIRY_WARN_INST

DATE

Time to warn the creator of the rule that the rule is about to expire.

EXPLANATION

VARCHAR2(4000)

Explanation of how data is translated for specific column. For example, this might include the table name and column name from the MES used to populate the column in the FPSINPUT table.

EXPT_ID

VARCHAR2(12)

Experiment identifier which indicates the lot will process differently that normal for its product on at least one step of the route.

EXPT_INSTRUCTIONS

VARCHAR2(512)

General instructions about the experiment performed on this lot. This is a long string field for display only.

EXPT_VARIATION

VARCHAR2(12)

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.

EXP_CASCADE_BATCHES

NUMBER(2)

Expected cascade batches is only for cascading batch tools. It is used in throughput calculations to determine how many batch_intervals to count after each first_unit_sec. If this is not populated we assume the batch tool does not cascade. This value could also be used in dispatching/scheduling to specify how many batches should be cascaded before a setup change is allowed. Historical data should be compared to this value regularly to verify it.

EXP_CASCADE_QTY

NUMBER(3)

Expected number of wafers in a cascade is only for cascading tools which are not batch tools. It is used in throughput calculations to determine how many unit_intervals to count after each first_unit_sec. If this is not populated we use the exp_qty_per_carr_for_wph as the default meaning we cascade just one carrier. This value could also be used in dispatching/scheduling to specify how many wafers should be cascaded before a setup change is allowed. Historical data should be compared to this value regularly to verify it.

EXP_QTY_PER_BATCH

NUMBER(3)

Expected wafers in a batch used in throughput calculations and for inc_batch_pct calculation. This value is required to be populated for batch tools.

EXP_QTY_PER_JOB

NUMBER(7)

If populated this value is used for the EET/TCT calculation for this eqp type instead of avg_qty_per_carr_for_wph which is the default for the facility.

EXTL_ADDL_INFO

VARCHAR2(256)

This will have any additional lot info needed by the external system

EXTL_DEST_LOCATION

VARCHAR2(32)

This column will have the destination location for the lot

EXTL_DISP_INST

DATE

Time by when the external system recommends that the job must be dispatched.

EXTL_DO_NOT_MOVE

CHAR(1)

This column will decided whether NextMove will highlight to move or override it

EXTL_END

DATE

Time by when the external system recommends that the job will end processing.

EXTL_ID

VARCHAR2(64)

The identifier for the external model. For details on all EXTL columns please see Help Site page at https://help.finalphasesystems.com/display/SCHED/Scheduler+and+External+Model+Status.

EXTL_IS_RESERVED

CHAR(1)

Flag indicated whether the external system has reserved the lot to the tool. If not we still move to the destination.

EXTL_MODEL_EXPIRED_INST

DATE

to indicate when this model will be expired

EXTL_MODEL_EXPIRE_INST

DATE

Datetime when the model state will expire. This value is critical for prioritizing lots in Scheduler using the Expiring status.

EXTL_RANK

VARCHAR2(1)

Allowed values are P, F, W. For details on all EXTL columns please see Help Site page at https://help.finalphasesystems.com/display/SCHED/Scheduler+and+External+Model+Status.

EXTL_RANK_COMMENT

VARCHAR2(256)

Optional comment entered by user or system who last updated external information.

EXTL_RANK_UPDATED_INST

DATE

Datetime populated by trigger when external rank was last updated.

EXTL_RANK_USER

VARCHAR2(64)

User or system who last updated external information.

EXTL_REQ_EXACT_DEST

CHAR(1)

This column will decided whether NextMove use alternates and station assignments or ignore them.

EXTL_SHOW_EXACT_DEST

CHAR(1)

This column will decided whether NextMove will show the destination Bay or the exact destination.

EXTL_START

DATE

Time by when the external system recommends that the job will begin processing.

EXTL_STATUS_DISPLAY

VARCHAR2(64)

Normally just a display field for the External Model status but if the value matches one of the allowed Model States then it is considered to be the Model State. For the list of Model States and full detailed on all EXTL columns please see Help Site page at https://help.finalphasesystems.com/display/SCHED/Scheduler+and+External+Model+Status.

EXTL_TIME_TO_NEXT_MOVE

DATE

Time provided by an external system to override the carrier time to move for racks.

EXTL_TRANSPORT_MODE

VARCHAR2(16)

Name of the site transport mode which represents how material is moved from one location to another.

FACILITY

VARCHAR2(6)

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.

FACILITY_DISPLAY

VARCHAR2(20)

The name of the facility displayed on all dashboards and reports. Facility is a short field since it is used in every join so we allow a longer more descriptive name here although often this will be the same as the facility.

FACILITY_OUT

VARCHAR2(6)

Facility of final flushed product. See detailed comments and examples in table overview.

FACILITY_SEGMENT

VARCHAR2(36)

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.

FB_PRIORITY

VARCHAR2(10)

This could be used for 0 through 10 or HIGH, MED, LOW but is left unconstrained for any site to use as they wish. We have considered adding a second table with would be the possible values that could be configured that is for a later time.

FDC_CHAMBER

VARCHAR2(32)

The chamber identifier within the FDC system which is unique to that FDC_TOOL. This can be a string or number.

FDC_TOOL

VARCHAR2(16)

The tool identifier within the FDC system. This could match the tool in the MES or DWH but this is not guaranteed.

FEEDBACK_FROM_EMAIL

VARCHAR2(128)

The email address to use as the From email when we send emails with the ADM_SEND_EMAIL procedure. We send emails via our Feedback application which is configured to do so for whatever restrictions we have at the site. This should probably be something like no-reply-dwh@client.com.

FEEDBACK_HOST_URL

VARCHAR2(500)

This is the host of the server where our Feedback application is configured. It should be something like http://fpsdev.client.com. We add /feedback/api/email to this host and use this URL to send emails via our Feedback application.

FEED_IF_LESS_THAN_SEC

NUMBER(6)

If WIP in the queue sequence as measured by total seconds of EET is below this number then we should prioritize lots entering the sequence.

FG_FACILITY

VARCHAR2(16)

The facility logged by the FabGuard Broker. Needed to change the name to not bother ADM_CHK_ALL to allow null in Facility.

FIFO_STEP_SEC_TO_EOL

NUMBER(11)

This can be used for critical ratio to avoid the following situation. Lot A of prd A and lot B of prd B are both at the same step on the same route. Plan CT for A is 40 plan CT for B is 60. Due date for A is in 41 days. Due date for B is in 59 days. Normal CR says A is one day ahead and B is one day behind so run B first. But this is insane because both are on the same route with exactly the same steps coming up and B is only "behind" because of a lower expectation. We should run A first. If we use FIFO then both are something like 50 days CT and A is 9 days behind and B is 9 days ahead. However there is a problem with this strategy because we would basically let B sit around and do nothing for 20 days until it was also 40 days and then have to run it at the same rate. So this is not perfect either.

FILE_NAME

VARCHAR2(50)

CFG_FILES table is currently not used.

FILLIN_AMR_PCT

NUMBER(3)

This is for our throughput calculations and addresses the case where we get a mix of real values and NA for the actual_machine_recipe for a particular process. If the percentage of real values is higher than this number then we assume that the NA are actually the real value and count all towards the throughput calculation. This avoids the confusing two rows for the same process, one with the real value and one with NA.

FILLIN_EMR_PCT

NUMBER(3)

This is for our throughput calculations and addresses the case where we get a mix of real values and NA for the est_machine_recipe for a particular process. If the percentage of real values is higher than this number then we assume that the NA are actually the real value and count all towards the throughput calculation. This avoids the confusing two rows for the same process, one with the real value and one with NA.

FILL_IN_RECIPE

VARCHAR2(100)

One example use of this column is that we may set it to SLOW, MED, FAST to use as default for new recipes and then we would manually populate SLOW, MED, FAST recipe data for each EQP_TYPE in RTG_RECIPE_EQPTYPES.

FILTER

VARCHAR2(64)

The name of the filter to be defined in the UI. The filter can be used by multiple rules.

FILTER_DESCRIPTION

VARCHAR2(256)

The description of the filter.

FILTER_FROM_EQP_SUMMARIES

CHAR(1)

If this is Y then tools in this MNT_FAMILY will not be included in the EQP/ETP state summary bar charts on the facility and module level. This applies to bar charts on the Operations, Equipment, and Performance tabs of the Dashboard. EQP/ETP state summaries will still be available for these tools on the process family and tool level.

FILTER_PARAMETER

VARCHAR2(50)

The filter parameter. The parameter options will be limited and pre-defined unless the IS_LOT_PARAMETER flag is set to Y. In this case, the user will input the parameter, which will be looked up in WIP_LOT_PARAMETERS.

FILTER_VALUE

VARCHAR2(256)

The value for the filter parameter.

FIRMWARE_VERSION

VARCHAR2(20)

Firmware/Hardware version the tool us running. This value is only used to display in the Dashboard.

FIRST_LOT_IN_JOB

VARCHAR2(32)

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.

FIRST_NAME

VARCHAR2(36)

First name of the user.

FIRST_NUM_HOURS

NUMBER

is used to determine hours of the first step of the lot to schedule based on the sched-group and lot-group; if not to schedule any lot from this group, then set this value to -1 will work

FIRST_QUAL_FROM_INST

DATE

First time during the maintenance when the tool was logged into qualification.

FIRST_UNIT_SEC

NUMBER(9,3)

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.

FIRST_UNIT_SEC_LCL

NUMBER(9,3)

Lower control limit for first unit seconds used in our Throughput monitoring. Obviously this must be less than the manual first unit value.

FIRST_UNIT_SEC_UCL

NUMBER(9,3)

Upper control limit for first unit seconds used in our Throughput monitoring. Obviously this must be greater than the manual first unit value.

FIRST_WFR_BEG_INST

DATE

Time when the first wafer of the job started processing.

FIRST_WFR_END_INST

DATE

Time when the first wafer of the job finished processing.

FIXED_CARRIER_SEC

NUMBER(4)

Seconds between units in two different carriers in additional to the normal unit interval. This time is added to the EET, MPU, and UPH.

FLCT_REPEAT_DAYS

NUMBER(4)

There are two reasons why a lot would record a second finish event for the same lot/facility/prd. The first reason is that the lot id is reused which happens often for test wafers lots. To account for this, our default behavior is to only look for activity since the last finish event for this lot. But the second reason is that the lot was unshipped or unscrapped or the initial finish event was deleted in the MES or otherwise somehow reversed. In this case, we do not want to look for all activity since the start associated with the last finish event rather that since the last finish event. This parameter tells us to assume the second reason if the second finish event was within this many days of the first event. When the second reason occurs, the second event is usually just a few minutes after the first one but it can occasionally be longer. If your MES never reuses lot ids even for test wafer lots then you can set this to a big number without any concern.

FLUSH_SEQ_DESC

NUMBER(2)

Flush sequence descending is the order of main routes and banks for the lot from final flushed product back to the current. 1 is always the last main route or bank for the final flushed product.

FLUSH_SEQ_NUM

NUMBER(2)

Flush sequence number is the order of main routes and banks for the lot from current to the final flushed product. 1 is always the current main route or bank.

FONT_SIZE

NUMBER(2)

Font Size of the badge text or icon.

FORCE_VALID_FINISH_EVENT

VARCHAR2(48)

In order to count as a valid finished lot, a lot must complete the last real step in the route, complete at least one step in the last operation of the route, log a ship event, or log the event entered in this field as the event which signifies a valid finish event for the facility. In most facilities, setting this field will not be necessary because even if you have an event that signifies a valid finish event you are likely already setting is_ship_event to Y. The use case where this is necessary is when a lot must go through multiple prds in the same facility and we only want to count the ship out of the last prd as a ship event. Then we can set this field so that we can force the earlier prds to be valid if a lot logs this event.

FORMULA

VARCHAR2(1000)

Mathematical formula for how the data is derived.

FROM_BAY

VARCHAR2(12)

Bay to move from.

FROM_INST

DATE

Time from which this state was active.

FROM_MSO_PROCESS_NA

VARCHAR2(100)

Main processing step for the rule link. This is the step where the decision to tag lots is made and the skip/tag counter is incremented.

FROM_RQD_SETUP

VARCHAR2(100)

Setup that is changed from. This should match a value in rqd_setup in RTG_TOOL_ASSIGNMENTS.

FTR_U_MIN_MFG_SECS

NUMBER(7)

This value is the minimum time a entity must be in an MFG state (SBY and PRD) in order to close an FTRu window.

FUTURE_THREAD_STEP

VARCHAR2(256)

Future step(s) that will have its PERM_RANK altered based on the tool that processed the lot at the start step

FUTURE_WIP_STEP

VARCHAR2(256)

FUTURE_WIP_STEP is for sequenced operations. The most common is the Diffusion clean-furnace sequence. Lots for the furnace always wait at the sink so there is technically never any WIP at the furnace operation. But we do not want to count it as Sby No WIP if there is WIP available at the sink. This tells us to link the steps so that we will report Standby Wip At Previous Related Step.

GATHER_STATS_ALWAYS

CHAR(1)

For large history tables, we normally check if we should skip gathering stats during ADM_STATS_ALL. This flag forces the procedure to always gather stats on this table.

GATHER_STATS_NEVER

CHAR(1)

This flag causes ADM_STATS_ALL to never gather stats. This would typically be used for history tables to override the normal checks but could be used for any table if needed.

GBL_SORT

NUMBER(38)

Sorting used for dispatching or allocation systems to sort future start lots based on priority, critical ratio, etc.

GOAL_BEGIN_INST

DATE

Time when the lot has to complete the current step to remain on schedule.

GOAL_COMPLETES

NUMBER(12,4)

Completes goal for the current shift. Typically we calculate either completes or moves goal depending on the site logic and then either multiply moves by est_smp_pct to get completes or divide completes by est_smp_pct to get moves.

GOAL_MOVES

NUMBER(12,4)

Moves goal for the current shift means how many units we need to move through this step to progress towards our demand or due date. This could be either a complete or a skip. Typically we calculate either completes or moves goal depending on the site logic and then either multiply moves by est_smp_pct to get completes or divide completes by est_smp_pct to get moves.

GOAL_OPER_MOVES

NUMBER(12,4)

Oper moves goal for the current shift. This should be recorded at only one step of the operation at it can be at any step not necessarily the last one. Since we do not get an oper move if we skip the entire operation, this is typically the maximum goal completes for any step in the operation. Some sites might calculate goal oper moves independently and potentially even get goal moves and completes from the goal oper moves.

GOAL_WIP

NUMBER(12,4)

WIP goal for each shift. If you are using the GP logic in FPSAPP to get WIP goals for line balancing then you might want to pull those goals into this table to show on Dashboard. If not, this can be calculated by dividing the goal moves per day (from this logic) by the commit cycle time in days for the step (from CTM_SUMMARY_PLUS).

GOAL_WIP_PCT_TO_TGT_BAY_PERF

NUMBER(2)

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.

GP_SUBFAMILY

VARCHAR2(58)

GP_subfamily is used for Goal Planner and is an extension of process_family which can additionally include lot_group and an additional suffix. We populate GP_subfamily automatically based on process_family, process_subfamily, gp_subfamily_suffix, and add_lotgrp_to_gp_subfamily using the function GET_GP_SUBFAMILY. We build this starting with nvl(process_subfamily, process_family) followed by gp_subfamily_suffix if populated then followed by lot_group if add_lotgrp_to_gp_subfamily is set to Y. It is possible to have one or two or three parts. You might have values for process_family/process_subfamily/gp_subfamily_suffix/add_lotgrp of Furn/blank/blank/Y and that would give you gp_subfamilies of Furn/Prod and Furn/Dev. Or Furn/HighTemp/blank/Y would give you HighTemp/Prod and HighTemp/Dev. Or Sink/blank/FeedsOxFurn/N would give you Sink/FeedsOxFurn. And so on.

GP_SUBFAMILY_OR_EACH

VARCHAR2(36)

Key field containing the subfamily name or EACH when all values are specified for the values specified in this table

GP_SUBFAMILY_SUFFIX

VARCHAR2(12)

See comments in GET_GP_SUBFAMILY function. This field is normally blank unless configuration is required for Goal Planner.

GRANTEE

VARCHAR2(30)

User to whom the privilege needs to be granted

GROSS_DIE_PER_WFR

NUMBER(6)

Expected gross die per wafer for the product. This is a critical field for planning die shipments. Note this is gross so we multiply by line yield and by sort yield for remaining steps of remaining products.

GTG_EPISODE_FROM_INST

DATE

The time when the current series of ETP_MNT_EPISODES started and should be considered part of the same Green-to-green (GTG) time.

HASH_EVENT_KEY_IN_WIP_HOLD_FUT

CHAR(1)

If this is set to Y, then WIP_HOLD_FUTURE.EVENT_KEY field is a an opaque event identifier which can be used directly as a key by web apps; if N, then it is a long human-readable string and should be hashed before being used as a key.

HEX_CODE

VARCHAR2(7)

The hex code has the format of # then six hexadecimal characters.

HIDE_CTR_WSH_IF_LESS_THAN_SECS

NUMBER(4)

To reduce the number of rows on the Finished Lot Cycle Time lot history page, we hide steps which took less than this number of seconds. The default is 1200 or 20 minutes. We always show the first and last steps even if they were fast.

HIDE_EVENT_IN_DASH_HIST

CHAR(1)

Occasionally we have certain events which are logged frequently in the MES but are unimportant. We do not want to show these events in the Dashboard lot event history table as they clutter up the list. Set this column to Y to hide an event from this list.

HIDE_FACILITY_ON_WEB

CHAR(1)

Hide a facility from our applications. Default is N, but setting to Y hides on Dashboard and other applications will not reference hidden facility

HIDE_FUT_IN_LOT_STEP_SUMMARY

CHAR(1)

Indicates whether future step records will be hidden in the Dashboard Lot History Summary table.

HIDE_IN_DASH

CHAR(1)

Set to Y to hide this tool from the Dashboard and most other reports.

HIDE_IN_MSO

CHAR(1)

Set to Y to hide this tool from the MSO Dashboard and MSO UI. This should be used on tools where no metrology or tracking is required.

HIDE_LOTS_IN_DASH

CHAR(1)

This flag is similar to CONSIDER_IN_BANK but even more extreme. This flag will completely hide all lots and moves on this route from the Dashboard. Honestly we discourage anyone from using this flag (and strongly discourage it for anything but test wafers) but it is here at least for Dashboard only if a particular site really wants it.

HIDE_ON_THP_PAGE

CHAR(1)

Some eqp types we just simply do not care about their throughput so we can use this flag to hide them from our Throughput Tracker.

HIDE_ON_TOOLS_IN_NMV

CHAR(1)

Hides all lots of the test wafer lot type on the NextMove tool page and bay view. This should rarely be used and when it is used it should only be set to Y for specific test wafer lot types that you never want to see on the NextMove screens.

HIDE_TIMER_IN_DASH

CHAR(1)

This configuration will remove WIP for this timer_id from the Dashboard Queue Timer report.

HISTORY_SOURCE

VARCHAR2(36)

The reason why this history was written. What caused us to think that this mnt event was finished. Values starting with U are triggered from updating in EQP_MNT_FUTURE. Values starting with D are from being deleted from EQP_MNT_FUTURE, values start with C are triggered from a counter reset in EQP_MNT_COUNTER_CURR.

HIST_CATCHUP_MINS_AFTER_DD

NUMBER(5)

The number of minutes of data we load during each run of WIP_EVENT_HIST. This is constrained to be at least 30 minutes. This value becomes important after the load gets behind, either due to a planned stop or due to a failure. Loading all of the missing data at once can overwhelm the database so we catchup this many minutes at a time.

HIST_INSERTED_TIME

TIMESTAMP(6)

Unlike just about every other history table, ETP_HIST does not have a single column that represents the inst associated with the record. For example, WIP_EVENT_HIST has inst, WIP_END_SHIFT_HIST has start_shift, THP_EQPTYPE_WEEK_HIST has start_week, and so on. These columns are consistent with the data in the entire table and sorting by them gives you a consistent order of the records in the table. When a record is inserted into ETP_HIST, it might be because of an EQP state change in which case eqp_to_inst would be the inst of the event that triggered the state change. But etp_to_inst would still be the old value. And vice versa for ETP state changes. Furthermore while usually either eqp_to_inst or etp_to_inst is relevant, we also insert records when the standby state changes without a EQP/ETP state change and in these cases sby_inst is relevant but both eqp_to_inst and etp_to_inst are old values. And the worst case is when the only change is a standby state of any entity on the tool which actually has no relevant inst. The only column which is always relevant is hist_inserted_time so we have no choice but to use this column as the purge_column_name in CFG_TABLES. By the nature of the logic, hist_inserted_time is always newer than all of the other inst values so we will never purge too many records. If the data is behind or loaded for a past period then we will purge too little but that is acceptable.

HIST_OVERLAP_MINS_BEFORE_DD

NUMBER(3)

In a perfect world, we could just load all events newer than data_date into WIP_EVENT_HIST. But the world is not perfect. Instead events are loaded into the MES in an order which does not perfectly match the order in which they were logged. In other words, an event logged at 01:23:46 is inserted in the MES before another event logged at 01:23:45. In order to not miss any events, we have to go back at least a few seconds prior to data_date and then check if those events have already been inserted and insert only if not. This variable determines how far back we have to look. Usually it should be a minute or too but there is little cost in going back 5 or 10 minutes just to make sure. For debugging, we might set temporarily to a larger number but for normal running it should be no longer than an hour.

HIST_WEEKS_FOR_CTM_FIN_PERIOD

NUMBER(3)

If you choose to define finished period by weeks then this is the number of weeks to load into the CTR tables and show on the FLCT application. We store all data in the CTM_FINISHED_LOT_HIST table and purge that table based on the normal purge logic in CFG_TABLES so this is only for the CTR/FLCT.

HOLD_FOR

VARCHAR2(48)

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.

HOLD_GROUP

VARCHAR2(36)

Grouping of hold_type for reporting purposes.

HOLD_NOTE

VARCHAR2(512)

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.

HOLD_PARM1

VARCHAR2(128)

Four user-defined fields which can store anything the user would like to track relating to the hold type.

HOLD_PARM2

VARCHAR2(128)

See HOLD_PARM1.

HOLD_PARM3

VARCHAR2(128)

See HOLD_PARM1.

HOLD_PARM4

VARCHAR2(128)

See HOLD_PARM1.

HOLD_PRTY_GROUP

VARCHAR2(20)

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.

HOLD_TYPE

VARCHAR2(24)

Generally hold_type will come directly from the MES.

HOME_BAY

VARCHAR2(12)

Assign vehicle to a home bay for the normal place where the cart resides. If you assign a home bay, then the transit times for lots on the vehicle will be determined using the bay to bay matrix with the home bay as the from bay.

HOME_STATION

VARCHAR2(32)

The optional home station of the vehicle or carrier is generally where it should be stored when not in use or the area in which it operates.

HOME_TOOL

VARCHAR2(16)

The optional home tool of the durable is generally where it should return after maintenance or inspection or where we prefer to schedule its use

HOST_ACTION

VARCHAR2(100)

Indicate the default action of host

HOST_CONTROLLER

VARCHAR2(100)

Indicate the default controller of host

HOST_TYPE

VARCHAR2(36)

is used to tell if this is for WEB or SERVICE

HOURS_FOR_NEXT_MOVE

NUMBER(3)

Include lot-step in NextMove Pick List if lot is expected to arrive sooner than hours_for_next_move or if step is less than or equal to this many steps away from the current step. Populates nmv_display_in_pick_list column in WIP_STEP_FUTURE

HOURS_FOR_WIP_STEP_FUT

NUMBER(4)

The maximum number of expected hours to arrival for steps in WIP_STEP_FUTURE. This is used in combination with steps_for_wip_step_fut. For example, if this is 48 and steps is 10 then we write all steps where a lot is expected to arrive within 48 hours or is within 10 steps way. This should likely be 24-72 for a fab and possibly a bit longer for assembly/test.

HOURS_SINCE_PROC

NUMBER(4,1)

Hours since the tool was last processing lots.

HOURS_TO_DISPLAY

NUMBER(5)

WILL REMOVE SOON

HOURS_TO_SCHEDULE

NUMBER(5)

This column is used to determine how many hours to look ahead and schedule the lots that might come into this area/SCHED-GROUP even it is still several steps away.

HOURS_TO_SCHEDULE_FIRST_STEP

NUMBER

to set the max hours to sched for the first step of each lot

HOURS_TO_SCHEDULE_TOOL_EVENT

NUMBER

to indicate how far in the future to include a tool_event. Any event that starts within current time + this value will be considered

HOVER_TEXT

VARCHAR2(100)

The hover text of the report link

HTML_STYLE

VARCHAR2(500)

used to configure how to display this lot priority on kitting/scheduler web page

ICON_NAME

VARCHAR2(50)

Unique name to be used for each icon.

IGNORE_BANK_TW_ON_DASH

CHAR(1)

The Dashboard spotlight shows a number of Test Wafers in the facility. Usually we want this to include test wafers in a bank so we would set this to N. To ignore test wafers in a bank then set this to Y.

IGNORE_BATCH_FOR_ETP

CHAR(1)

Some unusual tools load lots as a batch but then process each lot individually like a non-batch tool. On these tools we need to treat them as batch tools for Dashboard and Scheduler but ETP should treat each lot individually. This flag tells ETP to do just that.

IGNORE_BATCH_FOR_INC_BATCH_PCT

CHAR(1)

This flag will allow batch thp tools to not report any incomplete batch pct for ETP if set to Y. This should rarely be used for tools that should schedule as batch tools but not report any ETP loss because of the batch size. This configuration is created specifically for the Mattson Asher tools

IGNORE_BLANK_CHK

CHAR(1)

Certain sites have a known ETL condition that can lead to key columns temporarily populating blank! values in WIP_EVENT_HIST. Setting this to Y tells SYSMNTR_ERRORS to ignore its standard check for blank! values at this site.

IGNORE_BNS

CHAR(1)

If set to Y the bottleneck score will always be 999 so it will be a the bottom of the list. Note that we normally use pace for families with no tools therefore this should generally be set only for families which we do not care about whatsoever.

IGNORE_FOR_SCHED

CHAR(1)

Set to Y if the location should be ignored by the Scheduler. Usually this value is the same as is_internal and in fact all ports which are not internal are constrained to not be ignored but occasionally the Scheduler does schedule internal ports such as boats.

IGNORE_HOLD_FOR_PROC_STATE

CHAR(1)

When a metrology tool detects an error on a wafer, it often automatically places the lot on hold even though the job is still processing on the metrology tool. When this happens, we want to consider this as a "running hold" which means that the lot continues processing and then will be on hold as soon as it finishes. There are two ways to indicate a running hold if put on hold during processing, either by the is_running_hold_if_proc column for a hold_type or by this column for all tools in an eqp_type. This is an "or" condition so if a hold_type is Y that applies to all tools and if a tool is Y that applies to all hold types. When a lot goes on a running hold, we will set the ECT state of the lot to PRD-RUNHOLD and keep the ETP state of the tool in PRD. Then when the lot ends or moves to the next step, we will set the ECT state of the lot to HOLD and set the ETP state of the tool using our normal END logic which will set to Standby unless a newer job has started.

IGNORE_MAIN_ALWAYS

CHAR(1)

This flag indicates to ignore the state of the main entity. When this flag is set and the main entity is down and a chamber is up that we schedule lots to that chamber and we consider the tool to be partially up in our ETP calculation. The only known use cases for this are Photo cells that can run track only lots when the track is up and the main cell is down.

IGNORE_MAIN_IF_PRD

CHAR(1)

Set to Y to ignore main tool in cluster calculations when in a PRD state. This is configurable because some tools log better information for main tool and some for chambers.

IGNORE_PASS_THRU_PRD_FOR_FLCT

CHAR(1)

Our normal logic to determine whether a finished lot is considered valid for FLCT calculations is to only count as valid if the lot moved through the first step and the last step of the main route (or if they ran on the last step and split from a lot that ran on the first step). But many sites especially those with multiple facilities have prds that we call "pass-through" prds where the prd goes through a bank but no steps. If we want to count any lots as valid for these prds then the only option is to simply count all finished lots as valid because if we used our normal logic then we would never have any lots as valid. Whether or not to do this is configurable here by facility.

IGNORE_PROC_LONGER

CHAR(1)

This flag tells ETP that we should never set state to Missed Cascade when processing a lot of this lot group because the throughput estimates are unreliable. This must always be N for production lot groups.

IGNORE_WLRT_UPDATED_TIMESTAMP

CHAR(1)

This flag determines if WIP_LOTS_REALTIME_UPDATE_BEF should check if the Updated_timestamp is different or not. Most cases do want to check that the updated_timestamp is new, but at some sites where they ETL runs really fast and the database lacks high timestamp precision (3 vs. 6 places) it may be beneficial to suppress preventing updates to wip_lot_realtime for having the same update_timestamp.

INCLUDE_EQP_STATE_IN_DASH_ETP

CHAR(1)

This column will add the MES state of the tool to the end of the ETP_STATE_NAME for Dashboard users to see the MES state of the tool after the ETP state. If set to N then only the ETP state will be shown.

INCLUDE_EST_TRANSIT_IN_XFACTOR

CHAR(1)

We automatically calculate the estimated transit time for each route-step in the RTG_EST_TRANSIT view and we write this to CTM_SUMMARY in the est_transit_sec column but this flag tells us whether to include this in the processing time denominator of the X-Factor calculation in DCTA, FLCT, and PERF.

INCLUDE_IN_CTA_IF_NOT_MAIN

CHAR(1)

By default, we only include the main route for each prd in Cycle Time Analyzer. If we want to include alternate main routes in CTA then we can set this flag. Note that these must be full alternate routes for the prd and not rework routes nor short loop routes as those are not added properly to the overall calculation.

INCLUDE_IN_DASH_DOWN

CHAR(1)

This column will hide tools from the Down tools section of the Equipment Dashboard if set to N for this opportunity state

INCLUDE_IN_WIP_FLUSH

CHAR(1)

Indicates whether this start should be included in the WIP_FLUSH table. Generally this should be Y for near future starts and N for those which are more distant but it is fine to set for all or none depending on your use of WIP_FLUSH.

INCLUDE_IN_WSF

CHAR(1)

Indicates whether this start should be included in the WIP_STEP_FUTURE table. Please only set this to Y for starts within a week or two because a larger WIP_STEP_FUTURE table can impact the speed of the RealTime job and the overall database. Plus there is no need to have starts in the distant future in WIP_STEP_FUTURE.

INCLUDE_NST_AS_CAP_ENT

CHAR(1)

Determines whether tools/chambers in NST states should be counted as capacity entities. The default value is N.

INC_BATCH_EQP_STATE

VARCHAR2(48)

This optional column is the eqp_state to use for processing incomplete batch if this is included in the client equipment state model. Populate only if you are passing eqp_inc_batch_pct in EQP_EVENT_HIST.

INC_BATCH_PCT

NUMBER(3)

Percentage of the full batch size processed. For tool performance calculations, TOOL_PCT percentage productivity is calculated using INC_BATCH_PCT to factor in that the batch size is not fully utilized.

INDICATOR_NAME

VARCHAR2(128)

A maintenance indicator is the name of a value that needs to be tracked and controlled to monitor the maintenance status of a tool or chamber.

INHIBIT_E_FOR_SCH

CHAR(1)

In the curr_rank logic used for ETP, perm_rank E (Emergency) automatically becomes U (Use Emergency) when all other allowed tools are down or blocked. The idea of this logic is that we will only want to run lots of rank E when there is no better available allowed tool. When this column is set to Y then we replicate this behavior for Scheduler and only send lots with perm_rank E to the Scheduler when all other allowed tools are down or blocked. If this is set to Y and the lot has at least one other tool of a better rank like P or A then we will not show this tool as an option for this lot on Scheduler.

INITIALIZE_INST

DATE

This is the time when this DWH started logging events. When we insert entities into the DWH we set their state to SBY-DEF starting at this time. When lot events are logged we will set the step_ent_inst to this inst. While this is a helpful reference over the entire life of the DWH it is only used for the startup event logging. We like this to be the start of a work week so we can get summary information for entire weeks.

INNER_MAX_PCT

NUMBER(4,1)

Inner upper limit for this target type.

INNER_MIN_PCT

NUMBER(4,1)

Inner lower limit for this target type.

INPUT_DESC

NVARCHAR2(2000)

used to set a slider description display that will stay constant within the sched_group

INPUT_RANK

NUMBER(1)

Preference where we want to send carriers which are reserved to this tool. These are typically input racks/stockers for the bay. This is a non-unique numeric rank from 1 to 9 where 1 is first choice and 9 is last choice.

INPUT_STATION

VARCHAR2(32)

Bay input rack assigned to the carrier based on either reserved or scheduled tool

INSERTED_TIME

TIMESTAMP(6)

Timestamp field set by trigger storing SYSTIMESTAMP when record was inserted in the table.

INST

DATE

Time when the event occurred.

INSTALL_COMPLETE_INST

DATE

This is the time when the script complete running on this database. To be more specific, it is the time when we turned ETL on (or when we skipped turning ETL on because we knew we were continuing to upgrade to a newer version). A a null value in this column signifies that the upgrade script for the version has not yet completed.

INSTALL_INST

DATE

This is the time when the script started running on this database.

INTERMEDIATE_STATION

VARCHAR2(32)

For NextMove, all moves from the from_bay to the to_bay should go to this station next.

INTERVAL_SEC

NUMBER(9,3)

Unit_int_sec or batch_int_sec expected for the lot at the time of processing from our THP tables.

INTERVAL_SEC_LCL

NUMBER(9,3)

Lower control limit for interval seconds used in our Throughput monitoring. Obviously this must be less than the manual interval value.

INTERVAL_SEC_UCL

NUMBER(9,3)

Upper control limit for interval seconds used in our Throughput monitoring. Obviously this must be greater than the manual interval value.

INT_SEC_TO_REFRESH_WEB_DATA

NUMBER(5)

Interval where Scheduler will refresh cached web data after this many seconds have elapsed since last refresh

INT_SEC_TO_RUN_SCHEDULER

NUMBER(5)

This column is used to determine how often to run the scheduler for this SCHED-GROUP. For example, if it sets 60 seconds in this column, it means it will wait for at least 60 seconds before initializing a new scheduler run from the end time of previous run.

INVESTIGATED_BY

VARCHAR2(64)

Name of person who is investigating or did investigate this error.

INVESTIGATED_ON

DATE

Datetime when this error was last investigated.

INVESTIGATION_NOTE

VARCHAR2(512)

This is optional if the error is under investigation and stop_alert_until_inst is null. It is required if we are not alerting about this error.

IN_BAY_TRANSPORT_MODE

VARCHAR2(10)

Bay level in bay transport mode. If no other mode is specified, this will be the value used to direct wip within a bay internally.

IS_ACTIVE

CHAR(1)

Flag to enable or disable the tag condition.

IS_ALARM

CHAR(1)

This should be set to Y if the state should count as an alarm event. (This is typically a downtime event automatically triggered by the equipment.)

IS_ALARM_EVENT

CHAR(1)

Is set to Y when the episode included an Alarm state. Should possible be called has_alarm_event. Check L5_state_diagram for states.

IS_ALLOWED_FOR_SCHED

CHAR(1)

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.

IS_ALLOWED_IF_COL_NOT_NULL

CHAR(1)

This column indicates exactly how the column is ignored by the ETL.

IS_ALSO_ACCEPTABLE_IF_CURRLOC

CHAR(1)

This means that we would not send reserved carriers from elsewhere in the site to this location but if the carrier is already here that is not worth moving an assigned input location. Typically this is Y for location which are in adjacent bays.

IS_AMHS

CHAR(1)

This field indicates if the stocker is part of the Automated Material Handling System.

IS_ANY_VALID_OUTPUT_NEARBY

CHAR(1)

Set this flag to Y to not use bay runner. This means operators will be directed to go get any reserved lot from any valid output rack in their building.

IS_ANY_WAFER_SIZE

CHAR(1)

A value of null for wafer_size means that these tools can run all wafer sizes. This column is only to eliminate confusion for ETL maintenance purposes. A value of Y means these tools are known to run all wafer sizes while the default value of N means we have no wafer size information for these tools.

IS_ASSIST_CHAMBER

CHAR(1)

This indicates that the chamber assists the other primary chambers. If an assist chamber is in ch_allowed then at one least chamber of the ch_type must be up but as long as this is true then we ignore the assist chambers. We send only the non-assist chambers to the schedule as ch_to_sched.

IS_AT_COMP

CHAR(1)

Specifies if the hold will occur when the lot completes the step.

IS_AT_DISP

CHAR(1)

Specifies if the hold will occur when the lot is dispatched to a tool.

IS_AT_ENTER

CHAR(1)

Specifies if the hold will occur when the lot enters the step, which in some cases will be when the lot finishes the previous step.

IS_AUTO

CHAR(1)

This field shows if the port mode is set to automatically deliver material. If the facility either has automated delivery (aka 300mm) or is using semi-automated delivery (aka NextMove) then a port set to a port_mode where this is N but is_up is Y is considered manual. A manual port means that the delivery system cannot use this port. If all ports are manual then rank will be M (Ports Manual) and ETP will set the state to SBY-RANKM (Standby With All Ports in Manual). In addition, we report auto_pct by summarizing the port states in auto and manual.

IS_AUTO_KILL_ALLOWED

CHAR(1)

Flag indicating whether the session is allowed to be killed automatically.

IS_AUTO_SLOT_ASSIGNMENT

CHAR(1)

Y means automatically assign lot locations on carts. N means let the user assign the slot by scanning the lot then scanning the location.

IS_BATCH_THP

CHAR(1)

This is a critical value for throughput calculations. Throughput for batch tools is the same regardless of the qty in the batch. Throughput for non-batch tools varies based on the qty in the job. Usually this is Y when max_batch_size_carriers > 1 but not always. We can have tools who load multiple carriers together but whose throughput is calculated per unit. We can also have tools who load only single carriers but whose throughput is calculated per batch.

IS_BOLD

CHAR(1)

Font Weight of the badge text or icon.

IS_CAP_ENT_BY_TOOL

CHAR(1)

Used if you do not want to allow eqp_entities to determine this with internal logic and force it to be based on the tool

IS_CASCADING_IMPOSSIBLE

CHAR(1)

There are some chamber tools where we know cascading is not possible but running in parallel can confuse the THP logic so this flag addresses that.

IS_CHGLOG_ADDL_ENABLED

CHAR(1)

This column allows us to enable CHGLOG table/trigger functionality on additional tables which would not otherwise have it based on our normal manual table or manual columns logic.

IS_CHGLOG_PERM_DISABLED

CHAR(1)

Our FPSINPUT tables have the capability to record all changes in a CHGLOG table as built by BLD_CHGLOG. You can disable this by setting this to Y.

IS_CHILD_LOT_FOR_MSO

CHAR(1)

Field specific for telling MSO if a lot is a child lot or not. Tag conditions can be set to no allow child lots to be tagged. This field controls what is a child lot for MSO.

IS_COMPLETE

CHAR(1)

Boolean indicating whether the lot has completed processing.

IS_COMP_RQD_FOR_OPER_MOVE

CHAR(1)

This indicates whether a move must have move_type of COMP in order to count as an oper move.

IS_CONFIG_HIST_TABLE

CHAR(1)

Indicates if the table is history table of all the MSO configurations

IS_CONFIG_TABLE

CHAR(1)

Indicates if the table is a MSO configuration table that defines rules, tag conditions, waivers, settings, etc. Typically these are tables modified by the UI. These tables may have triggers associated to them that track changes.

IS_CONTIGUOUS

CHAR(1)

Since this table accepts different period types to display on FLCT we might need to choose only certain values to represent the forecasted cycle time for this prd over time. For example, we might have weekly values and then a value for the entire upcoming year and in this case all of the weekly values would be Y and the year value would be N so we would ignore the year value for all uses other than displaying it.

IS_COPY_ALLOWED

CHAR(1)

Indicates if the table is part of the COPY_CONFIGURATION_TABLES procedure in ADM_MSO_UTILITIES package.

IS_COUNT_PRIORITY_PCT

CHAR(1)

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.

IS_CRITICAL_IN_NMV

CHAR(1)

Used by NextMove to highlight critical tools in BayView. Ideally the client would update this column via ETL

IS_CTM_CALC_BY_PROCESS

CHAR(1)

Flag indicating whether we calculate planned queue cycle time by process instead of by eqp_family

IS_CURR

CHAR(1)

Boolean flag where Y indicates this row is for the current main route or product. Same as flush_seq_num = 1.

IS_DATA_HIST_TABLE

CHAR(1)

Indicates if the table contains history of MSO sampling results (i.e. tagging decisions, process history, etc.). This also is used if copying data from one database to another.

IS_DATA_TABLE

CHAR(1)

Indicates if the table contains current MSO data (i.e. current counters, tagged lots, etc.). This also is used if copying data from one database to another.

IS_DEFAULT

CHAR(1)

This is used to land the first sched group on the scheduler/web by default

IS_DEFAULT_PARAMETER

CHAR(1)

Flag indicating if the parameter is the default parameter to be set. For the UI this will be the default parameter selected.

IS_DEFAULT_UNCHECK_ON_DASH

CHAR(1)

Flag used for lot group, wafer size, and line section that indicates whether this value should be unchecked by default on the Dashboard. All TW must be unchecked.

IS_DEFAULT_UNCHECK_ON_DCTA

CHAR(1)

Flag used for lot group, wafer size, and line section that indicates whether this value should be unchecked by default on Dynamic Cycle Time Analyzer. All TW must be unchecked.

IS_DEFAULT_UNCHECK_ON_FLCT

CHAR(1)

Flag used for lot group and wafer size that indicates whether this value should be unchecked by default on Finished Lot Cycle Time. Please note that line section does not apply to FLCT. All TW must be unchecked.

IS_DEFAULT_UNCHECK_ON_PERF

CHAR(1)

Flag used for lot group, wafer size, and line section that indicates whether this value should be unchecked by default on Performance. All TW must be unchecked.

IS_DEFAULT_UNCHECK_ON_WF

CHAR(1)

Flag used for lot group, wafer size, and line section that indicates whether this value should be unchecked by default on WIP Flush. All TW must be unchecked.

IS_DELETE_EVENT

CHAR(1)

If the event results in this lot being deleted then logic in the trigger will set this to Y. This flag indicates that we should delete this lot from WIP_EVENTS_CURR_STEP and WIP_STEP_FUTURE in via subsequent triggers. There are two correct ways to delete a lot. One is to log an event with the qty set to 0 (i.e. merge or scrap or terminate). Two is to log an event where next_facility is set to a facility which is not in GEN_FACILITIES (i.e. ship). Then there is case three where the lot disappears from WIP_LOTS_VERIFY with no event designating this. Case three means the ETL needs to be improved to log the proper event so it becomes case one or two.

IS_DIE_BANK_FOR_CTM

CHAR(1)

We treat the die bank as a special bank regardless of the facility in our finished lot cycle time logic. Often there are die banks within each facility and we sum them together and count these die separately from other banks.

IS_DISPLAY_SLOT

CHAR(1)

Identifies slot on smart rack where the tablet is positioned, so a lot is unable to be stored there.

IS_DISP_RQD_TO_INSERT_WWH_WEH

CHAR(1)

When the first wafer begin event is logged in WIP_WAFER_HIST for a lot, we consider whether to copy this event as a lot BEGIN event in WIP_EVENT_HIST. If this flag is set to Y then we require the proc state to be DISP (meaning that the lot has been tracked in) in order to copy. Copying the event to WEH will set the proc_state of the lot to PROC and the etp_state of the tool to PRD.

IS_DURABLE_AT_DESTINATION

CHAR(1)

NextMove flag indicating if the durable location is the same as the tool the carrier needs to process on.

IS_DURABLE_REQUIRED

CHAR(1)

NextMove flag indicating if the carrier requires a durable to process.

IS_DURABLE_RQD

CHAR(1)

The scenario addressed here is when the recipe which requires a durable is allowed but the durable assignment is missing. We do not want to schedule lots without the durable but we could do this unless this flag is set to Y. Here are the four combinations for reference. 1) When is_durable_required is set to Y and there is a durable assigned then the Scheduler will schedule the lot using that durable. This is the normal Photo case. 2) When is_durable_required is set to Y and there is no durable assigned then the Scheduler will not allow the lot to be scheduled. This is important for Photo to not schedule without durable. 3) When is_durable_required is set to N and there is a durable assigned then the Scheduler will schedule the lot using that durable. You will notice that the flag actually does not matter when there is a durable assigned. That is this flag is not populated at some older sites so we cannot only look for the durable if this flag is set because then the Photo Scheduler would not schedule anything at these older sites. When is_durable_required is set to N and there is no durable assigned then the Scheduler will schedule the lot without a durable. This is the normal case for all groups outside of Photo. This would also be the case at the older sites for Photo except that we have some hardcoded logic at those sites to address this. Eventually we will transition all sites to use the is_durable_required flag.

IS_DURABLE_SCHEDULED_ONLY

CHAR(1)

Check to see if trk views should only use scheduled durables

IS_DYNAMIC_TOOLSTATUS_COND_ON

CHAR(1)

Flag that sets the rule group to allow dynamic adjusting of the sample condition and min condition override depending on tool conditions for the rule group.

IS_EQP_RELATED

CHAR(1)

This should be set to Y for UDT or SDT states where the equipment is solely responsible for the entity being down and is actively being diagnosed or repaired. (Does not include Wait-times or alarms, can include Quals). Should only be Set to Y for Downtime (UDT or SDT) states

IS_EQP_RELATED_EVENT

CHAR(1)

Is set to Y when the event is solely caused by the equipment. This is used to determine the Equipment related metrics. Should possible be called has_eqp_related_event. Check L5_state_diagram for states.

IS_ETL_ON

CHAR(1)

This flag allows us to turn off ETL temporarily for either APF or DBLINK sites. Unlike most columns in GEN_SITE, this column should only be set by a procedure and not set manually.

IS_ETL_TABLE

CHAR(1)

Indicates if the table or certain columns in the table is affect MSO. This is primarly used for verifying differences between databases in ETL tables.

IS_ETL_UNDER_DEVELOPMENT

CHAR(1)

Set to Y if the ETL is still under development to hide errors including no rows and disabled constraints that are acceptable.

IS_EXCLUDED_LINE_BALANCE

CHAR(1)

Lots on hold are excluded from line balance calculations if this flag for the hold type is set to Y. By default this is N which means that lots on hold of this type are included in line balance calculations.

IS_EXCLUDE_IN_MSO

CHAR(1)

This flag controls if a certain lot parameter will not increment the counters or impact the MSO system decisions. By default we allow all lots, but this provides excluding lots that client may not want to impact their sampling outcome.

IS_EXCLUSIVE_CHAMBER

CHAR(1)

This indicates that the tool may not run other jobs on other standby chambers while this job is running. For example, a process uses only chamber B on a three chamber tool. Normally that means you can run another job that uses A and/or C. However when this job is running you cannot run anything on chamber A nor C. If A and/or C are down you can still run the process on B.

IS_EXEMPT_FROM_TOP_ON_DASH

CHAR(1)

Normally we sort process familiies by Bottleneck Score or WIP but there are some facilities, usually logistics or sometimes metrology, that we do not want to show on the top even when the Score indicates they should be.

IS_EXPIRED_ON_NEXT_MEASURE

CHAR(1)

Defines if the waiver will expire once a lot is measured at Metrology. If the falg is set to Y the waiver will espire and is deleted even if the scan happens prior to the expiration time defined for the waiver.

IS_EXPIRED_ON_NEXT_TAG

CHAR(1)

Defines if the waiver will expire when the next lot is tagged or not. If the flag is set to Y the waiver expires and is deleted even if the tagged lot is before the expiration time defined for the waiver.

IS_EXPT_STEP

CHAR(1)

Flag set to Y if the experiment requires abnormal processing at this step.

IS_EXTERNAL

CHAR(1)

Y means the job is called externally so we should not expect it to be in ADM_LOAD_CFG_SCHED.

IS_EXTL_RANK_RENEWABLE

CHAR(1)

This flag indicates that if we run a lot applying to this record on the tool that we can renew the expiration of this rank. For example, a thread that expires after 48 hours of not being used. In this case, we would want to encourage scheduling a lot to renew the rank even if it is slightly lower priority than other lots.

IS_EXTRA_SCAN_BUFFER

CHAR(1)

This column allows you to bifurcate locations into 2 types. 1st is a real location that represents a physical spot, this is the default N value. The 2nd is if this location is not actually real and just being used to give extra space for whatever reason you may need it. If this is set to Y then it will not add to the cast_capacity displayed in the Dashboard.

IS_FIRST_TIME_RIGHT_FAIL

CHAR(1)

The denotes if this reason should count as a failed SDT episode. The idea is that if a Y flag is seen within the green to green (GTG) episodes after an SDT episode than that means that the SDT PM was not performed first-time-right, FTR. if the flag is set to N than the reason code will not cause a FRT fail.

IS_FIXED_FOR_SCHED

CHAR(1)

Y indicates that this upcoming maintenance time is fixed and should be scheduled around by the Scheduler.

IS_FUTURE

CHAR(1)

This should be set to Y if the state does not apply immediately. Production runoff and alarms are two examples where we do not want to set this state in ETP until the tool misses the cascade and starts to lose productivity.

IS_FUTURE_FACILITY

CHAR(1)

This flag is unnecessary and poorly named and will be dropped in a future release.

IS_HIDDEN_BY_DEFAULT

CHAR(1)

If this flag is set then this event is hidden by default on the Maintenance Dashboard to avoid clutter. There is an option to show hidden events.

IS_HIGHLIGHTED_PRTY

CHAR(1)

This flag indicates if this priority should be highlighted on the dashboard. When we sort all priorities by priority_sort all Y should be first followed by all N.

IS_HOLD

CHAR(1)

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.

IS_HOLD_END

CHAR(1)

Event ended hold

IS_HOLD_START

CHAR(1)

Event started hold

IS_IGNORE_MAIN_ENTITY_STATE

CHAR(1)

is used to determine on the chamber tool to know if it should ignore the main entity state and make it always UP?

IS_IGNORE_MOVABLE_TURNS

CHAR(1)

Movable turns differs from our standard turns calculation in that we ignore steps where lots are not expected to move like staging steps or logistics steps. Like is_ignore_turns, this flag can be set in either RTG_OPERATION_FAMILIES, RTG_PROCESSES, or RTG_LINE_SECTIONS.

IS_IGNORE_MOVES

CHAR(1)

This flag is in both RTG_OPERATION_FAMILIES and RTG_PROCESSES. If the value is Y for the operation family then we do not count moves from those operations as oper moves. If the value is Y for either the operation family or the process then we do not count moves from the route-step as completes even if our normal logic suggests that it should be a complete. This logic can cause confusion so here are a few important notes. 1) Dashboard does not read the is_ignore_moves flag therefore we must set move_type to DSKIP rather than COMP and we must set is_oper_move to N in order to ignore the move. 2) This flag is often used for staging steps but it is independent of the is_staging_step flag so if you want to ignore staging steps then you need to set these flags appropriately. 3) The flag in RTG_PROCESSES does not directly affect the oper moves but it does affect it indirectly if the is_comp_rqd_for_oper_move is set to Y. In that case, if the only move during the operation is for a process which is ignored then we do not have a complete during the operation and therefore will not count the move from the operation as an oper move since a complete is required.

IS_IGNORE_TURNS

CHAR(1)

This flag is in RTG_OPERATION_FAMILIES, RTG_PROCESSES, and RTG_LINE_SECTIONS. If this flag is Y in any of the three tables then we do not count turns at the route-step towards the total for the facility. We also ignore turns at route-steps where we ignore WIP and/or moves which makes sense since turns is moves divided by WIP. Finally we ignore turns for certain line sections towards the facility average.

IS_IGNORE_WIP

CHAR(1)

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.

IS_INACTIVE_STEP

CHAR(1)

Since we now use RTG_ROUTE_STEPS_INACTIVE table, we should only include the active steps on each route in RTG_ROUTE_STEPS. Therefore this value must be set to N in the RTG_ROUTE_STEPS table but will be set appropriately to Y for inactive steps in the RTG_ROUTE_STEPS_PLUS table.

IS_INCLUDED_WIP_FLUSH

CHAR(1)

If yes, then multi-facility WIP flush should include this LOT_GROUP when calculating weighted-average cycle time for future routes.

IS_INSERT_FROM_ETL

CHAR(1)

For APF, if Y then we include the column in our pre-built insert statement but not in our update statement. For REF views, if Y we include the column in the pre-build REF view but we only use it for insert and ignore for update. This allows the ETL to populate a default value on initial insert but then not update it since it will be updated manually.

IS_INTERNAL

CHAR(1)

Set to Y if the location is internal to the tool. For example, a bath inside a sink. This is critical to NextMove since we cannot direct a carrier to move to this port.

IS_IN_KIT

CHAR(1)

used to determine if this process group will show in kitting page

IS_IN_NMV_PICK_LIST

CHAR(1)

Set to Y if lot-step is within range to be displayed in NextMove Pick List according to hours/steps_to_schedule fields in GEN_FACILITIES

IS_IN_PRODUCTION

CHAR(1)

Boolean indicating whether a durable is in production or not.

IS_KEY_ON_FACILITY_DASH

CHAR(1)

Should be set for less than 5 of the most critical process families in the facility to keep them always displayed on the facility page in the Key Process Families section.

IS_KEY_ON_MODULE_DASH

CHAR(1)

Should be set for less than 5 of the most critical process families in the module to keep them always displayed on the module page in the Key Process Families section.

IS_LARGE_MANUAL

CHAR(1)

GrimRepo stores the data for manual tables and it really slows down if the table is large so CHK_TABLES warns if any manual table has over 500 rows. This flag tells CHK_TABLES to stop complaining.

IS_LAST_LOC_UNLOAD

CHAR(1)

Y means the last activity for the vehicle was a load. N means it was an unload.

IS_LAST_STEP_OPERATION

CHAR(1)

If Y then this step is the last step in an operation. By completing this step, the lot will move to a different operation which is usually the primary criteria to be counted as an oper move.

IS_LINE_SECTION_FROM_MAIN_RT

CHAR(1)

When a lot is on a rework route, our default is to use the line section from the main route rather than the line section from the rework route. This is because most facilities do not define a meaningful line section for their rework routes. For those facilities that define meaningful line sections for the rework routes and want to use them as the line section for lots on those routes, we set this value to N.

IS_LOAD_TIMER_COMBINED

CHAR(1)

Flag indicating whether a load and unload timer will be displayed, or just a single combined load timer.

IS_LOCATION

CHAR(1)

Y means this chamber is an acceptable location for material to be stored and the chamber will be passed through as an allowed location to other relevant DWH objects. The default is N which means the chamber is not an acceptable location.

IS_LOCATION_ASSUMED

CHAR(1)

This column flags whether or not the location value is an assumed value or not. An assumed value is when the location is set, usually within the ETL, based on certain conditions rather than actually coming from a source system directly.

IS_LONG_SETUP

CHAR(1)

Normally when rqd_setup from RTG_TOOL_ASSIGNMENTS does not match curr_setup from ETP_STATUS for the entity then the curr_rank is S for Setup. S is not blocked and lots are available to be scheduled using the appropriate setup penalty. If this is set to Y then the curr_rank is L for Long Setup. L is blocked and these lots are not available to be scheduled. This allows us to use the automatic functionality of ETP_STATUS for long setups without manual intervention.

IS_LOT_ASGN_INFO_RQD_FOR_SCH

CHAR(1)

Populating standard values for setup and batch information in RTG_TOOL_ASSIGNMENTS by process+tool and leaving these columns null in RTG_TOOL_ASSIGNMENTS_LOT/RTG_TOOL_ASGN_LOT_PROCESS in order to use the standard values from RTA is a recommended ETL strategy used at many sites. In contrast to IS_LOT_ASGN_RANK_RQD_FOR_SCH which has a default of Y, the default for this flag is N which means that our defaults are to only schedule lot-steps with ranks in RTAL and get batch/setup from RTA when this information is not populated in RTAL. But some sites want to use RTAL/RTALP exclusively and do not want to use any information from RTA. Setting this flag to Y does this and prevents the information from RTA from being used in WIP_STEP_FUT_ASGN_xxx views. Note if this flag is Y then the RANK flag must also by Y but if this is N then the RANK flag can be Y or N.

IS_LOT_ASGN_RANK_RQD_FOR_SCH

CHAR(1)

Our lot-tool assignments use a hierarchy where if we have any entries in RTG_TOOL_ASSIGNMENTS_LOT or RTG_TOOL_ASGN_LOT_PROCESS for a lot then the lot is only allowed on those tools and any others in RTG_TOOL_ASSIGNMENTS are inhibited. Normally if we have no entries in either lot assignments table then we use RTG_TOOL_ASSIGNMENTS. But for Scheduler we often only want to schedule lots which are included in the lot assignments table. Setting this flag to Y here or in RTG_PROCESS_GROUPS enables this behavior by setting eff_rank to I in WIP_STEP_FUT_ASGN_FOR_SCH for any lot without specific assignments by lot.

IS_LOT_BLOCKED

CHAR(1)

Boolean indicating whether a durable state causes associated lots needing to use the durable to show as blocked.

IS_LOT_PARAMETER

CHAR(1)

Flag to determine if the parameter is a lot parameter or one of the pre-defined paramter options.

IS_MAIN_ROUTE

CHAR(1)

Y indicates the route is the main processing route for PRD. N indicates it is a rework or alternate route.

IS_MANUAL

CHAR(1)

Y means the job is called manually so we should not expect it to be in ADM_LOAD_CFG_SCHED.

IS_MSO_ALLOWED_SUB

CHAR(1)

Flag indicating whether this step can be used as a process sub in the MSO application. This flag is only used by the UI for filtering purposes. A process sub is a metrology process that we cannot make a skip / take decision on, but can be run to clear counters.

IS_MSO_CONFIG_COPY_ENABLED

CHAR(1)

For sites using MSO, this flag allows the site to enable or disable the MSO rule configuration copy to this database. Usually this would be on to keep primary and secondary databases in sync, but in cases where and upgrade or planned failover is scheduled this can disable the auto copy job from executing.

IS_MSO_ON

CHAR(1)

Set to Y if the Metrology Sampling Optimizer application is being used. This will enable the triggers in WIP_EVENT_HIST_INSERT_BEF and EQP_EVENT_HIST_INSERT_BEF.

IS_MSO_SKIPPABLE

CHAR(1)

Flag indicating whether this step is allowed to be skipped by the MSO application. This flag controls the options for TO_MSO_PROCESS in the UI and it serves as a last check before sending a skip decision to the MES. Setting the flag to N will keep it from ever being sent as a skip step and will not show it as a Sample step in the UI

IS_MULTIPLE_REQUIRED

CHAR(1)

When more than one durable family of the same durable class is assigned to the same criteria, we use this field to determine whether to choose one or whether we need all. Our default indicated by N is that any of them can be used. Occasionally certain processes require multiple durables of the same group (i.e. double reticles) and you indicate this by setting this column to Y.

IS_N2

CHAR(1)

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.

IS_NEXT

CHAR(1)

Indicates record goes into WIP_STEP_HIST

IS_NMV_ON

CHAR(1)

Set to Y if the NextMove application is being used in production. This will enable SysMonitor alerts for NextMove checks

IS_NMV_PRIORITY

CHAR(1)

This flag indicates if this priority should be emphasized in NextMove

IS_NONSTD

CHAR(1)

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.

IS_NORMALLY_SCHEDULED

CHAR(1)

We show facility shutdowns on the progress chart on the Dashboard Lot page but for a facility that does not operate 24-7 then we do not want to show weeknights or nights when it is normally scheduled to be shutdown.

IS_NOT_USED

CHAR(1)

Y means the job is not used at this site so we should not expect it to be in ADM_LOAD_CFG_SCHED.

IS_NST_HIDDEN_ON_HIST

CHAR(1)

If yes then do not include time in this NST state in the history. Most NST states should be Y unless there is a specific reason why the client wants it to be part of the total. An example calculation here is if a tool is PRD for 1 day, SBY for 1 day, SDT for 1 day, UDT for 1 day, and NST for 3 days then the totals for the week are 25% each for PRD, SBY, UDT, SBY because the NST is ignored.

IS_OK_TO_USE

CHAR(1)

Boolean indicating whether a durable is ok to use immediately.

IS_ONLY_ALARM

CHAR(1)

Indicates that the entire episode consists only of alarm states as determined by the is_alarm flag in EQP_L5_TRANSITION_STATES. Typically these episodes consist of the tool being logged UDT by an alarm event like SPC failure and then being logged back up soon after so we might not want to include these episodes in MTTF/MTTR calculations.

IS_ONLY_QUAL

CHAR(1)

Indicates that the entire episode consists only of qual states as determined by the is_qual flag in EQP_L5_TRANSITION_STATES. Typically these episodes consist only of a frequent qual that is run by Operations and the Maintenance team is not involved therefore we might not want to include these episodes in MTTS calculations.

IS_OPERATION_FROM_MAIN_ROUTE

CHAR(1)

Operation is a field defined in RTG_ROUTE_STEPS and the operation of a lot is the operation of its current route and step. But some facilities prefer for the operation to be based on the main route and step rather than the current route and step so that lots which are on rework routes will show the operation from their main route. Setting this flag accomplishes this but please note that this only works for current WIP status and not for history.

IS_OPER_MOVE

CHAR(1)

The critical Dashboard metric we call oper moves is moves according to the specific definition of the site, usually the moves calculation they used prior to installation of the FPS Dashboard. If Y then this step move meets the specific criteria for the site to be counted as an oper move.

IS_OPER_MOVE_IF_REWORK_END

CHAR(1)

So far the decision to count the move which ends the rework and returns the lot back to normal production is only by facility but we have it by lot group to be consistent with the decision for rework moves.

IS_OPER_MOVE_IF_REWORK_MOVE

CHAR(1)

This is usually set to Y for Development so that we count an oper move even if reworked. This flag does not affect moves which start rework, even though those are strictly speaking a subset; the separate IS_OPER_MOVE_IF_REWORK_START flag covers those.

IS_OPER_MOVE_IF_REWORK_START

CHAR(1)

See comments on IS_OPER_MOVE_IF_REWORK_MOVE.

IS_OUTPUT_FOR_BAY

CHAR(1)

This flag indicates if this rack qualifies as an output rack for the bay for NextMove.

IS_PARALLEL_OTHER_CH

CHAR(1)

NOTE: Currently this is not set and is always N! This flag is for chamber tools where the job is running on some chambers while another job is running on entirely different chambers. For example, we expect a job on chambers AB to be faster running alone than when running in parallel with another job on chambers CD.

IS_PERMANENT

CHAR(1)

This boolean flag includes whether this is permanently disabled at this site. With the default value of N, SYSMNTR_DISABLED will remind you that it is disabled which can be helpful so you do not accidentally leave it disabled forever.

IS_PLAN_PRIORITY

CHAR(1)

Flag indicates whether this priority is a plan_priority which is the permanent priority for the lot. If this is N that indicates this is a temporary priority such as queue time warning or SPC jeopardy.

IS_PM

CHAR(1)

This should be set to Y if the state should count as a Preventative Maintenance, PM, event. This should only be Y on Scheduled (SDT) States. This is used in the Mean time to (perform) PM, MTTPM metric. (Does not include Wait-times. Can include Qualifications or Verification tests)

IS_PM_EVENT

CHAR(1)

Is set to Y if the event included a Preventative Maintenance, PM, event. This is used in the Mean time to (perform) PM, MTTPM metric. Should possible be called has_PM_event. Check L5_state_diagram for states.

IS_PRESET

CHAR(1)

Used by MSOUI to determine what waivers are done through the UI preset option.

IS_PRIMARY_MSO_DWH

CHAR(1)

Set to Y if the MSO the DWH is the primary MSO database that should be writing decisions to the cleint MES.

IS_PRI_LINK

CHAR(1)

Flag indicating if this link_oper is the primary link_oper for this smp_oper

IS_PRI_SMP_BY_TYPE

CHAR(1)

Flag indicating if this route-step is the primary smp_oper for this smp_type

IS_QUAL

CHAR(1)

This should be set to Y if the state should count as a qual event and time spent in this state should count as qual time. The EQP_L5_QUAL_CHECK constraint ensures that this must be set to Y when mnt_group is QUAL. The is_qual column is critical for NMV_P_TOOL_QUAL_SUMMARY and this constraint is not perfect but it prevents the most obvious wrong case.

IS_QUEUE_SKIP_ENABLED

CHAR(1)

Flag set to allow lots to be automatically skipped if a lot that was run later on the main processing tool is already at metrology or has already run through metrology.

IS_QUEUE_TIMER

CHAR(1)

Flag to display queue timer icon in NextMove if lot is in queue time loop.

IS_REAL_TOOL

CHAR(1)

Flag indicating whether tool physically exists. An example where this is not set would be lot start or visual inspect.

IS_REF_VIEW_USABLE_BY_OTHERS

CHAR(1)

REF views exist solely to refresh their corresponding table. Therefore in CHK_ALL, we flag if a REF view is used by any other object. Usually the solution to escape the wrath of this warning is to use a LOAD_xxx view for the commonly used logic. But occasionally there is a case when it is either impossible or extremely undesirable to do this and we really want to use the REF view in another object. For these special cases we added this column but we hope that you never use it!

IS_REPEAT_IF_SET_BY_EVENT

CHAR(1)

This column is only relevant if GEN_SITE.SET_REPEAT_BY_EVENT is set to Y. If so, then any move for this event is counted as a repeat and effectively not counted as a move. Typically the MES event name does not indicate repeat so we will have to add a Repeat suffix onto the event name in our ETL if the move is recorded as a repeat in the MES.

IS_RESERVED

CHAR(1)

This flag indicates if the carrier has been reserved to a tool.

IS_REWORK

CHAR(1)

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.

IS_REWORK_END

CHAR(1)

Event ended rework

IS_REWORK_START

CHAR(1)

Event started rework

IS_RUNNING_HOLD_IF_PROC

CHAR(1)

Normally when a lot goes on hold during processing we assume that it is no longer processing and we set the ECT state of the lot to HOLD and set the ETP state of the tool to SBY. But sometimes this can be a "running hold" which means that the lot continues processing and then will be on hold as soon as it finishes. There are two ways to indicate a running hold if put on hold during processing, either by this column for a hold_type or by the ignore_hold_for_proc_state column in EQP_TYPES for all tools in an eqp_type. The latter is normally used for metrology tools. This is an "or" condition so if a hold_type is Y that applies to all tools and if a tool is Y that applies to all hold types. When a lot goes on a running hold, we will set the ECT state of the lot to PRD-RUNHOLD and keep the ETP state of the tool in PRD. Then when the lot ends or moves to the next step, we will set the ECT state of the lot to HOLD and set the ETP state of the tool to SBY. Note that when we refer to setting the ETP state to SBY we technically mean that we use our normal END logic which will set to SBY unless a newer job has started then we keep ETP as PRD.

IS_SAMPLE

CHAR(1)

If Y then lots are allowed to skip this process

IS_SCHED

CHAR(1)

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.

IS_SCHED_BLOCKED

CHAR(1)

to indicate if there is any preceding steps UNSCHED

IS_SCHED_QUAL

CHAR(1)

This should be set to Y if the state should count as a scheduled qual event. (This is typically a qual run by the equipment operator rather than by the maintenance group.)

IS_SCRAP_EVENT

CHAR(1)

If the event results in any number of units in the lot to be scrapped then this field is set to Y. It is common to have scrap occur not only from a scrap event but also from a move event where the lot loses some but not all units. Therefore we cannot just look at scrap events and this flag tells what to count as scrap for this particular facility.

IS_SDT_SETUP

CHAR(1)

Boolean column indicating if the eqp_state is Scheduled Down due to setup conversion. We will note this in ETP_MNT_EPISODE_HIST to differentiate from regular PMs.

IS_SEC_FOR_BEG_END

CHAR(1)

Set to Y to store begin and end events logged to this entity in the SEC_BEGIN_INST and SEC_END_INST columns in WIP_STEP_HIST. The common example is for steppers where the begin and end for the lot will be from the track but we also want to store the begin and end for the stepper.

IS_SHIP_EVENT

CHAR(1)

This flag tells us what to count as a ship for a particular facility. Related to the ship event is the finish event which is the last event for a facility-prd which either changes facility or changes prd or terminates the lot by changing the qty to 0 without merging. Often the ship event is the same event as the finish event. But when the ship event is different and logged prior to the finish event, we write a record to CTM_FINISHED_LOT_HIST when the ship event is logged with finish_inst blank. This record is include in Dashboard Ships Summary but not in Finished Lot Cycle Time. Then later when the lot finishes, we update the record keeping the ship_inst and populating the finish_inst so it is then including in Finished Lot Cycle Time. Technically this "insert at ship then update at finish" process is the same regardless of how far the ship is before the finish but it is most critical when the the ship is quite some time before the finish, for example, when wafer test is part of the same route but we want to count the ship when the lot finishes the fab steps.

IS_SPECIAL_TW

CHAR(1)

Specifies if this lot type is a special type of test wafer. This is used a grouping field for reporting.

IS_SPECIFIC_PRD

CHAR(1)

This indicates if the future hold is a line hold applicable to all lots at the step for the specific product.

IS_SPECIFIC_ROUTE

CHAR(1)

This indicates if the future hold is a line hold applicable to all lots at the step for the specific route.

IS_STAGING_STEP

CHAR(1)

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.

IS_START

CHAR(1)

Boolean flag where Y indicates the lot is an upcoming start and not an existing lot.

IS_SUB_DECISION_TAG

CHAR(1)

This flag should be set to Y if the sub should count to reset the skip / take counter for the decisions history. Setting the flag to Y will mean the sub counts as a take decision. Setting the flag to N will reset the at risk count, but will not change any skip / take decisions.

IS_TEXT_ONLY

CHAR(1)

For text_only badges, background color, shadow, and border are removed.

IS_TIMER_STEP_TO_SCHED

CHAR(1)

The flag to indicate if this is the timer step to schedule

IS_TIMER_WIP_PRIORITY

CHAR(1)

Flag inicates if this priority is excluded from multi area non queue timer wip percentage calculation. If this flag is set to Y, any non queue timer WIP of the priority will count as 100% in multi area queue timer logic.

IS_TOOL_RQD_FLCT_FIRST_STEP

CHAR(1)

For the purpose of Finished Lot Cycle Time calculations, we consider the first step on the route to be the first step with real tools allowed. But some sites have some routes where the first step is a staging step with no tools allowed that we would like to count. This parameter which has default of Y allows us to configure by facility whether to a real tool is required when determining the first step for FLCT.

IS_TOOL_RQD_FOR_COMP

CHAR(1)

Set to Y if we only want COMP events to have move types of COMP when an entity is logged with the event. If N then all COMP events will count as completes.

IS_TRUNCATE_ALLOWED

CHAR(1)

Indicates if the history table can be truncated in the ADM_MSO_UTILITIES package

IS_TW

CHAR(1)

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.

IS_TW_ONLY

CHAR(1)

IS_TW_ONLY indicates that a PRD or ROUTE has only test wafer lots. This flag is slightly different than IS_TW, which is associated with lots via their LOT_GROUP. Some PRDS/ROUTEs are mixed and this is set to N if there are any non-TW lots.

IS_TW_USE

CHAR(1)

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.

IS_UNLOADED

CHAR(1)

Boolean indicating whether the lot has been unloaded.

IS_UP

CHAR(1)

This field shows if the port mode of the stations is considered up or down. If all ports are down then rank will be R (Ports Down) and ETP will set the state to SBY-RANKR (Standby With All Ports Down).

IS_USED_FOR_GOALS

CHAR(1)

If yes, lot group will be included in goal calculations. Filter is applied in FPSBASE.WIP_REF_GOAL_EST_SHIFT view: IS_USED_FOR_GOALS = Y.

IS_USE_SETUP_CHG_FINAL

CHAR(1)

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details.

IS_USE_TOOL_ASGN_OVR_ONLY

CHAR(1)

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details.

IS_VALID

CHAR(1)

We consider a lot valid for our finished lot calculations when the lot moved through the first step and the last step on the main route for its product. There are some variations such as the lot moved through the first step on an older version of the route or finished with an event specifically marked as a ship event or the route did not have any steps.

IS_VALID_LOT

CHAR(1)

Flag to indicate of the lot logged is a valid lot. If the lot is not valid then the tool_to_clear value is used to reset the counter.

IS_VIRTUAL_CHAMBER

CHAR(1)

This flag determines whether a chamber is a virtual chamber on a tool. Virtual chambers are used for scheduling but are not tracked like real processing chambers or assist chambers in other applications. Virtual chambers exist in ETP but always contribute 0% towards the cluster calculation for the tool. An example of this usage would be to model each of the sources for an implanter as a virtual chamber, so the area would be able to log these chambers up and down as needed. When a source needs replacement, it can be logged down and the scheduler will not schedule lots needing that source, instead switching to one of the available sources. Another example would be modeling the robot as a virtual chamber on a tool.

IS_WAITING_FOR_PARTS

CHAR(1)

If this is set then the maintenance event is effectively on hold waiting for parts.

IS_WARN_WHEN_LOGGED_AFTER_COMP

CHAR(1)

We normally log an error in WIP_EVENT_HIST if an event is logged for a lot before its current step_ent_inst. This means that the events were logged out of order. Specifically it means COMP event was logged to WIP_EVENT_HIST and then another event with an inst before the inst of the COMP event was logged subsequently. For certain events, usually END events logged by a separate automation system outside of the MES, this behavior is acceptable and we can just ignore this and this flag allows us to configure this by event.

IS_WITHIN_APF

CHAR(1)

Y means the job is called within an APF rule or report so we should not expect it to be in ADM_LOAD_CFG_SCHED.

JOB_DEBUG_INFO

VARCHAR2(128)

Debug information written by trigger regarding the population of the job-related fields for each event.

JOB_GROUP

VARCHAR2(50)

To indicate which group. for first version, it will only allow REALTIME, 10MIN, SHIFT

JOB_ID

VARCHAR2(64)

Automatically set by trigger when the first lot of a job logs an event to the tool.

JOB_NAME

VARCHAR2(500)

the name of the scheduled-job, should also include schema name

KEEP_ACTIVE

CHAR(1)

Manual flag to keep record active even if no activity for the prd-route

KEEP_FULL_LOTS_PER_LOOP

CHAR(1)

This flag determines if the Scheduler will add another lot to the loop after a lot is placed on the schedule in order to always keep the full number of lots in the loop. Having this flag on might slow down the calculation but is critical for tools with setup penalties and many different setups -- for example reticles on Litho cells. We will explain with a long example here. This full number of lots in the loop is determined by the configurable parameter NUM_LOTS_TO_SCHEDULE_PER_LOOP which has a default of 50. We always start by placing the processing and dispatched lots on the schedule and then picking the top 50*2=100 lots to go in the first loop based on the scores. These scores include setup based on the newest dispatched lot to each tool. The Scheduler does its looping algorithm on these 100 lots and places the most important lot on the schedule. We will say it was scheduled to tool T1 for example. If this flag in N then the Scheduler proceeds with its looping algorithm on the remaining 99 lots and places the next most important lot on the schedule -- and continues to do this 48 more times until it places 50 of the 100 lots in the first loop on the schedule. Then it calculates the scores for all remaining lots -- including the leftover 50 and all that did not make it in the first 100 -- and picks the next best 100. Then it does 50 loops to place lots 51 through 100 on the schedule. Then recalculates scores and continues until the full schedule is complete. The weak spot with this faster logic is that if lot #101 in the original loop is the same setup as the 49th lot placed on the schedule but none of the remaining 51 lots in the first loop match this setup that we will place one of these 51 lots next causing a setup change and then schedule lot #101 which had the same setup later. This would result in a particular tool having a schedule with setups A-A-B-B-A when we could have done A-A-A-B-B. That is where this flag helps. If this flag is Y then we still pick the top 100, do the looping algorithm, and place the first lot on the schedule to tool T1 as before. But then we recalculate the scores for the lots 101 and above which were not in the original loop -- but only for those lots allowed to T1 where we just placed a lot. Of all of these remaining lots we pick the top score and add to the 99 lots remaining from the first loop. This keeps 100 lots in the loop at all times! Scheduler does its looping algorithm and places a second lot on the schedule (for T2). Now it recalculates the scores for remaining lots that can run on T2 and adds the top lot to the loop. Note that if it did not find any lots allowed to T2 then it will add another lot to the loop so now we will have 99. This flag solves the same setup weakness described above because when the lot placed on the schedule is setup S1 then the next lot added to the loop would be another S1 lot if the scores determined that same setup was important enough to maintain.

KEEP_IN_PRD_WHILE_JOBS_EXIST

CHAR(1)

This flag is used to keep tools in a PRD etp state if jobs are still active for any entity of this tool. If the value is set to Y then there must be no records in WIP_CURR_JOBS for the entity when an end event type occurs.

KEEP_MAIN_ROUTE_ACTIVE

CHAR(1)

One way to reduce the number of active routes is to not activate the main_route of lots that have been sitting in a bank for awhile. To do this, set this column to N.

LABEL_DURABLE

VARCHAR2(36)

is used to define the label of durable. in most of cases it will be Reticle

LABEL_DURABLE_CARRIER

VARCHAR2(36)

is used to define the label of durable carrier. in most of cases it will be Pod

LABEL_LOT_RANK

VARCHAR2(36)

is used to define the label of lot rank. it can be critical ratio or anything

LABOR_AREA

VARCHAR2(36)

LABOR_AREA allows the ability to create custom groups of tools that are not necessarily in the same bay. This allows you to assign tools to custom work areas that match the way they run the fab.

LABOR_EFFICIENCY_PCT

NUMBER(3)

This is a percentage that will be used to remove the time operators spend doing things other than loading tools from their total available time. This value is tool specific because the location of the tool matters for the delivery time.

LABOR_ROLE

VARCHAR2(36)

Labor roles indicate who can support processing on a particular eqp_type. For example, a metrology tool might require a more experienced technician to do the inspection than a processing tool which just needs to be loaded.

LABOR_SEC_PCT_FROM_LOAD

NUMBER(3)

Specifies the amount of LABOR_SEC_PER_CARR that is associated with loading vs unloading. The default of 50 means that load and unload take the same time each half of the total. Then if load took 60 sec and unload took 40 sec we would enter 100 sec in for the labor_sec_per_carr and enter (60/100)100=60 as the percentage

LABOR_SEC_PER_BATCH

NUMBER(8,3)

Required labor seconds for this labor role to run a batch

LABOR_SEC_PER_CARR

NUMBER(8,3)

Required labor seconds for this labor role to run a carrier

LABOR_SEC_PER_UNIT

NUMBER(8,3)

Required labor seconds for this labor role to run a wafer

LAST_ACTIVITY_MORE_THAN_2D_AGO

DATE

For frequently used PRDs and ROUTEs we do not want to keep updating the last activity time on every update. But we need to store the last activity time for PRD/ROUTEs which have no recent activity as we will delete them after GEN_FACILITIES.DAYS_TO_KEEP_PRD_ACTIVE days. To achieve these objectives, we only populate this field if the last activity was more than 2 days ago and then we clear it when the lot has new activity.

LAST_END_INST

DATE

Time when the last occurrence of this maintenance was completed if known. It is common for this field to be null for all records.

LAST_END_OPERATOR

VARCHAR2(64)

Username of the user that logged last completed occurrence of this maintenance if known. It is common for this field to be null for all records.

LAST_FAIL_INST

DATE

when was the last time job ran failed

LAST_FAIL_NOTES

VARCHAR2(4000)

the notes from the last time job ran failed

LAST_HOLD_INST

DATE

Time when the lot was last placed on hold.

LAST_KNOWN_DURABLE_LOC

VARCHAR2(32)

The previous location of the durable.

LAST_KNOWN_LOCATION

VARCHAR2(32)

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.

LAST_KNOWN_LOCATION_INST

DATE

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.

LAST_LOCATION

VARCHAR2(32)

Last location of vehicle is set by trigger based on the previous location of the carrier most recently loaded from/to the vehicle.

LAST_LOCATION_INST

DATE

Time when the vehicle last loaded or unloaded a carrier.

LAST_LOGIN_INST

DATE

Last cart login time

LAST_LOGOUT_INST

DATE

Last cart logout time

LAST_NAME

VARCHAR2(36)

Last name of the user.

LAST_PROCESS_TOOL

VARCHAR2(16)

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.

LAST_PROCESS_TOOL_BEG_INST

DATE

Time when the lot finished processing on the previous tool (excluding metrology).

LAST_RELEASE_INST

DATE

Time the lot was previously released from hold.

LAST_START_INST

DATE

Time when last completed occurrence of this maintenance started if known. It is common for this field to be null for all records.

LAST_START_OPERATOR

VARCHAR2(64)

Username of the user that logged last started occurrence of this maintenance if known. It is common for this field to be null for all records.

LAST_STEP_CURR_PRTY

VARCHAR2(256)

The last step where the current lot_priority applies. After this step we assume the lot will return to its plan_priority.

LAST_SUCCESS_INST

DATE

when was the last time job ran successfully

LAST_TOOL

VARCHAR2(16)

For rework and scrap events we automatically look up the last tool where the lot processed including metrology tools.

LAST_TOOL_BEG_INST

DATE

Time of the last event on the previous tool (including metrology) for the lot occurred.

LAST_WFR_BEG_INST

DATE

Time when the last wafer of the job started processing.

LAST_WFR_END_INST

DATE

Time when the last wafer of the job finished processing.

LATE_DAYS_LOGISTIC_SLOPE

NUMBER(4,2)

The steepness of the S-curve function for lot days late. Larger numbers mean steeper curves - i.e. closer to a step function change.

LATE_DUE_INST

DATE

to store the late due time of the floating PM tool event, i.e., the late start time of the floating PM could be calculated via substracting the EST_DURATION_SEC value

LATE_INST

DATE

Latest time when maintenance can be started. In most systems, the entity in question will be mandatorily logged down if the maintenance is not started by this time.

LB_FUT_WIP_DELTA_CALC_TYPE

VARCHAR2(8)

Determines how future step WIP deltas are aggregated. Options are "SUM" and "WAVG". SUM means the straight sum is taken of the future step WIP deltas. WAVG means the weighted average of the future step WIP deltas is used.

LB_GROUPING

VARCHAR2(48)

Allowed values are "ROUTE STEP", "ROUTE FAMILY COMMON STEP", "ROUTE GROUP COMMON STEP", "COMMON STEP", "ROUTE FAMILY PROCESS", "ROUTE GROUP PROCESS", "PROCESS", "ROUTE FAMILY PROCESS FAMILY", "ROUTE GROUP PROCESS FAMILY", and "PROCESS FAMILY". This determines the level at which line balance is aggregated. ROUTE STEP means the line balance calculation is evaluated within each route for each step. COMMON STEP means the line balance calculation is evaluated across routes for each COMMON STEP, assuming common steps are shared across routes. PROCESS means the line balance calculation is evaluated across routes for each PROCESS, assuming processes are shared across routes. PROCESS_FAMILY means the line balance calculation is evaluated for each process relative to the process_families that are ahead. Normally a target WIP ratio is calculated for each route/step or process looking ahead at future route/steps or processes. When PROCESS_FAMILY is specified, the current target WIP ratio for the process is compared against the target WIP ratios for the future process_families, which includes processes that may be in different parts of the process flow. This setting can be used to slowdown the feed of WIP to process_families but may not result in balanced WIP across processes in the process flow.

LB_HORIZON_DAYS

NUMBER(3,1)

Line Balance horizon in days of cycle time. Controls how far downstream from each step, expressed in days of cycle time, the line balance calculation includes. This is treated as an OR condition in conjunction with LBR_HORIZON_NUM_STEPS.

LB_HORIZON_NUM_BLOCKS

NUMBER(2)

Line Balance horizon in number of line balance group units. Controls how far downstream from each step, expressed in number of blocks of line balance group, the line balance calculation includes. This is treated as an OR condition in conjunction with LBR_HORIZON_DAYS.

LB_NORMALIZATION_GROUPING

VARCHAR2(32)

This determines the grouping used to calculate the normalized line balance score. If set to facility then normalization is done across the facility. If set to route section or any other value then the normalization is done within the group which means there may be multiple max or min scores that represent different effective WIP deltas across the facility.

LB_NORMALIZATION_METHOD

VARCHAR2(24)

This determines the method used for normalization, which is either linear or logistic S-curve. Logistic creates greater seperation of scores that are closer to 0.

LB_QMODEL_MAX_XFACTOR

NUMBER(4,1)

The max X-factor that is allowed to be used when using the queueing model method to calculate target cycle time and corresponding WIP

LB_QMODEL_MIN_XFACTOR

NUMBER(4,1)

The min X-factor that is allowed to be used when using the queueing model method to calculate target cycle time and corresponding WIP

LB_QTIMER_START_STEP_PCT

NUMBER(3)

The percentage of target WIP that should be reallocated from steps in queue timers to the start step. If multiple timers overlap the WIP will be reallocated to the earliest start step.

LB_ROUTE_MIN_NUM_LOTS

NUMBER(3)

Filter for number of lots within a route for it to be considered within the line balance logic, helps with efficiency of computation as well as considering only main runners

LB_STEP_MIN_SMP_PCT

NUMBER(3)

Sets the minimum required sample rate to be considered in the line balance normalization calculation. Useful when metrology steps are dominating the line balance score.

LB_TARGET_BASIS

VARCHAR2(36)

Basis of determining line balance target distribution. Default is 1x process time from CTM_SUMMARY historical data, but can updated with TCT to use TCT_SEC instead.

LB_TARGET_METHOD

VARCHAR2(14)

Method of calculating the cycle time used to determine the ideal WIP distribution for the line balance WIP targets. 1X FACTOR means distribute the WIP based on the process time only. QUEUEING MODEL means distribute the WIP based on a target cycle time that is calculated using a queueing model. Note that the QUEUEING MODEL method relies heavily on the VARIATION_FACTOR set in EQP_TYPES.

LB_WIP_DELTA_WEIGHT_PCT_CURR

NUMBER(3)

The percentage of weight given to the current step WIP delta. This can be used to change the weighting of the WIP delta for the current step relative to future steps.

LB_WIP_DELTA_WEIGHT_PCT_FUT

NUMBER(3)

The percentage of weight given to the future step WIP deltas. This can be used to change the weighting of the WIP delta for the future steps relative to the current step.

LE_SEQ_WITHIN_SEC

NUMBER(2)

For rows with identical timestamps, sequence records to get proper sequence for logged entity.

LIMIT_TYPE

VARCHAR2(64)

limit type, can only be setup, recipe, recipe_family, recipe_group

LIMIT_VALUE

VARCHAR2(100)

the value of this type, for example the value of the recipe

LINE_SECTION

VARCHAR2(32)

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.

LINE_SECTION_IF_NO_MAIN_RT

VARCHAR2(32)

Line section is in RTG_ROUTE_STEPS but the Dashboard uses this filter for the bank spotlight too so this allows us to put lots of this prd which are in a bank and not on a main route into a specific line section.

LINE_YIELD_PCT

NUMBER(6,3)

Sort yield percentage from the current step to the finish of the specified route/bank. If the route/bank is not the current one then this included all steps.

LINE_YIELD_PCT_TO_EOL

NUMBER(6,3)

Line yield percentage to end of line is the percentage of units expected to successfully complete the remaining steps on the route. Normally we multiply the line yield of all remaining steps for the Capacity Model but entering a value in this OVR table manually overrides that calculated number.

LINKS_REQ_ALLOWED_TAG_COND

CHAR(1)

Define if rule links require an allowed tag condition to be able to tag at the main process step. This is usually set to N unless the metrology step requires recipes to exist in those cases we set to Y to be able to only TAG when an allowed tag condition for the rule link is defined.

LINK_FIRST_KEY

VARCHAR2(250)

The key for the first step, for example COAT

LINK_NEXT_KEY

VARCHAR2(250)

The key for the next step, for example STEP

LINK_STEP

VARCHAR2(256)

Linked step assigned to the sampling step.

LINK_TEXT

VARCHAR2(100)

The text of the report link

LINK_TYPE

VARCHAR2(12)

This value must be SKIP, TAG, or ALL. If the value is SKIP, then any parent mso decision that is skip will force all child processes to also SKIP. If the value is TAG, then any parent mso decision that is tag will force all child processes to TAG. For ALL, all child processes will match the decision of the parent process.

LOAD_JOB

VARCHAR2(10)

Name of load job

LOAD_ORDER

NUMBER(3)

Order of objects to load within the load job

LOAD_SEC

NUMBER(4)

For throughput purposes, we would like the begin event to be logged when the first wafer of the lot enters the tool so that we can accurately track theoretical cycle time (TCT) which starts at this point. If the tool logs as desired then this column will be 0 and it usually is. But some tools do not log the begin event until some amount of time later, for example after the pumping time. This column exists to account for this delay and it is the number of seconds from when the first wafer enters until the begin is logged. We simply add this time to the processing time to get the TCT. This is by eqp_type as we estimate that all recipes of all tools in the same eqp_type will be consistent in this behavior. Please note that unload_sec is similar for any time after the end event until the lot can be unloaded.

LOCATION

VARCHAR2(32)

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.

LOCATION_INST

DATE

Time when the carrier arrived at the location.

LOC_ON_RACK

VARCHAR2(5)

This is the short name of the location on the rack, probably a combination of the x, y, and z coordinates. This field is unique within the given rack and is used to save space when we already know the rack, for example on the rack NextMove screen. If the rack is the location then this should be blank. This column is in contrast to the location field which is the full name of the location. Location is unique within the entire site and almost always includes the rack name. Location is what is in MHS_CARRIERS and gets set when the carrier arrives as the location.

LOC_ON_VEHICLE

VARCHAR2(5)

This is the short name of the location on the vehicle, probably named something simple like S1, S2, etc. but perhaps if the vehicle has two levels perhaps A1, A2, B1, B2, etc. This field is unique within the given vehicle and is used to save space when we already know the vehicle, for example on the vehicle NextMove tablet. This column is in contrast to the location field which is the full name of the location. Location is unique within the entire site and almost always includes the vehicle name. Location is what is in MHS_CARRIERS and gets set when a carrier is placed on the vehicle.

LOGGED_ENTITY

VARCHAR2(36)

Entity to which event is logged in the MES. This could be a main tool, subtool, entity, or port. In MNT tables this could be a vehicle or durable as well which is why the column width is wider. If main tool or port, we apply the event to all entities. If subtool we apply to all within the subtool. If entity we apply only to the entity.

LOGICAL_RECIPE

VARCHAR2(100)

Used for infomational purpose and is populated if known otherwise it will match the recipe.

LOGS_AUTO_BEGIN

CHAR(1)

For tools that log auto begin events we want the manual begin (i.e. the MES lot start or batch start or track in) to count as a DISPATCH event. But for tools which do not log auto begin events, we want the manual begin to count as a BEGIN_M event. We automatically calculate logs_auto_begin for each tool and then we set events which are configured as BEGIN_M in WIP_EVENTS to DISPATCH where logs_auto_begin is Y.

LOGS_LOT_BEG_END_FROM_EQP_CHG

CHAR(1)

This flag is for some older simple tools that automatically log that the tool started and finished processing but do not know the lot. When this is set to Y then when the eqp_state changes to PRD we look up the most recently dispatched lot and log a BEGIN event for that lot. Similarly when the eqp_state changes from PRD then we log an END event. For batch tools, we assume all dispatched lots are in the batch when we log BEGIN and we assume all processing lots are in the batch when we log END. If you set this to to Y for any tool then you must insert both BEGIN_FROM_EEH and END_FROM_EEH into your WIP_EVENTS table.

LOG_QUERY_START

CHAR(1)

This is for tables loaded by APF only where we run the APF report first and then the sqlplus query. Normally we just log the start and end of the object so the total time includes both report and query. If you want to track each independently set this to Y and we will log a record in ADM_LOAD_HIST at the end of the report which is also the start of the query.

LOT

VARCHAR2(32)

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.

LOTS_AT_RISK_AVG_LOWER_LIMIT

NUMBER(8)

Tool level limit that is used to highlight in the dashboard how many tools have an average lots at risk under the lower limit value. The lots at risk is a increments each time a lot runs at the main process tool until a measurement triggers the counter to reset.

LOTS_AT_RISK_AVG_UPPER_LIMIT

NUMBER(8)

Tool level limit that is used to highlight in the dashboard how many tools have an average lots at risk under the upper limit value. The lots at risk is a increments each time a lot runs at the main process tool until a measurement triggers the counter to reset.

LOTS_AT_RISK_MAX_LOWER_LIMIT

NUMBER(8)

Tool level limit that is used to highlight in the dashboard how many tools have a max lots at risk under the lower limit value. The lots at risk is a increments each time a lot runs at the main process tool until a measurement triggers the counter to reset.

LOTS_AT_RISK_MAX_UPPER_LIMIT

NUMBER(8)

Tool level limit that is used to highlight in the dashboard how many tools have a max lots at risk under the upper limit value. The lots at risk is a increments each time a lot runs at the main process tool until a measurement triggers the counter to reset.

LOTS_IN_JOB

NUMBER(2)

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.

LOT_ACTIVITY_INST

DATE

Date/time when the lot last had activity.

LOT_ASGN_RATIO

NUMBER(5,2)

This is the ratio of lot assignments by tool calculated by the DWH

LOT_DUE_INST

DATE

the due date of the lot

LOT_FAMILY

VARCHAR2(24)

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.

LOT_GROUP

VARCHAR2(8)

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.

LOT_GROUP_DISPLAY

VARCHAR2(24)

The name of the lot_group displayed on all dashboards and reports. We allow a longer more descriptive name here although often this will be the same as the lot_group.

LOT_GROUP_EACH_NA

VARCHAR2(8)

Define what lot groups will be tracked in the MSO_RULE_COUNTER_HIST tables.

LOT_GROUP_NA

VARCHAR2(8)

Lots that are of the defined lot mso group will be tagged or never tagged, depending on the condition type that is selected. If the value is NA the check is ignored.

LOT_GROUP_TO_SCHED_LIST

VARCHAR2(64)

By default we will schedule all lots when a tool is in a state where mfg_state is MFG (PRD and SBY but not ENG). For NONMFG states use this column to schedule lots of certain lot_groups, most likely test wafers.

LOT_MSO_GROUP

VARCHAR2(8)

Grouping of lot types to be used specifically for the MSO application for tag conditions and counter settings.

LOT_MSO_GROUP_EACH_NA

VARCHAR2(8)

Define what lot mso groups will be tracked in the MSO_RULE_COUNTER_HIST tables.

LOT_MSO_GROUP_NA

VARCHAR2(8)

This is the counter definition value for lot mso group. If lot mso group is not part of the rule definition and included in the counter then it will be NA, otherwise it will have the lot mso group value.

LOT_NA

VARCHAR2(16)

Lots that have a matching lot id will be tagged or never be tagged depending on the condition type selected.

LOT_OR_ALT_ID

VARCHAR2(128)

This is the primary key of this table which is the actual lot ID if available or an alternate ID if not. That alternate ID would likely be a combination of the product and start date range. Note that we can record starts representing more than one lot with a single record in this table. For example, we might have 200 starts for a product during an upcoming work week and we would enter 200 as start_qty and the start of the work week as inst and the end of the work week as start_range_end_inst. Then we would assume those starts would be distributed in lots matching the max_qty_in_carrier for the facility across the entire work week. Alternatively we might record single lot starts with a specific start time by entering the lot as lot_or_alt_id and the qty as start_qty and the start time as inst and leave start_range_end_inst blank.

LOT_PARAMETER_NAME

VARCHAR2(32)

Lots that have this MES parameter set with its corresponding value will be tagged or never tagged, depending on the condition type that is selected. If the value is NULL the check is ignored.

LOT_PARAMETER_VALUE

VARCHAR2(32)

Lots that have this MES parameter value will be tagged or never tagged, depending on the condition type that is selected. If the value is NULL the check is ignored.

LOT_PARM_NAME

VARCHAR2(32)

Lots that have this MES parameter set with its corresponding value will be tagged or never tagged, depending on the condition type that is selected. If the value is NULL the check is ignored.

LOT_PARM_VALUE

VARCHAR2(32)

Lots that have this MES parameter value will be tagged or never tagged, depending on the condition type that is selected. If the value is NULL the check is ignored.

LOT_SEQ_WITHIN_SEC

NUMBER(2)

For rows with identical timestamps, sequence records to get proper sequence

LOT_SUBTYPE

VARCHAR2(8)

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.

LOT_TYPE

VARCHAR2(24)

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.

MAIN_ROUTE

VARCHAR2(256)

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.

MAIN_ROUTE_FAMILY

VARCHAR2(36)

Route family of the main route for the prd of the lot.

MAIN_ROUTE_GROUP

VARCHAR2(36)

Route group of main route. Often referred to as technology.

MAIN_RT_REMAINING_PCT

NUMBER(5,3)

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

MAIN_RT_STEP

VARCHAR2(256)

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.

MANL_RESERVE_CH_TO_USE

VARCHAR2(24)

List of chambers to use for processing set by NextMove when lot is reserved.

MANL_RESERVE_INST

DATE

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.

MANL_RESERVE_TOOL

VARCHAR2(16)

Stores tool reserved by NextMove

MANUFACTURER

VARCHAR2(36)

Manufacturer of the tool used for display purposes only.

MAP_COORD_X

NUMBER(4)

This is the x coordinate of the bay on a map of the building. MHS_BAY_TO_BAY_MATRIX_PLUS uses the distance to estimate the bay-to-bay transit time if it is not specifically populated in MHS_BAY_TO_BAY_MATRIX.

MAP_COORD_Y

NUMBER(4)

This is the y coordinate of the bay of a map of the building. See MAP_COORD_X comment for more details.

MAX_ALLOWED_PER_UNIT

NUMBER(4)

the maximun allowable per unit

MAX_BATCH_SIZE_CARRIERS

NUMBER(2)

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.

MAX_BATCH_SIZE_LOTS

NUMBER(2)

The maximum number of lots allowed in one batch

MAX_BATCH_SIZE_UNITS

NUMBER(7)

Maximum number of units which can be loaded together in a batch for a tool where the batch size is limited by the number of units. This value should nearly always be greater than the standard lot size. If it is less, that means that standard lots must be split in order to run on this tool. This is rare but possible therefore we have no constraint and allow this value to be as small as 1. This column will be null for non-batch tools. For batch tools,There are three cases to consider here. The first case is where the limit is only on carriers which is most common. For example, a furnace can load up to 6 carriers regardless of the units in each carrier. In this case, max_bs_carriers is 6 and max_bs_units is null. The second case is where the limit is only on units. For example, the tool can load 100 wafers regardless of the number of carriers. In this case, max_bs_units and max_bs_carriers should both be 100 which indicates that we could theoretically load a full batch of 100 carriers each with one unit. The third case is where the limit is on both carriers and units. For example, you can load up to 4 carriers and up to 80 units (meaning you cannot load 4 carriers of 25 units each nor can you load 5 carriers of 15 wafers each). In this case, max_bs_carriers is 4 and max_bs_units is 80.

MAX_CAL_SEC

NUMBER(6)

This is used to set how many seconds allowed to run the single-looping calculation. This includes all time taken for parallel calculation in AVG_CAL_SEC. As an example, if AVG_CAL_SEC is 300 and MAX_CAL_SEC is 360 then the first 300 seconds will be done with parallel calculation and the remaining 60 with serial/single-loop calculations. If scheduler takes more than this time to complete, it will be tagged as SLOW. This value should be greater than or equal to AVG_CAL_SEC. If equal to AVG_CAL_SEC, all calculations will be done via parallel calculations.

MAX_CARRIERS_TO_RESERVE

NUMBER(2)

Maximum number of carriers the tool is allowed to reserve. This is tool specific and the process might have a different restriction and we take the min.

MAX_CONSECUTIVE_SKIP_WARN

NUMBER(5)

Value to be used in reporting and for alerts when the maximum number of skips is getting high for the rule. This value does not impact actual sampling decisions.

MAX_CONSECUTIVE_SKIP_WARN_WVR

NUMBER(5)

The warning value consecutive skips for the defined rule and tool waiver.

MAX_CONSEC_SKIP_MES_PARAMETER

VARCHAR2(100)

Configurable parameter that will be sent to the MES if the maximum consecutive skip trigger mes action limit is exceeded.

MAX_CONSEC_SKIP_TRG_MES_ACTION

NUMBER(5)

Maximum number of consecutive skip decisions that are allowed for a PERCENT/TIME rule before MES action is triggered by MSO. This limit will not automatically set lots to tag, rather tell the MSO system to initiate a message to the MES (i.e. log tools down)

MAX_CON_SKIP_TAG_LOT_BASE

NUMBER(5)

Max consecutive skips to hit sample percent. Calculated from 1/n value. Should not be changed or updated. This value is not actually used in the percent rule algorithm.

MAX_CON_SKIP_TAG_LOT_DEFAULT

NUMBER(5)

Default value to be used in percent rule calculation. Initial load defaults to base MAX_CON_SKIP_TAG_LOT_BASE value + 20%. This value is used in the percent rule algorithm unless there is a rule override value.

MAX_CON_SKIP_TAG_NEXT_LOT_OVR

NUMBER(5)

Maximum number of consecutive skip decisions that are allowed for a PERCENT/TIME rule before the next lot that process will be tagged to measure, regardless of the sample rate. In cases where rule interaction may tag multiple lots we do not want to skip many lots until the sample rate drops.

MAX_CON_SKIP_TAG_NEXT_LOT_WVR

NUMBER(5)

When the consecutive skips count reaches this limit, MSO will tag the next available lot for the defined rule and tool waiver.

MAX_CON_SKIP_TRG_MES_ACTN_WVR

NUMBER(5)

When the consecutive skips count reaches this limit, MES action will be triggered for the defined rule and tool waiver.

MAX_CTM_XFACTOR

NUMBER(5,2)

Maximum x-factor, which is a multiplier of raw process time, that cycle time will be allowed to be for predicting future step arrival times. For example, if the value is set to 1.5 for hot lots, then cycle time will be capped at 1.5 * process time for each step.

MAX_DAYS_FOR_MNT_INSTANCE

NUMBER(3)

The maximum days in the future that we will show subsequent instances of maintenance events. Note that the next instance is not affected by this maximum. See comment on mnt_instances_per_event column for example.

MAX_HOLD_SEC_FOR_WSF

NUMBER(8)

Prevent huge cycle times at steps where a minority of lots have been on hold for an exceedingly long time

MAX_LAR_MES_PARAMETER

VARCHAR2(100)

Configurable parameter that will be sent to the MES if the maximum lots at risk trigger mes action limit is exceeded.

MAX_LAR_TRIGGER_MES_ACTION

NUMBER(9)

Maximum number of consecutive lots at risk for a PERCENT/TIME rule before MES action is triggerd by MSO. This limit will not automatically set lots to tag, rather tell the MSO system to initiate a message to the MES (i.e. log tools down)

MAX_LAR_TRIGGER_MES_ACTN_WVR

NUMBER(9)

When the lots at risk value reaches this limit, MES action will be triggered for the defined rule and tool waiver.

MAX_LAR_WARN

NUMBER(9)

Value to be used in reporting and for alerts when the maximum number of lots at risk is getting high for the rule. This value does not impact actual sampling decisions.

MAX_LAR_WARN_WVR

NUMBER(9)

The warning value of lots at risk for the defined rule and tool waiver.

MAX_MERGE_NUM_LOTS

NUMBER(2)

At some sites we schedule lots to be merged there can be limitations to the total number of additional lots that can be merged together in a single carrier. This limit maybe met without reaching the maximum number of wafers in the lot. If this number is set to 1 then another lot can be merged into the same carrier with this lot. 0 or null here means no lots can merge into this carrier

MAX_MSO_DECISION_STEPS

NUMBER(4)

The maximum number of steps away between a MSO main process step and metrology step can be so that the MSO can make a skip/tag decision. If this value is null then the limit is not applied otherwise the steps must be within range when evaluating a process link for an MSO rule.

MAX_NUM_TO_FIX_EQP

NUMBER(5)

Maximum number of entities allowed to be fixed automatically by ADM_FIX_EQP_STATUS. Typically if this procedure wants to fix a large number of entities this indicates a significant problem with the load which should be addressed.

MAX_NUM_TO_FIX_WIP

NUMBER(5)

Maximum number of lots allowed to be fixed automatically by ADM_FIX_WIP_EVENTS_CURR_STEP. Typically if this procedure wants to fix a large number of lots this indicates a significant problem with the load which should be addressed.

MAX_PROC_TIME_SEC

NUMBER(7)

We typically have decent logic to ignore certain cases and only take 10-50% but this is another way to eliminate bad data. We do not recommend setting this unless you investigate certain cases of throughput oddities and decide there is no other method.

MAX_QTY_IN_JOB

NUMBER(7)

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.

MAX_QTY_PER_CARR

NUMBER(7)

Maximum number of wafers in a carrier - also known as maximum lot size - which is typically 25 for a wafer fab.

MAX_RCP_CHG_SEC

NUMBER(4)

Maximum time allotted for recipe change. If standby time between lots of different recipes exceeds this time then the remainder counts as standby.

MAX_SEC_ADM_FIX_WSF

NUMBER(3)

This is the time limit for the ADM_FIX_WIP_STEP_FUTURE procedure. To avoid locking, updates to WIP_STEP_FUTURE must be made serially with inserts to WIP_EVENT_HIST therefore this procedure must be in the RealTime job. Most of the time it does nothing but after a particularly big change we might have a bunch of lots to fix. When this happens, we fix as many lots as possible in the time limit and then save the rest for the next job in order to not make the RealTime data get too far behind. The default setting is 60 seconds and if you repeatedly go over this limit then we recommend scheduling CHK_WSF_LOTS_TO_FIX more frequently.

MAX_SEC_TO_KEEP_POD

NUMBER(6)

used to determine how long will keep the pod on the tool before to switch another pod. by default, it should be 0 which means it allows to switch the pod without any restriction.

MAX_STEP_SEC

NUMBER(7)

This is a cap on the cycle time for steps in this process family. The most common use is for a process family which has historically been bad but we do not want the cycle time to show that. We hesitated on capping the historical numbers and prefer to only cap commit and target but we somewhat reluctantly agreed to cap history too.

MAX_STEP_SEC_NOHOLD_FOR_WSF

NUMBER(8)

Prevent huge cycle times at steps where a minority of lots have been waiting for an exceedingly long time

MAX_USAGE

NUMBER(9)

the max usage for change_from before it change to the new value

MAX_WAIT_SEC_FOR_TIMER

NUMBER(7)

The Scheduler will not consider a tool eligible for scheduling timer lots if the WAIT_SEC_TO_SCHED is greater than this value in seconds.

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.

MAX_WEIGHTS

NUMBER

used to determine the maximum weight for eachF evaluation

MAX_ZONE_SIZE_LOTS

NUMBER(2)

The maximum number of lots that can be scheduled to this zone in any batch.

MAX_ZONE_SIZE_UNITS

NUMBER(3)

The maximum number of units (i.e. quantity) that can be scheduled to this zone in any batch.

MEAN_AVAIL

NUMBER(5,4)

This is the mean availability for the tool over the period of time defined by num_days_for_cv_of_av in gen_site.

MEAS_RESULT

VARCHAR2(1)

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.

MERGE_INTO_PRD

VARCHAR2(64)

This is the prd of the lot into which this lot is merged if that prd is different than the prd of this lot. Typically this is an assembly step. This is important to track the prd flow from individual components into the final shipped prd.

MERGE_LOT_LIST

VARCHAR2(512)

Lot (or list of lots) merged with this lot by this merge event. A value here indicates this was a merge event.

MES_ACTION_COMMENT

VARCHAR2(256)

User can store a comment value by rule that can be sent to the MES when logging a tool down.

MES_CHAMBER

VARCHAR2(19)

If MES Chamber is populated it means that the site is using the Lookup table within FabGuard and the hopes is that this matches a MES chamber name.

MES_EVENT_NUMBER

NUMBER(3)

This optional field is used to simplify the ETL for MES such as PROMIS where the event is stored as a number.

MES_PROCESS_GROUP

VARCHAR2(36)

This is the process group from the MES used to determine tool assignments. In some MES this is absolutly like our process group but in other MES this can be overridden with other methods or systems which is why this is a separate column. This is used only in our ETL to determine tool assignments and not in any DWH logic.

MES_STEP_ENT_INST

DATE

This is the time when the step was entered according to MES. Since we calculate step_ent_inst in the DWH based on the events, we only use this to confirm that any differences in WIP_LOTS_VERIFY are not due to a lag in the data load. Not all MES will have this exact time but we expect most will have something reasonably close. The time entered the current stage or operation or step or process or recipe would all be sufficient.

MES_TOOL

VARCHAR2(16)

If MES Tool is populated it means that the site is using the Lookup table within FabGuard and the hopes is that this matches a MES tool name.

METHOD

VARCHAR2(6)

Method used to load data in table or execute procedure

MFG_GROUP_INST

DATE

Time when the mfg_group last changed.

MFG_PCT_PER_CH

NUMBER(7,4)

This optional value is the mfg_pct of the tool when this chamber is the only chamber of its ch_type that is MFG (PRD or SBY) while all chambers of all other ch_types are MFG. This column applies to sequential chamber tools which have chambers of more than one ch_type and have multiple chambers with the same ch_type. The default if this column is not set is to assume that all ch_types are bottlenecks of the tool so if 3 of 4 chambers of one type are MFG then the mfg_pct for that type is 75. If 2 of 3 then 66.7% and so on. But typically one ch_type is the bottleneck which means that if a chamber of another type is NONMFG (ENG or UDT or SDT) then the mfg_pct of tool is better than the ratio. Let us say a tool has two clean chambers C1+C2 and three deposition chambers C3+C4+C5. C1+C2 have ch_type CLEAN while C3+C4+C5 are all DEP. If both C1+C2 are NONMFG then the mfg_pct of the tool is 0% regardless of the status of the DEP chambers because it has no CLEAN chamber. Similarly if all three of C3+C4+C5 are NONMFG then it is also 0%. Of course if all chambers are MFG then it is 100%. But if at least one chamber is MFG while at least one of the CLEAN chambers and at least one of the DEP chambers is MFG then the tool can still run albeit with a degraded throughput. By default if only one of C1+C2 is MFG then the mfg_pct of the ch_type CLEAN is 50%. Similarly if one of C3+C4+C5 is MFG then the mfg_pct of DEP is 33.3% and if two then 66.7%. Technically the default calculation is 100/n where n is the number of chambers of the ch_type. But if the CLEAN chambers are the bottleneck and only one DEP chamber is NONMFG then the throughput will exceed the default of 67% and this mfg_pct_per_ch value is an estimate of this. If the mfg_pct_per_ch for DEP is 40 that means the throughput will be 40% with one DEP chamber up and 80% with two DEP chambers up. So the mfg_pct of the ch_type is p * number of MFG chambers (but no more than 100 of course) and the mfg_pct of the tool is the minimum of the mfg_pct of each ch_type. One final note is that mfg_pct_per_ch is an approximation of the contribution of each chamber for all recipes but in reality each recipe can be different. If we know the throughput for the chamber combination for the recipe then we use that instead of the mfg_pct_per_ch. For example, if C4 is NONMFG, mfg_pct_per_ch tells us the tool mfg_pct is 80% and we use that 80% number if the tool is standby or if we do not know the throughput on C1+C2+C3+C5 for the recipe running. But if we know that recipe runs at 30 UPH with all five chambers but 27 UPH with C1+C2+C3+C5 then we set the tool mfg_pct to 90%.

MINS_NO_WEH_TO_LOAD_HIST

NUMBER(2)

Normally we insert history data for the last shift/day when data_date is after the end of the last shift/day. But at sites with low activity which do not log events frequently we might want to insert the history data soon after the end even with no new events. This field is the number of minutes after the end to wait before we go ahead and write the history even if no new event has been logged.

MINS_TO_USE_ENT_AS_BEG_IF_ZERO

NUMBER(3)

If this value is set and end_proc_inst is logged less than 60 seconds after beg_proc_inst and end_proc_inst is less than this many minutes after step_ent_inst then we will use step_ent_inst as beg_proc_inst for throughput calculations. This is typically used at metrology operations.

MINS_WAIT_TO_LOAD_HIST

NUMBER(2)

This is the number of minutes into the shift/day to wait before loading data from the previous shift/day into the WIP_END_SHIFT_HIST/WIP_PLAN_DAY_HIST table. This delay is to prevent loading incomplete data for the last shift/day in case WEH events are inserted out of order. For example, if we have at event at 07:01:20 but we configure to 2 minutes then we will not insert into WESH. Instead we will wait until we have an insert after 07:02:00.

MINUTES_UNTIL_SCHED

NUMBER(7)

This value should be set only for NONMFG states and represents the number of minutes from the time when the eqp state changed until we will schedule lots to a tool in this state as long as that time is no earlier than remaining_mins_until_sched from now. The default value in EQP_L6_DETAILED_STATES can be overridden by an entry in EQP_OVR_MINS_UNTIL_SCHED for a specific eqp_type and eqp_state. If the value is EQP_L6_DETAILED_STATES is null then we will not schedule. For example, the current time is 10:00, the current state is SCH-SERVICE, state changed at 02:00, minutes_until_sched is 600, and remaining_mins_until_sched is 90. 02:00 + 600 minutes is 10:00 which is more than 90 minutes away therefore we schedule lots to this tool starting at 10:00. But once the clock passes 08:30 then the original estimate of 10:00 is less than 90 minutes away then we perpetually estimate that the tool will be up in 90 minutes. So at 08:35 we schedule starting at 10:05 then at 08:40 we schedule starting at 10:10 and so on.

MIN_BATCH_SIZE_CARRIERS

NUMBER(2)

Minimum number of carriers which should be loaded together in a batch. Scheduler will do everything possible to wait for at least this many carriers before scheduling.

MIN_BATCH_SIZE_LOTS

NUMBER(2)

The minimum number of lots required in one batch

MIN_BATCH_SIZE_UNITS

NUMBER(7)

Minimum number of units which should be loaded together in a batch. Scheduler will do everything possible to wait for at least this many units before scheduling.

MIN_BATCH_WAIT_MINS

NUMBER(5)

Minimum amount of time that a group of lots MUST wait before scheduling a group of lots below the minimum batch size. This value must be populated for the Scheduler to apply minimum batch logic. Null means Scheduler will not evaluate minimum batch constraints.

MIN_CASCADE_BATCHES

NUMBER(2)

Minimum number of batches allowed in a cascade is used for dispatching/scheduling. If a tool is below the minimum it should run a lower priority lot to maintain the cascade.

MIN_CASCADE_QTY

NUMBER(3)

Minimum number of wafers allowed in a cascade is used for dispatching/scheduling. If a tool is below the minimum it should run a lower priority lot to maintain the cascade.

MIN_CON_SKIP_ALLOW_TAG_BASE

NUMBER(5)

Min consecutive skips to hit sample percent. Calculated from 1/n value. Should not be changed or updated. This value is not actually used in the percent rule algorithm.

MIN_CON_SKIP_ALLOW_TAG_DEFAULT

NUMBER(5)

Default value to be used in percent rule calculation. Initial load defaults to MIN_CON_SKIP_ALLOW_TAG_BASE value - 20%. This value is used in the percent rule algorithm unless there is a rule override value.

MIN_CON_SKIP_ALLOW_TAG_OVR

NUMBER(5)

Minumum number of consecutive skip decisions that must occur for a PERCENT/TIME rule before the next lot that process will be tagged to measure, regardless of the sample rate. In certain cases we do not want lots that run back to back at the main process step be selected to measure at Metrology.

MIN_CON_SKIP_ALLOW_TAG_WVR

NUMBER(5)

When the consecutive skips count reaches this limit, MSO will begin to allow tagging lots if the sampling criteria is met for the defined rule and tool waiver.

MIN_DISP_SEC_RQD_FOR_COMP

NUMBER(3)

This parameter allows us to configure the minimum seconds required from DISP to COMP in order to set move_type to COMP. It is typically set only for metrology tools where pass-through moves are common. It only applies if a tool is required for COMP and events have been logged to a tool but no automatic BEGIN nor END events.

MIN_EST_PCT_OF_SUBFAM

NUMBER(2)

If at least this percentage of the total completes of a subfamily run on a tool then that counts counts as being in the subfamily for purposes of Dashboard and Goal Planner. Please note that a tool can also be in a subfamily by exceeding percentage of min_est_pct_of_tool.

MIN_EST_PCT_OF_TOOL

NUMBER(2)

If a tool runs at least this percentage of its total completes of the subfamily then that tool counts as being in the subfamily for purposes of Dashboard and Goal Planner. Please note that a tool can also be in a subfamily by exceeding percentage of min_est_pct_of_subfam.

MIN_KIT_SEC

NUMBER(7)

Minimum kit time for pod kitting

MIN_PROC_TIME_SEC

NUMBER(5)

Normally we ignore process times less than 60 seconds when calculating throughput to avoid the dreaded case when the operator logs begin and end together. However some tools actually process jobs in less than 60 seconds so we need to override this with a smaller number. If desired we could also override with a larger number.

MIN_QTY_FOR_BNS

NUMBER(6)

Minimum current WIP quantity required for a bottleneck score to be calculated. If the current WIP quantity is below this number then the bottleneck score will be set to 999.

MIN_QTY_PER_LOT

NUMBER(7)

Lots with a quantity that is greater than or equal to the value set be tagged or never tagged, depending on the condition type that is selected.

MIN_QTY_TO_USE_CTM_WEEK_HIST

NUMBER(7)

We want to avoid using records from CTM_WEEK_HIST with just a few wafers moved which would lead to huge misleading values. We normally want this value to be units in a full lot which is usually 25 for wafer fabs and larger for backend sites where the qty is in units of die. However we might set slightly larger like 26 for wafer fabs to require at least two lots including one full lot.

MIN_RQD_PER_UNIT

NUMBER(11,2)

the minimum required quantities/pct to run one unit

MIN_SEQ_DELTA_FOR_WSF

NUMBER(2)

At some facilities, the steps on the active routes jump around frequently so we can set this greater than 0 if we choose not refresh WSF for all changes. If we set to 2 then means we would only refresh WSF if seq_num changed by at least 3. Most sites should have this set to the default of 0.

MIN_SETUP_COST_FOR_RANK_S

NUMBER(4)

See comment on MIN_SETUP_SEC_FOR_RANK_S.

MIN_SETUP_SEC_FOR_RANK_S

NUMBER(4)

Sometimes we actually have zero setup penalty for certain combinations in EQP_SETUP_CHG_MANUAL and we want to ignore these when we set the rank to S which leads to the ETP state of Standby With Setup Rqd. That will happen which both min_setup_sec_for_rank_s and min_setup_cost_for_rank_s are set to the default values of 0. But we might also want to ignore setups with a tiny albeit nonzero penalty which we can do by setting one or both of these columns to a tiny value greater than zero. Our rank logic will only count the setup change if the setup_sec is more than min_setup_sec_for_rank_s or the setup_cost is more than min_setup_cost_for_rank_s.

MIN_STEP_SEC

NUMBER(7)

See MAX_STEP_SEC comment. This minimum limit should rarely be used.

MIN_STEP_SEC_TO_EOL

NUMBER(11)

Total minimum step cycle time to the end of line

MIN_WAIT_SEC

NUMBER(7)

All lots must wait at least this many seconds at the step before processing. This column is the opposite of the others and can only be populated if the others are null. Also start_step and end_step must be the same since this can only apply at a single step.

MIN_WEIGHTS

NUMBER

used to determine the minimum weight for each evaluation

MISS_CASC_INST

DATE

Time when the last cascade was missed or the current cascade will be missed.

MNT_CREATED_INST

DATE

Time when this maintenance event_id was first created in the system.

MNT_DUE_INST

DATE

Time when the next occurrence of a time-based maintenance is due or expected. See `early_inst` and `late_inst` for the window of time in which the maintenance can be performed

MNT_FACILITY

VARCHAR2(6)

Stockers and vehicles are locations but they are also maintenance entities. Location is independent of facility so the mnt_facility is not relevant as far as location. But maintenance entities needed a facility and this mnt_facility column is used exclusively for that purpose.

MNT_FAMILY

VARCHAR2(50)

MNT_FAMILY is assigned to each EQP_TYPE. Tools in the same MNT_FAMILY are similar and share the same maintenance schedule.

MNT_GROUP

VARCHAR2(36)

Grouping field for upcoming maintenance on Dashboard and Mnt Viewer. This can be any value and should be formatted for display.

MNT_INSTANCES_PER_EVENT

NUMBER(2)

The number of future instances we will show for each maintenance event. This column works together with max_days_for_mnt_instance. For example, if this is 7 and max_days is 31 then we will show daily PMs for the next week (limited by 7 instances) and weekly PMs for the next month (4 or 5 instances limited by 31 days) and only the next instance of an annual PM.

MNT_INTERVAL_SEC

NUMBER(9)

Indicates the frequency of future occurrences of this maintenance. For example, a daily PM will be listed once with due_inst set to the next occurrence and `mnt_interval_sec` set to 86400 so we know to plan for it to occur again 24, 48, 72, etc. hours after `mnt_due_inst`.

MNT_MODULE

VARCHAR2(12)

MNT_MODULE is the module responsible for maintaining the tool and is a property of MNT_FAMILY. See comments on the module column in GEN_MODULES for how it relates to eqp_module and mnt_module.

MNT_NAME

VARCHAR2(128)

Name identifying the scheduled maintenance event which is unique for the `logged_entity`. For example, daily qual or weekly PM.

MNT_TECH_USERNAME

VARCHAR2(64)

The unique identifier of a technician that also needs to exist in GEN_USERS.

MNT_WORK_AREA

VARCHAR2(50)

This field is only used for custom reporting but it gives us one more field to assign each mnt_family to a work area which is more specific that the mnt_module.

MODEL_NUMBER

VARCHAR2(50)

Model of tool provided by manufacturer. This value is only used to display in the Dashboard.

MODE_LOT_TYPE

VARCHAR2(24)

Most frequently used lot type for the ROUTE. This is used as a default lot type for starts of this PRD if the lot type is not specified in the starts plan.

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.

MODULE_ABBR

VARCHAR2(5)

Abbreviation of module. For example Implant module would be abbreviated as IMP.

MODULE_DISPLAY

VARCHAR2(20)

The name of the module displayed on all dashboards and reports. We allow a longer more descriptive name here although often this will be the same as the module.

MODULE_OR_ANY

VARCHAR2(128)

MODULE from v$session or the word ANY which signifies any MODULE.

MOVE_TO_BANK

VARCHAR2(36)

If this step moves the lot to a bank then populate this with the name of the bank. Typically this is the last step on a production route but it can be in the middle of the route as well.

MOVE_TYPE

VARCHAR2(9)

Move_type is populated with a value in WIP_MOVE_TYPES (COMP, ISKIP, etc.) for all records where is_next = Y. It is null when the qty changes but is_next = N and these "delta only" records will always have a delta_type. Note that it is possible and not unusual to have both move_type and delta_type when the lot both moves and changes qty with the same event.

MPU

NUMBER(8,4)

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.