semi合集-English.pdf - 第3693页

SEMI PR8-0703 © SEMI 2003 23 Example: OpSeg Event <EdaData> <EquipmentID> <Supplier>Some Supp lier</Supplier> <Model>8400</Mo del> <ImmutableID>9989 48< /Immu tab le ID> &l…

SEMI PR8-0703 © SEMI 2003 22

RELATED INFORMATION 1

OPERATIONAL SEGMENT EXTENSION TO EDA

NOTICE: This related information is not an official part of SEMI PR8. This related information is not intended to

modify or supersede the official proposed standard. Determination of the suitability of the material is solely the

responsibility of the user.

R1-1 Operational Segments

R1-1.1 Operational Segment Event — Operational segments are optional, at the discretion of the supplier, and can

be provided as an extension to the equipment events described in the specification. Operational Segment events are

provided for those suppliers that desire to model their tools in a more structured and hierarchical way than is

possible with simple events. The operational segment is a generalization of the task model defined in SEMI E116

(Equipment Performance Tracking).

R1-1.1.1 Operational Segments — An operational segment, or segment, is a persistent entity that is expected to

occur as part of normal or planned equipment operations. A segment always has only one start time and only one

complete time, so if a segment is viewed on a timeline or Gantt chart it literally occupies a segment of time. Most

segments of interest are general equipment operations that are expected to repeat on a regular basis. For example,

for an equipment robot that performs the act of loading a wafer into a chamber many times, the robot is the locator,

the “load” task is a segment, and each occasion that the equipment performs that task is an instance of that “load”

segment.

R1-1.1.2 Segment Instances — Segments of the same name repeat frequently over time. It is necessary to identify a

particular occurrence of a segment and to relate it to other segments involved in the same or dependant operations.

InstanceIDs perform this function. The network of operational segments can be reconstructed by connecting each

segment event to the segment that it describes and then relating each segment to its parent segment, if any. For

example, a wafer “get” might have a start and complete event, which are related via an InstanceID to describe the

“get” sub-task. The “get” sub-task might be part of a load wafer task. The “get” sub-task would be related to its

parent segment via the ParentInstanceID.

Table R1-1 Operational Segment Event

Tag Name Description XML Datatype Behavior

OpSegEvent Operation Name Complex Required

SegmentType Identifier for the type of segment being executed

(e.g. Process Job, Substrate, Task, etc.).

String Required

EventType Enum--

0 = Complete;

1 = Start;

2 = Suspend;

3 = Resume;

4 = InProgress;

5 = Transitional;

6–9 = Equipment Defined

NonNegative Integer;

Max inclusive = 9

Required

TaskName Name of Task String Optional, include if task or

sub-task

Purpose The intended use of the segment (e.g.

Production, Engineering, maintenance, etc.).

String Optional, include if task or

sub-task

SegInstID Unique identifier of the specific segment

instance to which the message applies. May be

UUID.

String Optional

ParSegInstID Unique identifier of the parent of the segment

instance that the message applies. May be

UUID.

String Optional, include if segment

start event

SEMI PR8-0703 © SEMI 2003 23

Example: OpSeg Event

<Supplier>Some Supplier</Supplier>

</EquipmentID>

<Event>

<Locator> Inspector.robot.aligner </Locator>

<EventID>OpSegEvent</EventID>

<TaskName>Align</TaskName>

<Purpose>Manufacturing</Purpose>

</ OpSegEvent>

</Extension>

</OpSegEvent>

</EdaData>

R1-1.1.2.1 Note that the EventID child element of the Event element from the specification is used to identify the

extension as an operation segment extension. The additional information used for operational segments is contained

within the extension element, and resides in a different namespace than that used to define the EDA data types.

R1-1.1.3 Enumerations — Three enumerations are included in the Operational segment format for ease of parsing

and extraction from a database. These enumerations are: 1) SegmentType, 2) EventType, and 3) Purpose.

R1-1.1.4 EventType Enumeration — The EventType enumeration is a list of the types of events that may occur as

part of the execution of a segment. This list describes the different event types that naturally occur as part of the

execution of a segment. Six (6) common event types are defined and the equipment may add custom types as

required.

Enumeration Value Name Description

0 Complete The segment completes, either normally or abnormally

1 Start The segment begins

2 Suspend The segments stops, with the potential to resume

3 Resume The segment resumes execution after a suspend

4 In-Progress A milestone is reached, or a parametric report is issued

5 Transitional One segment ends and another begins simultaneously

6–9 Equipment Defined These enumerations can be defined by the supplier

R1-1.2 Schema Document

R1-1.2.1 A machine-readable XML Schema file is provided to help ensure interoperable usage of the operational

segment message described in this section of the Related Information for this specification.

R1-1.2.2 OpSeg.xsd

R1-1.2.2.1 This file is an XML Schema document that describes the structure of the XML document fragment

specified in Table R1-1 of this section of the Related Information. This file can be used in conjunction with the

schema and WSDL files provided with the primary specification to validate, or to facilitate, the serialization and

deserialization of, operational segment data enclosed in the Extension element of the Event message.

SEMI PR8-0703 © SEMI 2003 24

RELATED INFORMATION 2

EXAMPLE EDA CLIENT APPLICATIONS

NOTICE: This related information is not an official part of SEMI PR8. This related information is not intended to

modify or supersede the official proposed standard. Determination of the suitability of the material is solely the

responsibility of the user.

R2-1 Typical Users of Proposed EDA

Solutions

R2-1.1 This section provides a very basic overview of

the different classes of data collection clients that

proposed EDA implementations are intended to support

from the viewpoints of the types of data that are used,

and the basic dynamics of each client. The different

classes of data collection capabilities may be required

in a combination or separately depending on the

necessity.

R2-1.1.1 Equipment Utilization Tracking

R2-1.1.1.1 Scope of Utilization Tracking Applications

R2-1.1.1.1.1 Utilization tracking applications are

responsible for collecting information regarding the use

of the equipment in the factory. These applications

typically look for events and alarms/exceptions from

the to determine when the equipment is being

exercised, when it is idle, and when it is unable to

perform its intended function due to errors or alarms.

R2-1.1.1.2 Timeliness and Accuracy of Utilization

Data

R2-1.1.1.2.1 Such applications are not time-critical,

and can accept data off-equipment with very high

latencies (on the order of seconds to minutes or greater)

with no adverse effect on the ability of the application

to function. However, as these applications are meant

to calculate where the equipment is spending its time,

they require adequately accurate time stamping of all

events and alarms/exceptions. They also depend on the

equipment to properly communicate when tasks begin

and end, when alarms are set and when they are cleared,

etc. It is important for the equipment not to drop these

events, to double-count them, or to provide incorrect

timestamps for them.

R2-1.1.2 Equipment Health Monitoring

R2-1.1.2.1 Scope of Equipment Health Monitoring

Applications

R2-1.1.2.1.1 Equipment health monitoring applications

are responsible for collecting information regarding the

details of equipment operation, and to analyze

equipment operational data to detect or predict negative

trends in the performance of the equipment. These

applications will typically look for equipment

operational events describing the behavior of individual

subsystems, exceptions and alarms, trace data on select

parameters, and actuator status. The EDA interface

shall support a detailed level of equipment operations

that has not been conventionally supported so as to

achieve detailed equipment health monitoring or

diagnosis.

R2-1.1.2.2 Timeliness and Accuracy of Equipment

Health Data

R2-1.1.2.2.1 These applications are not time-critical,

and can accept data off-equipment with relatively high

latencies (on the order of seconds to minutes) with no

real adverse effect on the ability of the application to

function. They may be more reactive than utilization

tracking systems, looking for negative conditions on

which they may take some action (such as paging an

engineer, or warning of the need for a possible

maintenance run).

R2-1.1.3 Run-to-Run Control

R2-1.1.3.1 Scope of Run-to-Run Applications

R2-1.1.3.1.1 Run-to-Run applications are reactive

systems that collect process variable data from the

equipment (typically a metrology tool) at the end of a

run, and perform analysis on the results to determine if

any adjustments in control parameters shall be made to

future processing at the step that was measured. The

new settings are calculated and made accessible for

subsequent use at the corresponding process step.

R2-1.1.3.2 Timeliness of Run-to-Run Data

R2-1.1.3.2.1 These applications are not very time

critical in today’s systems, where control parameter

adjustments are performed on a lot basis. As it

becomes possible to collect measurement data on a

wafer basis, they will become more time-sensitive, and

may function properly with latencies on the order of

seconds.

R2-1.1.3.3 Run-to-Run Data Interests

R2-1.1.3.3.1 These applications are typically interested

in measurement result sets, events, exceptions, or

alarms.