semi合集-English.pdf - 第1891页

SEMI E54-0705 © SEMI 1997, 2005 7 RELATED INFORMATION 1 APPLICATION NOTES NOTICE : The material contain e d in these Applicat ion Notes is not an of ficial part of SEMI E54 and is not intended to modify or supersede the …

100%1 / 7923
SEMI E54-0705 © SEMI 1997, 2005 6
Therefore, each NCS is also a specification that grows over time. As new device models are developed and
approved, a mapping of the model to a network technology is added to a NCS.
7.1.5 Auxiliary Information — Auxiliary information may be included with the standard in the form of appendices
or technical notes. Generally, this information is not balloted, but is included as provided by the SEMI Standards
Program regulations. Auxiliary information shall always be noted as such when it accompanies a specification or
ballot.
7.2 Interoperability
7.2.1 At the Applications Level — The SDMs are used to derive the definitions for attributes, services, and behavior
that are unique to each device type. A model may discuss relationships internal to a device to provide additional
meaning to the services and attributes that can be manipulated over the network. Applications written to these
models can operate a device independent of the network on which they communicate. The models shall assure that
devices of different types can operate cooperatively at the applications level.
7.2.2 Below the User Layer — The various SANCS specifications describe the method by which a device
communicates over a specific network such that it can meet the requirements of its type. All devices described
within an NCS shall operate cooperatively on that specific network technology below the user layer.
7.2.3 The SEMI SAN standard does not address methods for internet-working below the applications layer, as
described herein. An application entity may connect to more than one network. This could be typical of the
application entities on the equipment controller. While the SAN standard allows that application entities could exist
at any network node, it requires no mechanism for a message that begins on one network to be routed to another
network.
7.3 SEMI SAN Compliance — To fully describe the characteristics of a network capable device, its compliance
shall be specified by reference to the SAN ancillary standards. Thus, a device indicates both its type and network
technology for its SDM and a NCS.
7.3.1 For a device to be compliant to the SAN standard, it shall implement all of the required attributes, behavior,
and services as described in the SAN CDM.
7.3.2 Type or Applications Model Specification — The SDM of a device (which is its type, e.g., MFC or
thermocouple) shall be denoted by SEMI E54.y, where “y” indicates the SDM ancillary standard.
7.3.3 Network Communication Specification Communication (protocol) compliance specification of a device is
denoted by SEMI E54.x, where “x” is the network communications ancillary specification.
NOTICE: SEMI makes no warranties or representations as to the suitability of the standard 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.
SEMI E54-0705 © SEMI 1997, 2005 7
RELATED INFORMATION 1
APPLICATION NOTES
NOTICE: The material contained in these Application Notes is not an official part of SEMI E54 and is not intended to modify or
supersede the official standard. Rather, these notes are auxiliary information included as reference material for implementers of
the standard. The standard should be referred to in all cases. SEMI makes no warranties or representations as to the suitability of
the material set forth herein for any particular application. The determination of the suitability of this material for any particular
purpose is solely the responsibility of the user.
R1-1 Implementing a SAN Standard-Compliant Device
R1-1.1 This Related Information section describes how the SAN standard is used by a device supplier who wishes
to offer SEMI SAN-compliant devices to the market.
R1-1.2 While the SAN standard may appear overwhelming on first viewing, it is actually built from independent
components. It is not necessary to understand or ‘know’ the entire standard. It can be dealt with in small pieces. For
device suppliers, only the pieces that deal with their particular device type need to be considered. The specifications
to implement a specific device are typically less than thirty pages of text. The standard is structured such that it is
extensible while providing the ability to specify a device by reference to the standard.
R1-1.3 Synopsis of Device Operation — All devices on a SAN have a similar operational profile. That profile is
specified in SEMI E54.1 (Standard for Sensor/Actuator Network Common Device Model) and in the Common
Device Model support section of each NCS.
R1-1.3.1 Table R1-1 explains where to find specifications for various device operations.
Table R1-1
Operation Spec.
Power applied CDM
Enable SAC CDM
Enable DM CDM
Enable Communications NCS
Establish Communication NCS
Send Events CDM
Receive messages/answer CDM
Send messages/accept CDM
R1-1.4 Device Type — Each type of device is specified in the SDM specifications. One SDM is devoted to each
device type. An SDM is always a specialization of the CDM. The SDM provides services, behavior, and attributes
that are in addition to those specified in the CDM. For example, the SDM of a manometer might specify attributes
for current pressure and alarm bands. It might have services needed for performing calibration.
R1-1.5 Network Technology — How a network technology is used by the SAN standard is specified in an NCS.
The NCS for a technology provides a mapping of the CDM and SDM of a device type to a specific network
protocol.
R1-1.5.1 It is only necessary for a device to support an NCS and the section for its type within that NCS. The NCS
provides all that is needed to ensure that a device can communicate and interoperate across a given network
technology. The point is that from the other side of the wire, the network-independent interface is not visible. That
interface is implied by the behavior of the network interface.
R1-1.6 Network Independence — Device suppliers have the option of supplying an interface at the protocol-
independent applications layer, as indicated in Figure 1. While this requires more implementation work for the
device supplier, it speeds the integration of sensors and actuators for the OEM.
SEMI E54-0705 © SEMI 1997, 2005 8
R1-1.6.1 In this case, it is still necessary for the device to support the NCS to ensure that their device will
interoperate with other devices on the network.
R1-1.6.2 To supply this option, a device supplier would provide a device driver-like interface (software) to the
OEM.
R1-1.6.3 Devices that supply a protocol-independent API that is compliant to the SEMI SAN standard provide
advantages to both device and control system suppliers. The device supplier can assure that his device receives
syntactically correct messages at his network interface layer. Control applications written to the protocol-
independent interfaces have the advantage that they would not have to be rewritten in order to change to another
network. To achieve this, device suppliers would have to ship software, in the form of ‘device drivers’, that would
be installed on the control supplier's platform.
NOTE 1: Standards for these ‘device drivers’ may be developed at a later time as they do not currently exist. However, most
operating systems used by control systems suppliers support installable device drivers.
R1-1.7 Recommendations on Optional and Extended Device Capabilities — It is expected that device suppliers
would not compete based on their network interface. Devices traditionally compete based on cost, service, stability,
reliability, accuracy and repeatability, and relevant dynamic attributes. From a network perspective, all devices have
these common characteristics: periodic reporting, polled reporting, asynchronous event reporting, calibration, health,
and diagnostic reporting. Access and control over the common characteristics should be implemented based on the
SAN standard. Access and control of the competitive characteristics of devices may be implemented with supplier-
specific interface extensions. However, the device supplier is strongly cautioned in the use of these extensions.
Heavy use of extensions could be a serious competitive disadvantage unless the supplier is the clear winner in all the
competitive characteristics. A locked door could lock one in, it could also lock one out. Device suppliers will usually
find that their extensions can be implemented using the optional features of the CDM and SDM.
NOTE 2: Network interfaces could be a competitive factor during the early technology adoption phase.
R1-1.8 The Controller Side Usage of the SAN Standard — The control system supplier (in many cases this is the
OEM) evolves a different view of SEMI’s SAN standard. They are not as concerned with the network technology as
with utilizing the applications capabilities as specified by the CDM and SDMs. It is strongly recommended that
control applications not be network aware. This may produce some operating overhead, but for most applications,
this is a good trade-off to gain flexibility provided by a protocol-independent interface. Many network devices may
be supplied without any user layer (device driver) application side software. For these devices, the control system
supplier would have to do some system’s programming to provide a device driver for the application interface. Over
time, it is likely that most devices will be delivered with a device driver. (Similar to the way printers are sold with
Windows (TM) device drivers. This is what allows Windows applications to use a printer of the end users choosing.)
R1-1.8.1 The standards as of 1996 do not provide all the specifications needed to uniquely define how device
drivers would be installed in the controller side of the API. This may become a future area of standardization, if
OEMs decide to invest in the standard’s development time.
R1-1.9 Device Intelligence — This varies considerably between device types and between devices of the same type.
SEMI SAN specifications attempt to allow a range of intelligence to devices without forcing them to be ‘highly’
intelligent. To this end, the applications models specify a required minimum set of capabilities that must be
supported for a device. Optional capabilities generally require more intelligent device operation. Devices that are not
capable of supporting these extended capabilities provide a “not implemented” indication if access to those
capabilities is requested.
R1-1.9.1 The following subsections describe device capabilities in order of increasing intelligence. A device’s I/O
direction is defined relative to the control application entity. Therefore, a sensor is an input, even though from the
sensor’s point of view it supplies output values.
R1-1.9.2 Polled input is the simplest sensor device requirement. All sensing devices should meet this requirement.
In this mode of operation, a device only reports its value(s) when requested. This mode potentially provides the
biggest burden on network bandwidth. However, it is the capability level that is most compatible with current
control system architectures.
R1-1.9.3 Strobed output is the simplest actuator device requirement. All actuating devices should meet this
requirement. This device only changes to a new state at the time of receipt of a specific message to do so.