Processing Issue Handling - on Equipment Abort mid-process#

Overview#

This feature adds a mechanism for users to easily classify wafer status in case of an abnormal process interruption. Based on the classification, the system can automatically split and abort, track-out or hold each wafer group. A resolution protocol can be triggered to confirm the wafers status and respective disposition actions.

Business Context#

On the Semiconductor typical process scenario, the equipment starts a set of wafers, but only processes them one by one, queuing the wafers internally.

In case the equipment needs to stop/abort processing of an on-going Job, there might be a set of wafers that have already been fully processed, one (or small set) currently in-process, and the remaining ones that have not started yet.

In this situation, the MES cannot abort and reprocess the whole lot (including all wafers), because in most processes, the wafers that were already processed cannot be reprocessed. The wafers that were only partially processed, will require a deeper analysis to determine if they can be recovered, typically by re-processing with a special partial recipe, or if they need to be scrapped.

The target scenario is for equipment that process only one Material (or small set) at a time, and returns all materials back to their original container positions. This feature might not be adequate to:

• Batch equipment scenarios (e.g. Cure/Oven), as all Materials are either processed or aborted at the same time
• Equipment with different input and output locations (e.g. Die Attach; Line Equipment; etc.), as the Materials are already physically split on the equipment output.

Concept#

This feature allows the creation of a Processing Issue, which enables the possibility of classifying the processing state of each sub-material - e.g. processed, not processed, issue, etc. Depending on the classification, the system can trigger several disposition actions, typically:

• Splits the processed sub-materials and tracks them out
• Splits the mid-process sub-materials (per each different issue), aborts them and puts them on hold
• Aborts the remaining non-processed sub-materials (original lot)

After classifying each sub-material, a Protocol can be opened with a workflow to investigate the issue if a sub-material was classified as an issue or unknown state. Following the investigation the sub-material's processing state, the classification can be corrected, and trigger the disposition actions only when the protocol is resolved.

A Future Merge can be automatically set, to join all the materials back together once the pending sub-materials are re-processed.

How to Configure#

Action Plans and Classification mapping#

The first step to configure the feature is to setup the disposition action plans, and map each processing state classification to an action plan.

The Action Plans can be configured in the SemiProcessingIssueActionPlans Generic Table. Each Action Plan can contain up to 3 Actions (e.g. Abort + Rework + Hold), and define if the affected materials will be merged back automatically.

The SemiProcessingClassificationSettings Generic Table defines a Default Action Plan to be used for each classification, the Split sequence and whether a Protocol should be triggered. e.g. if a sub-material's processing state is classified as "Processed", trigger the Track-Out action plan; if classified as "Issue", open a protocol for investigation, and trigger the Abort & Hold action plan if the issue is confirmed.

The following Master Data file includes an example setup of these tables for a typical Semiconductor Front-End process scenario: ProcessIssue-ExampleClassificationsAndActionPlans.xlsx

If needed, the possible Classifications and Actions Plan Names can be configured in the SemiProcessingClassification and SemiProcessingIssueActionPlan lookup tables respectively.

Classification input and Protocol setup#

In order to collect information on the state of each sub-material, the logic relies on a Data Collection with specific parameters. The Data collection provides a user interface for users to report processing issues, and can also be filled out automatically via Equipment Integration.

The Data Collection requires a least to have a parameter SemiProcessingStatus with samples per Sub-Material or per Container Position. An additional SemiDispositionActionPlan data collection parameter can optionally be used, if the user/automation needs to be able to override the default Action Plan for each classification (configured in the SemiProcessingIssueActionPlans table previously mentioned). If needed, the parameter names used by the logic can be modified in the ProcessingStatusParamName and DispositionActionPlanParamName Config entries respectively. If use sample names based on Container positions (instead of Sub-Material names), the naming convention (e.g. "Slot ##") can be set in the ContainerPositionNamingConvention config entry. Additional informational parameters can be added freely to the data collection, if additional info is required to be collected depending on the business scenario.

It is also possible to have different Processing Issue Data Collections with different parameter setups depending on context. The Data Collection definition, and optionally Limits, Protocol and Hold Reason, can be configured in the Smart Table SemiProcessingIssueContext.

The Protocol for investigating the issue can follow any workflow and checklists as required by the business-specific process. The processing issue handling logic will automatically link it to the Data Collection Instance that triggered the protocol, and allow reviewing and correcting the sub-material state classifications. The only requirement for triggering the disposition Action Plans, is that the protocol definition needs to have a checklist item with an Action using the Rule SemiProtocolDispositionExecutionRule. The Hold Reason configured in the table is meant to set the Material on hold until the protocol actions are triggered - This Reasons must have the SemiProcessingIssueTempHoldReason attribute set to true.

The following Master Data file includes example Data Collections, Protocol and respective SemiProcessingIssueContext setup, to be able to have a full scenario running. ProcessIssue-ExampleDCAndProtocol.xlsx

How to Use#

For users to open a Processing Issue, there is a new "Process Issue" button on the Material Details, Step and Resource Views, that should be visible when a Material is In Process.

Clicking the button will open the configured data collection for the user to fill out. For example:

Upon submitting the data, if no protocol is configured to be triggered, the main Material is split per processing state classifications - if two or more sub-materials have the same Action Plan, they are split together to a new Top-Most Material. The splits are made according with the SplitSequence (defined in the SemiProcessingClassificationSettings table), and classification with the lowest Split Sequence will not be split, and will remain as the initial Main Material. After splitting, the MES will then execute the Action Plans for each new Material, and inform the user of the actions taken.

If a protocol was configured to be triggered for any of the submitted sub-material state classifications, the action plans will not be executed immediately, and a new protocol instance will be opened instead. While waiting for the protocol resolution, the Material will remain In Process in MES, and set on Hold (if configured in the SemiProcessingIssueContext table). When executing the protocol, at any stage, there is a new "Post Data" button that allows reviewing and correcting the sub-material state classifications.

Once the classifications and dispositions actions have been determined in the protocol, an Automatic Action can be triggered via a checklist on the protocol, which will launch the execution of the appropriate Action Plans.

When all the Split Materials get reached the defined Merge Point (if any), the all Materials are merged back.