Virginia Tech, Emergency Communications, and Academic Sheep

When the Virginia Tech shootings hit the news two years ago, I was sitting in on a meeting of the committee developing standards for communication in emergencies. Interoperability is critical to innovation, and emergency scenarios make the innovation scenarios crystal clear. Unfortunately, emergencies also cause the timid to stampede, and there is no more timid class in America than the academic leadership at our colleges and universities. I began thinking of this entry during the anniversary recognitions on the UNC campus.

Every school in the country rushed to do something, anything in the aftermath. Campus police chiefs were instructed to make a decision now, without waiting to consider the future. Campus decision makers rushed to spend money as fast as they could. On campuses, outcomes are measured on care demonstrated rather than on effective results. Care is demonstrated by new initiatives and by money spent; no campus leader wished to be left behind in number of initiatives. Millions were wasted creating systems that do not work well, and provide no foundation for future growth.

At Carolina, the two initiatives were public address systems and automated phone trees. Neither has proved particularly useful, or effective. Standards-based systems based upon EDXL and its peers were explicitly rejected.

The public address system lends an odd cold war edge to the campus. I grew up in San Diego, a town target rich with Navy base home to multiple fleets. Emergency response and emergency communications were part of the town culture. Warning sirens were mounted on tall white towers throughout the neighborhood I grew up in. They were tested every month, at noon on Friday if I recall correctly. Today, towers like this dot the campus.

This system might have been useful on the campus of the fifties. In today’s world, in which every student walks in a personal shell created by a booming IPod, it is unclear how well they work or even can work. Campus initiatives may not be effective, but they are thorough. The outlying fringe area of office space have the same sirens as on campus. The towers are ostentatious, installed without consideration of cost or effectiveness, and demonstrate caring.

The other initiative is what I call an automated phone tree. The campus signed up with some third party provider to automate calls to campus denizens. The campus asked students, faculty, and staff to enter their numbers into the database. It should come as no surprise that many never learned of this option, and that many more declined to be listed. As time goes on, the list can only be maintained by inculcating fear in each entering freshman class, and in all new employees.

A deeper problem is that this solution does not scale. Thousands of numbers must be dialed. Different cell phones have their own unique ways to go to voicemail. If the phone is busy, should the system try again?. In test emergencies, people routinely never receive the messages or receive them several hours later.

The correct target for today’s emergency messages is the cell phone and, to a lesser extent, the pager. EDXL alerts are all tagged with a geographic polygon of the affected area. EDXL alerts routinely include a narrative message, usually in a CAP Alert. Every cell provider knows the location of its cell towers. Every phone is talking to a particular tower at a particular time. There is no technical reason each of those phones could not receive a simple text message at the same time using existing infrastructure.

Cybersecurity for smart buildings and the smart grid

Building systems have until now been secured only for interaction between their parts. Schemes such as shared tokens used on open networks serve the purpose of isolating systems from interaction. They do not address the more intriguing security issues of interaction with non-system actors. These non-system actors may be agents from other systems, business process from other companies, or even direct consumer access.

Today’s shared token security schemes are only thinly deployed in buildings. They are an improvement on traditional building system security, which is largely non-existent.

What security there is today in control systems is most frequently controlled through some sort of head end system. Identity management for that system is entirely separate from that of the enterprise. This approach demonstrably reduces security. The most significant security breaches of SCADA systems appear to be by former employees, often months after they are no longer employed. The isolated systems that operate the engineered world are not tied directly enough to the business processes of Human Resources. A change in job status should cause instant changes in access rights; in the SCADA systems that control our utilities and our buildings, changes in access could take months.

We lack a commonly agreed upon common framework for defining access levels. At UNC, we defined a hierarchy of access rights that we could apply across many buildings of diverse technology. We defined configurers, system operators, system auditors, tenant operators, tenant auditors, and public. This framework allows us to define generic access and control rights across many buildings with diverse technology. Identity management, that is, recognizing who someone actually is, is always by reference to external enterprise systems. A security framework enablers easier adoption of the best practice of distributed authentication, local authorization.

For the smart grid and enterprise responsive buildings to develop together, we need easier adoption of best practices in security. Distributed generation and distributed energy storage introduce new inter-business interactions and new enterprises into the grid. As third party energy management and demand response aggregation merge, more enterprises will interact within the building. These are opportunities best met using federated identity management.

The smart grid and smart buildings will need to understand delegation. Delegation maintains control of information and services when they are provided by others interacting with third parties. To understand delegation, consider what you would want for secure management of on-line interactions with the IRS. You would like to keep all such communications private, and to prevent anyone from making decisions on your behalf. You would want to be able delegate this access to an identified professional such as your accountant. This assignment of rights might be for a limited term or it might be indefinite. You would want to be able to revoke that assignment at any time. You may grant your accountant the right to delegate once; he may need to delegate this access to his clerk, again able to revoke this delegation at any time. The delegation may be complete or partial, it may include all your business, or just managing your payroll. This model of delegation while managing control is well understood by enterprise architects.

Delegation, especially when combined with federated identity management, will be core to distributed operation of the open interoperable systems of the smart grid and smart buildings. Delegation will authorize your home or office energy management service (EMS) to share direct operation with your utility, your contracted demand aggregator, or with a maintenance analytics provider. Revocable delegation will authorize your utility to share your meter data with Google Energy or with others simply and quickly.

There are of course many other enterprise security concepts and approaches that we will need in enterprise buildings and the smart grid. Preparing for these three will introduce many more.

Collaborative Energy—the Smart Grid and the End Node

A significant goal of the smart grid is to encourage rapid innovation in the end nodes, that is in the commercial buildings, homes, and industrial sites that consume most of the electricity produced. Today’s North American power grid is probably the supreme engineering feat of the twentieth century; it has made possible the greatest life style ever lived. Its reliability, though, is insufficient for the digital world. Every system margin has been pushed too thin. The introduction of any significant portion of intermittent source energy, such as wind and solar, will make things much worse.

It is time to engage the end nodes in supporting system reliability. Today’s buildings have higher requirements for reliability and quality than the grid was ever designed for. Site-based generation and site based storage are part of the solution, but they could make the system even less reliable. It is time to begin the move to collaborative energy.

The Smart Grid Interim Roadmap highlights the Energy Management Service (EMS) as the sole service in the end node (Industry, Commercial Building, and Home) that communicates with the grid for purposes of load shaping and load curtailment. Over time, the load shaping signal will become primarily economic. Load curtailment, the mandatory response to critical issues on the grid, may not ever be adequately handled by economic signals. Load shaping and load curtailment comprise the function referred to by the utilities as Demand Response. The external signals to the EMS are being defined in the OASIS Energy Interoperability TC, building upon the work of OpenADR.

The EMS marshals the energy response from the building. This may range from the simple "shut off, turn on" to a nuanced response to enterprise and occupant driven priorities. While those priorities and their management are left, as they should be, to the market, we need stadata models to free the appliance, building system, and consumer electronics manufacturers to innovate. These standards go under the currently imprecise name "energy profiles".

Energy profiles will define the interaction patterns of the smaller systems. How much energy is it using? Can it respond to a price signal? How much can it respond to a price signal? How long will it take to respond? Will it use more before it uses less? The answers to these questions must be aggregated by the EMS and offered up to respond to OpenADR signals. The EMS should be able to access the meter to verify its own operations.

This model should support multiple levels, as several building systems may present one face to the EMS, or several EMS’s in a campus may present one face to the grid. The model does not include detailed operations of the EMS, nor does it define EMS user interfaces. These areas are best left to the creativity of the market.

A key function of the EMS is to support remote operations. Third parties will use the EMS to offer remote energy management services. Today, many utilities see themselves as the sole provider of these services. Increasingly, companies such as Enernoc and Constellation Energy are challenging that assumption. With proper standards, energy managers will flood the market, driving prices down. Those left standing will compete on higher level services.

There is still time to join the OASIS Energy Interoperability Technical Committee—drop me a line and I will tell you how to join.

Do we really need "IP Everywhere" in the smart grid?

If you want to start a fight in a crowd of smart grid participants, you can begin one by announcing unambiguously how you feel about IP (Internet Protocol) everywhere. Vendors fight to gain advantage for or to forefend elimination of their product lines. Utilities become passionate to defend their AMI projects and their rate bases.

Many of these conversations are premised on (to my mind) flawed thinking. Others need to define what they really want rather than relying on a simple slogan. I am a passionate believer in both open access to information and to open interfaces. I am also against IP everywhere.

One frequent claim is that I may need to talk to any device from anywhere in the future. I need no communication protocol for the car next to me on the free way to access my carburetion strategy. It is a security feature that the pierced guy next to me at the coffee shop does not have an IP address in the credit card in my wallet. Remote access reduces accountability. Remote access creates security requirements. Security requirements create expense and complexity.

We understand this everywhere but the grid and other aspects of the Internet of Things (IOT). When integrating engineered systems, there is a pervasive urge that everything must be able to address everything else at all times. Direct control of remote systems usually reduces quality of both experience and performance. As Gail Horst has explained succinctly, a clothes washing machine already is able to operate its internal controls; it knows that it can’t respond unless it is not full of bleach. It needs to expose only enough to indicate how and when it can respond, and to receive plaints of urgency and notifications of price.

For example, the Energy Management Service (EMS) manages the internal energy use in the home or commercial building. Ideally, an EMS needs communications of price, and of how much to shed, and to make a commitment. Period.

If the occupant chooses to outsource the operation of its EMS to an external third party, then the EMS needs additional capabilities to pass messages about internal devices and capabilities to that third party and to relay commands from that third party to the systems and agents within the building. If the third party happens to be a utility, and the utility business and regulatory model includes direct control by the utility, all messages should still be through the EMS. Today, third party management by the Utility just happens to be the default set of decisions in many parts of the country.

Nothing about this model mandates any shared IP space, or any direct addressability. I would argue that this model accurately describes the *business* model. So what are the IP wars about?

IP interfaces support easy interoperability within a domain—but interoperability between what. I do not need an IP address on my disk drive, although there are business cases when I may want it. The interoperability between things is needed for those loosely coupled situations that I may want to reconfigure/reassemble easily.

Building operators and building integrators are often frustrated by their inability to directly read meter data. The utility may have carefully engineered a solution to collect meter data at fifteen minute intervals to support billing. That solution may use non-standard protocols to wring every bit of performance through a limited communication channel. The billing system may use a batch process to post this collected data against each customer hours later. That information may only be available in a web page after carefully logging in.

The building system integrator would like to access live data for shorter intervals when tuning systems. The building operator would like to access this information in real time to support demand response. These functions require reading the meter on demand. The barrier is that meter data is collected only to support the billing system, and only to meet the needs of the billing system. The problem is sharing information only after processing. If IP were used to support the existing process, none of that would change.

In between domains, there is always a gateway. That gateway may be translating from CDMA to 1000BASEFL, it may be merely performing Network Address Translation (NAT), it may be doing semantic and ontological translation. It is still a gateway from one world to another. As such, either side should barely trust it. As such, it can have different protocols on either side.

The smart grid needs information sharing and informational interfaces. It needs discoverable interfaces at the domain transition, because I don’t care how hard the CPUs are processing, I’m concerned about the 3 days of head scratching, cursing human time needed to integrate each interface (which means every home, building, and factory) when someone switches to a new version of something somewhere.

The smart grid should leverage web developed and web-derived technologies, protocols, and interactions wherever in the smart grid they can speed development, increase transparency, and ease interoperability with adjacent domains to meet business goals. It does not need IP everywhere.