When 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?

Hardware 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.

Software 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.

Modern 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?

So, 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.

Often 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.

On 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

Those 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.

This 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.

Now, 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.

This 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 Niagara

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.

Xenta 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 interfaces. 

Programmable 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.

Although 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 well.

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.

As 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.

Xenta 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.

[an error occurred while processing this directive]In addition to point discovery, reading, writing and overloading, Niagara understands “advanced” Xenta features – alarms, schedules and trendlogs.

Xenta 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.

Xenta 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.

Xenta 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.

It 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.

Sometimes 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 costs.

Big 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.