(a.k.a. “Outrage in Gridiopolis” – a Greek Tragedy about the Smart Grid)
Players: “The Archon”, “The Engineer Ultra”, and “The Chorus” -- the citizens of Gridia, known as the Gridians
Setting: Gridiopolis, in the province of Gridia -- in a parallel dimension
“I’m afraid that AMI is not the Smart Grid (SG) – and today’s AMI communication infrastructure is not SG 2.0-capable”, said the Archon of Gridiopolis. “This requirement was not anticipated in the rate-making processes for AMI – it was generally assumed our AMI communications infrastructure, or to be more precise, υποδομή, would support SG 2.0 applications.
For example, AMI investments were justified on the basis of their professed ability to enable a wide variety of demand response and distribution automation applications. This was in addition to AMI-enabled real-time pricing and time-of-use rate applications. The industry got into the habit of using the AMI and SG acronyms interchangeably, and in some people’s minds the acronyms became, incorrectly, synonymous.”
“What!” the astounded citizens of Gridiopolis exclaimed, “We don’t have a smart grid? We thought that’s what we paid for!”
The Archon turned to address His Eminence, The Engineer Ultra: “So, if AMI isn’t the smart grid, what exactly do we need then, Ultra, to enable SG 2.0 applications?”…………………………..
The Engineer Ultra set aside his astrolabe, refilled his krater, called on the flute players to desist, and responded as follows:
“Most of the SG 2.0 applications require higher control signal speed and band-width than today’s deployed AMI systems. To physically implement SG 2.0, we need a system combining the high-speed, high band-width communications with smart “boxes” or sensors at control points at the edges of the system.
Just as importantly, SG 2.0 applications also require significant integration investments, i.e., application programming interfaces (APIs) connecting the SG 2.0 applications to existing operating systems – what we call interoperability, or, to be more precise, διαλειτουργικότητ. NIST’s SGIP 1.0 and 2.0 initiatives, and other standards groups, have been doing some fine work to address these interoperability challenges.
But we don’t necessarily need to create a custom communications system, as was almost universally done for AMI.”
“Whew!” said the citizens, “Thank Apollo for small mercies!” The Engineer Ultra, somewhat discomfited by the boldness of their ridicule, continued: “Several suitable communication infrastructures have already been deployed at enormous expense by telephone, cable, fiber-optics, and wireless service companies. And we have a mature empire-wide communications language: the Internet Protocol (IP).
However, we will still need to invest a significant amount of capital for the “boxes”, sensors, software integration, and data management functions required to support SG 2.0.” He paused, exhausted, and lulled by the sweet scent of myrrh, fell into a deep sleep, muttering as he did, “I should have definitely consulted the Oracle………………………...”
At SGiX, our new definition of the SG and the iX cleans that up the ambiguity that is present today between AMI and SG concepts -- to recap, AMI is simply a part of today’s power system infrastructure (iX), enabling consumption measurement and monitoring. These applications don’t require real-time communications or high band-width, whereas the SG and its SG 2.0 applications do.
To be fair, AMI does enable a limited set of smart grid applications that can tolerate some latency. For example, the smart meter can enable remote disconnects, outage detection, theft detection, and direct load control. In our standardized definition, we call these applications SG 1.0.
Some SG 1.0 applications can even by-pass the AMI communications system. A historical example would be the pager systems used in the 1980s to broadcast Direct Load Control signals – my thanks to John Powers, CEO, Extensible Energy, for providing this example. These were operated by utilities, but they don't have to be. Some of today’s SG business models, especially those offering end-user energy management services, are using other by-pass strategies -- selling directly to energy customers without needing to “touch” any utility-owned assets, including their AMI systems.
Is it possible to have a single, scalable system that enables SG 2.0 based on the Internet Protocol (IP) and integrates AMI 1.0 legacy systems?
Yes, according to a very interesting joint study by Cisco, IBM, and SCE, and a seminal paper on Gridonomics by Cisco (references also cited in our Archives). They propose a three-stage transition to SG 2.0 – from today’s communications silos in utilities to a single common information bus, then to many common, integrated buses, and finally to a converged system. The technology is available now, and is mature.
So, our investment to date in AMI iX needn’t be wasted. The current AMI systems can be integrated with SG 2.0. But it will take decades to transition from the current system to SG 2.0 -- not for technology-based reasons, but because the “refresh cycle” for utility assets is lengthy. In an analogy to the development of the Internet, Laura Ipsen, formerly of Cisco, estimated that it might take up to 30 years to complete such a “change-out” transition – time for a whole career in the SG!
The power sector wouldn’t be the first to make such a transition to IP-based systems – e.g., the telecom, banking, and healthcare systems have already done it – but there’s a crucial difference: our challenge is made more difficult by the fact that the power system -- a very complex, real-time, physical machine -- must run reliably, second by second, as we evolve to a SG 2.0 regime. It truly is critical infrastructure – the health of our national economy, security, and society itself depend on it.
Finally, as we implement increasing numbers of SG 2.0 applications, we have to be careful to preserve the stability of the power system. Along with decreasing system inertia due to the increasing amounts of renewable electricity production, we will be introducing fast-response, price-driven, demand-side behavior, e.g., RTP/DP, ADR, which has the potential to out-speed the system operator's supply-side dispatching ability. SGiX is planning a separate dialog on this potential issue in the near future.