semi合集-English.pdf - 第3692页

SEMI PR8-0703 © SEMI 2003 22 RELATED INFORMATION 1 OPERATIONAL SEGMENT EXTENSION TO EDA NOTICE: This related information is no t an official part of SEMI PR8. This related information is not intended to modify or superse…

SEMI PR8-0703 © SEMI 2003 21

7.10.3 eda_equipment.wsdl

7.10.3.1 This file is an interface description document

that describes the types, messages, and SOAP and

HTTP protocol usage for each of the operations that the

equipment must support (Tables 15 and 16). Note that

it does not include specification of the endpoint address

for these operations, since this is unique for each

equipment installation that provides the service. This

file can be used by SOAP messaging toolkits that

support WSDL to generate interoperable client and

server code stubs. The contents of eda.xsd have been

directly included in the body of this file, so it is not

necessary to use that file separately in order to

implement these messages.

7.10.4 eda_consumer.wsdl

7.10.4.1 This file is an interface description document

that describes the types, messages, and SOAP and

HTTP protocol usage for each of the operations that

any EDA client must support (Tables 17-22). Note that

it does not include specification of the endpoint address

for these operations, since this is unique for each EDA

application. This file can be used by SOAP messaging

toolkits that support WSDL to generate interoperable

client and server code stubs. The contents of eda.xsd

have been directly included in the body of this file, so it

is not necessary to use that file separately in order to

implement these messages.

NOTICE: SEMI makes no warranties or

representations as to the suitability of the standards set

forth herein for any particular application. The

determination of the suitability of the standard is solely

the responsibility of the user. Users are cautioned to

refer to manufacturer' s instructions, product labels,

product data sheets, and other relevant literature,

respecting any materials or equipment mentioned

herein. These standards are subject to change without

notice.

By publication of this standard, Semiconductor

Equipment and Materials International (SEMI) takes no

position respecting the validity of any patent rights or

copyrights asserted in connection with any items

mentioned in this standard. Users of this standard are

expressly advised that determination of any such patent

rights or copyrights, and the risk of infringement of

such rights are entirely their own responsibility.

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.