Removing the Umbilical Cord between Controllers and Sensors This is only possible by removing the logic from the logic controllers and putting it into standard software running on edge computing. And that is only possible by removing the umbilical cord between controllers and sensors, the wires that restrict them from taking more and better inputs.

Phillip Kopp CEO Conectric Networks Part 2 of 2 Part 1 0f 2

In the first part of our flexible building mini-series, we explored how wireless digital control is the core to establishing operational flexibility over a building's lifecycle, and why this leads to a more comfortable, efficient and functional building environment. Today we look at the formula for a truly open, low cost and future proof building.

The next order of building flexibility is to remove the specialized programming tools and compilers that exist in today’s digital PLC’s which lock your building into a state of inflexibility. Instead, we look at a roadmap for buildings with control sequences programmed in standard software languages like JavaScript or .Net using open tools and completely separating hardware from software.

Why are controls sequences compiled with proprietary tools into logic controllers in the first place? Technically speaking, direct digital controllers (DDC) and PLC’s do not have very powerful onboard computers. They run on the firmware that has to be programmed to each controller individually. A static program that can’t be changed once is “flashed” into the hardware. If you want to change the control sequence or add a new sensor, you have to reprogram the firmware in a specialty software with line drawings to reflect the changes in each controller. That software will only compile and run on the chip that is specific to that controller and thus, the only way to program it is using the specialized tool for that vendor. While this may be fine for operational day one, it has many adverse effects after that.  Including limiting the number of people that can work on that building in the future, to those that have the right programming software, those trained to use that software, and a high cost to change sequences or add sensors—making the building very inflexible. There are solutions to this, such as the use of the Sedona framework; however, these are mostly band-aids, layered on top of existing proprietary controls and don’t get to the root of the problem. These are special programs limited to building automation, meaning there is a small labor pool to work on these controllers and limited transferable skills between building automation and other industries.

Let's look at a real-world example. Something as simple as adding occupancy sensors to existing office building HVAC systems will have a dramatic impact on energy efficiency. Yet, it cannot be done to existing HVAC systems because that would require wiring sensors to controllers and reprogramming controllers individually. Running wire will be very expensive. Few contractors (i.e. those affiliated with the controller vendor) have access to the software or know how to use it. This limited resource (in many cases territorial, meaning there is only one per city) creates a monopolistic business environment. Again, driving costs to the point where ROI is unachievable. Yet, this is the precise reason why the current design remains; the system is to protect monopolistic and territorial business practices, which is bad for buildings, owners, operators, occupants and even our environment. The advent of open protocols and projects like BACnet or Haystack will not change this scenario as long as controllers must be programmed with compiled software on proprietary programming toolchains, using specialized vendor software that only they control and train people how to use. Under the current system, the cost of the upgrade will easily outweigh ROI, and we see the result, most buildings are 50% inefficient or even more.

Take the control sequences out of the controllers and into more powerful edge servers that run software that can be worked on and developed in standard languages opening the door for a vast resource pool to work on building automation, the entire global software developer community! Imagine what having access to the global software developer brain trust and market competition would do not only for the quality of the control algorithms but to the cost of developing and implementing them?

A good comparison might be the early days of the internet when you had to pay a website developer $10,000's or $100,000's to create each custom website individually. A costly and time-consuming exercise with a limited number of specialized resources, much like the BAS controller programming of today. Fast forward about 15 years, and platforms like Wordpress standardize beautiful and functional template-based websites on the order of $100's of dollars, maybe 10% of the initial cost, or Wix that allows you to build your site for free.

Why hasn't this happened in building automation yet? There are a plethora of low cost, reliable, "dumb" i/o controllers on the market that follow instructions provided by a server. SCADA systems typically are designed in industrial factories. So why not in buildings? It is not due to a lack of available hardware.

The answer is not just poor business practices, but partly also a technical one. Wireless technology finally permits removing the umbilical cord between controllers and sensors, the wires that restrict them from taking more and better inputs. The reason why logic must exist in the controller today (making it exceedingly difficult to change and adapt in the future) is because the inputs are attached to them. If you remove the inputs from the controller and you run everything through software, there become zero reasons for programming logic into controllers, and the building is free from inflexibility! Wireless sensor inputs placed where needed and updated as building use and tenant improvements change over time. Those inputs feed into the smart software that operates advanced control sequences, intelligent algorithms and even artificial intelligence applications that can be worked on by standard software developers over the life of the building. Wireless technology makes it possible to use common and open languages like Node JavaScript developer kits. Provided license free by companies like real-time mesh wireless technology provider Conectric Networks, and combined with open source frameworks like Node-RED enables a completely free and open building control platform taking buildings into the modern software age of Wordpress and Wix (disclaimer, I am the co-founder and CEO of Conectric Networks).

With wireless networks, "dumb" slave controllers, programming control sequences in a completely 100% digital environment using standardized software languages with tools that any software engineer on the planet has access to and knows how to use, we can completely revolutionize how our buildings work. They will be fully programmable, flexible, efficient, adaptive and then plugged into infinite ecosystems of new software, tools, energy systems, human interfaces, smart algorithms and even artificial intelligence (AI) programs. We can connect brains to buildings. More importantly, they will be easy to service and maintain over time, having not only a far lower cost to build, but also to operate. The ROI is virtually infinite when comparing to the existing wired approach today.

The final question remains. If it were so easy, why isn't everyone just doing it? Putting all else aside, there are always tradeoffs. This is as true with technology as it is with engineering, business practices and even social balance. There have been dramatic improvements in wireless technology; the truth is that high throughput and high bandwidth communications like what we have described, such as WiFi or Cellular require a lot of power to keep a constant connection, or only transmit short distances and therefore also require wires… sort of defeating the whole purpose of the conversation.

Wireless technologies that don't require wires and can run on batteries or energy harvesting communicate infrequently and unreliably, making them perform poorly for the kind of expectations we have for latency and operation in building systems. Compared to this, wired systems just work better. Fortunately, there are companies like our company Conectric Networks, working on what I call "hybrid mesh systems." Hybrid mesh systems leverage both constant powered and battery-powered nodes to provide the performance of wired networks, with the flexibility of wireless ones and enable the Jetsons building of the future. Thanks to editorial platforms like automatedbuildings.com giving myself and others from companies like Lynxspring, EnOcean, LoRa Alliance, Aruba Networks the opportunity to write articles like this, we can share our work and the great promise it brings to solving the inflexible building challenge.

About the Author

Phillip Kopp is a technology co-founder who fell into the world of building automation and energy efficiency over 20 years ago starting the first totally wireless RF sensor company for hotel guestroom automation, sold to the Somfy Group in 2009. He has since built or sold three other companies in financial technology and SaaS and has contributed to over 15 US Patents. Phillip is currently the CEO of Conectric Networks, whose goal is to install billions of wireless sensors into buildings, AI enabling to develop a massive virtual grid. Reducing 20% of global energy consumption and paving the way to a safer, more productive and healthier future.

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]