In commercial and industrial construction projects, the design requirements are constantly in flux, and change management is one of the most arduous parts. For DDC programmers, this effect can be amplified since the building automation trade’s most intense time is in the later portions of a construction project, when the nuances of the original building design manifest in the built environment, and all of the project teams come together to deliver a high-quality product for the building owner.

As BAS product vendors improve and iterate on their offerings, there’s an opportunity to take advantage of better and newer technology offerings. However, a BAS is typically a 15-plus year investment in the building as an asset, and so the DDC programmers who are responsible for working with both the old and new must balance all the variations in technical knowledge. A DDC programmer must simultaneously understand control theory, pneumatic calibration techniques, low-voltage electronic signal types, OSI network layers, and IP network layout best practices, just to mention a few.

I alluded to this in my column about DDC application engineers, but there is also a source of new innovation in this industry as it relates to control sequences. These new sequences are designed to squeeze more and more energy efficiency out of the built environment, and the fine details must be worked out by DDC programmers. Implementing these new sequences calls for DDC programmers to increase their knowledge of data science techniques, statistical analysis, and, even in some cases, machine learning.

In a sense, a BAS should ideally be a “set it and forget it” sort of thing, but the reality is that being such a long-term investment, buildings change. Building tenants move in and out, usage patterns change, and there are good reasons for things like maintenance contracts. That said, someone who has worked with an aging DDC system knows the value a new system provides. For a DDC programmer working on a retrofit project, or on a project where the customer’s facilities management team is experienced with other buildings, it can be very rewarding to hand over a finished and flawless system to them, because they truly know what they’re getting. It’s rewarding to know that as they use this system for years to come, it will continue to drive value for them.

There can also be some reward in the challenge of coming up with the optimal solution to a problem. Years ago, I was handling some integration and programming tasks related to a weather station. We were sent some existing programming logic by the customer to use as a reference for our implementation, and the weather station provided a scaled value from 0-360 degrees, representing wind direction (among other sensors). The customer wanted the wind direction to be presented as directions like North, Northwest, North-Northwest, etc. The trouble we had was that the building we were working on had the weather station mounted in a different orientation than the one the reference programming was made for. This was “functional block” programming, and the engineering tool showed a page full of logic to accomplish this task. As I tried to dissect the way this programming was put together, I came to remember a concept called “integer division,” and I managed to get the same outcome in four programming blocks that previously took 25 blocks, and it could be adjusted for mounting position.