Imagine this: A building owner comes to you and wants to control his lighting system through the facility’s BAS. At first you may be tempted to specify that the lighting contractor and building automation contractor will “coordinate” the integration.

The specification language may look something like this:

6. Provide hardware, software, and wiring to provide communication interfaces with each of the systems listed below.

a. Computer room air conditioning (CRAC)

b. Lighting control system

Here is the problem with that approach; it won’t work.

Now, I know you may be thinking in your mind, “But Phil, we’ve been doing this for years.” OK, and guess how many of those buildings still work after the lighting and BAS contractor fake their way through commissioning? Not many.

The reality is, even simple integrations like a BAS to lighting integration require a more detailed process. The good news is that a “more detailed process” does not mean more work. Not if you follow the steps.

Step 1: Define what the use case is

This seems to be a straightforward step. The end user wants to turn on the lights via the BAS, easy right? Wrong!

This is the step you should be spending the most time on.

You may be tempted to simply say that the use case is turning the end user’s lights on via the BAS, but what happens when someone wants to use a light switch? What happens at night? What happens when there is a fire alarm?

As you can see, there is much more to “turning the lights on” then simply pushing a button. This is the most important step, and you must take some time to write up a formal use case narrative (we will look at this in detail in next month’s article).

Step 2: Seek solutions to the use case

You can now use your formal use case narrative to seek solutions for the use case. The beauty of having a written use case narrative is that you now have features that are quantitative and not qualitative. Does your use case require occupancy sensors in the light switches? That is now a feature that is required for the solution.

In a future article, we will spend time evaluating a use-case narrative and how to identify features that can be quantitatively measured.

Step 3: Build out work packages

With the solutions from step two, you can begin to build out work packages for contractors to respond to. Work packages are contractual documents, like specifications, that identify the use case and the expected solution. Contractors can then respond to these work packages as part of the request for proposal process.

As a side note, this process works great for plan and specification projects because you can build up a library of work packages that you reuse on every project. I want to make sure you captured what I just said in the previous sentence. If you are engineering a solution for every single project, you are wasting time and effort.

Your goal should be to identify common use cases to build out a set of work packages that can be used across multiple projects. You may still have to modify these work packages, but the act of modifying work packages is much less intensive than creating work packages from scratch.

Step 4: Secure contractors

With all the prework done, now you can assist in the selection of contractors to execute the work packages. The beauty of following this four-step process is that it reduces the amount of coordination and the amount of “on-site engineering.” The problem with on-site engineering is that it creates nonengineered solutions that are often piecemealed together. This results in systems that are not properly documented and unable to be supported post warranty.

There you have it, a real-world implementation of the four-step integration process. In next month’s article, we are going to look at a more complex integration consisting of three systems with different protocols. In the meantime, if you have any questions, feel free to reach out to me. I’d love to answer your questions in future articles.