semi合集-English.pdf - 第1729页

SEMI E41-95 © SEM I 1995 12 • Detect and report that an abnormal situation is no longe r appa rent o r re levant b y clea ri ng the r elate d exception condition and reporting it if enabled. • Provide f or enabling and d…

100%1 / 7923
SEMI E41-95 © SEMI 199511
10.3.2 EXCleared — Notification that an abnormal situation is no longer apparent or relevant, as is described in
Section 8.1, is communicated using the EXCleared service.
Table 6 EXCleared Service Detail
Parameter Req/Ind Comment
Timestamp M
EXID M Identifies the exception condition which has detected the abnormal situation.
EXType M
EXMessage M
10.3.3 EXRecover — Recovery action requests, described in Section 8.1, are communicated using the EXRecover
service. The recovery action services are not available for alarms.
Table 7 EXRecover Service Detail
Parameter Req/Ind Rsp/Cnf Comment
EXID M - Identifies the exception condition on which to perform the recovery action.
EXRecovery M - The particular recovery action being requested.
EXRecoveryStatus - M
10.3.4 EXRecoveryComplete — Notification of recovery action completion by the exception agent is
communicated using the EXRecoveryComplete service. Recovery action completion, which is described in Section
8.1, is not directly linked to clearing the exception condition state, and successful completion indicates only that the
operation performed completed normally.
Table 8 EXRecoveryComplete Service Detail
Parameter Req/Ind Comment
Timestamp M
EXID M Identifies the exception condition on which the recovery action was performed.
EXRecoveryStatus M
10.3.5 EXRecoveryAbort — Recovery action abort, described in Section 8.1 is communicated using the
EXRecoveryAbort service.
Table 9 EXRecoveryAbort Service Detail
Parameter Req/Ind Rsp/Cnf Comment
EXID M - Identifies the exception condition on which the recovery action is being performed.
EXRecoveryStatus - M
10.4 Fundamental Requirements — Exception management defines the standard services available to achieve
exception condition-based exception handling and error recovery in equipment.
All exception agent implementations shall support the fundamental requirements. This standard provides for two
aspects of fundamental requirements: exception reporting and interactive exception handling. It is possible to
support only exception reporting in systems which do not require interactive exception handling. Interactive
exception handling requires that exception reporting be supported.
10.4.1 Exception Reporting — The fundamental requirements of the exception agent for exception reporting are
based on maintaining the decision authority updated on the exception conditions it is interested in. These are listed
below.
• Detect and report the occurrence of significant abnormal situations by setting the related exception condition,
and posting it if reporting is enabled.
SEMI E41-95 © SEMI 1995 12
• Detect and report that an abnormal situation is no
longer apparent or relevant by clearing the related
exception condition and reporting it if enabled.
• Provide for enabling and disabling reporting on
each exception condition.
• Maintain the data of exception condition attributes
indicated in Table 2.
• Reject requests for capabilities not supported (such
as recovery actions).
10.4.2 Interactive Exception Handling — The
fundamental requirements of the exception agent for
interactive exception handling extend the exception
reporting to allow the decision authority to request
recovery actions to be performed to resolve abnormal
situations. These are listed below.
• Support all exception reporting fundamental
requirements specified above.
• Supply a list of valid recovery actions for an
exception condition when posting.
• Execute a requested recovery action for an
exception condition if the requested recovery
action is currently valid. The exception agent may
support only a single recovery action to be in
progress at a time and reject all other recovery
action requests for other exception conditions
while it is busy.
• Report the completion of the recovery action.
• Support Abort of the recovery action at all times,
immediately ceasing recovery activity and
terminating the recovery action.
• Reject requests with incomplete or invalid
parameters.
• Reject requests for capabilities not supported.
Optional capabilities defined or enabled in this standard
include the following:
• Support for multiple concurrent recovery actions.
The standard allows only one recovery action in
progress for each exception condition.
• Adjust the exception condition message and the
valid recovery action list as appropriate during the
error recovery, and post the changes if reporting is
enabled.
The services are defined with mechanisms to reject
unsupported services and options should they be
requested. This improves robustness and enables
sophisticated service-users to adjust its requests to the
capabilities of the particular exception agent.
NOTICE: These standards do not purport to address
safety issues, if any, associated with their use. It is the
responsibility of the user of these standards to establish
appropriate safety and health practices and determine
the applicability of regulatory limitations prior to use.
SEMI makes no warranties or representations as to the
suitability of the standards set forth herein for any
particular application. The determination of the
suitability of the standard is solely the responsibility of
the user. Users are cautioned to refer to manufacturer’s
instructions, product labels, product data sheets, and
other relevant literature respecting any materials
mentioned herein. These standards are subject to
change without notice.
The user’s attention is called to the possibility that
compliance with this standard may require use of
copyrighted material or of an invention covered by
patent rights. By publication of this standard, SEMI
takes no position respecting the validity of any patent
rights or copyrights asserted in connection with any
item mentioned in this standard. Users of this standard
are expressly advised that determination of any such
patent rights or copyrights, and the risk of infringement
of such rights, are entirely their own responsibility.
Copyright by SEMI® (Semiconductor Equipment and Materials
International), 3081 Zanker Road, San Jose, CA 95134. Reproduction o
f
the contents in whole or in part is forbidden without express written
consent of SEMI.
SEMI E41.1-96 © SEMI 19961
SEMI E41.1-0996
SECS-II SUPPORT FOR EXCEPTION MANAGEMENT STANDARD
1 Purpose
This document maps the services and data of its prime document, SEMI E41, to SECS-II streams and functions and
data definitions.
2 Scope
This is the standard way to implement the Exception Management Standard, which provides remote control
communication of exceptions and recovery, using the SECS-II message format.
3 Referenced Documents
3.1 SEMI Standards
SEMI E5 — SEMI Equipment Communications Standard 2 Message Content (SECS-II)
SEMI E41 — Exception Management (EM) Standard
4 Terminology
None.
5 Mapping of Exception Ma nagement Messages
Table 1 Exception Management Messages SECS-II Mapping
Service Message Name Stream, Function SECS-II Name
EXPost Notify S5F9,F10 Exception Post Notify/Confirm
EXCleared Notify S5F11,F12 Exception Clear Notify/Confirm
EXRecover Request S5F13,F14 Exception Recover Request/Acknowledge
EXRecoveryComplete Notify S5F15,F16 Exception Recovery Complete Notify/Confirm
EXRecoveryAbort Request S5F17,F18 Exception Recovery Abort Request/Acknowledge
6 Exception Parameters Mapping
Table 2 Exceptions Data Item Mapping
Parameter SECS-II Data Item
ErrorCode ERRCODE
ErrorText ERRTEXT
EXAck ACKA
EXEnabled EXENABLED
EXID EXID
EXMessage EXMESSAGE
EXRecovery EXRECVRA
EXState EXSTATE
EXType EXTYPE
Timestamp TIMESTAMP