semi合集-English.pdf - 第1998页

SEMI E54.6-0997 © SEMI 1997, 2004 4 address(es) determined at installation time. Finally, configuration p roperties are a ttribu tes typically stored in non-volatile memory and preserved acro ss device resets and power c…

SEMI E54.6-0997 © SEMI 1997, 2004 3

4 Referenced Documents

4.1 SEMI Documents

SEMI E30 — Generic Model for Communications and

Control of SEMI Equipment (GEM)

SEMI E39 — Object Services Standard: Concepts,

Behavior, and Services

SEMI E54.1 — Standard for Sensor/Actuator Network

Common Device Model

4.2 ISO Standard

ISO 7498 — Basic Reference Model for Open Systems

Interconnection

4.3 Other Documents

LonTalk Protocol Specification, Echelon Corporation,

4015 Miranda Avenue, Palo Alto, CA 94304 USA

LonMark Layers 1–6 Interoperability Guidelines,

Echelon Corporation

LonMark Application Layer Interoperability

Guidelines, Echelon Corporation

Neuron Chip Data Book, Echelon Corporation

Neuron C Programmer’s Guide, Echelon Corporation

Standard Network Variable Type Master List and

Programmer’s Guide, Echelon Corporation

Standard Configuration Parameter Type Master List

and Programmer’s Guide, Echelon Corporation

5 Terminology

Terminology that is common to all of the documents in

this SAN series may also be defined in the Sensor

Actuator Network Standard. Terminology may be

reproduced here which is defined in other SEMI

documents.

5.1 Acronyms

5.1.1 CDM — Common device model

5.1.2 DM — DeviceManager

5.1.3 DS — Device status

5.1.4 NCS — Network communications standard

5.1.5 NV — Network variable

5.1.6 OSI — Open systems interconnect

5.1.7 OSS — Object services standard

5.1.8 SAC — Sensor, actuator, controller object

1 International Organization for Standardization, 1 rue de Varembe, Case

postale 56, CH-1211, Geneva 20, Switzerland

5.1.9 SAN — Sensor/actuator network

5.1.10 SCPT — Standard configuration parameter type

5.1.11 SDM — Specific device model

5.1.12 SNVT — Standard network variable type

5.2 Device Component Definitions — As this standard

defines the presentation or mapping of CDM data

structure and behavior over a network, it makes use of

many of the terms in the CDM document. Table 1

provides a mapping of fundamental terminology of the

CDM document into this document and the LonWorks

definitions. The symbol “=” indicates that the definition

is used exactly as specified on the CDM specification.

In the following sections, additional clarification of

some of these terms is provided in the context of the

LonWorks protocol.

Table 1 Mapping of CDM to NCS Terminology

CDM Term

NCS

Equivalent

LonWorks Equivalent

Device = Device or node

Device Model = Functional profile

Object = LonMark object type

Instance = LonMark object instance

Attribute = Network variable or

configuration property

Behavior = =

Service = Network variable function or

application message

State Diagram = =

Byte = =

Nibble = =

Character

String

= String of ASCII characters or

string of international

characters

5.2.1 attribute — Attributes are either input network

variables, output network variables, or configuration

properties. Input and output network variables may be

read and/or written by the device itself, and all

attributes may be polled over the network. Additionally,

input network variables and configuration properties

may be updated over the network, and the receipt of

such an update causes an event to be propagated to the

device' s application layer. This corresponds to a RW

(Read and Write) attribute of the object owning the

network variable. Output network variables may not be

updated over the network. This corresponds to a RO

(Read Only) attribute of the object owning the network

variable. When the device itself updates one of its

output network variables, the value of that variable may

be propagated over the network to destination

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

rom Device

Poll from

Network

Poll from

Device

Input

Yes Yes Yes Yes

Output

No Yes

Yes No

Config’n

Yes No Yes Yes

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