semi合集-English.pdf - 第2163页

SEMI E54.16-0705 © SEMI 2005 8 6.8.2 Functional Block Structure — The L ON M ARK App lication Layer Interopera bility Guidelines define a structure for functional p rofiles . Each functio nal profil e may have a set of m…

SEMI E54.16-0705 © SEMI 2005 7

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.

SEMI E54.16-0705 © SEMI 2005 8

6.8.2 Functional Block Structure — The LONMARK Application Layer Interoperability Guidelines define a structure

for functional profiles. Each functional profile may have 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 profile. This is illustrated in Figure 2. This

notation is defined in the LONMARK Application Layer Interoperability Guidelines.

NOTE: Diagram notation, the arrow-like symbol used in Figure 2 is defined in the LonMark Application Layer Interoperability

Guidelines.

Figure 2

LonMark Object Structure

6.8.3 The LONMARK Application Layer Interoperability Guidelines provide for the definition of Standard Network

Variable Types, Standard Configuration Property Types, and Functional Profiles. In the mapping of the SEMI CDM

to the LONMARK object structure in §7, extensions to the current SNVT list and LONMARK Interoperability

Guidelines are marked with an asterisk (*). Functional profile numbers are specified by the guidelines; a device may

consist of one instance of a Node Object type, and one or more instances of other functional profiles.

6.9 Network Management — The ANSI/EIA/CEA-709.1 (LONWORKS) 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 addresses for implicit messaging, router configuration, and device-level diagnostics. The

LONMARK Application Layer Interoperability Guidelines define a device management layer for functional blocks.

7 Required and Optional Object Types

7.1 The LONMARK guidelines do not require any specific objects to exist in a device in order to be a compliant

LONMARK device, except that a Node object functional block is required for devices that contain multiple functional

blocks (SEMI compliant devices will typically have a Node object functional block). New LONMARK standard

profiles are defined in this standard to identify and describe functional blocks that shall exist in devices that are to be

interoperable and interchangeable on a LONMARK SEMI compliant SAN network.

7.1.1 LONMARK International Association publishes functional profiles for various sensor, actuator, and controller

objects. A specific device may be implemented using functional blocks based on these profiles. The Common

Device Model specification additionally identifies two functional blocks (namely the Device Manager (DM) and

Sensor Actuator Controller (SAC) objects) that must exist in all SEMI compliant SAN devices. The required

functional profiles for a SEMI compliant SAN device utilizing the network communication specification described

herein necessarily comprise, at minimum, the union of the LONMARK functional profile requirements and the CDM

specification requirements.

7.1.2 A list of required and optional object types is given in Table 3. Additional objects that are specified in a

particular SDM are given identifiers in that SDM specification. The LONMARK specific presentation information for

these identifiers is given in §9 of this document.

SEMI E54.16-0705 © SEMI 2005 9

Table 3 Common Device Model Required and Optional Object Types

SEMI Object

Name

LONMARK SEMI Class

ID/Instance ID

CDM Tag

LONMARK Functional

Profile Name

Required By

LONMARK

equired By

CDM

Required

By NCS

(DM)

Device Manager

0 / 1 DmIO Node Object Yes Yes Yes

(SAC)

Sensor/Actuator/C

ontroller

0 / 1 SacIO Node Object Yes Yes Yes

Assembly 180.81 / 1 through i Asm Manufacturer-specific

Members

No No No

Local Link Turnaround

Connection

Lnk Turnaround Connection

No No No

Sensor-AI 180.11 / 1 through k Sai SFPTsemiSensorAI No No No

Sensor-EI 180.22 / 1 through l Sei SFPTsemiSensorEI No No No

Sensor-BI 180.18 / 1 through m Sbi SFPTsemiSensorBI No No No

Actuator-AO 180.31 / 1 through n Aao SFPTsemiActuatorAO No No No

Actuator-EO 180.34 / 1 through o Aeo SFPTsemiActuatorEO No No No

Actuator-BO 180.33 / 1 through p Abo SFPTsemiActuatorBO No No No

Controller 180.51 / 1 through q C SFPTsemiController No No No

Sensor-BI-TH 180.19 / 1 through s Sbith SFPTsemiSensorBITH No No No

LonMark groups SEMI Class IDs as reference 180 and designates specific object name categories as .XX. See LONMARK Application Layer

Interoperability Guideline and http://types.lonmark.org.

See E54.1 – CDM specification for further information

A turnaround connection is not a profile, but is a protocol-specific method for creating a link

The LonMark Application Layer maps the SEMI Device Manger (DM) and Sensor/Actuator/Controller (SAC) objects to the LonMark Node

object.

7.1.3 Service Requests Code — Most service requests are implemented as network variable updates addressed to the

network variable corresponding to the specified attribute. The exceptions to this mapping are requests that require

more than a 31 byte response. In that case, the request is implemented as a network variable update containing a file

request to an nviSemiReq input to the Node Object functional block of a device. This input is defined by the

SNVT_semi_req type as follows:

typedef enum {

struct {

CMD_RESET = 1,

CMD_ABORT = 2,

CMD_RECOVER = 3,

CMD_GET_ATTRIBUTE = 4,

CMD_SET_ATTRIBUTE = 5,

CMD_OERATE = 6,

CMD_RESTOTE_DEFAULT = 7,

CMD_PUBLISH_ATTRIBUTE = 8,

CMD_LOCK = 9,