Echelon OpenLNS - Manual (Page 40)

OpenLNS Programmer's Reference 3
The remainder of the OpenLNS Objects originate from the three Networks collections. A
network is represented by an instance of the Network object, which contains both a
systems and channels collection. A network defines a physical LONWORKS network,
while a system is an entity, both logical and physical, that uses the network fabric. Each
Network object has a MyVNI property which contains an AppDevice object which
contains the MonitorSets collection for that network. Each MonitorSet contains an
NvMonitorPoints collection and an MsgMonitorPoints which represent the network
variable and message monitor points contained in that monitor set.
One System object is supported per network. Channels are physical objects which may
be shared by multiple systems (each with their own independent OpenLNS Server); they
are accessible via the Network object.
The System object has a tree of objects below it. A TemplateLibrary object has the role of
a profile or “parts catalog”, containing generic parts that can be applied across different
objects. For example, a single HardwareTemplate object or DeviceTemplate object can be
defined that is later associated with more than one AppDevice . A HardwareTemplate
contains information such as the hardware type and Neuron model of a device and is
used only for devices with application images which are built from source code using the
LCA Field Compiler. A DeviceTemplate contains all the information necessary to define
a generic AppDevice ; the information contained in the DeviceTemplate can come from
the external interface files (.XIF, .XFB, and .XFO extensions), a source program, or the
device itself. A ConnectDescTemplate object describes a generic connection, including its
LonTalk protocol service and other connection attributes.
The System object contains a Subsystems collection. Subsystems are used to organize
devices similar to how directories are used to organize files—they could represent
groupings of devices in a room, for instance. The concept of a location in the OpenLNS
Commissioning Tool (CT) can be represented using a Subsystem. By allowing nested
Subsystems, the Object Server makes it possible to define subsystem hierarchies. For
example, a building subsystem may consist of floor subsystems, each of which consists of
room subsystems, each of which consist of HVAC, security, and lighting subsystems.
A single device may be associated with multiple subsystems, and must be associated
with at least one. For example, a VAV controller may appear in both a Floor subsystem
and an HVAC subsystem. When initially defining a device, it is first added to a single
subsystem. References to the device may then be added to other subsystems. The device
is not deleted from the OpenLNS database or decommissioned until all references have
been deleted. The device’s association with the first subsystem is also treated as a
reference, so it may be removed from its initial subsystem at any time.
The AppDevices collection, and the
AppDevice object s that are part of it, are key
components of a System. AppDevice object s represent individual application devices (also
called nodes). Both Neuron Chip-hosted and host-based devices are represented by this
object.
Each
AppDevice object contains an Interface object. The Interface object contains
LonMarkObject, NetworkVariable, ConfigProperty, and MessageTag objects that define
the external interface to the device. AppDevices may also contain an Interfaces collection
object, if the underlying physical device supports dynamic network variables.
DeviceTemplate objects also contain an Interface object that defines the external
interface for the device template. The DeviceTemplate object’s Interface has the same
definition as the AppDevice object ’s Interface.
User-defined object names must be unique within their respective collections. For
example, Subsystem names, AppDevice names, and Router names must be unique within