semi合集-English.pdf - 第1722页
SEMI E41-95 © SEM I 1995 5 The term posting is used to desc ribe all reportin g t he transition to the SET state and while an e xception condition state is SET . Clearing is the reportin g o f the occurrence of an except…
SEMI E41-95 © SEMI 1995 4
abnormal situations are reported by an exception agent
(service-provider) to a decision authority (service-user).
In the case of recoverable situations, services are
provided for a decision authority to choose how to
proceed to resolve the abnormal situation.
The exception agent is the equipment entity which
manages access to and reporting of information on
abnormal situations. It achieves this by defining
exception conditions, each related to a significant
abnormal situation. All services are defined in terms of
these exception conditions.
Exception management allows for the decision
authority to direct the resolution of an abnormal
situation. The decision authority selects a recovery
action to be performed to resolve the situation from
among the options supplied with the exception
condition. The exception agent performs the requested
recovery action, which may or may not resolve the
situation.
The services are fully defined in terms of the
functionality provided by the exception agent (service-
provider) and as such do not dictate the architecture of
the decision authority (service-user).
This standard describes the concepts and exception
condition model on which the communications are
based, followed by the detailed behavioral model used.
It then describes the standard object attributes and
message services in detail.
6.1 Compliance — Compliance with this standard
includes adherence to all stated requirements in this
document where implemented. This includes defined
message services and state models.
There are two levels of compliance defined. The first is
alarm reporting support. The second extends support to
include interactive handling of recoverable exception
conditions. Required capabilities are listed in
Fundamental Requirements, Section 10.4.
7 Concepts
7.1 Exception Management Model — The exception
management model describes the mechanism for
interactive handling of equipment exception conditions.
An exception condition is a condition monitored in
equipment by an exception agent (service-provider) for
detecting an abnormal situation. Exception conditions
are limited in this standard to those accessible by a
remote decision authority (service-user).
An exception condition is persistent, existing whether
or not the abnormal situation currently exists. The
abnormal situation is indicated by the exception
condition state becoming SET. An exception agent is an
entity which manages remote decision authority access
to any number of exception conditions. Each exception
condition is identified by a name which is unique for
the exception agent.
A decision authority is a remote entity requiring to be
notified of exception condition information and which
decides appropriate actions to take to resolve abnormal
situations. The decision authority may be represented
by a supervisory controller interacting with an operator
who may ultimately choose the recovery action.
The exception agent notifies the decision authority on
detection of an abnormal situation related to an
exception condition (i.e., state is SET) and again when
it is no longer apparent. It also provides access to
exception condition attribute data and for the execution
of recovery actions requested by the decision authority.
Exception management defines two types of exception
conditions: alarms and error conditions.
An alarm is related to any abnormal situation on the
equipment that may endanger people, equipment, or
material being processed. Alarms do not provide for
decision authority involvement in the resolution of the
abnormal situation.
An error condition is related to any abnormal situation
detected which is made accessible to a decision
authority. An error condition may supply a list of
possible recovery actions from which the decision
authority can select to attempt to resolve the abnormal
situation, thereby resulting in the error condition state
becoming CLEARED.
Being persistent, exception condition attributes may be
queried at any time, and reporting of changes, such as
state SET/CLEARED, can be disabled by the decision
authority.
7.2 Posting and Clearing — Significant changes in an
exception condition are reported to the decision
authority if enabled. The major significant events are
the transitioning of the exception condition state to SET
or CLEARED, which indicate that the abnormal
situation has been detected or is no longer apparent,
respectively.
All significant information is sent when reporting that
the exception condition state is SET. This includes the
unique identifier, type, a message describing the
abnormal situation, time and a list of possible recovery
actions where appropriate. It is important to keep the
decision authority updated on exception condition
information while the abnormal situation exists,
especially with respect to valid recovery actions. All
changes in the list of possible recovery actions are
reported to the decision authority while the exception
condition state is SET.
SEMI E41-95 © SEMI 19955
The term posting is used to describe all reporting the
transition to the SET state and while an exception
condition state is SET.
Clearing is the reporting of the occurrence of an
exception condition state transition to CLEARED. Note
that the exception agent, not the decision authority,
transitions the state to CLEARED. Any
acknowledgment at the decision authority of exception
condition posting (e.g., by the operator) is not relevant
to the exception agent.
Exception condition changes while its state is
CLEARED are not reported to the decision authority.
7.3 Enable/Disable Reporting — The decision
authority may enable and disable posting and clearing
for a particular exception condition by setting and
resetting its enabled attribute, respectively. Reporting
on an exception condition is enabled by default.
Note that the exception condition itself is not being
enabled or disabled, but the reporting of its state is
being enabled or disabled.
Posting of an exception condition shall occur upon
being enabled if the exception condition state is SET.
7.4 Recovery Actions — Recovery actions provide a
mechanism for a decision authority to assist in
resolving an abnormal situation detected in the
equipment. This is generally needed to resolve failure
or conflict where information is required beyond the
capabilities of the system. By supplying options related
to each error condition, error recovery is directed to the
problem area.
One or more recovery actions may be associated with
an error condition. A recovery action is any operation
with the aim of resolving the abnormal situation
detected. It may supply information to the exception
agent or request it to perform some activity.
A recovery action may be requested by the decision
authority only when the error condition state is SET.
Only recovery actions currently valid for the error
condition are accepted by the exception agent.
The list of valid recovery actions is supplied in the
posting of an error condition. Changes in this list are
notified by re-posting. A decision authority may request
any of the supplied recovery actions to be performed
and is notified of acceptance to perform the recovery
and, some time later, its completion. No more than one
recovery action may be in progress on a particular error
condition and it may be aborted by the decision
authority at any time.
A recovery action does not directly change the error
condition state to CLEARED. It performs activities or
provides information with the object of removing the
abnormal situation which in turn changes the state to
CLEARED. A recovery action may continue after the
state has transitioned to CLEARED, until the activity
initiated has completed. A recovery action is rejected if
received when the error condition state is CLEARED.
Since the exception agent must maintain system
integrity by ensuring that incompatible operations are
not performed concurrently, it may reject any recovery
action requested.
8 Behavior
This section provides a high-level definition of the
communications between the decision authority and the
exception agent used in exception management. It does
not define the message detail, concentrating on the
concepts. The message detail is addressed in the
Messaging Services section.
8.1 Exception Condition Communication
8.1.1 Exception Report Messaging — The message
flow for exception reporting is shown in Figure 1. The
arrows represent significant information exchange.
Figure 1
Exception Reporting Message Flow
A detailed description of each message used in
exception reporting follows:
EX Post — The exception agent has detected an
abnormal situation which is monitored by an exception
condition. It changes the exception condition state
attribute to SET. The exception agent notifies the
decision authority using the EX Post notification,
supplying the following information:
• identification of the exception condition,
• type of exception,
• time,
• a message explaining the abnormal situation,
• a list of possible recovery actions (where available
with error conditions).
SEMI E41-95 © SEMI 1995 6
EX Post is re-sent every time the message or recovery
action information changes as long as the exception
condition state remains SET.
The EX Post notification is not sent if reporting on the
exception condition is disabled, that is, if the enabled
attribute is false. The EX Post notification is sent when
an exception condition becomes enabled if the
exception condition state is SET.
Upon receipt of the EX Post, the decision authority has
the information needed to take the appropriate action.
This may include requesting the exception agent to
perform one of the supplied recovery actions.
EX Cleared — The abnormal situation detected by the
exception agent is no longer apparent or relevant. The
exception agent changes the exception condition state
attribute to CLEARED. It notifies the decision authority
using the EX Cleared notification, supplying the
following information:
• identification of the exception condition,
• type of exception,
• time,
• a message.
The EX Cleared message is not sent if reporting on the
exception condition is disabled. That is, the enabled
attribute is false.
Upon receipt of the EX Cleared, the decision authority
knows that the abnormal situation related to the
exception condition is no longer apparent or relevant.
8.1.2 Recovery Action Messaging — In this section,
the extended messaging of the recovery action is added
to the reporting messaging described above. Recovery
actions are not available for alarms. The message flow
for recovery actions is shown in Figure 2.
Figure 2
Recovery Action Message Flow
A detailed description of each message used in recovery
actions follows:
EX Recover — The decision authority requests that the
exception agent perform a recovery action. The
particular recovery action selected is identified in the
EX Recover request together with the related exception
condition identifier. It shall be one of the recovery
actions supplied for the exception condition in the EX
Post notification.
Upon receipt of the EX Recover request and before
acknowledging, the exception agent checks that the
specified recovery action is currently valid. The request
shall be accepted and initiated immediately or rejected
by the exception agent.
The exception agent rejects a recovery action request if
there is already a recovery action in progress on that
exception condition.
EX Recover Acknowledge — The exception agent
responds to the decision authority that the requested
recovery action is accepted or rejected, and if rejected,
supplies text reasons for failure.
Acceptance of a recovery action indicates that the
exception agent has initiated the operation. The
operation continues to completion without further
intervention by the decision authority. The recovery
action may or may not result in the exception condition
state changing to CLEARED and the recovery action
may continue after the state becomes CLEARED.
The exception agent may reject a requested recovery
action for a number of reasons, including:
• unknown recovery for the exception condition,
• recovery currently invalid,
• busy with recovery for this exception condition,
• currently unable to perform the recovery (e.g.,
other conflicting activity or failure).
EX Recovery Complete — The exception agent declares
the recovery action to be complete once it has
completed the associated operation. This message is
also used when a recovery action ends abnormally. The
message indicates whether the operation completed
normally and, if not, supplies text reasons for the
failure.
Note that normal completion of a recovery action does
not indicate that the abnormal situation has been
resolved. That is indicated by the EX Cleared
notification.
EX Recovery Abort — The decision authority may
command the exception agent to abort a recovery action
at any time. The goal of the abort command is to end