semi合集-English.pdf - 第2001页
SEMI E54.6-0997 © SEMI 1997, 2004 7 attributes that exceed the ne twork variable size limit of 31 bytes. 6.7.1 Object Models — The L onTalk Pr otocol provides an object-oriented specification for defining an d addressing…
SEMI E54.6-0997 © SEMI 1997, 2004 6
transceivers. This document also provides
specifications of wiring types and interconnection
topologies to be used for guaranteed device
interoperability. Note that the LonTalk Protocol
supports heterogeneous networks. Devices with
dissimilar transceivers may be interconnected and
communicate via routers or repeaters. Similarly, routers
and repeaters may be used to extend a physical channel
beyond the device count, wire length, or other physical
limitations imposed by the chosen transceiver.
Multiple physical layer protocols and data encoding
methods are used in the LonTalk Protocol. Differential
Manchester encoding is used on twisted pair physical
layers.
6.2 Link Layer — The device shall comply with the
LonTalk protocol link layer specification. This layer
includes the media access control sublayer. For a
number of reasons, including simplicity and
compatibility with the multicast protocol, the LonTalk
protocol supports a simple connectionless service. Its
functions are limited to framing, frame encoding, and
error detection, with no error recovery by
retransmission.
6.2.1 Media Access Control Sublayer — In order to
deal with a variety of media in the potential absence of
collision detection, the MAC (Media Access Control)
sublayer employs a collision avoidance algorithm called
Predictive p-persistent CSMA (Carrier Sense, Multiple
Access).
6.3 Network Layer — The device shall comply with the
LonTalk protocol network layer specification. This
layer handles packet delivery within a single domain,
with no provisions for inter-domain communication.
The network service is connection-less,
unacknowledged, and supports neither segmentation
nor re-assembly of messages. The routing algorithms
employed by the network layer to learn the topology
assume a tree-like network topology; routers with
configured tables may operate on topologies with
physical loops, as long as the communication paths are
logically tree-like. In this configuration, a packet may
never appear more than once at the router on the side on
which the packet originated. The unicast routing
algorithm uses learning for minimal overhead and no
additional routing traffic. Use of configured routing
tables is supported for both unicast and multicast
addresses.
6.4 Transport Layer — The device shall comply with
the LonTalk protocol transport layer specification. The
heart of the protocol hierarchy is the Transport and
Session layers. A common Transaction Control
sublayer handles transaction ordering and duplicate
detection for both layers. The transport layer is
connectionless and provides reliable message delivery
to both single and multiple destinations. Authentication
of the message sender’s identity is provided as an
optional feature. The authentication server requires only
the Transaction Control sublayer to accomplish its
function. The transport and session layer messages may
be authenticated using all of the LonTalk addressing
modes other than broadcast. The transport layer
supports end-to-end acknowledged service and an
unacknowledged/ repeated service.
6.5 Session Layer — The device shall comply with the
LonTalk protocol session layer specification. This layer
implements a simple Request-Response mechanism for
access to remote servers. This mechanism provides a
platform upon which application-specific remote
procedure calls can be built. The LonTalk network
management protocol, for example, is dependent on the
Request-Response mechanism in the Session layer,
even though it accesses the protocol via the application
layer interface.
6.6 Presentation Layer — The device shall comply
with the LonTalk protocol presentation layer
specification. The Presentation layer and the
Application layer taken together form the foundation of
interoperability for LonTalk devices. The application
layer provides all the usual services for sending and
receiving messages, but it also contains the concept of
network variables. The presentation layer provides
information in the Application Protocol Data Unit
(APDU) header for how the APDU is to be interpreted
for network variable updates. This application-
independent interpretation of the data allows data to be
shared among devices without prior arrangement. With
agreement on which network variables are to be used
for sensors, actuators, etc., intelligent components from
different manufacturers may work together without
prior knowledge of each other' s characteristics.
6.7 Application Layer — At the application layer,
interoperability between LonWorks-based devices is
facilitated through the use of LonMark objects and
Standard Network Variable Types (SNVTs). LonMark
objects build upon network variables and provide a
concise application layer interface that incorporates
semantic meaning for specific device functions.
LonMark objects not only define which SNVTs to use
to convey data, but also provide semantic meaning
about the information being communicated. To aid in
the specification of specific device models with well-
defined functional behavior, collections of objects with
defined relations can be aggregated and referenced as
functional profiles. The Application Layer also includes
the LonTalk file transfer protocol, which provides
segmentation and reassembly of arbitrary length files of
data. This service may be used to get and set object
SEMI E54.6-0997 © SEMI 1997, 2004 7
attributes that exceed the network variable size limit of
31 bytes.
6.7.1 Object Models — The LonTalk Protocol provides
an object-oriented specification for defining and
addressing network variables and configuration
properties, which are the representation of object
attributes and events. The device shall comply with the
object model specifications defined in Section 7 of this
document.
6.7.2 LonMark Object Structure — The LonMark
Application Layer Interoperability Guidelines define a
number of object types. Each object type has a set of
mandatory network variables, a set of optional network
variables, a set of configuration properties (both
mandatory and optional), and a manufacturer-defined
section, which may be used for non-interoperable
extensions to the object. This is illustrated in Figure 4.
This notation is defined in the LonMark Application
Layer Interoperability Guidelines.
Object Name and
Number
Mandatory Network
Variables
Optional Network
Variables
Configuration
Properties
Input Network
Variables
Output Network
Variables
Manufacturer Defined
Section
Figure 4
LonMark Object Structure
2
The LonMark Application Layer Interoperability
Guidelines provide for the definition of new Standard
Network Variable Types, LonMark Object Types, and
Functional Profiles. In the mapping of the SEMI CDM
to the LonMark object structure in Section 7, extensions
to the current SNVT list and Interoperability Guidelines
are marked with an asterisk (*). Object type numbers
are specified by the guidelines; a device may consist of
one instance of a node object type, and one or more
instances of LonMark object types, which are assigned
sequential instance numbers starting from one.
6.8 Network Management — The LonTalk Protocol
defines a complete network management and diagnostic
protocol for LonWorks devices. This protocol is a layer
above the Session layer (request/response service) and
provides mechanisms for application downloading,
device address assignment, distribution of destination
2 Diagram notation, the arrow-like symbol used in Figure 4 is defined
in the LonMark Application Layer Interoperability Guidelines.
addresses for implicit messaging, router configuration,
and device-level diagnostics. The LonMark Application
Layer Interoperability Guidelines define a device
management layer for LonMark objects.
7 Required Object Types
The LonMark Application Layer Interoperability
Guidelines describe sensor, actuator, and controller
objects. A specific device may be implemented using
these objects or functional profiles based on these
objects. The Common Device Model specification
additionally identifies two objects (namely the Device
Manager (DM) and Sensor Actuator Controller (SAC)
objects) that must exist in all SEMI-compliant SAN
devices.
7.1 Service Requests — Common Device Model
service requests are implemented as LonTalk foreign
frame messages delivered to the application using the
LonTalk request/response protocol. The transaction
layer protocol ensures that response messages are
correlated with the original request message. Tables 3
and 4 show the LonTalk APDU format for the
Request/Indication message, and for the
Response/Confirmation message respectively.
SEMI E54.6-0997 © SEMI 1997, 2004 8
Table 3 SEMI SAN Request Message APDU Format
Field Name Size (bits) Value
Message Code 8 4D (hex). Indicates a SEMI SAN-compliant foreign frame message.
Object ID 16 Destination object’s ID number. Based on the order of the declaration of the instance
in the device’s external interface documentation string.
Service Code 8 Defines the service being requested.
Request Parameters optional Service-specific request parameters.
Table 4 SEMI SAN Response Message APDU Format
Field Name Size (bits) Value
Message Code 8 Zero indicates successful execution of the requested service. Non-zero indicates
failure. Values are request-specific.
Response Parameters optional Service-specific result parameters.
7.2 Object Attributes — The GetAttribute and
SetAttribute service requests may also be implemented
as network variable fetch, poll, and update requests
addressed to the network variable corresponding to the
specified attribute. This is appropriate when
application-layer service responses are not required. A
GetAttribute service request may be addressed directly
to any network variable as a LonTalk request message,
using the LonTalk protocol network management NV
fetch mechanism. A GetAttribute service request may
also be addressed to an output network variable as a
LonTalk NV poll message, using the NV selection
mechanism. A SetAttribute service request may be
addressed to an input network variable as a LonTalk
NV update message, using the NV selection
mechanism. The confirmation of a SetAttribute
(network variable update) is provided by the
acknowledged service of the LonTalk protocol transport
layer.
Each network variable in a LonMark object is identified
by means of a self-documentation string stored in the
device’s memory. This string contains the object id of
the object to which this variable belongs, and the
sequence number of the network variable within its
enclosing object. For the LonWorks NCS, this sequence
number is identical to the numerical sequence number
specified by the CDM tag.
Example: Suppose that the Device Manager object
instance is declared as the second object instance in the
device. It would, therefore, have object id 1. The
Device Manager attribute Standard Revision Level has
the tag DmA2. The self-documentation string for this
network variable is, therefore, specified as “@1| 2.”
The Publish notification service is implicit when an
output network variable is updated. The device
propagates the value of the output network variable
(equivalent to a read-only attribute) to any input
network variable(s) to which it may be bound.
The LonTalk protocol only supports propagation of
output network variables. In CDM terminology, this
means that only read-only attributes may be published.
If a specific device model requires publication of a
read/write attribute, an output network variable whose
value mirrors the value of the input (read/write)
network variable may be introduced to the object
definition.
7.3 Sensor/Actuator/Controller Object (*) — The
SEMI CDM SAC object coordinates the functionality
of Sensor, Actuator, and Controller objects in the
device. A new object type is defined, which forms part
of the LonMark Functional Profile for SEMI SAN-
compliant devices based on LonWorks. Table 5
summarizes the services implemented by the SAC
object.
Table 5 SAC Object Services
Service Name CDM Tag Service Code
Reset SacS1 1
Abort SacS2 2
Recover SacS3 3
7.4 Device Manager Object (*) — The SEMI CDM
Device Manager Object combines attributes of device
self-documentation with an exception reporting
mechanism. A new object type is, therefore, defined
with the following mandatory network variables and
behaviors. This object type forms part of the LonMark
Functional Profile for SEMI SAN-compliant devices
based on LonWorks. Table 6 summarizes the network
variables that implement the attributes of the Device
Manager object.