Desiring to use actionable data from our buildings is undoubtedly a good thing. To effectively do this, however, defining terms and allocating responsibility for tasks is essential – especially when the “smarts” from our edifices exist in the space between systems, writes Mott MacDonald Digital Technology Lead Pete Swanson, Affil.AIRAH.
The hype surrounding smart buildings has been growing steadily over the past five to 10 years. Today, it is very likely that any new premium development project will describe itself as being “smart”. Smart offices, smart campuses, smart hotels, smart stadiums – you name it, we want it to be smart. Which is all well and good, apart from the fact that the client brief often starts and ends there – “Smart technology shall be provided”; “Data-driven performance shall be provided”; “Automated experiences and services shall be provided”.
The breadth of interpretation possible from these kinds of high–level statements is astonishing – so is it any surprise that clients, designers and contractors are suffering increasing frustration in delivering these smart buildings?
One of the main challenges interpreting and delivering such outcomes is that they are often in no one individual’s scope. Though traditional systems such as lighting, HVAC, security, vertical transport, and audio–visual equipment can be clearly defined, designed and procured, very often the “smarts” exist in the space between these systems. You don’t get a smart building just by delivering those five systems in isolation. They need to interact together in order to achieve functions we might consider to be smart.
Whose scope is it anyway?
Today, two outcomes are likely by default – either the BMS contractor or the network integrator will be deemed to be the main integrator. This is due to the evolution of building systems, with BMS being progressively leveraged into more integrations and more features over time, while the network as the “unifying connection” for systems provides a natural home for the integrated features made possible by it. Either may be satisfactory, but it’s important to properly define the scope at the outset of the project.
The current state of projects is that all too often only a vague, or high–level, systems integration requirement is described. This leaves too much opportunity for arbitrary cost cutting or value management resulting from competitive pricing processes. Competitive pricing plays an important role in efficient delivery, but when the playing field is uneven due to too much room for interpretation, the client bears significant risk as to what they are purchasing – what has really been allowed for. If the scope can be clearly defined, then we can better judge its value and which party is best placed to deliver it.
Clearly defining the scope starts with a first-principles approach to project briefing. The number of possibilities under the “smart building” banner can be quite bewildering even to seasoned professionals, so using a structured framework helps to maintain focus and clarity on what the potential benefit of each technology and solution may be. Using benefit and value tools of the kind developed in the IT industry for enterprise architecture can help to set the scene and secure stakeholder buy-in to the project’s priorities.
Such frameworks typically define the connections or contributions between individual systems, the capabilities they deliver and the overarching outcomes and benefits that can be achieved as a result. Often projects are already using aspects of this approach, but they may not extend to the area of systems integration – the links between those individual systems. This is where it is important to clearly define performance expectations between systems. As an example, let’s say I want to deliver a smart office building with an integrated, touch-less journey through the lobby.
If I were to set a KPI for this solution, what might I call out? Do I want the app to reliably connect via the lobby Wi-Fi? Do I need credential integration from the app to my access control system? What level of connection do I need from the access control system to the vertical transport system – and what functions do I want to share on the app?
What is an acceptable amount of time for our user to have to wait for authentication and then to be able to call a lift? How reliable does this function need to be? Do I need a manual backup (the lift panel) if the app functionality fails?
You can see that even from a relatively basic building function we rapidly identify a variety of technical and functional requirements. These need to be captured not just in a “smart scope”, but also in the individual building systems specifications including the Wi-Fi, the access control system, the vertical transport system, and the mobile app itself.
So, that one scope actually becomes a blend of various building systems requirements. And this is where we realise the need for an organising role to coordinate all these elements. The Master Systems Integrator role is a key component of ensuring that all systems providers deliver on their responsibilities and that the collective whole achieves the integrated outcome. While the designer may well have described the various interface requirements well in their documentation, without that management and coordination role amongst the various contractors, it is unlikely to be delivered well.
What is the scope anyway?
Which brings us to the second issue, “What is the scope anyway?” By the time we’ve engaged a Master Systems Integrator and the various contractors, many design decisions have already been made and the project budgets have been set. This is why it’s essential that the designer takes responsibility for turning that project briefing into a well-resolved scope and set of specifications.
Broadly, in smart buildings today there are three primary outcomes that can be identified:
- Delivering a great experience for the occupants
- Achieving high reliability and effectiveness in operation
- Maintaining efficient, energy-reducing and sustainable performance.
The experience outcome requires a focus on human–centred design techniques, layering the following three aspects to help define and describe what is required:
- User journey – Identifying how the various users move through the building throughout their time in it
- User experience – Detailing the systems a user accesses during their journey through the building
- User interface – Defining the specific functions that users interact with when accessing each system.
One of the most common insights to come from this process is that different users, or groups of users, can have very different expectations and needs relating to each system. As a simple example, a property management executive will want a very different BMS dashboard compared to the building engineer or the service engineer. None of these three users is “wrong” in what they want, they just have different requirements based on their role and expertise. Understanding these requirements enables more efficient design of the specific interfaces required for each system, or group of systems.
And reliably applying user briefings for each type of system enables a clear experience brief to be documented, supporting the technical requirements for each system and group of systems.
The operations outcome is more focused on “building as system”, seeking to achieve efficient delivery of each feature or function. A solid understanding of how the building is expected to be managed is essential to achieving this outcome.
In some cases, a client may be developing a building type with which they are already very familiar – for example adding another commercial office to their existing portfolio. However, in others they may be developing something brand new – such as a stadium or museum – that they have never operated before. Clearly there will be significant differences in client understanding between these two examples. Regardless of how familiar the client is with operating a particular building type, developing an operational model is a key component in assuring reliable, effective performance.
Operational models are well-established structures for describing how an organisation functions and who is responsible for what. By extending the user briefings to consider what the organisation is aiming to achieve, a cohesive view can be formed of what defines a successful operation – what “good” looks like.
Sustainable performance
Sustainable performance can have a variety of interpretations depending on the type of asset. The key question to ask in this area is, “How can technology support these goals?” Or equally, “How can we avoid technology harming performance in this area?” Often the contribution in this area will be the reduction of resource consumption – or the modification of it. Think energy, water and waste as the three most common items to focus on.
The corollary to this point is to ask, “What is the impact of deploying this system compared to the resource reduction it delivers?” To date, little consideration has been given to the embodied carbon impact of technology systems in buildings. But as we move towards a greater focus on retrofit or re-use, this will become an important metric to factor in.
So, now we’ve considered the occupant experience, the operational outcomes and sustainable performance. Typically, these three areas will generate up to 100 or more interface and integration requirements between the various systems common in modern buildings. It’s time to ask the third question – “How can these capabilities be best delivered?”
We’re finally ready to consider which system, or systems, need to hold responsibility for delivering the smart, integrated outcomes. At this point, it can be tempting to say, “We want everything to communicate with everything else!” Yet this approach can lead to highly complex and costly integrations, which may ultimately over-complicate the solution and drive up its cost both at the time of installation and in operation.
Instead, it’s better to evaluate the various integrations to identify where clusters of requirements present – and from there, you can structure specific integration briefs for each element. These briefs can then form the basis of the interface scope required between each contractor’s deliverables, allowing a clearly defined set of requirements that can be competitively priced.
The reality for any smart building project is that there will always be complexity – both in the technologies themselves and in the delivery model. The key is to get right into the detail to make sure the “smarts” are genuinely understood and can be realistically delivered.
Based in Sydney, Pete Swanson, Affil.AIRAH, is the Digital Technology Lead for Mott MacDonald.
