Architecture in the Mist

Recently, a friend asked me to explain fog computing. Is it different than cloud computing?

The term Cloud in an architectural diagram, as originally used, meant “it doesn’t matter where the computing is”, i.e., the term Cloud meant vague and undefined. As happens so often, a few big data center operators (you know their names) re-defined it to mean “in our far-away high-up location”. This definition supports their marketing but restricts the original purpose of the term.

Fog is taking back the cloud, by pointing out that clouds can be low to the ground and widely dispersed. Edge-based analytics in the IoT, for example, are near the Things rather than far away.

Fog is still as vague, still a cloud. Is intelligent processing it in each sensor? In each collection of similar sensors? In a single integrated system?

The answer is, it depends.

More and more IOT applications are choosing when to transmit data to the cloud, usually near an event or trend. In 2015, IOT systems collected nearly 8 Zettabytes of data. (A Zettabyte is a billion Terabytes). Most of this data is never reviewed or analyzed. Local storage and local event processing can reduce the ever-growing data collection—as well as the network bandwidth it requires.

Local event processing and local storage can reduce the data that needs to be stored in the [high] Cloud, as well as transmitting the data that is transmitted in more efficient batch transfers. Even some simple systems are now transmitting only the antecedent and proximate data to the event up to the cloud.

In a trivial and easy to understand example, consider the web-enabled doorbell, recording video continuously. It maybe has the capacity to keep a few hours of video locally. When the doorbell rings, it can send the 30 sends before and 30 seconds after to the cloud (transmitting the Antecedent and Proximate data). Before this edge processing, users would see the hat of a delivery person walking away. With this intelligent edge processing, the user sees that face of the person coming onto the porch and ringing the bell.

Now extend this thought to whatever data collection you do. Perform simple analysis locally, and quickly. I say quickly because one principle for good IoT is to “analyze quickly, while it still matters”. This approach can preserve privacy while lessening the need for [mostly] unused zettabytes being transferred to the remote data center.

So, the Fog is the Cloud, just one near the action, on the edge. . .and in the Internet of Things, the Edge is where it’s at.

Big Data, Buildings, and the Internet of Things

Big Data is the hot new buzz-phrase for something that buildings system integrators have long struggled with. Last Thursday (3/29), the White House Office of Science and Technology Policy (OSTP) launched its public initiative on big data for government, the Big Data Research and Development Initiative.

The purpose of big data is to support analytics, that is the massive crunching and correlating of data to find patterns. Early targets of the initiative include:

• putting the government’s own data sets into open formats
• pushing states to include a data or statistical literacy component in their education plans
• establishing ways to continuously collect data on prescribed topics as opposed to relying on temporary snapshots

The real time use of big data that is most commonly in the news click-stream and advertising analytics. This back-room technology only makes the news when there are privacy violations. Big data analytics are why Google is now in a death-match with Facebook, and why the European Union is in a privacy face-down with Google.

In government, the best known big data analytics are in security and crime prevention. Einstein systems gate all information in or out of each cabinet-level department, searching for patterns that indicate intrusion. The NSA and FBI are doing something with big data; the NSA may or may not be consolidating information on all internet communications at its Utah Data Center.

Buildings have long struggled with big data. They are not designed for storing or to processing too much. System instructions regularly warn to minimize trend reports. Product from a number of leading makers of environmental controls struggle with monitoring just a small portion of the buildings on the UNC campus. Building systems houses all aim at cloud-based analytics in their next release, but each that I have seen struggles with pushing information to the cloud. I have watched very fast networks struggling to handle data collection from a 100 buildings, and watched data edifices crack under the hundreds of gigabytes they produce each week.

We are just now entering the period in which the internet of things (IOT) becomes real, and the IOT stores its data in the cloud. Last month, Ninja Blocks (http://ninjablocks.com/) got its initial funding. Ninja blocks are consumer sensors that are as cheap as X10, and send their data to the cloud. Ninja blocks use open source hardware (download schematics from the site) to sense their environment: acceleration, temperature, current, humidity, motion, distance, sound, light and even capture video. You can create and sell your own Ninja Blocks to connect to the Ninja Cloud.

The Ninja Cloud connects this sensor information to social and cloud services. Sensor events can send tweets, SMS, or email. Ninja photos and video can move automatically into Facebook or Dropbox. The user plugs in a Ninja Block and then uses the web to develop scripts in the Ninja Cloud using point and click.

This may not be the same as energy management, but one of the more successful campus energy projects of recent years set up Facebook pages for buildings on the University of Mississippi campus. Students were encouraged to friend the buildings; systems in the buildings tweeted their energy use. The project raised Student awareness.

Ninja Blocks is a new company. They can probably do most of what they claim. Their team of entrepreneurial young engineers seems smart, quick, and committed. Their business plan is inspired using open source hardware to let others create new value sources for the Ninja Cloud. Still, I wonder whether their approach will scale well. They may hit the same wall that I have seen, when too many sensors are continuously logging too many points to the cloud.

Whether or not Ninja Blocks makes it, they are the future. Other start-ups, such as the Bluetooth-based, open source i-voltmeter will change the way we think sensors work. The data gathered by the internet of things will make its way to the cloud, where it will be Big Data. Building systems that do not participate will find themselves pushed aside.

The value of Big Data is in re-purposing and in re-use. The cost of gathering big data is going down, and will continue to go down. The Big Data from buildings will accumulate at an astounding rate. The value of Big Data will be in continuous re-harvesting for more information, the way click-streams and advertising are harvested again and again. Building operations and failure predictions are only the start.

Big Data from Building systems must learn to share well with others. This industry must consider its own version of the federal goals: open formats for data, better statistical literacy in systems, and the methods to collect and store very large volumes of data loom large. We may need to use the common semantics from Project Haystack as a common ontology for our big data. It will be mandatory to share with the Big Data from the IOT, both to accept IOT data into Building Clouds, and to send Building data into the IOT clouds, including the Ninja Cloud.

It will be a fast ride. Into the Clouds!

Smart Operations are a necessary part of Smart Energy. Maybe GBXML is, too.

It is easy to think we are playing the end game, but we are really working on the early stages of smart energy.

Smart grids may end at the edges of the grid, they may know no bounds, i.e., ZigBee and SEP, or they may end at the meter. Beyond the meter may be a collection of dumb systems, a minimal collection of defined systems with defined responses, or a micro-grid with its own economy, and own dynamics. I think that every node a microgrid is the future.

I was pulled back to thinking about buildings as I prepared to speak at the AHR show in Orlando next week, and by an announcement about an upcoming seminar on GBXML (GB = Green Building). GBXML is a format designed for the exchange of engineering information, particularly that related to energy use and energy efficiency, during the design process. GBXML may be the key to understanding microgrids in buildings.

The challenge when we treat the end nodes as micro-grids is categorizing and measuring the services they provide. These may be relatively clear in the data center, but even there, understanding HVAC support services is relatively obscure to the IT operator. Going a step further and treating the data center as the district energy center for thermal distribution is hard to understand, harder to account for, and therefore difficult for most enterprises to work with. What are the services in the end nodes?

So, after a building has been partially renovated a few times, and has three EMS (energy management systems), each managing a dozen zones, what effect is there on which part of the business when load is shed in a particular way? Which departments, or tenants, are even affected? Do tenants have QOS agreements, and if so, how are they affected.

Full-fledged BIM (Building Information Model), as defined in NBIMS and BuildingSmart, is too fat, too heavy to use in everyday operations. GBXML is a light-weight one-off of the IFCs in BuildingSmart. It was developed to model energy use, and to exchange energy models within buildings. GBXML includes formal definitions of geometries and spaces, and common models for the components of the energy using systems in buildings. It might just be the map between the design, the operations, and the services. GBXML might just be BIM-Light.

Somewhere between the intriguing, but not yet all that useful Microsoft Hohm and Google Energy, there needs to be a path for buildings as service providers. Understanding services in buildings requires understanding tenants, and their purposes. Perhaps Building Service Profiles link to the spaces in the light-weight BIM (GBXML) and therefore to the tenant services.

Energy profiles linked to the Building Service Profiles, then, become the links between Demand Response and graphical, tenant aware interfaces for building operations.

Last week, I received an announcement of a GBXML seminar in building design (http://www.gbxml.org/events.php). So far, efforts such as LEEDS have not yet delivered on the vision of sustainable energy-efficient high-performance buildings. The unhappy truth today is that most "green" buildings are poor energy performers within a couple years of delivery. Commissioning is a one-time act with no visible links to ongoing operations. Maybe using GBXML to both define the services of buildings and to operate/visualize their operations will not only enable stronger DR, but will lead to better every-day operations.

I am convinced that long term models for distributed energy, and for rapid innovations in energy use, come in this area. All the early incentives of DR, and the early visualizations of Google Energy and Hohm, are merely the tip of wedge for DER and smart energy in the end nodes. We need an interface between design, construction, operations, and smart energy. GBXML may be the most important enabler of net zero, near grid, and off-grid facilities. It may be what we need to apply the facilities capability management approaches pioneered by the Coast Guard to the policy-based net zero security and survivability of the NZ Army base.

I recommend that you check out the seminar on GBXML if you are interested in the real potential of smart energy.

body>

Data centers are just the start of unsustainable IT

Lots of people consider data centers, those great energy sucking heat producing resource hogs. Data centers have become the PR battlegrounds for corporate sustainability. Heads of large corporations have been known to charter jets to inspect operations of data centers and declare their interest in reducing carbon footprints. This is somewhat overwrought; that flight may have a larger carbon footprint that savings for a year. Such posturing is well known; today, I am writing of IT’s unsustainable interactions with basic building operations.

I am not concerned today with the workstations left on all night to support overnight patches. That too is well known. Besides, any competent IT manager who manages his PCs by policy has had a palliative long ago. Group policy extensions for energy management have been available for years. The Windows 2008 server policy extensions make is straightforward to manage workstation energy use.

The rogue data center is one of the more common barriers to more sustainable building operations. The rogue data center includes the server in the law office supply closet. On the college campus, it includes the small Beowulf cluster under the post-doc’s desk. That post doc may bike to work, with a save-the planet logo on his back pack, but his rogue data center burns energy night and day and requires the building to do so as well.

Rogue data centers prevent any reasonable program of building set-backs. Set-backs are simply doing in commercial space what a programmable thermostat does at home. Setbacks program the building to use less energy when unoccupied, but they run afoul of heat from the rogue data center. At UNC, rogue data centers are revealed after spring break, when even the least controlled buildings are manually set back. They overheat and their owners are on a rampage…

But even in an environment with better control over policy and server security, the communications closets present a significant challenge to sustainable operation of buildings.

At UNC, most of the buildings have pneumatic controls. This means they are very reliable at keeping the building at a fixed temperature all of the time. We are trying several approaches that have recently come to market to let us do setbacks, i.e., raise the night-time temperature in the summer. We can put digital radio-controlled thermostats on the walls and turn them down based on a program. We have had some problems, such as the heater coming on to heat the building up to the new temperature. It seems that these systems need some more work

We also ran into another problem. The communications closets in these older buildings get their air conditioning from the rest of the building. The communications closets are filled network gear that generates a lot of heat. When the buildings are set back, the equipment in the communications closets overheats.

For now, we are building Rube Goldberg-style work-arounds. We are putting SNMP temperature sensors in the closets. When things get to hot, they send alarms to the data center. The data center can then send a standard message to the building’s wireless retrofits to cool the building for an hour.

The needs of IT remain a regular hurdle on the road to sustainability.