semi合集-English.pdf - 第1721页
SEMI E41-95 © SEM I 1995 4 abnormal situations are reported by an exception agent (service- provider) to a decision authority (ser vice-user). In the case of recoverable s ituations, ser vices are provided for a deci sio…
SEMI E41-95 © SEMI 19953
5.2 Object Attribute Representation — The object
information models for standardized objects will be
supported by an attribute definition table with the
following column headings:
Attribute Name 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 service-users have
to the attribute.
A ‘Y’ or ‘N’ in the requirement (Rqmt) column
indicates whether or not this attribute must be supported
in order to meet fundamental compliance for the
service.
The Form column is used to indicates the format of the
attribute. (See Section 4.1 for definitions.)
5.3 Service Message Representation
5.3.1 Service Resource Definition — A service
resource definition table defines the specific set of
messages for a given service group, as shown in the
following table:
Message Service Name Type Description
Message Name N or R The intent of the service.
Type can be either N = Notification or R = Request.
Notification type messages are initiated by the service
provider, and the provider does not expect to get a
response from the consumer/subscriber.
Request messages are initiated by a service consumer or
subscriber. Request messages ask for data or an activity
from the provider. Request messages expect a specific
response message (no presumption on the message
content).
5.3.2 Service Parameter Dictionary — A service
parameter dictionary table defines the parameters used
in a service, as shown in the following table:
Parameter Form Description
Parameter X Data type A parameter called X is B in A.
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 contents of the corresponding primitive.
The Form column is used to indicate the type of data
contained in a parameter. (See Section 4.1 for
definitions.)
The Description column in the Service Parameter
Dictionary table describes the meaning of the
parameter, the values it can assume, and any
interrelationships with other parameters.
To prevent the definition of numerous parameters
named “XxxList,” this document adopts the convention
of referring to the list as “(List of) Xxx.” In this case,
the definition of the variable Xxx will be given, not of
the list. The term “list” indicates a collection (or set) of
zero or more items of the same data type. Where a list
is used in both the request and the response, the list
order in the request is retained in the response. A list
must contain at least one element unless zero elements
are specifically allowed.
5.3.3 Service Message Definition — A service
message definition table defines the parameters used in
a service, as shown in the following table:
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
message sent by the initiator is called the “Request.”
The receiver terms this message the “Indication” or the
request. The receiver may then send a “Response,”
which the original sender terms the “Confirmation.”
The following codes appear in the Req/Ind and Rsp/Cnf
columns and are used in the definition of the parameters
(e.g., how each parameter is used in each direction):
“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.
“=” — (for Response only) Indicates that the value of
this parameter in the response must match that in the
primary (if defined).
6 Overview
Exception management is concerned with the
interactive handling of equipment exception conditions.
This standard defines the services provided by which
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).