semi合集-English.pdf - 第1893页

SEMI E54-0705 © SEMI 1997, 2005 9 R1-1.9.4 Periodic input is the capability to program the inpu t device so that it sends its value(s) on a schedu led or periodic basis. Network bandwidth burden is reduced because it is …

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.

SEMI E54-0705 © SEMI 1997, 2005 9

R1-1.9.4 Periodic input is the capability to program the input device so that it sends its value(s) on a scheduled or

periodic basis. Network bandwidth burden is reduced because it is not required to send a request each time an update

for the input value is needed.

R1-1.9.4.1 This is also very compatible with current control architectures.

R1-1.9.5 Asynchronous input provides a capability for a sensing device to supply its value(s) when an event is

detected. These events are usually programmed into the device. Examples of programmable events include threshold

crossing of a value, value rate of change, measurement complete.

R1-1.9.5.1 Devices with this capability can significantly reduce network bandwidth burden, because they only need

the network when some event has occurred. Equipment control architectures developed before 1990 may not be able

to utilize this type of capability.

R1-1.9.6 Programmed output provides the capability for actuating devices to follow a programmable sequence of

operations. For instance, an analog output could be given a ramp profile to follow as it moves between set points.

R1-1.9.6.1 This is another capability which can greatly reduce network bandwidth requirements. But, it is also a

capability that 1990 vintage and earlier control systems may not be able to utilize easily.

R1-1.9.7 Devices with distributed processing capabilities are able to support features such as monitoring their

health, providing diagnostics, and programmable preprocessing of data.

R1-1.9.7.1 These capabilities can have an impact on network burden, but more importantly may improve equipment

reliability and maintainability. Again, this is a capability that is not readily utilized by control architectures

developed prior to 1990.

R1-1.9.8 Devices with distributed control capabilities are capable of being programmed to create peer relationships

with other devices on the network. Within these relationships, it is possible for one or more of the peers to control or

regulate a subsystem within the equipment. For instance, a butterfly valve and manometer with these capabilities

could be programmed to hold a particular pressure.

SEMI E54-0705 © SEMI 1997, 2005 10

RELATED INFORMATION 2

INDEX FOR SENSOR/ACTUATOR STANDARDS

NOTICE: This related information is not an official part of SEMI E54 and is not intended to modify or supercede the official

standard. After approval of this document, publication of this Related Information was authorized by the committee chairs solely

to aid in identifying the relationships between the current Sensor Bus standards and documents in process. Determination of the

suitability of the material is solely the responsibility of the user.

R2-1 Scope

R2-1.1 The table below is based on Figure 1 in SEMI E54.1, and is intended to show the relationships between

standards that are currently published, as well as describe documents in process in SEMI Standards that, if approved,

will be added to SEMI E54.

R2-1.2 There are five categories:

Main Document

Templates

Specific Device Model

Common Device Model

Network Communication Standards

R2-1.3 Standard titles with a designation number are published documents, and descriptors without designation

numbers are documents in process.

Table R2-1 Sensor/Actuator Network (SAN) Standards

SEMI E54, Sensor/Actuator Network (SAN) Standard

Templates (How to Write Network Communications Standards (NCS) and Specific Device Models (SDM))

Specific Device Models Common Device Models Network Communications Standards

SEMI E54.4, Standard for SAN

Communications for DeviceNet

SEMI E54.5, Standard for SAN

Communications for the Smart Distributed

System (SDS)

Mass Flow Controller SDM

SEMI E54.1, Standard for Sensor/Actuator

Network Common Device Model

SEMI E54.6, Standard for SAN

Communications for LONWorks

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.

International), 3081 Zanker Road, San Jose, CA 95134. Reproduction of

the contents in whole or in part is forbidden without express written

consent of SEMI.