General Relativity and Control Systems Standards

I suspect most of my readers can just about remember light speed, the 100 foot barn, and the 110 foot log from learning about relativity. The barn had doors at each end, and one set would close the instant the other doors opened. The challenge was to transport the log through the barn. The answer had to do with light speed and collapsing space, so that as one got close enough to light speed, the log shortened, and it could fit through the barn. It was a simple enough calculation as to how fast one could go to make the log shrink how much. When each of us had completed the math, the professor sprang the surprise on us: "OK, what is happening from the perspective of a cockroach on the log?"

I haven’t been writing much recently, because I have been writing all of the time. The national smart grid roadmap is a project being completed in double time. The EPRI team is diverse and whip smart. The workshop participants are opinionated and have hundreds of millions on the line. I would be surprised of the process was not contentious.

The real problem, though, is no one thinks of the cockroach. Each player on the multi-disciplinary team sees the problem set up the way that they want things to work. Power grid engineers see homes and offices as just one more set of slow devices to turn on and off. Homes and offices see the grid as a secretive and not very reliable partner they have to work with. Green and sustainable energy folks seem to see the laws of thermodynamics as as much a social construct as are the tariffs and business procedures of the grid. Utilities executives see distributed generation as an inefficient way for middle class hobbyists to get their obsessions paid for by those less well off.

The cockroach was moving every bit as fast as the log he was sitting on. While an observer saw space, and the length of the log, contracting, the cockroach was sitting on the log and saw it remaining at 110 feet. The cockroach actually saw the barn getting shorter still, and not likely to let the log pass. However, the cockroach also saw was time dilation instead of space dilation. To the cockroach, the two doors no longer open and close simultaneously, giving the log just enough time to slip through.

And that is the problem with the smart grid. The grid operators do not see the problems of the buildings. The building owners do not see the problems of the grid, because they are hidden by the rules and market design. Venture capitalists do not see a path to profitability in funding projects with years of indecision by the utilities built into the sale cycle. “If only those others would learn about how hard my problems are…” None of them will embrace the perspective of the others; they happen to have other jobs.

Today, I have been wrestling with “Architecturally Significant Interfaces”. Grid architects tend to see the world as late 60’s open plan houses, with no proper rooms to divide the houses activities. Open up the kitchen to the dining room and living room. (I wonder how much great rooms are responsible for the tendency to eat take-out in front of the TV.) Open up the master bedroom to the great room as a loft; it is open and honest, and who cares if it scares the kids. Heck, pry the doors of the bathrooms, so everybody can interact, no matter what they are doing.

A good architecture divides the house into rooms, and thereby defines how people live there. It does not determine the furniture or the wall paint. The conceptual model of the smart grid (read it yourself, chapter 3) describes the functions of the grid and the buildings and people who participate in it. The Architecturally Significant Interfaces could define how information is handed between them; if selected correctly they will free up those in reach room to innovate, without concern for those in other rooms. If we end up with an open floor plan, we will have a mess, wherein in the name of openness we will need a family meeting to before we can decide to change anything.

Relativity—it relies on acknowledging different perspectives. Without acknowledging a few architecturally significant interfaces, the smart grid will assume a perspective held by no one. And that will be a prescription for failure.

Parsimony and Security

I have been thinking about security and parsimony lately. Security is not merely about confidentiality or even identity. It is about predictability and integrity. Challenges to predictability and integrity occur not only malefactors, but from those who develop, test, and maintain systems. Even interoperability is a part of security, introducing new sub-systems, or upgrading old ones, can introduce unanticipated interactions and failures.

Introducing any interface not actually required introduces new attack vectors and increases the complexity of testing. An interface that is only used rarely is only tested rarely. Any non-essential interface is a site that will be delegated to the junior developer; primary interfaces will be tested fully while the non-essential interface becomes a back door.

DOS/Windows is the poster child for security and reliability problems. Upgrade problems and incompatibilities were legend. Many of these arose when little used and long deprecated interfaces were eliminated or changed. Some interfaces existed only to support development and testing, and were never even documented. As thousands of developers competed for advantage, these interfaces got used. In an ecosystem of systems with far more variety, we will be better served to never introduce these obscure interfaces.

The other challenge presented by DOS/Windows was the sheer number of interfaces. One bit of code might support a dozen interfaces. Code added to fix one problem would get replaced as code to address another security based on an earlier code fork would reintroduced the problem. Complex interfaces require complex maintenance.

An oft-heard and little understood truism is that security must be designed in. This can be interpreted to require planning for encryption and isolation at every interface. This task can be fiendishly complex and require that only the most sophisticated programmers work on each system. As we know that we cannot guarantee such attention, this is poor security design. Complex procedures embrace their own failure. Better security design offers fewer chances for missteps, and better chance for sustained success.

For the smart grid, this means fewer interfaces and simpler testing. The smart grid has defined inflection points, places where responsibility or ownership or business processes change. Such inflection points define business processes with specific requirements for shared identity and authority. These business interfaces define the risks and the costs of failure. They should be few, simple, and well-defined.

We may anticipate site-based generation is either PV or Wind. We could, in theory, include wind speed as a required part of the wind source interface for the grid. A house in a tidal swamp may have some sort of novel generation strategy that appears, in most respects, identical to energy generated by the morning and evening winds that characterize the weather between the California coast and desert. By excluding wind speed, in this example, the same interface would serve for the wind generation and the tidal swamp generation. Simpler, sparser interfaces are what enable diversity and innovation. Coming back to security, the unused wind speed interface in the Tidal generator, if mandatory, is the one that will be untested and eventually a security hole.

Anything we put on the smart grid will be there for some time. It will be upgraded numerous times and coexist with other version levels. The interfaces should be few, because they will be there for a long time, and implemented and patched by many programmers.

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.

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.