FPSINPUT Tables

START_PLAN_DAY

All known plan days including past, present, and future.

All known plan months including past, present, and future.

All known plan quarters including past, present, and future.

All known plan weeks including past, present, and future.

All known plan years including past, present, and future.

START_SHIFT

All known shifts including past, present, and future.

START_WORK_DAY

All known work days including past, present, and future.

All known work months including past, present, and future.

All known work quarters including past, present, and future.

START_WEEK

All known work weeks including past, present, and future.

All known work years including past, present, and future.

TOOL

Configuration of tool badges for display in NextMove.

Has information about all chambers in the facility. The columns CH, CH_TYPE, and CH_SHORT_DISPLAY are filled in by the EQP_CHAMBERS_BEF trigger and please read the detailed comment in that trigger regarding avoiding mutating errors if you are using database links for ETL.

CHG_TIMESTAMP, FACILITY, CHAMBER

Log of all changes to EQP_CHAMBERS populated by a simple history trigger. Unlike other CHGLOG tables, this one has GLOBAL scope meaning that is required for all sites regardless of how you populate the EQP_CHAMBERS table. This is because the EQP_CHAMBERS_BEF trigger uses this CHGLOG table to fill in values for critical fields if necessary. Also because of this, you may not purge this table so we constrain ovr_purge_chglog_days to 9999 in CFG_TABLES for EQP_CHAMBERS.

FACILITY, EQP_TYPE, CH_TYPE

This table has information about each chamber type for a particular equipment type. EQP_TYPE must exist in EQP_TYPES and CH_TYPE must exist in EQP_CHAMBERS with a corresponding tool of the appropriate EQP_TYPE. Populating rows in this table is optional and only needed if overriding the values defined for the EQP_TYPE.

FACILITY, TOOL

this is the current pattern supplied that has been run on the tool. assumptions/ground rules: 1) recipe sequencing is assumed to be active if a tool exists 2) the order for curr_pattern is assumed left to right, where right is the most recent process run on the tool. example: a,b,b,b,c. recipe c just ran on the tool. 3) if recipe sequencing active, a null curr_pattern is interpreted as no history exists. the scheduler will can effectively run anything as to initiate a sequence. 4) the assumption is that the curr_pattern supplied is comma delimited.

DOWN_REASON

This is an optional table that can either be empty, manually updated or populated through the ETL. The usage of this table is to any values of REASON and IS_FIRST_TIME_RIGHT_FAIL = N that the site does not want to consider something that will cause first time right to fail. The default functionality is to consider any reason code after a SDT within a gtg falling first time right. If there are some REASONS that are to be excluded populate them here with IS_FIRST_TIME_RIGHT_FAIL = N. The fundamental assumption is that after a SDT event if there are any UDT events it is likely due to the SDT event not passing or not being performed properly.

INST, FACILITY, LOGGED_ENTITY, LE_SEQ_WITHIN_SEC

When ADM_LOAD_EVENT_HIST_VIA_APD fails to insert any record into EQP_EVENT_HIST, it writes the original values from EQP_APD_EVENT_HIST into this table so that we can debug the failure. This also allows us the option to insert the record manually into EQP_EVENT_HIST later if desired. Please note that this table must have the same columns in the same order as EQP_EVENT_HIST. This table has the same PK as EQP_EVENT_HIST so that the columns will be listed in the same order in the GrimRepo snapshot used by DWH_build but the PK is permanently disabled because we never want the insert to fail.

INST, FACILITY, LOGGED_ENTITY, LE_SEQ_WITHIN_SEC

History of all events logged to tools or entities without a lot attached. Events logged to tools or entities with a lot go into WIP_EVENT_HIST.

INST, FACILITY, LOGGED_ENTITY, LOAD_SEQ_WITHIN_SEC

Temporary table to store records to be inserted into EQP_EVENT_HIST. This table is identical to EQP_EVENT_HIST except with fewer constraints since this stores the raw data before many columns are updated by the insert trigger.

This table is how we join the client states with our ETP hierarchy. Transition_state is the parent of eqp_state which comes directly from the client input data. ETP_group is the FPS ETP Level 4 group where the values are defined by FPS as an enhancement of the industry SEMI standard. From the ETP_group we get the SEMI standard E10 and availability and other information. Therefore we can determine the E10 and availability for each client eqp_state through this table.

EQP_STATE

These are the detailed states used by the client. See comments in EQP_L5_TRANSITION_STATES for more details

FACILITY, LABOR_ROLE

List of labor roles available. Although the username is logged with each transaction in the EVENT_HIST tables, currently names of actual people are not mapped to roles, just the roles are tracked for capacity modeling. So a report of labor role requirements by shift can be generated but not a report of what labor role capacity is available although this would be a fairly easy extension.

INST, FACILITY, ENTITY

This table stores the historical values of the chamber alarms being tracked by an FDC system.

INST, FACILITY, ENTITY

This table stores the historical values of the chamber health being tracked by an FDC system.

FACILITY, EVENT_ID, INST

History of all values for counter-based PMs. Used to determine the trend to predict future values over time and ultimately estimate when the PM will be due.

FACILITY, EVENT_ID

Optional list of maintenance events including but not limited PMs, quals, automated, inline or adhoc.

FACILITY, MNT_FAMILY

See comments on EQP_TOOLS for detailed information about EQP hierarchy.

List of all upcoming scheduled maintenance including PMs, quals, and automated or inline. This table might include current maintenance too and if so the actual_start_inst will be populated to indicate the maintenance is in progress. The primary key here is `facility`, `event_id` (with an additional unique key of `facility`, `logged_entity`, `mnt_name`) which means we only include the next occurrence of each maintenance. `Mnt_interval_sec` or `count_interval` indicate the frequency of future occurrences. Either the time-based columns must be populated OR the counter-based columns must be populated, but NOT both; see `EQP_MNT_FUTURE_TIME_OR_CNT_CHK` constraint for details. The `eqp_state`, `carrier_state`, or `durable_state` value represents the state that the entity in question is expected to be logged in during the maintenance; `eqp_state` is normally a substate of E10 SDT which indicates either a qual or a PM.

INST, FACILITY, ENTITY, INDICATOR_NAME

This table stores the historical values of the maintenance indicators being tracked by an FDC system.

FACILITY, MSO_EVENT

Contains the list of allowed MSO events to be used by the Metrology Sampling Optimizer UI. This will allow ETL to pre-populate the event drop down list in the UI for a user trying to create an event rule.

FACILITY, EQP_TYPE, EQP_STATE

Our default values for minutes_until_sched and remaining_mins_until_sched are configured for each eqp_state in EQP_L6_DETAILED_STATES but entries in this table override these defaults for a specific eqp_type and eqp_state. For example, the time for a qual is different for Diffusion furnaces than it is for Litho cells.

FACILITY, PATTERN_ID

this is the configuration table to define how specific recipe sequences should be applied by the scheduler. by default the scheduler will apply the sequence to the eqp_type. if tool is provided the the pattern is specific to the tool and will only be applied to the tool id provided.

FACILITY, PATTERN_ID, SORT_ORDER

this is the configuration table to define the specific recipe change sequences to be applied by the scheduler. each process change key should be supplied in the order it should appear in the pattern.

FACILITY, LOCATION

Contains all tool ports including internal. In other words, all locations where a carrier or pod could be when on a tool. Please note that tool in this table could be either a standard tool or a shared parent tool and therefore does not have a foreign key. If the port is shared among all tools which share the parent then set tool to the shared_parent_tool value.

CHG_TIMESTAMP, FACILITY, LOCATION

Log of all changes to EQP_PORTS populated by simple history trigger. You can query the state of the table at any time in the past by using t >= chg_timestamp and t < next_chg_timestamp.

PORT_MODE

List of allowed port modes for the facility and whether each is considered auto.

TOOL, CHANGE_TYPE, CHANGE_VALUE, FACILITY

This is the configuration table to store the recipes and/or setups to ignore the change. Ignore basically means that we keep the previous value as the current recipe or setup.

EQP_TYPE, TOOL, LIMIT_TYPE, LIMIT_VALUE, UNIT_TYPE, FACILITY

is the configuration table to store the usage limit for the chamber/recipe on the tool

EQP_TYPE, TOOL, ENTITY_TYPE, UNIT_TYPE, CHANGE_TYPE, CHANGE_FROM, CHANGE_TO, MAX_USAGE, FACILITY

is the configuration table to store the process max usages costs/time. it needs to be able to specify max number of consecutive change type on the tool

EQP_TYPE, RECIPE, FACILITY

is the configuration table to store the recipt - recipe_family info

EQP_TYPE, RECIPE_FAMILY, RECIPE_GROUP, FACILITY

is the configuration table to store the recipe_family - recipe_group info

REPAIR_REASON

This is an optional table that can either be empty, manually updated or populated through the ETL. The usage of this table is to any values of REASON and IS_FIRST_TIME_RIGHT_FAIL = N that the site does not want to consider something that will cause first time right to fail. The default functionality is to consider any reason code after a SDT within a gtg falling first time right. If there are some REASONS that are to be excluded populate them here with IS_FIRST_TIME_RIGHT_FAIL = N. The fundamental assumption is that after a SDT event if there are any UDT events it is likely due to the SDT event not passing or not being performed properly.

FACILITY, TOOL, ENTITY, EVENT, START_INST

This table is used to store scheduled event for all tools. usually this is used by using ETL

FACILITY, EQP_TYPE, FROM_RQD_SETUP, TO_RQD_SETUP

For users to manually input setup change times which will override calculated times.

FACILITY, ENTITY

This table has the current state of tools and entities, along with the datetime of the status change. The EQP_STATE column is unusual, because it references FPSBASE.EQP_STATE_DIAGRAM, which contains a union of the client equipment states (populated in FPSINPUT.EQP_L6_DETAILED_STATES) as well as required default states.

This table has information about each tool. Tool is unique but the primary key is actually tool+facility because we want most foreign keys pointing to this table include facility to ensure that the facility is correct. We have three EQP hierarchies: TOOL->PROCESS_GROUP->SCHED_GROUP is for Scheduler, TOOL->EQP_TYPE->MNT_FAMILY->MNT_MODULE is for Equipment Dashboard including all maintenance applications, and TOOL->PROCESS_FAMILY->PROCESS_MODULE is for Operations Dashboard. Please read the extensive comments in the EQP_REF_TOOLS_PLUS view for complete details as setting up all three of the EQP hierarchies correctly is one of the important tasks in any FPS kickoff.

FACILITY, TOOL_MSO_GROUP

List of tool groups and their assigned modules used in the Metrology Sampling Optimizer and Sampling Dashboard.

This is our most critical table for equipment configuration with over 100 important fields for batching, throughput, and scheduling. Some of these columns will be populated automatically through ETL either from the MES or another EQP/IE database. Others will be entered manually. See comments on EQP_TOOLS for detailed information about EQP hierarchy.

FACILITY, EQP_TYPE, CHANGE_TYPE

Override setups by eqp_type that should be shown in NextMove

FACILITY, EQP_TYPE, CH_TYPE_CNT_INPUT, CH_TYPE_CNT_THP

Optional table to override the default multiplier for a particular combination of ch_type_cnt for a given eqp_type.

TOOL

Optional list of target completes and WIP per tool.

FACILITY, TOOL, ZONE

Has information about all zones in the facility.

FDC_TOOL, FDC_CHAMBER

Lookup table used by any FDC system to determine tool and entity when the values fed from the FDC system do not match perfectly with values in the FPS DWH. This table is often used initially to start FPS-FDC integration until the tools and entity names are updated in the FDC system to match those in the MES and FPS DWH.

EVENT_TIME, LOT, EVENT

Stores history of FDC lot-based events. Most likely this table will be referenced by WIP_APD_EVENT_HIST to include in WIP_EVENT_HIST.

EVENT_TIME, LOT, WAFER, EVENT

Stores history of FDC wafer-based events. Most likely this table will be referenced by WIP_APD_WAFER_HIST to include in WIP_WAFER_HIST.

Table list the badge configurations for to display in NextMove.

INST, TABLE_NAME, FACILITY, LOT_OR_ENTITY, LOAD_SEQ_WITHIN_SEC

This is a temporary table used to load data into WIP_EVENT_HIST, EQP_EVENT_HIST, and WIP_WAFER_HIST in chronological order.

CUSTOMER

List of all customers. For startup, this table can just be populated with one generic customer for all planprds.

This table is where we make client-specific explanations about the translation of their data into our FPSINPUT tables.

Information about each facility plus several configuration variables.

FACILITY, BUILDING

List of buildings associated with each facility. This is an important table because the NextMove application is separate for each facility. For the facility selected, only bays, vehicles, racks, and locations in these buildings will be visible. This is a many-to-many relationship so it requires a separate table. in each site.

Information about facility shutdowns past, present, and future.

This table lists the modules of each facility. Most facilities have only a handful of modules like Litho, Etch, Diffusion, and so on. We assign two module values, PROCESS_MODULE for processes and MNT_MODULE for tools. PROCESS_MODULE is the module used to credit moves and set goals and is determined by route-step -> process -> process_family -> process_module. MNT_MODULE is the module responsible for maintaining the tools and is determined by tool -> eqp_type -> mnt_family -> mnt_module.

This table has only one row and stores information about this site as well as global information that we want to constrain appropriately.

USERNAME

Detailed information about users that can log events in various input systems. User information is optional and we will always show the username or operator that logs the event if there is no record here.

FACILITY, WAFER_SIZE

List of wafer sizes in the facility. If the facility only has one size and we do not want to divide dashboard by wafer size then we should leave this table empty and all wafer_size columns blank.

List of bays in each building.

FACILITY, FROM_BAY, TO_BAY

Estimated transit time between all bays for cassettes and durables used both for Scheduler and NextMove.

BUILDING

List of buildings in each site.

CARRIER

Current location of all carriers including empties. This includes cassettes which carry lots and pods which carry reticles.

CARR_CATEGORY

List of carrier categories valid in each facility.

LOT

This table includes delivery destination and next station for carriers that feeds the NextMove application.

EXTL_TRANSPORT_MODE

List of allowed transport modes that are used at the site. These modes are mapped to the standard FPSADMIN transport modes which are used by various applications.

This table stores all pod family assignments to each tool. This table is optional and used for scheduling pods if populated.

This table includes racks, rooms, or any location where a carrier, lot, or durable could be located which are not tools nor ports nor stockers nor vehicles. This is because tools, ports, stockers (including zero footprint storage), and vehicles (including carts and AMHS vehicles) each have their own table.

LOCATION

This table includes locations on racks. Populating this table is optional and depends on the specificity of the carrier tracking. If carrier tracking sets to location to the specific spot on each rack then we must populate this table will all of these specific locations. But if the carrier location is set only to rack then the location would be the rack and there is no reason to populate this table. When NextMove determines that a carrier should move to a rack, the destination will always be the rack and never a specific location on that rack. This is why we have curr_location and dest_station.

STAFFING_GROUP, FACILITY, BAY

The purpose of this table will be to allow NextMove to staff bays as defined in the table, meaning if we have a staffing group GROUP1 which consists of BAY1 and BAY2, NextMove will treat BAY1 and BAY2 as one bay and display lots and movements of both bays on both BAY1 and BAY2 move lists.

FACILITY, STATION, ALTERNATE_STATION

Table used to map a station to any other station which can be considered an acceptable alternative for delivery

Contains the stations assigned to each tool for staging, input, and output as well as other stations which are acceptable if the carriers happen to be there already.

List of stockers where carriers can be stored.

LOCATION

List of stocker input, output, and transfer ports.

List of all vehicles in the material handling system - including carts in a non-automated MHS. The location of a vehicle should be determined based on the location of the carrier(s) that it is transporting. For carts, this is typically the location of the last carrier that was picked up.

VEHICLE

List of all vehicles in the material handling system - including carts in a non-automated MHS. The location of a vehicle should be determined based on the location of the carrier(s) that it is transporting. For carts, this is typically the location of the last carrier that was picked up. Also tracks the user that is currently using the cart

FACILITY, VEHICLE, VEHICLE_SUB_ROUTE

This table associated vehicles (carts) to the appropriate sub-routes. See comment in MHS_VEHICLE_ROUTES table for more details.

Contains the vehicle assignments to bay or station. Either bay or station must be populated but not both.

LOCATION

This table is optional and should only be populated if we want to specify multiple locations on a vehicle, usually a cart. If this table is blank then we just consider the vehicle to be the location and the station.

VEHICLE_ROUTE

Vehicle routes and sub-routes enable routes for NextMove and will enable carriers to be scheduled to a sub routes externally and through MHS_DELIVERY_NEXT logic. These cart routes need to be created to enable routing. 1) Configure routes in MHS_VEHICLE_SUB_ROUTES through ETL, manually, up to client lead. 2) In MHS_VEHICLES carts will need to be assigned to a route. 3) Using the extl procedure or delivery next, schedule lots to sub routes. For example, CART1 can be assigned to BLUE LINE and carriers can be scheduled to any sub route like OHARE or LOOP. A carrier scheduled to OHARE can be only picked up by a cart on the BLUE LINE route and any carrier scheduled to LOOP can be picked by cart on either BLUE LINE or GREEN LINE route.

VEHICLE_ROUTE, VEHICLE_SUB_ROUTE

See comments on MHS_VEHICLE_ROUTES table.

LOT, WAFER

Current wafer slot mapping for a given lot. This helps identify where wafers are currently positioned in the carrier for a given lot.

CERT

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

FACILITY, CERT, EVENT_ID

Relates all Certifications to Event_IDs in EQP_MNT_FUTURE with the idea that one Event_ID could resolve to multiple Event_IDs or many Event_IDs could relate to multiple Certifications

FACILITY, EVENT_ID, PART_ID

The parts required for an certification/Event_id.

PART_ID

Current information on counter-based PMs based on information from EQP_MNT_FUTURE.

MNT_TECH_USERNAME

Maintenance technicians who can perform event_id they have the certifications for.

MNT_TECH_USERNAME, CERT

The Certifications that the technicians can perform.

SCHEDULE_ID

The possible schedules that a technician could work.

MNT_TECH_USERNAME, SCHEDULE_ID

This table links together all schedules that a technicians works on including both their regular/default schedule defined in FPSINPUT.MNT_TECHNICIANS and any other ad-hoc or overtime schedules.

INST, FACILITY, LOGGED_ENTITY, EVENT

History of all events logged to tools or entities related to MSO rules. Events can either be sent directly to this table or come from EQP_EVENT_HIST.

FACILITY, PROCESS_LINK_GROUP

List of all process link groups created by the ETL.

FACILITY, PROCESS_SUB_GROUP

List of all process link subs created by the ETL.

FACILITY, PROCESS_LINK_GROUP, FROM_MSO_PROCESS_NA, TO_MSO_PROCESS_NA

List of all process links that are created through the ETL and grouped by the process link group.

List of all additional MSO processes in the process sub group populated through ETL. Group can be assigned to a rule through the MSOUI.

Assignment of external MSO tag conditions for each sampling rule loaded via an external system.

FACILITY, TAG_CONDITION_NAME

Table to provide a list of Metrology Sampling Optimizer tag conditions loaded via an external system.

This table has the user defined context of the tag condition loaded via an external source. A single tag condition can have multiple conditions defined. Each row for a single tag_condition_name, one case needs to match. For a single row all the defined column values must be true for that context row to be true, where a null value means we ignore that column. When loading at least one of the context columns must be defined.

FACILITY, BANK

Information about each bank. Lots must be either on a route with a step or at a bank. If a lot goes to a bank in the middle of the route we do not count that time towards the route cycle time.

FACILITY, COMMON_STEP

For the Line Viewer and anywhere else when we want to display information on steps across multiple routes (usually by route_group or facility) we need a common_step to be defined with a sort_order to be able to group steps appropriately..

FACILITY, COMMON_START_STEP

Input table for the common step balance configurations which is similar to RTG_STEP_BALANCE but for common step rather than step. This allows to control WIP at the common start step based on how much WIP is in between the start and end common steps (Balance Window), how many wafers to allow to run at the start common step per day, and tool threading calculation at the start common step.

Detailed information about each durable. 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.

LOT, STEP, TOOL, COMBINATION_ID, DURABLE, ROUTE, FACILITY

This tables stores all durable assignments on the durable level. Users will need to configure on the lot/route/step/tool level only at this moment.

This tables stores all durable family assignments. Process is required but tool, step, route, prd, and lot are all optional. These five fields must match if they have a value but are ignored if null. For example, if tool is populated then the durable can only be used on that tool but if tool is blank then it can be used on any tool for the specified process.

FACILITY, DURABLE_CLASS

List of durable classes which are generic values like RETICLE or PROBE_CARD.

FACILITY, DURABLE_FAMILY

List of durable groups for foreign key.

FACILITY, DURABLE_GROUP

List of durable groups for foreign key.

List of FPS defined values allowed for the durable state. Restricting durable_state to a value defined in this table allows our applications to make specific references to these values.

FACILITY, LINE_SECTION

List of line sections in the facility. If the facility only has one section and we do not want to divide dashboard by section then we should leave this table empty and the LINE_SECTION column blank.

Contains the list of allowed processes to be used by the Metrology Sampling Optimizer system its UI. These processes are used to define the main process and/or metrology/skip steps in a process flow. RTG_ROUTE_STEPS has a MSO_PROCESS column that refers to the processes defined in this table, but more can be defined here for cases where a particular process is not part of defined flow. This allows the system to identify a processes for test wafer lots or other scans that can clear a main process tool. Users may want to create rules before a flow exists in FPS, keeping the MSO process list here helps facilitate that as well.

FACILITY, OPERATION

Operation is the lowest level of routing in the MES. FPS only allows one tool per step so our step is an even lower level of routing than operation. For facilities which have the same requirement, this entire table can be left blank and we will use step as the operation in RTG_ROUTE_STEPS_PLUS. But for facilities which allow processing on multiple tools within an operation, we will populate this table and use operation as a grouping of step. Note that because operation can include multiple steps and therefore multiple eqp_families we cannot have any association to equipment by operation.

FACILITY, OPERATION_FAMILY

List of all operation families. This table can be blank if the facility does not require special operation grouping or specific wip_module assignments.

FACILITY, COMMON_STEP, ROUTE_FAMILY, ROUTE_SEGMENT

This table allows the ETL to override this value which determines the sorting of common steps on the Line Viewer by route family. Our default logic to do this sort is in RTG_ROUTE_STEPS_PLUS and we hope that is sufficient and that this table can be empty.

PLANPRD

Prd and planprd have a many-to-many relationship. Multiple prds share the same planprd when those prds are interchangeable to ship to a customer despite their different processing. These prds could use different routes or even be different technologies or have different wafer sizes but if the customer does not care then they share a planprd. On the other hand, a prd can have multiple planprds when there are different varieties based on recipes or durables used at a particular time that matter to the customer.

This table lists all prds from the MES regardless of whether or not they are active. This is because we want all prds in the supply chain of an active prd to be active. So we list all prds in this table then RTG_ACTIVE_PRD_ROUTES_BASE logic determine what prds are active then RTG_ACTIVE_PRD_ROUTES logic activates all prds in the supply chain of an active prd based on RTG_PRD_FACILITY_NEXT. Only the active prds are in RTG_PRDS_PLUS which is used in most cases to get information about prds. Note this means that RTG_PRDS is an exception to our normal rule that PLUS objects have the same rows as their parent object.

PRD, CTM_SERIES

This table stores the list of CTM series for each prd which is used for selection criteria in the Finished Lot Cycle Time application. In theory this could be determined from RTG_PRD_FACILITY_NEXT but there are often exceptions and options in that table which make it difficult. We found it was easier to configure this manually using this table.

FACILITY, PRD, BANK

Stores bank(s) where lots will go after finishing main route of facility-prd. This table has two important uses. First it is used together with RTG_PRD_FACILITY_NEXT. If the facility-prd has no records here then lots go directly to the main_route of the next prd. If it has one record then it will go to that bank until started on the next prd. It is possible to have multiple records which would mean the lots would go to multiple banks in sequence but that is unusual. Second it is used in the WLRT trigger to log jumps to WIP_JUMP_HIST. When a lot moves from any step to an end bank, we jump all non-bank steps on the route which are after that step including any steps which occur after the move_to_bank on the route. Recording the jump for all following steps is necessary to calculate est_smp_pct correctly. One example is a packaging route with multiple choices for the end bank. An example route ends with the following five seq_num: process X, process A1, move to end bank B1, process A2, move to end bank B2. All lots go to process X but A1 and A2 are optional! So lots will either go to X->A1->B1 or X->B1 or X->A2->B2 or X->B2. Of course when the lot moves X->B2 we will log jumps over A1 and A2 since those steps are in between X and B2 on the route. And when the lot moves X->A2 (and then to B2) we will jump over A1. But the important logic is that when we move X->B1 or A1->B1 we actually need to log a jump over A2! Even though A1->B1 is a move between sequential steps on the route! This is so that the est_smp_pct for A2 correctly shows this lot "skipping" this step! If we did not have this logic and the split was 50-50 we would calculate est_smp_pct of 50% for A1 and 100% for A2! With this special "move to end bank" logic we correctly calculate 50% for both steps. An important corollary of this logic is that if a bank in the middle of the route is actually an intermediate bank (meaning that lots leave that bank and continue with the following steps) then it is critical to not include that bank in RTG_PRD_END_BANKS.

SOURCE_FACILITY, SOURCE_PRD, DEST_FACILITY, DEST_PRD

Mapping of product routing through multiple facilities including assembly. PK is both source and next facility/prd for two reasons. First is that multiple source prds can be used to make the next prd. This is indicated by all source prds having the same source_prd_num. Also in this case the source prds should have the same planprd. Second is that assembled prds require multiple source prds. This is indicated by each source prd having a different source_prd_num. Note you could have a combination of these two cases as well.

FACILITY, STEP, PRD

Stores information specific to PRD and STEP which for now is only yield. We only have rows in this table if the information overrides the default. Route is not in this table because we know the route for the PRD using the MAIN_ROUTE column in RTG_PRDS.

Some information about each process. Process defines what occurs at a step so different steps can share the same process -- see the comments in RTG_ROUTE_STEPS for details. Process is a primary key for throughput and for tool assignments and is displayed all over our applications so it is well worth putting some thought into how to define the process for each route-step.

this table is used to store the information for each process resource counter/target.

this table is used to store the historical run data on resource counter.

FACILITY, PROCESS_FAMILY

See comments on EQP_TOOLS for detailed information about EQP hierarchy.

Most columns in this table are configuration for the Scheduler. See comments on EQP_TOOLS for detailed information about EQP hierarchy.

Detailed information about all queue timer sequences. We have three types: multi-step timers, single step timers, and minimum wait timers.

LOT, TIMER_ID

Table allows ETL to manually populate the time when each lot started a queue sequence. If this table has any records then it will be used exclusively. If empty then we will use FPSBASE.RTG_QUEUE_TIMERS_LOT_AUTO.

List of active routes. We define a route as the full sequence of steps that a product must go through in a facility. If a facility is setup such that one product must go through multiple routes to complete processing then we will define the route as the product.

FACILITY, ROUTE_FAMILY

Information about each route_family.

FACILITY, ROUTE_GROUP

Information about each route_group.

FACILITY, ROUTE_SEGMENT

Route_segment_sort is provided to the Dashboard by route_family+route_segment in the questionably named view DASH_P_ROUTE_SEGMENTS. This table allows us to set the segment_sort for all route segments across the overall facility. If this table is empty (which is common and acceptable) then logic in RTG_REF_ROUTE_STEPS_PLUS will calculate the segment sort for each route family by ordering based on the seq_num of the various routes in the family. But if this table is populated, we will always see the segment chart sorted based on the order in this table at all levels (family, group, facility). It is critical that if you populate this table that you include all route segments on production routes. If it is populated for some segments but not all (which should not happen but could especially for new routes) then the segments with a defined sort will be first in that order followed by the undefined segments. This logic is not perfect is when the same segments are in clearly different order in different families. So in family Eugenia segment A comes before segment B but in family Audelia segment B comes before segment A. In the table, we set the segment_sort for the overall facility as best we can but we have to choose. We choose to sort like Eugenia so when we look at the Line Viewer for any family, we see A before B which meets our customer requirement that all segments are shown in the order defined in the table. But this is out of order for the Audelia family.

Contains basic information that is uniquely determined by a ROUTE-STEP combination. We define a STEP as processing on one tool. We realize that different MES define their routings differently so we will often have to do some complex transaction to get their routing model into our format -- particularly for sites where they allow processing on multiple tools like deposition then inspect at the same step. PROCESS defines what occurs at the STEP. It is possible for multiple steps to share the same PROCESS. This can happen within a route, for example, randomize. But it is most common between routes, for example, 2nd Metal Mask could be step 7000 on route A and step 7100 on route B.

FACILITY, ROUTE, STEP, EQP_TYPE

Table allows you to override the values used in calculating the line balance score/tool utilization numbers

Configuration for all sched_groups in the FPS Scheduler. We need the hours/steps_to_schedule for each sched_group in FPSINPUT to use for WIP_STEP_FUTURE. We add all other configuration columns here too since it is best to have all configuration in the same place. This table will only include groups which are being scheduled and therefore will be empty for sites not using the Scheduler at all.

FACILITY, ROUTE, SMP_STEP, LINK_STEP

Assigns each sampleable step to its relevant linked step which is typically the process step before the metrology step.

FACILITY, ROUTE, START_STEP

Input table for the step balance configurations. This allows to control WIP at the start step based on how much WIP is in between the start and end step (Balance Window), how many wafers to allow to run at the start step per day, and tool threading calculation at the start step. Configurations in this table will be used over the common step configuration table.

FACILITY, ROUTE, START_STEP, FUTURE_THREAD_STEP, THREAD_TOOL

Input table for steps and tools to be setup for Threading logic which will fix lots to tools at future steps based on what tool processed them at previous steps

LOT, PROCESS, FACILITY, TOOL, CH_PATH

List of chamber run paths for a lot-process-tool. When this table is populated for a lot-process-tool then we will use only the paths listed here. When there is no record then we use our default logic from RTG_TOOL_ASGN_LOT_PROCESS using ch_allowed and require_all_chambers to determine the list of paths. If you populate this 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.

LOT, PROCESS, FACILITY, TOOL

Override RTG_TOOL_ASSIGNMENTS for a specific lot/process. This table will be used instead of RTG_TOOL_ASSIGNMENTS_LOT when many route/step values share the same process.

LOT, STEP, ROUTE, FACILITY, TOOL, CH_PATH

List of chamber run paths for a lot-route-step-tool. When this table is populated for a lot-route-step-tool then we will use only the paths listed here. When there is no record then we use our default logic from RTG_TOOL_ASSIGNMENTS_LOT using ch_allowed and require_all_chambers to determine the list of paths. If you populate this 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.

FACILITY, ROUTE, STEP, TOOL

Override RTG_TOOL_ASSIGNMENTS for a specific lot/route/step. If step_order is populated this table will populate WIP_SMP_FUTURE with TAKE for included steps and SKIP for those not included.

Contains the tools on which each process is allowed to run along with recipe and other relevant information.

Override RTG_TOOL_ASSIGNMENTS for a specific lot/route/step. If step_order is populated this table will populate WIP_SMP_FUTURE with TAKE for included steps and SKIP for those not included.

This table is for throughput values from an automated source which is external to the FPS DWH, for example a simulation model or corporation planning system. These can override calculated times from THP_4WK_AVG and/or external times from THP_EXTERNAL depending on the always_use flag.

For users to manually input throughputs which will override calculated times from THP_EQPTYPE_AUTO and/or external times from THP_EXTERNAL.

FACILITY, LOT, BADGE_NAME

Table that contains the badges associated to each lot. More than one badge can be applied to a lot, but the badge name must be unique.

FACILITY, PRD, PERIOD_LABEL

Forecast of total cycle time by prd for upcoming weeks, months, quarters, and/or years. This is specifically to feed the Finished Lot Cycle Time application but could be used for other applications including Capacity Model and WIP Flush in the future.

FACILITY, PLANPRD, LOT_GROUP, DEMAND_INST

Committed demand by planprd. We use this to generate demand dates for each lot. See the extensive comments in the header of the WIP_FLUSH_REORDER_DEMAND procedure for details.

This table is used only to populate the EVENT_TYPE field in WIP_EVENT_HIST. It assigns an FPS event type to each MES event.

When ADM_LOAD_EVENT_HIST_VIA_APD fails to insert any record into WIP_EVENT_HIST, it writes the original values from WIP_APD_EVENT_HIST into this table so that we can debug the failure. This also allows us the option to insert the record manually into WIP_EVENT_HIST later if desired. Please note that this table must have the same columns in the same order as WIP_EVENT_HIST. This table has the same PK as WIP_EVENT_HIST so that the columns will be listed in the same order in the GrimRepo snapshot used by DWH_build but the PK is permanently disabled because we never want the insert to fail.

Probably the most important FPSINPUT table records all events for all lots. It includes lot events logged to tools like begin and end as well as lot events without tools like hold and release. A trigger on this table populates WIP_LOTS_REALTIME with the new values then the WIP_LOTS_REALTIME_UPDATE_BEF trigger has the full logic to populate most of its columns which are then written to WIP_LOT_HIST for each event and WIP_STEP_HIST for every move and change in qty.

INST, LOT, LOAD_SEQ_WITHIN_SEC

Temporary table to store records to be inserted into WIP_EVENT_HIST. This table is identical to WIP_EVENT_HIST except with fewer constraints since this stores the raw data before many columns are updated by the insert trigger.

EVENT_TYPE

Table to configure the definition of user-defined event_parm and event_inst columns in WIP_EVENT_HIST for each event_type;

FACILITY, PRD, PLANPRD, ROUTE, STEP, LOT_TYPE, PLAN_PRIORITY, IS_NONSTD

Goals for the current and upcoming shifts based on whatever logic is desired by the site. For startup, we can use our STD_WIP_REF_GOALS_PER_SHIFT view to get some reasonable goals.

LOT, STEP, ROUTE, FACILITY, EVENT_KEY

Future holds for lots including line holds and holds for the specific lot.

HOLD_GROUP

List of all possible hold groups. Having hold type and group allows for two categories of grouping.

List of all possible hold types that can be assigned to various lots on hold.

Estimated end process time for lots in process from an external source.

LOT

Everything you ever wanted to know about each lot that does not relate to the current step. All lot information regarding the current step is gathered from WIP_LOTS_STATIC_REALTIME views through events. The columns in this table will not change when a lot moves to a new step but instead will change only when they have reason to change and therefore this table will have CHGLOG to track changes.

This table has information about the current step for each lot from the MES lot table. We get current step information from the events in WIP_EVENT_HIST but we use this table to verify that our events are correct. Because this table changes frequently and should be represented by WIP_EVENT_HIST it will not have a CHGLOG table.

LOT_FAMILY

The purpose of lot family is 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

The set of possible lot groups that can be assigned to various lot families. We group WIP and moves by lot group on the dashboard so this is important

LOT, PARAMETER_NAME

Table stores MES parameters and the respective value for a lot. Multiple parameters can be stored per lot.

The set of possible lot types that can be assigned to various lots.

START_SHIFT, LOT, OPERATION, FACILITY, INST

This table allows us to override oper moves for past shifts with exact data from the client systems.

Table stores MES parameters that are tracked for lots. Serves as foreign key for WIP_LOT_PARAMETERS and provides dropdown list for the MSO UI.

This table lists the possible set of priorities that can be assigned to lots in the facility with several columns used to properly configure Dashboard, Scheduler, and NextMove for each priority. If we were starting from scratch then we might have many of these columns in WIP_PRTY_CTM_GROUPS rather than WIP_PRIORITIES because it makes little sense to have two priorities in the same prty_ctm_group with different values for hold_prty_group, is_count_priority_pct, is_nmv_priority, is_timer_wip_priority, never_stop_for_queue, proc_time_look_ahead_pct, prty_transport_mode, sched_sort, and timer_prty_xfactor. Having said that, our ETL and our Scheduler views reference these columns in WIP_PRIORITIES so we will keep them in this table. When you are populating the ETL, please keep in mind that while you are technically allowed to have different values for priorities in the same prty_ctm_group that you likely want to keep them the same.

PRTY_CTM_GROUP

The possible set of priority cycle time groups that can be assigned to different prty_ctm_groups. Separate table needed for normalization of prty_ctm_factor.

SAH_TYPE

The set of possible sendahead types that can be assigned to various lots.

LOT, STEP, ROUTE

Future sampling decisions for lots.

LOT_OR_ALT_ID

List of upcoming starts used for Scheduler, Goal Planner, and Capacity Model. This table includes all starts including both near future and distant future. We might know the exact lot and start time or we might just have a quantity to start over a certain time range - but we have various columns to cover all possibilities.

LOT, STEP, ROUTE

This table allows us to override the several fields including sched_group, wait_sec_to_sched, and priority for a specific lot-route-oper. As fits the OVR convention in the name of this table, a value of null for any field means no change. For sched_group, we have special logic that you can populate with a value of "blank!" which will clear the normal sched_group and set to null.

INST, TOOL, ACTUAL_CH_USED, EST_MACHINE_RECIPE, BEG_PROC_INST

manually store every completed lot that ran on the tool. this is used to the case when some certain lot did not exist in mes

INST, LOT, WAFER, LOT_SEQ_WITHIN_SEC

When ADM_LOAD_EVENT_HIST_VIA_APD fails to insert any record into WIP_WAFER_HIST, it writes the original values from WIP_APD_WAFER_HIST into this table so that we can debug the failure. This also allows us the option to insert the record manually into WIP_WAFER_HIST later if desired. Please note that this table must have the same columns in the same order as WIP_WAFER_HIST. This table has the same PK as WIP_WAFER_HIST so that the columns will be listed in the same order in the GrimRepo snapshot used by DWH_build but the PK is permanently disabled because we never want the insert to fail.

INST, LOT, WAFER, LOT_SEQ_WITHIN_SEC

History of wafer begins and ends, most likely on chambers but could be on main tool as well. This table essentially has two primary keys, both including inst and logged_entity. The first adds event which means we cannot log the same event for multiple wafers at the same time. The second adds lot and wafer which means we cannot log multiple events for the same wafer at the same time. The main purpose of this table is for throughput. Ultimately for non-batch tools we need to calculate the unit interval and the first unit times. The ideal way to calculate this is using (last wafer end - first wafer end) / (qty - 1) as the unit interval and (first wafer end - first wafer begin) as the first unit time. Last wafer end should be job end and first wafer time should be job begin so the key event is first wafer end. If we do not have wafer information then we approximate unit interval as job end - prev job end and first unit as (job end - job beg - unit interval * (qty - 1)) so having the real wafer times helps out throughput be more accurate.

INST, LOT, WAFER, LOAD_SEQ_WITHIN_SEC

Temporary table to store records to be inserted into WIP_WAFER_HIST. This table is identical to WIP_WAFER_HIST except with fewer constraints since this stores the raw data before many columns are updated by the insert trigger.