If You Spec It, They Will Come Out of date and over spec’d designs are failing to address the major problems of most control systems

Brad White, P.Eng, MASc Principal, SES Consulting Inc.

Lately, I’ve been spending a lot of time thinking about why the overwhelming majority of occupants are so unhappy with their temperature control. An encounter on the show floor at AHR last month forced me to look in the mirror and really think about my role (as a consultant) in contributing to this abysmal state of affairs. My conclusion was that consultants and engineers (myself included) are designing control systems that overlooking some key elements and all but ignore many of the most important innovations in controls from the past few years. Some of these innovations, like the use of personalized controls, have been shown to improve occupant satisfaction significantly.

The relevant encounter on the floor at AHR went something like this:

Me (talking with a controls vendor whose products I regularly spec): “This smartphone app you have that allows occupants to interact with the BMS is very cool, are you doing a lot of deployments?”

Vendor: “Actually no, we’re not really sure why; we think maybe the contractors see it as extra work and aren’t including it.”

Me: “This is something that should just be in the spec…that reminds me, I should probably update OUR specs to include this”

I’ve been ranting on a fairly regular basis lately about how things like giving occupants this sort of personalized controls can help significantly improve their satisfaction and even lead to improved productivity. Despite understanding the value and knowing that at least some vendors have apps like this available, it hadn’t occurred to me to include it in our specs. In this case, it can’t simply be blamed on having just copied and pasted past specs without bothering to have updated anything, though this is something that engineers always need to be vigilant about. In other ways, our specs are very up to date, for example, by including a provision for long term data storage and use of metadata tagging so that our BMS systems are “analytics ready.” There’s a more fundamental oversight here. We are focused almost exclusively on the technical aspects of how control systems are assembled and function with minimal attention given to the “softer” side of our systems.  How do you spec a good user experience?

Virtually any control spec I’ve ever come across, include the ones I’ve written, looks much the same as any other engineering document. They go on for pages and pages on things like wire gauges, response speeds, sensor accuracy and panel sizes, commissioning requirements, etc. ad nauseam.  The part of the spec devoted to user interfaces is tiny by comparison and, even then, it’s typically devoted entirely to the operator’s front end. This stuff is all important to be sure, and many engineers do not pay sufficient attention to the technical details of control systems, but I have yet to see a spec that includes even the barest consideration of how an occupant will interact with the BMS. This is where a BMS is fundamentally different from spec’ing say an air handling unit that doesn’t really have an “end user” so to speak. Yet we spec a BMS and an air handling unit pretty much the same way. The assumption, by and large, seems to be that all systems are more or less the same and whatever thermostat we end up with will be good enough. Given the high levels of dissatisfaction of temperature controls among occupants, this thinking is clearly flawed. If we’re going to design control systems that occupants are satisfied with, it’s time for engineers to stop treating the BMS as just another part of the mechanical or electrical system.

[an error occurred while processing this directive]So how can we make things better? While something as nebulous as “great user experience” is hard to write an ironclad technical spec for, it is considerably easier to know it when you see it. One way, therefore, to approach this would be greater reliance on the RFP (Request for Proposal) and use of performance spec’s that emphasize the What instead of the How. In other words, bidders, you tell us how you will approach ensuring a great user experience for the occupants, and we will include that as a consideration when evaluating proposals. Now, this may seem like a bit of a cop out on the engineering side, but given the ever-increasing diversity of approaches that the various vendors take, I think this approach is pretty sensible. This view may be unpopular among my colleagues, but I think engineers may sometimes feel the need to issue dense technical specifications to justify their role (and their fees) on a project. Sometimes a well-crafted 5 page RFP is a better approach, and results in better outcomes for our clients, than a 20+ page detailed spec full of technobabble. To take considerable liberty with the words of William Shakespeare: brevity is the soul of wit and also, I believe, the sign of a good consultant. This is particularly applicable to the controls industry as the relative straightforwardness of systems consisting of panels, points, sequences, and trend logs are giving way to systems that incorporate rapidly evolving cloud-based analytics, self-learning edge devices, and an endless number of IOT plugins. Maybe in a few years, new standards will start to become commonplace enough that we can confidently be more prescriptive on some of these items. But, for the foreseeable future, it’s the wild west out there, and we control engineers need to adapt, lest we become out of date anachronisms ourselves.