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.

A pricing Service for Electricity

What price structures are necessary to enable fully symmetric negotiations over power purchase and sale? Over at the NIST TWIKI, Marty Burns, Bill Cox, and I ironed out the requirements for a pricing service for electricity. Comments are welcome.

---

What are the requirements for communicating price across the smart grid? What pricing structures are in use or under development now? How do we move to a common information element, common whatever else needed for prices?

Note: It is important to emphasize that these are requirements for a solution set for pricing services. Therefore all the following requirements are not necessarily simultaneously applied to any particular single service based on the ensuing model.

Due to potentially [rapidly] changing roles, we use the terms supplier and consumer rather than utility and customer. With aggregators, these terms are still more general.

This page was created and modified by Marty Burns, Toby Considine, and William Cox, for discussion among the DEWGs.

Pricing Requirements

Dynamic pricing enables dynamic power management and includes both:

1) the realtime response of automation systems to "realtime" grid pricing and

2) the managed response of consumer management and planning systems to supplier/grid price forecasts.

1.1 Regulatory/Policy

• 1.1.1 Metering, Billing, and Collections are separate processes / services from power delivery.
• 1.1.2 Aggregation and Delegation should be explicitly permitted for all operations.
• 1.1.3 The pricing model is not explicitly tied to any particular regulatory environment.
• 1.1.4 Barriers to symmetric operations should be eliminated.
  • 1.1.4.1 Suppliers and consumers may exchange roles at frequent intervals.
• 1.1.5 Businesses willl handle traditional business processes as they do now.

1.2 Business Objectives

• 1.2.1 Suppliers are able to provide automated dynamic pricing information to consumers.
• 1.2.2 Pricing is able to support active power management and optimization.
  • 1.2.2.1 Price adjustments can be made in time in up near real time manner.
  • 1.2.2.2 Prices may include commitment enforcement in support of a variety of scenarios, including both minimum and maximum commitments.
• 1.2.3 Pricing should be available for a variety of deliverables.
  • 1.2.3.1 Power Consumption.
  • 1.2.3.2 Peak Availability.
  • 1.2.3.3 Relinquishment of prior right (Differential Behavior vs Absolute Consumption).
  • 1.2.3.4 Power Quality.
  • 1.2.3.5 Carbon Offsets.
  • 1.2.3.6 Transmission and Congestion.
• 1.2.4 Pricing should support the decommoditization of power.
  • 1.2.4.1 Wind, Distance, Carbon, Triple Bottom Line, and other attributes.
• 1.2.5 Pricing should be time sensitive.
  • 1.2.5.1 Time offer made.
  • 1.2.5.2 Window for offer.
  • 1.2.5.3 Time of acceptance.
  • 1.2.5.4 Scheduled Time of consumption.
  • 1.2.5.5 Actual Time of Aggregation.

1.3 Business Procedures

• 1.3.1 A set of core processes and transactions will be defined.
• 1.3.2 A service to support each core process will be defined.
• 1.3.3 A common service framework will be defined to support all services.
• 1.3.4 Market operations should support unidirectional price announcements.
• 1.3.5 Market operations should support bidirectional bidding.

1.4 Business Context

• 1.4.1 Legacy pricing models need not be supported by the new interfaces.
• 1.4.2 Legacy business processes need not flow through new interfaces.
• 1.4.3 Requirements to continue traditional business processes may be met outside of the new interface.

1.5 Semantic Understanding

• 1.5.1 Must accommodate wide range of Pricing Models.
• 1.5.2 All Pricing Models should contain a common set of properties.
• 1.5.3 Many Pricing Models may be in effect concurrently.
• 1.5.4 Pricing Models will change over time and must be discoverable.

1.6 Interaction Model.

• 1.6.1 All intereactions will be messaging based.
  • 1.6.1.1 synchronous request-response pull.
  • 1.6.1.2 asynchronous publish-subscribe push.
• 1.6.2 Symmetry should be supported at all interfaces.
• 1.6.3 Best Efforts message delivery shall be supported.
• 1.6.4 Security and Privacy must be designed into the model.
  • 1.6.4.1 Authentication is often required.
  • 1.6.4.2 Guaranteed message delivery shall be supported.
  • 1.6.4.3 Non-repudiated message delivery shall be supported.
  • 1.6.4.4 Private message delivery shall be supported.
• 1.6.5 Delegation of message handling shall be supported.

Gamboling through the Clouds

Some months ago, I wrote about how Software as a Service (SaaS) was going to be used in building controls. The UNC Enterprise Building Management System (EBMS) and Hosted Controls already use that model for monitoring and operations of building systems. Others like Sensus offer building analytics and knowledge-based maintenance from their own data center. Now Harrah’s Entertainment, the largest of the casino operators is moving into the clouds, and the outcome may change building systems again.

It has been best practice for a while now to interface building systems to hotel customer operations. The check-in process can activate the room systems, which then save energy when not rented. Front door access control sensors can read the room key and turn on the room conditioning as the guest comes in the front door. The Hotel Technology Next Generation group has even included remembering customer preferences for the operation of room based systems in their customer retention strategies. Traditionally, these approaches relied on direct interaction with the reservations system.

Harrah’s has outsourced its systems for managing reservations, for air travel, and for player relations to the SaaS vendor SalesForce.com. This is a strong statement, as no industry relies more on customer loyalty programs than the gaming industry, and Harrah’s is known for the most data intensive approach to this problem.

One of the concerns with outsourcing core business functions like this is vendor lock-in; you have committed yourself to integrating your other business functions with an external computing resource of which you have no control. It is easy to view these operations as a simple user interface for the customer making a reservation, and for the clerk checking the customer in. The hotel reservation has a host of interactions, however. Housekeeping needs to know not only when the customer arrives and departs, but also any requirements for special bedding, or extra towels. The restaurant may support one free drink on the night of check-in; tabs for breakfast on the departure date may need expedited processing. In today’s hotel, third parties may run housekeeping and the restaurant, increasing the complexity of the interaction

These interactions, and their importance to the enterprise, are why service interfaces and service definitions are so important.

If we take these interactions to building maintenance and operations, and to new energy markets, the service interaction problems continue. The reservation process should drive the operation of each room. The hotelier may want to balance spreading guests out for maximum privacy vs. bunching guests on a few floors because of anticipated high energy costs or energy reliability signals. Organizations such as Harrah’s demand close integration of tenant service and physical security.

Harrah’s provides high amenity facilities wherein an extra feel of luxury creates an increased willingness to gamble. Harrah’s has global distribution with considerable site-based diversity. Knowledge based maintenance and central management of facility quality are particularly valuable to Harrah’s.

Standard service definitions can put all operations into cloud computing, whether the low hanging fog of facility operations or the core customer relationship management that Harrah’s has outsourced. Building controls are grounded concrete systems—but their heads should be in the clouds.

EBMS Takes its First Steps

I have written before of UNC’s Enterprise Building Management System (EBMS). EBMS talks to legacy systems in more than a 100 buildings on the UNC campus. EBMS uses a half dozen variants of web services to monitor and operate building systems using nearly every brand and every internal protocol. All data is normalized and brought into an industry standard database, currently we are adding 42 million transactions a day to that database.

Phase II of EBMS is finishing up before the end of the year. The system is going through final tuning and acceptance testing; the developers from Cyrus Technologies are still sleep deprived but have that light in their eyes that coders get when the end of a death march is in sight.

While commissioning the system, we found errors in our old proprietary system, including sensors that had always supplied bad data. Building integrators had “solved problems by the expedient of not displaying bad data. In at least one case, this bad data explained years of expensive maintenance and replacements. When EBMS is complete, our operators will have a single web-based console for all of these buildings.

We are just beginning to get other sources of data into the EBMS database. EBMS now includes historical weather data. Metering data for all utilities in the building is just starting to flow in. Even though we have in-house utilities providing electricity, and steam, and chilled water to the buildings, we have had as much difficulty getting live information as if we were getting information from a third party. The barriers have been political, or perhaps more fairly cultural. Still, the information is now flowing in.

One of the final steps for the developers was setting up an OLAP framework for looking at the data. Online Analytic Procession (OLAP) is using multi-dimensional analysis of data to find underlying patterns. OLAP is typically used in business reporting for sales, marketing, management reporting, business process management (BPM), budgeting and forecasting, and financial reporting. OLAP has not traditionally been available for building operational data. We now have an OLAP framework in place for 100 buildings.

This week, we are interviewing candidates for a new position, for a new role in this, or perhaps any, organization. We are hiring a full time data analyst, looking for experience in quality management or marketing rather than in mechanical systems. This positions full time job will be to look for anomalies and patterns in the operational data.

Perhaps we are moving toward predictive maintenance based upon analysis. Perhaps we are finding sub-optimal building response arriving from technology choices made years ago. Perhaps we will be able to understand the relationships between different departments and how buildings perform for them. We are entering the era of knowledge-based operations.