semi合集-English.pdf - 第3674页
SEMI PR8-0703 © SEMI 2003 4 Table 1 EDA Interface Features Covered in Section # Feature Description Supported By Interface Definition Implementation Required General Interface 7.1.3 Messages are communicated vi a Etherne…
SEMI PR8-0703 © SEMI 2003 3
6.1.2 Figure 1 shows a conceptual model of the relationship between applications that can utilize this interface for
data acquisition and the host system that uses the SECS/GEM interface to perform process control tasks. If process
messages must be sent to the equipment based on data obtained via the EDA interface, the host system must be
integrated with those components that utilize the EDA interface, so the corresponding process messages can be sent
to the equipment via SECS/GEM.
Host System
SECS/GEM
Diagnostic, Equipment Health
Monitoring, OEE, and other systems
EDA
Equipment data clients set up and control
the flow of data from the equipment, perform
analysis, and send/receive control
messages to/from host when necessary
messages
Host uses control/process
j
ob, GEM, etc. to control
equipment actions and
execution
Equipment
p
rocess and data acquisition
messages
data acquisition messages only
Figure 1
Control and Data Interfaces to the Tool
6.1.3 Figure 2 shows a conceptual picture of the capability supported by this specification. Note that some data
acquisition messages can be sent to the equipment via the SECS/GEM interface, if the equipment has been so
configured. This capability is in place to facilitate factory architectures in which all data management operations
must be centralized at the SECS/GEM host during the period when systems based on this specification are in
development.
Host System
EDA Client
•
Data management services
•
SECS
-
II / HSMS
Equipment
SECS Port
EDA Port
EDA Client
EDA Client(s)
• Data management services
-
• Data delivery services
SECS
EDA
Configure
data management
to take place via
either SECS or EDA
port
Figure 2
EDA Interface Features
6.2 Interface Features
6.2.1 This section itemizes interface features. Not all features require implementation from suppliers. The
“Implementation Required” column indicates whether the feature must be implemented in order to be in compliance
with this proposed standard. “Optional” in the Implementation Required column indicates that the feature is not
required for compliance with the standard, but shall be considered for advanced implementations, and need not be
implemented except at the supplier’s discretion. The column entitled “Supported by Interface Definition” indicates
whether the feature is supported via the SECS/GEM or XML/SOAP message specifications defined in this
document. A “-“ (dash) in the supported by interface definition column indicates that the feature is supported
outside of the interface, whereas a “!”(checkmark)
indicates that the feature is supported through the interface.
SEMI PR8-0703 © SEMI 2003 4
Table 1 EDA Interface Features
Covered in
Section #
Feature Description
Supported By
Interface Definition
Implementation
Required
General Interface
7.1.3 Messages are communicated via Ethernet using HTTP on top o
f
TCP/IP as the message transport.
! !
7.1.9 Messages are represented as XML data within SOAP
envelopes.
! !
7.7.3.2 Data collection events, state model transitions, equipment
exceptions, and parametric data defined by existing software
standards (such as SEMI E30, E40, E87, E90, E94, etc…) that
are made available through the SECS/GEM interface are
supported.
!
Optional
7.7.3.2 Transmission of milestones or tasks during subsystem
processes, actuator operations, is supported.
!
Optional
7.7.2 A time resolution of 0.01 seconds is supported in messages
requiring a timestamp.
!
Optional
Data Collection Management
7.6.2.7 Ability to list the names of, and activate/de-activate data
collection plans via the EDA interface is supported.
! !
7.6.2.6 Ability to list the names of, and activate/de-activate data
collection plans via the –SECS/GEM interface is supported.
! !
7.4.1 Equipment configuration is provided to switch listing/activation
of data collection plans to either the SECS/GEM or the EDA
interface.
-
!
7.4.4 Multiple data collection clients are supported.
!
Optional
7.7.4 Ability to warn clients of equipment performance degradation
is supported.
! !
7.9 The equipment shall provide a method for the user to modify,
add and delete data collection plans.
-
!
7.9 The equipment shall provide a method for the user to view the
contents of the data collection plans.
-
!
7.6.2.2 The equipment shall provide the names of Data Collection
Plans available for selection/activation by applications through
the interface.
! !
7.6.2.6.1 Data transmission will continue independent of the SECS/GEM
communication state of the equipment.
-
!
Security
7.4.2, 7.6.2 Ability to specify the URI of data consumers and data managers
at the equipment is supported.
-
!
Metadata
7.8 Equipment metadata is accessible to off-tool clients. -
!
7.8 Metadata shall include the equipment’s physical structure down
to the level of each individual sensor/actuator that can be
included in a data collection plan.
-
!
7.8 Metadata shall include the names and definitions of any
parameters that can be included in a data collection plan.
-
!
7.8 Metadata shall include the possible exceptions or errors that can
be included in data collection plans.
-
!
7.8 Metadata shall include what transitions from SEMI standard
and equipment supplier defined state models are available
through the EDA port.
-
!
SEMI PR8-0703 © SEMI 2003 5
Covered in
Section #
Feature Description
Supported By
Interface Definition
Implementation
Required
Data Collection Plans
7.9 The data to be transmitted through the EDA port shall be
defined in a set of named data collection plans.
-
!
7.9 Data collection plans shall describe which events, exceptions,
data variables will be sent through the interface when that plan
is activated.
-
!
6.3 Risks for Preliminary Implementations
6.4 There are some inherent risks to implementers of
the EDA interface specified in this document.
Significant risks include:
6.4.1 TCP/HTTP Limitations on Data Latency — Any
use of this standard in an application requiring
deterministic latency in the communication of data to
an off-tool application is at risk of failure due to late
delivery of data. Occasional delays in data delivery on
the order of a second or more can occur in TCP
communication due to the need for packet
retransmission. This is inherent in the TCP/IP protocol
used by HTTP, and cannot be addressed through
application design.
6.4.2 Data Collection Plan and Metadata Structure
and Formats are not Specified — The content and
transmission format of Data Collection plans and
Metadata for the proposed standard are left up to the
supplier. Standards are in process to define Metadata
and data collection plan content and data transmission
format in a standard way. The standard definitions may
be different than those defined by the supplier for the
proposed standard.
6.4.3 SOAP Protocol Usage — The SOAP usage
defined in this standard is targeted for point-to-point,
synchronous communication. This style of SOAP
communication may not be suitable for more
complicated communication models, and other
approaches may be required to achieve the objectives of
such applications.
6.4.4 XML/SOAP Limitations on Data Throughput —
While much has been done to optimize commercial
implementations of XML/SOAP messaging support,
end-to-end implementations on semiconductor
equipment have not been studied to quantify the
performance limitations of these technologies for data
collection, or to identify what hardware/software
configuration options are significant factors in
providing optimal throughput performance with these
technologies. If an implementation of this standard
requires meeting specific data throughput goals, it may
be necessary to evaluate the choice of networking
software drivers, application design, messaging
software toolkits used, hardware memory/cpu resources
or other elements when designing an implementation of
this specification. If the desired throughput goals
cannot be met by these design options, it may impact
the design of the message specification, the choice of
transport, or the mechanism for encoding the data
described in this specification.
NOTE 1: For information on factors contributing to SOAP
messaging performance, see http://www.extreme.indiana.edu/
~ mgovinda/research/papers/soap-hpdc2002.pdf
NOTE 2: For information on factors contributing to HTTP
performance, see http://www.w3.org/Protocols/HTTP/
Performance/
NOTE 3: For information purposes only, one example of
possible worst-case data throughput expectations for FDC
applications is available at http://www.sematech.org/public/
resources/ediag/background/eec032702.pdf.
7 Proposed EDA Interface Specification
7.1 Transport and Messaging
7.1.1 XML Schema Namespace — All XML element
information items defined in this specification belong to
the reserved SEMI namespace “urn:semi-
org:schema:eda_ps_v0.0”.
7.1.2 Separate Data Port — The proposed Equipment
Data Acquisition interface shall be a separate logical
port from the SECS/GEM control port on the tool.
7.1.3 Transport Mechanism — The transport
mechanism for the proposed EDA interface shall be
HTTP 1.1. The HTTP POST operation shall be used to
send messages to and from the equipment. There shall
be an HTTP connection from the equipment to the
client used for data only and another HTTP connection
from the client to the equipment, which will be used for
data management. These two HTTP connections
together make up a single EDA interface.
7.1.4 HTTP Performance Features — The client of the
equipment’s data port must operate in persistent
connection mode, as defined in HTTP 1.1. It is not
required that the data management connection of the
EDA port operate in persistent connection mode,
though that is the default mode for HTTP 1.1.