semi合集-English.pdf - 第1921页

SEMI E54.1-1000 © SEMI 1996, 2000 27 Behavior associated wi th the (Alarm and Warning) Exception Queues (see Sect ions 7.3.1.21 an d 7.3.1.22), if supported, is as f o llows: Upon device initia lization (start-up) or res…

100%1 / 7923
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.
SEMI E54.1-1000 © SEMI 1996, 2000 28
Active Element
--------------------
Name
Status
AlarmEnable
Warning Enable
--------------------
Reset
Abort
Recover
Operate
Get
Set
RestoreDefault
Sensor
--------------------
Value
ReportInhibitTimer
EnableReportRate
ReportRate
Actuator
--------------------
Setting
SafeState
WatchRate
WatchDog
Controller
--------------------
Setpoint
ProcessVariable
ControlVariable
DataType
DataUnits
AlarmSettleTime
AlarmErrorBand
WarningSettleTime
WarningErrorBand
Sensor-AI
--------------------
Offset
Gain
DataType
DataUnits
SafeState
EnableReportDelta
ReportDelta
EnableReportROC
ReportROC
AlarmTripPointHigh
AlarmTripPointLow
AlarmHysteresis
WarningTripPointHigh
WarningTripPointLow
WarningHystersis
Sensor-BI
--------------------
DebounceControl
AlarmState
WarningState
Actuator-BO
--------------------
Actuator-AO
--------------------
Offset
Gain
DataType
DataUnits
Sensor-EI
--------------------
DebounceControl
AlarmState
WarningState
Actuator-EO
--------------------
Sensor-BI-TH
--------------------
Reading Valid
Status
State
Figure 7
Active Element Class Generalization Hierarchy
7.4.1 Active Element (AE) Class — The AE class at the top of the active element generalization hierarchy contains
structure and behavior common to all active element instances in a device.
7.4.1.1 Active Element Class Attributes — All required and “common optional” AE class attributes are listed in
Table 30 and described below. For an explanation of the table format, see Section 7.3.1.
Table 30 AE Class Attributes*
Attribute Name Attribute
Identifier
Access
(Network)
Rqmt Form
Name nA1** RO N Text, 16 characters maximum
Status nA2 RO Y Context-specific
AlarmEnable nA3 RW N Boolean
WarningEnable nA4*** RW N Boolean
* A “Definition” column is not included. For attribute definitions, see text.
** Where ‘n’ is the type of the object instance to which the particular attribute is associated (e.g., Sai, Sbi, Aao, Ado, or C), see Sections 7.4.4
through 7.4.8.
*** ID’s nA5 through nA15 are reserved for future AE class attribute definition.