8
ICC
3.
Gateway Concepts
The XLTR-1000 is a member of the Millennium Series communication gateways.
Members of this family are designed to provide a uniform interface, configuration
and application experience. This commonality reduces the user’s learning curve,
reducing commissioning time while simplifying support. All Millennium Series
gateways are configured using the ICC Configuration Studio. The XLTR-1000
provides simultaneous support for many different communication protocols,
allowing complex interchanges of data between otherwise incompatible
networks.
The heart of the Millennium Series concept is its internal database. The database
is a 4 KB, byte-wise addressable data array. This provides a total size of 4096
bytes for the entire database, referred to as DB
Size
in the protocol driver manuals.
The database allows data to be routed from any supported network to any other
supported network. Data may be stored into the database in either big-endian
style (meaning that if a 16-bit or 32-bit value is stored in the database, the most
significant byte will start at the lowest address) or little-endian style (meaning that
if a 16-bit or 32-bit value is stored in the database, the least significant byte will
start at the lowest address).
The other fundamental aspect of the Millennium Series is the concept of a
configurable “service object”. A service object is used for any master/client
protocol to describe what service (read or write) is to be requested on the
network. The gateway will cycle through the defined service objects in a round-
robin fashion; however, the gateway does implement a “write first” approach.
This means that the gateway will perform any outstanding write services before
resuming its round-robin, read request cycle.
Additionally, the database and service objects provide the added benefit of “data
mirroring”, whereby current copies of data values (populated by a service object)
are maintained locally within the gateway itself. This greatly reduces the request-
to-response latency times on the various networks, as requests (read or write)
can be entirely serviced locally, thereby eliminating the time required to execute
a secondary transaction on a different network.
In order to facilitate the free scaling and conversion of native data values, a user-
configurable “multiplier” and “data type” exist for some network configurations. All
network values are scaled by a multiplier prior to being stored into the database
or after being retrieved from the database. The data type is used to determine
how many bytes are allocated for the value in the database, whether the value
should be treated as signed or unsigned, and whether the value should be
interpreted as an integer or a floating point number upon retrieval from the
database.
A typical use of the multiplier feature is to preserve the fractional components of
a network value for insertion into the database. For example, if the floating-point
value “3.19” is read by the gateway from a remote BACnet device, then we could
use a multiplier value of 0.01 to preserve all of the significant digits of this value:
the network representation (3.19) will be divided by the multiplier value (0.01) to
