- Project plans
- Project activities
- Legislation and standards
- Industry context
- Specialist wikis
Last edited 08 Nov 2020
The problems with smart buildings
A record is a circular lump of vinyl into which is embossed a series of bumps and grooves, that when rotated and a fine needle run in said grooves, emits sounds we call music. If the grooves get damaged, the needle sticks in a hollow and endlessly repeats the same series of sounds.
We don’t have these problems any more. Because we have digital, and I can listen to “The girl from Ipanema” on various electronic devices scattered not just throughout the house but tucked in various crevices around my person. Well, I would if I could, but I can’t get iTunes to recognise a file downloaded to one device to play back on another. The software won’t tell me why. It sits there, literally and metaphorically mute. Clearly I need an expert to help. Suddenly I feel obsolete and useless.
The answer isn’t to dust off my 1930s gramophone and play a 78. Far too much like hard work. And the 1930s sound reproduction doesn’t match my 21st century expectations. I’ve tried playing the iPad but there’s a slight problem of hardware incompatibility.
This, as an analogue for smart technologies in buildings, is pretty much where we are today: adding complexity to comfort systems to meet supposedly higher expectations, but introducing risks we subsequently can’t handle because the technology has outstripped our abilities to manage it. It often also alienates us in the process and compromises the building’s performance. Get the interfaces wrong or trade features for usability and robustness, and see where it gets you. All carbon dioxide monitors I’ve come across in classrooms have more vices than virtues.
This isn’t a Luddite perspective, nor a romantic notion that manual devices are better than automated ones. The problem is whether the technological solution is appropriate to the need. But even that isn’t the problem. The real problem is whether the needs and expectations of the building users have been properly considered before reaching for a highly complex technological solution when, actually, reaching for a simple manual handle or switch might have done the job just as well.
An even bigger question is whether, in today’s time-pressured, budget-strapped design process, all the assumptions in the client’s requirements and the design brief have been fully tested; and indeed, tested against well-expressed operational outcomes. It doesn’t just take time and diligence to do this – it really makes the brain hurt too. So it’s no surprise that smart technologies – however they are defined – are mostly a given at the start of the project and don’t get the level of interrogation they demand. There’s no shortage of controls companies selling the dream.
Here are some insights gleaned from building performance studies that might help you see things a little differently.
We need to realise this, because most of the time building occupants couldn’t care less about a building’s sustainability or low energy credentials,. They aren’t as enthusiastic about maintaining set points to meet a BREEAM Excellent objective, they just want to do their job and be comfortable without the building getting in the way. It’s not that they act wantonly and selfishly, it’s that the building’s systems aren’t on their radar most of the time. Smart systems that impose themselves on occupants will alienate, fall into disuse, or worse get vandalised.
Is this a case for central automation? It might be, but that’s not the point. You can have systems controlled centrally or you can devolve control to the occupants. Either way, it needs to be done well, and the interfaces have to be intelligible, responsive, intuitive and logical. In other words, systems need to be usable. A smart building is one that doesn’t make its users look stupid, as Adrian Leaman memorably put it.
We sell dreams but install nightmares
The sophistication of smart technologies needs to be matched by the sophistication of the installation, commissioning, user training, and system fine-tuning after handover. Often it’s nowhere near what it needs to be for the technologies to deliver their promise. Building performance studies are littered with automated lighting that either turns off lights when they’re needed, or prevents them from being turned off.
A study of recent schools and academies revealed that reasonable lighting energy consumption of 15 kWh/m2 per annum is achievable in schools below about 2,000 m2, but scale up over 8,000 m2 and that same lighting will double its consumption or more. The complexity of the control systems are outstripping our ability to set them up properly and manage them in operation.
Automatic window actuators are another example. They are usually noisy, and open and close seemingly randomly. They also become a maintenance burden and a financial drain, evidenced by a primary school that found itself saddled with paying high annual maintenance fees in perpetuity. Had this not been pointed out they would never have challenged it.
Controls designed for what they could do, not for what’s needed
As has been said many times before, unmanageable complexity is the enemy of good performance. And nowhere is this more obvious than in air-conditioning control devices with so many features that they defeat everyone but the system provider. And in schools, carbon dioxide monitors designed to inform teachers when to open the windows are usually tucked out of sight on a power rail somewhere, and in any case impossible to read without a magnifying glass. Usually these systems come with irritating warning sounds – usually the first thing to be disabled by a teacher trying to concentrate.
Failures to communicate
Even after nearly two decades promise of interoperable communication protocols, systems that fail to communicate with each other are rife. Again, Building Performance Evaluation (BPE) studies reveal underfloor heating and passive stack ventilation systems that are intended to be controlled centrally by the building management system, but are actually controlled by the vendors’ standalone software that the Building Management System (BMS) can only monitor. And if it tries to intervene it can’t, because of incompatible software. Similarly, automated lighting systems that can only be adjusted post-handover by the vendor coming to site with a laptop for a £1000 fee become a financial headache.
Just because the Engineering Performance Specification requires centralised, open, or interlocked control between, say, an air-conditioning system and a heating system doesn’t mean it will be provided under the packaged sub-contract route, which leads to the next truism:
What the designers intend and what ends up being specified under a design and build contract is often different. Packaged solutions are packaged technologically, contractually, and staggered throughout the construction stage. In the absence of a commissioning engineer appointed early, and/or a talented, experienced facilities manager to oversee it all come together, it’s too much for the design team to keep tabs on, even if the terms of their appointment endow them with that authority. They may have the responsibility, but sensibly they’ll run a mile afterwards rather than take the rap for resolving performance problems caused by packaged sub-contracts whose systems should be interlocked, but aren’t. Someone needs to manage this all the way through. Commissioning starts at design.
Keep it simple, do it well, and finish it off properly
Those of us working in the field of Soft Landings have been saying this for years. But it doesn’t seem to slow the bandwagon of over-complicated, poorly thought-through, inadequately commissioned and ultimately occupant-alienating systems from being specified. In many building performance studies there’s a fundamentally sound building struggling to escape the limitations placed on it by over-ambitious technical specification.
Often the difference between success and failure is a fine one, and the clue to that is the buck-passing one hears from various parties to the project, along the lines of, “Oh well, if they’d only installed it properly”, or “if only they’d not value-engineered and put in a cheaper system”, or worse, “It’s not our fault if they don’t employ someone with the right skills to run it”. All of which might be true, if only for the likelihood that there was probably a much simpler way to have done it in the first place.
Which leads, ultimately, to the most fundamental question of all:
What comprises occupant comfort?
Studies of the human condition in enclosed spaces – the very purpose of which is to release the latent potential of human beings that can’t be achieved sitting in muddy field – show that there are about 50 comfort factors that need to be considered, and sometimes more depending on the context. Most of those cannot be met through the greater application of smart technologies, whatever they are. They can only be satisfied by more careful and thorough consideration of the needs and expectations of building occupants. And that, itself, demands that the assumptions under which designers and the controls specialists work need to get deeper attention and scrutiny.
This article originally appeared as ‘Too clever by half? - What comprises occupant comfort?’ published in BSRIA’s Delta T Magazine in January 2016, written by Roderic Bunn.
 Find out more
 Related articles on Designing Buildings Wiki
Featured articles and news
An architectural biography. Book review.
The house where the future king of France lived.
The teacher, architectural technologist and mum offers her insights.
Careful planning needed as supply chain issues continue.
The sensitive conversion of a neglected Cornwall structure.
Plan stresses local involvement in city, town and village development.
Environment Agency publishes BAT guidance.
CLC guidance outlines carbon reduction priorities.
Making the most of a staycation.
Organisation urges G20 to revisit wind energy.
The historian spent much of his life compiling architectural resources.
How technology can expose efficiency levels in existing buildings.