• Subscribe

Using a framework to validate factory scheduling solution systems (Part 1/2)

A quality factory scheduling solution can improve equipment productivity, product quality, and on-time delivery of products

A semiconductor factory’s manufacturing schedule has a direct impact on critical business objectives such as equipment productivity, product quality, and delivering products to customers on time. A schedule that isn’t performing as it should, then, can be costly. Fortunately, it’s possible to validate the schedule to make sure it was created using the right data and is creating the right outcome in the factory.

Factory scheduling solution systems help semiconductor manufacturers make the best use of their equipment and personnel resources. To be effective, solutions will produce a schedule that is accurate and complete. A validation framework lets manufacturers determine the validity of the schedule by looking at both its output and the quality of the input data used to create it.

Manufacturers use factory scheduling solution systems to create a 12 to 24 hour factory schedule for lots, tools, and durables. The schedule is typically refreshed and updated in near time every 5-10 minutes to an hour, depending on the factory use case and their cycle times, product mix, and operating philosophy. When a scheduling solution is deployed in a factory, the validation framework must also be deployed to determine the validity of the schedule it generated. It’s important that the framework has the granularity to be able to drill down to the tool level and lot level from the table-level summary for deeper analysis.

Creating the Factory Schedule

A typical scheduling workflow is shown in figure 1, below. Factory data sources including the MES are accessed to generate the solution input data needed for the scheduling solution. The scheduling engine then applies logic to generate lot-to-tool assignments to fulfil the defined objectives of the local area or the factory globally. Any and every discrepancy, inaccuracy, invalidity, and infeasibility of a schedule can be traced back to the solution input data and/or the scheduling engine.

Figure 1: Typical scheduling workflow
Figure 1: Typical scheduling workflow

Evaluation and validation of the schedule entails a base level validation and validation of the input data quality and completeness, as shown in figure 2.

Figure 2: Three levels of validation of a schedule
Figure 2: Three levels of validation of a schedule

Base level validation of a factory schedule

The schedule is produced in the form of a Gantt chart. A set of specific questions is used to validate the schedule. If the user can answer ‘Yes’ to any of the following questions, then the schedule is invalid and more investigation is needed to trace the root cause and apply fixes.

Tools-related questions:

  • Are up tools not assigned any lots by the scheduler?
    • Was there any WIP qualified and available to run on those tools?
  • Are down tools assigned lots by the scheduler?
    • Are scheduled down tools assigned lots by the scheduler overlapping with the maintenance event time horizon?
    • Are unscheduled down tools assigned lots by the scheduler?
  • Are tools assigned lots for steps where they are not qualified to run?
  • Are tools assigned lots for a part that does not have that step in its route?
  • Does lot assignment consider the configuration of the tools including load ports and chambers?
Lot specific questions:
  • Are active WIP lots not assigned to any tools for their current and future steps?
  • Are inactive WIP lots assigned to any tool for their current and future steps?
  • Does the scheduler assign lots that would violate Q-time windows or show zero wait time lots waiting in queue for processing behind lower priority lots at a step?
A production schedule typically refreshes in a cadence from every five minutes to up to an hour. Therefore, the validation framework needs to have summary report and analytics (as shown in figure 2) to track the trend of the schedule validity run over run.
Figure 3: Example of a summary table analytic
Figure 2: Example of a summary table analytic

Secondary validation of factory schedule

Input data quality and completeness

When there is an incomplete or invalid schedule, validation of the extract transform load/extract transform map (ETL/ETM) layer of the solution is often the reason. For example, tools, lots, and routing steps might be missing due to the incompleteness and incorrectness of the data extraction and transformation process. Data validation reports are needed to make sure the scheduling solution was fed accurate and correct input data. The following are examples of outputs generated when input data is incomplete:

  • WIP: WIP in the factory, not in the scheduling system, are accounted for.
  • Tools: Scheduling solution input data reflects all installed and operational tools in the factory.
  • Step: number of steps without routes mapped to it or tool groups defined to run it.
  • Part number of parts: with no valid route assigned to them.
  • Part number of lots: running on routes not matching those defined in the scheduling solution input data.
  • Generic resource of steps: that claim a generic resource like probe card or reticle for usage.
  • Setup of stations: with no current setups defined.

Input Data Tracking for Factory Scheduling

Schedule adherence and accuracy is impacted by the relative accuracy of model inputs like process time. To measure the drift and delta of process time, you must be able to compare process time for a part-step-tool group combination versus statistically generated and computed process time based on historical data, as shown in figure 3. This can help the user identify entries which need correction or updating out of cycle (if they have a regular cadence to update those model inputs). There also need to be alerts in the workflow to notify the user about drifts in process time

Figure 4: Example of a table tracking process time.
Figure 3: Example of a table tracking process time.

Once these validations have been completed, manufacturers can move on to advanced validations and fine tuning of the schedule. This includes understanding the decision making that went into creating the schedule and consideration of specific KPIs. These are discussed in “Using a framework to validate factory scheduling solution systems, (Part 2/2)

A semiconductor factory’s manufacturing schedule has a direct impact on critical business objectives such as equipment productivity, product quality, and delivering products to customers on time. A schedule that isn’t performing as it should, then, can be costly. Fortunately, it’s possible to validate the schedule to make sure it was created using the right data and is creating the right outcome in the factory.

Need for a validation framework

Factory scheduling solution systems help semiconductor manufacturers make the best use of their equipment and personnel resources. To be effective, solutions will produce a schedule that is accurate and complete. A validation framework lets manufacturers determine the validity of the schedule by looking at both its output and the quality of the input data used to create it. Manufacturers use factory scheduling solution systems to create a short interval, 12–24 hour, factory schedule for lots, tools, and durables. The schedule is typically refreshed and updated in near time every 5-10 minutes to an hour, depending on the factory use case and their cycle times, product mix, and operating philosophy. When a scheduling solution is deployed in a factory, the validation framework must also be deployed to determine the validity of the schedule it generated. It’s important that the framework has the granularity to be able to drill down to the tool level and lot level from the table-level summary for deeper analysis.

Creating the Schedule

A typical scheduling workflow is shown in figure 1, below. Factory data sources including the MES are accessed to generate the solution input data needed for the scheduling solution. The scheduling engine then applies logic to generate lot-to-tool assignments to fulfil the defined objectives of the local area or the factory globally. Any and every discrepancy, inaccuracy, invalidity, and infeasibility of a schedule can be traced back to the solution input data and/or the scheduling engine.
Figure 1: Typical scheduling workflow
Figure 1: Typical scheduling workflow
Evaluation and validation of the schedule entails a base level validation and validation of the input data quality and completeness, as shown in figure 2.
Figure 2: Three levels of validation of a schedule
Figure 2: Three levels of validation of a schedule

Base level validation

The schedule is produced in the form of a Gantt chart. A set of specific questions is used to validate the schedule. If the user can answer ‘Yes’ to any of the following questions, then the schedule is invalid and more investigation is needed to trace the root cause and apply fixes.

Tools-related questions:

  • Are up tools not assigned any lots by the scheduler?
    • Was there any WIP qualified and available to run on those tools?
  • Are down tools assigned lots by the scheduler?
    • Are scheduled down tools assigned lots by the scheduler overlapping with the maintenance event time horizon?
    • Are unscheduled down tools assigned lots by the scheduler?
  • Are tools assigned lots for steps where they are not qualified to run?
  • Are tools assigned lots for a part that does not have that step in its route?
  • Does lot assignment consider the configuration of the tools including load ports and chambers?

Lot specific questions:

  • Are active WIP lots not assigned to any tools for their current and future steps?
  • Are inactive WIP lots assigned to any tool for their current and future steps?
  • Does the scheduler assign lots that would violate Q-time windows or show zero wait time lots waiting in queue for processing behind lower priority lots at a step?

A production schedule typically refreshes in a cadence from every five minutes to up to an hour. Therefore, the validation framework needs to have summary report and analytics (as shown in figure 3) to track the trend of the schedule validity run over run.

Figure 3: Example of a summary table analytic
Figure 3: Example of a summary table analytic

Secondary validation: input data quality and completeness

When there is an incomplete or invalid schedule, validation of the extract transform load/extract transform map (ETL/ETM) layer of the solution is often the reason. For example, tools, lots, and routing steps might be missing due to the incompleteness and incorrectness of the data extraction and transformation process. Data validation reports are needed to make sure the scheduling solution was fed accurate and correct input data. The following are examples of outputs generated when input data is incomplete:
  • WIP: WIP in the factory are accounted for versus WIP in the scheduling system.
  • Tools:All installed and operational tools in the factory are reflected in the scheduling solution input data
  • Step: number of steps with no routes mapped to it and no tool groups defined to run it.
  • Part: number of parts with no valid route assigned to them.
  • Part: number of lots running in the factory on routes not matching the defined routes in the scheduling solution input data.
  • Generic resource: of steps that claim a generic resource like probe card or reticle for usage.
  • Setup: of stations with no current setups defined.

Input Data Tracking

Schedule adherence and accuracy is impacted by the relative accuracy of model inputs like process time. To measure the drift and delta of process time, you must be able to compare process time for a part-step-tool group combination versus statistically generated and computed process time based on historical data, as shown in figure 4. This can help the user identify entries which need correction or updating out of cycle (if they have a regular cadence to update those model inputs). There also need to be alerts in the workflow to notify the user about drifts in process time
Figure 4: Example of a table tracking process time.
Figure 4: Example of a table tracking process time.

What’s next

Once these validations have been completed, manufacturers can move on to advanced validations and fine tuning of the schedule. This includes understanding the decision making that went into creating the schedule and consideration of specific KPIs. These are discussed in “Using a framework to validate factory scheduling solution systems, part 2/2.”

About the Author

Ravi Jaikumar, Global Product Manager, Real Time Dispatching and Scheduling
Ravi Jaikumar, Global Product Manager, Real Time Dispatching and Scheduling
Ravi is a Global Products Manager for Real Time Dispatching and Scheduling software solutions for semiconductor front end fabs and Assembly, Test and Packaging factories. Prior to joining Applied Materials Automation Products Group almost two years ago, he was a senior industrial engineer with Qorvo, Inc. He also served as an industrial engineer for ON Semiconductor and was a supply chain consultant with Hyster-Yale Group. He earned a bachelor’s degree in mechanical engineering from Anna University Chennai, and a master’s degree in industrial engineering from the North Carolina State University.