Echelon IzoT Commissioning Tool - Manual (Page 266)

single network using a portable network server under a sequential network installation scenario, in
which no permanent server is needed. In most cases, however, it may be easier (if not necessary)
to install each floor as a separate network. Once the entire site has connectivity, the individual
floor networks can be merged into a single network representing the high rise.
To support these scenarios, IzoT Commissioning Tool provides the ability to merge IzoT
Commissioning Tool networks.
Network Merge Considerations
When you create a new L ON W ORKS network that will entail merging individual networks, minimize
the number of objects in the top-level subsystem. When you merge two IzoT Commissioning Tool
network designs, the merge process will be disruptive to the operation of the networks. For example,
devices in the source network will be assigned new subnet/node addresses, connections will be
recreated, and authenticated devices will have authentication disabled for a period of time. Devices in
the destination network will generally be impacted less, but they can be affected if their connections
are modified to accommodate the new devices from the source networks.
Limitations
The network merge process has several limitations:
• Server support only. You can only merge networks from a local client. You cannot merge
networks from a remote client.
• Single direction only. You cannot stop the merge process once it has begun. You can, however,
restore a network from an IzoT Commissioning Tool backup file, if needed.
• Single root subsystem. You can only merge networks that have a single top-level subsystem (this
is the default for OpenLNS CT drawings). If the network has more than one top-level subsystem,
as may be the case when using an OpenLNS network database created by another network tool,
the pre-merge utility will fail. You must remove or relocate all but one of the top-level
subsystems, before retrying the pre-merge utility.
Information Loss
When you merge networks, the following information in the source network will be lost:
• Registered plug-ins. Plug-ins registered in the source database but not in the destination database
must be re-registered following the merge.
• Non-channel object descriptions. Channel descriptions are stored in the channel SmartShapes as
well as in the network database; therefore, they are transferred to the destination database. Other
object descriptions that are not stored in the SmartShapes are lost.
• Source network addresses, group IDs, NV selectors, and other related information. All
devices in the source network are assigned new addresses in the destination network domain and
all connections are reconstructed. Therefore, all subnet/node IDs, group IDs, and NV selectors,
will likely change. In addition, all previously commissioned devices in the source network must
be recommissioned.
• Commission Status. Devices in the source network are unconfigured in the destination network
upon the completion of the network merge. However, the Neuron IDs of the devices are preserved
in the destination network.
• Network service devices. All network service devices (and their functional blocks and
connections) in the source network are removed during the merge.
• Unreferenced device templates. Device templates that have been imported but do not have any
corresponding devices are not created in the destination network.
250 Maintaining Networks