August 2019 |
[an error occurred while processing this directive] |
Smart
Buildings Can they be described by three characteristics and six types of components? |
Rune Winther Head of Digital Products Development, Buildings & Properties Multiconsult Originally published LinkedIn |
Articles |
Interviews |
Releases |
New Products |
Reviews |
[an error occurred while processing this directive] |
Editorial |
Events |
Sponsors |
Site Search |
Newsletters |
[an error occurred while processing this directive] |
Archives |
Past Issues |
Home |
Editors |
eDucation |
[an error occurred while processing this directive] |
Training |
Links |
Software |
Subscribe |
[an error occurred while processing this directive] |
While there are a plethora
of descriptions of what constitutes a smart building, it is my
impression that many of the descriptions too often are hooked on
specific technical topics (e.g. “IoT” and “energy”). A problem with
this is that we might not see the forest for the trees.
In
this article, I will describe some personal thoughts related to smart
buildings. I certainly make no claim to have all the answers, but I
believe in discussion as a means of learning. By writing my thoughts in
this article (as naïve as they might be), I hope to get some response,
new ideas and an improved understanding. It will be a real surprise if
everyone agrees with my views…
Much
of the current activity related to smart buildings seems to be driven
by equipment vendors, and with a focus on a few chosen building
qualities (e.g. energy efficiency). I’m probably not alone in thinking
that the “shiny object syndrome” troubles smart buildings.
My goal is to describe how smart buildings look from a general engineering perspective. Specifically, I will present a rather simple definition, highlighting what I consider are the three essential characteristics of a smart building, and then define a set of six generic components that I think are all required to make a building smart.
What is a smart building?
Searching
the internet for answers to the question “What is a smart building?”,
you get a variety of answers. What answer you get depends (naturally)
on context and perspective. If energy efficiency is your main interest,
it is likely that the definition you use for a smart building has some
reference to energy management. Similarly, if you’re selling
technology, your definition is likely to refer to technology. According
to Wikipedia, a smart building is simply a building
controlled by a BAS (Building Automation System).
The
company I’m working for, Multiconsult, is a vendor-independent
engineering company, working with a broad set of building projects from
concept to detailed design. A key point for us is to help our clients
realize the best possible building according to their specific needs,
within their budget and other constraints. Whether the client is
focused on energy, sustainability, or any other quality, makes little
difference for how we go about doing our job. This, of course, affects our understanding of what a smart
building is.
What
I often miss in definitions of smart buildings is possibly the most
important part of “smart” – That the building is capable of running
itself.
My
take on “smart building” is as follows:
A
smart building is a building that, with minimal human control,
optimizes defined qualities.
There
are three key characteristics here: “Minimal human control,”
“optimizes,” and “qualities.” Let’s have a quick look at each of them.
Minimal human control
The
essence here is autonomy, and there are two reasons for this:
Optimization
This is why smart buildings are interesting in the first place: They are expected to do things better than traditional buildings! In practice, optimization involves the use of advanced digital systems.
Qualities
Two
examples of building-related qualities that receive a lot of attention
are the effectiveness of energy management and space utilization. There
are, however, many other qualities that can be optimized, such as
working efficiency, employee well-being, environmental impact, waste
management, etc.
Contrary to some of the other definitions of "smart building," the definition above has no reference to technology and does not single out specific qualities. An important reason for using this definition is that it encourages us to focus on real needs and benefits, i.e. what we want to achieve with the building. Definitions that include references to a specific technology (e.g. IoT, wireless networks, etc.), or specific qualities (e.g. energy) have a tendency to draw our attention to the technological implementation (shiny objects…) too early in the process.
To help us focus right, we’re using the following simple “equation” as a reminder:
Needs + Possibilities = Solution
This tells us that the best solutions are achieved when we meet actual needs with the best available technologies. To do this, we need three different sets of skills:
Considering the speed at which new technology is developed, the second bullet point is particularly challenging for a vendor independent consultant. I also believe the first and third bullet points represent such a challenge that I will address them in a separate article.
What we see in many projects is that there is too much focus on the technological possibilities and too little on the actual needs and benefits. The fact that something is possible doesn’t mean that it adds value (at least not in all situations).
The
recently published State of the Smart Buildings Market study
recognizes that “…the market is
chaotic, and customers can struggle to make sense of opportunities
through the noise.” However, it also points out that “…there has been a significant shift in
supply-side focus from technology to business cases.” This shows
that the smart building market is maturing and that we are moving in
the right direction.
What does it take for a building to become smart?
Keeping
things generic and avoiding technicalities, I have (so far) identified
six generic components needed to make a building smart, i.e. to make a
building capable of optimizing
relevant qualities with limited need for human control.
One of the benefits I experience from defining these generic components
is that they help me avoid going into specific technologies too early.
When discussing smart buildings with others, it is also my impression
that these generic components supplement the definition and
understanding of what a smart building is. The generic components are,
Sensors, Actuators, Connectivity, Autonomous control algorithms, Data
analysis and User interfaces.
While you will find many of these in regular buildings today, a smart building according to our definition requires all six. Note also that that having all six does not necessarily mean that the building is smart. Let’s have a closer look at each of the component types:
Sensors
If you can’t measure and observe, you can’t optimize – It’s as easy as that. The development of small, wireless and cheap sensors is a key driver for smart buildings. We have had sensors in buildings for decades, but the development and availability of sensors we see now is a real game-changer.
Actuators
If you can’t change or control the state of the building’s systems through some type of remote control, optimization is going to be difficult and well, less optimal… As for sensors, we’ve had actuators in buildings for decades, but it is in combination with the other “smart” components that their potential can be fully exploited.
Connectivity
This
is a big one, comprising anything used to collect, manage or distribute
data, as well as all other types of communication between entities in
the building. Connectivity is essentially the backbone and nervous
system of a smart building. Communication networks are clearly part of
this, but also various “platforms” that ensure that all the other
components can function as intended. It might be that Connectivity
should be divided into more specialized component types.
Autonomous control algorithms
Minimal human control requires autonomy, usually at a high level. While systems don’t have to be complex to be autonomous (e.g. thermostats), autonomy in smart buildings will require algorithms able to handle a much higher number of inputs and outputs than regular building automation does. The typical Building Management Systems (BMS)/Building Automation Systems (BAS), while autonomous to some degree, usually don’t support optimization or control across subsystems to the extent we require in a smart building.
Data analysis
With loads of sensors comes loads of data. In order to get any value (i.e. optimization) out of this, we need to do data analysis. It is important to note, however, that data analysis will support optimization on several levels:
The
various levels of control might require different types of analyses.
For example, on the tactical level, it will be possible to do deeper
and more comprehensive analyses of how energy consumption might be
reduced than what is possible in real-time.
User interfaces
While our definition emphasizes minimal human control, this does not imply minimal human interaction. On the contrary, truly smart buildings will interact heavily with their users. In fact, its users will probably not experience a building as smart, if it is not capable of adjusting its operation according to user feedback. Input from user interfaces will be just as important as data from sensors.
A very important question that isn’t addressed above is that of cybersecurity. The reason is that I don’t view cybersecurity as a functional component, but something that must be an integral quality of the components. Having decades of experience from risk management in various industries, including cybersecurity, it is clear to me that ensuring security, reliability, safety, etc. of smart buildings is going to be crucial.
When
you do a break down of a smart building into generic components like
the above, it becomes apparent that engineering smart buildings will
require both a wide range of competences and an engineering process
capable of handling the combined complexity. In order to manage both
complexity and risk/cybersecurity, I believe improvements to the
engineering process is a key challenge. This is why the engineering
process is my main focus area, both as a consultant in Multiconsult and
as a researcher at Østfold University College.
Vendors and “bundling” of
components
[an error occurred while processing this directive]The supplier market for smart buildings has grown rapidly, and it will probably take several years to mature and find its “form” (if it ever will). Based on observations and interactions with various vendors, there are a couple of things worth commenting on:
Vendors tend to think (or at least imply) that their product is the essential one, when in fact you will need (at least) six different types of components to realize a truly smart building.
“Bundling” of components, i.e. that a vendor requires you to buy several components together as a package.
As to the first bullet point, this is the typical “hyping” of products. In essence, there is a misunderstanding of necessity versus adequacy. You obviously need a big number of sensors in a smart building, but sensors alone are getting you nowhere if you don’t have matching connectivity, autonomy, analysis capability and the ability to physically control your system through actuators. This problem also makes clients more vulnerable to shiny object syndrome. In Multiconsult, we see it as one of our core tasks to help clients cut through the hype, evaluate products according to what they actually contribute, and identify what is needed to achieve the client’s goals.
There are situations where a vendor might struggle to sell their product because a corresponding component with the right capabilities is missing. A few examples:
While it is understandable that this happens, it is my view that this type of bundling of components will not be sustainable. The point is that if the use of a specific sensor suite is dependent on using a specific platform and analysis tool, you will be very vulnerable to competitors that offer similar sensors, but that doesn’t do the same bundling. What seems to happen sometimes is that lack of support for your core product forces you to make it yourself, and then you risk losing track of what you were good at in the first place.
There is nothing wrong in offering complete solutions, and for many clients, this will be considered a simpler solution. The situation in the smart building market, however, is very much that of hyper-competition, and I believe that the more you bundle components, the faster you will lose your temporary advantage. Thus, it seems to me that even when offering complete solutions, the best way forward would be to ensure that each component can be used independently and in combination with components from other vendors. Thinking of smart building systems as an advanced version of Lego makes sense from the perspective of a vendor-independent engineering consultant.
While
it is obvious that the way forward is that of open standards, I don’t
think that this by itself is adequate if there is no standardization of
what we consider to be the basic types of components.
The desire for shiny objects –
Is it all bad?
Not
entirely, if you know what you are doing. As Nicolas
Waern points out in this interview with Ken Sinclair, “gimmicky
might be gold, in the way that it will lead to quicker wins and buy-in
from the organization.” I think the point here is that we are
talking about two rather different value propositions.
The
definition of a smart building I’ve presented above is the “full
package,” i.e. a building capable of optimizing several qualities and
operate autonomously. The “gimmicky” approach consists of using a
selection of smart components to pick some of the low-hanging fruits.
While you are not building a smart building, you are making smart use of new
technologies. A typical example is the use of sensors to gather data
over time and then use this to support tactical and strategic
decisions.
While
the first value proposition is mostly relevant for new buildings and
complete makeovers, the latter is most relevant for improvements to
existing buildings.
Where things easily go wrong is either when you think you’re getting
the first value proposition, while actually getting the second, and
when you think you are getting the latter when you are really just part
of an experiment. These situations are most likely to occur when
vendors oversell their product, and the client is overenthusiastic
about the fancy shiny objects.
The
fact that I think the two value propositions require different design
and implementation processes, and different skill sets, is a topic for
another article...
About the Author
Thirty years of experience working on statistics, risk and reliability issues for various industries and research institutions, with a special interest in digital systems. Extensive experience as a consultant, lecturer and researcher, having worked with many dependability aspects - specifically safety, reliability and security. I find smart buildings, smart cities, the increased use of artificial intelligence in general, new digital solutions in health care, etc., particularly interesting and challenging. My main focus area, both as a consultant and researcher, is on improving the engineering process to match the significant increase in complexity and criticality new digital systems represent for buildings and properties. As part of my job I'm also leading Multiconsult's task force for disruptive technologies in buildings and properties.
[an error occurred while processing this directive]
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]