semi合集-English.pdf - 第1892页

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 t o ensure that their device will interoperate with other devices on the networ k. R1-1.6.2 To supply this …

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.

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.