data-dictionary

FPSINPUT.RTG_PROCESSES

Data Dictionary

>

FPSINPUT Tables

> FPSINPUT.RTG_PROCESSES

Table FPSINPUT.RTG_PROCESSES"

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.

  • Schema: FPSINPUT

  • Tablespace: FPSDATA


Column

Type

Nullable

Comment

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

PROCESS

VARCHAR2(50)

Process defines what occurs at a step. Different steps can share the same process if they are identical. Process should normally determine allowed tools and recipe although it can be overridden by step, route, prd, lot, and experiment for exceptions. Each process is dynamically assigned to one or more eqp_type-process_family combinations with use_pct. One process_family is determined to be primary. If grouping is done correctly, a process should only be one eqp_group with no crossover.

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.

DEFAULT_PROCESS_FAMILY

VARCHAR2(50)

N

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

DESCRIPTION

VARCHAR2(256)

Tool desciption. This value is only used to display in the Dashboard. (* from FPSINPUT.EQP_TOOLS)

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.

GP_SUBFAMILY_SUFFIX

VARCHAR2(12)

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

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

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

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

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

IS_SAMPLE

CHAR(1)

If Y then lots are allowed to skip this process

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.

OVR_PROCESS_SUBFAMILY

VARCHAR2(100)

This column is the first of three ways to set process_subfamily. If populated this will be the process_subfamily for all route-steps using this process. The other two ways are by durable and by setup.

PREFERRED_WIP_MODULE

VARCHAR2(12)

The wip_module is the module of the primary process family. This field only applies when using OVR_PROCFAM_BY_TOOL_ASGN in EQP_TOOLS to set process_family based on tool. When this happens a process might have multiple process families and if they are in different module and this field is populated we prefer the process family with the matching module. This field will usually be blank.

PROCESS_ADDL_INFO

VARCHAR2(50)

Additional information on the process which we show on the Dashboard process summary. For example, the most common machine recipe.

PROCESS_DISPLAY

VARCHAR2(50)

N

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

PROCESS_GROUP

VARCHAR2(36)

N

Process group is the critical field where tools and processes come together for the purposes of Scheduler. Process group is in both EQP_TOOLS for the tools and in RTG_PROCESSES for processes. Ideally all tools that run the same set of processes with no crossover including back-up and emergency tools would be in the same process group but it is important to note that this is not technically required for Scheduler as long as all process groups are in the same sched group. (* from FPSINPUT.RTG_PROCESS_GROUPS)

PROC_SORT_WITHIN_FAC

NUMBER(5)

This is an overall sort order for all processes in the facility regardless of route. It is used when displaying differing routes together

SORT_ORDER_IN_DASH

NUMBER(5)

This is the sort order can be used in the Dashboard on the Top Process Summary section. User can leave it blank and the DWH will sort this based on the DEFAULT_SORT_COLUMN_ID in DASH_C_CATEGORY_TABLES for the TOP_PROCESSES table or they can configure it to display in certain order