semi合集-English.pdf - 第1887页

SEMI E54-0705 © SEMI 1997, 2005 3 Figure 1 SEMI SAN Protoc ol Layers 5.2 Generally, the functionality of a softwa re layer is embodied by the definition of t he services it provides. Its services are the set of messages …

100%1 / 7923
SEMI E54-0705 © SEMI 1997, 2005 2
4.1.4 IDL — Interface Definition Language. A programming language-independent notation for specifying
interfaces.
4.1.5 ISO — International Organization for Standardization.
4.1.6 NCS — Network Communication Standard. Provides the specification for mapping the CDM and SDM to
specific network technologies. These standards will be incorporated as parts of the SEMI SAN standard.
4.1.7 OEM — Original Equipment Manufacturer. They are usually the control system developer, but in any case
they are almost always responsible for the control system.
4.1.8 OMT — Object Modeling Technique. A methodology developed by James Rumbaugh, et al. for using objects
to model systems.
4.1.9 OSI — Open System Interconnection. A seven-layer model for communications developed by ISO.
4.1.10 OSS — Object Services Standard. SEMI E39.
4.1.11 SAN — Sensor/Actuator Network. It is frequently used to reference this standard.
4.1.12 SDM — Specific Device Model. This is an application model for a specific type of sensor, actuator, or entity.
4.2 Definitions
4.2.1 application — for software, this is a working series of computer instructions that provide end user services.
4.2.2 applications model — a formal description of the software elements and interactions that perform an end user
task.
4.2.3 entity — in software engineering, this is something that is recognizable as distinct and particular from the
other things that make up a software system or program.
4.2.4 interface — in information modeling, it is the boundary between two entities from which information will
flow.
4.2.5 user layer — in communications, this is a set software function connected to the communication protocol's
top layer, usually called the applications layer, from the user’s application environment. It typically allows the user
application to be protocol-independent.
5 Overview
5.1 Referring to Figure 1, the SAN standards specify a complete communications solution covering all the layers of
the OSI reference model. The CDM and SDM together specify a protocol-independent set of application services,
attributes, and behavior for a device that must be supported by the user layer as shown in Figure 1. An NCS
completes the specification of the user layer by specifying a mapping to a network technology’s interface. The NCS
must specify its capabilities referenced against the ISO OSI Reference Model. An NCS may utilize an open or
commercial solution. In any case, the NCS will provide references to those solution’s specifications.
SEMI E54-0705 © SEMI 1997, 2005 3
Figure 1
SEMI SAN Protocol Layers
5.2 Generally, the functionality of a software layer is embodied by the definition of the services it provides. Its
services are the set of messages it generates and to which it responds, and its subsequent behavior upon receipt of
any particular message. The CDM and an SDM provide a complete user layer specification in a platform and
language-neutral form (dotted line in Figure 1). The goal being to provide device interoperability at the applications
level. The NCS will guarantee interoperability at the network level (i.e., across a single type of network). The SAN
standard does not require implementation of the top interface to the user layer, as specified by the CDM and an
SDM. The CDM and an SDM provide the information needed to develop an NCS, which defines the interface
requirement between the user layer and a specific network technologies communication layer (the solid line labeled
as Network Interface). This means that the SAN standard allows user applications, whether from the device or the
controller side implementation viewpoint, to interact directly with a network technologies interface.
5.3 Network Technology Supplier View of the SAN Standard
5.3.1 The CDM and an SDM together specify the messages, behavior, and attributes of a device type that will be
visible over the network. In Figure 1, this is the area above the line that indicates the protocol-independent interface.
Network suppliers will map this information to the top layer of their protocol. They do this by helping to develop
and extend their NCS.
5.3.2 Most network suppliers have an application layer already defined for their protocol. In that case, the user layer
as specified in a SEMI SAN NCS is quite thin. In fact, it is just a simple mapping of SDM interface to messages and
data (attributes) provided by the network. Thus, an NCS (one for each supported network) specifies a user layer that
sits on top of the network supplier’s protocol.
5.4 Device Supplier View of the SAN Standard
5.4.1 Device suppliers are not required to implement designs illustrated in the specific device model (SDM)
specifications. The designs are presented using an object-modeling notation as a means to clearly specify the devices
interface. An SDM provides a model of a device, it is not a design for the device. Device suppliers are not expected
to provide an object-oriented implementation. However, in order to ensure that a device interface responds as
expected, it is necessary for the device supplier to not only provide the support for the services and attributes
specified, but to ensure that the code that is implemented on the device behaves as specified by the applications
model for a specific device type.
5.5 Equipment Supplier View of the SAN Standard
5.5.1 The OEM’s have the largest task in adopting the SAN standard. They have to implement applications that use
the interfaces defined for the many devices that make up the typical equipment control system. They have to be
SEMI E54-0705 © SEMI 1997, 2005 4
familiar with the interfaces of a large number of the SDMs. On the other hand, they will become insulated from the
inner workings of many devices, and from the code that they used to write to support those inner workings. In many
cases, they may have to implement more than one Network Communication Standard.
5.5.2 During early adoption, OEM’s may look to the SAN to act as a replacement for memory mapped discrete
wired IO. With this type of adoption, the OEM will not lessen his burden of control code.
5.5.3 As Sensor Bus becomes more broadly adopted, OEM's may take advantage of the distributed processing
capability offered by intelligent devices to reduce the complexity of their control software.
5.6 The SAN Standard Structure
5.6.1 A SAN employs devices from numerous sup-pliers. The SEMI SAN standard provides a framework to ensure
interoperability of these devices within a network. The standard enables device suppliers and equipment control
system developers to achieve that end. The SAN standard comprises five specifications.
5.6.2 The first specification is this document, which is the root document and specifies the connection between the
other documents of the standard. It also specifies the construction for each of the other documents.
5.6.3 The next specification is the Common Device Model Specification. Each device on the SAN must comply
with this specification.
5.6.4 The third specification defines the templates for creating ballots for specific device models and additions to
the NCS.
5.6.5 The fourth specification is Specific Device Models standard. These standards contain models for various types
of sensors, actuators, and entities. For instance, a model of a mass flow controller, a manometer, and a thermocouple
will be specified.
5.6.6 The fifth type of specification is the Network Communication Standards. Each network technology has its
own standard as an ancillary specification to the SAN standard.
5.6.7 Applications notes may accompany a number of the standards documents and are intended to guide
implementors in the application of the standard.
6 Concepts
6.1 Minimal device — The SAN specifications allow simple and complex devices to be built compliant to the
standard. This is done by specifying a minimum of required attributes, services, and behaviors in an SDM. The
SDMs may also provide optional service definitions that must be followed if extended capabilities are to be built
into a device. Devices that do not implement the extended capabilities must respond to extended service or access
requests with an appropriate response code rather than failing to respond or issuing an exception or alarm message.
6.2 Many of the SAN NCS specifications rely on commercial technology. A significant number of network
technologies are available off-the-shelf. The standards do not prescribe a choice. Once a technology described in an
NCS is chosen, the NCS specifies how it is to be applied. The SAN standard is easily extensible for future
technologies.
6.3 A device supplier must be able to use the standard to describe a device with little or no ambiguity for the device
users. For the user, this means that he can select a device with confidence and that it can be easily integrated with his
control system. The user must understand the electrical interface, the capabilities, and messages which a device
supports based on the supplier’s description of how this standard is supported by the device.
7 Requirements
7.1 Organization of the SAN Specifications — Figures 2 and 3 are intended to assist in understanding the document
relationships that are specified in the following subsections. In these figures, all specifications that are standards are
drawn as rounded rectangles. In Figure 3, the shadowed rectangles indicate the standards that contain requirements
for implementing devices that are compliant to this standard.