Presentation on theme: "2003 ITRS Factory Integration Factory Information & Control Systems (FICS) Backup Foils."— Presentation transcript:
1 2003 ITRS Factory Integration Factory Information & Control Systems (FICS) Backup Foils
2 Factory Information and Control System (FICS) Backup Outline ContributorsHow Metrics were SelectedProduction Equipment Performance and Factory OperationsProcess Control SystemsEngineering ChainAMHS Direct TransportSuggested University and Industry Research for 2004+
3 Contributors to this Section Ray Bunkofske (IBM)Jonathon Chang (TSMC)Gino Crispieri (ISMT)Jean-Francois Delbes (STM)Barbara Goldstein (NIST)Ton Govaarts (Philips)Arieh Greenberg (Infineon)Franklin Kalk (DuPoint Mask)Giant Kao (TSMC)Ya-Shian Li (NIST)Leon McGinnis (Georgia Tech)Shantha Mohan (Kaveri, Inc.)Eckhard Muller (M&W Zander)Richard Oechsner (Fraunhofer)Mark Pendleton (Asyst),Adrian Pyke (Middlesex)Lisa Pivin (Intel)Court Skinner (Consultant)KR Vadivazhagu (Infineon)Bob Wiggins (IBM)
4 How Metrics were selected Almost every metric is a best in class or close to best in classSources are: Rob Leachman’s published 200mm benchmarking data, Individual IC maker feedback, and I300I Factory Guidelines for 300mm tool productivityIt is likely a factory will not achieve all the metrics outlined in the roadmap concurrentlyIndividual business models will dictate which metric is more important than othersIt is likely certain metrics may be sacrificed (periodically) for attaining other metrics (Example: OEE/Utilization versus Cycle time)The Factory Integration metrics are not as tightly tied to technology nodes as in other chapters such as LithographyHowever, nodes offer convenient interception points to bring in new capability, tools, software and other operational potential solutionsInclusion of each metric is dependent on consensus agreementWe think the metrics provide a good summary of stretch goals formost companies in today’s challenging environment.
5 Production Equipment Performance & Factory Operations
6 Integrated FICS to Improve Equipment Performance GOAL: No Equipment Idle Time (“starvation”) if Material is availableImproves output (w/ priority on “super hot lot”) through more effective equipment utilizationRequires integrated equipment, scheduling/dispatching, AMHS, factory operations, and PMOHVOHV1a. Load port event signals carrier leaving OR1b. Equipment event indicates that processing is nearly finishedPM schedule checked to verify no PM is dueDispatcher selects highest priority lot for processingAMHS routes carrier to process equipmentNext lot delivered to equipment before it starvesUIUIProcessChamberaProcessEquipmentbStockerProcessingnearlycompleteSECS/GEMEquipmentControllersScheduling &Dispatching SystemEquipmentTrackingSystemAMHS ControlSystemInformation Bus
7 Predictive PM to Improve Equipment Performance GOAL: Predict future PM time to have technician/consumables ready. Intelligently determine when to run PM based on lot priority & tool/downstream impact.Improve equip perf by optimizing Preventative Maintenance (PM) timing and avoiding unscheduled or last minute scheduled down timeRequires integrated equipment, scheduling/dispatching, AMHS, and factory operations1. Equipment data indicates need for future Preventative Maintenance (PM)Scheduler determines when to PM the equipmentPM is automatically scheduled in Equipment Tracking systemPrior to PM time, Scheduler validates need (based on lot priority, tool impact, downstream impact)Technicians notified via page that specific PM is requiredEquipment finishes processing and is taken offline for PMOHVUIProcessChamberProcessEquipmentEquipment dataEquipmentControllersScheduling &Dispatching SystemEquipmentTrackingSystemPaging SystemInformation Bus
9 Continued Opportunities for APC to Improve Factory Productivity GoalMotivationSPCFDCRun to RunIMOptimize performance to Process Spec Wafer cost Die PerformancePrevent wafer/die loss & equipment damage Factory OutputReduce Wafer ReworkFaster Factory TPT (Throughput Time) New and normal product deliveryBetter Equipment Reliability Capital CostSolutions can be applied in parallelObjective is a Quantified Improvement to the Key Factory Goals
10 Future Equipment & Automation Capabilities Development in 2001 [with standards]. Qualification/Production by 2005Manufacturing Execution System (MES)OperationsDataWIPTool ControlMCSDispatchSECS/GEM Control LineIntegrated APC/Yield Data & SystemsEquipment Data Acquisition (EDA) Standards LineRunToFDCSPCEquipment &Process DataYieldPCSToday100 3 Hz each= 300 values per secFuture EDA Goal500 Hz each= 10,000 values per secAutomation System CapabilitiesData Sharable between APC applicationsHigh data transfer ratesSingle point configurationsIntegrated yield, process control, and operational systemsRapid application development (run to run algorithms, etc.)Equipment CapabilitiesStandardized data and connectivityFast sensor sampling & data transfer ratesHost ability to stop processing as neededGraceful recovery when a fault occursAbility to change parameters and values between wafersWafer tracking all points within the tool
11 APC and Process Control Capabilities are Key Enablers for Agile Manufacturing ModuleFlowAProcessStepsCDBTarget values(Recipe and major parameters)Physical Structure base controlProcess EngineeringEq.Eq. Process control info.Interpretation into what equipment can executeF/FAPCDevice structureOptimization ControlInformationCurrent center of interestDetailed Eq. Status info.Machine-to-Machine Difference and AdjustmentNPW Management and ControlChamber wet cleaning and SpecificationTime dependent performance change and compensationEq. Maint. and RulesEq. Process performance adj info.Manufacturing ExperienceResource ConsumptionManagementMore focus for agile manufacturing
12 Fault Detection and Classification Prevent scrap or equipment damage CategoryPurposeCapability DefinitionEquipment RequirementsSystemRequirementsRoadmap RequirementsFault Detection and Classifi-cation (FDC)Prevent harm to product and/or equipment due to equipment operation while out of specifi-cationMonitor equipment processing data to determine if the equipment is in specShut down or pause equipment if out of specAccept changes from the Run to Run system to avoid inadvertent pauses to productionReal-time process sensors on process toolsReporting of real-time data to host systemAlong with buffers and filters to reduce data trafficReport lot, slot, waferid, recipe step and chamber level recipe name as SVID’s.Ability to stop processing at various intervals via host commandImmediatelyAfter this stepAfter this lotAfter this waferHandle large network volumes MB / sec, no single fail pointsRedundant hardware, auto fail-over for both hardware and app’sScaleable apps and hardware, no redesign as system growsSupport ease of introduction of new applicationsModular applications with interfaces to allow data exchangeSupport download of FDC models to equipAbility to use standard commands to stop processing at various intervals% wafers processed while equipment is out of specPotential Solution:Guidelines and Standards TargetITRS Requirements include:Defect Reduction: Particle density (particles / m2) tied back to yieldOverall Equipment Efficiency – reduces MTTD (diagnose)Add process repeatabilityITRS Requirement:Equip Table Target
13 Run to Run Control Optimize performance to equipment processing specification CategoryPurposeCapability DefinitionEquipment RequirementsSystemRequirementsRoadmap RequirementsRun to Run ControlRealize the process specificationIndependent of input conditions (wafer or previous process results)Independent of some equipment conditionsAdjust process equipment process based on actual metrology resultsReporting of metrology data to host systemSupply data to determine relationship of end processing results to adjustable process parameters.Historical detailed data required from equipment sensorsAbility to adjust key recipe parameters at various intervals via host commandImmediatelyAfter this step/waferAfter this lotNeed to be able to correlate data to material (chamber level process recipe, lot, slot, wafer id) all the time from every tool – can’ t do this todayRedundant hardware, auto fail-over for both hardware and app’sScaleable apps and hardware, no redesign as system growsSupport publish / subscribe architecture to ease introduction of new applicationsStandard app interfacesCoefficient of variation of key process parametersCv = sigma/meanPotential Solution:Guidelines and Standards TargetITRS Requirement:Equip Table TargetPrimary ITRS Requirements is Coefficient of Variation for (ITRS examples):Litho – gate CD control (nm), Overlay Control (nm)Diffusion – Oxide thickness and thickness control
14 Run to Run Control Optimize performance to equipment processing specification CategoryPurposeCapability DefinitionEquipment RequirementsFICS Req’tsRun to Run ControlRealize the process specificationIndependent of input conditions (wafer or previous process results)Independent of some equipment conditionsAdjust process equipment process based on actual metrology resultsCommunicate changes to the FDC system to avoid inadvertent pauses to productionReporting of metrology data to host systemSupply data to determine relationship of end processing results to adjustable process parameters.Historical detailed data required from equipment sensorsAbility to adjust key recipe parameters at various intervals via host commandImmediatelyAfter this step/waferAfter this lotReceive dataCalculate optimal parameterPotential Solution:Guidelines and Standards TargetResearch Required:modeling – e.g. multivariate control – relation of variables by process/tool (what key parameters affect output?)ITRS Requirement:Equip Table Target
15 Integrated Metrology Reduce module level Throughput Time (TPT) CategoryPurposeCapability DefinitionEquipment RequirementsRoadmap RequirementsIntegrated MetrologyDecrease module level TPTIntegrate metrology into the process equipmentIncludes hardware and softwareHardware integration of process and metrology equipmentDon’t increase footprintInteroperabilitySoftware integration of metrology and process equipmentSingle SECS/GEM interface for integrated metrology and process equipment“Smart IntegrationNeed to match IMM with each other & stand-alone equipment (repeatability)Reliability/quality req’ts (support recalibration)Reduction of:Throughput timeTime for metrology feedback loopWafer handling and AMHS timeFloor spacePotential Solution:Guidelines and Standards TargetPrimaryFactory Cycle time [days] per mask layer (hot lot and non-hot lot)AMHS system throughput (moves / hour)SecondaryFloor space effectiveness (activities / hour / m2 or WIP turns / m2)ITRS Requirement:Equip Table Target
16 Fault Detection and Classification (1/2) Outside of ToolFDC ModelingFDC control configurationExternal sensor and tool data integration by IC MakerLevel 0 FDC Assumptions:FDC occurs outside the toolData collection through SECS interface for integrated sensorsUse Trace data collection (S6F1) or poll (S1F3/4)Data collection frequency 1-3 Hz through the SECS interfaceIC Makers integrate sensors and use proprietary interfaces where needed.Tools need graceful shutdown options at various intervals (some exist, implementations vary)Equipment parameter control & fault detection – ensure there are triggers to support immediate reactionHost SystemFDCModuleSECS Interface used for most data collection and all controlFDC DataExternal Sensor Integration OptionalFDC ControlGraceful Shutdown options requiredDetailed wafer, recipe and chamber data requiredIt is vital that the tools be able to report the chamber level process recipe, recipe step, lot number, slot number and wafer ID at the very beginning of wafer processingStep NUIIC Maker integrated External SensorProcessEquipment
17 Fault Detection and Classification (2/2) Outside of ToolHost determines actions based on type of faultHost issues control commandLevel 1 FDC Assumptions:Some FDC may occur inside the tool (IC maker’s discretion)Enables real-time control loopsIC Maker configures in-tool FDC control model and actions to be taken based on process via standard interface (if it exists)Tool determines when model is violated, controls tool, and notifies host (in tool FDC case)Historical and Summary Data collection through standard EE Interface (with high level linkage data)Tools needs graceful shutdown options at various intervalsImmediately, after this step, after this lotMay also have off tool FDC and health monitoring in parallel to on tool FDCOPEN: How does this interact with wafer to wafer control (FDC model may need to change with each wafer)Host SystemSlow FDCModuleSECS Interface used to control tool in the event of a faultFDC SignalFDC ControlInside the ToolFDC Models configuredFDC host signals configuredFDC actions may also be configuredProcessEquipmentStep NUIHistorical and Summary data storage and analysisDetailed wafer and chamber data trackedInterfaceEEEES
18 Detailed wafer and chamber data required Run to Run Control (1/3)Level 0 L2L Run to Run Assumptions:IC Maker configures control model based on processRecipe adjustment calculations made using metrology data and other data from the equipment or process.Recipe adjustment occurs outside the tool (recipe adjusted by the host and downloaded to the equipment)Parameterized recipes supported on some equipmentMetrology data collected through the SECS interfaceParameterized recipes requiredDetailed wafer and chamber level data requiredStep NMetrologyEquipmentUIUIMetrologyEquipmentUIStep N-1Models and Recipe AdjustmentStep N+1ProcessEquipmentDetailed wafer and chamber data requiredSECSEquipControllerSECSSECSEquipControllerEquipControllerFeed Forward Control - Use preprocess metrology data to adjust processing for that lotMetro data collected via SECS interfaceMetro data collected via SECS interfaceRun to Run ControlFeedback Control - Use post metrology feedback data to adjust processing for the next lotHost System
19 Run to Run Control (2/3) (Lot to Lot Case) Proposed GuidelinesLevel 1 L2L Run to Run Assumptions (non integrated metrology case)IC Maker configures control model based on processRecipe parameter value calculations made using metrology data and other data from the equipment or process (occurs in the EEC).Recipe parameter values are applied to base recipes inside the toolParameterized recipes utilized (supported on all equipment via SEMI standard)Recipe parameters are recommended to the Host by the EECRecipe parameters downloaded to the equipment via the HostStill need recipe download capability for base recipesMetrology data collected through the EE interfaceExecuted values reported from equipment to EEC (with high level linkage data)Recipe Adjustment Models and CalculationsModular apps with open interfacesRecipe RecommendationsHost SystemEESFeed Forward Control - Use preprocess metrology data to adjust processing for that lotEquipControllerEquipControllerEquipControllerDatabaseAdaptorEEDatabaseRun to Run ControlFeedback Control - Use post metrology feedback data to adjust processing for the next lotRecipe Parameter ControlFactory NetworkSECSDetailed wafer and chamber data requiredSECSEEEESECSEEMetro data collected via EE interfaceMetrologyEquipmentUIMetro data collected via EE interfaceUIMetrologyEquipmentStep NStep N+1Step N-1UIRecipe Adjustment (Parameterized recipes required)ProcessEquipment
20 Run to Run Control (3/3) (Wafer to Wafer Case) Level 2 W2W Run to Run Assumptions (IM only case)Lot to Lot capabilities are same as level 1IC Maker configures control model based on process and downloads like a recipe via some download standard.Recipe parameter value calculations made using metrology data and other data from the equipment or process (occurs in the tool).Recipe parameter values are applied to base recipes inside the toolParameterized recipes utilized (supported on all equipment via SEMI standard)Still need recipe download capability for base recipesMetrology data collected through the EE interfaceAny modification to the process parameters reported from equipment to EEC (with high level linkage data)OPEN: Should internal communication between process part and metrology part be standardized?IM means that the Metrology part is integrated with the process part of the toolBoth Hardware and SoftwareEESModular apps with open interfacesEEDatabaseIntegrated SECS and EE Interfaces for Process and MetrologyFactory NetworkEE NetworkEESECSRecipe and Model Selection and Download via SECS InterfaceHost SystemIntegrated Metro data and detailed wafer and chamber data collected via EE interfaceEquipControllerIntegrated MetrologyModule (not Bolt on)UIParameterized recipes requiredRecipe Adjustment Models, Calculations, ControlIntegratedProcess andMetro Equip.
21 Integrated Metrology (1/1) Guideline:Hardware integrated process and metrology tools shall also integrate their data collection and control systems.OKOKNGStandaloneIn-LineIntegratedOff ToolEEC SystemOff ToolEEC SystemOff ToolEEC SystemEEC NetworkDualEECLinesSingleEECLineIndividualEECLinesProcess ToolProcess ToolProcessToolMetrologyToolMetrologyToolMetrologyToolIndividualSECS/GEMLinesDualSECS/GEMLinesSingleSECS/GEMLineControl NetworkOff ToolControl SystemOff ToolControl SystemOff Tool System Control
22 Integration Time for Equipment Control Systems (Run to Run algorithms) Must Decrease Perform Experiment / Acquire “X” input dataAnalyze Results and create Process ModelRelease to Factory FloorTimeNot to scaleBuild run to run algorithm into the systemFunctional Testof run to run algorithmDesign of ExperimentAcquire “Y” output dataTotal Time (expected to decrease)Solutions to decrease:If fundamental process models exist, then use historical data to decrease time to create new algorithmWafer Level Tracking; Slot tracking, & Storage/Retrieval of all data with Wafer ID referenceIntegration of data analysis & Run to Run (APC) FrameworkIf data is available, then start with Analyzing ResultsDecrease to 4 weeksMust have enough variability in dataSolutions unknown to decrease below 4 weeksAssumptions:Run to Run algorithms are developed (not purchased)Production tool time available for performing experimentsRun to Run Framework exists. Just need to add new algorithmAble to reuse of business logic from other run to run algorithmsWafer-level data availableTool parameters can be modifiedProcess is stable
24 New Products Need Faster Customer Delivery Challenge: Customers want new products delivered much fasterKey Concept: The Engineering Chain integrates rapid, accurate, flexible data exchange from design to new chip delivery to the customer to ensure customer cycle times are metEngineering Chain = Design Reticle Integration Customer High VolumeDifferent from supply chain management which focuses on volume productionPlanning and parallel activities to deliverData TransferProcess DevelopmentProductDesignMaskFabricationPackagingand TestCustomerEvaluationWafer FabDataTransferDataTransferDataTransferThis is a Supply Chain TaskVolumeRunDesign FixDesign ImprovementNot Engineering or Supply ChainPart of Supply ChainLegend
25 Engineering Chain vs. Supply Chain Focus is on rapid new product, new process, and new proceduresSuccess indicators include:Design successesTime and cost to introduce new and changed partsPerformance repeatability in high volume manufacturingCustomer serviceabilityQuality of reticle, wafer, and final chipMaximize and manage IP useInformation flow to support Idea → Design → Mask → Fab → TestRequires engineering data exchange“APC for the entire chain”A collaborative workflowSupply ChainFocus is on efficient high volume productionSuccess indicators include:Low wafer and parts costTime and cost to make all parts for mass productionReduction in cost of inventoryFlow of raw materials to finished goodsRequires exchange of schedule and inventory data.Workflow is well understood;Low volume of data exchangedBothPhases and elements include Source, Plan, Make, and DeliverEfficiency, speed & Cost are essential
26 Critical Cycle Time and Cost Issues Data translationsData volumePrecise knowledge of design intentPrecise awareness of mask/process capabilities
27 Potential Solutions to Accelerate New Products Faster data exchange using standard data models and structures between major operationsImproved methods and capabilities to match the process to the product on timeImprove execution and process control systems, analogous to the chip fab, in Mask Shops to deliver masks with 0% excursions ( requires improved systems, richer equipment data, etc.)Supply Chain (O2D)SalesSCPMESFactoryShippingWOWIPOrderPromiseDesignCommerce DataEngineering DataEngineering Chain (T2M)e-DiagMaintenanceSupportEE DataEESAPCRecipeEqpt. ConfigurationMass ProductionProduct DevelopmentProcessDevmn’tYMSMaskEqpt.Eqpt. Supplier
28 Process engineering department Engineering Chain Potential Solutions: SEMI Reticle Data Management Task ForcePattern data areexcluded from V1.0Logic, circuit designEBconversionEB exposureMask shipmentMask order sheetInspection specificationTransportMaskAcceptance Incomming QADRCFrame generation, frame specificationDesign departmentProduction control departmentMask manufacturing departmentWafer manufacturing departmentIn-house processingFrame specificationInspection dataWafer fab.Mask fab.13254DesignProcess engineering departmentData serverGDSII data transfer serverORC OPC generationInspection RecipeDummy generationInspectionSpecification code registrationapproval, issuePattern designDummyOPCFrameStandardizationScopeOrder EntryRecipe MaintenanceDefect/Repair/ReviewclusteringSEMI-WG-CSEMI-WG-BSEMI-WG-ASource: JEITA
29 Mask Shop MetricsA key addition to the 2003 roadmap is the inclusion of Mask Shop metrics from a Factory Information and Control System perspectiveThe 2003 metrics represent a 1st revision of analysis into this area.In addition, we have included more detailed and refined mask shop metrics that are not quite ready for the 2003 publication, however, represent solid directions for 2004.Mask file sizes per litho layer are increasing exponentially. This is causing the time to process the data required to write the masks to also increase exponentially.While some of this cycle time can be reduced by advances in computing power, we believe that additional capabilities [algorithms, standardized data, etc.] are needed to keep mask cycle times and associated costs in check
30 2003 Current Mask Shop Metrics Year of Production2003200420052006200720082009201220152018Wafer Diameter300mm450mmOptical Mask Data File size per Layer (GB) from Litho14421632448672910941640N/AEUVL Mask Data File size per Layer (GB) from Litho73010962466555012490Time to send and load tape-out data into Mask Shop data system (hours)5-106-12Time for OPC calculations and data preparation for mask writer (days)4-8OPC Time only (days)2-43-6FI MetricExplanationTime to send and load tape-out data into Mask Shop data system (hours)Time in hours to send data from mask designer to mask shop and load it into the OPC application.Time for OPC calculations and data preparation for mask writer (days)Time in hours to perform OPC calculations + Time in hours to convert the output of the OPC engine to the format the mask writer understands + Time in hours to transmit the data into the mask writing systemOPC Time only (days)Time for OPC calculations only is the time in hours to perform the OPC calculations once the OPC application has received the tape-out data from the mask designer
31 2004 Proposed Mask Shop Metrics (Work in Progress – Metrics will be updated in the 2004 version to show better details)Year of Production2003200420052006200720082009201220152018Wafer Diameter300mm450mmOptical Mask Data File size per Layer (GB) from Litho14421632448672910941640N/AEUVL Mask Data File size per Layer (GB) from Litho73010962466555012490Data Transfer from Designer to OPC (hours)5-106-12OPC Time only (days)2-43-6Send OPC results to Mask Developer (hours)5-207.5-30Mask Data Prep (hours)10-1815-27Loading mask data into mask writer (hours)Key Notes:These metrics show greater detail on the mask shop cycle time components and will be updated and refined for 2004.Starting in 2005, mask processing time starts to grow exponentially with the file size and will take 250 to 511 days to process for each layer (see slide 34) unless improved computing power and new solutions are used.
32 2004 Proposed Mask Shop Metrics (Work in Progress – Metrics will be updated in the 2004 version to show better details)MetricExplanationData Transfer from Designer to OPC (hours)Time in hours to send data from mask designer to Optical Proximity Correction (OPC) application.OPC Time only (days)Time in days to perform the Optical Proximity Correction (OPC) calculations once the OPC application has received the tape-out dataSend OPC results to Mask Developer (hours)Time in hours to send data to Mask DeveloperMask Data Prep (hours)Time in hours to convert the output of the Optical Proximity Correction (OPC) engine to the format the mask writer and mask inspection equipment understandLoading mask data into mask writer (hours)Time in hours to transmit the data into the mask writing equipmentKey Notes:These metrics show greater detail on the mask shop cycle time components and will be updated and refined for 2004.Starting in 2005, mask processing time starts to grow exponentially with the file size and will take 250 to 511 days to process for each layer (see slide 34) unless improved computing power and new solutions are used.
33 Mask Operations - Cycle Time Reduction Required Data Transfer from Designer to OPC ApplicationOPC CalculationsSend OPC results to Mask Developer (at network transfer rate of 0.5 GB/hour)Mask Data PrepLoading mask data into mask writerCircuit DesignDesignrule checkerOPCOPC ApplicationMask Data Prep(prepare data formask writer)Mask WriterPotential SolutionsOPC rule checker for circuit design to ensure it is possible to decorate the mask with OPC to provide the correct lines once imagedBetter data structures (hierarchical), compaction & bigger data pipes to decrease time for data transfer from OPC to Mask Data PrepNeed improved standard for specifying the mask specifications to decrease time to load data to Mask WriterLeverage learning from operational simulation modeling in mask operations to reduce data and manufacturing cycle timesTiming for Potential SolutionsResearchDevelopment 2006Qualification/Pre-Production 2007
34 Worst Case Mask Data Preparation Mask Files and Cycle Times will Increase Exponentially unless New Solutions are Found50012,500Worst Case Mask Data PreparationCycle Time (days)LegendBest Case Cycle TimeWorst Case Cycle TimeFile SizeSolutions are needed to keep cycle times from exploding40010,0003007,500File Size in GB per mask layerTarget: Keep mask production cycle times at 2004 levels (4-9 days per mask layer)2005,0001002,500200320062009201220152018Key Notes:Starting in 2005, mask processing time starts to grow exponentially with the file size and will take from 250 to 511 days to process for each layer unless improved computing power and new solutions are used.
36 AMHS is Changing to an On-Time Delivery System Intra and InterSeparate SystemUnified System(Dispatcher Base)(Scheduler Base)TransferThroughputTransfer Time(Ave & Max)Punctuality(On-Time)Intra-BayInter-BayPushPullRe-RouteAve & MaxTimeWafer LevelTrackingCapacityPlanningOn-TimeDeliveryAMHSKey IndicatorEquipmentViewLot ViewH/W EffortsS/W EffortsReduce WIPSchedule WIP
37 Direct Tool to Tool Transport Is Needed by 2004 Many Direct Transport Concept OptionsObjectives:Reduce product processing cycle timeIncrease productivity of process toolsReduced storage requirements (# of stocker)Reduced total movement requirementsPriorities for Direct Delivery:Super Hot Lots (< 1% of WIP) & Other Hot Lots (~5% of WIP)Ensure bottleneck equipment is always busyCapability NeedsTools indicate that WIP is needed ahead of timeEvent driven dispatchingTransition to a delivery time based AMHSIntegrated factory scheduling capabilitiesTimingResearch RequiredDevelopment UnderwayQualification/Pre-ProductionS1S2T1T2S3S4T3T4S5S6T5T6S7S8T7T8Fully Connected OHVS1S2T1T2S3S4T3T4S5S6T5T6S7S8T7T8OHV with Interbay TransportPartially Connected OHVWith Conveyor Interbay
38 Integrated FICS to Support Direct Transport GOAL: Reduce priority lot (“Super Hot Lots” & Other Hot Lots) cycle time through direct tool-to-tool moves without return to stockerRequires integrated equipment, MES (to maintain lot priority), scheduling/dispatching, PM schedule, Factory Operations and AMHSOHV1a. Load port event signals carrier leaving OR1b. Equipment event indicates that processing is nearly finished for priority lotPM schedule checked to verify no PM is dueEquipment Tracking System ensures downstream tool is held availableDispatcher selects priority lot for processingAMHS routes carrier directly to process equipmentOHVUIProcessChamberaUIProcessChamberProcessEquipmentbProcessEquipmentProcessingnearlycompleteScheduling &Dispatching SystemSECS/GEMEquipmentControllersEquipmentTrackingSystemAMHS ControlSystemInformation Bus
39 Research Opportunities ITRS Factory Integation TWG2017/3/27Research OpportunitiesFITWG 2000
40 Fab Operations and Design Modeling Laboratory 300 mm discrete event simulation models currently available for download from Sematech are not accurateEvents associated with process tools are represented with reasonable fidelity, but events associated with fab planning / control systems are approximations.This simulation approach exposes the industry to significant economic risks, as design and operating decisions are based on simulation models that are known to be inaccurate.Computing, software, and communication technologies have developed to the point where a new approach to fab simulation modeling is feasible.Fab operations (process tools, AMHS, lots, operations, setups, quals, etc) can be modeled explicitly (simulated) in software that interfaces directly with “real” fab planning and control systems.The industry needs a laboratory where the technologies and development issues associated with a true 300mm “virtual fab” can be addressed in a neutral, pre-competitive setting.Employ available commercial software systems for fab planning and control.Develop and demonstrate the associated engineering tools for rapidly configuring this virtual fab (e.g. alternative fab layouts or AMHS strategies.)Concern: Most of the commercially available tools do not support today’s needs. How to we plan for the future when current tools do not support current capabilities?
41 Future ResearchData mining approach for managing Process Control & Factory Operations dataWhat are the key data items that data mining solutions must be able to extract & provide ?Modeling for Fault Detection and Run to Run ControlWhat parameters are key to control (by process / by tool type)?What input parameters impact the output & how do they relate to one another (multivariate control)?Factory workflow controlWhat business rules are needed between integration of key factory systems (MES, MCS, Scheduler, Dispatcher, Equip Tracking) to optimize processing?Operational scenarios showing equip / FICS / AMHS interactions to support Tool-to-Tool moves (Direct Transport)Include exception handlingOpportunities / improvements for Mask Operation cycle timeWhat specific improvements can be made to address the opportunities identified by ITRS?What other opportunities are available to reduce cycle time or cost of Mask Operations?