semi合集-English.pdf - 第1986页
SEMI E54.5-0997 © SEMI 1997, 2004 2 The SDS Networ k communications standa rd document structure is shown in Figure 2. This standard specifies the mapping of t h e SAN comm on device model onto the SDS-specific network. …
SEMI E54.5-0997 © SEMI 1997, 2004 1
SEMI E54.5-0997 (Withdrawn 0704)
STANDARD FOR SENSOR/ACTUATOR NETWORK
COMMUNICATIONS FOR THE SMART DISTRIBUTED SYSTEM (SDS)
NOTE: This document was previously designated SEMI E60. Because this document is part of a suite of documents, its
designation has been reassigned for ease of reference. Please note that the technical content of this document is unchanged from
the 0697 version.
NOTICE: This document was balloted and approved
for withdrawal in 2004.
1 Purpose
This standard defines a communication protocol based
on the Smart Distributed System (SDS) to enable
communications between intelligent devices on a
sensor/actuator network (SAN) to be used in
semiconductor manufacturing equipment.
1.1 Background and Motivation — SDS provides
interconnection of smart control devices such as
sensors, actuators, and controllers in a fast-response
time, low-cost network for industrial use. SDS enables
multiple devices to share a single bus, thereby
significantly reducing the point-to-point wiring between
controllers, sensors, and actuators. The SDS system is
based on CAN, the controller area network used in the
automotive industry and defined by Bosch.
2 Scope
This document specifies a SAN communications
standard based on the Smart Distributed System (SDS)
specification that is in compliance with the SEMI SAN
Common Device Model specification.
2.1 This document specifies the protocol and services
that compliant intelligent devices must support to
interchange information over this semiconductor
equipment sensor/actuator network.
2.2 This document is used in conjunction with a SEMI
standard SAN Common Device Model specification
and one or more SEMI standard specific device model
specifications (e.g., for a mass flow controller).
Together, the model documents describe the data
structure and behavior that are characteristic of the
various devices on the network. This SAN
communications standard identifies the protocol for the
interaction with such a device over the network to make
the data structures and behavior available to other
devices.
2.3 This standard, together with a sensor/actuator
network interoperability guideline, the sensor/actuator
network common device model, one or more
sensor/actuator network specific device model
documents, and the SDS specifications, form a
complete interoperability standard. The general
sensor/actuator network document architecture is
shown in the Sensor/Actuator Network Common
Device Model document in Figure 1.
Figure 1
Sensor/Actuator Network Related Documents
SEMI E54.5-0997 © SEMI 1997, 2004 2
The SDS Network communications standard document
structure is shown in Figure 2. This standard specifies
the mapping of the SAN common device model onto
the SDS-specific network. In addition, the document
will include mappings to specific device models (e.g.,
the mass flow controller). The latter mappings will be
included in this document as the specific device models
are defined.
Figure 2
SDS Network Communications Standard Document
Structure
3 Limitations
3.1 This document specifies a semiconductor
equipment SAN based solely on SDS and is a
companion document to the SDS specification; thus, a
complete specification of this standard necessarily
includes the SDS specifications. There are other
semiconductor equipment SAN communications
options. The specifications for these options are not
included here.
3.2 This standard specifies enhancements that provide
additional capabilities over and above those currently
required by SDS. In order to avoid document
consistency problems, information in the SDS
specification that relates to this standard is not repeated
in this document. This document is limited to
describing enhancements or limitations to the SDS
specification that are imposed by this standard.
3.3 A complete specification of the conformance
testing procedure shall include the SDS protocol
conformance testing specification. Conformance testing
shall also include enhancements and limitations to the
SDS specification required by this standard.
4 Referenced Standards
4.1 SEMI Standards
SEMI E30 — Generic Model for Communications and
Control of SEMI Equipment (GEM)
SEMI E39 — Object Services Standard: Concepts,
Behavior, and Services
SEMI E54.1 — Standard for Sensor/Actuator Network
Common Device Model
4.2 ISO Standards
1
ISO 7498 — Basic Reference Model for Open Systems
Interconnection
ISO 11898 — Road Vehicles — Interchange of Digital
Information — Controller Area Network (CAN) for
High-Speed Communications
4.3 Other Documents
Doc 84-08420-1 (GS 052 103) — SMART
DISTRIBUTED SYSTEM Application Layer Protocol
Specification, Honeywell MICRO SWITCH, February
15, 1995
Doc 84-08421-A (GS 052 104) — SDS Physical Layer
Specification, Honeywell MICRO SWITCH, December
15, 1994
Doc 85-08453-0 (GS 052 107) — SMART
DISTRIBUTED SYSTEM Component Model
Specification, Honeywell MICRO SWITCH, January
29, 1995
Doc GS 052 108 Issue 1 — SMART DISTRIBUTED
SYSTEM Conformance Test Procedure Specification,
Honeywell MICRO SWITCH, January 2, 1995
Controller Area Network Specification: Version 2, R.
Bosch GmbH, + Postfach 50 D-7000, Stuttgart 1,
Germany, 1991
5 Terminology
Terminology that is common to all of the documents in
this SAN series may also be defined in the Sensor
Actuator Network Interoperability Guideline.
Terminology may be reproduced here which is defined
in other SEMI documents.
5.1 Device Component Definitions — This standard is
based on the concepts developed in the Sensor Actuator
Network Common Device Model (SEMI E54)
document and makes use of the following terms defined
in it:
a) device
b) device model
c) object
d) instance
e) attribute
f) behavior
g) service
1
International Organization for Standardization, 1 rue de Varembe,
Case postale 56, CH-1211 Geneva 20, Switzerland
SEMI E54.5-0997 © SEMI 1997, 2004 3
h) state diagram
i) byte
j) nibble
k) character string
5.2 SDS-Specific Definitions — In addition to the
above terms, the following terms are defined for SDS
networks.
5.2.1 actions — operations that a client may request
an Embedded Object to perform. The action typically
modifies the state of the device. Actions are more
powerful than writing to an attribute, in that multiple
input arguments may be provided as part of an action
request. Also, results of the action are typically
returned. Actions, like attributes, have identifiers that
are specific to the type of the object. However, these
identifiers are independent from attribute or event
identifiers. The “request” services specified in SEMI
E54 are implemented as SDS actions.
5.2.2 controller area network (CAN) — a protocol
developed by the Bosch corporation for automotive in-
vehicle networking. The CAN specification specifies
OSI reference model layers 1 and 2, specifically the
physical signaling and media access/data link protocols.
5.2.3 embedded objects — each SDS Logical Device
contains at least one, and at most 32, Embedded
Objects. An SDS Embedded Object is an abstraction
representing an addressable entity “embedded” within a
Logical Device having specific application-related
interface characteristics. These characteristics include a
defined set of attributes, actions, and events that are
specific to the Embedded Object. Combinations of
these Embedded Objects provide a mechanism for
describing an arbitrary sensor/actuator network device.
The behaviors required by SEMI E54 are specified as
part of the definition of attributes, actions, and events.
5.2.4 events — Are used by objects to asynchronously
report the occurrence of events within an Embedded
Object. Event definitions specify the event reports that
a specific Embedded Object type may emit. Events also
have type-specific identifiers. Event definitions include:
a text string defining the semantics of the event, an
event identifier numerical value and textual name, and a
syntax definition. The “notification” services specified
in SEMI E54 are implemented as SDS events.
5.2.5 logical device — It is possible to have one or
more independent Logical Devices within the Physical
Component. This provides the illusion of multiple
devices on the network that actually are implemented
on the same physical hardware. Logical Devices are
distinguished within the Physical Component using
unique SDS bus addresses. The Logical Device defines
a separately addressable entity within a Physical
Component that has an independent interface definition.
5.2.6 physical component — An SDS Physical
Component is an abstraction representing a single
physical package of hardware and software that is
connected to the network. This is equivalent to the
CDM SEMI E54 definition for “device.” The Physical
Component contains one or more Logical Devices.
Table 1 provides a mapping of SEMI E54 definitions to
SDS-specific definitions. Column 2 contains an equal
sign “=” if the definition is used exactly as specified in
SEMI E54. Otherwise, the appropriate SDS-specific
term(s) are identified.
Table 1 Table 1 Mapping of Terms Between SEMI
E54 and SDS
SEMI E54 Term SDS Term
Device =
Device Model Physical Component
Object Embedded Object
Instance =
Attribute =
Behavior Set of Attribute/Action/Event
definitions
Service Actions for Request Services
and Events for Notification
Services
State Diagram =
Byte =
Nibble =
Character String =
6 Communication Protocol High Level
Structure
The SDS protocol is based on a three-layer architecture.
These layers constitute a collapsed form of the OSI
seven-layer architecture, mapping into the physical,
datalink, and application layers of the Open Systems
Interconnection Reference Model. The high level
protocol architecture is shown in Figure 3.
Note that Figure 3 represents a conceptual view of the
device architecture. Conforming implementations must
implement the services defined in this specification at
each layer and must appear (from the network) to have
implemented this architecture; however, an internal
modular partitioning is not required. Implementations
may sacrifice modularity in order to achieve high
performance.