Web Services for Industrial Demand Response

John Gillerman

SISCO

johng@sisconet.com

Jim Luth

OPC Foundation

Jim.Luth@opcfoundation.org

Keywords: Demand Response, Web Services, OPC UA, IEC 62541, Industrial Communication

Abstract

Demand Response requires reliable communication over a wide area. While Internet based Web Services can be used for this communications, for industrial customers these Web Services must satisfy requirements for security, availability, reliability, and performance/scalability. Additionally, these web services must be readily integrated into existing communication networks at the communication end points. This paper considers the use of the set of Web Services called IEC 62541: OPC Unified Architecture (OPC UA) for Demand Response communication with Industrial Systems.

1. DEMAND RESPONSE COMMUNICATIONSIn order for utilities to more effectively control power system loading, they must be able to communicate reliably with load control systems and devices. Frequently, communication system designers will start by developing a set of XML documents that get exchanged between parties.

Figure 1: Industrial Demand Response Network

For industrial customers, the architecture must support two-way PUSH and the PULL communications between a

centralized utility server and distributed industrial client load control systems and devices. When using PUSH, the server sends client load control systems XML documents asynchronously. When using PULL, the industrial load control clients request XML documents from the server.

While it is easier and frequently necessary to employ a PULL model for communication, clients typically don’t know when events occur in the server. Clients can continuously poll the server, but as the number of clients increases, the latency of message delivery increases. A reliable standardized mechanism for industrial clients to asynchronously receive an XML document is needed. However, the W3C Web Service standards alone do not meet the requirements for industrial Demand Response communication.

This paper describes how Web Services can be use to perform reliable asynchronous communication through which an industrial client can receive Demand Response related XML documents. The proposed solution employs IEC 62541 OPC UA Web Services being standardized in IEC SC65E WG 8. IEC 62541 OPC UA does not define the content of the XML document, but only the means by which clients set up a reliable and secure two-way communication channel with servers.

1.1. Communication Technology RequirementsIndustrial Demand Response communication requirements include:

Object Technology Neutrality – It shall be possible to implement the Web Service Profile using a variety of Object Technologies including Java, Microsoft’s .Net, ‘C’ Language, and others.

Middleware Neutrality – Given that technology and platforms vary widely, it is required that service definitions be as decoupled from middleware specifics as possible. The Web Services defined in this profile must be able to provide access to messaging middleware, databases, content repositories, and a wide variety of applications including ERP systems.

Grid-Interop Forum 2008 Web Services for Industrial Demand Response-1

Performance/scalability – The capabilities of Demand Response communication end points and communication channels vary widely. The varying availability of resources rules out a single way of exchanging data. Consequently Demand Response communications standards seek to maximize interoperability while at the same time enabling choice of transport and encoding technologies.

Reliability – Reliability related to industrial demand response data exchange needs to be insured. Lost or corrupted messages can severely impact the profitability of operations. Service definitions are required to insure reliable data exchange.

Availability – Power systems need to run year round with minimal disruptions. Service definitions must provide robust interoperable mechanisms for failing over clients and servers.

Security – Traditional web service deployments secure the transport layer only using Transport Layer Security (TSL) or Secure Sockets Layer (SSL). However, these technologies alone do not ensure a secure exchange of messages. While more complete security can be added to TSL or SSL, the large number of options available makes interoperability difficult to achieve. The specification for demand response Web Services must provide enough detail to achieve interoperability without the need for superfluous bilateral agreements.

2. POSSIBLE SOLUTIONSThe development of Web Services for Demand Response can be seen as consisting of two tasks. The first is the specification of message payloads and the second is the specification of how Web Service technology is used to transmit payloads. The specification of payloads is particular to Demand Response since the content of message payloads reflects the content of the communication. However, the specification of the way in which Web Service technology is used to reliably communicate information need not be specific to Demand Response. Instead, the reuse of generic technology may be employed as long as that technology meets the requirements of Demand Response Communication described in Section 1.

For example, the OpenADR [1] addresses both aspects of Web Service communication by specifying the content of the messages exchanged (payloads) as well as a set of technical profiles by which the payloads are transmitted. OpenADR specifies a set of XML documents to be exchanged between a Demand Response Automation Server (DRAS) and load control systems and devices. The Open

ADR technical profiles include BACNet for communication with building automation systems as well as several custom profiles for communication with systems other than building automation systems. However, it is not clear that the specification of custom technical profiles for industrial related communication is preferred over an approach that re uses existing technical profiles. When communicating with industrial systems, the reuse of Web Services designed for industrial communication may be preferred. By using existing standards for industrial communication, existing system are more readily integrated into a Demand Response System. For example, the draft IEC 62541 OPC Unified Architecture (OPC UA) standard could be considered. IEC 62541 OPC UA is based on work originally done by the OPC Foundation [2].

IEC 62541 OPC UA is attractive for communication with industrial systems for several reasons:

Older OPC technology based on Microsoft COM technology is widely used by industrial control systems. It is straight forward task to wrap existing OPC COM based interfaces with IEC 62541.

IEC 62541 OPC UA is under consideration by IEC TC 57 for communication within the operations and maintenance areas within electric utilities.

It is believed that IEC 62541 OPC UA meets all requirements for Demand Response communication and will enable more rapid uptake by the DR community. In particular, since IEC 62541 OPC UA has been developed in cooperation with many of the large energy management/process automation/utility SCADA companies, IEC 62541 OPC UA provides the most expedient way to reach consensus with regard to communication with industrial systems.

2.1. IEC 62541 OPC UA Object Technology Neutrality

IEC 62541 OPC UA provides cross platform Web Services that have been implemented using:

.Net Java ANSI C

2.2. IEC 62541 OPC UA Middleware Neutrality

IEC 62541 OPC UA can be implemented over a variety of middleware and applications.

The figure below illustrates IEC 62541 OPC UA Web Service application adapters communicating via SOAP messaging over HTTPS.

Grid-Interop Forum 2008 Web Services for Industrial Demand Response-2

Figure 2: Adapter Architecture for an IEC 62541

OPC UA Web Service based Infrastructure

2.3. IEC 62541 OPC UA Performance/Scalability

IEC 62541 OPC UA services can be implemented over a variety of communication transport profiles. This means a single application wrapper can be used regardless of the technology used to transport data. Consequently, the technology used for a communications link can be optimized based on end point and communication channel sizing. For example, requirements for a high throughput link may not allow the use of XML data encoding, but instead may employ binary encoding of data on the network. However, switching binary encoding on the network does not mean the adapter needs to be rewritten.

IEC 62541 OPC UA provides three transport profiles to meet the varied performance/scalability requirements of the utility metering and operations environment:

XML Web Services (HTTP, XML, SOA)o Excellent tool supporto Firewall friendlyo CPU and Bandwidth intensiveo Recommended applications: Enterprise

integration and general business/information applications

SOAP/HTTP with binary attachmentso Mid-range performanceo Firewall friendlyo Requires IEC 62541 secure conversation

implementationo Recommended applications: Integration

across the Internet in the case where data payloads are large

Pure Binary (TCP Secure Conversation and Binary attachments)

o Best performanceo Limited Tool Supporto Requires firewall configurationo Single TCP port per servero Recommended Applications: Specialized

high speed applications or when running on a platform with limited resources.

It should be noted that which profile is used can be configured at run-time. The IEC 62541 OPC UA API supplied by the OPC Foundation provides portability between profiles.

2.4. IEC 62541 OPC UA Reliability

The WS specifications by themselves do not provide reliable messaging. IEC 62541 OPC UA provides additional reliability via:

Timely detection of communication failureo Keep-alive interval negotiated by client

and server o Both client and server monitor activity

Rapid recovery from communication failureo Resynchronization with existing channel

With no loss of Datao Data loss unlikely for intermittent failureso Servers cache delivered notifications

allowing retransmission

It should be noted that the requirement for reliable communication for industrial communications suggests that the Web Services should not follow the Representational State Transfer (REST) paradigm. Typically REST based services have the following the characteristics: A pull-based interaction style: consuming components

pull representations. However, for industrial demand response, push is also needed.

Stateless: each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server. Therefore, neither the client nor the server can positively know if all messages sent by the server have been received.

It should be noted that a REST based protocol may be suitable with residential customers for whom a lost message does not have as great a potential economic impact.

Grid-Interop Forum 2008 Web Services for Industrial Demand Response-3

2.5. IEC 62541 OPC UA Availability

The WS specifications by themselves do not enable the construction of interoperable highly available components. IEC 62541 OPC UA high-availability is provided by:

Keep Alive messages provide timely detection of communication failures

Client/Server Sessions allow IEC 62541 OPC UA components to maintain state context

Notification Sequence Numbers allow clients to keep track what messages have been received

Subscription republishing allows seamless transfer

Figure 3: IEC 62541 OPC UA Augments the WS Specifications to Support Failover

In Figure 2, illustrates redundant clients provided by one vendor can interoperate with redundant servers provided by a second vendor.

2.6. IEC 62541 OPC UA Security

In the absence of IEC 62541 OPC UA, WS Security provides a very large number of options. It is difficult to achieve interoperability without limiting the choices to those that are applicable to the utility metering and operations environment. IEC 62541 OPC UA includes a set of mandatory encryption and authentication profiles based on WS standards. The IEC 62541 OPC UA Security profiles are illustrated in Figure 4.

Figure 4: IEC 62541 OPC UA Security Profiles

The IEC 62541 OPC UA WS security stack includes many of the WS Security specifications. A closer look of the IEC 62541 OPC UA Security stack is shown in the figure below:

Figure 5: IEC 62541 OPC UA Implements the WS Security Specifications

Custom DR Web Services could defined that implement the WS specifications to meet DR specific needs, however UA provides a pre engineered solution with support by major vendors. By reusing the generic IEC 62541 OPC UA services, building/industrial/utility automation systems can limit the number of supported interfaces.

3. PROPOSED APPROACHIt is proposed that the Open ADR community lead by the Demand Response Research Center (DRRC) of Lawrence Berkeley National Laboratories (LBNL) and supported by the California Energy Commission's (CEC) Public Interest Energy Research Program (PIER) enter into a partnership with the OPC Foundation to develop an IEC 62541 OPC

Grid-Interop Forum 2008 Web Services for Industrial Demand Response-4

UA profile for Demand Response for industrial systems. As stated above, this does not include the discussion of message payloads, but only the messaging protocols. After the development of this profile is complete, it is proposed that the OPC Foundation and LBNL work to get this profile standardized in IEC TC 57.

REFERENCES [1] OpenADR Draf May 2008, Demand Response Research Center (DRRC) of Lawrence Berkeley National Laboratories.

[2] The OPC Foundation, dedicated to interoperability in automation and enterprise computing, is an independent, non-profit organization comprosed of leading manufacturers and solution providers in factory and process automation as well as enterprise solutions. The OPC Foundation's charter is to develop worldwide industry-standards for data transfer offering multi-vendor interoperability and seamless connectivity of measurement and automation devices, systems, networks, and enterprise computing solutions used in the manufacturing and process industries, by leveraging open computing technologies. Development of specifications is undertaken by volunteers from 450+ members worldwide. With the introduction of the OPC Unified Architecture (OPC UA), the Foundation has partnered with other standards organizations to produce OPC UA information model companion specifications.  The partners include ISA, MIMOSA, FDI/EDDL, and IEC TC57 WG13. For more information see www.opcfoundation.org

BIOGRAPHYJohn Gillerman has over 20 years experience working in the field of power engineering. Since 1988, Mr. Gillerman has concentrated on the design of software systems for power system monitoring and control. At SISCO, Mr. Gillerman has co-led the design and architecture of the Utility Integration Bus (UIB) – an application integration product based on the IEC 61970 and 61968 standard interfaces. Mr. Gillerman has served as the Integrated Security Network Facilitator for NERC’s Data Exchange Working Group, been active in OMG’s Utility Domain Task Force, EPRI’s Control Center API working group and is SISCO’s representative on the IEC TC 57 WG 13, 14, 16, and 19 standards committees. Mr. Gillerman holds a BSEE from Rutgers University, New Brunswick, NJ.

Jim Luth is the Technical Director of the OPC Foundation and the chair of the Unified Architecture Working Group. Prior to full-time OPC employment, Jim was a Consulting Engineer at ICONICS, architecting and developing many of the OPC-enabled GENESIS32 modules and representing ICONICS in OPC Foundation Technical Committees.

Jim has 25 years of experience in factory automation and software development having previously worked for such organizations as General Motors, Taylor Instruments and The Foxboro Company. Jim received a Bachelor of Science degree in Electrical Engineering from Rensselaer Polytechnic Institute.

Grid-Interop Forum 2008 Web Services for Industrial Demand Response-5