BTL Mark: Resolve interoperability issues & increase buyer confidence
|Smart BMS Upgrade
TAC Xenta / Tridium Niagara Case
building management systems fall out of date, it is necessary to
modernise them, which can be a challenging process. Reusing the
original hardware enhanced with the right software can help achieve
this task quicker, cheaper and in a more flexible manner while reaping
the benefits of new technologies.
Why upgrade BMS?
fails eventually. DDC and PLC controllers can operate for one or two
decades or longer, but not forever. Their support and replacement
become more and more expensive as manufacturers stop producing outdated
hardware and there are fewer trained engineers available.
evolves very rapidly and ten years old program usually appears
prehistoric both in terms of its look & feel and functionality. And
even if its user is still satisfied with it, there are other pitfalls.
Let’s say a facility manager wants remote access to BMS computer for
24/7 monitoring. IT department will not allow it unless the Windows
version is still supported by Microsoft and is free from known
vulnerabilities. However BMS software runs on pretty old OS and cannot
be easily transferred to a new version.
BMS software has many new interesting features compared to “classic”
10-20 years old BMS packages: remote access via web-browser, semantic
tagging, analytics, new communication protocols like MQTT, AMQP, OPC
UA, EnOcean, Zigbee and domain-specific protocols like DALI or SMI,
cloud integration, AI & ML, energy dashboards, predictive
maintenance. These features allow to save energy, improve performance
and reduce the number of failures. Interestingly, most of them can be
implemented on the BMS management level, not in DDC controllers.
What are the biggest challenges?
why haven’t all these BMS systems been upgraded already? The biggest
obstacle here is the cost, naturally. There are two parts to it: the
cost of the upgrade itself and, potentially, the cost of having the
building unoccupied during the transition.
installers recommend to completely remove all existing BMS controllers
since they are not familiar with them or have an agreement with another
manufacturer. Replacing all controllers may be hugely expensive,
comparable to building a brand new BMS. It may lead to control panel
replacement or even to field equipment replacement along with cable
rewiring. Then all controllers must be reprogrammed and recommissioned.
It is hard to do if the building is in use, especially if some
equipment is mission-critical, like in data centres.
the other hand, if the client does not want to throw away all the
hardware which may still serve for the next decade, in most cases, they
are forced to reach out to the original vendor. That’s because their
BMS is proprietary, and nobody else is able to communicate with it. The
original vendor normally offers an upgrade path with less hardware
replacement required. However, with no competition, they could charge
more for software, hardware, labour and maintenance.
Retrofitting via Integration
challenges were identified a long time ago; that’s why open protocols
and vendor-neutral integration products were introduced. Yes, I’m
speaking about Tridium Niagara.
is how it works. System integrator follows “if it ain't broke, don't
fix it” principle and leaves in place all operational field and
automation level devices – sensors, actuators, DDC controllers. On the
management level, they add new software which can communicate with
proprietary devices and features new graphical front-end with all the
bells and whistles.
if any old DDC controller fails, it can be replaced with a new
non-proprietary controller, which can be integrated into the same
framework via open protocols like BACnet or Lonworks.
approach allows to retrofit the whole BMS in a very short time with all
equipment working and without the extended shutdowns. If necessary,
automation devices can then be replaced “organically” – in phases or if
and when they fail. The cost of such an upgrade is much lower than the
“replace all” scenario but provides more freedom compared to vendor
recommended upgrade path.
Integration of TAC Xenta into Tridium
TAC (now Schneider Electric) Xenta BMS is a popular system installed in a large number of buildings all over the world. Generally, it consists of Vista – front-end software and Xenta – DDC controllers, gateway and interfaces.
controllers are application-specific (Xenta 100 series) or freely
programmable (Xenta 401, 301, 281, etc.). They all are connected to LON
FTT-10 two-wire communication bus together with IO modules (Xenta 411,
421A, 451A etc.) and perform real-time control. Quite often Lonwork IP
(EIA-852) backbone is used to utilize fast Ethernet and fibre optic
Xenta controllers are fully AST – alarming, scheduling, trending –
enabled, which means they can generate alarms, operate according to
built-in calendars,weekly schedules and periodically log real-time
values. These functions make Xenta controllers less fault-prone: they
can function successfully even in case of full communication failure.
Xenta devices have the LonMark logo printed on them, they rely on a
proprietary protocol. That is the reason why switching to other BMS
vendors is problematic. Other systems might support LonWorks, but it is
not sufficient: to see all points, access schedules and trends, receive
alarms and override IO, the proprietary protocol should be supported as
Xenta proprietary protocol driver
has been implemented for Tridium Niagara AX and Niagara 4 by
baudrate.io, and it has been successfully used in many projects. The
integration process is familiar to any Niagara engineer, whether they
work with Tridium, Honeywell, Distech Controls, Johnson controls or any
other Niagara vendor.
mentioned before, Xenta BMS utilizes LON FTT-10 and LON IP
communication interfaces, both of which are supported by Xenta driver
for Niagara. Usually the driver is deployed in Niagara JACE, but in the
case of LON IP it can operate in Supervisor as well. Similarly to
generic Lonworks, all Xenta devices are discovered from the network.
After the devices have been added to Niagara station, model and
firmware versions are automatically displayed.
The next step is to get all points – the main building blocks of any BMS. They can be either imported from program files or discovered from the device itself. This feature is useful if the TAC Vista server has failed and no backups are available. Imported points are presented with names, descriptions, units and types, so engineers can easily understand the purpose of each point. As soon as the points are added to the station, their real-time values are polled. All changeable points – setpoints, time delays, constants – can be written to.
controllers have a nice feature that allows overriding their IO points.
So an operator can manually open a valve or temporarily set a specific
value for the temperature sensor for maintenance purposes. All these
features are available in Niagara and the overridden point will be
shown with a colour-coded status.
In addition to point discovery, reading, writing and overloading, Niagara understands “advanced” Xenta features – alarms, schedules and trendlogs.
time schedules are mapped into Niagara schedules, so they can be
imported from the controller, viewed and edited in a computer or mobile
browser and then exported back into the controller.
alarms can be routed into Niagara alarm console or any other recipient
– e-mail, cloud, database, third-party software. Instead of creating
alarms in Niagara, engineers just specify what to do with all Xenta
alarms based on their priorities.
trends are gathered in Xenta device, then sent to Niagara host every
few hours or days. Again, it considerably reduces the
integrator’s engineering time. Xenta trends become Niagara histories
and they can be viewed in every HTML5 browser, pushed to the cloud via
MQTT, processed in Niagara Analytics or SkySpark.
is important to mention that when AST functionality is implemented in
the end devices, there is no need for supervising systems to constantly
poll all related points. This way network bandwidth is used only to
monitor necessary points, which can be updated every few seconds. As a
result, the client receives a very fast real-time graphical interface,
which is an important part of a good user experience.
it is hard to believe that the same result – upgrading an outdated
system or adding new features – can be achieved with such a different
level of effort. In our case, some integrators were able to upgrade the
whole BMS in a few days without disrupting tenants. And while mostly
Niagara replaced the original Vista front-end, sometimes it was used as
a protocol gateway, for example, to translate Xenta points to BACnet.
Or as a data pump to feed Xenta real-time values and trends to
cloud-based energy analysis software. Or to collect Xenta alarms and
send them to a unified multi-vendor alarm console. There are various
scenarios to get extra value from the old system without the massive
vendors try to persuade customers to spend a lot of money even if it is
not really necessary. They market it as “we deliver systems, not
products.” This approach actually may provide some benefits to the
customer, however, those are not as certain. Integration of multiple
vendor components allows to pick the best options without spending a
fortune. It does require a higher level of technical competence – one
should be familiar with various systems instead of one, – but provide
extra value for the customer and system integrator.
About the Author
Paul Tomas is a partner in baudrate.io,
a company developing software for building automation. Paul has over 20
years of experience in the BMS industry and worked with Tridium, Cylon,
Honeywell, Schneider Electric and many other systems. He is interested
in the latest developments in AI & ML and how they could be applied
to the building automation field.
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]