semi合集-English.pdf - 第2160页

SEMI E54.16-0705 © SEMI 2005 5 5.4.8 state diagram — In a L ON W ORKS device, state i s represented by t he collection of values of local and network variables of the application program. Transitions betwee n stat es are…

100%1 / 7923
SEMI E54.16-0705 © SEMI 2005 4
Table 1 Mapping of CDM to NCS Terminology
CDM
Term
NCS Equivalent LONWORKS Equivalent
Device = Device or node
Device Model = Device interface
Object =, Class Functional profile, Class
Instance = Functional block
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.4.1 attribute — Attributes are either input network variables (NVI), output network variables (NVO), or
configuration properties (CP). Input and output network variables and configuration properties 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 may cause 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 addresses
determined at installation time. Finally, configuration properties are attributes typically stored in non-volatile
memory and preserved across device resets and power cycles.
5.4.2 behavior — Generic object behavior is specified by the L
ONMARK Application Layer Interoperability
Guidelines. Additional object-specific behavior is specified by means of functional profiles.
5.4.3 device — A device (or node) typically consists of one network transceiver which implements the physical
layer of the ANSI/EIA/CEA-709.1 (LONWORKS) 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 ANSI/EIA/CEA-
709.1 (LONWORKS) protocol.
5.4.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; functional blocks such as sensors, actuators, and controllers;
individual network variables; and configuration properties.
5.4.5 instance — Real devices may have zero or more instances of each of the defined functional blocks. Object
instances are identified by means of an instance number within the device.
5.4.6 object — Functional blocks 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. Functional blocks form the basis of interoperability at the application layer. The
functional blocks describe standard formats for how information is input to, and output from, a device, and shared
with other devices on the network.
5.4.7 service — Request services are represented by ANSI/EIA/CEA-709.1input network variables (NVI) being set
and delivered to the device application. Notification services are represented by ANSI/EIA/CEA-709.1output
network variables being set by the device application and delivered over the network.
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
#2
Output No Yes
#1
Yes No
#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.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
y
ers
Application:
network variable exchan
g
e,
application-specific RPC, etc.
Network Mana
g
ement:
network mana
g
ement RPC,
dia
g
nostics
Session La
y
er
request-response service
Transport La
y
er
acknowled
g
ed and unacknowled
g
ed unicast and multicast
Authentication
server
Transaction Control Sublayer
common orderin
g
and duplicate detection
Network La
y
er
connection-less, domain-wide broadcast, no se
g
mentation,
loop-free topolo
gy
, learnin
g
routers
Link La
y
er
framin
g
, data encodin
g
, CRC error checkin
g
MAC Subla
y
er
predictive p-persistent CSMA: collision avoidance;
optional priorit
y
and collision detection
Ph
y
sical La
y
er
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.