semi合集-English.pdf - 第1898页
SEMI E54.1-1000 © SEMI 1996, 2000 4 5.2.18 Si gned Integer (IN T) — An in t e ger , 2 by te s long , in the ran ge -32768 to 32767. 5.2.19 text string — A string of one b y t e characters. 5.2.20 U nsigned Double Integer…
SEMI E54.1-1000 © SEMI 1996, 20003
Figure 2
Examples of Devices
5.2.5 data type — An unsigned short integer formatted
as an enumerated byte to specify attribute data format.
The intended use of this attribute type is in cases where
an attribute, or set of attributes, may be defined,
allowing for more than one level of support (e.g., INT
or REAL). The following values are defined:
0=INT
1=REAL
2=USINT
3=SINT
4=DINT
5=LINT
6=UINT
7=UDINT
8=ULINT
9=LREAL
10–99=reserved for CDM
100–199=reserved for SDMs
200–255=manufacturer-specified
5.2.6 data units — An unsigned integer enumerated to
specify attribute data units. The intended use of this
attribute type is in cases where an attribute, or set of
attributes, may be defined, allowing for more than one
unit’s context. The values are defined in Appendix 1 of
this document.
5.2.7 date — A data structure of four bytes used to
represent a calendar date. Table 1 defines the format of
the date data type.
Table 1 Date Format
Data # Description Range
0–1 Year Unsigned Integer < 65,536
2 Month Unsigned Integer
(range of 1 to 12)
3 Day Unsigned Integer
(range of 1 to 31)
5.2.8 Double Integer (DINT) — An integer, four bytes
long, in the range -2
31
to 2
31
-1.
5.2.9 enumerated byte — A byte with assigned
meaning to the values 0 through 255. May take on one
of a limited set of possible values.
5.2.10 full scale range — The defined 100% value of
an attribute in its assigned units. This value is not
necessarily the maximum value for the attribute. As an
example, the indicated flow attribute value may attain
120% of the full scale range.
5.2.11 Last Valid Value (LVV) — The most recent
value successfully assigned to an attribute.
5.2.12 Long Integer (LINT) — An integer, eight bytes
long, in the range -2
63
to 2
63
-1.
5.2.13 Long Real (LREAL) — A double floating point
number, 8 bytes long, as defined by IEEE 754.
5.2.14 nibble — A string of four adjacent binary bits.
5.2.15 null character — A byte with a value of zero.
5.2.16 Real (REAL) — A floating point number, 4
bytes long, as defined by IEEE 754.
5.2.17 Short Integer (SINT) — An integer, one byte
long, in the range -128 to 127.
SEMI E54.1-1000 © SEMI 1996, 2000 4
5.2.18 Signed Integer (INT) — An integer, 2 bytes
long, in the range -32768 to 32767.
5.2.19 text string — A string of one byte characters.
5.2.20 Unsigned Double Integer (UDINT) — An un-
signed integer, four bytes long, in the range 0 to 2
32
-1.
5.2.21 Unsigned Integer (UINT) — An integer, 2
bytes long, in the range 0 to 65535.
5.2.22 Unsigned Long Integer (ULINT) — An un-
signed integer, eight bytes long, in the range 0 to 2
64
-1.
5.2.23 Unsigned Short Integer (USINT) — An integer,
1 byte long, in the range 0 to 255.
6 Conventions
6.1 Harel State Model — This document uses the
Harel State Chart notation to describe the dynamic
behavior of the objects defined. An overview of this
notation is presented in an appendix of SEMI E30. The
formal definition of this notation is presented in Science
of Computer Programming 8, “Statecharts: A Visual
Formalism for Complex Systems,” by D. Harel, 1987.
Transition tables (referred to in this document as “state
transition matrices”) are provided in conjunction with
the state diagrams to explicitly describe the nature of
each state transition. Each transition table contains
columns for Transition #, Current State, Trigger, New
State, Action(s). The “trigger” (column 3) for the
transition occurs while in the “current” state. The
“actions” (column 5) include a combination of: 1)
actions taken upon exit of the current state, 2) actions
taken upon entry of the new state, and 3) actions taken
which are most closely associated with the transition.
No differentiation is made.
6.2 OMT Object Information Model — The object
models are presented using the Object Modeling
Technique developed by Rumbaugh, James, et al, in
“Object-Oriented Modeling and Design,” Prentice Hall,
Englewood Cliffs, NJ, ©1991. Overviews of this
notation are provided in an appendix of SEMI E39.
6.3 Object Attribute Representation — The object
information models for standardized objects will be
supported by an attribute definition table with the
following column headings:
Attribute Definition Access Rqmt Form
The formal text
name of the
attribute.
Description of
the information
contained.
RO or
RW
Y or N (see
below)
The access column uses RO (Read Only) or RW (Read
and Write) to indicate the access that users of Object
Services have to the attribute. Note that, in this
document, the access column is used only to indicate
user access via the network; no indication is made as to
local access as this level of specification is considered
to be implementation-specific. Thus, in the context of
this document, a RW attribute is a network-settable
attribute (i.e., an attribute whose value can be altered
from the network), while a RO attribute is a non-
network-settable attribute.
A ‘Y’ or ‘N’ in the requirement (Rqmt) column
indicates if this attribute must be supported in order to
meet fundamental compliance for the service.
The Form column is used to indicate the format of the
attribute.
6.4 Service Message Representation
6.4.1 Service Resource Definition — The service
resource definition table defines the specific set of
messages for a given service group, as shown in the
following table:
Service Type Description
Message name N or R The intent of the service.
Type can be either Notification (N) or Request (R).
Notification messages are initiated by the service
provider. No response is expected. Request messages
are initiated by the service user. Request messages ask
for data or for an operation to be performed. Request
messages expect a specific response (no presumption
on the message content).
6.4.2 Service Parameter Dictionary — Each parameter
should relate to either attributes from the object model
or events of the dynamic model (Harel State Chart). All
parameters to the services are listed in a single table or
dictionary. The column headings for this parameter
dictionary are as follows:
Parameter Form Description
Parameter X Data type A parameter
A row is provided in the table for each parameter of the
service. The first column contains the name of the
parameter. This is followed by columns describing the
form and the contents of the parameter.
The form column is used to indicate the type of data
contained in the parameter and the possible values it
may take on.
The description column describes the meaning of the
parameter and interrelationships with other parameters.
SEMI E54.1-1000 © SEMI 1996, 20005
6.4.2.1 Service Message Definition — There is a table
showing the parameter detail for each service in which
parameters are explicitly specified. The column
headings for the service detail are as follows:
Parameter Req/Ind Rsp/Cnf Description
Parameter X (see below) (see below) A description of the
service.
The columns labeled Req/Ind and Rsp/Cnf link the
parameters to the direction of the message. The mes-
sage sent by the initiator is called the “Request” (Req).
The receiver terms the message the “Indication” (Ind).
The receiver may then send a “Response” (Rsp), which
the original sender terms the “Confirmation” (Cnf).
The request (Req/Ind) and response (Rsp/Cnf) entries
can take on the following values:
“M” Mandatory parameter — Must be given a
valid value.
“C” Conditional parameter — May be defined in
some circumstances and undefined in others.
Whether a value is given may be completely optional
or may depend on the value of another parameter.
“U” User-defined parameter
“-” The parameter is not used.
“=” The entries M and C in the response can be
modified with (=) to indicate that the value in the
response must match the request.
7 Device High Level Structu re
The high level object view of a device aggregation is
shown in Figure 3. A device is depicted as consisting of
a sensor/actuator/controller (SAC) object, a device
manager (DM) object, and at least one active element
object (i.e., sensor or actuator or controller object).
Each of these objects by definition has attributes,
services, and behavior. Note that the “Device” object is
depicted in Figure 3 only for purposes of illustrating a
high level view of the device and its component
objects; in the context of this document, the “Device”
object is not addressable, does not have addressable
attributes or accessible services, and has no behavior
defined.
This document defines in detail only the DM object.
The SAC, Sensor, Actuator, and Controller objects are
defined here only in terms of characteristics common to
all devices. A complete definition of a SAC object in-
cludes an appropriate sensor/actuator network specific
device model. This companion model could also com-
plete the definition of sensor, actuator, and controller
objects as appropriate to specify a device model.
7.1 General Requirements — Objects are defined in
terms of their object name and instance identifier.
Identifiers for all objects described in this document are
summarized in Table 2. Note that these identifiers may
be used for remote interrogation of an object instance
via the sensor/actuator network (see appropriate
sensor/actuator communications specification). Also
note that, in Table 2, many of the objects specified in
this document have exactly one instantiation per device.
De vice M an a
g
er
Ob
j
ect
(
DM
)
De v ice
Sens or
/
Actuator
/
Controller Ob
j
ect
(
SAC
)
Sensor
Ob
j
ect
(
s
)
A
ctuator
Ob
j
ect
(
s
)
Controller
Ob
j
ect
(
s
)
Coord
i
na
t
es
I
s
M
anaged By
m+n+p•1
mnp
mnp
(
A
g
g
re
g
ation
)
Act iv e Element
Figure 3
High Level Object View of a Device