semi合集-English.pdf - 第3694页

SEMI PR8-0703 © SEMI 2003 24 RELATED INFORMATION 2 EXAMPLE EDA CLIENT APPLICATIONS NOTICE: This related information is no t an official part of SEMI PR8. This related information is not intended to modify or supersede th…

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.

R2-1.1.4 Fault Detection and Classification (FDC)

R2-1.1.4.1 Scope of FDC Systems

R2-1.1.4.1.1 FDC systems are data-intensive, time-

critical applications. They typically collect process

variable, event, and exception/alarm data from the

equipment as it’s produced, and analyze the results,

looking for faults that indicate or could lead to mis-

processing. If such a condition is detected, an FDC

system may send a control signal to the equipment

through the host, to abort processing before further

material is lost.

R2-1.1.4.2 Timeliness of FDC Data

R2-1.1.4.2.1 FDC applications can be very time

critical, sometimes in the sub-second range. As the

time criticality of FDC applications becomes more

acute, the ability of this interface to support these

applications will be severely tested.