eda workshop - sematech workshop agenda 13:00 enabling the e-manufacturing vision thomas chen -tsmc...

EDA WorkshopTaiwan 2004

EDA WorkshopTaiwan 2004

Gino CrispieriISMIMember Technical [email protected]

• • Slide 2

EDA Workshop AgendaEDA Workshop Agenda13: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 - ISMI15:00 Break15:15 XML Performance Study Gino Crispieri - ISMI15:40 RAP Standard Lance Rist - ISMI16:15 Challenges of EDA Implementation Mitch Sakamoto TEL16:45 Q&A 16:55 Workshop Summary Harvey Wohlwend – ISMI17:00 Adjourn

Enabling the e-Manufacturing Vision

Enabling the e-Manufacturing Vision

Thomas W.Y. Chen / 陳文耀[email protected] 30, 2004

2004/11/22 • j://stdpres/template.pot • Slide 2

AgendaAgenda• Key Messages• Motivation for Change• Interface Definitions• EDA Role in Manufacturing• Equipment Expectations• EDA Design Requirements• FAST II Roadmap• Interface C Status• Key Messages


Key ISMI Member Company MessagesKey ISMI Member Company Messages1. Fully functional 300 mm standards are assumed2. 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 ISMI5. 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


Environmental Pressures and Some Motivations for ChangeEnvironmental Pressures and Some Motivations for Change

Large Process Complexity+

2-3 Year Technology Nodes

High Cost of Mis-Processing (100’s to

1000’s of die)

Complex Equipment Design

+Fierce Competition for

Next Design Win

Time to Money for Install, Configure, & Qualification

Pay for Performance – High Cost of Downtime

Need to Focus Few Expert Resources on Solving Issues

vs. Finding Data

Innovation is Needed to Get the Right Data and have the Right Tools to Meet the Complex Needs of Future Technology


Interface RefresherInterface 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)

Factory Network

APC App 1

APC App 2

e-Diag App 1

OEE App 1

OEE App2

FDC App1

EE Applications

EEAccess Control

EE DataCollection

And StorageFICS/MES

•Equipment Control•WIP Tracking•Factory Scheduling

Global EE Data

Fire Wall

Interface C

Interface B SECS/GEM

Interface

Interface ASupplier Remote

Location

Remote monitoringRemote diagnosticsRemote de-bugging/ fixRemote sensingSpare parts Mgt.


EDA Role in ManufacturingEDA Role in ManufacturingDiagram is Conceptual Only

Diagnostics Utilization

Process Control

Process physics dataTool operational data

Suppliers deliverapplications

Suppliers deliverapplications

Suppliers, ICM, 3rd partydeliver applications

Suppliers, ICM, 3rd partydeliver applications

• 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 fromEDA

– Equipment Data needed for Factory Applications will come from the EDA Interface

Tool operational dataTool internal dataProcess physics dataTool operational data

EDA


Equipment ExpectationsEquipment Expectations

• Equipment internals behind the EDA interface must be designed toprovide 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

50-100 total scalar variables @ 3 Hz 50+ var’s per chamber

@ up to 10 Hz

Today’s ThroughputToday’s Throughput Future Throughput Expectations

Future Throughput Expectations

Subsystem A

Subsystem B …

E40

Equipment Control System

E87 E30 E90 E94

Job management Recipe execution Data CollectionHCI Motion Control

Subsystem A

Subsystem B …

E40

Equipment Control System

E87E30 E90 E94

Job management Recipe execution

HCI Motion Control

Today’s Equipment Internals

Today’s Equipment Internals

Dedicated High Throughput Data Bus

EDAInterface

Future Equipment Internals

Future Equipment Internals


Equipment Expectations - InternalEquipment 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


ISMI EDA Design RequirementsISMI EDA Design Requirements

SupplierResponsibility

ICM, 3rd Vendor,Supplier products

Equipment

ProprietaryServer

Proprietary,HSMS, other

non-EDA

Factory App Factory App

EDA

Equipment

Factory App Factory App

EDA

300mm Host

HSMS / GEM 300

No intermediate conversion server on the

equipment for EDA implementations

No historical data storage on the

equipment for EDA implementations

• 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


FAST II RoadmapFAST II Roadmap1Q04 2Q04 3Q04 4Q04 1Q05 2Q05 3Q05 4Q05 1Q06 2Q06 3Q06 4Q062003Nov. 2004

EDA Production Software Need/Plan Dates

E134 Data Collection

E132 Client A & A

E120 CEM

E125 Equipment Self- Description

• 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

2 3 1 1

2 3 1 1

2 3 1 1

2 3 1 11 3 1 1

1 3 1 1

1 3 1 1

1 3 1 1

Standardapproval date

TechnicalSpec

Device Makers Need DatesSuppliers Planned Dates

Interface C DefinitionInterface 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 3rd

party suppliers • Requirements, Implementation Guidelines, and

Assessment Checklist included in e-Diagnostics Guidebook, section 4.3.2 and chapters 11 and 12


Interface C Requirements SummaryInterface C Requirements Summary

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• Support data other than that directly produced by the

equipment

e-DiagnosticsServer

Full Proxy

•VPN or Internet

•HTTPS/443/ Web Services

DMZ

Tools (Interface A)

ApplicationsFactory information to enrich data

Servers

•HTTPS/443/Web Services UDDI•Other legacy protocols

Fab LDAP

Hardened Servers

•SSL

Supplier sideFactory side

1

AEC/APC Symposium, TaiwanInterface A

Interface A

Presented by Harsha Raj S.

e-Manufacturing InitiativesHCL Technologies

2

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

3

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

4

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 canaccess or collect data

5

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

HCL EDA Solution- Factory Perspective

SECS Port EDA Port

Host System (SECS/GEM)

EDA Client(s)

6

HCL Unified Factory Automation Framework

Control Interface

Messages

Configure Port SECS or EDA

SOAP/XML over HTTP

300MM Automation Framework

APC, FDC, EPT, e-Diagnostics..

Interface C

Interface-A Framework

EEC Applications MES / FCS Applications

HSMS over TCP/IP

Interface B

Messages

Data Interface

7

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

Authenticate, Discover, Define, Activate

Engi

neer

s

Data Collection

PlanEDA Client 1 (e-Diagnostics

System)

EDA

Client-side

EDA Client 2 (FDC System)

Equipment-side

RD

F Integration Layer

EquipmentFactory Applications

DCP Client Notification Services

(E134)

Browser UI

DCP

Tool data store

Equipment Data Acquisition System

Tool software

Equipment Self Description Services

(E125)

Tool Integration Layer

Data Collection Management Services

(E134)

Events Exceptions

TraceData

Buffering

1. Pre-defined Supplier DCP ’s2. Dynamically

defined FactoryDCP’s

HCL EDA Solution – Interface A Standards…

Equipment Client Authentication and

Authorization (E132)

Event Reports

ExceptionsReport

TraceReport

Data Collection

Report

8

9

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

10

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

11

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.

12

E125 Example Use case

Equipment returns its E120 CEM model along with events, alarms and parameters supported by each CEM node

“GetEquipmentNodeAssociation” Request (E125)

“GetExceptions” Request (E125) Equipment returns the

various exceptions supported

“DefinePlan” Request (E134)

Using GUI or Factory side APIs

Browser UI

DCPs can be defined based on the information provided by the Equipment

13

E125 Sample User Interface

Equipment Metadata Hierarchy displayed as an XML to show the equipment’s structure

14

E125 Sample User Interface…

Equipment Metadata obtained using E125 being used to create DCPs

15

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

16

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)

17

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)

18


Browser UI

“DefinePlan” Request

“ActivatePlan” Request

Data Collection Report

“NewData” Message

On-demand Activation


Client apps get data through Factory-side API

Equipment Level Security provides privilege checks for APIs

Equipment sends data collected as per activated DCP(s)

19

E134 Sample User Interface

20

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.

21

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

22

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.

23


Equipment performs security checks and authenticates

“EstablishSession” Request

Any E125 Request

Any E134 Request

Equipment verifies Session ID and performs appropriate privilege checks for each API

Equipment verifies Session ID


Browser UI

Equipment Response with Session ID

24

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

25

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

26

HCL EDA Solutions – APC

Equipment

EDA Interface

APC Application SetFDC R2R …

EDA Server1

EDA Server3

EDA Server1

SPCFactory clients

EDA Servers

EDA Enabled Equipment

HCL EDA Solutions – Utilization

Equipment

EDA Interface

Utilization Application SetEPT E10 …

EDA Server1

EDA Server3

EDA Server1

eDiagFactory clients

EDA Servers

EDA Enabled Equipment

27

28

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.

29

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.

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

31

Q & A

For more Information on HCL Solution Offerings, please visit: HCL-eManufacturing

or send e-mail [email protected]

Thank You

Acknowledgement:SEMATECH – e-Diagnostics , EDA, related standards and articlesProduct names and company names used in this presentation are for identification purposes only and may be trademarks or service marks of their respective companies

Interface A Usage ScenariosInterface A Usage Scenarios

Gino CrispieriMember Technical [email protected]

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 otherservicemarks and trademarks are the property of their respective owners.

11/22/2004 • EDA Scenarios • Slide 2

Purpose and OutputPurpose 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


Scenario Development ApproachScenario 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)• Messages with specific content

• Content– Functional sequences and unit scenarios per standard– General usage scenarios– Exception scenarios (next publication phase)


Classification of Usage Scenarios Document 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


EDA Base Component OverviewEDA Base Component Overview

Authentication Metadata Management

DCP Management

DCP Activation

DataReporting

ApplicationCertificates

EquipmentCertificates

QueryMetadata

DefineDCP

Query Active DCP

MetadataRevised

Query a DCP Content

ActivateDCP Event Report

Exception Report

Trace ReportEstablishSession - SSL

NotificationSetup

DeleteDCP

DeactivateDCP

GetACL

AddACLEntry

DeleteACLEntry

SecurityAdmin Setup

Get DefinedPrivilege

EstablishSession no SSL

SessionManagement

Get ActiveSessions

Set MaxSession

CloseSession

PersistSession

PingSession

Normal Use


EDA Base Component OverviewEDA Base Component Overview

AuthenticationMetadata

ManagementDCP

ManagementDCP

ActivationData

Reporting

AuthenticateFail

Defined DCP inconsistentW/ Metadata

DeleteNonexistent Plan

Delete Active Plan Activate An

Already Active Plan

Activate ErrorPerformance Down

Report FormatError

Report ContentsError

Session Establishment

Fail

Unauthorized Request


Activate Invalid/Nonexistent Plan

UnauthorizedRequest

SecurityAdmin Setup

Delete Nonexistent Entry

Invalid Role/Privilege Provided

Invalid Session/ No Session

SessionManagement



Add Duplicate Entry


Nonexistent Equipment Node



Exception Cases


Fundamental Sequences and Unit ScenariosFundamental 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


Admin or Client AuthenticationAdmin or Client AuthenticationEstablishSession

SessionStart Close Session

Admin or Client Authentication

Client Equipment

•EstablishSession()•EstablishSession()EstablishSession()

ACK

CloseSession()


E132-SEQ-01 Establish Session Request ServiceE132-SEQ-01 Establish Session Request Servicesd 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


E132-SEQ-01.1 Admin or Client AuthenticationDetail (SSL Enabled)E132-SEQ-01.1 Admin or Client AuthenticationDetail (SSL Enabled)

sd E132-SEQ-01.1 Authorization & Authentication



Client IDSession SecretClient ID Proof

AlgorithmEquipmentIDChallenge

Equipment Verifies ACL entryfor cl ientClient Authorized

Session Request(EndPoint)

Equipment Challenge

Client Authenticates

Equipment Authorizes(SessionID)

•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

orA subject in the ACL is equal to anyPrincipal that has assigned

privileges


E132-SCN-05 Administrator Closes Session owned by Another UserE132-SCN-05 Administrator Closes Session owned by Another User

sd E132-SCN-05 Admin Closes Session Owned by Another Client

:Administrator


«interface»:Equipment

Administrator mayclose other client sessions when equipment or application updates are needed 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.

EstablishSession(endPoint)

EstablishSessionResponse(sessionId)

GetActiveSessionRequest

GetActiveSessionResponse(activeSession)

CloseSessionRequest(activeSession)

SessionClosedNotification(sessionId)

AckCloseSessionResponse

CloseSessionRequest(sessionId)

CloseSessionResponse


SEMI E125 Equipment Self Description StandardSEMI E125 Equipment Self Description Standard

• Two groups of services have been defined:– Metadata Query Services– Metadata Management Service


MetadataMetadata

Metadata Management ServicesMetadata Management Services

Client Equipment

MetadataRevised

NotifyOnRevisions()

GetLatestRevision()

MetaDataRevised()

Establish Session NotifyOnRevisions()Session

Start

• MetadataRevised()• NotifyOnRevisions()• SetNotifyOnRevisions()• GetLatestRevision()

Metadata Notification Services

• MetadataRevised()• NotifyOnRevisions()• SetNotifyOnRevisions()• GetLatestRevision()

MetadataRevised()

GetLatestRevision()

Close Session


E125-SCN-02 Metadata Change Notification Scenario

E125-SCN-02 Metadata Change Notification Scenario

sd E125-SCN-02 Metadata Notification Scenario

Metadata Revised



Client establishes a session, queries the equipment forits latest metadata revisiondate and asks to be notified of anychanges

Equipment notifies client thatthe metadata has changed



GetLatestRevisionRequest

GetLatestRevisionResponse(response)

NotifyOnRevisionRequest(notification)

NotifyOnRevisionsResponse

MetadataRevisedNotification(revision)

Ack

CloseSessionRequest(sessionId)



SEMI E134 Data Collection Management StandardSEMI E134 Data Collection Management Standard

• Defined Groups of Services Are:– DCP Management Services– DCP Query Services– DCP Performance Warning Services


DCPDCPDCP Management ServicesDCP Management Services

Client Equipment

DefinePlan()

TriggeroccursNewData()

DeactivatePlan()

ActivatePlan()

NewData()

Authenticate Metadata CreateDCP Activate Data

Report DeactivateSessionStart Close Session

Data Collection Plan Management

• DefinePlan()•Event, Exception, Trace

• ActivatePlan()• DeactivatePlan()• DeletePlan() • GetActivePlanIDs()• GetPlanDefinition()• GetDefinedPlanIDs()

• DefinePlan()•Event, Exception, Trace

• ActivatePlan()• DeactivatePlan()• DeletePlan() • GetActivePlanIDs()• GetPlanDefinition()• GetDefinedPlanIDs()


DCP Management ServicesDCP Management Services

• 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 Deactiv atePlan()



DeactivatePlanRequest(planId, terminate)

DeactivatePlanResponse(deactivatedPlan)

sd E134-SEQ-04 DeletePlan()



DeletePlanRequest(planId)

DeletePlanResponse(deletedPlan)


DCP Recovery from Performance WarningDCP Recovery from Performance Warning

Client Equipment

Report Data 1Activate Plan 1

PerformanceWarning()

Reporting Data 1-2

PerformanceIssue

Deactivate could be done by either client or equipment

Deactivate Plan 2

Report Data 2

Activate Plan 2

Report Data 1Report Data 1


E134-SCN-04 Performance Warning with Performance Restored

E134-SCN-04 Performance Warning with Performance Restored

sd E1324-SCN-04 Performance Warning with Performance Restored



Client establishes session, queries for all defined DCPs in the equipment and starts activating DCPs

Equipment starts reporting data from activated DCPs

Client continues activating 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

Client deactivates remaining DCPs and closes its session



GetDefinedPlanIdsRequest

GetDefinedPlanIdsResponse(definedPlans)

ActivatePlanRequest(planId)

ActivatePlanResponse(activatedPlan)

NewDataNotification(dataCollectionReport)Ack

ActivatePlanRequest(planId)


PerformanceWarning(warning)Ack

DCPDeactivationNotification(deactivationNotice)Ack

PerformanceRestoredNotification(status)Ack

NewDataNotification(dataCollectionReport)Ack

DeactivatePlanRequest(planId)DeactivatePlanResponse(deactivatedPlan)

CloseSessionRequest(sessionId)CloseSessionResponse


DCPDCP

Equipment Restarts DCP with PersistenceEquipment Restarts DCP with Persistence

Client Equipment

ActivatePlan()

Trigger occursNewData()

DCPHibernation()Equipment is going offline

Equipment is back online

Trigger occursNewData()

SessionPing()

SessionFrozen()Client suspends data collection and waits for session to come back


General Usage ScenariosGeneral 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


SCN-02 Single Client Multiple DCP ActivateSCN-02 Single Client Multiple DCP ActivateAuthenticate Create

DCP 1 Activate DataReport Deactivate Close

Session

CreateDCP 2 Activate Data

Report Deactivate

ClientStart

Client A EquipmentAuthenticate & Create Session

Create & Activate DCP 1

Create & Activate DCP 2

Data Report for DCP1


Deactivate DCP 1


Deactivate DCP 2

Close Session


SCN-03 Multiple Client Single DCPSCN-03 Multiple Client Single DCP

Authenticate

Metadata CreateDCP

Activate

DataReport Deactivate

CloseSession

DataReport Deactivate

Client AStart

Client BStart

Authenticate CloseSession

GetDCP


Client B

Create DCP

Activate DCP

Data Report

Deactivate DCP

Close Session

Authenticate & Create Session

Get DCP Definition & ID

Activate DCPData Report

Deactivate DCP

Close SessionData Report

Only one data report sent out from EQP to many clients at the same time.

Only one data report sent out from EQP to many clients at the same time.

The DCP can not be deactivated until the last client sent deactivate DCP message.


SCN-04 Multiple Client Multiple DCPSCN-04 Multiple Client Multiple DCP

Authenticate


Report Deactivate CloseSession


Report Deactivate

Client AStart

Authenticate

Client BStart

CloseSession


Client B

Request Metadata

Create DCP 1

Activate DCP 1

Data Report

Deactivate DCP 1

Close Session

Authenticate & Create Session

Request Metadata

Create DCP 2

Activate DCP 2

Data Report

Deactivate DCP 2

Close Session

Note that the Request Metadataand Create DCP are optional to client(s).


SCN-05 DCP Deactivation with more than one Client Receiving Data (Terminate=True)

SCN-05 DCP Deactivation with more than one Client Receiving Data (Terminate=True)

sd SCN-05 DCP Deactiv ation with More than One Client Receiv ing Data



«interface»ApplicationII

Client1 establishes session, creates and activates a DCP Client2

establishes a session, queries equipment aboutdefined DCPs, selects the one that is currently active, and activates it

Equipment sends data report to Client1

Equipment sends data report to Client1 and Client 2

Client1 deactivates DCP and terminates all instances using the terminate argument set toTRUE

Equipment notifies and deactivates DCP reporting



DefinePlanRequest(newPlan)

DefinePlanResponse(definedPlan)EstablishSessionRequest(endPoint)

EstablishSessionReponse(sessionId)ActivatePlanRequest(planID)

ActivatePlanResponse(activatedPlan) GetDefinedPlanIdsGetDefinedPlanIdsResponse(definedPlans)

GetPlanDefinitionRequest(planId)

GetPlanDefinitionResponse(planDefinition)NewDataNotification(dataCollectionReport)Ack ActivatePlanRequest(planId)


NewDataNotification(dataCollectionReport)NewDataNotification(dataCollectionReport)AckAck

DeactivatePlan(planId, terminate)DCPDeactivationNotification(deactivationNotice)

AckDeactivatePlanResponse(deactivatedPlan)

CloseSessionRequest(sessionID)



Next StepsNext Steps

• Publication and availability of EDA Usage Scenarios – Tech Transfer Document at SEMATECH – ISMI public web

site• http://www.sematech.org/docubase/abstracts/4579atr.htm

• 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

• ContactGino Crispieri

[email protected](512)-356-7547

Factory Automation Standards Tracking (FAST):

FAST II Survey EDA ResultsDecember 2004

Jackie Ferrell, [email protected]

Harvey Wohlwend, ISMI [email protected]

Lance Rist, ISMI [email protected]

Jeff Silveira, [email protected]

FASTII 200411072

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.

FASTII 200411073

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

FASTII 200411074

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

FASTII 200411075

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

FASTII 200411076

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

FASTII 200411077

Survey CategoriesDevice 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

RD

R

RF

F

O

W

SupplierImplemented• 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 200411078

Analysis of Survey ResultsUsage/Delivery

RD RF F O WR

Priority Value (# of responses)

Priority* Priority Values: 3 = High 2 = Medium 1 = Low

Weighted Average = Priority values ÷ # of responses

Timing1Q04 2Q04 3Q04 4Q04 1Q05 2Q05 3Q05 4Q05 1Q06 2Q06 3Q06 4Q062003

Dat

a A

cqui

sitio

n

FAST II Roadmap EDA Production Software


E132 Client A & A

E120 CEM


FASTII 200411079

Communication Standards - Suppliers

0123456789

1011121314151617

E5 SECS II E30 GEM E30.1 ISEM E30.5 MSEM E37 HSMS

# Eq

uipm

ent P

latfo

rms

Communication Standards - Device Makers

0123456789

10111213141516

E5 SECS II E30 GEM E30.1 ISEM E30.5 MSEM E37 HSMS

# D

evic

e M

aker

sCommunication Standards

RD RF F O WR

SECS, GEM, HSMS are the basis of most implementations

The original specific equipment models (SEM’s) are used very little

FASTII 2004110710

Standards Not Widely Used - Suppliers

0123456789

101112

E32 MaterialMovement

E53 Event reporting E98 OBEM E81, 86, 96, 97, 102,105 CIM FW

# eq

uipm

ent p

latfo

rms

Standards Not Widely Used - Device Makers

0123456789

101112

E32 MaterialMovement

E53 Event reporting E98 OBEM E81, 86, 96, 97, 102,105 CIM FW

# de

vice

mak

ers

Standards Not Widely Used

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?

RD RF F O WR

FASTII 2004110711

Integration and Automation (I&A)

300 mm I&A standards provide base functionality

Most are being delivered at a level sufficient for operations

Integration and Automation Standards - Device Makers

0123456789

10111213141516

E39 OSS E40 ProcessJob

E87 CarrierMgmt

E90 SubstrateTracking

E94 ControlJob

E109 ReticlePod Mgmt

# D

evic

e M

aker

s

Equipment Integration and Automation Standards - Suppliers

0123456789

101112131415

E39 OSS E40 ProcessJob

E87 CarrierMgmt

E90 SubstrateTracking

E94 ControlJob

E109 ReticlePod Mgmt

# Eq

uipm

ent P

latfo

rms

RD RF F O WR

FASTII 2004110712

Equipment Data Acquisition - Suppliers

012

3456

78

E120 CEM E125 Equip Self-Description

E132 Client A&A E134 Data Collection

# eq

uipm

ent p

latfo

rms

Equipment Data Acquisition - Device Makers

0

1

2

3

4

5

6

7

8

E120 CEM E125 Equip Self-Description

E132 Client A&A E134 Data Collection

# D

evic

e M

aker

sEDA Standards

RD RF F O WR

3.0 (4)

2.8 (5)

3.0 (4)

2.67 (6)

2.5 (4)

2.67 (6)

3.0 (4)

2.67 (6)

Priorities: 3 = High 2 = Medium 1 = Low

FASTII 2004110713

FAST II Roadmap1Q04 2Q04 3Q04 4Q04 1Q05 2Q05 3Q05 4Q05 1Q06 2Q06 3Q06 4Q062003Nov. 2004


E132 Client A & A

E120 CEM


EDA Evaluation Software Need/Plan Dates

1 1 1 1 1

1 1 1 1 1

1 2 1 1

1 2 1 1

1

11 1 4

1 41

1 1 4

1 1 4

1

1

1

1

• 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


TechnicalSpec


FASTII 2004110714

FAST II Roadmap1Q04 2Q04 3Q04 4Q04 1Q05 2Q05 3Q05 4Q05 1Q06 2Q06 3Q06 4Q062003Nov. 2004

EDA Production Software Need/Plan Dates


E132 Client A & A

E120 CEM


• 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

2 3 1 1

2 3 1 1

2 3 1 1

2 3 1 11 3 1 1

1 3 1 1

1 3 1 1

1 3 1 1


TechnicalSpec


FASTII 2004110715

FAST and FAST II Roadmaps Compared

Device Makers Need Dates

2003 1Q04 2Q04 3Q04 4Q04 1Q05 2Q05 3Q05 4Q05 1Q06 2Q06 3Q06 4Q06

Suppliers Planned Dates

Make-up of responders

slightly different between the 2

surveys

Nov. 2004

E132 Client A & A

Device MakersSuppliers

E120 CEM

E125 Equipment Self-Description


• Device maker range of need dates is narrowing

• Need dates align with standards approval targets

• Latest deployment dates are stable

EDA Production Software

Standardapproval

Technical Spec

FAST IIFAST

FASTII 2004110716

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

FASTII 2004110717

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

List of SEMI Standards for ReferenceEquipment Communication

and ControlE5 SECS II E30 GEM E30.1 Inspection SEME30.5 Metrology SEME32 Material MovementE39 Object Services (OSS)E40 Process JobE42 Recipe ManagementE53 Event reportingE58 ARAMS (Automated E10)E87 Carrier Management E90 Substrate TrackingE94 Control JobE98 Object-Based Equipment ModelE109 Reticle Pod MgmtE116 Equipment Productivity TrackingE120 Common Equipment ModelE125 Equip Self-DescriptionE126 Equip Quality Info Parameters (EQIP)E132 Client Authentication & AuthorizationE134 Data Collection3442 Recipe Adjustable Parameters3562 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 TechnologyE4 Message Transfer (SECS I)E37 High-speed Message ServicesE121 XML Style & UsageE128 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

1Q04 2Q04 3Q04 4Q04 1Q05 2Q05 3Q05 4Q05 1Q06 2Q06 3Q06 4Q06


Nov. 2004 2003


E132 Client A & A

E120 CEM


Make-up of responders slightly different between

the 2 surveys

EDA Evaluation Software

• Range of device maker evaluation SW need dates narrowed • Need dates moved out to align with standards target dates

StandardapprovalFAST IIFAST

Device Makers Need DatesDevice Makers Technical SpecSuppliers Planned DatesSuppliers

FASTII 2004110720


1Q04 2Q04 3Q04 4Q04 1Q05 2Q05 3Q05 4Q05 1Q06 2Q06 3Q06 4Q06Nov. 2004 2003


E132 Client A & A

E120 CEM


Make-up of responders slightly different between

the 2 surveys

EDA Evaluation Software

• Range of device maker evaluation SW need dates narrowed • Need dates moved out to align with standards target dates

StandardapprovalFAST IIFAST

Device Makers Need DatesDevice Makers Technical SpecSuppliers Planned DatesSuppliers

FASTII 2004110721

Industry e-Manufacturing FAST RoadmapProduction Software Need Dates

EPT-E116

Dat

a U

tiliz

atio

nD

ocs.

PCS-E133

2004 2005

Data Quality-3652

Dat

a A

cqui

sitio

n

RaP-3442

3Q2Q1Q 4Q 3Q2Q1Q 4Q2006

3Q2Q1Q 4Q

Standard/document approval date

OBEM-E98

IC Maker’s priorities

Supplier’s prioritiesHigh Medium Low

Medium Low

Interface A

Sensor Bus-E54

Interim I/F A-PR8

Interface C Guidelines

Integrated Measurement-E127

Electronic Documentation-E36.1

2 1

1 2 1

3 1

2 2 1

1 1 4

1 1

1 2 2 1 1

1 1 1 2 1

1 2 1

1 1 2 1 1

1 17+

IC Makers +

10 Suppliers in

put

High

Nov 2003

21

FASTII 2004110722

Industry e-Manufacturing FAST RoadmapEvaluation Software Need Dates

EPT

Integrated Measurement

Dat

a U

tiliz

atio

nD

ocs.

2004 2005D

ata

Acq

uisi

tion

Interim I/F A

RaP

3Q2Q1Q 4Q 3Q2Q1Q 4Q2006

3Q2Q1Q 4Q

Standard/document approval date

Data Quality

Sensor Bus

OBEM

PCS

IC Maker’s priorities

Supplier’s priorities

2.01 – 3.00

Medium Low

2 1

1 2

2 2 1

1 11 3

1 1 1 3

2 3 2

2 1 2 1

3 1

1 2

2 2 1 1

2.01 – 3.00 Medium LowHigh

Interface A

Interface C Guidelines

Electronic Documentation

E132, E134, E125, E120

PR8-0303

3652

E54

E116

3442

E127

E98

E36.1

7+IC M

akers +

10 Suppliers in

put

High

E133

Nov 2003

22

FASTII 2004110723

Specific Communication Device Models - Device Makers

02468

10121416

Mass FlowDevices

DeviceNet Seriplex ProfibusDP Modbus/TCPTCP/IP

In-SituParticleMonitor

EndpointDevices

CC-Link Ethernet/IP

# D

evic

e M

aker

s

Specific Communication Device Models - Suppliers

02468

10121416

Mass FlowDevices

DeviceNet Seriplex ProfibusDP Modbus/TCPTCP/IP

In-SituParticleMonitor

EndpointDevices

CC-Link Ethernet/IP

# eq

uipm

ent p

latfo

rms

Specific Communication Device Models

RD RF F O WR

Only a few device makers require a particular Specific Communication Device Model

FASTII 2004110724

Recipe & Productivity StdsRecipe Management- Device

Makers

0

1

2

3

4

5

6

7

8

9

10

11

E42 RecipeManagement

3442 RaP

# D

evic

e M

aker

s

Productivity Standards - Device Makers

0

1

2

3

4

5

6

7

8

9

10

11

E58 ARAMS E116 EPT

# D

evic

e M

aker

sRecipe Management Standards -

Suppliers

0

1

2

3

4

5

6

7

8

9

10

11

E42 RecipeManagement

3442 RaP

# Eq

uipm

ent P

latfo

rms

Productivity Standards - Suppliers

0

1

2

3

4

5

6

7

8

9

10

11

E58 ARAMS E116 EPT

# Eq

uipm

ent P

latfo

rms

2.5 (4)

1.75 (4)

2.2 (5)

2.33 (3)

Recently approved RaP replaces little used E42

Newer EPT has more support than ARAMS; however, both standards are used

RD RF F O WR

FASTII 2004110725

Automated Material Handling

E82 and E88 are specific to AMHS suppliers

Widely used E84 Parallel I/O links production equipment to AMHS

Automated Material Handling Standards - Device Makers

0123456789

101112131415

E84 Parallel I/O E82 IBSEM E88 Stocker SEM

# D

evic

e M

aker

s

Automated Material Handling Standards - Suppliers

0123456789

101112131415

E84 Parallel I/O E82 IBSEM E88 Stocker SEM

# Eq

uipm

ent P

latfo

rms

RD RF F O WR

FASTII 2004110726

Internal EquipmentInternal Equipment Standards - Device Makers

0123456789

1011

E38 Cluster ToolModule/CTMC

E54Sensor/Actuator

E95 HumanInterface

E99 Carrier ID RW E118 Wafer ID

# D

evic

e M

aker

s

Internal Equipment Standards - Suppliers

0123456789

1011

E38 Cluster ToolModule/CTMC

E54Sensor/Actuator

E95 HumanInterface

E99 Carrier ID RW E118 Wafer ID

# eq

uipm

ent p

latfo

rms

RD RF F O WR

FASTII 2004110727

Emerging Standards - Suppliers

0123456789

101112

3562 Data Quality E126 EQIP E127 IntegratedMetrology

E133 PCS

# eq

uipm

ent p

latfo

rms

Emerging Standards - Device Makers

0123456789

101112

3562 Data Quality E126 EQIP E127 IntegratedMetrology

E133 PCS

# D

evic

e M

aker

s

New and Emerging Standards

2.0 (3)

2.25 (4) 2.4 (5)

2.33 (3) 1.67 (3)

2.25 (4)

3.0 (1)

2.0 (1)

RD RF F O WR Priorities: 3 = High 2 = Medium 1 = Low

Data Quality needed. It is not yet well defined

One device maker provided need date (2006). This appears to be a good idea that needs to mature

FASTII 2004110728

FAST II Roadmap Emerging Stds Evaluation Software Need / Plan Dates

E116 EPT

3442 RaP

E127 Integ Meas

1Q04 2Q04 3Q04 4Q04 1Q05 2Q05 3Q05 4Q05 1Q06 2Q06 3Q06 4Q06

E116 EPT

3442 RaP

E127 Integ Meas

Emerging Stds Production Software Need / Plan Dates

3652 Data Quality

E126 EQIP

E126 EQIP

3652 Data Quality

2003Nov. 2004

3

1 1

12

1 1

1

1 1 2

1 1 1 1

1

1 1

21 1

2 1

1 1

1

1

111

111

3 12

1 12

12

11

1

1

1

Device Makers Need Dates Standardapproval dateSuppliers Planned Dates

FASTII 2004110729

XML Standards - Suppliers

0123456789

1011121314

E121 XML Style & Usage E128 XML Messages E36 Equip Info Tag

# Eq

uipm

ent P

latfo

rmsXML Standards - Device Makers

0123456789

1011121314

E121 XML Style & Usage E128 XML Messages E36 Equip Info Tag

# D

evic

e M

aker

sXML Standards

2.4 (5)2.4 (5)

2.0 (3) 2.0 (3)

2.0 (1)

XML Technology is entering the semiconductor industry.

E36 - Recently modified to include XML tagging, Needs marketing if it is to succeed

RD RF F O WR

Measuring the Performance of XML-Based Data Standards

Measuring the Performance of XML-Based Data Standards

Gino [email protected]

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 otherservicemarks and trademarks are the property of their respective owners.


ContentContent

• NIST Marshalling Performance Testing– Results based on Castor and JIBX XML Binding

Software• XML SOAP Package Performance

Measurement– JavaSOAP1– JavaSOAP2– C++SOAP

• Lessons Learned


Common Manufacturing EnvironmentCommon 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


Equipment RequirementsEquipment 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

• http://ismi.sematech.org/emanufacturing/docs/EECReqs.pdf


What is Marshaling?What is Marshaling?

E134 Message example


Data Collection ReportData Collection Report

plan Id

Report

Event Report

Trace Report

Exception Report

Data Collection ReportplanIdbufferStartTimebufferEndTimereportTime

1

1..*

{ordered}

Data Collection Report

EventReport

EventReport

ExceptionReport

TraceReport

bufferEndTimebufferStartTime

Consumer

send reportat (report Time)send report

at (report Time)

The consumer should be identified by authenticated session.

The consumer should be identified by authenticated session.

E134

IntervalInMinutes

NIST XML Marshalling Testing

NIST XML Marshalling Testing

Eric Simmons, Art Greisser – NISTGino Crispieri - ISMI


Hardware SetupHardware 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


Testing FlowchartTesting Flowchart

Calculate and recordunmarshalling time

Record Start Time

Call Marshalling

Record Stop Time

Calculate and RecordMarshalling Time

Record Stop Time

Call Unmarshalling

Record Start Time

Collect Garbage

Calculate and RecordUnmarshalling Time

Record Start Time

Call Marshalling

Record Stop Time

Calculate and RecordMarshalling Time

Record Stop Time

Call Unmarshalling

Record Start Time

Java collects garbage before running the test

Unmarshal from XML instance, using mapping file, into Java objects

Marshal data from Java objects into XML instance using mapping file


Castor XML PerformanceCastor XML Performance

1-1000f8 no-X

0

50

100

150

200

250

300

350

400

450

500

0 100 200 300 400 500 600 700 800 900 1000

Number of Parameter Values (average of 99 tests)

Tim

e (m

S)

Marshalling

Un-Marshalling


JIBX Performance DataJIBX Performance Data

0

100

200

300

400

500

600

1 50 500 5000 50000

UnmarshallMarshall


Integer vs Double Precision Parameter Value PerformanceInteger vs Double Precision Parameter Value Performance

Tim

e (m

S)

0

100

200

300

400

500

600

700

800

1 11 21 31 41 51 61 71 81 91

Integer UnmarshallingInteger MarshallingDouble UnmarshallingDouble Marshalling

Garbage collection

Run Number


NIST Summary of ResultsNIST 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++)

SOAP and XML Performance Measurements

SOAP and XML Performance Measurements

Jean Francois Dufuor & EugenKender – CenterPointGino Crispieri - ISMI


XML SOAP Package PerformanceXML SOAP Package Performance• Three SOAP packages were analyzed by 3rd 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


MeasurementsMeasurements

Field Defined DATATIMERECEIVER The time required by the receiver application

to process the data. In the case of our testing, the data is written to a file.

XMLTIMERECEIVER The time required by the receiver to parse the XML document and to receive the message.

DATATIMESENDER The time required by the sender to generate the values for transmission.

XMLTIMESENDER The time required by the sender to construct the XML document and send the message.

CPULOAD CPU Load as a percentage. Obtained from the operating system.

PAGEFAULTRATE Page Faults / second. Obtained from the operating system.


Hardware SpecificationsHardware 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

10.000rpm, 4MB Cache ST336607W– O/S Windows 2000 SP 4 and Linux


StatisticsStatistics• 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


XML Time Receiver C++SOAPXML Time Receiver C++SOAPXMLTIMERECEIVER: C++SOAP to C++SOAP

0

50

100

150

200

250

300

10 50 100 500 1000 5000 10000Values / Message

Tim

e (m

s)

Windows receiving from Windows Linux receiving from Linux Linux receiving from Windows Windows receiving from Linux


XML Time Receiver JavaSOAP1XML Time Receiver JavaSOAP1XMLTIMERECEIVER: JavaSOAP1 to JavaSOAP1

0

50

100

150

200

250

300

350

400

450

10 50 100 500 1000 5000 10000

Values / Message

Tim

e (m

s)

Windows receiving from Windows Linux receiving from Linux Linux receiving from Windows Windows receiving from Linux


XML Time Receiver Java-SOAP2XML Time Receiver Java-SOAP2XMLTIMERECEIVER: JavaSOAP2 to JavaSOAP2

0

20

40

60

80

100

120

140

160

180

200

10 50 100 500 1000 5000 10000

Values / Message

Tim

e (m

s)

Windows receiving from Windows Linux receiving from LinuxLinux receiving from Windows Windows receiving from Linux


Total Time C++SOAPTotal Time C++SOAPDATATOTAL: C++SOAP to C++SOAP

0

100

200

300

400

500

600

10 50 100 500 1000 5000 10000

Values / Message

Tim

e (m

s)

Windows vs. Windows Linux vs. Linux Linux vs. Windows Windows vs. Linux


Total Time JavaSOAP1Total Time JavaSOAP1DATATOTAL: JavaSOAP1 to JavaSOAP1

0

500

1000

1500

2000

2500

3000

3500

10 50 100 500 1000 5000 10000

Values / Message

Tim

e (m

s)



Total Time JavaSOAP2Total Time JavaSOAP2DATATOTAL: JavaSOAP2 to JavaSOAP2

0

500

1000

1500

2000

2500

3000

10 50 100 500 1000 5000 10000

Values / Message

Tim

e (m

s)



XML Performance Same PackageXML Performance Same PackageMessages per second: C++Soap to C++Soap

050

100150200250300350400450500550600650700750800

Values / Message

Num

ber o

f mes

sage

s

Windows sending to Windows 324.343948 250.285833 194.132079 69.7130063 40.1320888 8.1066158 4.06308451

Linux sending to Linux 562.111135 405.830781 306.406103 104.544988 61.6736345 12.7936984 6.42832169

Windows sending to Linux 280.510393 249.037135 232.987552 93.6016512 57.8209459 12.9424816 6.10916836

Linux sending to Windows 511.279007 353.077572 247.483657 73.9440256 37.0851322 7.48746499 3.76672295

10 50 100 500 1000 5000 10000


XML Performance Alternate PackageXML Performance Alternate Package Linux vs. Linux Sender: Interoperability

0

500

1000

1500

2000

2500

3000

10 50 100 500 1000 5000 10000

Values / Message

Tim

e (m

s)

Java2S sending toCsoap Csoap sending to Java2S CSoap sending to Java2S

Java2S sending to Java1S Java1S sending to CSoap CSoap sending to Java1S


Multi-thread Environment TestMulti-thread Environment TestMeasure of the average time needed to send one message in a multithreaded

environment with C++soap, 1 sender node and 1 receiver node

0.00

2000.00

4000.00

6000.00

8000.00

10000.00

12000.00

Number of threads

Elap

sed

send

er ti

me

(ms)

100 datapoints 3.26 7.64 12.88 16.16 18.77 30.54 48.58 96.09 167.20

1000 datapoints 16.21 39.56 62.92 84.77 107.44 173.86 283.82 542.97 1049.06

10000 datapoints 155.56 406.80 670.82 949.84 1221.20 2093.24 3445.15 7113.09 12240.74

1 3 5 7 9 15 25 50 99


Messages send versus Number of Threads

Messages send versus Number of Threads

Measure of the efficiency difference between the three main scenarios with C++Soap

0,00

100,00

200,00

300,00

400,00

500,00

600,00

700,00

Nb of datapoints

Mes

sage

s se

nt p

er s

econ

d

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

100,00 1000,00 10000,00


CPU Load SenderCPU Load SenderC++SOAP to C++SOAPJavaSOAP to JavaSOAP

CPU Load SenderJavaSOAP, C++SOAP

0

10

20

30

40

50

60

70

80

90

Windows Sending toWindows

Linux Sending to Linux Windows Sending to Linux Linux Sending to Windows Average of All


CPU Load ReceiverCPU Load ReceiverCPU Load ReceiverJavaSoap, C++soap

0

20

40

60

80

100

120

Windows Sending toWindows

Linux Sending to Linux Windows Sending to Linux Linux Sending to Windows Average of All

C++Soap to C++SoapJavaSoap to JavaSoap


CPU Usage Multi-threadingCPU Usage Multi-threadingMeasure of the processor usage with JavaSOAP

(Multiple sender nodes - 1 receiver node)

0,00

10,00

20,00

30,00

40,00

50,00

60,00

70,00

80,00

90,00

100,00

100 1000 10000

Nb of datapoints

CPU

(%)

3 threads - Rcv 5 threads - Rcv 3 threads - Snd 5 threads - Snd


CPU usage ResultsCPU 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


InteroperabilityInteroperability• SOAP packages provide code generation utilities that take a

WSDL and schema documents and creates sending/receivingcode (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>884.27734375</F8>

– SOAP Message from C++SOAP:• <ns2:TR collectionTime="1970-01-02T04:46:39+02:00">

<ns2:PV><ns2:F8>884.27734375</ns2:F8>


Lessons LearnedLessons 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 http://www.ws-i.org

– 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 onefor implementation


ConclusionConclusion• 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

Developments In

Recipe Management

Developments In

Recipe Management

Lance RistISMI512-356-3153

e-Manufacturing Workshop


All Clipart Copyright © 1998 Corel Corporation and its licensors. All rights reserved.

2

OutlineOutline• 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

3

Equipment Recipe Management TodayEquipment Recipe Management Today• Recipe management today is primitive

– Related SEMI Standards are 15-20 years old– Implementations are limited

to upload/download/delete– No commercially successful

alternative has been available

4

Equipment Recipe Management TodayEquipment 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)

5

Equipment Recipe Management TodayEquipment 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!

6

A New SolutionA 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?

7

Recipe Content Can Be TrustedRecipe 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), orb) 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

8

Process Control is EnhancedProcess 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

9

Number Of Recipes ReducedNumber 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

10

Multi-Part Recipes SupportedMulti-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

Master PDE

ReferencedPDE’s

PDE

PDE PDE

PDE PDE PDE

PDE PDE

Process Job

PDE’s reference other PDE’s:subrecipes, utilities, etc.

RCPSPEC/PPID

VariableParameterso PDEparam1o PDEparam2o etc…

PDE = Process Definition ElementRecipe Component

11

Traceability of Recipes EnabledTraceability 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

12

RaP Value PropositionRaP 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

13

RaP Conceptual View

RaP Conceptual View

• Three entities defined– Factory (FICS)– Equipment– Recipe Editor

• Interfaces definedA. Equipment – FactoryB. Editor – FactoryC. Equipment – Editor

• Standard Protocol not required

• RaP defines eight communication services Transfer Manage Verify

getPDE() getPDEdirectory() verifyPDE()requestToSendPDE() deletePDE() resolvePDE()sendPDE() getPDEheader()

EQUIPMENT RECIPE EDITOR

FICS

Station Controller

Recipe Manager

Data BaseAPC

settings history

A B

C

14

RaP Adds Public Recipe HeaderRaP 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• …

PDEbody<<Executable Part>>

Content is not specifiedand may be kept private

• Target Equipment• Antecedents• PDE References• External Parameters• User Info

15

All recipe components are PDE’s

PDE Object ModelPDE Object Model

ReferencedPDE

id

0..*

AntecedentData

uidnamegidgroupNamedescriptionauthorcreateDatecreateNode 0..*

PDEheader

uidnamegidgroupNamedescriptiontypeexecutablemaxAntecedentscreateDatecreateNodeauthoruserInfosupplierInfo

PDEparameter

namedescriptionunitsrelatedParametersdefaultValueinputBoundaryTypeinputBounds

ExecutionTarget

identifiersuppliermakemodelrecipeTypes

0..* 0..*

0..*

PDE

checksum

PDEbody

0..1

1

PDEbodyReference

specificationbodyChecksum

0..1

xor

16

Transition To RaPTransition 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

17

RaP Task Force ActivitiesRaP Task Force Activities• SEMI Doc. 3442A (RaP) approved Oct. 2004

– 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

No. 1Equipment Supplier’s Forum M. Sakamoto/TEL

EDA Workshop

Interface A Discussionin Equipment Supplier’s Forum

@SEMICON/Japan2004


AGENDAData Description

E120 and E125 have defined the formatHowever we need to have more definition for how to give the information such as components, parameters, etc.

Data QualityWe need to define accuracy of data and possible data collection/report frequency.

Performance of Data CollectionWe need to identify true performance that is available on equipment

InteroperabilityHow we can make it happen.


Data Description

Guide for Convention for Data Description is required

If it is not provided, descriptions will be assigned in various manners by equipment suppliersThe variation will harm the benefit that was expected on the standard

Subjects Equipment Element descriptionsData Source identificationsParameter NamingDynamic Object representations


{E125} Concept of MetadataMETADATA

SEMI Object

Exception

Parameter

Equipment Node Description

Type and Unit

IO Device

Subsystem Subsystem

Module Module

…

…

Equipment

Equipment Structure (based on CEM)

State Machines and Events


{E120} Equipment Node AttributesClass Attribute Name Description Form

uid Unique ID of Namable object; includes uuid String: UUID

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:

Subsystem / IO

Device

immutableId Serial number or “unknown” String:

processName Description of the process; ex. “coat”, “develop” String:

processType Category of process Enumerated: Process or Measurement

Module / Equipm

ent

recipeType Type of recipes that can be executed on the equipment String:

Abstract M

oduleEquipm

ent Element

Nam

able


{E125} Parameter Description

Parameternamedescription

0..*

0..*

0..*

1

ParameterTypeDefinition

AssociatedParameterdescription

Constraint

namedescriptiondefinition

ParameterClassification

1

1

1

1 0..*

it is provided only for “Read/Write” parameter

refers to the Associated Parameter1


Example for Event Report

ProcessChamber

HeaterBlock

ChamberTemp.

N2

MFC

PM-1

EQUIPMENTEVENT

“PM-1”sourrceId“PR-STRT”eventId

eventTime 20031027T120304

ParameterValue(value) (real value)

ParameterValue(value) (real value)

PM-3

PM-2

MFC Set Point MFC Actual

What should be given to the Parameter Name for “MFC Set Point” or “MFC Actual” ?

What name should be given to "sourceId" or "eventId" ?


Data Quality

We need to define WHAT IS DATA QUALITYWe need to define accuracy of data and possible data collection/report frequency.

It is not just a computer technology


Study of the Data Accuracy

Sensor Accuracy

Sampled Value

Timestamp

Sampling Rate

Sample Timing

DeviationCorrelation among

events, traces may be effected

To Factory

Sample timing Flicker

A/D Conversion Resolution

Among Equipment Modules

Data

Correlation to external event may be effected

Trace Data pitch may have variance

Sampling Rate should be selected to the data

frequencyAccuracy is made of Senor Accuracy and

A/D Resolution

Sample Timing is determined by the data collection mechanism

such as poling


Performance of Data Collection

We need to define WHAT IS THE PERFORMANCEWe need to identify true performance that is available on equipment

It is not just a computer technology


Consideration ofInterface A Performance

Equipment

ModuleController

Data CollectionExecutionController

ModuleController

Internal Network

Data Client

Performance

Performance

Performance

MES

Factory Network


Interoperability

How we can make it happen.

Need system other than computer technologyKind of protocol to define the specs.


Interoperability .NET and Java

Equipment A Equipment B

Client 1 Client 2

.NET Java

Java.NET

e-Manufacturing Workshop Summary

e-Manufacturing Workshop Summary

30 November 2004

Harvey [email protected]



Interface A StandardsISMI Member Companies #1 priority is access to data from equipment. This goal required Interface A standardization, a second equipment port for data access.

Standard Description

Common Equipment Model (CEM, E120)

Describes the physical structure of equipment

Equipment Self Description (EqSD, E125)

Describes the data provided by equipment

Equipment Client Authentication / Authorization (E132)

Restricts access to equipment services

Data Collection Management (E134)

Defines and activates data collection plans

Interface A Standards are Approved!


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


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: www.ismi.sematech.org/emanufacturing/forums.htmregistration is required so e-mails can be forwarded to participants

Contact: [email protected], 512.356.7547


Equipment Data Acquisition Discussion TopicsEquipment Data Acquisition Discussion Topics

• 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


References• SEMI EDA standards: E120, E125, E132, E134

downloads.semi.org/PUBS/SEMIPUBS.NSF/webstandardssoftware!OpenViewteams.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, 04094557A-ENG, www.sematech.org/docubase/abstracts/4557aeng.htm

• Usage Scenarios, 04104579A-TR,www.sematech.org/docubase/abstracts/4579atr.htm

• Virus Protection, 04104567A-ENG, www.sematech.org/docubase/abstracts/4567aeng.htm