EDA Workshop. Taiwan Gino Crispieri ISMI Member Technical Staff

Transcription

1 EDA Workshop Taiwan 2004 Gino Crispieri ISMI Member Technical Staff

2 Slide 2 EDA Workshop Agenda 13:00 Enabling the e-manufacturing Vision Thomas Chen -TSMC 13:20 EDA Standards Updates Common Equipment Model (E120) Harsha Raj Equipment Self Description (E125), Subrahmanian, Data Collection Management (E134), Rajesh Sampath - HCLT Authorization and Authentication (E132) 14:20 EDA Usage Scenarios Gino Crispieri - ISMI 14:45 FAST II Roadmap Lance Rist - ISMI 15:00 Break 15:15 XML Performance Study Gino Crispieri - ISMI 15:40 RAP Standard Lance Rist - ISMI 16:15 Challenges of EDA Implementation Mitch Sakamoto TEL 16:45 Q&A 16:55 Workshop Summary Harvey Wohlwend ISMI 17:00 Adjourn

3 Enabling the e-manufacturing Vision Thomas W.Y. Chen / 陳文耀 tsmc wychen@tsmc.com November 30, 2004

4 2004/11/22 j://stdpres/template.pot Slide 2 Agenda Key Messages Motivation for Change Interface Definitions EDA Role in Manufacturing Equipment Expectations EDA Design Requirements FAST II Roadmap Interface C Status Key Messages

5 2004/11/22 j://stdpres/template.pot Slide 3 Key ISMI Member Company Messages 1. Fully functional 300 mm standards are assumed 2. Interface A (a.k.a. EDA) is now the KEY ISMI member company focus. Interface A standardization is complete and supplier community is implementing 3. The ISMI member companies are cooperating with suppliers early to assure mutual understanding and success 4. Interface A prototypes are being evaluated at ISMI 5. Leading OEMs are deploying e-diagnostics solutions (1000s of tools) and reporting significant benefit Fabwide coverage requires Interface A and C standardization 6. ISMI member companies will require Interface A on equipment purchased starting in 2005

6 Environmental Pressures and 2004/11/22 j://stdpres/template.pot Slide 4 Some Motivations for Change Large Process Complexity Year Technology Nodes Need to Focus Few Expert Resources on Solving Issues vs. Finding Data Complex Equipment Design + Fierce Competition for Next Design Win High Cost of Mis- Processing (100 s to 1000 s of die) Time to Money for Install, Configure, & Qualification Pay for Performance High Cost of Downtime Innovation is Needed to Get the Right Data and have the Right Tools to Meet the Complex Needs of Future Technology

7 2004/11/22 j://stdpres/template.pot Slide 5 Interface Refresher SECS/GEM Still the primary equipment control I/F Interface A Equipment Engineering Data Interface First Goal: More & better data from the equipment Interface C External access to EEC (e-diagnostics) Interface B Among EEC applications and to FICS/MES EES (Equipment Engineering System) Remote monitoring Remote diagnostics Remote de-bugging/ fix Remote sensing Spare parts Mgt. Supplier Remote Location EE Access Control Interface C Global EE Data Fire Wall EE Data Collection And Storage EE Applications APC App 1 APC App 2 e-diag App 1 Interface B Factory Network OEE App 1 OEE App2 FDC App1 FICS/MES Equipment Control WIP Tracking Factory Scheduling Interface A SECS/GEM Interface

8 EDA Role in Manufacturing Diagram is Conceptual Only Suppliers, ICM, 3 Suppliers, ICM, rd 3 rd party party deliver applications deliver applications Suppliers deliver Suppliers deliver applications applications Process Control Process physics data Tool operational data Diagnostics EDA Utilization Tool internal data Process physics data Tool operational data Tool operational data EDA refers to SEMI E120, E125, E132, and E134 Includes associated implementation specs like E120.1, E125.1, E132.1, E134.1 ISMI intends to use EDA as the Primary Data Pipe for all Equipment Data Includes both Operational and Process Related Data Includes Data Accessed Internally at the Factory and External from the Factory Both Internal Factory Applications and External Supplier Applications will Leverage the EDA Interface Equipment e-diagnostic Data Available External to the Factory will come from EDA Equipment Data needed for Factory Applications will come from the EDA Interface 2004/11/22 j://stdpres/template.pot Slide 6

9 Equipment Expectations Today s Today s Throughput Throughput total scalar 3 Hz Future Future Throughput Throughput Expectations Expectations 50+ var s per up to 10 Hz Today s Today s Equipment Equipment Internals Internals E40 E87 E30 E90 E94 Job management Recipe execution Data Collection HCI Motion Control Equipment Control System EDA Interface Future Future Equipment Equipment Internals Internals E30 E90 E94 E87 E40 Job management Recipe execution HCI Motion Control Equipment Control System Dedicated High Throughput Data Bus Subsystem A Subsystem B Subsystem A Subsystem B Equipment internals behind the EDA interface must be designed to provide dedicated high-throughput data acquisition while maintaining equipment run rates For this reason, ISMI will be focusing on current and future generations of 300 mm tools for EDA implementation 2004/11/22 j://stdpres/template.pot Slide 7

10 2004/11/22 j://stdpres/template.pot Slide 8 Equipment Expectations - Internal Implementation quality is critical EDA Interface must be integrated directly Layering atop old (e.g., SECS-II) communication will not meet performance and reliability needs Data Quality must be assured Sampling-to-reporting latency reduced Time stamps accurate Formatting, units, etc. correct and consistent Time Synchronization Internal Time Synch must be <10ms (sampling rate) Equipment components must integrate well» Blackbox add-ins problematic NIST research has shown that equipment-factory synchronization can be easily accomplished The factory provides the master clock

11 2004/11/22 j://stdpres/template.pot Slide 9 ISMI EDA Design Requirements Factory App Factory App Factory App Factory App 300mm Host EDA Proprietary, HSMS, other non-eda Proprietary Server No intermediate conversion server on the equipment for EDA implementations EDA Equipment HSMS / GEM 300 Equipment No historical data storage on the equipment for EDA implementations Supplier Responsibility ICM, 3 rd Vendor, Supplier products ISMI MC s will access EDA directly from the equipment No off-tool servers required in order to collect data via EDA Equipment must be designed for EDA No on-tool historical data storage Per-tool database support overhead is not cost-effective

12 2004/11/22 j://stdpres/template.pot Slide 10 Nov FAST II Roadmap EDA Production Software Need/Plan Dates E132 Client A & A 2003 E134 Data Collection E125 Equipment Self- Description E120 CEM 1Q04 2Q04 3Q04 4Q04 1Q05 2Q05 3Q05 4Q05 1Q06 2Q Q06 4Q06 Equipment Data Acquisition (EDA or Interface A ) remains the highest priority Standards targeted completion aligns with need and implementation roadmap Majority of suppliers are trailing IDM need dates Device Makers Need Dates Suppliers Planned Dates Standard approval date Technical Spec

13 Interface C Definition ISMI Working Group defined requirements for moving data securely from the factory to the supporting organization Working Group included IC Makers, OEMs, and 3 rd party suppliers Requirements, Implementation Guidelines, and Assessment Checklist included in e-diagnostics Guidebook, section and chapters 11 and 12

14 2004/11/22 j://stdpres/template.pot Slide 12 Interface C Requirements Summary Supplier side DMZ Fab LDAP Factory side Interface C shall: Be interoperable Normalize interface from different IC Makers to different suppliers Protect equipment supplier and IC Maker data Data Separation and Security between Equipment Suppliers and between the IC Maker and Equipment Supplier Guarantee data delivery Meet performance expectations Be secure VPN, SSL, etc. Comply with the Measurement & Assessment checklist Enable remote equipment operation e-diagnostics Server Support data other than that directly produced by the equipment VPN or Internet HTTPS/443/ Web Services Hardened Servers SSL Full Proxy HTTPS/443/ Web Services UDDI Other legacy protocols Tools (Interface A) Applications Factory information to enrich data Servers

15 2004/11/22 j://stdpres/template.pot Slide 13 Key ISMI Member Company Messages 1. Fully functional 300 mm standards are assumed 2. Interface A (a.k.a. EDA) is now the KEY ISMI member company focus. Interface A standardization is complete and supplier community is implementing 3. The ISMI member companies are cooperating with suppliers early to assure mutual understanding and success 4. Interface A prototypes are being evaluated at ISMI 5. Leading OEMs are deploying e-diagnostics solutions (1000s of tools) and reporting significant benefit Fabwide coverage requires Interface A and C standardization 6. ISMI member companies will require Interface A on equipment purchased starting in 2005

16 AEC/APC Symposium, Taiwan Interface A Interface A Presented by Harsha Raj S. e-manufacturing Initiatives HCL Technologies 1

17 Presentation Topics Speaker Introduction Interface A - Goals Interface A Factory Perspective Interface A Standards E120 E125 E134 E132 EDA - enabler for APC EDA - enabler for utilization Steps to achieve Interface A compliance Q & A 2

18 Speaker Introduction Speaker Harsha Raj Subrahmanian Senior Manager, Software projects HCL Technologies - Semiconductor practice emanufacturing Initiatives Co-speaker Rajesh Sampath Project Manager, Software projects HCL Technologies - Semiconductor practice EDA Framework Development 3

19 Interface A (EDA) Goals Key Enabler for realizing emanufacturing Standardized web services interface to equipment data Obtain equipment self-description at run-time Visibility into equipment sub-systems and operational data Security: Only factory authorized applications and personnel can access or collect data 4

20 Interface A (EDA) Goals (contd ) Data Quality: Provide high throughput, quality data at 5,000-10,000 fps Platform independence irrespective of equipment internals Multiple clients simultaneous data access by factory applications Host independence - Allow direct data access to EEC applications, while retaining host control via SECS/GEM Create a gradual path to modernize software technology in fab 5

21 HCL EDA Solution- Factory Perspective MES / FCS Applications Interface B Interface C APC, FDC, EPT, e-diagnostics.. EEC Applications 300MM Automation Framework Host System (SECS/GEM) Messages EDA Client(s) Interface-A Framework Control Interface Data Interface SECS Port EDA Port HSMS over TCP/IP Configure Port SECS or EDA HCL Unified Factory Automation Framework SOAP/XML over HTTP 6

22 Interface A - Standards E120: Common Equipment Model Model to describe Equipment Structure Equipment Supplier to design/represent equipment structure in-line with specified CEM E125: Equipment Self Description Equipment Capabilities published to Factory Clients Associates Equipment Model of E120 with specific data E134: Data Collection Management Automated Process and Operational Data Collection method from the equipment to clients (ediagnostics, APC, SPC) Fulcrum of Interface A and is being supported by E125 and E132 E132: Equipment Client Authentication and Authorization Secure communication between EDA Clients and Equipments Granular Access Control 7

23 HCL EDA Solution Interface A Standards Data Collection Report Event Reports Trace Report Exceptions Report Events Trace Data Exceptions Buffering EDA Client 1 (e-diagnostics System) Data Collection Management Services (E134) Tool software Data Collection Plan Engineers EDA Client 2 (FDC System) Browser UI EDA Client-side DCP Client Notification Services (E134) Equipment Client Authentication and Authorization (E132) Equipment-side Tool Integration Layer Tool data store RDF Integration Layer DCP Equipment Data Acquisition System 1. Pre-defined Supplier DCP s 2. Dynamically defined Factory DCP s Factory Applications Equipment Self Description Services (E125) Equipment Authenticate, Discover, Define, Activate 8

24 E120 Features E120: Common Equipment Model Equipment Suppliers describe physical structure of their equipments using common terminology Model provides Hierarchical representation describing relationship between various components Features of E120 Ability to describe linked, multi-chamber equipments Hierarchical model allows nesting of components Ability to describe modules, sub systems, I/O devices etc. Forms the basis for E125 Metadata representation 9

25 E125 Features E125: Equipment Self Description Equipment publishes its capabilities (called Equipment Metadata) to the factory Maps CEM of E120 with equipment data (events, alarms, parameters) Accurate Information for designing Data Collection Plans Features of E125 Mapping of E120 CEM with equipment data (events, alarms, parameters). Ability to represent Equipment State Machines. Ability to represent 300mm objects (like Process Job, Control Job, Carrier etc) supported by the Equipment Metadata Notifications EDA Clients can subscribe with Equipment for notifications about changes to Equipment metadata Changes to the Equipment s Metadata can be notified to interested EDA Clients 10

26 E125 Benefits Benefits to Equipment Suppliers Ability to publish equipment capabilities to factory Ensures consistency between Equipment s capabilities and DCPs defined by Clients. Changes in Equipment metadata due to Equipment Upgrades can be communicated to Factory Clients Benefits to IC Makers Can query equipment s capabilities at runtime. Metadata obtained from Equipment forms as the inputs for designing DCPs. 11

27 E125 Example Use case Browser UI Using GUI or Factory side APIs GetEquipmentNodeAssociation Request (E125) GetExceptions Request (E125) DefinePlan Request (E134) Equipment returns its E120 CEM model along with events, alarms and parameters supported by each CEM node Equipment returns the various exceptions supported DCPs can be defined based on the information provided by the Equipment 12

28 E125 Sample User Interface Equipment Metadata Hierarchy displayed as an XML to show the equipment s structure 13

29 E125 Sample User Interface Equipment Metadata obtained using E125 being used to create DCPs 14

30 E134 Features E134: Data Collection Management Automated Process and Operational Data Collection method from the equipment to clients (ediagnostics, APC, SPC) Fulcrum of Interface A and is being supported by E125 and E132 Data Collection Model of E134 Define and Activate DCPs This neat separation of definition and activation ensures that DCPs can be activated/deactivated in a burst mode based on specific requirements of Interface A clients Same DCP can be activated by multiple Interface A Clients Push style Data Collection Persistent DCPs Once activated, will remain active across multiple shut downs of the Equipment On-demand data collection Latest revision of E134 provides APIs using which Interface A clients can request data from the Equipment at runtime without having to explicitly define DCPs DCPs can be defined with the help of Equipment metadata obtained from E125 APIs Security enforced by E132 15

31 E134 Features Data Collection Plan Event Reports Give info on State changes on the Equipment Helpful for tracking Execution Context of the Equipment Exception Reports Monitor error conditions on the Equipment Trace Reports Periodic data collection for real-time monitoring of Equipment Parametric Data Analysis On-tool Buffering Support for Built-in (Supplier-Generated) DCPs E134 Technical Specification SOAP/XML based specification ensures Platform-Independence Many-to-many connectivity unlike point-to-point SECS/GEM High throughput capabilities Support for varied types of data (including images) 16

32 E134 Benefits Benefits to Equipment Suppliers Reduced load on equipments as all data need not be collected always Enabler for e-diagnostics, thereby reducing equipment downtime Performance Warnings features ensure that Interface A does not interfere with Tool Performance Equipment data can be shared with multiple Interface A Clients simultaneously Benefits to IC Makers Unified interface for data collection Ability to collect data from multiple tools simultaneously Platform-independence and Interoperability High-Throughput data (Of the order of 5,000 to 10,000 values per second) 17

33 E134 Example Use case Browser UI Using GUI or Factory side APIs DefinePlan Request ActivatePlan Request Equipment Level Security provides privilege checks for APIs On-demand Activation Client apps get data through Factory-side API Data Collection Report NewData Message Equipment sends data collected as per activated DCP(s) 18

34 E134 Sample User Interface 19

35 E132 Features E132: Equipment Client Authentication and Authorization Secure Communication between EDA Clients and Equipment Granular Access Control capabilities Security Features of E132 Clients Authenticate with Equipment before performing EDA activities Successful Authentication results in a unique Session established between Equipment and the concerned EDA client, which will be used for subsequent privilege checks. SecurityAdmin is a special EDA Client capable of performing Administrative tasks. Privileges can be assigned to individual EDA Clients by SecurityAdmin Session Ping capabilities to ensure the Session is alive both on the Equipment and the EDA Client Persistent Sessions Ability to persist a session, once it is established across multiple equipment re-starts. Ability to set the maximum number of sessions for non-admin clients. Usage of SSL for secure communication between Equipment and EDA Clients. 20

36 E132 Key Interfaces SessionManager Interface Clients use this interface to establish a session with the Equipment Provides methods to establish, persist or close a session SecurityAdmin Interface Can be used only by the Security Admin client Provides methods to Assign and remove privileges to Clients. Set the maximum number of non-admin sessions 21

37 E132 Benefits Guarantees secure access to information provided by the Equipment Specification covers industry standard security protocol. Both E125 and E134 are to be accessed only after establishing a session using E132. This ensures secure access to metadata as well as Data Collection Plans. Granular privilege assignment ensures better control of security. Security Admin Interface to perform privilege management to various clients. 22

38 E132 Example Use case Browser UI Using GUI or Factory side APIs EstablishSession Request Equipment Response with Session ID Any E125 Request Any E134 Request Equipment performs security checks and authenticates Equipment verifies Session ID Equipment verifies Session ID and performs appropriate privilege checks for each API 23

39 EDA Solutions Features to look for Portability & Interoperability Generic SOAP implementation to support multiple OS Equipment and Factory Interoperability Rapid Development Framework Needs minimal coding on the equipment side and Simple Facilitates Rapid Integration with Equipments and Interface A Clients (e-diagnostics, SPC, APC, EPT) Tool Interface development wizard Support for multiple client applications simultaneously Performance Equipment-side solutions should support high data throughput (of the order of 10K values per second) EDA Client-side solutions should scale to accept high volume data from multiple equipments 24

40 EDA Solutions Features to look for Additional capabilities Ability to maintain metadata of more than one equipment in the same tool database and associate with the current equipment at runtime. Ability to change the metadata at runtime and validate DCP's based on the current metadata. Reusable Utility to validate DCPs at runtime. Maintenance of active / inactive nature of Interface A Client s state Metadata level security 25

41 HCL EDA Solutions APC Factory clients FDC R2R SPC APC Application Set EDA Server1 EDA Server1 EDA Server3 EDA Servers EDA Interface EDA Enabled Equipment Equipment 26

42 HCL EDA Solutions Utilization Factory clients EPT E10 ediag Utilization Application Set EDA Server1 EDA Server1 EDA Server3 EDA Servers EDA Interface EDA Enabled Equipment Equipment 27

43 Steps for achieving Interface A Equipment Compliance For Equipment Suppliers Arrive at a CEM representation of the Equipment valuable to factory/fab Derive the Equipment Self Description Metadata from the CEM Arrive at data set to be supported Can include Process, Product, Automation data Identify primary or target factory applications to validate data set selected. Choose/develop appropriate Interface A Implementation based on Readiness Compliance Performance Ease of Integration Support Integrate Interface A Implementation with Equipment Software Optionally, re-engineer the Equipment Software to meet the needs of data delivery through Interface A. Carry out application oriented tests as well as generic Interface A compliance Pilot and qualify equipment with specific IC Makers. 28

44 Steps for achieving Interface A Factory Compliance For IC Makers Choose/develop Interface A Implementation based on Factory Application Readiness Compliance to standard Performance as per stated goals of Interface A Support and Services to roll out applications. Identify high benefit target applications, including application data requirements. Facilitate equipment providers to become Interface A compliant, providing required data for selected applications. Develop or deploy selected applications in pilot environment to validate the system. Carry out systematic roll out of applications and equipment capabilities across factory(s). Add new applications on the system to expand the benefits. 29

45 Value Proposition to IC Makers and Suppliers Interface A provides a common and modern web services based interface to all equipment types in semiconductor manufacturing. Interface A provides an operating system and network neutral way to interoperate complex equipment and factory applications, and can benefit equipment or applications running on Windows, Unix (or mainframes ). Interface A is accepted by SEMI and International Sematech, and approved in March 04. As a step in right direction, Interface A is identified by combined body of equipment providers and IC makers to hold highest priority for immediate future. ( refer FAST II roadmap ) Interface A opens the way for introduction of modern software technology, and moving forward from the SECS model of communication starting with low-risk high-value data acquisition, while retaining equipment control. Interface A provides both application and equipment providers to develop systems and applications independently to service the overall e-manufacturing goals. 30

46 Q & A For more Information on HCL Solution Offerings, please visit: HCL-eManufacturing or send to harsha@ctd.hcltech.com Thank You Acknowledgement: SEMATECH e-diagnostics, EDA, related standards and articles Product names and company names used in this presentation are for identification purposes only and may be trademarks or service marks of their respective companies 31

47 Interface A Usage Scenarios Gino Crispieri Member Technical Staff ISMI gino.crispieri@ismi.sematech.org SEMATECH, the SEMATECH logo, AMRC, Advanced Materials Research Center, ATDF, the ATDF logo, Advanced Technology Development Facility, ISMI and International SEMATECH Manufacturing Initiative are servicemarks of SEMATECH, Inc. All other servicemarks and trademarks are the property of their respective owners.

48 11/22/2004 EDA Scenarios Slide 2 Purpose and Output Purpose: Usage scenarios represent the ISMI Member Company consensus of production factory use models. They establish expected behavior sequences providing guidance for suppliers during implementation of the functions and requirements in EDA standards. Usage Scenarios also bound the space of interest for conformance and validation testing

49 11/22/2004 EDA Scenarios Slide 3 Scenario Development Approach Interface management, client and equipment level communication Three level communication description used Concept Representation Simple description using arrows between client and equipment Message Transaction Description of the actual messages, service call, input/output attributes and sequences for Level 0 concept representation Message and Command Breakdown (Not Included) Content Messages with specific content Functional sequences and unit scenarios per standard General usage scenarios Exception scenarios (next publication phase)

50 11/22/2004 EDA Scenarios Slide 4 Classification of Usage Scenarios Document Classification Fundamental Sequences Small reusable functional cases that represent functions each standard defines Have an Exxx-SEQ-XX identifier number A given Exxx-SEQ-XX is given a.x number for different combinations of message content Unit Scenarios Composed of a combination of fundamental sequences from single standard Have an Exxx-SCN-XX identifier number Integrated Scenarios Composed of a combination of fundamental sequences from multiple standards Have an SCN-XX identifier number only since uses elements from multiple standards

51 11/22/2004 EDA Scenarios Slide 5 EDA Base Component Overview Authentication Security Admin Setup Session Management Metadata Management DCP Management DCP Activation Data Reporting Application Certificates GetACL Get Active Sessions Metadata Revised Define DCP Activate DCP Event Report Equipment Certificates Add ACLEntry Set Max Session Query Metadata Query Active DCP Deactivate DCP Exception Report Establish Session - SSL Delete ACLEntry Close Session Notification Setup Query a DCP Content Trace Report Establish Session no SSL Get Defined Privilege Persist Session Delete DCP Ping Session Normal Use

52 11/22/2004 EDA Scenarios Slide 6 EDA Base Component Overview Authentication Security Admin Setup Session Management Metadata Management DCP Management DCP Activation Data Reporting Authenticate Fail Unauthorized Request Unauthorized Request Invalid Session / No Session Unauthorized Request Unauthorized Request Report Format Error Session Establishment Fail Invalid Session / No Session Invalid Session / No Session Nonexistent Equipment Node Invalid Session / No Session Invalid Session / No Session Report Contents Error Add Duplicate Entry Defined DCP inconsistent W/ Metadata Activate Error Performance Down Invalid Role/ Privilege Provided Delete Nonexistent Plan Activate Invalid/ Nonexistent Plan Delete Nonexistent Entry Delete Active Plan Activate An Already Active Plan Exception Cases

53 11/22/2004 EDA Scenarios Slide 7 Fundamental Sequences and Unit Scenarios Authentication and Authorization Standard (E132) Credential Set Up for Equipment and Applications Admin or Client Authentication with and without SSL ACL Entry Management Services Administrative Session Management Services Session Operation Services Equipment Notification Services Equipment Self Description Standard (E125) Metadata Query Services Metadata Management Services Data Collection Management Standard (E134) DCP Management Services DCP Query Services DCP Performance Warning Services

54 11/22/2004 EDA Scenarios Slide 8 Admin or Client Authentication Session Start Establish Session Close Session Admin or Client Authentication Client Equipment EstablishSession() ACK EstablishSession() CloseSession()

55 11/22/2004 EDA Scenarios Slide 9 E132-SEQ-01 Establish Session Request Service sd E132-SEQ-01 ACL Establish Session «interface» :Application «interface» :Equipment EstablishSessionRequest(endPoint) EstablishSessionResponse(sessionID) This service is used by both Admin and non-admin Clients to connect with the equipment Normal Case E132-SEQ-01.1 Application has a valid certificate and ACL entry (SSL enabled) E132-SEQ-01.2 Application has an ACL entry (SSL disabled) special case where the equipment skips or ignores the low level Authentication Authorization still applies (ACL Entry is required!) Exception Cases E132-SEQ-01.3 Application does not have a certificate at all (w SSL enabled) E132-SEQ-01.4 Application with a certificate that is not trusted E132-SEQ-01.5 No ACL entry Scenario E132-SCN-01 SSL Configuration Change Scenario

56 11/22/2004 EDA Scenarios Slide 10 E132-SEQ-01.1 Admin or Client Authentication Detail (SSL Enabled) sd E132-SEQ-01.1 Authorization & Authentication «interface» :Application «interface» :Equipment Client ID Session Secret Client ID Proof Client Authorized Session Request(EndPoint) Equipment Challenge Client Authenticates Equipment Authorizes(SessionID) Algorithm EquipmentID Challenge Equipment Verifies ACL entry for client The Client will be granted access to a session automatically if A subject in the ACL matches the ID in the FROM field from the request or A subject in the ACL is equal to anyprincipal that has assigned privileges

57 11/22/2004 EDA Scenarios Slide 11 E132-SCN-05 Administrator Closes Session owned by Another User sd E132-SCN-05 Admin Closes Session Owned by Another Client «interface» :Equipment «interface» :Application :Administrator EstablishSession(endPoint) EstablishSessionResponse(sessionId) GetActiveSessionRequest Administrator may close other client sessions when equipment or application updates are needed GetActiveSessionResponse(activeSession) CloseSessionRequest(activeSession) CloseSessionResponse CloseSessionRequest(sessionId) CloseSessionResponse SessionClosedNotification(sessionId) Ack If a DCP is active for a persistent session, the equipment informs the client of DCP hibernation. Then, equipment notifies that the session will be frozen.

58 11/22/2004 EDA Scenarios Slide 12 SEMI E125 Equipment Self Description Standard Two groups of services have been defined: Metadata Query Services Metadata Management Service

59 11/22/2004 EDA Scenarios Slide 13 Metadata Management Services Metadata Metadata Session Start Establish Session NotifyOnRevisions() Close Session MetadataRevised() GetLatestRevision() Client NotifyOnRevisions() Equipment Metadata Notification Services MetaDataRevised() Metadata Revised MetadataRevised() NotifyOnRevisions() SetNotifyOnRevisions() GetLatestRevision() GetLatestRevision()

60 11/22/2004 EDA Scenarios Slide 14 E125-SCN-02 Metadata Change Notification Scenario sd E125-SCN-02 Metadata Notification Scenario «interface» :Application «interface» :Equipment EstablishSessionRequest(endPoint) Client establishes a sessi on, queries the equipment for its latest metadata revision date and asks to be notified of any changes Establ i shsessi onresponse(sessi onid) GetLatestRevisionRequest GetLatestRevisionResponse(response) NotifyOnRevisionRequest(notification) NotifyOnRevisionsResponse Metadata Revised MetadataRevisedNotification(revision) Ack CloseSessionRequest(sessionId) Equipment notifies client that the metadata has changed CloseSessionResponse

61 11/22/2004 EDA Scenarios Slide 15 SEMI E134 Data Collection Management Standard Defined Groups of Services Are: DCP Management Services DCP Query Services DCP Performance Warning Services

62 DCP Management Services DCP DCP 11/22/2004 EDA Scenarios Slide 16 Session Start Authenticate Metadata Create DCP Activate Data Report Deactivate Close Session Client DefinePlan() Equipment Data Collection Plan Management ActivatePlan() NewData() NewData() DeactivatePlan() Trigger occurs DefinePlan() Event, Event, Exception, Exception, Trace Trace ActivatePlan() DeactivatePlan() DeletePlan() GetActivePlanIDs() GetPlanDefinition() GetDefinedPlanIDs()

63 DCP Management Services 11/22/2004 EDA Scenarios Slide 17 E134-SEQ-03 DeactivatePlan() E134-SEQ-04 DeletePlan() Normal Case E134-SEQ-03.1 DeactivatePlan() Terminate set to False E134-SEQ-03.6 DeactivatePlan() Terminate set to True Exception Cases E134-SEQ-03.2 Invalid SessionID E134-SEQ-03.3 No privilege E134-SEQ-03.4 Non existent PlanID E134-SEQ-03.5 PlanId Not activated Scenario E134-SCN-02 DCP Deactivation Scenario (add text to cover Terminate attribute ) E134-SCN-03 Terminate set to true everyone stops getting data Normal Case E134-SEQ-04.1 DeletePlan() Exception Cases E134-SEQ-04.2 Invalid SessionID E134-SEQ-04.3 No privilege E134-SEQ-04.4 Non existent PlanID Scenario E134-SCN-04 DCP deletion and Editing sd E134-SEQ-03 DeactivatePlan() «interface» «interface» :Application :Equipment DeactivatePlanRequest(planId, terminate) DeactivatePlanResponse(deactivatedPlan) sd E134-SEQ-04 DeletePlan() «interface» «interface» :Application :Equipment DeletePlanRequest(planId) DeletePlanResponse(deletedPlan)

64 11/22/2004 EDA Scenarios Slide 18 DCP Recovery from Performance Warning Client Equipment Activate Plan 1 Report Data 1 Activate Plan 2 Report Data 2 Reporting Data 1-2 PerformanceWarning() Deactivate Plan 2 Report Data 1 Report Data 1 Performance Issue Deactivate could be done by either client or equipment

65 11/22/2004 EDA Scenarios Slide 19 E134-SCN-04 Performance Warning with Performance Restored sd E1324-SCN-04 Performance Warning with Performance Restored «interface» :Application «interface» :Equipment Cli ent establ i shes sessi on, queries for all defined DCPs in the equipment and starts activating DCPs Client continues activating DCPs Client deactivates remaining DCPs and closes its session EstablishSessionRequest(endPoint) EstablishSessionResponse(sessionId) GetDefinedPlanIdsRequest GetDefinedPlanIdsResponse(definedPlans) ActivatePlanRequest(planId) ActivatePlanResponse(activatedPlan) NewDataNotification(dataCollectionReport) Ack ActivatePlanRequest(planId) ActivatePlanResponse(activatedPlan) PerformanceWarning(warning) Ack DCPDeactivationNotification(deactivationNotice) Ack PerformanceRestoredNotification(status) Ack NewDataNotification(dataCollectionReport) Ack DeactivatePlanRequest(planId) DeactivatePlanResponse(deactivatedPlan) CloseSessionRequest(sessionId) CloseSessi onresponse Equipment starts reporting data from activated DCPs Equipment detects performance problems, reports it to client and shuts down the last activated DCP Equipment notifies the vclient that performance has been restored and resumes data reporting

66 11/22/2004 EDA Scenarios Slide 20 Equipment Restarts DCP with Persistence DCP DCP Client Equipment ActivatePlan() NewData() Trigger occurs Client suspends data collection and waits for session to come back DCPHibernation() SessionFrozen() SessionPing() NewData() Equipment is going offline Equipment is back online Trigger occurs

67 11/22/2004 EDA Scenarios Slide 21 General Usage Scenarios Single and Multiple Client and Server Combination SCN-01 Basic EDA Usage Scenario SCN-02 Single Client Multiple DCPs Activate SCN-03 Multiple Clients Activating Same DCP SCN-04 Multiple Clients Multiple DCP SCN-05 Deactivate with More than One Client Receiving Data

68 SCN-02 Single Client Multiple DCP Activate 11/22/2004 EDA Scenarios Slide 22 Client Start Authenticate Create DCP 1 Activate Data Report Deactivate Close Session Create DCP 2 Activate Data Report Deactivate Client A Authenticate & Create Session Equipment Create & Activate DCP 1 Create & Activate DCP 2 Data Report for DCP1 Data Report for DCP2 Deactivate DCP 1 Data Report for DCP2 Deactivate DCP 2 Close Session

69 11/22/2004 EDA Scenarios Slide 23 SCN-03 Multiple Client Single DCP Client A Start Client B Start Authenticate Authenticate Metadata Create DCP Get DCP Activate Data Report Data Report Deactivate Deactivate Close Session Close Session Client A Equipment Client B Authenticate & Create Session Create DCP Activate DCP Data Report Authenticate & Create Session Get DCP Definition & ID Activate DCP Data Report Only Only one one data data report report sent sent out out from from EQP EQP to to many many clients clients at at the the same same time. time. Data Report Deactivate DCP Close Session Deactivate DCP Close Session The DCP can not be deactivated until the last client sent deactivate DCP message.

70 11/22/2004 EDA Scenarios Slide 24 SCN-04 Multiple Client Multiple DCP Client A Start Authenticate Create DCP 1 Activate Data Report Deactivate Close Session Client B Start Authenticate Create DCP 2 Activate Data Report Deactivate Close Session Client A Equipment Client B Authenticate & Create Session Request Metadata Create DCP 1 Activate DCP 1 Data Report Authenticate & Create Session Request Metadata Create DCP 2 Activate DCP 2 Data Report Note that the Request Metadata and Create DCP are optional to client(s). Deactivate DCP 1 Close Session Deactivate DCP 2 Close Session

71 11/22/2004 EDA Scenarios Slide 25 SCN-05 DCP Deactivation with more than one Client Receiving Data (Terminate=True) sd SCN-05 DCP Deactiv ation w ith More than One Client Receiv ing Data «interface» :Application «interface» :Equipment «interface» ApplicationII EstablishSessionRequest(endPoint) EstablishSessionResponse(sessionId) Client1 establishes sessi on, creates and activates a DCP DefinePlanRequest(newPlan) DefinePlanResponse(definedPlan) ActivatePlanRequest(planID) ActivatePlanResponse(activatedPlan) Equipment sends data report to Client1 NewDataNotification(dataCollectionReport) Ack EstablishSessionRequest(endPoint) EstablishSessionReponse(sessionId) GetDefinedPlanIds GetDefinedPlanIdsResponse(definedPlans) GetPlanDefinitionRequest(planId) GetPlanDefinitionResponse(planDefinition) ActivatePlanRequest(planId) ActivatePlanResponse(activatedPlan) Client2 establishes a sessi on, queries equipment about defined DCPs, selects the one that is currently active, and activates it Equipment sends data report to Client1 and Client 2 NewDataNotification(dataCollectionReport) NewDataNotification(dataCollectionReport) Ack Ack Client1 deactivates DCP and terminates all i nstances usi ng the terminate argument set to TRUE DeactivatePlan(planId, terminate) DeactivatePlanResponse(deactivatedPlan) CloseSessionRequest(sessionID) CloseSessi onresponse DCPDeactivationNotification(deactivationNotice) Ack Equipment notifies and deactivates DCP reporting

72 11/22/2004 EDA Scenarios Slide 26 Next Steps Publication and availability of EDA Usage Scenarios Tech Transfer Document at SEMATECH ISMI public web site Exception Handling Cases Continue development of additional cases and describe in more detail the expected behavior of the interface via exception handling cases Completion Date 1Q2005 Contact Gino Crispieri (512)

73 Factory Automation Standards Tracking (FAST): FAST II Survey EDA Results December 2004 Jackie Ferrell, ISMI Harvey Wohlwend, ISMI Lance Rist, ISMI Jeff Silveira, SEMI

74 Outline About the FAST II Survey Analysis of EDA Responses Usage, Priorities, Roadmaps Summary SEMATECH, the SEMATECH logo, AMRC, Advanced Materials Research Center, ATDF, the ATDF logo, Advanced Technology Development Facility, ISMI and International SEMATECH Manufacturing Initiative are servicemarks of SEMATECH, Inc. All other servicemarks and trademarks are the property of their respective owners. 2 FASTII

75 FAST II Survey Purpose Consolidate surveys and expand scope Update survey and roadmap on a regular basis Compare Device Maker need dates and Supplier implementation roadmaps Report level of usage/delivery on existing standards Provide feedback to standards task forces to: Focus industry resources on standards that are most important to customers and suppliers Identify obsolete standards 3 FASTII

76 About The Survey Scope of FAST II All SEMI Information and Control Standards Standards usage, priority, and timing Distribution ISMI sends to member company fabs SEMI sends to Suppliers and other device makers Results ISMI provides summary results from ISMI device makers SEMI provides summary results from suppliers and other device makers Names of participants are confidential ISMI maintains consolidated summary report 4 FASTII

77 Survey Responses FAST II Device Makers 9 device makers responded Responses related to 300 mm fabs 7 provided need dates for future requirements 1-4 responders assigned priorities to the standards FAST II Equipment Suppliers and Software Providers 16 responses for equipment platforms 9 provided implementation dates for new and emerging standards 1-6 responders assigned priorities to the standards FAST II Roadmap compared to FAST Roadmap Some of the responses represent different companies FAST device makers responses = 7 FAST supplier responses = 10 5 FASTII

78 Survey Frequency FAST Survey was completed in November 2003 FAST II survey will be conducted as needed to reflect current status FAST II Summary Results reported: Sept 04 AEC/APC Denver Oct 04 e-mfg Workshop Portland update Dec 04 Taiwan AEC/APC update Apr 05 Dublin AEC/APC update planned Next Survey Distribute early 2005 Refresh current survey participant information Add new survey participant responses Enhance survey; add new standards 6 FASTII

79 7 Device Maker Delivered Standard is being delivered at a level sufficient for operations Required Standard is in purchase spec but is not yet being delivered Required and Future Standard is in purchase spec as a future requirement Future Standard will be required in the future Ignore Standard is low priority and not in my purchase spec Withdraw Standard should be withdrawn Survey Categories RD R RF F O W Supplier Implemented Supplier is delivering compliant implementations In development Standard is being developed On Roadmap Standard is on our roadmap for implementation Evaluating For Future We are evaluating as a future requirement Ignore or not applicable Standard is low priority or not applicable to our equipment Withdraw Standard should be withdrawn FASTII

80 Analysis of Survey Results Usage/ Delivery RD R RF F O W Priority Value (# of responses) Priority* Priority Values: 3 = High 2 = Medium 1 = Low Weighted Average = Priority values # of responses Timing FAST II Roadmap EDA Production Software Q04 2Q04 3Q04 4Q04 1Q05 2Q05 3Q05 4Q05 1Q06 2Q06 3Q06 4Q06 Data Acquisition E132 Client A & A E134 Data Collection E125 Equipment Self- Description E120 CEM 8 FASTII

81 Communication Standards Communication Standards - Device Makers # Device Makers # Equipment Platforms E5 SECS II E30 GEM E30.1 ISEM E30.5 MSEM E37 HSMS RD R RF F O W Communication Standards - Suppliers E5 SECS II E30 GEM E30.1 ISEM E30.5 MSEM E37 HSMS SECS, GEM, HSMS are the basis of most implementations The original specific equipment models (SEM s) are used very little 9 FASTII

82 Standards Not Widely Used Standards Not Widely Used - Device Makers # device makers # equipment platforms E32 Material Movement RD R RF F O W E32 Material Movement E53 Event reporting E98 OBEM E81, 86, 96, 97, 102, 105 CIM FW Standards Not Widely Used - Suppliers E53 Event reporting E98 OBEM E81, 86, 96, 97, 102, 105 CIM FW CEM (E120) may supercede OBEM (E98) CIM FW standards have influenced MES design; however, they are not enforced as standards - consider converting to guidelines or auxiliary info? 10 FASTII

83 Integration and Automation (I&A) Integration and Automation Standards - Device Makers 11 # Device Makers E39 OSS RD R RF F O W # Equipment Platforms E40 Process Job E87 Carrier Mgmt E90 Substrate Tracking E94 Control Job E109 Reticle Pod Mgmt Equipment Integration and Automation Standards - Suppliers E39 OSS E40 Process Job E87 Carrier Mgmt E90 Substrate Tracking E94 Control Job E109 Reticle Pod Mgmt 300 mm I&A standards provide base functionality Most are being delivered at a level sufficient for operations FASTII

84 EDA Standards 8 Equipment Data Acquisition - Device Makers # Device Makers (4) 3.0 (4) 2.5 (4) 3.0 (4) 1 0 E120 CEM E125 Equip Self- Description E132 Client A&A E134 Data Collection RD R RF F O W # equipment platforms E120 CEM 2.8 (5) Equipment Data Acquisition - Suppliers 2.67 (6) E125 Equip Self- Description Priorities: 3 = High 2 = Medium 1 = Low 2.67 (6) E132 Client A&A 2.67 (6) E134 Data Collection 12 FASTII

85 Nov E132 Client A & A FAST II Roadmap 2003 E134 Data Collection E125 Equipment Self- Description E120 CEM EDA Evaluation Software Need/Plan Dates 1Q04 2Q04 3Q04 4Q04 1Q05 2Q05 3Q05 4Q05 1Q06 2Q Q06 4Q06 Technical standards target aligns to evaluation need dates Some suppliers had Interface A demos at SEMICON West in July; however, several are trailing IDM need dates Device Makers Need Dates Suppliers Planned Dates Standard approval date Technical Spec 13 FASTII

86 FAST II Roadmap EDA Production Software Need/Plan Dates Nov E132 Client A & A 2003 E134 Data Collection E125 Equipment Self- Description E120 CEM 1Q04 2Q04 3Q04 4Q04 1Q05 2Q05 3Q05 4Q05 1Q06 2Q06 3Q06 4Q Equipment Data Acquisition (EDA or Interface A ) remains the highest priority Standards targeted completion aligns with need and implementation roadmap Majority of suppliers are trailing IDM need dates Device Makers Need Dates Suppliers Planned Dates Standard approval date Technical Spec 14 FASTII

87 FAST and FAST II Roadmaps Compared Nov E132 Client A & A E134 Data Collection E125 Equipment Self-Description EDA Production Software Q04 2Q04 3Q04 4Q04 1Q05 2Q05 3Q05 4Q05 1Q06 2Q06 3Q06 4Q06 E120 CEM Device maker range of need dates is narrowing Need dates align with standards approval targets Latest deployment dates are stable Device Makers Suppliers FAST FAST II Device Makers Need Dates Suppliers Planned Dates Standard approval Technical Spec Make-up of responders slightly different between the 2 surveys 15 FASTII

88 Summary Conclusions 300 mm Integration and Automation standards are maturing EDA remains the highest priority Span of device makers need dates is narrowing Supplier dates are trailing device makers need dates Early implementations of EDA are available 2005 is the industry deployment target Roadmap Value Better Planning A consistent industry view of critical need dates and availability of standard implementations Insight to focus resources on most value-add standards Normalization of expectations supplier and device maker More participants invited to help define the roadmap Soliciting survey inputs for April 2005 update The Roadmap is most valuable when it truly reflects global suppliers and device makers 16 FASTII

89 Backup Reference Information Reference list of SEMI Information and Control standards November 2003 FAST Roadmaps Evaluation Software Production Software FAST II Results for other standards 17 FASTII

90 List of SEMI Standards for Reference Equipment Communication and Control E5 SECS II E30 GEM E30.1 Inspection SEM E30.5 Metrology SEM E32 Material Movement E39 Object Services (OSS) E40 Process Job E42 Recipe Management E53 Event reporting E58 ARAMS (Automated E10) E87 Carrier Management E90 Substrate Tracking E94 Control Job E98 Object-Based Equipment Model E109 Reticle Pod Mgmt E116 Equipment Productivity Tracking E120 Common Equipment Model E125 Equip Self-Description E126 Equip Quality Info Parameters (EQIP) E132 Client Authentication & Authorization E134 Data Collection 3442 Recipe Adjustable Parameters 3562 Data Quality Equipment Internal Standards and Equip-Equip Communication E38 Cluster Tool Module/CTMC E54 Sensor/Actuator Network (SAN) E54.3 SAN Device Model for Mass Flow Devices E54.4 SAN Device Model for DeviceNet E54.7 SAN Device Model for Seriplex E54.8 SAN Device Model for Profibus-DP E54.9 SAN Device Model for Modbus/TCP TCP/IP E54.10 Device Model SAN In-Situ Particle Monitor E54.11 Device Model SAN for Endpoint Devices E54.12 Device Model SAN for CC-Link E54.13 Device Model SAN for Ethernet/IP E84 Parallel I/O E95 Human Interface E99 Carrier ID Read/Write E118 Wafer ID E127 Integrated Metrology Communication Technology E4 Message Transfer (SECS I) E37 High-speed Message Services E121 XML Style & Usage E128 XML Messages AMHS Communication and Control E82 Inter/Intrabay Specific Equipment Model (SEM) E88 Stocker SEM Probe, Assembly and Test Communication E91 Prober SEM E122 Tester SEM E123 Handler SEM E130 Prober SEM Factory Level Standards (external to equipment) E36 Equip Information Tag E81, 86, 96, 97, 102, 105 CIM Framework Suite E133 Process Control System 18

91 FAST and FAST II Roadmaps Compared EDA Evaluation Software Nov Q04 2Q04 3Q04 4Q04 1Q05 2Q05 3Q05 4Q05 1Q06 2Q06 3Q06 4Q06 E132 Client A & A E134 Data Collection E125 Equipment Self- Description Make-up of responders slightly different between the 2 surveys E120 CEM Range of device maker evaluation SW need dates narrowed Need dates moved out to align with standards target dates Device Makers Suppliers FAST Device Makers Need Dates Suppliers Planned Dates FAST II Standard approval Technical Spec

92 FAST and FAST II Roadmaps Compared EDA Evaluation Software Nov Q04 2Q04 3Q04 4Q04 1Q05 2Q05 3Q05 4Q05 1Q06 2Q06 3Q06 4Q06 E132 Client A & A E134 Data Collection E125 Equipment Self- Description Make-up of responders slightly different between the 2 surveys E120 CEM Range of device maker evaluation SW need dates narrowed Need dates moved out to align with standards target dates Device Makers Suppliers FAST Device Makers Need Dates Suppliers Planned Dates FAST II Standard approval Technical Spec 20 FASTII

93 Industry e-manufacturing FAST Roadmap Data Acquisition 7 + IC Makers + 10 Suppliers input Interface A Production Software Need Dates Interim I/F A-PR8 Data Quality-3652 Sensor Bus-E54 Interface C Guidelines Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q Q 3Q Nov Q Data Utilization EPT-E116 RaP-3442 Integrated Measurement-E127 PCS-E133 OBEM-E Docs. Electronic Documentation-E IC Maker s priorities High Medium Low 21 Supplier s priorities High Standard/document approval date Medium Low 21 FASTII

94 Industry e-manufacturing FAST Roadmap Data Acquisition 7 + IC Makers + 10 Suppliers input Interface A Interim I/F A Data Quality Sensor Bus Evaluation Software Need Dates Interface C Guidelines Q 2Q 3Q 4Q 1Q 2Q 3Q Q 1Q Q 3Q Nov Q E132, E134, E125, E120 PR E54 Data Utilization EPT RaP Integrated Measurement PCS OBEM E E127 E133 E98 Docs. Electronic Documentation 1 2 E36.1 IC Maker s priorities 2.01 High 3.00 Medium Low Supplier s priorities High Standard/document approval date Medium Low FASTII

95 Specific Communication Device Models Specific Communication Device Models - Device Makers # Device Makers Mass Flow Devices RD R RF F O W # equipment platforms Mass Flow Devices DeviceNet Seriplex ProfibusDP Modbus/TCP TCP/IP In-Situ Particle Monitor Endpoint Devices Specific Communication Device Models - Suppliers DeviceNet Seriplex ProfibusDP Modbus/TCP TCP/IP In-Situ Particle Monitor Endpoint Devices CC-Link Ethernet/IP Only a few device makers require a particular Specific Communication Device Model CC-Link Ethernet/IP 23 FASTII

96 Recipe & Productivity Stds 11 Recipe Management- Device Makers 11 Productivity Standards - Device Makers # Device Makers # Equipment Platforms E42 Recipe Management 3442 RaP Recipe Management Standards - Suppliers 1.75 (4) E42 Recipe Management 2.5 (4) # Device Makers RD R RF F O W 3442 RaP # Equipment Platforms E58 ARAMS E116 EPT Productivity Standards - Suppliers 1 E58 ARAMS 2.33 (3) 2.2 (5) E116 EPT Recently approved RaP replaces little used E42 Newer EPT has more support than ARAMS; however, both standards are used 24 FASTII

97 Automated Material Handling # Device Makers Automated Material Handling Standards - Device Makers E84 Parallel I/O E82 IBSEM E88 Stocker SEM RD R RF F O W # Equipment Platforms Automated Material Handling Standards - Suppliers E84 Parallel I/O E82 IBSEM E88 Stocker SEM E82 and E88 are specific to AMHS suppliers Widely used E84 Parallel I/O links production equipment to AMHS 25 FASTII

98 Internal Equipment Internal Equipment Standards - Device Makers # Device Makers E38 Cluster Tool Module/CTMC E54 Sensor/Actuator E95 Human Interface E99 Carrier ID RW E118 Wafer ID RD R RF F O W Internal Equipment Standards - Suppliers # equipment platforms E38 Cluster Tool Module/CTMC E54 Sensor/Actuator E95 Human Interface E99 Carrier ID RW E118 Wafer ID 26 FASTII

99 New and Emerging Standards Emerging Standards - Device Makers Data Quality needed. It is not yet well defined # Device Makers (4) 2.4 (5) 3562 Data Quality E126 EQIP E127 Integrated Metrology RD R RF F O W 2.25 (4) Emerging Standards - Suppliers 2.0 (1) E133 PCS Priorities: 3 = High 2 = Medium 1 = Low One device maker provided need date (2006). This appears to be a good idea that needs to mature # equipment platforms (3) 2.33 (3) 1.67 (3) 3.0 (1) 3562 Data Quality E126 EQIP E127 Integrated Metrology E133 PCS 27 FASTII

100 FAST II Roadmap Emerging Stds Evaluation Software Need / Plan Dates Nov E116 EPT 3442 RaP E127 Integ Meas E126 EQIP 3652 Data Quality Q04 2Q04 3Q04 4Q04 1Q05 2Q05 3Q05 4Q05 1Q06 2Q06 3Q06 4Q Emerging Stds Production Software Need / Plan Dates E116 EPT 3442 RaP E127 Integ Meas E126 EQIP 3652 Data Quality Device Makers Need Dates Suppliers Planned Dates Standard approval date 28 FASTII

101 XML Standards XML Standards - Device Makers # Device Makers # Equipment Platforms E121 XML Style & Usage E128 XML Messages E36 Equip Info Tag RD R RF F O W 2.4 (5) 2.4 (5) XML Standards - Suppliers 2.0 (3) 2.0 (3) 2.0 (1) E121 XML Style & Usage E128 XML Messages E36 Equip Info Tag XML Technology is entering the semiconductor industry. E36 - Recently modified to include XML tagging, Needs marketing if it is to succeed 29 FASTII

102 Measuring the Performance of XML-Based Data Standards Gino Crispieri ISMI SEMATECH, the SEMATECH logo, AMRC, Advanced Materials Research Center, ATDF, the ATDF logo, Advanced Technology Development Facility, ISMI and International SEMATECH Manufacturing Initiative are servicemarks of SEMATECH, Inc. All other servicemarks and trademarks are the property of their respective owners.

103 11/22/2004 j://stdpres/template.pot Slide 2 Content NIST Marshalling Performance Testing Results based on Castor and JIBX XML Binding Software XML SOAP Package Performance Measurement JavaSOAP1 JavaSOAP2 C++SOAP Lessons Learned

104 11/22/2004 j://stdpres/template.pot Slide 3 Common Manufacturing Environment More than 500 discrete instruments on the facility floor Typical factory networks equipment with 100 Mbps Ethernet with 1 Gbps backbone network to control room

105 11/22/2004 j://stdpres/template.pot Slide 4 Equipment Requirements The technology used for data transfer must support a maximum throughput of 10,000 data values per second or at least one trace message of 1000 variables at sample period of 100 milliseconds The typical tool should provide 50 variables per chamber at a maximum on-tool sample rate of 10Hz For some specialized processes such as rapid thermal and flash anneal, an additional smaller number of (up to, for example, a total of 30-40) critical variables may require a maximum on-tool sample rate of 200Hz EEC High Level Requirements for APC

106 11/22/2004 j://stdpres/template.pot Slide 5 What is Marshaling? E134 Message example

107 11/22/2004 j://stdpres/template.pot Slide 6 Data Collection Report IntervalInMinutes plan Id Data Collection Report Data Collection Report planid bufferstarttime bufferendtime reporttime Event Report bufferstarttime Trace Report Exception Report Event Report bufferendtime 1 {ordered} 1..* Report send send report report at at (report (report Time) Time) Consumer Event Report Trace Report Exception Report The The consumer consumer should should be be identified identified by by authenticated authenticated session. session. E134

108 NIST XML Marshalling Testing Eric Simmons, Art Greisser NIST Gino Crispieri - ISMI

109 11/22/2004 j://stdpres/template.pot Slide 8 Hardware Setup 1.3 GHz Athlon CPU 100Mhz bus, 512M RAM, 7200 rpm IDE hard drive Linux Operating System Five levels of data were created containing 10, 50, 100, 500, 1000, 5000 and 10,000 data points integer data values ranging from 0 to 100,000 double precision floating point data values ranging from 0.0 to 1.0

110 11/22/2004 j://stdpres/template.pot Slide 9 Testing Flowchart Collect Garbage Record Start Time Java collects garbage before running the test Call Unmarshalling Record Stop Time Calculate and record Record Unmarshalling unmarshalling time Time Unmarshal from XML instance, using mapping file, into Java objects Record Start Time Call Marshalling Marshal data from Java objects into XML instance using mapping file Record Stop Time Calculate and Record Marshalling Time

111 11/22/2004 j://stdpres/template.pot Slide 10 Castor XML Performance f8 no-x 500 Time (ms) Marshalling Un-Marshalling Number of Parameter Values (average of 99 tests)

112 11/22/2004 j://stdpres/template.pot Slide 11 JIBX Performance Data Unmarshall Marshall

113 11/22/2004 j://stdpres/template.pot Slide 12 Integer vs Double Precision Parameter Value Performance Time (ms) Garbage collection Integer Unmarshalling Integer Marshalling Double Unmarshalling Double Marshalling Run Number

114 11/22/2004 j://stdpres/template.pot Slide 13 NIST Summary of Results Initial loading of mapping file increases marshalling/unmarshalling time of first test Object creation causes big performance hit Other processes running concurrently while marshalling cause non-negligible delays JIBX outperformed Castor Marshalling/unmarshalling times scale approximately linearly with processor speed Unmarshalling scales exponentially with parameter values There is little performance difference between an instance with integer values and an instance with double precision values Next performance test with XBINDER (C++)

115 SOAP and XML Performance Measurements Jean Francois Dufuor & Eugen Kender CenterPoint Gino Crispieri - ISMI

116 11/22/2004 j://stdpres/template.pot Slide 15 XML SOAP Package Performance Three SOAP packages were analyzed by 3 rd Party Software supplier A Java language SOAP package (will call JavaSOAP1 ) A Java language SOAP package (will call JavaSOAP2 ) A C++ language SOAP package (will call C++SOAP1 ) Each implementation had a sender and a receiver The sender was responsible for generating data, creating SOAP message from the data, and sending the SOAP message The receiver was responsible for receiving the SOAP message, parsing the message, and processing the data The time taken to perform these steps was measured Additionally an overall sender and receiver total time was measured CPU load and Page Fault Rate for the test scenarios were also measured

117 11/22/2004 j://stdpres/template.pot Slide 16 Measurements Field DATATIMERECEIVER XMLTIMERECEIVER DATATIMESENDER XMLTIMESENDER CPULOAD PAGEFAULTRATE Defined The time required by the receiver application to process the data. In the case of our testing, the data is written to a file. The time required by the receiver to parse the XML document and to receive the message. The time required by the sender to generate the values for transmission. The time required by the sender to construct the XML document and send the message. CPU Load as a percentage. Obtained from the operating system. Page Faults / second. Obtained from the operating system.

118 11/22/2004 j://stdpres/template.pot Slide 17 Hardware Specifications The two computers used had the following specifications: CPU Pentium IV 2.8GHZ S478 FSB800 (1MB) Hyper Threading RAM 256MB DDR Hard Disk 36.6 GB 4.7ms rpm, 4MB Cache ST336607W O/S Windows 2000 SP 4 and Linux

119 11/22/2004 j://stdpres/template.pot Slide 18 Statistics Each test case has more than 100 numerical results that were averaged and plotted The standard deviations are used to generate confidence intervals using a Student s T distribution, which assumes a Gaussian distribution for the response variables A 95% confidence interval of +/- 1.5 for a mean value 15 means that, while we report 15 as the average, the true running is within 13.5 to 16.5, 19 times out of 20 All confidence intervals are valid 19 times out of 20, or 95% of the time

120 11/22/2004 j://stdpres/template.pot Slide 19 XML Time Receiver C++SOAP XMLTIMERECEIVER: C++SOAP to C++SOAP Time (ms) Values / Message Windows receiving from Windows Linux receiving from Linux Linux receiving from Windows Windows receiving from Linux

121 11/22/2004 j://stdpres/template.pot Slide 20 XML Time Receiver JavaSOAP1 XMLTIMERECEIVER: JavaSOAP1 to JavaSOAP Time (ms) Values / Message Windows receiving from Windows Linux receiving from Linux Linux receiving from Windows Windows receiving from Linux

122 11/22/2004 j://stdpres/template.pot Slide 21 XML Time Receiver Java-SOAP2 XMLTIMERECEIVER: JavaSOAP2 to JavaSOAP Time (ms) Values / Message Windows receiving from Windows Linux receiving from Windows Linux receiving from Linux Windows receiving from Linux

123 11/22/2004 j://stdpres/template.pot Slide 22 Total Time C++SOAP DATATOTAL: C++SOAP to C++SOAP Time (ms) Values / Message Windows vs. Windows Linux vs. Linux Linux vs. Windows Windows vs. Linux

124 11/22/2004 j://stdpres/template.pot Slide 23 Total Time JavaSOAP1 DATATOTAL: JavaSOAP1 to JavaSOAP Time (ms) Values / Message Windows vs. Windows Linux vs. Linux Linux vs. Windows Windows vs. Linux

125 11/22/2004 j://stdpres/template.pot Slide 24 Total Time JavaSOAP2 DATATOTAL: JavaSOAP2 to JavaSOAP Time (ms) Values / Message Windows vs. Windows Linux vs. Linux Linux vs. Windows Windows vs. Linux

126 11/22/2004 j://stdpres/template.pot Slide 25 XML Performance Same Package Messages per second: C++Soap to C++Soap Number of messages Windows sending to Windows Linux sending to Linux Windows sending to Linux Linux sending to Windows Values / Message

127 11/22/2004 j://stdpres/template.pot Slide 26 XML Performance Alternate Package Linux vs. Linux Sender: Interoperability Time (ms) Values / Message Java2S sending tocsoap Csoap sending to Java2S CSoap sending to Java2S Java2S sending to Java1S Java1S sending to CSoap CSoap sending to Java1S

128 11/22/2004 j://stdpres/template.pot Slide 27 Multi-thread Environment Test Measure of the average time needed to send one message in a multithreaded environment with C++soap, 1 sender node and 1 receiver node Elapsed sender time (ms) datapoints datapoints datapoints Number of threads

129 11/22/2004 j://stdpres/template.pot Slide ,00 Measure of the efficiency difference between the three main scenarios with C++Soap 600,00 Messages sent per second 500,00 400,00 300,00 200,00 Messages send versus Number of Threads 100,00 0,00 100, , ,00 3 threads, 1 snd - 1 rcv 392,71 75,83 7,37 3 threads, 1 snd - N rcv 435,48 73,83 7,42 3 threads, N snd - 1 rcv 512,61 105,13 12,65 5 threads, 1 snd - 1 rcv 388,35 79,47 7,45 5 threads, 1 snd - N rcv 485,51 77,10 7,60 5 threads, N snd - 1 rcv 690,72 130,89 16,92 Nb of datapoints

130 11/22/2004 j://stdpres/template.pot Slide 29 CPU Load Sender CPU Load Sender JavaSOAP, C++SOAP C++SOAP to C++SOAP JavaSOAP to JavaSOAP Windows Sending to Windows Linux Sending to Linux Windows Sending to Linux Linux Sending to Windows Average of All

131 11/22/2004 j://stdpres/template.pot Slide 30 CPU Load Receiver CPU Load Receiver JavaSoap, C++soap C++Soap to C++Soap JavaSoap to JavaSoap Windows Sending to Windows Linux Sending to Linux Windows Sending to Linux Linux Sending to Windows Average of All

132 11/22/2004 j://stdpres/template.pot Slide 31 CPU Usage Multi-threading Measure of the processor usage with JavaSOAP (Multiple sender nodes - 1 receiver node) 100,00 90,00 80,00 70,00 60,00 CPU (%) 50,00 40,00 30,00 20,00 10,00 0, Nb of datapoints 3 threads - Rcv 5 threads - Rcv 3 threads - Snd 5 threads - Snd

133 11/22/2004 j://stdpres/template.pot Slide 32 CPU usage Results C++SOAP outperformed JavaSOAP with respect to speed, on every test JavaSOAP outperformed C++SOAP [in terms of resource consumption] in our hardware tests JavaSOAP always used less CPU than C++SOAP Page fault rates were similar for the receiver regardless of SOAP package, but the JavaSOAP sender had significantly less page faults than the C++SOAP sender Page fault rates for the sender and receiver were less under Linux than for Windows. Soap package did not affect this CPU Time was much less when using JavaSOAP than when using C++SOAP. Linux used marginally less CPU time than Windows did One JavaSoap package cause CPU usage to drop on the equipment side because is affected their performance by making the equipment wait to send next message

134 11/22/2004 j://stdpres/template.pot Slide 33 Interoperability SOAP packages provide code generation utilities that take a WSDL and schema documents and creates sending/receiving code (proxys) for their SOAP framework One JavaSOAP implementation generated invalid (non conformant) message Own mechanism to optimize message exchange The other JavaSOAP and C++SOAP implementation generated valid (conformant) messages Qualified each tag with a namespace prefix (similar to other packages) SOAP Message from JavaSOAP: <TR soapenc:arraytype='n3:collecteddatatype[1]'> <i><pv soapenc:arraytype='n3:parametervaluetype[2]'><i> <Arr xsi:nil='1'></arr> <F8> </F8> SOAP Message from C++SOAP: <ns2:tr collectiontime=" t04:46:39+02:00"> <ns2:pv> <ns2:f8> </ns2:f8>

135 11/22/2004 j://stdpres/template.pot Slide 34 Lessons Learned Using generic Parsers for marshalling and un-marshalling can affect performance Castor, JIBX, Gnome, JABX, XBinder, Liquid XML, LMX,.net and others Must conform to XML, WSDL, SOAP specs and WSI Basic Profile Rules There are many SOAP commercial packages for the computer language of your choice GSOAP,.Net Framework, Websphere, IONA XML, TCLSoap, SoapRMI, GLUE, Apache Axis, and many others Operating system can have impact on performance Be careful of background processes (GUI, other applications) Windows 2000 vs XP, Unix vs Linux, Solaris, VMX, others Interoperability can be a problem if you do not ensure your toolkit supports the W3C and WS-I specifications EDA specs use document/literal encoding Make sure the SOAP package supports this encoding and conforms to the Web Services Interoperability (WS-I) organization s Basic Profile See It is possible to create map files to fix this problem but performance can be affected Do a complete performance and resource consumption characterization of your candidate toolkits before selecting one for implementation

136 11/22/2004 j://stdpres/template.pot Slide 35 Conclusion XML Performance is not an issue it can be achieved to EDA specified rates Choosing the right hardware and software combination depends on your application Client performance can be an issue since it could affect equipment capability to send messages Interoperatibility is possible across operating systems as well as SOAP packages

137 Developments In Recipe Management Lance Rist ISMI e-manufacturing Workshop SEMATECH, the SEMATECH logo, AMRC, Advanced Materials Research Center, ATDF, the ATDF logo, Advanced Technology Development Facility, ISMI and International SEMATECH Manufacturing Initiative are servicemarks of SEMATECH, Inc. All other servicemarks and trademarks are the property of their respective owners. All Clipart Copyright 1998 Corel Corporation and its licensors. All rights reserved.

138 2 Outline What is the state of Recipe Management? What are the problems? The Solution A new SEMI Standard (RaP) How does RaP solve the problems? Brief technical overview of RaP RaP roadmap

139 3 Equipment Recipe Management Today Recipe management today is primitive Related SEMI Standards are years old Implementations are limited to upload/download/delete No commercially successful alternative has been available

140 4 Equipment Recipe Management Today Is There Really A Problem? Yes, it is large and growing Equipment Integrators cannot ensure the recipe is the correct one Process Control Engineers cannot set all needed parameters Process Engineers cannot track what actually happened Key Settings are often beyond recipe control The SECS/GEM connection is saturated with constant recipe uploads and downloads (recipe size is growing)

141 5 Equipment Recipe Management Today What is the current solution? Use a larger club! Hack the recipe to change APC settings Download the recipe every time Pay for special enhancements Or ignore the problem Cancel some APC projects Assume the correct recipe/settings were used Live with reduced throughput and more scrap It is time for new ideas!

142 6 A New Solution Recipe and Parameter Management (RaP) A new SEMI Standard Approved in October, 2004 Gives the user the tools to solve today s Recipe Management problems! How does RaP solve the problems?

143 7 Recipe Content Can Be Trusted Today, recipes on equipment are suspect Recipes are identified by name not guaranteed unique Recipe content may change by user, by equipment At job setup, most factories: a) Download the recipe (again), or b) Upload the recipe and compare it to the real recipe For many equipment, recipes are MB or even GB sized A RaP recipe is downloaded only once RaP recipes are given a universally unique identifier (uuid) uuid is an ISO standard string - guaranteed unique Even recipes created on different equipment would never have the same identifier When a recipe changes, the identifier must change A checksum is included to ensure no change has occurred Bottom Line With RaP: Recipe upload/download is the exception, not the rule

144 8 Process Control is Enhanced Today, few recipes are parameterized Some equipment provides a limited parameter set Device makers commonly modify recipes on the fly and download, overwriting the old version RaP provides for user controlled parameterization User decides which module parameters can be set at run-time A given module parameter may take on different values Multiple steps in a process chamber Bake at 100C for10 min then Bake at 200C for 5 min Revisit the same process chamber In a cluster tool, can use same chamber for different steps Give setting per wafer (less common, but very powerful) APC may give each wafer different etch time Bottom Line With RaP: Process Control gains access to the needed run-time settings

145 9 Number Of Recipes Reduced Today, factories must maintain separate recipes For each set of process conditions For each instance of the same equipment type A RaP recipe can be fully parameterized Recipes can be used run-to-run Changes from run to run can be adjusted without recipe change (Process Job parameters) Recipes can be shared by similar equipment Recipes can be reused for similar processes Bottom Line With RaP: We can simplify the job of managing recipes Managing the parameter settings becomes a challenge But it does not involve a proprietary recipe editor The user has full control

146 10 Multi-Part Recipes Supported Today, multi-part recipes exist, but are not supported In RaP, the PDE s form a hierarchy At the top of the hierarchy is a Master PDE Specified for Job via RCPSPEC/PPID User has services to assess availability of all needed recipe components Each component can have its own parameter set Bottom Line RaP supports today s complex equipment Referenced PDE s Master PDE PDE = Process Definition Element Recipe Component PDE Process Job PDE PDE PDE PDE PDE RCPSPEC/PPID PDE PDE s reference other PDE s: subrecipes, utilities, etc. PDE VariableParameters o PDEparam1 o PDEparam2 o etc

147 11 Traceability of Recipes Enabled Today, it is difficult to trace history of a wafer Recipes selected by name names not unique Recipes modified and downloaded for process control same recipe name in retrospect, can t tell one from another RaP enables and encourages traceability Recipes identified by uuid guaranteed unique Equipment encouraged to report RaP defined data Identity of the Master PDE (Recipe) Identities of all other PDE s used for processing Values supplied for recipe parameters As context report RaP data for each instance of processing Bottom Line RaP enables traceability with clear data definition & identifiers Encourages improved data reporting Requirement of data reporting belongs in Processing Management standard (SEMI E40) RaP TF working with GEM300 TF to achieve this

148 12 RaP Value Proposition $ Recipe Content Trusted Guarantee that the recipe on the equipment is exactly the one the factory approved/downloaded/selected Streamlines Job Setup $ Process Control Enhanced User defines which parameters can be set per job and when during processing they will be used $ Number of Recipes Reduced If they are parameterized, fewer recipes are needed $ Multi-Part Recipes Explicitly Supported Enabling a practical method for reuse of recipe components Ensuring all needed components are available $ Traceability of Recipes Enabled Unique identifiers assigned to recipe components are reportable via events (and parameter values) With RaP equipment can support new, sophisticated host-side recipe management systems

149 13 RaP Conceptual View Three entities defined Factory (FICS) Equipment Recipe Editor APC settings Data Base Station Controller history FICS Recipe Manager Interfaces defined A. Equipment Factory B. Editor Factory C. Equipment Editor Standard Protocol not required A EQUIPMENT C B RECIPE EDITOR RaP defines eight communication services Transfer Manage Verify getpde() getpdedirectory() verifypde() requesttosendpde() deletepde() resolvepde() sendpde() getpdeheader()

150 14 RaP Adds Public Recipe Header Standardized recipe header (non-executable) Documents key recipe attributes for human and computer use Name, description, target equipment, antecedents, etc. XML format for accessibility by common tools No need to access the (proprietary) recipe body to learn about recipe contents. PDE (= Recipe Component) PDEheader <<Documentation Part>> Name UID GID Version Description Target Equipment Antecedents PDE References External Parameters User Info PDEbody <<Executable Part>> Content is not specified and may be kept private

151 15 PDE checksum PDE Object Model 1 PDEheader AntecedentData 0..1 PDEbodyReference specification bodychecksum xor 0..1 PDEbody uid name gid groupname description type executable maxantecedents createdate createnode author userinfo supplierinfo 0..* 0..* uid name gid groupname description author createdate createnode id ReferencedPDE 0..* All recipe components are PDE s 0..* 0..* ExecutionTarget identifier supplier make model recipetypes PDEparam eter name description units relatedparam eters defaultvalue inputboundarytype inputbounds

152 16 Transition To RaP Existing recipes can be preserved (in many cases) Original recipe can be maintained as a separate (nearly unchanged) opaque entity PDE can act as a descriptive wrapper on the original recipe Execution on equipment may not need to change Equipment recipe management must adjust to new structures Communication Services very similar to current ones Pull or push recipes, directory, verify, delete (add get-header) Within the context of E40: Define the name to be used in the RCPSPEC field of Stream 16 SECS II messages Define the name to be used in the RCPPARNM field of Stream 16 SECS II messages

153 17 RaP Task Force Activities SEMI Doc. 3442A (RaP) approved Oct Some improvements scheduled none major RaP Needs Implementation Mappings Content of the PDE s XML Schema (xx.1) SECS II Messaging (xx.3) XML Messaging Similar to EDA (xx.2) Some Improvements Beyond RaP Scope Most in E40 Scope (owned by GEM300 TF) Protection of recipe during job queue/run Variable Parameter setting validation Traceability data for recipe use and parameter settings Standard Format for Recipe Body A possible future standard No schedule or specific plans for this

154 EDA Workshop Interface A Discussion in Equipment Supplier s 2004 Equipment Supplier s Forum M. Sakamoto/TEL No. 1

155 AGENDA Data Description E120 and E125 have defined the format However we need to have more definition for how to give the information such as components, parameters, etc. Data Quality We need to define accuracy of data and possible data collection/report frequency. Performance of Data Collection We need to identify true performance that is available on equipment Interoperability How we can make it happen. Equipment Supplier s Forum M. Sakamoto/TEL No. 2

156 Data Description Guide for Convention for Data Description is required If it is not provided, descriptions will be assigned in various manners by equipment suppliers The variation will harm the benefit that was expected on the standard Subjects Equipment Element descriptions Data Source identifications Parameter Naming Dynamic Object representations Equipment Supplier s Forum M. Sakamoto/TEL No. 3

157 {E125} Concept of Metadata METADATA Equipment Structure (based on CEM) Equipment Equipment Node Description Module Subsystem Module Subsystem Parameter Type and Unit State Machines and Events SEMI Object IO Device Exception Equipment Supplier s Forum M. Sakamoto/TEL No. 4

158 {E120} Equipment Node Attributes Class Attribute Name Description Form uid Unique ID of Namable object; includes uuid String: UUID Namable Equipment Element Subsystem / IO Device Module / Equipment name Human readable name; represents function in the equipment structure String: description Human readable description; enough information is required. String: elementtype Description of the Equipment Element; ex. nitrogen valve, Load Port String: supplier Supplier name or unknown String: make Hardware make (Brand Name) or unknown String: model Hardware model (Type) or unknown String: modelrevision Hardware model Revision or unknown String: function Role of Equipment Element in the equipment String: immutableid Serial number or unknown String: Abstract Module processname Description of the process; ex. coat, develop String: processtype Category of process recipetype Type of recipes that can be executed on the equipment String: Enumerated: Process or Measurement Equipment Supplier s Forum M. Sakamoto/TEL No. 5

159 {E125} Parameter Description 1 ParameterTypeDefinition 0..* 1 Parameter name description 1 0..* AssociatedParameter description 0..* refers to the Associated Parameter 1 1 Constraint it is provided only for Read/Write parameter 0..* name description definition 1 ParameterClassification Equipment Supplier s Forum M. Sakamoto/TEL No. 6

160 Example for Event Report EQUIPMENT PM-1 PM-2 Process Chamber PM-3 N 2 MFC Heater Block Chamber Temp. sourrceid eventid eventtime EVENT PM-1 PR-STRT T What should be given to the Parameter Name for MFC Set Point or MFC Actual? What name should be given to "sourceid" or "eventid"? MFC Set Point MFC Actual ParameterValue ParameterValue (value) (real value) (value) (real value) Equipment Supplier s Forum M. Sakamoto/TEL No. 7

161 Data Quality We need to define WHAT IS DATA QUALITY We need to define accuracy of data and possible data collection/report frequency. It is not just a computer technology Equipment Supplier s Forum M. Sakamoto/TEL No. 8

162 Study of the Data Accuracy To Factory Correlation to external event may be effected Timestamp Data Deviation Sample Timing is determined by the data collection mechanism such as poling Sample Timing Accuracy is made of Senor Accuracy and A/D Resolution Among Equipment Modules Sample timing Flicker Sampling Rate Correlation among events, traces may be effected Trace Data pitch may have variance Sampling Rate should be selected to the data frequency Sampled Value A/D Conversion Resolution Sensor Accuracy Equipment Supplier s Forum M. Sakamoto/TEL No. 9

163 Performance of Data Collection We need to define WHAT IS THE PERFORMANCE We need to identify true performance that is available on equipment It is not just a computer technology Equipment Supplier s Forum M. Sakamoto/TEL No. 10

164 Consideration of Interface A Performance MES Data Client Factory Network Performance Execution Controller Data Collection Internal Network Performance Module Controller Module Controller Performance Equipment Equipment Supplier s Forum M. Sakamoto/TEL No. 11

165 Interoperability How we can make it happen. Need system other than computer technology Kind of protocol to define the specs. Equipment Supplier s Forum M. Sakamoto/TEL No. 12

166 Interoperability.NET and Java Client 1 Client 2.NET Java.NET Java Equipment A Equipment B Equipment Supplier s Forum M. Sakamoto/TEL No. 13

167 e-manufacturing Workshop Summary 30 November 2004 Harvey Wohlwend SEMATECH, the SEMATECH logo, AMRC, Advanced Materials Research Center, ATDF, the ATDF logo, Advanced Technology Development Facility, ISMI and International SEMATECH Manufacturing Initiative are servicemarks of SEMATECH, Inc. All other servicemarks and trademarks are the property of their respective owners.

168 Interface A Standards 11/22/2004 j://stdpres/template.pot Slide 2 ISMI Member Companies #1 priority is access to data from equipment. This goal required Interface A standardization, a second equipment port for data access. Interface A Standards are Approved! Standard Description Common Equipment Model (CEM, E120) Equipment Self Description (EqSD, E125) Describes the physical structure of equipment Describes the data provided by equipment Equipment Client Authentication / Authorization (E132) Data Collection Management (E134) Restricts access to equipment services Defines and activates data collection plans

169 11/22/2004 j://stdpres/template.pot Slide 3 Key ISMI Member Company Messages 1. Fully functional 300 mm standards are assumed 2. Interface A (a.k.a. EDA) is now the KEY ISMI member company focus. Interface A standardization is complete and supplier community is implementing 3. The ISMI member companies are cooperating with suppliers early to assure mutual understanding and success 4. Interface A prototypes are being evaluated at ISMI 5. Leading OEMs are deploying e-diagnostics solutions (1000s of tools) and reporting significant benefit Fabwide coverage requires Interface A and C standardization 6. ISMI member companies will require Interface A on equipment purchased starting in 2005

170 11/22/2004 j://stdpres/template.pot Slide 4 What we are seeing Grand assumption of e-manufacturing Access to the required data makes decision making more effective Interface A suite of standards are complete Standards are implementable Standards are implemented Equipment modeling is a key new concept Performance needn t be an issue on properly architected solutions

171 11/22/2004 j://stdpres/template.pot Slide 5 EDA Discussion Forum What: Equipment Data Acquisition Interface Forum Who: IC makers, OEMs, suppliers, consultants, service providers, etc. Why: Industry participants can use this forum to pose questions, discuss issues, and document learnings related to the Interface A suite of standards Where: registration is required so s can be forwarded to participants Contact: Gino.Crispieri@ismi.sematech.org,

172 Equipment Data Acquisition Discussion Topics 11/22/2004 j://stdpres/template.pot Slide 6 Authorization and Authentication (E132 & E132.1) General Common Equipment Model (E120 & E120.1) General Equipment Self Description (E125 & E125.1) General Data Collection Management (E134 & E134.1) General 300 mm and EDA General XML and SOAP (SEMI E121, E128, & other XML specs) Performance General Other Category General

173 11/22/2004 j://stdpres/template.pot Slide 7 References SEMI EDA standards: E120, E125, E132, E134 downloads.semi.org/pubs/semipubs.nsf/webstandardssoftware!openview teams.semi.org/quickplace/stds_icdda/main.nsf e-diagnostics Guidebook, v2.0, ismi.sematech.org/emanufacturing/docs/guidebook.pdf EEC Guidelines, v2.5, ismi.sematech.org/emanufacturing/docs/eecguidebook.pdf EEC High-level Requirements for APC, ismi.sematech.org/emanufacturing/docs/eecreqs.pdf Prototyping, ismi.sematech.org/emanufacturing/prototype.htm Time Synchronization, A-ENG, Usage Scenarios, A-TR, Virus Protection, A-ENG,