New Energy and Legacy Buildings

Building systems used to be fully compatible and interoperable. Prior to digital controls, the best systems were built with pneumatic controllers. Electric signals are complicated. There’s voltage. There’s there is binary packing of data. There’s non-standardized xml vocabularies. Pneumatics were simple. Pressure was everything.

Many institutional owners of buildings resisted the new-fangled digital controls for a long time. When own a large number of buildings, interoperability is more important. Before real standards for networking and remote communications, the most important interoperability was with the maintenance technician. As Roger, the long time head of HVAC for UNC explained to me “No matter what the problem, we can clear it from here with a tank of pressurized air”. This means that at UNC, and on many campuses, most of buildings still have pneumatic systems.

Pneumatic systems work best for continuous operation. They usually cannot perform automatic setbacks. Setbacks refer to adjusting the building temperatures up or down (depending on season) outside of business hours. Just as in the home without a digital thermostat, it is a rare building operator who will consistently and reliably perform manual setbacks.

At UNC, we have been looking at some innovative approaches to retrofitting pneumatic systems for automated central operation.

Cypress Semiconductor is one of the old-line silicon valley firms. Cypress has come up with a digital retrofit for pneumatic thermostats. The digital thermostats are then linked by a wireless network back to a central controller, enabling the thermostats to be re-set remotely. Cypress further claims that the thermostats collect data on system health through analyzing fluctuations in air pressure. The central controller is a standard PC, so an operator can use the web to re-set the thermostats.

The external interface to that PC is a traditional building system protocol. Cypress would have better served itself if they had reached further. Buildings that have pneumatic systems do not usually have effective or extensive building operations systems in place. At the next level, owners are trying to crack the façade of proprietary building systems and to achieve enterprise interaction. Interposing traditional building control protocols just gets in the way.

Enterprise interactivity will let these systems respond to the business of the occupants. Conference rooms could be heated and cooled based upon schedules in the corporate calendar. Larger building operations could respond changes in business schedules and to changes in staffing. In this year’s tight economy, building operations could respond to Friday furloughs in response to signals from human resources. Enterprises expect abstract web services such as oBIX, not low level protocols, even if repackaged in TCP/IP or even XML.

We need a BIM Lite

Every week I encounter another project which would be simpler if we had a light-weight three dimensional BIM standard. BIM (Building Information Model) is a family of data standard models that fit together to describe every aspect of the design and construction of buildings. The sexiest member of this family is the Building Model, the 3D representation of the space itself. Today, BIM does little for the operation of a building or for providing tenant services. For this we are going to need a BIM Light.

Today the internet of things is becoming salient; the intelligent objects and intelligent systems that run so much of our world are getting interfaces. The agents that run them our learning to respond to our financial systems and with our lives. In return, these systems are starting to share information with us. This interaction is at the heart of new energy, of e-tech. This information is central to new models for emergency response. These changes will be critical to offering each of us improved amenities even as the agents work aggressively and autonomously to reduce our energy footprints.

Direct control of these systems means we will limit their responsiveness to the minimum. Direct access to these systems will ensure that we share as little information as we can get away with. We will not allow these systems to do much unless we, as the owners and occupants of the buildings can understand what we are allowing them to do, and how their responses will affect us. As we have protean businesses and dynamic lives, these interactions and their effects on us our ever changing.

In the IT world, we coordinate loose collections of services by policy-based assertions. Policy frameworks are used to coordinate services that may be similar, but not necessarily known, or operated by the same people. We know what policies refer to if we are describing financial services, or contractor interactions, or customer relations. It is not clear how to apply policy to things, especially things that are run by agents that have their own internal logic and business rules.

We do know one thing about these objects and systems; each is grounded in space. If one of these systems is supporting a customer service, that customer is grounded in space, and the business relationship with that customer, perhaps a lease, is grounded in space. In an industrial building, each division or work unit is assigned space. The natural basis for asserting policy on these services is to tie them to the space that they support. The natural framework to understand the information these services report is through the lens of space, and through mapping that space to the customers and business services supported by that space.

Today’s BIM is too large to use as a vehicle to transfer information. It is filled with detailed structural and performance information that makes it too unwieldy to use as the basis for a service framework. Even retro-BIM, the information collected long after construction, often to support renovation, is too detailed. We need something small and light, the size of a Google Sketch-Up drawing, and expressed in XML, that we can use to visualize and understand services.  Perhaps it can be based on GBXML (Green Building XML), already based on BIM and used for exchanging information used for energy modeling.

Ideally, the new dimensional BIM-light would support easy perspective-based translation to Scalable Vector Graphics (SVG). SVG is an internet standard based on XML for defining graphics. SVG graphics are already supported by many cell phones, and by all browsers except Microsoft’s (and Google is working on a solution for that). Because it is vector based, zooming in or zooming out is based on simple math operations  and produces clean sharp lines at any scale. SVG supports the full Document Object Model (DOM). DOM is the basis for interactive web pages, so scripting languages such as JAVA and interactive approaches such as AJAX are fully supported.

A simple light way to exchange three dimensional building models would improve owner and occupant understanding of building performance. A better understanding would reduce the perceived risk of fully participating in collaborative energy activities, including demand response. A shareable framework for visualizing information from building services would improve both the safety any occupants inside a building during an emergency and that of emergency responders.

Smoke Signals from the Energy Architecture workshop

I am not at the smart grid high level architecture workshop this week as Southern California Edison. Its members may be sworn to secrecy, or exhausted from long work, but are letting nothing out. The mere fact they are meeting, though, has caused numerous others to discuss the interface between the building/home/industry and grid, what we are starting to call X2G.

Three of the most prominent pre-standard specifications are OpenADR (Automated Demand Response), OpenAMI (Automated Metering Infrastructure), and OpenHAN (Home Area Network). In discussions around the formation of the OASIS Entergy Interoperability, someone asked “does OpenHAN define a gateway to OpenADR?”

The key architectural principles of symmetry, composition, and discoverability make this an unhelpful question. Every interface is a gateway, from one realm to another. That realm my include security changes, ownership changes, technology changes, and protocol changes. There may be significant operating requirement changes as well. For example, the definition of Real Time Response changes markedly as one moves from core transmission (very fast) to distribution, to home and building (relatively slow).

It is not the within the functions of the interface to define processes past the interface. This is why BACnet and LON and other building protocols proprietary and public have no place in the smart grid standards. This is why the industrial control protocols OPC has no place in the smart grid standards. OpenHAN is a special case, as it is a an in-building protocol created to meet the needs of the smart grid, but it, too, is not part of the smart grid interfaces.

I imagine two Service Entry Points for each [facility]. One offers time-sensitive two-way metering and also acts as a SCADA end point to improve customer service and diagnostics. The other offers a suite of services that I am calling the Energy Management Service (EMS). The EMS can be collocated on “the meter” or use a separate appliance and data path. This possible separation frees up today’s AMI installations to continue.

The EMS offers up multiple services to the smart grid. It provides an OpenADR endpoint to the grid operators. It manages market negotiations for energy purchases, generation, and storage. It relays curtailment signals, by which I mean the fast emergency load shedding signals.

The customer side of the EMS supports a more diverse set of tasks.

If the customer side of an EMS is above a private distribution network, it relays the OpenADR request on and aggregates the response into its own OpenADR response to the grid. Examples of private distribution networks include college campuses, corporate campuses, and military bases. Future distribution networks could encompass building floors in an office environment or even include the green neighborhood microgrid in a new subdivision.

A more common profile of the EMS might have some sort of building services network below, which would include the HAN. The customer side of the EMS could then be on the HAN, and the EMS would be a gateway. At a minimum, such an EMS would need to be able to poll the devices on the HAN. Some visions have an agent living on the EMS/HAN gateway, able to coordinate response from the agent-based devices below. Other business models see the EMS registering devices up to the utility and thereafter relaying direct control messages. In either case, the devices on the HAN see the message and coordination coming to them from the EMS.

Update on 2009-05-07 21:35 by Toby Considine

As you can see in the comments, Steve has suggested that I share this diagram that, as I understand it,  arrived during a flight from China.

One detail to note is that the space outside the building is "Agregator Domain" - a term carefully chosen to avoid presupposing any existing business entities. For another take on this, see the comment left on my Cyborg Beetle article.

IP Everywhere, or Just About

In February, a new administration official stated that the smart grid requires "IP everywhere", stirring considerable concern among the dumbest (in terms of grid smarts) of the smart grid players. Earlier this month, as I wrote of in The Impulse to Run Around Naked, a maker of building systems asked why we don’t just build systems with their own native languages and their own "most optimal" media. The operators of the big distribution systems (SCADA) for electricity, water, sewage, and natural gas are all a-twitter over the proposed national cyber-security directorate. This agitation in those that manage the actions of the built world is based upon misunderstandings based upon poor definitions as much as anything else.

Access to each system should be IP-based, or have the characteristics of IP. (IP refers to the Internet Protocol, usually partnered in conversation with Transmission Control Protocol as TCP/IP.) These characteristics are what is important, any protocol that meets the same characteristics can be internetworked with IP. That internetworking is the only part that matters about "IP everywhere".

IP is first of all independent of underlying protocols. Fiber, cable, wireless, and phone lines all support IP. IP can adjust to the special requirements of underlying media, as it does for Zigbee (used in self assembling networks of low bandwidth digital radios), which is only similar to IP or in 6LoPAN (an explicit mapping of IP v6 to similar radios) as long as we define IP correctly. To me, as long as the access is open, I would count Zigbee and 6LoPAN as compatible with "IP everywhere".

IP is connectionless and unreliable–by design. Older networks used to rely on dedicated wires between points-I remember limited numbers of long distance lines all across the country. Connectionless protocols do not create a connection, even a virtual one, but send the data directly. IP makes no guarantees that a message will actually get there, or that a sequence of messages will get there in order. Properly designed IP applications embrace this design; properly designed IP applications will handle network degradation with only minimal loss of function. If we make something as big as the smart grid, we had better embrace this attitude.

IP is universally addressable. Despite firewalls, routers, NAT, and other security filters, under IP if you want to send a message to any device, and you have permission to send a message to any device, you can send a message to any device. Many of the worst security breaches have occurred when a system administrator did not bother with security because the network was unreachable. Unfortunately for them (queue Jurassic Park soundtrack) IP will find a way. What can be connected to the internet, will be connected to the internet. Critical systems should be managed as if connected to the internet; any security devices or isolation techniques are then only additional security measures.

IP is a protocol that is well understood, and that can be accessed by anyone. Any systems connected to the smart grid should be IP, or should be translatable to IP without loss. All interaction should be designed to accept new connections, and errors, because that’s how IP works. All systems should be designed as if anyone can connect at any time and to manage security and self integrity on that basis. All systems in buildings and on the smart grid must be designed this way if we are going to connect them all together.

In other words, we must build the smart grid as if IP is everywhere even if it isn’t literally everywhere.