semi合集-English.pdf - 第2159页
SEMI E54.16-0705 © SEMI 2005 4 Table 1 Mapping of CDM to NCS Terminology CDM Term NCS Equivalent L ON W ORKS Equivalent Device = Device or node Device Model = De vice interface Object =, Class Func tional profile, Class …
SEMI E54.16-0705 © SEMI 2005 3
Standard Program ID Definitions, http://types.lonmark.org/spid, LONMARK International.
SCPT Master List and Programmer’s Guide, http:// types.lonmark.org/scpt, LONMARK International.
SNVT Master List and Programmer’s Guide, http:// types.lonmark.org/snvt, LONMARK International.
5 Terminology
5.1 Terminology that is common to all of the documents in this SAN series may also be defined in the Sensor
Actuator Network Standard (see reference SEMI E54 §4.1). Terminology may be reproduced here which is defined
in other SEMI documents.
5.2 Abbreviations and Acronyms
5.2.1 APDU – Application Protocol Device Unit
5.2.2 CDM — Common Device Model
5.2.3 CP — Configuration Parameter
5.2.4 DM — Device Manager
5.2.5 DS — Device Status
5.2.6 NCS — Network Communications Standard
5.2.7 Neuron — Neuron Chip is the 8 bit hardware implementation of the ANSI/EIA/CEA-709.1 (L
ONWORKS)
Control Networking Protocol
5.2.8 NV — Network Variable
5.2.9 NVI — Network Variable Input
5.2.10 NVO — Network Variable Output
5.2.11 OSI — Open Systems Interconnect
5.2.12 OSS — Object Services Standard
5.2.13 RO — Read Only
5.2.14 RW — Read/Write
5.2.15 SAC — Sensor, Actuator, Controller (object)
5.2.16 SAN — Sensor/Actuator Network
5.2.17 SCPT — Standard Configuration Parameter Type
5.2.18 SDM — Specific Device Model
5.2.19 SNVT — Standard Network Variable Type
5.2.20 SPID — Standard Program ID
5.3 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 SEMI E54.1 - CDM document. Table 1
provides a mapping of fundamental terminology of the CDM document into this document and the L
ONWORKS
definitions. The symbol “=” indicates that the definition is used exactly as specified on the CDM specification.
5.4 In the following sections, additional clarification of some of these terms is provided in the context of the
ANSI/EIA/CEA-709.1 (LONWORKS) protocol.
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