wilamowski-b-m-irwin-j-d-industrial-communication-systems-2011

LonWorks 41-11
TABLE 41.1
Definition of Standard Network Variable Types Used in the Example
SNVT Purpose Data Type Range
SNVT_lux Illumination level unsigned long 0…65,535lx (raw: 0…65,535)
SNVT_occupancy Occupancy state enum occup_t OC_OCCUPIED,
OC_UNOCCUPIED,…
SNVT_scene Calling scenes struct of:
enum scene_t function
unsigned short
scene_number
SNVT_setting
Setting value
(e.g., for
sunblind)
struct of:
enum setting_t function
unsigned short setting
signed long rotation
SC_RECALL, SC_LEARN,…
1…255
SET_DOWN, SET_UP, SET_STOP,…
0.0…100.0% (raw: 0…200)
−359.98…360.00°
(raw: −17,999…18,000)
SNVT_speed Linear velocity unsigned long 0…6,553.5 m/s (raw: 0…65,535)
Composite types are structures (struct) and unions (union) of basic types. Each SNVT field has a scale
and an offset to represent values with a resolution lower than one. SNVT _ temp has, for example, a scale
of 0.1 and an offset of −2740 to represent a range of −274.0°C to 6,279.5°C by raw values 0–65,535 (2 bytes).
Other SNVTs, which are used in the example, are described in Table 41.1.
SCPT types often reference SNVT types. For example, SCPTtempOffset, which is used as calibration
offset of temperature probes, references SNVT _ temp _ diff _ p, which describes a temperature
difference.
Manufacturers can use their own user-defined network variable and configuration types (UNVT/
UCPT), which can be new types or referenced SNVT/SCPTs. These user types are always manufacturer
specific, so they are only valid for one manufacturer. They additionally have a scope, which defines the
range of application of a type. The range can be further limited to a device class, usage, channel type,
or an application itself. System integration tools ensure that only network variables of the same type
(SNVT or UNVT) can be bound.
41.6 Network Design Tools
Traditionally, each assembly section, such as lighting, sunblind, and HVAC, has its own designers and
system integrators. Since LonWorks covers all these assembly sections, the bus can be shared. If all
nodes are installed on one shared bus and the system integrators do not coordinate each other, which
often was the case, the completed system will not work: Logical addresses are used more than once or
bindings will be overwritten. A solution to this problem is to use a central database, where all assembly
sections are working on. On this account, Echelon released LonWorks network services (LNS) in 1996,
which is a de facto standard in the LonWorks world now. The LNS Server offers a database, where networks
can be stored, and an API, which provides network management methods for adding devices to a
network, binding network variables, and setting node and application-specific configuration properties.
With the first release of the LNS database, Echelon created the prerequisites for the development of
a wide range of LNS-based system integration tools for LonWorks networks. Today, tools from several
manufacturers are available on the market, which use the LNS database as backend [13]. Examples
are the LonMaker from Echelon [14], NL 220 and NL Facilities from Newron System [15], Alex TE
from Spega [16], and the Network Integrator from Circon Systems [17]. They all incorporate mostly all
LNS functions and enable the design, parameterization, commissioning, and test of open multi-vendor
LonWorks systems.
Besides, also LonWorks system integration tools exist that are specialized to devices from a
specific manufacturer. This limitation to a small number of devices makes an easier, semiautomatic
© 2011 by Taylor and Francis Group, LLC