There’s a problem with the technology within our industry. We’ve got all these smart systems and devices that surround us all the time, technology that has transformed our everyday experiences, but most of the systems in our built environment are shackled, restricted, designed to be discrete links in a chain, rather than a network of cooperative platforms. This is a broken philosophy and has resulted in a stagnated market, filled with wonderful devices that just “don’t work.” Consider the following two scenarios:

It’s 7am on a cold winter morning. You’re the first one at the office. You fumble your access card out of your wallet, tap the badge to get into the building, flash your ID to security, and then call an elevator car, which takes a minute or so to arrive. Upon reaching your floor, dimly lit by standard safety lights, you stumble in near-total darkness until you find the light switch. “It’s cold!” you mutter to yourself, as (in the background) you hear the rumble of the heating system starting up for the day.

Seems fairly straightforward. Okay, now consider this:

It’s 7am on a cold winter morning. You’re the first one at the office. You walk through the front door, breeze past security — passing through the automatic facial recognition system — and make your way to the elevator bank. The already-waiting elevator car whisks you to your floor, where your office lights are already on and the floor’s HVAC has tuned the temperature to your preferred preset. There’s no stumbling, no fumbling: the building has automatically taken care of the routine tasks occasionally required. Instead, you can get straight to task (or, first, to the coffeemaker).

All of the key differences between the two scenarios revolve around user interaction and having to interface with a particular building element, like the light switch. In the more automated, frictionless approach, a number of different, interconnected building systems cooperated to make your life and your interactions easier, faster, and more reliable, even going so far as to remove the need for some of those steps in the first place. Think of the different systems in play in that scenario: physical and digital security systems, elevator control, HVAC and lighting integration — all standard building systems — normally operating independently of one another, but when combined, serving to create a fuller and more seamless user experience. How do we get from the present to a future where the second scenario is commonplace, and then go even further? How could something like this even work? Is “intelligent infrastructure” even possible?

A Smarter Ecosystem

At TEECOMlabs, we’re constantly trying to envision the future of the built environment. We see an ever-changing landscape within an industry which remains passively immovable yet has the potential to jump-start trends, improve how we make use of our environment, and innovate and incite sizable breakthroughs in how we interact with our surroundings every day. We envision buildings that incorporate frictionless user-focused integrations by default, not as add-on or “premium” features. In this vision, buildings, campuses, even large-scale multi-campus organizations will have full awareness and control of all their components, capable of autonomous operation through intuitive, self-correcting behaviors.

Software platforms baked into physical infrastructure will enable sites to manage themselves at scale, well beyond the capacity of what humans could do manually. In other words, an intelligent software controller that orchestrates a building’s physical and digital infrastructure will be a standard and necessary component of that architecture. This design of self-sustaining hardware and software hinges on whether all of the building’s systems are connected together. But perhaps more importantly, it necessitates using platforms that are designed with open communication and accessibility in mind, for instance the ability to freely communicate to such an intelligent software system in the first place. We’ve labeled this metric as, “Does it play nice in the playground?”

Does the hardware platform have the functionality to send and receive data about itself? Can it be remotely controlled and managed? In essence, is it able to function as a part of a larger connected whole? Or, does the product, platform, or system close itself off, becoming a “black box” of sorts, lacking the ability to effectively and openly communicate with another system?Unfortunately, a number of currently sold platforms and products fall into the latter “black box” category. This is due to the “walled garden” approach by many manufacturers and suppliers when it comes to their product lines and families: they play nice with other in-brand equipment, but are designed specifically not to work well with others — whether this design choice is purposeful to keep users within the walled garden, or whether the effect occurs indirectly through the decision to simply not spend the resources to build the right tools, the result is the same: nothing works with anything else.We see the conundrum here: why purposely enable your customers to use competitors’ products?

It’s sometimes tough to envision an interconnected future because, as demonstrated by the current state of enterprise systems, intercompatibility isn’t always cost-effective. So why bother with it? Here’s why: because in the walled garden scenario, nobody wins. Users get a poorer experience, manufacturers aren’t forced to update or modernize their product (so they don’t, except to remain competitive), and companies are forced to buy into these walled ecosystems without necessarily considering all the possible and, likely, better options available to them.Manufacturers shouldn’t sacrifice (what should be) imperative functionality at the expense of user experience. To make things even more frustrating, in recent years we’ve seen an overhaul in electronic communication: any number of new standards (REST, AMQP, SOAP, etc.) have made it super easy for multiple devices to communicate with each other. And yet, despite all the protocols and APIs*to choose from, manufacturers have, by and large, either chosen to believe that their own software solution they built is clearly the best (and obviously the only correct) protocol, or alternatively have simply chosen to ignore the technology concepts altogether.

Cooperation is Key

This is the part where I’m issuing a call to action: it’s up to us in the AEC industry to push all our manufacturers and suppliers toward more open platforms.Some of these systems are already becoming more scalable, integrating intelligent technology packages and smarter control mechanisms, and certain manufacturers have already started to utilize open-source software and integrate APIs with public specifications; it’d be a shame to see products with so much potential left behind on the shelves, unsold, simply because they’re built upon restricted, proprietary platforms and/or don’t play well with other systems. And it’s also worth explicitly noting that a manufacturer deciding to build their own API with its own protocols and specs and bake it into their platforms is NOT the same as integrating APIs with public specifications. This paradigm shift won’t happen overnight, but for now, we should start with asking manufacturers the right questions: “Is your platform connected and secure? Does your platform have an open API? Does it ‘play well in the playground?’ (Does it work well with other manufacturers’ devices?)” If the answer isn’t consistently “Yes,” perhaps you might want to shop for some better options.

The Evolution of “The Hub”

In R&D we don’t wait for the future to invent itself. We wanted the seamless, frictionless user experience, the automation, the self-sustaining building ecosystem. And we wanted it today, not in a year or five from now. So we started with an experiment, one that resulted in allowing us to see the benefits of a connected future, firsthand: a platform to connect ALL our hardware, platforms, and systems together and have them work and interface cooperatively, a bridge to connect all sorts of hardware into a singular, intelligent, capable network.

“Alexa, would you kindly...?”

It started with a light switch. In TEECOM’s offices in Oakland, we use the Legrand Wattstopper DLM (digital lighting management) series of interconnected light switches, fixtures, dimmers, knobs, and wires, all tied together through a proprietary, closed, low-voltage network.While the system normally operates the same way you’d expect (flip light switch, light goes on), our goal was to see if we could control the lighting system conversationally from Amazon Alexa. As in, “Alexa, turn on the lights because it’s 7am, I’m cold, and can’t see anything.”We struggled with the lack of a proper interface with our Wattstopper lighting system. The serial control module was never designed to be an API — it’s nothing more than a simple communication interface. So we installed Philips Hue lights, which granted us additional functionality, a more application-focused interface, and capabilities including dynamic color and variable light color temperature. The Philips Hue API and the Legrand Wattstopper Serial control module (the interface) were not ever designed to work cooperatively together, so we built a software application to mesh the systems together and connect them to a custom Alexa skill. We called the software “LabLight.”

LabLight: the first great unifier

LabLight would call out to each of the lighting systems, request a status update, and actively maintain a known database of the status of each of the systems; with the introduction of our “context processor,” a person could use the lab and seamlessly utilize the two different lighting systems simultaneously without having to manage all of the overlap and conflicts (such as possibly getting stuck with no lights, or getting blinded because all of the different lighting systems were on full blast at once). The LabLight software became increasingly complex to maintain as we added features and integrated more of the sensors, devices, and equipment already in our lab. It soon became clear that we needed something more adaptable and scalable for the broader-reaching applications we had in mind. We needed an upgrade. Enter: The Hub platform.

The Hub: a logical successor

The Hub is comprised of a tri-level software platform.

1. The lowest (first) level, the drivers, are specialized for each different API we interface with (Philips Hue, Brivo ACS, Wattstopper, Liftmaster, etc.).

2. The second level, the controllers, link together all of the drivers within a particular domain (AV, Lighting, Security, Networking, etc.). The goal of the second level is to simplify the code required for all the apps above it, while ensuring that all the drivers still work below.

For example, we have an AV controller which incorporates our audio DSP and the various TVs/displays in the lab, and also a separate Security controller, which manages the Brivo ACS, the Garage door, and our security system. “LabLight” was repurposed as a lighting controller and also sits at this level.

3. The top (third) level consists of applications, which currently include our Web interface, a room controller (monitoring and management of our Lab space), graphics displays, automation and reporting tools, among others. Apps like these incorporate functions which may require interfacing with a variety of platforms across multiple domains.From a coding perspective, this tree-like hierarchy is a lot cleaner than building a “flat” software architecture.

A new dimension, a new interface

The Hub’s layered architecture added a new dimension of capabilities to our lab hardware. Through the creation and use of top-level applications — applications which could use the information from one system to intelligently control another — all of our integrated platforms and building systems each became a modular component of a functional whole machine, rather than independently working gears and parts with no central organization.Rather than a rat’s nest of sparsely connected infrastructure, The Hub bridged everything together. We could share data and intelligently manage multiple platforms across domains — and across manufacturers. We could control all of these systems, acquire their data and metrics, and leverage the capabilities of each system to create new effective uses.

An early example which used this style of “cooperative integration” was an app we created that used both the Brivo ACS locks (security) and the Liftmaster garage door opener: to gain entry to the lab, one had to tap their badge on the lock, and the lab door would unlock itself. Now, if you tapped twice, the electric Garage door would open as well (Brivo → The Hub → Liftmaster).Another example utilizes The Hub’s automated lighting software.

As we have multiple lighting systems stacked on top of each other (e.g. Wattstopper and Hue), there are endless combinations of scenes, moods, effects, or settings we can populate within the lab space. The Hub manages all the operational intricacy, making it easy to switch between various effects. Additionally, The Hub now knows in the early morning and late evening hours to auto-adjust the light color temperature based on sunrise and sunset, which is better for our health.

Automation: building layers of intuition

With the growing number of electronic systems installed in a building’s infrastructure, management tasks, periodic upkeep, and systems monitoring are increasingly handed off to automated computer systems, which take a fraction of the time and can handle orders of magnitude more data than people. Having a computer system perform a tedious task offloaded to it is only one type of automation, however.

For instance, when we attempt to teach a system to automate actions which themselves aren’t inherently well-defined, that’s when intelligence comes into play. Intuition and, sometimes, guesswork are integral parts of trying to build a more self-sufficient platform. It’s one thing to have the lights come on when you walk into a room and off sometime after you leave, but it’s entirely something else to have the lights automatically come on before you even enter the room. In other words, you could think of the lights turning on in response to your movement as a sort of reflex. Intuitive behavior would be the room anticipating that you’re going to enter and turning the lights on before you even get there.

Intelligent Interactivity

One of the most direct benefits we first observed from The Hub was the ability to fulfill intent. This was illustrated by a fundamental shift in how we interacted with our space: we started to move away from using explicit actions (or specific action-reaction interfaces, like a light switch) and more towards simply requesting our underlying intent.

For example, whereas before to preset a room for a presentation we would have performed a series of sequential and tedious operational tasks, now we could simply say “I want to start my presentation” and have all those intermediate actions performed for us. This shift, one which could abstract away all the intricate difficulty in interfacing with a space, was a major upgrade from manual operation and using explicit controls. While The Hub doesn’t inherently replace those controls, it augments our systems’ capabilities through automation and intelligent programming.

The Intelligent Future

The appeal for interconnected, cooperative systems is wide-ranging. Whether it’s data gathering, more-capable intelligent interfaces, or automated management, there are any number of potential use cases that can be built upon interlinked systems.

However, as I said before, the underlying necessity is the ability of these systems to work together. In our case with The Hub, we were required to rebuild a lot of the lower-level software and mechanisms that, in our opinion, should have been built into these devices by default. That’s fine for R&D, but it’s hardly scalable — The Hub platform we built can serve as a crossover in the interim, but it’s not an industry-wide long-term solution. It proves that even certain walled-off devices can still operate in a cooperative fashion through an intermediary — albeit with some additional work and some “middleware” serving as a bridge — but relying on this “middleware” software architecture (which is more of a stepping stone) isn’t a good strategy for long-term deployment.

Creating Meaningful Connections

“Smarter” devices, while a broad term, generally implies increased connectivity, increased data capture/awareness, or both. We should be seeing massively more hardware and platforms that integrate these “smart” technologies on the market, but we aren’t. The trend of interconnected services and platforms that has so permeated other technology markets hasn’t yet penetrated AEC to a meaningful degree. In a sector where a “walled garden” market strategy is dominant, phrases like “open connectivity” and “cooperative architecture” are rarely guaranteed.

Devices that are more open, more connected, therefore will, as we gravitate towards more intertwined systems, float to the top of the pecking order, all other functionality considerations aside. Why opt to lock into a specific manufacturer if there’s an equivalent class of devices that work with the rest of your infrastructure? Companies that don’t prioritize open and connected platforms will soon find themselves outmoded, outdated, and soon thereafter, left behind. To be prepared for a more connected future, we have to start with a more cooperative playground.

*API: Application Programming Interface – a set of specifications used within software programs to communicate with other software or hardware components.