semi合集-English.pdf - 第1999页
SEMI E54.6-0997 © SEMI 1997, 2004 5 some other de vice, or retrieved by the device i tself. This corresponds to a GetAttribute operation. 5.3.5 object instance — A device’s external interface documentation specifies the …
SEMI E54.6-0997 © SEMI 1997, 2004 4
address(es) determined at installation time. Finally,
configuration properties are attributes typically stored
in non-volatile memory and preserved across device
resets and power cycles.
5.2.2 behavior — Generic object behavior is specified
by the LonMark Application Layer Interoperability
Guidelines. Additional object-specific behavior is
specified by means of functional profiles.
5.2.3 device — A device (or node) consists of one
network transceiver which implements the physical
layer of the LonTalk Protocol, one Neuron Chip with
associated firmware which implements the other layers
of the LonTalk Protocol, and input/output hardware
implementing the physical interface of the device to
external sensor and/or actuator hardware. A LonWorks
device may optionally contain a host processor and
associated software or firmware which implements the
application layer of the LonTalk Protocol.
5.2.4 device model — The device model comprises
several elements which fully describe the external
interface of the device for an interoperable network.
The interface is made of the following pieces: a Device
Manager (DM) object; a Sensor/Actuator/Controller
(SAC) object; LonMark objects such as sensors,
actuators, and controllers; individual network variables;
and configuration properties.
5.2.5 instance — Real devices may have zero or more
instances of each of the defined LonMark objects and
functional profiles. Object instances are identified by
means of an instance number within the device.
5.2.6 object — LonMark objects are defined as a set of
one or more network variable inputs and/or outputs,
implemented as Standard Network Variable Types, and
a set of configuration properties, implemented as
Standard Configuration Property Types. LonMark
objects form the basis of interoperability at the
application layer. The LonMark objects describe
standard formats for how information is input to, and
output from, a device, and shared with other devices on
the network.
5.2.7 service — Request services are represented by
LonTalk messages delivered to the device application.
Notification services are represented by LonTalk
messages originated by the device application.
5.2.8 state diagram — In a LonWorks device, state is
represented by the collection of values of local and
network variables of the application program.
Transitions between states are the result of external
events (such as the receipt of a network variable update,
or other I/O event), or internal events (such as the
expiration of a timer).
5.3 LonWorks-Specific Definitions — In addition to the
standard data type definitions for bit, nibble, byte, and
character, the LonTalk Protocol defines a set of
standard data representations for use as attribute values.
5.3.1 binding — Network variables on the same or
different devices may be associated together by means
of a network management service known as binding.
Binding is permitted only if all the network variables in
the set are of the same data type. The values of network
variables that are bound together are propagated over
the network by the LonTalk protocol. Table 2 shows the
permitted combinations for updating and polling of
network variables.
Table 2 Updating and Polling of Network Variables
Network
Variable
Class
Update
from
Network
Update
f
rom Device
Poll from
Network
Poll from
Device
Input
Yes Yes Yes Yes
2
Output
No Yes
1
Yes No
Config’n
Yes No Yes Yes
2
NOTES:
1. When the device updates one of its own output network variables,
input network variables that are bound to this output network variable
receive an update from the network.
2. When the device polls one of its own input or configuration
network variables, output network variables that are bound to this
input or configuration network variable receive a poll from the
network.
5.3.2 configuration properties — These are attributes
of a LonMark object that are used to configure the
application-specific behavior of the object, such as
sensor gain and offset, linearization table, and sample
rate. These attributes are typically updated when the
device is installed, configured, or calibrated, and are
stored in non-volatile memory.
5.3.3 functional profile — A functional profile is a set
of one or more LonMark objects, together with
semantic definitions relating the behavior of the
object(s) to the network variable values. The collection
of functional profiles and LonMark objects in a device
corresponds to the device-specific model for that
device. Each type of functional profile is identified by a
type number which is allocated when the profile is
standardized.
5.3.4 network variable — This is a network-visible
data attribute of a device, with a well-defined data type.
Network variables are either input variables, output
variables, or configuration variables. The value of a
network variable may be updated either by the device
itself, or over the network by some other device. This
corresponds to a SetAttribute operation. The value of a
network variable may be polled over the network by
SEMI E54.6-0997 © SEMI 1997, 2004 5
some other device, or retrieved by the device itself.
This corresponds to a GetAttribute operation.
5.3.5 object instance — A device’s external interface
documentation specifies the type identifiers of the
LonMark object instances contained within the device.
Each instance is allocated an index number based on
the order of the declaration of the instance in the
device’s external interface documentation. This
documentation may be uploaded from the device, and
completely specifies the functional profiles and
LonMark objects contained within the device, as well
as the network variables and configuration properties
contained within each of the functional profiles.
5.3.6 object type — An object type is the definition of
the attributes and behaviors of an abstract entity. Each
type of LonMark object is identified by a type number
which is allocated when the object type is standardized.
A specific device type consists of instantiations of one
or more of these object types. The term LonMark object
is loosely used to refer to either a LonMark object type
or to a specific instance of a LonMark object type. The
attributes of a LonMark object are implemented as a
collection of network variables of SNVT types and
configuration properties of SCPT types.
5.3.7 standard configuration parameter types — These
data types, also known as SCPTs, provide a data type
definition and a semantic behavior for the configuration
properties of LonMark objects. A list of all available
SCPTs and details of their definitions is provided in the
SCPT Master List and Programmer’s Guide.
5.3.8 standard network variable types — These data
types, also known as SNVTs, facilitate interoperability
by providing a well-defined interface for
communication between devices made by different
manufacturers. A device may be installed in a network,
and logically connected to other devices via network
variables, as long as the data types match. A list of all
available SNVTs and details of their definitions is
provided in the SNVT Master List and Programmer’s
Guide.
6 Communication Protocol High Level
Structure
The LonTalk Protocol is based on a seven-layer
architecture. At each layer, there is a description of the
services provided within that layer. The high level
protocol architecture is shown in Figure 3.
Application and Presentation Layers
Application:
network variable exchange,
application-specific RPC, etc.
Network Management:
network management RPC,
diagnostics
Session Layer
request-response service
Transport Layer
acknow ledged and unacknow ledged unicast and multicast
Authentication
server
Transaction Control Sublayer
common ordering and duplicate detection
Network Layer
connection-less, domain-w ide broadcast, no segmentation,
loop-free topology, learning routers
Link Layer
framing, data encoding, CRC error checking
MAC Sublayer
predictive p-persistent CSMA: collision avoidance;
optional priority and collision detection
Physical Layer
mulitple-media, medium specific protocols
LAYERS 6,7:
LAYER 5:
LAYER 4:
LAYER 3:
LAYER 2:
LAYER 1:
Figure 3
Layered View of the LonTalk Protocol
Note that Figure 3 represents a conceptual view of the
device architecture. Implementations typically use the
Neuron Chip and its associated firmware, which
provide a conforming implementation of layers 2
through 6. The LonMark Interoperability Guidelines
specify the protocol options to be used, most
specifically at the physical layer (network transceivers)
and at the application layer (object model).
6.1 Physical Layer — The device shall employ one of
the LonMark-approved physical channels as specified
in the LonMark Layers 1–6 Interoperability Guidelines.
LonWorks-based SEMI SAN-compliant devices shall
use, by default, a two-pin screw-terminal open
pluggable connector (Weidmüller-Klippon SL2,
Phoenix Combicon, or equivalent) for the network
connection. The default connector specification may be
overridden for specific device types if special
requirements apply; any such overrides shall be noted
in Section 9 of this document. This connection is
polarity-insensitive. The requirements of semiconductor
equipment may be met by one of the twisted pair
channel specifications listed below.
6.1.1 TP/XF-1250 Twisted Pair — This twisted-pair
channel operates at a bit rate of 1,250kbps and supports
a bus topology using transformer-coupled transceivers.
6.1.2 TP/FT-10 Twisted Pair — This twisted-pair
channel operates at a bit rate of 78kbps and supports
both free topology and bus topology wiring, as well as
optional link power.
The LonMark Layers 1-6 Interoperability Guidelines
provide specific details of the characteristics of these
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