semi合集-English.pdf - 第1937页
SEMI E54.2-0698 © SEMI 1998, 2004 1 SEMI E54.2-0698 (Reapproved 0704) GUIDE FOR WRITING SENSOR/ACTUATOR NETWORK (SAN) STANDARD BALLOTS This guide was technically reapproved by the Global Information & Control Committ…
SEMI E54.1-1000 © SEMI 1996, 2000 42
APPENDIX 2
ERROR RESPONSES
NOTE: This appendix was approved as an official part of SEMI E54.1 by full letter ballot procedure.
The following is a listing of common service error
responses. The details of presentation of these
responses over the network (such as response codes) are
network-specific and, thus, are not part of this
document. Also, note that there may be additional
service error responses delineated in the appropriate
SDM specification or manufacturer specification.
A2-1 Error Responses
A2-1.1 Resource Unavailable — Resources needed for
the object to perform the requested service are
unavailable.
A2-1.2 Service Not Supported — The requested
service is not implemented or is not defined for this
Object Class/Instance.
A2-1.3 Invalid Attribute Value — Invalid attribute data
detected.
A2-1.4 Already in Requested Mode/State — The object
is already in the mode/state being requested by the
service.
A2-1.5 Object State Conflict — The object cannot
perform the requested service in its current mode/state.
A2-1.6 Attribute Not Settable — A request to modify a
non-modifiable attribute was received.
A2-1.7 Device State Conflict — The device’s current
mode/state prohibits the execution of the requested
service.
A2-1.8 Service Parameter Data Not Complete — Not
enough data supplied with the service request.
A2-1.9 Attribute Not Supported — The attribute
specified in the request is not supported.
A2-1.10 Too Much Data for Service Parameters —
The service supplied more data than was expected.
A2-1.11 Object Does Not Exist — The object specified
does not exist in the device.
A2-1.12 Vendor-Specific Error — Vendor-specific
error.
A2-1.13 Invalid Service Parameter — A parameter
associated with the request was invalid.
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 E54.2-0698 © SEMI 1998, 2004 1
SEMI E54.2-0698 (Reapproved 0704)
GUIDE FOR WRITING SENSOR/ACTUATOR NETWORK (SAN)
STANDARD BALLOTS
This guide 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 guide recommends the method, form, and
content for adding specific device models and
associated Sensor Actuator Network Communications
Standard (SANCS) extensions to the SEMI Sensor
Actuator Network (SAN) standard. This guide
facilitates consistency of these ballots, leading to better
consistency and clarity of the resulting specifications
and to easier development of SAN standard-conformant
devices that achieve a high level of interoperability.
2 Scope
2.1 This guide provides written templates for ballots
that will add either a specific device model (SDM), an
SANCS ancillary standard, or SANCS extensions to
support an SDM to the SEMI SAN standards. The
guide provides directions for using the templates.
2.2 Physical devices will not be compliant with this
guide; they will be compliant to standards which are
spawned from the templates specified herein.
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 Referenced Standards
3.1 SEMI Standards
SEMI E5 — SEMI Equipment Communications
Standard 2 Message Content (SECS-II)
SEMI E30 — Generic Model for Communications and
Control of SEMI Equipment (GEM)
SEMI E39 — Object Services Standard: Concepts,
Behavior, and Services
SEMI E54 — Sensor/Actuator Network Standard
SEMI E54.1 — Standard for Sensor/Actuator Network
Common Device Model
SEMI E54.3 — Standard for Sensor/Actuator Network
Specific Device Model for Mass Flow Device
NOTICE: Unless otherwise indicated, all documents
cited shall be the latest published versions.
4 Terminology
4.1 Abbreviations and Acronyms
4.1.1 A — Actuator (a CDM class definition)
4.1.2 AE — Active Element (a CDM class definition)
4.1.3 C — Controller (a CDM class definition)
4.1.4 CDM — (SEMI) Common Device Model
4.1.5 DM — Device Manager (a CDM class definition)
4.1.6 ISO-OSI — International Organization for
Standardization - Open Systems Interconnect (model)
4.1.7 NCS — Network Communications Standard
4.1.8 OMT — Object Modeling Technique
4.1.9 S — Sensor (A CDM object)
4.1.10 SAC — Sensor/Actuator/Controller (a CDM
class definition)
4.1.11 SAN — Sensor/Actuator Network (or Sensor
Bus)
4.1.12 SANCS — Sensor/Actuator Network
Communications Standard, frequently abbreviated to
NCS
4.1.13 SDM — (SEMI) Specific Device Model
4.2 Definitions
4.2.1 connection oriented — a situation between
communicating objects wherein they are connected in a
mode analogous to a two-way phone conversation.
4.2.2 specific device model (SDM) — a model used to
specify each type of device, such as a Mass Flow
Controller or Thermocouple.
5 Background
5.1 The SEMI sensor bus (SAN) communications
model consists of three components: a CDM, an SDM,
and an SANCS (NCS). The following subsections
provide a brief description of the specifications which
define these components:
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,