semi合集-English.pdf - 第1920页
SEMI E54.1-1000 © SEMI 1996, 2000 26 _ Optional EventTr iggeredOn — When a bit in the status attribute transitions from cleared to set, the device will automaticall y report the exception status attribute. When the excep…
SEMI E54.1-1000 © SEMI 1996, 200025
exception queue and send
service response.
14 NORMAL
OPERATING
Invalid service request. NORMAL
OPERATING
Error response to appropriate
request.
Valid for all sub-states of
NORMAL OPERATING.
15 CRITICAL
FAULT
Any service request. CRITICAL
FAULT
none Object services generally
cannot be processed.
16 ABORT Abort or Execute
request.
ABORT Error response. Not valid requests in this
state.
17 RUNNING Recover request. RUNNING Error response. Recover request only valid
while in ABORT state.
18 RUNNING Internally generated
PublishAttribute
Notification Service.
RUNNING Attribute Identified by Attribute
ID in PublishAttribute Service
is Published.
Notification only occurs if
specific conditions are met
(see Section 7.3.3).
19 EXECUTING Execute Request. EXECUTING Error response. Not a valid request in this
state.
20 INITIALIZED/
SELF TESTING
Execute service request. INITIALIZED/
SELF TESTING
Error response. Not a valid request in this
state.
21 SELF TEST
EXCEPTION
Execute service request. SELF TEST
EXCEPTION
Error response. Not a valid request in this
state.
* Transitions 10 through 21 are recursive (i.e., the New State is the same as the Current State (including all nested sub-states)).
The following also applies to DM behavior:
A DM instance service may be requested internally by
the DM object.
If a SetAttribute request is received over the network
for an attribute that is not network-settable, the attribute
value is not changed and an error service response is
generated.
When processing an Abort, Recover, or Reset service
request, the DM object issues a corresponding Abort,
Recover, or Reset service request to the SAC object.
While in the Abort state, the DM object will not initiate
communications over the network (e.g., it will not
initiate communication of exceptions over the network).
It may, however, communicate over the network in
response to service requests.
All DM services have the same behavior associated
with invalid service requests unless otherwise indicated.
Common service error responses are listed in Appendix
2.
The following identifies additional behavior associated
with specific values of DM object attributes:
The Device Status attribute value indicates the state of
the DM object (see Table 18). It is updated on
appropriate state transitions within the DM object (see
Table 29). Attribute values 1 through 6 represent valid
states. A value of zero indicates that the DM state is
unknown; conditions under which a zero value may
occur are outside the scope of this document.
The Reporting Mode attribute determines five different
conditions under which alarms and warnings are
reported through communication of the Exception
Status attribute (see Table 19). Both warnings and
alarms have separate values within Reporting Mode.
This allows alarms to be reported more aggressively
than warnings because alarms are presumably more
time-critical. The behavior associated with the five
Reporting Mode conditions which are used for both
alarms and warnings is described in the following
paragraphs. Optionality indicates that the mode may or
may not be supported; this optionality may be further
specified in a sensor/actuator network specific device
model and/or device manufacturer specification.
_ Request — When a bit in the status attribute
transitions from cleared to set, the device will not report
until requested. When the exception condition no longer
exists, both the exception status bit and the specific bit
in the exception detail attribute are cleared. In this
mode, a device may go in and out of an exception
condition without ever reporting the condition because
there has been no request. The device must always
respond to a request for exception conditions,
regardless of Reporting Mode state.
_ Optional RequestLatched — When a bit in the status
attribute transitions from cleared to set, the device will
not report until requested. When the exception
condition no longer exists, the exception status bit and
the specific bit in the exception detail attribute are not
cleared until they have been requested and reported.
This mode guarantees that a brief occurrence of an
exception condition will always be reported, barring an
unrecoverable communications error. Within each
exception variable, active bits will be cleared as they
are reported.
SEMI E54.1-1000 © SEMI 1996, 2000 26
_ Optional EventTriggeredOn — When a bit in the
status attribute transitions from cleared to set, the
device will automatically report the exception status
attribute. When the exception condition no longer
exists, both the exception status bit and the specific bit
in the exception detail variable are cleared.
_ Optional EventTriggeredOn/Off — When a bit in the
status attribute transitions from cleared to set, the
device will automatically report the exception status
attribute. When the exception condition no longer
exists, both the exception status bit and the specific bit
in the exception detail attribute are cleared, and the
device will again automatically report the exception
status attribute.
_ Optional TimeTriggered — If this mode is supported,
the Exception Status Timer attribute value indicates the
time interval for periodic status reporting. When the
indicated time period expires, the device will
automatically report the exception status attribute.
When the exception condition no longer exists, both the
exception status bit and the specific bit in the exception
detail attribute are cleared.
_ Optional EventOnOrTimeTriggered — This is a
logical “or” of EventTriggeredOn mode and
TimeTriggered mode. When the exception condition no
longer exists, both the exception status bit and the
specific bit in the exception detail attribute are cleared.
_ Optional EventOn/OffOrTimeTriggered — This is a
logical “or” of EventTriggeredOn/Off mode and Time-
Triggered mode. When the exception condition no
longer exists, both the exception status bit and the
specific bit in the exception detail attribute are cleared.
The Reporting Mode attribute value defaults to zero
upon object initialization (i.e., request mode), unless
otherwise specified in an appropriate sensor/actuator
network specific device model specification.
The Reporting Mode attribute is defined as network-
settable; however, it is only settable to (valid) values
corresponding to supported reporting modes (see Table
19, appropriate sensor/actuator network specific device
model specification, and device manufacturer
specification). Note that at least one reporting mode,
Request, must be supported. If an attempt is made, via a
Set_Attribute service request, to set the Reporting
Mode attribute to an invalid value, an error service
response is returned.
All exceptions are communicated through reporting the
values of the Exception Status and, conditionally, the
Exception Detail Alarm and Exception Detail Warning
attributes. An Exception Detail attribute may only be
reported if both bit 7 and the corresponding exception
bit of the Exception Status variable are set to 1.
If the Reporting Mode attribute indicates a reporting
mode of TimeTriggered, EventOnOrTimeTriggered, or
EventOn/OffOrTimeTriggered, the time interval for
reporting is the value of the Exception Status Report
Interval attribute. Time zero is defined as the time at
which the Reporting Mode attribute is last modified
utilizing the SetAttribute service. The first report is
generated at time zero (not after the first time interval).
If this value of the Exception Status Report Interval
attribute is zero, then time triggered exception reporting
is disabled.
If the Reporting Mode attribute indicates a reporting
mode of EventOnOrTimeTriggered, or
EventOn/OffOrTimeTriggered, the reporting associated
with the occurrence of the appropriate event and the
reporting associated with the report interval are
independent (e.g., the occurrence of reporting due to an
event does not impact the timing associated with
reporting according to a specified time interval).
The Exception Status Report Interval attribute value
defaults to 0.0 seconds upon object initialization, unless
otherwise specified in an appropriate sensor/actuator
network specific device model specification.
Additional behavior may be provided by a DM object
that is device-specific. A complete definition of this
additional behavior may be found in an appropriate
sensor/actuator network specific device model
specification.
The PublishAttribute service would be used for
automatic reporting of the DM object exception status
attribute when (1) an exception exists, (2) an automatic
reporting mode is indicated by the Reporting Mode
attribute (see Section 7.3.1), and (3) the indicated
reporting mode is supported by the device (in its current
state).
Behavior associated with the AlarmEnable and
WarningEnable attributes is as follows. If the
alarm/warning attribute is TRUE or if the attribute is
not supported, alarm/warning reporting behavior as
described elsewhere in this section is not impacted by
this attribute. If the alarm/warning attribute is set to
FALSE, all alarm/warning DM exception attributes are
set and maintained at values that indicate a no alarm
state. Thus, bits 0 through 2 of the ExceptionStatus
attribute (alarms) or bits 4 through 6 (warnings) are set
and maintained at zero, and any ExceptionDetail
Alarm/Warning attribute bytes are set and maintained at
a value of zero. When the Alarm/WarningEnable is
toggled to TRUE, the device immediately determines
its alarm/warning state, updates the appropriate DM
attributes as necessary, and reports any alarms/warnings
according to the mode defined by the ReportingMode
attribute.
SEMI E54.1-1000 © SEMI 1996, 200027
Behavior associated with the (Alarm and Warning)
Exception Queues (see Sections 7.3.1.21 and 7.3.1.22),
if supported, is as follows: Upon device initialization
(start-up) or reset, both exception queues are cleared.
The data type of queue elements is determined by the
value of bit 7 of the status attribute (as explained in
Section 7.3.1.21). As alarm events are issued to the DM
object, the appropriate exception parameters are set
(ExceptionStatus and ExceptionDetailAlarm/Warning)
and the events are also logged onto the appropriate
Alarm or Warning Exception Queue on a first-in, first-
out basis. Any alarm or warning clear events are also
logged onto these queues in the same manner; these
events are logged in the same data format as the
exception, but with the data value indicating that the
exception no longer exists. The maximum number of
elements that are retained by the queue is application-
specific. Once the maximum queue length is reached,
new exception events depose the oldest exception event
from the queue in a first-in, first-out fashion (similar to
a shift register). The GetExceptionQueue service may
be used to retrieve any number or all exception events
from either (alarm or warning exception) queue. If the
value of the Clear attribute is TRUE, retrieved events
are deposed from the queue; otherwise, they are left in
the queue.
Behavior associated with the optional “Date and Time”
attribute is as follows. This attribute indicates the
current date and time as perceived by the device
whenever it is reported. The resolution of the “Time of
Day” reported shall be milliseconds unless the “Date
and Time Type” attribute is supported and it indicates a
resolution other than milliseconds.
7.4 Sensor, Actuator, and Controller Objects — The
Sensor (S), Actuator (A), and Controller (C) objects are
the model components that model the high level
sensory, actuation, and/or control element capabilities
of the device as viewed from the network. Although the
structure and behavior of these elements can vary
widely from device to device, there are common
aspects of structure and behavior that can be identified.
Specifically, there are structure and behavior
characteristics common to all active elements (i.e., all
S, A, and C objects), common to all elements of an
element type (i.e., all S objects, A objects, or C
objects), or common to all elements of an element sub-
type (e.g., all analog input sensor objects). This
commonality of structure and behavior among these
object types is depicted in the class generalization
hierarchy of Figure 7. With this generalization
hierarchy in place, objects inherit structure and
behavior from their parent object classes, thus reducing
the level of redundancy in description. For example,
object instances of the Sensor-AI class inherit (i.e., also
have) the attributes, services, and behavior of the
Sensor and Active Element parent classes.
Note that the only classes from which accessible object
instances can be created in this hierarchy exist at the
lowest level (i.e., Sensor-AI, Sensor-BI, Actuator-AO,
Actuator-BO, and Controller objects). Also note that
the object identifiers for these object instances are
designated as indicated in Table 1 (e.g., a Sensor-AI
object instance has an Object Identifier of SenI’n’,
where ‘n’ is the instance number of the sensor object
for the device).
In the following sub-sections, the attributes, services,
and behavior at each level of the active element class
generalization hierarchy are identified and defined.
Note that the specific device model would complete the
definition of each sensor, actuator, and controller
element of a specific device type through definition of
additional structure and behavior for the S, A, and C
object instances that collectively realize the sensory/
actuation/control capability portion of the device
model.