semi合集-English.pdf - 第1988页
SEMI E54.5-0997 © SEMI 1997, 2004 4 Figure 3 Protocol Arc hitecture SDS uses a thr ee-layer prot ocol stack consi sting of the physical, datal ink, and application lay ers. The SDS physical layer uses two twisted pair to…
SEMI E54.5-0997 © SEMI 1997, 2004 3
h) state diagram
i) byte
j) nibble
k) character string
5.2 SDS-Specific Definitions — In addition to the
above terms, the following terms are defined for SDS
networks.
5.2.1 actions — operations that a client may request
an Embedded Object to perform. The action typically
modifies the state of the device. Actions are more
powerful than writing to an attribute, in that multiple
input arguments may be provided as part of an action
request. Also, results of the action are typically
returned. Actions, like attributes, have identifiers that
are specific to the type of the object. However, these
identifiers are independent from attribute or event
identifiers. The “request” services specified in SEMI
E54 are implemented as SDS actions.
5.2.2 controller area network (CAN) — a protocol
developed by the Bosch corporation for automotive in-
vehicle networking. The CAN specification specifies
OSI reference model layers 1 and 2, specifically the
physical signaling and media access/data link protocols.
5.2.3 embedded objects — each SDS Logical Device
contains at least one, and at most 32, Embedded
Objects. An SDS Embedded Object is an abstraction
representing an addressable entity “embedded” within a
Logical Device having specific application-related
interface characteristics. These characteristics include a
defined set of attributes, actions, and events that are
specific to the Embedded Object. Combinations of
these Embedded Objects provide a mechanism for
describing an arbitrary sensor/actuator network device.
The behaviors required by SEMI E54 are specified as
part of the definition of attributes, actions, and events.
5.2.4 events — Are used by objects to asynchronously
report the occurrence of events within an Embedded
Object. Event definitions specify the event reports that
a specific Embedded Object type may emit. Events also
have type-specific identifiers. Event definitions include:
a text string defining the semantics of the event, an
event identifier numerical value and textual name, and a
syntax definition. The “notification” services specified
in SEMI E54 are implemented as SDS events.
5.2.5 logical device — It is possible to have one or
more independent Logical Devices within the Physical
Component. This provides the illusion of multiple
devices on the network that actually are implemented
on the same physical hardware. Logical Devices are
distinguished within the Physical Component using
unique SDS bus addresses. The Logical Device defines
a separately addressable entity within a Physical
Component that has an independent interface definition.
5.2.6 physical component — An SDS Physical
Component is an abstraction representing a single
physical package of hardware and software that is
connected to the network. This is equivalent to the
CDM SEMI E54 definition for “device.” The Physical
Component contains one or more Logical Devices.
Table 1 provides a mapping of SEMI E54 definitions to
SDS-specific definitions. Column 2 contains an equal
sign “=” if the definition is used exactly as specified in
SEMI E54. Otherwise, the appropriate SDS-specific
term(s) are identified.
Table 1 Table 1 Mapping of Terms Between SEMI
E54 and SDS
SEMI E54 Term SDS Term
Device =
Device Model Physical Component
Object Embedded Object
Instance =
Attribute =
Behavior Set of Attribute/Action/Event
definitions
Service Actions for Request Services
and Events for Notification
Services
State Diagram =
Byte =
Nibble =
Character String =
6 Communication Protocol High Level
Structure
The SDS protocol is based on a three-layer architecture.
These layers constitute a collapsed form of the OSI
seven-layer architecture, mapping into the physical,
datalink, and application layers of the Open Systems
Interconnection Reference Model. The high level
protocol architecture is shown in Figure 3.
Note that Figure 3 represents a conceptual view of the
device architecture. Conforming implementations must
implement the services defined in this specification at
each layer and must appear (from the network) to have
implemented this architecture; however, an internal
modular partitioning is not required. Implementations
may sacrifice modularity in order to achieve high
performance.
SEMI E54.5-0997 © SEMI 1997, 2004 4
Figure 3
Protocol Architecture
SDS uses a three-layer protocol stack consisting of the
physical, datalink, and application layers. The SDS
physical layer uses two twisted pair to deliver power
and data to smart devices at speeds ranging from 125
Kbps to 1 Mbps and distances up to 500 meters. At the
data link layer, the CAN specification defines a carrier
sense multiple access mechanism for media access
control that avoids collisions and sends frames reliably.
The application layer supports a concise set of services
to set and get attributes of objects, to invoke operations
on objects, and to report notifications from objects.
These services are optimized for high performance in
discrete control applications (e.g., 3 byte messages
convey digital I/O state changes). In addition, a set of
pre-defined and extensible component objects flexibly
specifies all network-visible application level device
capabilities.
6.1 Physical Layer — The device shall comply with
the SDS physical layer specifications. These include
physical signaling (levels and baud rates - detailed in
the CAN specification), transceivers, node isolation,
media topology, cable specifications, network
connectors and taps, and power considerations (load
limits, system tolerances, and power supply options).
6.2 Data Link Layer — The device shall comply with
the SDS Data Link Layer Specifications (i.e., Controller
Area Network Specification: Version 2). These include
the media access control mechanism and the logical
link control mechanism. Frame formats, interframe
spacing, and error signaling shall comply with the CAN
specifications. CAN frame identifiers shall be 11 bits in
length.
6.3 Network Layer — There is no distinct network
layer. A future extension of the SDS SEMI SAN
protocol will support inter network messaging.
6.4 Transport Layer — There is no distinct transport
layer. Specific functionality of this layer is
implemented in the Application Layer. Functions
include: segmentation and reassembly for large
message delivery.
6.5 Session Layer — There is no distinct session layer.
6.6 Presentation Layer — There is no distinct
presentation layer. Data types are specified as part of
the SDS object definitions.
6.7 Application Layer — The device shall comply with
the SDS application layer specification. This includes
application object to application object communication
mechanisms.
6.7.1 Object Models — The SDS protocol provides an
object-oriented specification for defining and
addressing objects, including their attributes, actions,
and events. The device shall comply with the object
model specifications provided in the SDS Component
Model Specification. In addition, the device shall
comply with the object specifications defined in Section
7 of this document.
6.8 Network Management — The device shall comply
with the SDS system and network management
specifications.
7 Required Object Types
The Common Device Model specification identifies the
objects that must be supported in SEMI SAN-compliant
devices. These objects are specified in Table 1 of SEMI
E54 and include the following:
a) Device Manager (DM)
b) Sensor/Actuator/Controller (SAC)
c) Sensor (S
i
)
d) Actuator (A
i
)
e) Controller (C
i
).
As specified in SEMI E54, a conforming device must
support the DM, the SAC, and one or more of the
remaining object types.
This section specifies the implementation of these
required and optional objects in the SDS object model.
SDS object types are defined for the DM and SAC
objects. Sensor, actuator, or controller objects may be
implemented using existing standard SDS object types,
or new types may be specified, depending on the
specific device model needs.
SEMI E54.5-0997 © SEMI 1997, 2004 5
7.1 Embedded Object Type Hierarchy — SDS
classifies Embedded Objects into specific object types
(classes), and these types are organized into a class
inheritance hierarchy. (For more information on
classification and inheritance, see SEMI E39 -- Object
Services Standard). Each SDS object type specifies the
details of an object’s attributes, actions, and events. The
Embedded Object (an instance of a type) is a network-
addressable entity within a logical device. The
classification identifies common characteristics and
enables reuse of object definitions. The top two levels
of that hierarchy are shown in Figure 4 below.
Figure 4
Top Levels of the SDS Embedded Object Type
Hierarchy
The SDS object types are specified in detail in the SDS
Component Modeling Specification. There are four
primary Embedded Object types in the SDS type
hierarchy. These include: I/O, IEC 1131-3 Function
Object, Function Block, and SDS Interface. In addition,
a new SEMI object type has been defined for use in
developing classes necessary for SEMI SAN-compliant
networks. Each of these object types is derived from a
common type called SDS Minimum, which defines the
minimum characteristics that are common to all SDS
Embedded Objects.
All SDS object types inherit from the SDS Minimum
object type, which provides the fundamental
characteristics of an SDS device. The other top level
SDS object types shown in Figure 4 are summarized
below.
I/O Object (Type 1) — Defines the general
characteristics of objects used for process I/O type
functions. Subtypes of this type specify input and
output objects with either analog or digital process
variables. These may be used in SAN devices as the
sensor or actuator objects.
IEC 1131-3 Function Object (Type 2) — Defines
standard IEC 1131-3 Function Objects such as counters,
timers, type conversion, bit-wise operations, character
strings, etc.
Function Block Object (Type 3) — Collections of
function objects that have a specific set of inputs and
outputs (e.g., a predefined control algorithm). These
may be used in the SAN devices as the controller
objects.
SDS Interface Object (Type 4) — Models, network
interfaces, gateways, etc.
SEMI Object (object Type 10) — Implement the
additional object types necessary for SEMI SAN-
compliant networks.
7.1.1 SEMI Objects — To implement SEMI-specific
object types, the SDS object type hierarchy is
augmented with type number 10 - SEMI object. This
type, and the types derived from it, specify the new
functionality necessary to implement this SEMI
standard. Object type 10 is defined to include the
common required attributes, services, and behaviors as
described in the SAN Common Device Model standard
SEMI E54. This definition is in terms of SDS
Attributes, Actions, and Events.
In addition, there are derived types: types 10.1
implementing the SAC object and 10.2 implementing
the Device Manager (DM) object (Figure 5). Object
instances of these types are required in the Common
Device Model document SEMI E54.
Each object type inheriting from the SEMI Object type
10 (e.g., 10.1 SAC object) automatically includes the
features of the SEMI Object. Thus, both the SAC and
the DM object have the reset, abort, and recover actions
that are defined for the SEMI Object type 10. (See
Section 7.2.) The Device Manager type augments the
SEMI Object to provide the required characteristics
over and above those specified in type 10 and SDS
minimum.
As specific device models are defined, the SAC object
type will be refined to be specific to that device. These
object types are indicated in Figure 5 as object types
SDM-1, SDM-2, etc. (examples include: Mass Flow
Controller, Particle Counter, and Capacitance
Manometer SAC objects). These object types have (at
least) the set of attributes, actions, and events inherited
from SDS Minimum, the SEMI Object type, and the
SAC object type. Additionally, each SDM-n may have
other, unique attributes, actions, and events which
implement the desired behavior of a specific device
SAC object.