semi合集-English.pdf - 第3691页

SEMI PR8-0703 © SEMI 2003 21 7.10.3 eda_e quipment .wsdl 7.10.3.1 This file is an interface description document that describes the t ypes, messages, a nd SOAP and HTTP protocol usage for each of the operations that the …

100%1 / 7923
SEMI PR8-0703 © SEMI 2003 20
for Alarm Set. If the E30 alarm message is triggered by alarm clear then the ExState element shall contain “clear”,
for alarm clear. If it is necessary to include the value of ALCD in the exception, this information shall be provided
as a separate parameter within the Data element, the name of the parameter shall be “ALCD”, and its value shall be
of type Base64Binary. The only other required fields for transmission of an E30 alarm are MsgType, EventTime
and Locator.
7.7.10 Notification of Interference with Tool Operations — If the function of the EDA port, or the volume of data,
is interfering with tool operations or the output of the SECS/GEM port then the tool will notify all configured clients
of the condition. The format of this notification is defined in the following section.
7.7.10.1 Tool Interference Message — The following message format will be used to indicate interference with tool
operations. The table below describes the “Operation” element of the message. The message takes the general
form of XML data messages as described in Section 7.7.2. The SOAPAction HTTP header for this message is
“urn:semi-org:ws:eda_ps_v0.0:EdaError”. The ErrorType field for tool interference messages shall have the value
“PerformanceWarning”. Note that this message can be used to communicate other error conditions not defined in
this specification.
Table 22 EdaError XML Defintion
Tag Name Description XML Datatype Behavior
EdaError Operation Name Complex Required
ErrorTime Error time and date stamp dateTime Required
ErrorType The category or type of error String Required
ErrorCode A unique identifier for the error String Required
ErrorDesc A more specific description of the
problem
String Required
7.8 Metadata
7.8.1 Metadata — Metadata must be provided to the
user in the form of XML documents. The structure and
format of metadata is left to the equipment supplier.
The provided metadata must include sufficient
information to describe the following items:
1) Definition of all Param Names and other non-
standard tags that will be communicated. These
definitions will include, where applicable, units,
data types, max sampling frequencies, valid
limits, the tool entity to which each param
applies, and any other aspects necessary to
understand and use the data element,
2) Definition of the equipment structure and
hierarchy,
3) Definition of the available events and the tool
entities to which they apply,
4) Definition of any state models that are supported,
5) Definition of which parameters can be
communicated with each event, and
6) Definition of what exceptions can be
communicated, to what equipment entities they
apply, and what parameters will be included with
each exception.
7.9 Data Collection Plans — Data collection from the
equipment will be enabled through the activation of
specific data collection plans. The definition of
available data collection plans must be provided to the
user in the form of an XML file. The structure and
format of the data collection XML file(s) is left to the
supplier.
7.9.1 Modifying and Adding Data Collection Plans —
The equipment supplier must provide a means for
customers to change the content and number of
available data collection plans.
7.10 Schema and WSDL documents
7.10.1 Three machine-readable files are provided to
help ensure interoperable messaging between factory
applications and supplier implementations of the
specification. This section describes each file and its
usage.
7.10.2 eda.xsd
7.10.2.1 This file is an XML Schema document that
describes the structure of the XML document fragments
specified in Tables 15–22. This file can be used to
validate, or to facilitate the serialization and de-
serialization of, the body element of the SOAP
envelope for each of the messages defined in this
specification. It cannot be used to enforce or specify
the usage of the HTTP and SOAP protocols.
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