semi合集-English.pdf - 第1942页
SEMI E54.2-0698 © SEMI 1998, 2004 6 5 Terminology The various p rotocols and t he CDM invariably use different terminology. A m apping is m ade between the CDM terminology and the ter minology used in discussing the prot…
SEMI E54.2-0698 © SEMI 1998, 2004 5
5.x.3 Name1 Object Behavior — Describe the object states and sub-states as needed with a Harel State Diagram(s):
Figure
Harel State Diagram
Provide a state definition table as given in Table r. More than one state table could be added if a device is
sufficiently complex. Put in any text needed to explain object states.
Table r Name1 Object Behavior State Descriptions
State Name Description
Describe the state transitions using a table as given in Tables s or t. More than one table could be needed.
Table s Name1 Object Behavior State Transition Table
Event or Transition # Current State Trigger New State Action(s) Comments
Table t Name1 Object Behavior State Transition Matrix
State 3
Event Number State 1 State 2
Sub A Sub B
1
2
3
4
9 Template for Part 1 of an SANCS Ancillary Standard
9.1 The body of the ballot should then contain the following sections:
1 Purpose
This section contains wording describing the purpose with customization for the specific protocol. A “Background
and Motivation” subsection could be included to generally describe the protocol.
2 Scope
This section contains wording describing the scope with customization for the specific protocol.
3 Limitations
This section contains wording describing the limitations customized for the specific protocol. Any limitations of
CDM or SDMs support, due to the protocol, should be identified.
4 Referenced Documents
This section contains wording describing the referenced documents with additional references to protocol
specification documentation and any support documentation as required for complete specification of the protocol
(two subsections). A clearly defined mechanism is specified for obtaining any documentation that is not publicly
available or available from SEMI.
SEMI E54.2-0698 © SEMI 1998, 2004 6
5 Terminology
The various protocols and the CDM invariably use
different terminology. A mapping is made between the
CDM terminology and the terminology used in
discussing the protocol. For example, a CDM Service
implementation may be defined as an Action in the
NCS. This terminology mapping is explicitly covered
completely in the “Terminology” section. A mapping
table is desirable that contains a column listing of the
CDM terms in the same order as defined in the CDM
document, mapped to terminology used in the NCS
document. This NCS terminology and any additional
terminology is defined in a subsection (e.g., Section
5.2).
6 Communication Protocol High Level Structure
A basic description of the protocol is provided in
Section 6. The main purpose of Section 6 is to give the
reader a general understanding of what will be
specifically presented in the remainder of the
subsections in Section 6.
The rest of the subsections in Section 6 should be
devoted to describing the communications standard in
terms of the OSI seven-layer model (one subsection for
each layer) and any network management services.
Each of the OSI seven layers should be addressed and
specified either directly or through reference; for each:
• If an OSI layer is not supported/defined, this is
stated explicitly.
• Choices among protocol options are made,
specified, and explained where appropriate. A
complete summary of protocol choices specified
and protocol options allowed should be
summarized in a subsection of this section of the
specification.
The Physical
layer is specified either directly or through
reference (signaling, bus arbitration, baud rate,
transceivers, cabling, connectors, etc.).
The Data link layer is specified either directly or
through reference (packet/frame specification and node
addressing).
The Network
layer is optional.
The Transport
layer elements are specified either
directly or through reference; message segmentation
and reassembling should be supported as no message
length limits are indicated in CDM or SDM' s. This
support should be provided as a transport layer service.
Note that this functionality may alternatively be
provided at the application layer by protocols unable to
support it at the transport layer; if this is the case, it is
explicitly stated in the description of transport layer
support. Connection support would be specified here as
appropriate.
The Session
layer is optional.
The Presentation
layer is optional.
The Application
layer is specified. The document
defines (explicitly or through reference) how objects
are structured, identified, and addressed. Thus, it should
also define how object attributes are addressed and how
object request and notify services are addressed and
communicated. This section also defines the application
object to object communication mechanism which
should include or reference a communication state
model. This communication model should clearly
indicate whether or not the protocol is connection
oriented.
Network Management Services
may be defined in a
separate subsection.
7 Required Object Types
This section identifies specific objects that must be
supported to enable the CDM. The document should
identify how the CDM structure (Objects and relations)
fits into the protocol application layer foundation. Any
identifiable protocol object hierarchy should be
introduced here. Specifically, the following are defined:
• The implementation of all CDM objects (DM,
SAC, AE, and all subclasses) defined to the extent
that these objects are defined in CDM
documentation.
• Specific addressing/referencing for CDM objects
(attributes, services, etc.) defined as necessary so
as to specify access to CDM objects as required by
the CDM standard specification. Attributes and
services are further specified as necessary so that
the protocol required to access specific attributes
and services is fully defined. For example, a CDM
service may be defined as a “new” SANCS service
or mapped to an existing SANCS service (if an
appropriate candidate has already been defined in
the protocol specification).
• Any limitations among CDM object options are
identified.
• Any additional capabilities required of, or optional
for, CDM objects (e.g., attributes, services, and/or
behavior) are identified.
• Any additional required objects (e.g., network
management object) identified and their interaction
with the CDM objects (e.g., connection
management object) should be specified.
SEMI E54.2-0698 © SEMI 1998, 2004 7
8 Protocol Compliance
This section should specify a method or reference for
testing protocol compliance. It should contain in
subsection 8.1 a “protocol specification sheet” that lists
all protocol options that have been specified in the
document or must be resolved by the user in order to
achieve interoperability.
10 Template for an SANCS Ballot to Support
an SDM
Section 1 Table of Contents
Request that the table of contents for the SANCS be
updated to contain a pointer to the paragraphs which
specify the SDM mappings which are being added by
the ballot.
Section 2 <SDM> Object Mapping
Each of the subsections within this section should
identify specific objects that must be supported to
enable the SDM and should identify how the SDM
structure (objects and relations) fits into the protocol
application layer foundation.
Specifically, the following issues are addressed:
Terminology
• A mapping is made between the SDM terminology
and the terminology used in discussing the
protocol. This is explicitly covered in a
“Terminology” section. A mapping table is
desirable that contains a column listing of the SDM
terms in the same order as defined in the CDM
document, mapped to terminology used by the
network technology.
Required Object Types
• Address implementation of all SDM objects to the
extent that they are defined in SDM
documentation.
• Identify and map the specific addressing/refer-
encing for SDM object attributes, services, and
parameters to the protocol. Note that, for example,
this may be achieved by fully specifying a SDM
service as a “new” NCS service or by mapping the
service to an existing NCS service.
Protocol Compliance
• Provide methods or references (in addition to those
identified in the section titled Template for Part 1
of an SANCS Ancillary Standard, Section 8) for
testing protocol compliance of the SDM.
NOTICE: 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.