semi合集-English.pdf - 第1939页
SEMI E54.2-0698 © SEMI 1998, 2004 3 floating point, array of characters, etc. Actual format of these data type s is network-dependent . 6.2.4.2 Optional Service Parameter Table — If this table is included in the specific…
SEMI E54.2-0698 © SEMI 1998, 2004 2
5.1.1 Network Communications Standard Specification
— An NCS specification is required for each network
technology. Each one consists of two major parts:
5.1.1.1 Part 1, Enabling Protocol and CDM Object
Presentation — This part of an SANCS specification
should achieve the following goals:
• provide an ISO-OSI layered specification of the
protocol, specifying the protocol requirements at
each layer,
• specify the object oriented communication
environment, including object representation and
addressing, attributes and services addressing, etc.,
• specify how CDM objects are represented and
addressed to/from the network, and
• specify how AE class and subclass objects, defined
in the CDM and the SDMs, are represented and
addressed to/from the network.
5.1.1.2 Part 2, Enabling Specific Device Models —
This part provides a mapping of SDM objects for the
SANCS specification. There should be a section for
each SDM which identifies specific objects that must be
supported to enable the SDM and how the SDM
structure fits into the protocol application layer
foundation.
5.1.2 Common Device Model — Each device’s
functions on a network should comply with the
specifications of the Common Device Model, SEMI
E54.1. Three types or classes of objects may be
combined to create models of real devices. The types
are Active Element (AE) and its subclasses,
Sensor/Actuator Controller (SAC) and its embedded
objects, and the Device Manager (DM).
NOTE 1: The CDM specifies the relationship between these
objects. It specifies some of the structure and behavior for the
DM and SAC objects. The subclasses of the AE object
provide capabilities which are useful to most devices.
5.2 Specific Device Model
5.2.1 Specific Device Models are defined in the SEMI
SAN SDM (SEMI E54.3). Each SDM is added as a
separate new section (similar to the way a new section
is added to SEMI E5 when a new stream is added).
5.2.2 The Specific Device Models (SDM’s) should be
a specialization of the CDM and may extend the
attributes, services, and behavior of any of the Sensor,
Actuator, or Controller (subclasses of the AE class)
objects of which they are made. SDM’s may add to the
attributes, services, and behavior of the SAC object.
6 Ballot Preparation
6.1 The Cover Letter — All ballots are submitted with
a cover letter. The cover letter sets the context for the
ballot. The Ballot Cover Letter Template provides
guidance to prepare the cover letter.
6.2 Specific Device Model Ballots — A ballot to add an
ancillary specification for a new SDM should be
prepared as defined in the template in the section titled
Template for SDM Ballot Proposals.
6.2.1 SEMI E39 is the basis for the tables and figures
called out in the template. Refer to SEMI E39 for
clarifications on using and defining object models.
General instructions for using the template are
contained in the subsections of this section. Specific
instructions are included within the templates.
6.2.2 Device application models should be presented
using Rumbaugh’s Object Modeling Technology
notation for information models. (See SEMI E39 for
details on using object notation for defining standards.)
6.2.3 The behavior of objects should be defined using
Harel State charts, state definition tables, and state
transition tables. A discussion of the notation may be
found in Appendix A.5 of SEMI E30. An alternative
table, Object Behavior State Transition Matrix, may be
used in place of the more traditional (State) Transition
Table. Cells in the Transition Matrix indicate the
transition action which is taken for an event for any of
the states in which it can be detected. This can be
particularly useful for describing the variation in device
response depending on a sub-state when the parent state
detects an event.
6.2.4 The set of tables which define the device’s
interfaces are the only testable parts of the specification
for the application models. The interface for each
device model should be defined in a series of tables, as
follows:
6.2.4.1 Attribute Tables — For each object defined as
an element of a device, a table which defines its
network visible attributes should be specified. Each
attribute is named and tagged. Its network access type
(read only or read/write) and storage class (volatile,
non-volatile, or constant) are also specified. The table
should also indicate which attributes have standardized
values and which are device supplier reserved. The
definition or description of an attribute can either be
included in the table or else should immediately follow
the table. The “Required” column indicates if the
attribute must be supported for a device to be SDM-
compliant. Use the letter “Y” to indicate yes and the
letter “N” to indicate no. The form field is used to
indicate the data type of the attribute, such as integer,
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.