semi合集-English.pdf - 第1991页

SEMI E54.5-0997 © SEMI 1997, 2004 7 requester indicating the resp onse to the request. For example, the SAC Object Instance Behavior State Transition Matrix in Table 4 of the SEMI E54 document defines the val id SAC stat…

100%1 / 7923
SEMI E54.5-0997 © SEMI 1997, 2004 6
Figure 5
Second and Third Levels of the SEMI Object Type
Hierarchy
The optional sensor and actuator objects described in
the SEMI E54 specification may be instances of
existing SDS object types (e.g., of type I/O object in
Figure 4). In cases where a desired object type is not
available under SDS object type 1, new I/O object types
may be defined as sub-types of object type 10.3 SEMI
I/O object.
7.1.2 Example SEMI Device — For clarification
purposes, an example SEMI device is shown in Figure
6 (using Rumbaugh notation). It consists of three (or
more) objects, including a DM, SAC, and binary input
object. This is a complete and fully functional SEMI
SAN-compliant digital input device.
In Figure 6, the Device is assigned an SDS address
(e.g., 125), and each object is assigned an object
instance number. The device address may be changed
during installation. Each SDS message contains a
device address and an object instance number.
Figure 6
Example Device with Multiple Objects
7.2 SEMI Object Type 10 Definition — Table 2
formally specifies the SEMI Object (type 10). The three
sections in this table specify SDS identifiers to code the
required attributes, actions, or events. The first column
is the SDS identifier number, the unique identifier used
in SDS messaging. The second column is the SEMI
E54-specified name associated with the ID#. The third
column identifies the associated tag name (identifier)
used in SEMI E54.
Table 2 Table 2 SEMI Object Common Level
Model(Object Type 10)
Type 10 SEMI Object Common Structure and Behavior
Attributes
ID Name SEMI E54 tag
None defined.
80–144 SEMI Reserved Attribute IDs Reserve
Actions
ID Name SEMI E54 tag
80 Reset SacS1/DmS1
81 Abort SacS2/DmS1
82 Recover SacS3/DmS3
83–95 SEMI Reserved Action IDs Reserve
Events
ID Name SEMI E54 tag
None defined.
80–95 SEMI Reserved Event IDs Reserve
There are no attributes that are currently identified in
SEMI E54 that are common to all SEMI objects. As a
result, there are no attributes defined in the table.
However, 64 attribute IDs have been reserved for use in
other sub-types derived from type 10 in this document
and in future revisions of this document.
SEMI E54 defines three service requests (reset, abort,
and recover) that are common to the Device Manager
and the SAC objects. These service requests are
implemented as specific SDS Actions. Each service is
mapped to a designated SDS action in Table 2. The
actions are identified as ID# 80, 81, and 82
respectively. Additional action identifiers are reserved
for use in sub-types of this type and for future use.
Not explicitly shown as Actions are the SEMI E54 Get
and Set Attribute services. The equivalent behavior is
provided by the SDS Read and Write Attribute services
that are implicit for every attribute.
The execution of a service request may cause a change
in the object’s state variable. When a device receives an
SDS action message indicating a service request, the
object transitions to the appropriate state, after which an
SDS response message is transmitted to the service
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.