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.