As industrial and large commercial facilities continue to make use of distributed energy resources (DERs) for reliability and sustainability, there will be greater interest and need to interconnect those resources with the local electric utility. The industrial sector has many scenarios that would call for such an interconnection.
An industrial facility—a small manufacturing facility, for instance—may have an agreement with the utility for differential rates, requiring coordination of the DER operation with fluctuating pricing situations. DERs might also need to be brought online in response to a utility contingency. Another example might be a large petrochemical facility with its own power generation and distribution, including substations, distribution circuits, and generation facilities. Those DERs could include natural gas-driven microturbines, diesel generators, solar photovoltaics, and/or energy storage capabilities. At times, those resources could provide power back onto the grid, producing revenue for the industrial owner.
In these scenarios, the facility will have a load-shedding agreement with the local utility or a power purchasing agreement for when they supply power back onto the grid. As a requirement of such agreements, the local utility will typically require certain functions, features, and communication that it needs for that interconnection with that industrial facility. The utility may also require electrical system visibility and even some control functionality inside the industrial facility's electric power system, including generation control and substation configuration.
This is where IEEE 1547: Standard for Interconnecting Distributed Resources with Electric Power Systems can identify for the consulting engineer what functionalities need to be in the control systems.
How IEEE 1547 helps engineers
The base standard in the IEEE 1547 series is about DERs, and it lays out the agreements between the electric utility sector and the industrial or the DER sector, so that the industrial customer doesn't have to go utility by utility negotiating its own agreements. That would be very important where, for example, an industrial customer has facilities in many different locations, even different states. Using IEEE 1547, the engineer can devise a common approach to deal with the different electric utilities in multiple states.
Thus IEEE 1547 simplifies the approach for the industrial facility and provides a number of benefits. It allows facilities uniformity in purchasing equipment, which provides economies of scale. It allows them to establish standard operating procedures across multiple facilities, which benefits training efforts and operations and maintenance activities. Employees who work on multiple facilities will recognize and understand the common features, saving money, time, and manpower. The consultant benefits from having a repeatable design.
By using the IEEE 1547 series, the engineer has a starting point that will work in any of the 50 states that he or she works in. Whatever utility you're working with, IEEE 1547 gives both parties a clear, agreed-upon starting point for an interconnection. You don't have to reinvent a solution from the ground up. Recognizing the value of such a standard, the IEC has recently announced an effort to produce an IEC document based completely on IEEE 1547.
The fact that the international community is going to follow the IEEE 1547 series should lend the engineer and his or her client a certain degree of confidence that they're on solid ground in anticipating the future, if you will. Some call this "future-proofing," which is a pretty strong term. But in this case, as in others involving standards, if you base decisions on a standard accepted here and around the world, that's likely to stand you in good stead over time. Standards may get tweaked from time to time, but by design they are backwards compatible, so whatever you've done based on a standard is likely to continue working and doesn't face the threat of, say, becoming a stranded asset—at least not to the degree that's true for one-off solutions.
Interface between industrial customers, utility
For years, some have assumed that the interval or smart meter would be the interface between an industrial customer and the utility. In other words, that communications data, curtailment requests, generation requests, and price signals would all occur through an advanced metering infrastructure (AMI) system.
Based on an assessment of the systems themselves and the needs of industrial customers, however, the AMI approach may not be the only—or even the most desired—interface. And those two factors should be high priorities for the consulting specifying engineer designing industrial control systems and their utility interface.
This issue has big implications for industrial customers because the design and features and functions of their industrial control system are going to depend on which direction they take.
Let me explain. First, the bidirectional communications that a smarter grid will require can be handled independently of the interval meter AMI. Second, meters and AMI are largely proprietary systems, potentially leading an industrial customer to vendor lock-in. Third, it’s early in the AMI industry, and technical alternatives exist. Consequently, there will be winners and losers; if a utility’s AMI vendor goes belly-up or migrates to different technology, it could mean stranded assets for the customer.
A different approach would use the meter solely to record usage and employ a separate appliance or gateway for bidirectional communications.
This approach has several advantages, besides avoiding dreaded vendor lock-in and stranded assets. One advantage is that the gateway could use a high-speed Internet connection rather than be hobbled by the communication limitations of the AMI. Or the gateway could use dedicated communication lines to the electric utility, providing greater bandwidth for greater functionality. The appliance-as-portal option also gives the industrial user more flexibility for interconnections with other systems and, therefore, the data for greater insight into its operations.
Today, AMI protocols are vendor specific. If you purchase a meter from vendor X, you must also purchase the data collection and protocol system from vendor X. In contrast, the gateway approach allows the utility and the industrial customer to immediately employ industry-standard protocols such as IEEE Standard 1815 (aka DNP3), which provides the means for robust security.
What remains uncertain at this point is whether both options will be available from the utility. Consulting specifying engineers and their industrial customers should discuss this issue with the utility. If both options are available, then compare the two options’ costs, design challenges, features, and functions, taking into account the projected future needs of the industrial customer.
It’s important to understand that the cost-benefit ratio for AMI remains unproven; it’s still being evaluated. Much of the current deployment of AMI has been subsidized by 50% by the U.S. Dept. of Energy’s Smart Grid Initiative Grants in the U.S. Without those incentives, it is unclear whether the deployments will continue to spread, or be profitable. Some state regulators remain unconvinced that AMI is a cost-effective expenditure of rate payers' money.
Finally, because smart meters and AMI are a programmable system, greater potential exists for hackers accessing the system.
Perceived, widespread AMI adoption alone is not a good basis for an engineer to make an assessment of whether that's an appropriate technology choice. He or she needs to make a professional judgment about the systems themselves, and their technical capabilities, and not be swayed by the apparent spread of AMI systems. Talk to the utility to which you are designing your customer’s interconnection. You may find that other, more future-proof alternatives are available.
- The list is long on how ideas for standards are generated. Typically, engineers who implement technology:
- Encounter hurdles to the interoperability of equipment in the form of physical or software compatibility
- Run into a gap in established processes for how certain actions should be taken
- In the implementation of an established standard, may find that an issue has been left unaddressed.
The IEEE encompasses several dozen technical societies and groups, each of which has an interest in creating standards pertinent to its focus. Those interested in initiating a standard may form a working group to bring the matter to the attention of a technical society, which becomes the sponsor of the activity and then forwards the matter to the IEEE-Standards Association’s (IEEE-SA) New Standards Committee (NesCom) as a project authorization request, or PAR.
The members of the NesCom review the PAR to ensure that proper procedures have been followed and the originating group has offered a workable plan to complete the standards process within a reasonable timeframe. When the PAR is approved, it returns to the working group, which starts to create the draft of the standard.
After a draft of the standard has been created, the document is ready for balloting. The working group creates a sponsor ballot pool composed of people who express interest and are registered with IEEE-SA as potential balloters for the specific topic. Essentially, this is the peer review process.
After the sponsor ballot process is completed, the working group must address every comment. Then the working group attempts to build consensus behind the updated draft, first among its own membership in the resolution of the comments and then among members of the ballot pool.
Sciacca is president of SCS Consulting. He is an active senior member in the IEEE and the International Electrotechnical Commission (IEC) in the area of utility automation. He has more than 25 years of experience in the domestic and international electrical utility industries. Sciacca serves as the chair of two IEEE working groups that focus on cyber security for electric utilities: the Substations Working Group C1 (P1686) and the Power System Relay Committee Working Group H13 (PC37.240). Read his Insights on Power blog for more on this topic.
Powered by ContentStream®