FPSAPP.CTM_START_LOT_HIST

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)

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)

ROUTE

VARCHAR2(256)

N

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

INST

DATE

N

Time when the event occurred. (* from FPSINPUT.WIP_EVENT_HIST)

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

COMMIT_STEP_SEC_TO_EOL

NUMBER(11)

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. (* from FPSBASE.CTM_SUMMARY)

FIRST_STEP_COMP_INST

DATE

FIRST_STEP_ON_ROUTE

VARCHAR2(256)

N

HOLD_SEC_FOR_WSF_TO_EOL

NUMBER(11)

INSERTED_TIME

TIMESTAMP(6)

Timestamp field set by trigger storing SYSTIMESTAMP when record was inserted in the table. (* from FPSINPUT.WIP_EVENT_HIST)

IS_NONSTD

CHAR(1)

N

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. (* from FPSBASE.WIP_LOT_HIST)

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

LOT_GROUP

VARCHAR2(8)

N

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

LOT_SEQ_WITHIN_SEC

NUMBER(6,2)

For rows with identical timestamps, sequence records to get proper sequence (* from FPSINPUT.WIP_EVENT_HIST)

LOT_TYPE

VARCHAR2(24)

N

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

PLANPRD

VARCHAR2(64)

N

Planning product used for all planning purposes. All lots with the same planprd are interchangeable to ship to the customer regardless of their prd, route, technology, wafer size, etc. For detailed information on prd vs. planprd see table comments in RTG_PLANPRDS. (* from FPSINPUT.RTG_PLANPRDS)

PLAN_PRIORITY

VARCHAR2(7)

N

Permanent priority of the lot set in the MES generally by planning. (* from FPSINPUT.WIP_EVENT_HIST)

PRD

VARCHAR2(64)

N

Prd determines the route which is used to process the lot in the facility and what tools, recipes, durables, etc. can be used at each step. Prd also determines the next facility for the lot when it finishes its route. For detailed information on prd vs. planprd see table comments in RTG_PLANPRDS. (* from FPSINPUT.RTG_PRDS)

PROC_SEC_FULL_WAVG_TO_EOL

NUMBER(11)

PRTY_CTM_GROUP

VARCHAR2(7)

N

This is one of the primary keys of our CTM tables. We use this group rather than the priority because we often have several different priorities which are close and are expected to have the same cycle time. (* from FPSINPUT.WIP_PRIORITIES)

QTY

NUMBER(7)

N

Quantity of units in the lot according the qty_unit defined for the facility. It is required for all lots in each facility to have their qty defined in the same units therefore the change in the unit is critical to defining the facility. For example, a pretest facility might have a sort step in the middle where we learn the qty of die. Prior to this step we know only the wafer qty but after this step we know both wafer and die. Since wafer is the only qty we know throughput the flow then wafer must be defined as the qty unit for this facility. Die can then be populated as sec_qty when it is known. Similarly the wafer saw facility might have a step in the middle where we cut the wafers into die. After this step we no longer know the number of wafers which means that die must be the qty unit for this facility and wafers can be the sec_qty prior to the saw step. Please note that a lot with qty of 0 is allowed but only if the sec_qty is greater than 0. This is unusual but one case is where we know the wafers will be scrapped but cannot be scrapped quite yet. (* from FPSINPUT.WIP_EVENT_HIST)

ROUTE_FAMILY

VARCHAR2(36)

Route_family indicates that all routes within the family have similar or even identical steps and have the same segments. At facilities where various prds share the same route it is likely that the route will be the route_family. This is sometimes referred to as the main process flow. It is used on Segment Summary and Line Viewer to group similar routes. (* from FPSINPUT.RTG_ROUTE_FAMILIES)

ROUTE_GROUP

VARCHAR2(36)

Route_group is the parent of route_family. Route_group is used on the Dashboard and other applications as a large grouping for filtering. At many sites this is referred to as technology. (* from FPSINPUT.RTG_ROUTE_GROUPS)

SORT_YIELD_PCT_TO_EOL

NUMBER(6,3)

START_PLAN_DAY

DATE

N

Plan days must be 24 hours in length and the start of the plan day must be the start of one of the shifts. Contrast this to plan day which is independent of shift. (* from FPSINPUT.CAL_PLAN_DAYS)

START_SHIFT

DATE

N

Shifts can be of any length and it is important that all queries get the shift length based on start_shift and end_shift rather than assuming a set number of hours. (* from FPSINPUT.CAL_SHIFTS)

START_STEP

VARCHAR2(256)

Start step that will impact the future thread step rank in RTG_TOOL_ASSIGNMENT_LOT (* from FPSINPUT.RTG_STEP_THREADING)

STEP

VARCHAR2(256)

N

A single processing step within a route representing a single tool visit. Step is often a very complex string and should rarely be displayed. Instead we should use process_display. (* from FPSINPUT.RTG_ROUTE_STEPS)

STEP_SEC_2D_WAVG_TO_EOL

NUMBER(11)

STEP_SEC_7D_MED_TO_EOL

NUMBER(11)

STEP_SEC_7D_WAVG_TO_EOL

NUMBER(11)

STEP_SEC_FULL_WAVG_TO_EOL

NUMBER(11)

STEP_SEC_LONG_WAVG_TO_EOL

NUMBER(11)

STEP_SEC_NOHOLD_FOR_WSF_TO_EOL

NUMBER(11)

This is the expected seconds from the current step to the end of line not including time on hold. WIP_STEP_FUTURE is used for upcoming arrivals and should predict as if the lot will not go on hold unless it is known that it will. The result is that the predictions are reasonably correct for lots that do not go on hold or where we know the future hold - but very wrong for a few lots that go on hold that we do not expect. In contrast, WIP_FLUSH which is used for prediction completion of the route and all future routes will use the entire STEP_SEC including average hold. (* from FPSBASE.CTM_SUMMARY)

TARGET_CT_DAYS

NUMBER(5,1)

Number of days of cycle time targeted for the prd or bank. This target is only published internally which often means it is not even published to corporate planning. This should be less than or equal to the commit. (* from FPSINPUT.RTG_BANKS)

TARGET_STEP_SEC_TO_EOL

NUMBER(11)

TCT_SEC_TO_EOL

NUMBER(11)

UNIT_INT_SEC_TO_EOL

NUMBER(11)

The idea here is that a 1 wafer lot will progress a bit faster than a 25 wafer lot because it will save 24 wafer intervals at each step where wafers are processed individually. This column stores the number of seconds we expect to save for each wafer until the end of the line. In WIP_FLUSH we simply add or subtract this time based on whether the qty was higher or lower than the default in GEN_FACILITIES. We do not include lots which have been split in this adjustment since we expect they will be merged. For example, the CT to EOL is 30 days using our default of 20 wafers and this unit_int_sec_to_eol is 0.4 days. A lot with 19 wafers would get a revised estimate of 29.6. A lot with 18 wafers would get 29.2 and so on down to a lot with a single wafer at 22.4 days. On the other hand, our default can be less than the max so a lot with 21 wafers would get a revised estimate of 30.4 and so on up to a 25 wafer lot at 32 days. (* from FPSBASE.CTM_SUMMARY)