semi合集-English.pdf - 第1992页

SEMI E54.5-0997 © SEMI 1997, 2004 8 The DM Object Model maps exactly to the specification for the DM in SEMI E 54. Refer to that document for detailed descriptions for th e attributes, actions, and e vents define d in Ta…

100%1 / 7923
SEMI E54.5-0997 © SEMI 1997, 2004 7
requester indicating the response to the request. For
example, the SAC Object Instance Behavior State
Transition Matrix in Table 4 of the SEMI E54
document defines the valid SAC state transitions.
Service Notifications (as defined in SEMI E54) are
implemented with specific SDS event messages which
are specified in the third part of the table. The SEMI
object (type 10) has no events defined at this time.
Additional event identifiers are reserved for use in sub-
types of this type and for future use.
7.3 Implementation of Sensor/Actuator/Controller
Object Type (SAC) — A single instance of a SAC
object type is required in each SAN device. The actual
object type used will typically be derived from the SAC
object type rather than this exact type. The derived type
will have added services and attributes that are device-
specific (according to a Specific Device Model
specification). The generic SAC type is, nevertheless,
defined as a semantic type definition (sensor actuator
controller object). The features of the SAC object
include service requests (for Reset, Abort, Recover,
etc.) that are mapped to SDS Action functions. Since
these have been defined in the super type (object type
10), they are not re-defined here.
7.3.1 SDS Object Model for Sensor/Actuator/Control-
ler Object Type (SAC) — The SDS object model for the
SAC object type (Table 3) needs only to include the
appropriate mapping for SAC-specific attributes and
behavior (i.e., augmenting the SEMI Object Common
Level - Table 8-1). The SAC Object Model contains no
attributes, actions, or events beyond those specified in
its super type (type 10).
An implementor of a specific device will normally
derive a new SAC object type and add new attributes,
actions, or events as necessary (i.e., 10.1.1 MFC SAC
Object). Object type 10.1 is, in essence, a semantic
grouping only—for a group of device-specific SAC
object types implementing specific behavior.
The default object identifier that should be used for the
SAC object in an SDS device is 1. The actual object
identifier used may be reassigned by the implementor.
The identifier may be determined on line via reading
the object type attributes from all objects on the device.
Table 3 Table 3 SAC Object Model (Object Type
10.1)
Type 10.1 Sensor/Actuator/Controller Object Model
Attributes
ID Name SEMI E54 tag
None defined.
Actions
ID Name SEMI E54 tag
None defined.
Events
ID Name SEMI E54 tag
None defined.
7.4 Implementation of Device Manager Object Type
(DM) — A single instance of this type is required on
each device.
7.4.1 SDS Object Model for Device Manager Object
Type (DM) — The SDS object model for the DM object
type includes the appropriate mapping for DM-specific
attributes and behavior to SDS-specific identifiers
(Table 4).
Table 4 Table 4 DM Object Model (Object Type
10.2)
Type 10.2 Device Manager (DM) Object Model
Attributes
ID
Name
SEMI E54 tag
81 Device Type DmA1
82 Standard Revision Level DmA2
83 Device Manufacturer Identifier DmA3
84 Manufacturer Model Number DmA4
85 Software or Firmware Revision Level DmA5
86 Hardware Revision Level DmA6
87 Serial Number (optional) DmA7
88 Device Configuration (optional) DmA8
89 Device Status DmA9
90 Reporting Mode DmA10
91 Exception Status Timer (optional) DmA11
92 Exception Status DmA12
93 Exception Detail Alarm (optional) DmA13
94 Exception Detail Warning (optional) DmA14
Actions
ID Name SEMI E54 tag
83 Execute DmS6
84 PerformDiagnostics DmS7
Events
ID Name SEMI E54 tag
81 Publish Attribute DmS8
SEMI E54.5-0997 © SEMI 1997, 2004 8
The DM Object Model maps exactly to the
specification for the DM in SEMI E54. Refer to that
document for detailed descriptions for the attributes,
actions, and events defined in Table 4. The SEMI E54
tag column indicates the identifier used in SEMI E54.
The default object identifier that should be used for the
DM object in an SDS device is 2. The actual object
identifier used may be reassigned by the implementer.
7.5 Implementation of Sensor Object Type (S
i
) — Zero
or more instances of this object type are permitted on
each device.
Sensor object types are already defined within the SDS
object hierarchy (e.g., Object Type 1 - I/O Device).
Implementation of a device which is compliant with
this type results in compliance with this standard.
If the existing sensor object types defined in the SDS
specifications do not meet the requirements of the
application, new SEMI-specific types may be defined
deriving from type 10.3. If new types are required that
are generic (i.e., not specific to SEMI), they should be
derived from type 1 - I/O Device.
7.6 Implementation of Actuator Object Type (A
i
) —
Zero or more instances of this object type are permitted
on each device.
Actuator object types are already defined within the
SDS object hierarchy (e.g., Object Type 1 - I/O
Device). Implementation of a device which is compliant
with this type results in compliance with this standard.
If the existing actuator object types defined in the SDS
specifications do not meet the requirements of the
application, new SEMI-specific object types may be
defined deriving from type 10.3. If new types are
required that are generic (i.e., not specific to SEMI),
they should be derived from type 1 - I/O Device.
7.7 Implementation of Controller Object Type (C
i
) —
Zero or more instances of this object type are permitted
on each device.
Specific controller object types are defined within the
SDS object hierarchy (e.g., Object type 3 - Function
Block Object). Implementation of a device which is
compliant with these types results in compliance with
this standard.
If the controller types defined in the SDS specifications
do not meet the requirements of the application, new
SEMI-specific object types may be defined deriving
from type 10. If new types are required that are generic
(i.e., not specific to SEMI), they should be derived from
type 3 - Function Block Object.
8 Protocol Compliance
A method of testing protocol compliance is required to
verify conformance to this standard. The device must
satisfy the SDS protocol conformance requirements as
documented in the SDS specifications. The SDS
partners group provides a conformance verification test
procedure service to its members. When this SEMI
Sensor/Actuator Network standard is incorporated into
the SDS Partners specification set, this service may be
used to verify compliance with the SEMI guidelines.
8.1 Compliance Statement — Addendum A includes a
compliance statement form that should be completed by
device implementors for compliance verification.
9 Specific Device Model Mappings
9.1 Device Model for Mass Flow Controller — This
model will be specified after the MFC-specific device
model (SDM) standard is complete.
9.2 Device Model for Capacitance Manometer — This
model will be specified after the capacitance
manometer SDM standard is complete.
9.3 Device Model for Particle Counter — This model
will be specified after the particle counter SDM
standdard is complete.
9.4 Device Model for Residual Gas Analyzer — This
model will be specified after the residual gas analyzer
SDM is defined.
SEMI E54.5-0997 © SEMI 1997, 2004 9
APPENDIX 1
STATEMENT OF COMPLIANCE
NOTE: This appendix was approved as an official part of SEMI E54.5 by full letter ballot procedure.
This form is used to specify conformance options with respect to the SDS and common device model SEMI E54
specifications.
Fill in the blank or the appropriate box. ❑ ❑
Conforms to Smart Distributed
System Specification: Release ___________
Vendor Name ___________________
Vendor Partner ID# ___________________
Catalog Listing ___________________
Object Type ___________________
General
Device
Data
Software Version ___________________
Network Power Consumption ___________mA @
18 VDC
Smart
Distributed
System
Physical
Conformance
Data
Connector Style Open-Hardwired ❑ Sealed-Mini ❑
Open-Pluggable ❑ Sealed-Micro ❑
9 Pin ❑
Isolated Physical Layer Yes No ❑
Opto ❑
Transformer ❑
Default Device Address ___________
Communication Data Rates Supported 125K bits/s ❑ 500K bits/s ❑
250k bits/s ❑ 1M bits/s ❑
Device Type Master ❑
Slave ❑
Peer-to-Peer ❑
Smart
Distributed
System
Logical
Device &
Object
Data
Number of Logical Devices Default = 1
Object Class(es) on Logical Device #0 Minimum = 1
Object #0 ___________
Object #1 ___________
Object #2 ___________
Object #3 ___________
...
Object #31 __________
If there are additional logical devices, they should be documented as above.