semi合集-English.pdf - 第2161页

SEMI E54.16-0705 © SEMI 2005 6 types match. A list of all available SNVTs and details of their definitions is p rovided in the SNVT Master List and Programmer’s Guide . 6 Communication Protocol High Level Struc ture 6.1 …

SEMI E54.16-0705 © SEMI 2005 5

5.4.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.5 LONWORKS-Specific Definitions — In addition to the standard data type definitions for bit, nibble, byte, and

character, the ANSI/EIA/CEA-709.1 (LONWORKS) protocol defines a set of standard data representations for use as

attribute values.

5.5.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 ANSI/EIA/CEA-709.1 (LONWORKS) 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 from Device Poll from Network Poll from Device

Input Yes Yes Yes Yes

Output No Yes

Yes No

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.

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.5.2 configuration properties — These are attributes of a functional block that are used to configure the

application-specific behavior of the functional block, 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.5.3 device interface — A device interface is a specification of one or more functional blocks, together with

semantic definitions relating the behavior of the functional block(s) to the network variable values. The collection of

functional blocks in a device corresponds to the SEMI SAN device-specific model for that device. Each type of

device interface is identified by a standard program ID (SPID).

5.5.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 network 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 the SEMI specific service SetAttribute operation. The value of a network variable may be polled over

the network by some other device, or retrieved by the device itself. This corresponds to the SEMI specific service

GetAttribute operation.

5.5.5 functional block — A device’s external interface documentation specifies the type identifiers of the functional

blocks contained within the device. This documentation may be uploaded from the device, and completely specifies

the functional profiles implemented by the device, as well as the network variables and configuration properties

contained within each of the functional blocks.

5.5.6 functional profile — A functional profile is the definition of the attributes and behaviors of an abstract entity.

Each type of functional block is identified by a functional profile number. A specific device type consists of

instantiations of one or more of these functional profiles. A functional block is implemented as a collection of

network variables and configuration properties.

5.5.7 standard configuration property types — These data types, also known as SCPTs, provide a data type

definition and a semantic behavior for the configuration properties of functional blocks. A list of all available SCPTs

and details of their definitions is provided in the SCPT Master List and Programmer’s Guide.

5.5.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

SEMI E54.16-0705 © SEMI 2005 6

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

6.1 The ANSI/EIA/CEA-709.1 (LONWORKS) 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 1.

Application and Presentation La

ers

Application:

network variable exchan

application-specific RPC, etc.

Network Mana

ement:

network mana

ement RPC,

dia

nostics

Session La

request-response service

Transport La

acknowled

ed and unacknowled

ed unicast and multicast

Authentication

server

Transaction Control Sublayer

common orderin

and duplicate detection

Network La

connection-less, domain-wide broadcast, no se

mentation,

loop-free topolo

, learnin

routers

Link La

framin

, data encodin

, CRC error checkin

MAC Subla

predictive p-persistent CSMA: collision avoidance;

optional priorit

and collision detection

sical La

mulitple-media, medium specific protocols

LAYERS 6,7

LAYER 5

LAYER 4

LAYER 3

LAYER 2

LAYER 1

Figure 1

Layered View of the ANSI/EIA/CEA-709.1 (LONWORKS) Protocol

6.1.1 Figure 1 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.2 Physical Layer — The device shall employ one of the L

ONMARK-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 §9, Specific Device Type Information, 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.2.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.2.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.

6.2.3 The L

ONMARK Layers 1-6 Interoperability Guidelines provide specific details of the characteristics of these

transceivers. This document also provides specifications of wiring types and interconnection topologies to be used

for guaranteed device interoperability. Note that the ANSI/EIA/CEA-709.1 (LONWORKS) 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.

6.2.4 Multiple physical layer protocols and data encoding methods are used in the ANSI/EIA/CEA-709.1

(LONWORKS) protocol. Differential Manchester encoding is used on twisted pair physical layers.

6.3 Link Layer — The device shall comply with the ANSI/EIA/CEA-709.1 (LONWORKS) 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 ANSI/EIA/CEA-709.1 (LONWORKS) protocol supports a simple

connectionless service. Its functions are limited to framing, frame encoding, and error detection.

6.3.1 Media Access Control Sub-layer — In order to deal with a variety of media in the potential absence of

collision detection, the MAC (Media Access Control) sub-layer employs a collision avoidance algorithm called

Predictive p-persistent CSMA (Carrier Sense, Multiple Access).

6.4 Network Layer — The device shall comply with the ANSI/EIA/CEA-709.1 (LONWORKS) 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.5 Transport Layer — The device shall comply with the ANSI/EIA/CEA-709.1 (LONWORKS) protocol transport

layer specification. The heart of the protocol hierarchy is the Transport and Session layers. A common Transaction

Control sub-layer 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 sub-layer to accomplish its function. The transport and session layer messages may be authenticated using

all of the ANSI/EIA/CEA-709.1addressing modes other than broadcast. The transport layer supports end-to-end

acknowledged service and an unacknowledged/ repeated service.

6.6 Session Layer — The device shall comply with the ANSI/EIA/CEA-709.1 (L

ONWORKS) 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

ANSI/EIA/CEA-709.1 (LONWORKS) 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.7 Presentation Layer — The device shall comply with the ANSI/EIA/CEA-709.1 (LONWORKS) protocol

presentation layer specification. The Presentation layer and the Application layer taken together form the foundation

of interoperability for LONWORKS 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.8 Application Layer — At the application layer, interoperability between LONWORKS-based devices is facilitated

through the use of functional blocks and Standard Network Variable Types (SNVTs). Functional blocks build upon

network variables and provide a concise application layer interface that incorporates semantic meaning for specific

device functions. Functional blocks 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, functional block interfaces and semantics are defined by functional profiles. The

Application Layer also includes the LONWORKS file transfer protocol, which provides segmentation and reassembly

of arbitrary length files of data. This service may be used to get and set object attributes that exceed the network

variable size limit of 31 bytes.

6.8.1 Object Models — The ANSI/EIA/CEA-709.1 (LONWORKS) 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 §7 of this document.