semi合集-English.pdf - 第2000页

SEMI E54.6-0997 © SEMI 1997, 2004 6 transceivers. This doc ument also provides specifications of wiring types and int erconnection topologies to be use d for guarante ed device interoperability. Note th at the LonTalk Pr…

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

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

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.