Engineered Systems NEWSHVAC Engineering SectorsHigh-Performance Buildings & AutomationCommercial HVAC

The Four Steps to Two-System BAS Integration: The Role of Iteration

This month, we dig deeper into the topic and take a look at nested use cases.

In my previous article on two-system integration, I discussed the four steps for effective integration. Just to recap, those steps are:

Step 1: Define the use case;
Step 2: Seek solutions for the use case;
Step 3: Build out work packages; and
Step 4: Secure contractors

How Does this Process Apply to Systems that Encompass More than Two Systems?

It used to be that the building automation system would act as a centralized point for integration; however, due to the rise of APIs and web-based systems, designers and engineers must consider that “getting data” to the building automation system might involve multiple layers of integration.

Based on my experience, multi-system integration is not something that can be specified using traditional prescriptive specifications. The CSI model simply does not lend itself to supporting an iterative design process with multiple layers of nested use cases.

For example, if you want to use a badge swipe in a parking garage to enable the HVAC and lighting in a tenant’s office, you may have to pull data from the parking management system to the access control system, which then will send data to the building automation system and then enable the HVAC and the lighting systems.

Does that paragraph feel overwhelming?

It’s normal if it does.

The good news is that the four-step process still works to engineer and execute even the most complex integrations. We just need to add one thing: iterations.

Often times when you are performing a complex multi-system integration you will find that the systems being integrated are not readily apparent.

For example, it may seem obvious to pull data from the parking management system, but how? Sometimes you can go directly from a parking management system. Other times you must interface through the access control system or through various HR systems like Workday.

The only way you will discover this is to map out the use case for initial integration and then work through the use case logically. If you find yourself at a point where you are asking, “How do I integrate to this this system?” Or, “Where will the data come from?” Then you have probably discovered a nested use case.

Nested Use Cases and the Power of Iteration

Nested use cases are use cases that exist within a use case.

Going back to our parking management system integration, you may have a tenant badge in, but then what? The parking management system may have to communicate with the access control system in order to ensure that the person can get into the building, and then the access control system can communicate that data to the building automation system.

Those are two different use cases. Not properly identifying this will cause major issues with system specification and selection.

This is also why you must utilize the proper contracting vehicle. I have yet to see a complex multi-system integration project succeed that wasn’t at least a design-build project. At best, the process will be an integrated design process that involves the contractors.

What Is a Design Engineer to do?

First, you must accept that you will not have all the answers upfront. In a time when there is extreme cost pressures, you will be forced to engineer systems you simply cannot copy and paste in a design.

Second, you must find a way to involve contractors in the design process. I’m going to let you in on a little secret, even the so-called “technology integration” firms still rely heavily on the expertise of their contractors and suppliers.

Third, unlike simple two-system integration, multi-system integration must utilize the correct contracting vehicle. Without a method to engage contractors and adjust the design on the fly, integration simply will not happen, at least not at the level of complexity required for a multi-system integration.

There you have it, the path to complex systems integration. In our next article we will be looking at the rise of SaaS solutions and how to design post-installation processes and products into your design.

Looking for a reprint of this article?
From high-res PDFs to custom plaques, order your copy today!

Phil Zito is the founder and CEO of Building Automation Monthly, an online building automation training provider. Prior to founding Building Automation Monthly, Zito led the technical integration program for Johnson Controls’ $250 million integration business. During his time in the controls industry, he has held roles in operations, sales, partner management, and engineering. Zito is the author of “Building Automation Systems A to Z” and has published more than 140 podcast episodes. Contact him at phil.zito@buildingautomationmonthly.com.