data-dictionary

FPSINPUT.SCH_W_H_S_LOT_SCORE_DETAILS

Data Dictionary

>

FPSINPUT Tables

> FPSINPUT.SCH_W_H_S_LOT_SCORE_DETAILS

Table FPSINPUT.SCH_W_H_S_LOT_SCORE_DETAILS"

This table is used to store lot sched details to lot step level

  • Schema: FPSINPUT

  • Tablespace: FPSSCHEDHIST


Column

Type

Nullable

Comment

CREATE_INST

DATE

EVALUATION_ID

VARCHAR2(50)

EVL_ITEM_DETAILS

VARCHAR2(4000)

FACILITY

VARCHAR2(6)

N

Facility is included in almost every join in the DWH so this represents a definitive split. A route must have all steps on tools in the same facility. A tool must process all lots in the same facility. If your site has multiple buildings where lots run on routes using tools in multiple buildings then everything should be one facility. For example, multiple Fab buildings. But if your site has independent facilities like Fab and Test and Assembly where lot may progress from one to the next but on different routes then these should be different facilities. Since this column is in virtually every table it is critical that the value here is exactly matches what is in the MES if the MES has facility. Use facility_display for the display friendly name displayed in applications. See site_name comment for client/site/facility example. (* from FPSINPUT.GEN_FACILITIES)

LOT

VARCHAR2(32)

N

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

NUM_STEPS_AWAY

NUMBER(4)

Number of steps away not including steps which we know will be skipped nor those which we estimate will be skipped at least x pct of the time. This x value is configurable in GEN_FACILITIES using the smp_pct_for_num_steps_away column. (* from FPSBASE.WIP_STEP_FUTURE)

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

ROUTE

VARCHAR2(256)

N

Route that has threading requirements (* from FPSINPUT.RTG_STEP_THREADING)

RUN_ID

VARCHAR2(50)

N

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

SCHED_GROUP

VARCHAR2(36)

N

This is the grouping of tools and processes which the FPS Scheduler schedules together. Since this is a parent of tool via tool->process_group and a parent of process via process->process_group, by definition each tool and each process can only be in one sched group. We need all related tools and processes to be in the same sched group for efficient scheduling. One example is sinks and furnaces because of queue times and batching. Another example is for smaller facilities like Assembly or Test where we might schedule the entire facility together. (* from FPSINPUT.RTG_PROCESS_GROUPS)

SEQ_NUM

NUMBER(7,2)

Sequence number of step in route (* from FPSINPUT.RTG_ROUTE_STEPS)

SORT_ORDER

NUMBER(4)

This is used to sort within the grouping. SORT_ORDER always has a deferrable unique key to ensure uniqueness while allowing the user to make changes without erroring until the commit is attempted. Because of this you must be careful to not violate the unique key otherwise you will lose all of your edits. (* from FPSINPUT.GEN_FACILITIES)