Your Complete Source for Building Automation Sensors
Looking Ahead, Looking Behind
This is the first of a series of articles looking back on the roots of the IoT, as expressed in Automated Buildings, and looking for the theme we need to consider for success going forward. This month we look back on security vs autonomy (service) and how they illuminate data leakage and potential privacy liability.
I told him that many facilities managers are among the most technically savvy in a building. They are challenged by the conflicting requirements: energy savings vs. comfort vs. status vs. tenant retention vs. security (physical, network, IT) vs. branding.
It is frequent that today’s more efficient building systems fight. Anyone who has an instant hot water heater and a modern dishwasher can listen to them fight as the low-water dishwasher (one more deciliter of hot water because this load seems dirtier) starts and stops the instant hot water heater.
forms of integration make many IoT cloud integrations difficult and
expensive to maintain. Where efficiency means working on small
operating margins (for energy, or water, or…), the importance of fully
understanding how new technology interacts with the rest of the
building gets greater. Smaller operating margins on the grid make
creating a smooth, well-managed load profile more important. If you
plant to add a microgrid, then a well-managed load profile reduces the
capital-intensive generation and storage needed.
Cloud-based IoT creates new and poorly understood privacy issues. I know, we have all seen that people seem willing to give everything they know and do away to Facebook—but even so, the fast-growing installation internet ad-blocking technology is disrupting today’s revenue models. Today’s privacy law seems to create policies whose effect is to make much of our lives more frustrating. In the US, policies on medical privacy seem to allow everybody except the patient [and family] to see the data; the effect of privacy liability management is primarily to excuse bad customer service.
I mention medical privacy because it is only a matter of time until facilities managers get legal responsibility for managing privacy in the IoT. What tenant information can I share? What metadata about their comings and goings, and about the equipment that they use and when must be obscured from third parties. (More and more purveyors of digital power management are able to recognize every piece of equipment in a building by its electrical signature.) Will the cloud-based IoT provider warrant there will be no privacy leakage?
Many IoT ventures pitches today lean more on the potential value of the data-mining than they do on value to the tenant/customer. I characterize this as “fun for the boys, but hard on the frogs.” I don’t believe this path will lead to long-term success. It is my guess that an entire generation of cloud-based IoT that delivers less value to the customer than to the data-miner will fail, and fail spectacularly.
Local autonomous IoT in buildings is something different.
(Cognitive functions, Autonomy, and Integration)
Improved service and improved performance can be more easily achieved at a lower cost within smaller realms of the complete HVAC system for a floor. Better customer service and tenant retention can be achieved by more modular and tenant-responsive security systems.
(Bouncer or Prison Guard)
Autonomous IoT can become a way to enhance tenant service while reducing resource requirements, by self-learning to anticipate and offer the right service at the right time, but no other times.
This model of the IoT as the local autonomous coordinator preserves privacy, can increase efficiency, and enhances tenant service far better than will the cloud. It does not intrinsically offer and means of coordination. Coordination of services and resources will continue to be more important as resource operating margins become slimmer, and variability of resources becomes greater as they become based on distributed energy resources (DER).
(The Building Services Interface: The foundation of smart building security and interactions)
The answer is light, loose models of inter-system communication that balance resource usage over time, based upon the *local* varying supply. Loose integration reduces the complexity of specific integrations—we should aim for autonomous IoT applications that do whatever they do, and self-integrate into the larger building ecosystem with minimal human involvement. Today’s models of “green buildings fail because they do not scale—one can do twice as many buildings only if one has twice as many engineers on the payroll. Autonomous IoT agents are our best hope to get past this.
(Just-In-Time Power and Water at the Edge)
(Eight Agents for Energy)
Transactive integration is the loosest effective form of integration we know. Systems do not need to know how other systems operate (mechanisms), they only need to know how they compete (or supply) common resources. Set the limits on the resources available, either by hard supplies, or by budgets, and let the autonomous systems work things out. The spontaneous market order can replace non-scalable engineering piece-work.
The opportunities are immense. But they will not be built on merely hooking up every sensor in the world to a cloud and somehow creating value by using Hadoop.
“I wrote this column in mid-December. More recently, my son forwarded me this news on cloud-Iot and the law.
Police seek Amazon Echo data in murder case https://www.engadget.com/2016/12/27/amazon-echo-audio-data-murder-case/, a case that is sensational, but the third paragraph will be more important to IoT practiitioners…”
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]