semi合集-English.pdf - 第1971页

SEMI E54.4-0704 © SEMI 1997, 2004 6 Table 2 Required Ob ject Types Object DN Class #* CDM Tag ** R equired by DN * R equired by CDM ** R equired by NCS Identity 01 N.A.*** Yes No Yes MR 02 N.A. Ye s No Yes DN 03 N.A. Yes…

100%1 / 7923
SEMI E54.4-0704 © SEMI 1997, 2004 5
6.9 Presentation Layer — There is no distinct
presentation layer. Data types and data presentation in
DeviceNet messages are specified as part of the
DeviceNet object definitions and object attribute and
service communication protocol.
6.10 Application Layer — The device shall comply
with the DeviceNet application layer specification for
defining and addressing objects, including their
attributes and services, and enabling specified network
behavior. The device shall comply with the object
model specifications provided in the DeviceNet
specification as well as the “Interface Guidelines for
DeviceNet Devices on Semiconductor Manufacturing
Tools” component of the DeviceNet specification. In
addition, the device shall comply with the object
specifications defined in Section 7 of this document.
6.10.1 Object Models — The DeviceNet protocol
provides an object-oriented specification for creating,
defining, and addressing objects explicitly, including
their attributes and services (i.e., explicit messaging),
and creating, defining, and communicating object
attribute assemblies in an application-dependent format
(i.e., input/output messaging). The device shall comply
with the object model specifications provided in the
DeviceNet documentation. In addition, the device shall
comply with the object specifications defined in Section
7 of this document.
6.11 Network Management — The device shall comply
with the DeviceNet network management specifications
(e.g., physical layer bit rate, duplicate MAC ID
detection, master-slave, and peer-to-peer network
management). No (additional) network management
functions are specified in this document.
7 Required Object Types
7.1 The DeviceNet specification identifies and
describes objects (i.e., classes) that must exist in all
DeviceNet-compliant devices. The Common Device
Model specification additionally identifies two objects
(namely the Device Manager (DM) and Sensor
Actuator Controller (SAC) objects) that must exist in all
SEMI-compliant SAN devices. The required object
types for a SEMI-compliant SAN device, using the
network communication specification described herein,
necessarily comprise the union of the above to
requirements.
7.2 A list of required and optional object types is given
in Table 2. Note that the Sensor, Actuator, and
Controller object types are not required and are
indicated as optional in the CDM specification. These
objects are aggregated together to form a SEMI- and
DN- compliant device, as shown in Figure 4.
7.3 The mapping of the DM and SAC objects are
combined into a single object in DeviceNet called the
S-Device Supervisor (DS) object.
SEMI E54.4-0704 © SEMI 1997, 2004 6
Table 2 Required Object Types
Object
DN
Class
#*
CDM
Tag **
R
equired
by
DN *
R
equired
by
CDM **
R
equired
by NCS
Identity 01 N.A.*** Yes No Yes
MR 02 N.A. Yes No Yes
DN 03 N.A. Yes No Yes
CNX 05 N.A. Yes No Yes
DM(DS) 48 DmI0 No Yes Yes
SAC(DS) 48 SACI0 No Yes Yes
Sensor **** SenIn No No No
Actuator **** ActIn No No No
Controlle
r
**** CntIn No No No
(Other) **** N.A. No No No
* See DeviceNet specification for further information; values are
hexadecimal.
** See CDM specification for further information.
*** Not applicable.
**** Application-dependent.
7.4 An embodiment of a specific device type
represented as an aggregation of the object types listed
in Table 2, that is compliant with both the CDM
specification and the DN specification, is a candidate
for a SEMI SDM as well as a DN Device Profile.
Conversely, all SEMI SDM’s and DN Device profiles
specified for operation over a SEMI-compliant DN
network must be an aggregation of the object types
listed in Table 2 and be compliant with both the CDM
specification and the DN specification.
Device
Identit
y
(
DN
)
DeviceNet
(
DN
)
Connection
(
CNX
)
Dev. Su
p
r.
(
DS
)
Senso
r
(
CDM
,
SDMs
)
Actuato
r
(
CDM
,
SDMs
)
Controller
(
CDM
,
SDMs
)
Othe
r
(
SDMs
,
DN
)
(
A
gg
re
g
ation
)
Messa
g
e
Route
r
(
MR
)
Figure 4
Aggregation of a Compliant Device
7.5 In the following sections, the presentation to the
network of object addressing, object attributes, and
object services for each of the object types listed in
Table 2 and Figure 4 is described in detail.
7.6 Identity Object — This object provides
identification of, and general information about, the
device. The Identity Object must be present in all
DeviceNet products. As specified by DeviceNet, each
DeviceNet product shall support one (and only one)
Identity object per physical connection to the
DeviceNet communication link. Presentation of object
identity, attributes, and services to the network for this
object is described in the DeviceNet specification.
Compliance with the DeviceNet specification shall
constitute compliance with this NCS for the Identity
Object.
7.7 Message Router (MR) Object — The MR Object
provides a messaging connection point through which a
service of any object class or instance residing in the
physical device may be addressed. The MR object must
be present in all DeviceNet products. As specified by
DeviceNet, each DeviceNet product shall support one
(and only one) Message Router object per physical
connection to the DeviceNet communication link.
Presentation of object identity, attributes, and services
to the network for this object is described in the
DeviceNet specification. Compliance with the
DeviceNet specification shall constitute compliance
with this NCS for the MR Object.
7.8 DeviceNet (DN) Object — The DN Object provides
the configuration and status of a DeviceNet port. As
specified by DeviceNet, each DeviceNet product shall
support one (and only one) DN object per physical
connection to the DeviceNet communication link.
Presentation of object identity, attributes, and services
to the network for this object is described in the
DeviceNet specification. Compliance with the
DeviceNet specification shall constitute compliance
with this NCS for the DN Object.
7.9 Connection (CNX) Object — The CNX Object
provides configuration and management of DeviceNet
connections. A CNX object exists at each end of a
DeviceNet connection (point-to-point or multicast).
The CNX object handles the negotiation for connection
establishment and manages a set of timers in order to
handle cyclic traffic, connection timeout and fault
containment and recovery. Several connection
behaviors are supported including: explicit messaging,
polled, cyclic, change-of-state and multicast messaging.
7.10 S-Device Supervisor (DS) Object — The DS
object is the device component responsible for
managing and consolidating the device operation as
well as coordinating the interaction of the device with
the sensory/actuation/control environment. Each device
must support one (and only one) DS object. The DS
SEMI E54.4-0704 © SEMI 1997, 2004 7
object combines both the DM object and the SAC
object into a single object for DeviceNet. The DM and
SAC, as well as their common required and optional
attributes, services, and behavior, are described in the
CDM standard. The presentation of object attributes
and services to the DN network shall be as indicated in
Table 3.
Table 3 Network Presentation of DM Object
Attributes and Services
S-Device Supervisor Object - - Object ID == 48
Attributes
ID Name CDM
Tag
3 Device Type DmA1
4 Standard Revision Level DmA2
5 Device Manufacturer Identifier DmA3
6 Manufacturer Model Number DmA4
7 Software or Firmware Revision Level DmA5
8 Hardware Revision Level DmA6
9 Serial Number (optional) DmA7
10 Device Configuration (optional) DmA8
11 Device Status DmA9
-- * Reporting Mode DmA10
-- * Exception Status Report Interval (optional) DmA11
12 Exception Status DmA12
13 Exception Detail Alarm (optional) DmA13
14 Exception Detail Warning (optional) DmA14
Services
ID
(hex)
Name (SEMI) Name (DN) CDM
Tag
05 Reset Reset DmS1
4B Abort Abort DmS2
4C Recover Recover DmS3
0E Get_Attribute Get_Attribute_Single DmS4
10 Set_Attribute Set_Attribute_Single DmS5
06 Execute Start DmS6
4E Perform_Diagnostic
s
Perform_Diagnostics DmS7
* There is no one-to-one mapping of the Reporting Mode attribute in
DeviceNet. Instead, DeviceNet specifies several attributes, services
and behaviors for its Connection Object to effect a superset of the
behaviors associated with the DM attributes Reporting Mode and
Exception Status Report Interval. See the DeviceNet specification for
details.
7.10.1 Note that the format of DM object attributes is
detailed in the CDM document; the presentation of DM
object attributes to the DN network is detailed in Table
3 and the DN specification; the format of DM object
services is detailed in the CDM document and the DN
specification; and the presentation of the DM object
services is detailed in Table 3 and the DN specification.
7.11 Sensor Object, Actuator Object, Controller
Object, and Other Object Types — These object types
are used collectively to model the type-specific
structure and behavior of the device. The requirement
and number of each of these object types in a device
model is device type-specific. Further, the attributes,
services, and behavior associated with each of these
object classes and instances in a device is also device
type-specific, but must be compliant with both SEMI
and DN specifications. The specification of these object
types for a specific device type can be found in the
appropriate SDM. The method of presentation of object
structure and behavior to the DN network for objects
defined for, and associated with, a specific device type
can be found in Section 9 of this document.
8 Protocol Compliance
8.1 A method of testing protocol compliance is
required to verify implementation conformance to the
standard. The test plan includes tests for duplicate
address resolution, mandatory objects, etc.
8.2 The compliance test suite for this protocol
necessarily includes the DeviceNet protocol compliance
specification and test suite as well as the “Conformance
Test Procedures for DeviceNet Devices on
Semiconductor Manufacturing Tools” which is
published as part of the DeviceNet specification.
Additional compliance specification required for
compliance to this NCS is provided as a set of Protocol
Specification Sheets.
8.3 Any enhancements to DeviceNet presented in this
document must be accepted by the Open DeviceNet
Vendors Association (ODVA) and incorporated into the
DeviceNet Specification before they can be
implemented as a DeviceNet product.
8.4 Protocol Specification Sheets — Compliance to this
NCS necessarily requires adherence to a set of protocol
specification sheets. These sheets are included as
Appendix 1 of this document and are included here for
reference only. For compliance with this NCS, it is
necessary to reference the latest revision of the Protocol
Specification Sheets from ODVA. Note that these
sheets provide statements of compliance for general
device data, physical conformance data,
communications data, required object implementation
(see also Section 7 or this document), and optional
object implementation. Note also that these
specification sheets must conform with DeviceNet
specifications for “Statement of Compliance” forms.
Finally note that additional specification sheets shall be
completed as necessary to specify compliance with
objects defined in SDM’s and SDM mappings (see
Section 9).