Building Technology Integration: Getting Systems to Talk

Why do building systems end up in silos?

Walk through a typical Sydney commercial building and you will find a surprising number of independent systems. Air conditioning, lighting control, access control, CCTV, fire detection, lifts, energy metering, car park equipment and tenant services often each have their own supplier, software and network.

This happens for understandable reasons. Systems are procured at different stages of a project, often by different contractors. Each vendor naturally favours its own platform, and every upgrade or tenant addition brings another interface.

The result is a building that holds plenty of data and struggles to use it. A facilities manager might switch between four screens to diagnose a comfort complaint. Opportunities that depend on combining information, such as adjusting air conditioning according to actual occupancy, remain out of reach.

In my view, siloed systems are the main reason many smart building promises fall short. The technology works in isolation, yet the value sits in the connections between systems.

What do open protocols and building management system integration involve?

Systems communicate using protocols, which are agreed rules for exchanging data. Some protocols are proprietary, owned by a single vendor. Others are open, published standards that any manufacturer can support.

Common open standards in the building industry include BACnet and Modbus for controls and metering, along with newer approaches using web based interfaces. You will also meet semantic tagging and naming schemes, which describe what each data point means, such as a supply air temperature on a particular floor. Details vary between buildings and standards evolve. Ask your engineer or integrator which options suit your site.

When you plan building management system integration, a sound approach is to ask these questions of every system: * Which protocols does it support, and are they open and documented? * Can another party read its data, and under what licence terms? * What does it cost to enable the connection, and who pays? * Who maintains the interface when software is updated?

Open protocols matter for a practical reason. When you choose a different maintenance provider or add a new analytics tool in five years, an open building can adapt. A proprietary building often requires expensive rework or a full replacement.

How does a single data layer help?

Even with open protocols, connecting every system to every other system quickly becomes messy. A cleaner pattern places a data layer in the middle. Each system sends information to the layer in a consistent format, and applications such as dashboards, analytics and reporting tools read from it.

Think of it as a shared library. Instead of each application learning how to speak to each system, they all use the one catalogue. When you replace a system, you reconnect it to the layer rather than rebuilding every application.

A good data layer offers: 1. Consistent naming. Every point follows the same convention, which lets software interpret data automatically. 2. Historical storage. Trends and comparisons need data kept over time, owned by the building owner. 3. Controlled access. Different users and applications see only what they should. 4. Documentation. Someone can explain what each point means, years after the original installer has left.

This layer should sit under the owner's control. Ask your lawyer to confirm that contracts state who owns the data and how it can be exported. I touched on this in my article about where the return sits in smart building technology.

Who is responsible for what?

Integration often fails in the gaps between teams. The ICT team looks after networks and security. The facilities team operates the plant. The vendor supplies and configures the equipment. Each assumes another is handling the connection.

A responsibility matrix, agreed at the start, closes those gaps. It should show, for every system, who: * Designs and approves the interface. * Supplies and maintains the network connection. * Configures and tests the data points. * Monitors the system day to day. * Pays for licences and updates.

Include the project team as well. The consulting engineer should specify integration requirements in the design documents, and the head contractor should be accountable for delivering them. Where requirements are vague, vendors will quote only for their own scope, and the owner discovers the shortfall after handover.

A short quarterly meeting between ICT, facilities and the main vendors keeps changes visible.

What are the cyber security basics for building systems?

Connected building systems are part of your organisation's attack surface. Control networks that were once isolated are now linked to corporate networks and cloud services, which creates risk if they are poorly protected.

Sound basics include: * Network segmentation. Keep building systems on separate networks from corporate systems, with controlled connections between them. * Access control. Use individual accounts and strong authentication. Remove default passwords and revoke vendor access when a contract ends. * Remote access. Allow vendor connections through managed, logged channels only. * Patching. Agree who applies updates to controllers and servers, and how often. * Inventory. Maintain a current list of every connected device. * Incident planning. Know who to call and what to do if something goes wrong.

Involve your ICT security team early and ask for requirements to be written into vendor contracts. Cyber security for building systems is a specialist field, and a qualified adviser can assess your specific exposure. Obligations that apply to critical infrastructure or to particular organisations can change. Confirm the current position with a suitable adviser.

Why does commissioning decide the outcome?

Integration is only real when it has been tested. Commissioning is the structured process of proving that every system works as designed, individually and together.

Insist on integrated testing. Show that when a fire alarm activates, the lifts, air conditioning and access control respond as specified. Prove that data from every energy monitoring point appears in the data layer with correct labels and units. Confirm that alarms reach the right people.

Allow time in the program for this work. Ask for a witnessed test plan, a defects list and a handover pack containing drawings, point lists, passwords held securely and training records. Consider a follow up review after the first season of operation, because many issues appear once the building meets summer and winter conditions.

Final thoughts

Building technology integration rewards owners who treat it as a design and governance question rather than a product purchase. Open protocols, a shared data layer, clear responsibilities, sound security and proper commissioning give a building the ability to improve over time.

If you would like more practical Sydney property insight, subscribe to my newsletter, The Fine Print, on LinkedIn and follow along.