semi合集-English.pdf - 第1940页

SEMI E54.2-0698 © SEMI 1998, 2004 4 NOTE 2: The device may actu ally consist of multiple devices (e.g., Mass Flow Device inc ludes a Controller device an d a Meter device), in which case multiple s ections should be cr e…

100%1 / 7923
SEMI E54.2-0698 © SEMI 1998, 2004 3
floating point, array of characters, etc. Actual format of
these data types is network-dependent.
6.2.4.2 Optional Service Parameter Table — If this
table is included in the specification of an SDM, the
parameters, which are used by the device' s services, are
defined in it, including the data type and length.
6.2.4.3 Service Definition Table — Each service and its
parameters are defined in a table. If the optional
parameter table is not used in the SDM specification,
then the form field should be included in the service
definition table.
6.3 SANCS Ballots — A ballot to add an ancillary
specification for a new SANCS should be prepared as
defined by the template in the section titled Template
for Part 1 of an SANCS Ancillary Standard.
6.3.1 When a new SDM is added to the SAN standard,
an update to Part 2 of the ancillary SANCS
specifications is needed. A ballot should be prepared as
defined in the template in the section titled Template
for an SANCS ballot to support an SDM.
6.3.2 The nature of the Template for an SANCS ballot
to support an SDM is that it adds SDM information to
only one SANCS specification at a time. Additions and
changes to support each new SDM are balloted
separately for each SANCS specification.
6.3.3 Coordination with Industry User Groups — Most
of the network technologies are supported by an
industry user group or association. These groups are
responsible for the assignment (i.e., mapping) of
identifiers to the variables or attributes, parameters, and
messages/services that will be managed by their
protocol. When the SEMI SAN standards require new
identifiers, they should be requested from the
appropriate industry group.
6.3.3.1 Technical Notes — SEMI will make technical
notes available, for each protocol supported by the
SEMI SAN standards, that list the protocol' s identifiers.
6.4 Template Conventions
6.4.1 Instructions or text that is meant to be replaced
with ballot-specific information are included within the
templates in italics. Non-italicized text and tables are
intended to be included in the ballot as depicted in the
template.
6.4.2 Section, figure, and table numbers specified using
letters are meant to indicate structure and format.
Specific numbers should be generated by the ballot
author. Ballots which require adding to or modifying
existing SAN standards will be edited by SEMI for
consistency with the existing standard where necessary.
7 Ballot Cover Letter Template
7.1 Each ballot is accompanied by a cover letter which
includes the following sections:
7.1.1 Proposal — Provide a brief description, typically
one or two sentences, of the content of the ballot
proposal.
7.1.2 Background — In 1–3 paragraphs, give the
readers the background they need to understand the
content and value of the proposed standard.
7.1.3 Impact — Use one or two paragraphs to describe
how this standard affects the SEMI community.
7.1.4 Ballot Description — Describe the form of the
ballot proposal. Use one or two paragraphs.
7.1.4.1 Note that SDM ballots are additions to the
SEMI SAN SDM Specification (SEMI E54.3). This is a
parent document which already has sections for overall
purpose, scope, terminology, conventions, etc. for
SDMs. Each individual SDM ballot should include only
device-specific purpose, scope, and terminology. Items
that are used in multiple SDMs should be balloted as
updates to the SEMI E54.3 parent document.
8 Template for SDM Ballot Proposals
SEMI Document Number
Title
1 Purpose
Describe the purpose of the document. This is typically
to provide a network-independent application model for
the specific device - NamedDevice.
2 Scope
Describe the scope of the document.
3 Referenced Documents
List documents referenced from within this
specification.
4 Terminology
Define terms used within this document. This is only
for terms that are used within this document and not
defined elsewhere (in the SEMI E54.3 parent document
or other referenced documents).
5 NamedDevice High Level Structure
5.1 General Description — Describe what this device
does, how it is used, etc.
5.1.1 NamedDevice Description — Provide a
description of NamedDevice, including information
model(s) in figure(s) that use a Rumbaugh OMT (see
SEMI E39 Appendix A1-2) diagram.
SEMI E54.2-0698 © SEMI 1998, 2004 4
NOTE 2: The device may actually consist of multiple devices (e.g., Mass Flow Device includes a Controller device and a Meter
device), in which case multiple sections should be created - one per device.
5.1.x General Requirements
5.1.x.1 Device Objects — All objects are defined in terms of their object name and instance identifier. Identifiers
for all objects described in this document are summarized in Table m.
Table m NamedDevice Device Objects
Referenced Document Section Object Name Object Identifier Minimum Instances Maximum Instances
All parameters used by the device' s services can be summarized using the table (Table n). This is optional, as the
parameters are further defined in association with specific objects (see 5.x.2).
Table n Parameter Definition Table
Parameter Name Data Type Tag Description
For each Object in Table m, a section (5.x) is created as below, beginning with 5.2.
5.x Name1 Object
5.x.1 Name1 Object Attributes — Provide the object attribute information using the table (Table o) below.
Table o Object Name1 Attributes
Attribute Name Definition* Attribute Identifier Network Access Form Storage Class Required
* The definition column can be omitted if the definitions immediately follow the table. The definitions can be provided as subsections.
Where appropriate, provide initial and default values for object attributes. This can be done as a table.
5.x.2 Name1 Object Services — Describe the services provided by this object using the following table (Table p) to
list the services:
Table p Object Name1 Services
Service Service Identifier Type Description
Provide a detailed description of each service, including a definition of the parameters for the service. The
parameters can be defined using the following table (Table q) format:
Table q Service1 Service Parameter Definitions
Parameter Request/Indication Response/Confirmation Data Type* Description
* This column can be removed if there is an overall parameter definition table (Table n) included in the specification.
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.