In my experience, direct digital control (DDC) programmers have come to be regarded as “the men behind the curtain” in the way building automation systems (BASs) are put together. There are a lot of moving parts to systems like these, both in a physical sense but also in a logical sense. The word direct signifies that the unique systems responsible for equipment controls must be configured in such a way that they can operate equipment completely on their own but also in such a way that they can drive benefits when networked together. To design and build systems in this fashion takes a diverse set of knowledge and experience.

I have held some adjacent roles in the past and have occasionally backfilled these roles in the short term, so I have some experience in this area. Combining this with some great input from my colleagues who have not only held the role of DDC programmer but also managed a team of them, this column examines key aspects of this very important job.

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.