Getting all your building's systems to talk to one another can pay off in multiple ways, from making those systems more functional to centralizing data and making it easier to monitor and manage building performance.
Even though the benefits are clear, there seems to be precious little in the way of structured education or training for the implementation of building system integration. So much of what we learn is through the process or experience of integrating systems, which exposes the real life integration issues with data, clients, the client’s contractors, the BAS (building automation system) network, etc.
The origin of system integration started with fire systems triggering reactions from other related building systems, like HVAC (heating, ventilation and air conditioning systems), access control, elevators, etc. Today system integration includes all of the control systems in a building, but also encompasses facility management systems, business systems, and eventually utility grids.
Here are some things the industry has learned along the way:
Existing buildings have baggage. Existing buildings usually have a lot of pre-existing issues that must be resolved during the integration project. Many of these issues will affect a system integration project but are matters unto themselves.
One example: the lack of a naming convention for building equipment. The system integrator can’t manage a project where similar equipment has many different names; that’s a recipe for confusion. So the system integration team has to spend time developing a naming convention, coordinating it with the client and then translating all the existing equipment names over to the new naming convention.
A second example would be the BAS network architecture, especially in large existing buildings or campuses. Over time, BAS controllers and field devices are replaced or added to the BAS network. Typically the work is completed by a series of different technicians from the local branch office of the manufacturer, and not a lot of thought is given to the network architecture and impact on the throughput on the network. The result over time is the BAS network becomes unbalanced with too much traffic on some trunks, adding complexity for the system integrator to acquire data across the network.
Next page: Why you need a plan for system integration
Fault detection applications do not come "right out of the box." Fault detection is analyzing real-time data from an HVAC system against a set of rules that address relationships of different HVAC equipment. It has proven to be the killer app for buildings -- saving energy and significantly improving operations. However, it doesn’t just come “right out of the box” as if it were a software program you install on your PC from a thumb drive.
Almost every building and HVAC system is different and you end up having to customize the fault detection rules. Surely you’ll find similar buildings and HVAC systems in some cases, such as retail stores, but the vast majority of buildings will need to tweak or customize fault detection rules. That’s not necessarily a bad thing, as the customized rules are likely to be more accurate and based on client needs, but customization requires time, possibly extending schedules.
Don't have applications without a plan. System integration can facilitate applications such as consolidated alarm management, where the alarms from all the building control systems can be monitored and managed from a single application. If fault detection is the most effective software application, consolidated alarm management may be in second place.
The easiest part of deploying an alarm management application may be acquiring the alarm data from the building systems. The more difficult part is having an alarm management plan underlying the application.
The alarm management plan usually lists the alarms, prioritizes them, details the response for each alarm, groups various types of alarms, etc. Many building owners don’t have an alarm management plan, but without it the application goes nowhere; therefore the contractor for the system integration must work with the owner to prepare a comprehensive plan.
Less is more. One approach to system integration is to implement a platform that acquires data from every data point for every system. It maximizes the data available to present to users or to analyze. It would seem to be the optimal approach.
What you find, however, is you don’t need all that data; what you really need are just the important data points that support key performance indicators or specific analytic routines. The downside to acquiring all the data as opposed to selective data is that your database becomes bloated with information you’ll never use. Acquiring that data adds traffic to the network, affecting throughput – especially the case with older BAS controllers and data acquired from slow RS485 networks.
More Is better. There is no such thing as having too much information and documentation about the building’s sub-systems. By the end of a system integration project you will have to know every system in detail: The sooner you get that done the faster the project will be completed. You’ll want as-built drawings, control drawings, points lists, model numbers, versions, system server locations, etc.
Next page: Getting owners involved
Early owner involvement is key to success. Building owner/operator input regarding the user interfaces is critical -- and the sooner they get involved the better. The "uilding owner will consist of many disparate groups. You need to identify the user groups and spend time on what’s important to them. The initial implementation meeting should address the tasks and expectations for the client’s involvement. If you bring the client in too late in the process you risk alienating them and having them feel the integrated solution doesn’t address their needs, not to mention adding in additional cycles of revisions.
The project team needs to clearly lay out the revision process at the start and stick to it. If the owner/operator is unable or unwilling to participate, get them involved by giving them a choice between different versions of user interfaces instead of asking them to comment and provide direct input.
Don't race to the finish line. For new construction, integration work tends to happen at the very end of a project, once all building system contractors are finished. For some projects, getting to final completion and starting the handoff to occupancy and operations can be chaotic. Sticking to a schedule during this time is a challenge and needs to be a greater consideration than usual.
Clearly establish from the start what tasks by others are key to starting integration work and what the impact of any delays will be on the project schedule. It's equally important to define what is required for substantial completion versus final completion so that everyone’s expectations are the same and the contractor is able to close out the project in a timely manner.
Design integration into new construction. The design of a new building would seem to be the perfect environment for integration of building systems. Without any baggage that an existing building may have, the design engineer starts with a clean slate and can specify exactly what is needed in a formal Division 25 Integrated Automated construction document.
However, the idea of integration automation is driven by the owner, and without clear direction, designers will simply design their system: the mechanical/electrical professional will integrate fire, HVAC, access control and elevators via a traditional building management system, and that will be the extent of the integration. The further along the design process gets the more resistance there is to changing the standard proven automation design.
The process for developing and eventually bidding the integration requirements is slightly different; it involves much more coordination, touching on each of the designers or engineers that are specifying systems, each of the contractors that are installing systems, and many different client actions. Getting these multiple groups to understand the integration concept and their role and responsibilities in designing and deploying can be disordered and a challenge.
Also, the construction documents bid out for the integration automation may be laden with software requirements and IT infrastructure, and seem foreign to a construction management (CM) company typically procuring a certain amount of units of specific materials or equipment. A designer may be required to quantify any aspect of the integrated automation (server processor speed, number of dashboards, number of points, etc.) just to satisfy that the construction documents for the automation are "biddable."
Building systems integration continues to demonstrate a significant impact on building life cycle cost, primarily impacting operations and energy consumption. As the process for implementing integration projects continues to develop and improve, and as buildings become more complex, owners and facility management will more readily adopt the integrated approach. With that will come a rise in structured education for system integration as well as enhanced solutions.
For more information, write us at email@example.com.
Illustration of analog VU meters courtesy of creative4m via Shutterstock.