semi合集-English.pdf - 第1943页
SEMI E54.2-0698 © SEMI 1998, 2004 7 8 Protocol Compliance This section s hould specify a m ethod or reference for testing prot ocol compliance. It s hould contain in subsection 8.1 a “protocol specification sh eet” that …
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.
SEMI E54.3-0698 © SEMI 1998, 2004 1
SEMI E54.3-0698 (Reapproved 0704)
SPECIFICATION FOR SENSOR/ACTUATOR NETWORK SPECIFIC
DEVICE MODEL FOR MASS FLOW DEVICE
This specification was technically reapproved by the Global Information & Control Committee and is the
direct responsibility of the North American Information & Control Committee. Current edition approved by
the North American Regional Standards Committee on March 14, 2004. Initially available at www.semi.org
May 2004; to be published July 2004. Originally published June 1998.
1 Purpose
1.1 This specification is part of a suite of standards
which specify the implementation of SEMI standards
for the Sensor/Actuator Network. The specific purpose
of this specification is to describe a network-
independent application model comprised of device
objects which are common to all Mass Flow Devices on
a semiconductor equipment Sensor/Actuator
communications network.
2 Scope
2.1 This specification specifically addresses the
minimum attributes, services, and behavior a Mass
Flow Controller (MFC) and Mass Flow Meter (MFM)
device must support to be interoperable on the
Sensor/Actuator Network.
2.2 This specification is intended to ensure a high-
degree of device interoperability on the Sensor/Actuator
Network, while still allowing flexibility for product
differentiation and technology evolution.
2.3 The model specified in this specification is used in
conjunction with the Sensor/Actuator Network
Common Device Model (CDM) to completely describe
the MFC or MFM as it appears from the network
interface.
2.4 This specification, together with the
Sensor/Actuator Network Standard, the
Sensor/Actuator Network Common Device Model, and
a Sensor/Actuator Network Communication
Specification, form a complete interoperability
specification for the MFC and MFM.
2.5 To comply with this specification, a device must
implement and support, at a minimum, the required
attributes, services, and behavior identified in these
documents. Support for optional attributes, services,
and behavior are not required to be compliant to this
specification. Optional attributes, services, and behavior
are specified in these documents to promote further
device interoperability as features evolve and are
adopted by more manufacturers. If optional attributes,
services, and behavior are implemented for this device,
they must be implemented as identified in this
document.
NOTICE: This standard does not purport to address
safety issues, if any, associated with its use. It is the
responsibility of the users of this standard to establish
appropriate safety and health practices and determine
the applicability of regulatory or other limitations prior
to use.
3 Limitations
3.1 This specification is a companion to a suite of
specifications which together make up the
Sensor/Actuator Network Communication standard.
Therefore, using portions of this specification that relate
to network communications necessarily requires an
understanding of the associated network specification.
3.2 As this document is a specification for the Mass
Flow Device Model, it does not contain any definition
of objects, attributes, services, or behavioral
descriptions that are already defined in the
Sensor/Actuator Network Common Device Model
(CDM). Additional attributes, attribute assignments,
services, and/or service parameters that are Mass Flow
Device-specific and/or implementation-specific are
contained in this specification.
3.3 While this specification is sufficient to completely
describe the MFC or MFM as it appears from the
network, it does not fully describe behavior of the MFC
or MFM which is not visible from the network. This
allows flexibility in implementation techniques and
product differentiation between manufacturers.
Manufacturer-specific objects may be defined by the
manufacturer, but are, by definition, outside the scope
of this standard.
3.4 This specification is compatible, but not compliant,
with SEMI E39. This means that although this
specification does not require compliance with SEMI
E39, it is extensible such that implementations may be
developed that are fully compliant with both standards.
Note that the concepts and terminology of this
specification are compatible with those of SEMI E39.
However, SEMI E39 has specific requirements that are
intended for higher level applications and, thus, are not
applied to the Mass Flow Device Model.