Using Web Services to exchange power plant process data Olivier Pasteur
Tuan Dang Member IEEE
Pierre-Etienne Delon
EDF R&D – Department STEP 6, quai Watier 78401 Chatou Cedex FRANCE
[email protected]
EDF R&D – Department STEP 6, quai Watier 78401 Chatou Cedex FRANCE
[email protected],
[email protected]
EDF R&D – Department STEP 6, quai Watier 78401 Chatou Cedex FRANCE
[email protected]
Abstract – Since the introduction of SOAP protocol in 2000 by W3C, this Internet protocol continues to revolutionize the world of information and communication technology. In the domain of business information system, SOAP has allowed the development of Web services concept, which changes the way software and information system architecture may be designed and built. Service Oriented Architecture (SOA) is an example of this. In the area of industrial information system, the penetration of SOAP and Web services is less rapid because of the proprietary technology bastion, and the users reluctance in term of performance and lacking of feedback. In this paper, we show that our SOAP based Industrial Messaging Specification (SIMS) offers services, which are used successfully in exchanging power plant process data with soft real time performance. The upcoming OPC-UA is another illustration showing that SOAP is on the way to become a base standard in industrial messaging protocol.
Index Terms – Power system, telecontrol, dispatching, communication infrastructure, energy management systems, Web Services, SOAP, OPC-UA, IEC 60870-6-*. I. Introduction In 1999, the French regulator decided to make functional unbundling of EDF (Electricité de France), the main French public electric utility, into two separate activities: generation and distribution on the one hand, and transmission on the other hand. Historically, there was only one telecontrol communication infrastructure that served to perform technical dispatch of generation and transmission network. This infrastructure was used to collect remote measures of power data from all generating units. Following the separation of activities, this infrastructure became property of the Transmission System Operator (TSO), who decided not to offer this service any more for transparent and economic reasons [1]. As a consequence, EDF could no longer use the same infrastructure to control the transmission network and the hydraulic power plants. EDF hydraulic generation division (DPIH) decided to develop and renovate existing infrastructures for the telecontrol of its hydraulic power plants. An innovative solution using a SOAP (Simple Object Access Protocol) based Industrial Messaging Specification (SIMS) was evaluated instead of using a protocol like IEC 60870-6-* (ICCP/TASE.2) that is not widely available and can not be integrated easily in enterprise-wide application. More over, ICCP/TASE.2 does not specify
standard mechanism for authentication, and the “bilateral table” – that determines which control and data points will be provided to each side of association – does not offer a secure and an easy way to manage dynamic configurations . There exist other “messaging” systems such as DDS [5] and DAIS [6]. DDS is Data Distribution Service for RealTime Systems. That’s an OMG standard adopted in June 2003 and finalized in June 2004 defining a portable API using CORBA IDL. DDS provides a simple publishsubscribe mechanism with a real-time focus. The DAIS specification was approved for adoption in March 2001 by the OMG. The DAIS, Data Acquisition from Industrial Systems, defines a set of IDL interfaces for discovery of and access to simple property values. A DAIS Alarms and Events specification was also approved for adoption by the OMG in March 2001. However DAIS doesn’t address communication line issues while SIMS provides communication channels and watchdogs to address communication failures and manage recovery. Although some private implementations of DDS are now available, DDS and DAIS was not mature technologies in 2003 and no commercial implementations was found. With the development of Internet based technologies such as SOAP and XML, Web services looked to become a promising and major technology that can improve interoperability in industrial information system and provide easier implementation and deployment than Corba IDL. XML/SOAP is supported by lots of commercial tools while Corba IDL is less widespread and more complex. It may also be incompatible with some network security equipments and some low bandwidth links. II. THE SIMS MESSAGING SYSTEM The SIMS messaging is based on two components: a client and a server (see Fig.1). The server component is a data provider; it provides web services such as Read, Write or Subscribe. The client component is the data consumer; it aims to invoke server services and provides callback functions. These call-back functions are also web services used by the server, for instance, to notify the client that new data are available. Several servers and clients may be used in case of having many data providers and consumers, and several client components can exchange messages and get data from the same server component. Both of them, client and server component, include a SOAP client and a SOAP server used to exchange SOAP messages.
411
opened, the watchdog calls periodically the Notify() web service of the client. Seven services are provided by the server component: • OpenChannel : Open a communication channel
Messaging client Soap client
Soap server
han enC Op
el
Notify
CloseChannel
Unsubscribe
Subscribe
Write
Read
CloseChannel
ReOpenChannel
OpenChannel
Soap client
Soap server
ReOpenChannel : Re-open channel previously closed.
•
CloseChannel : Close a communication channel
•
Read : Read data
•
Write : Write data
•
Subscribe : Create a data subscription
•
Unsubscribe Cancel a data subscription.
a
communication
The client component aims to get data. It should be able to invoke the seven web services of the server component. The client is part of an application that consumes data. As soon as this application required some data, the client opens a channel with the server and reads or subscribes to these data using the appropriate web services. If data changes are made or if the server closes the channel, the client will be notified by its 2 web services:
Messaging server
•
Notify: Notify the client that new values are available for the data to which it has subscribed.
Fig. 1. Software architecture of the SIMS messaging
•
CloseChannel: Notify the communication was closed.
The server component aims to provide data. It should get an access to data sources (through OPC, ODBC…) and be able to provide these data if its web services are invoked. Messaging server was implemented with a set of services design to offer several possibilities for a client to access the data. The messaging provides two ways of data access: • Punctually writing or reading: The server provides two web services Read() and Write() that can be called by the client to punctually write or read current values. •
•
Subscribing: Client can subscribe to some data in order to be notified if any of the attributes of this data changed. The corresponding web service is Subscribe(). If data changes are made, a notification is created and stored in a buffer. Each channel gets its own notification buffer.
Only some of the messaging server services may be used for a specific application, the others services are useless in this case. Whatever the kind of data access used, all the exchanges are made through a communication channel. This channel is the unique way to exchange data between one server and one client. It has to be opened and closed using dedicated services. Each communication channel gets also a watchdog module that checks the availability of the two partners and the connection between them. As soon as the channel is
412
client
that
a
At any changes of a data, for which a subscription was made, the server component creates a notification and store it in a notification buffer. This notification contains a node with the data new value and the subscription identifier. This identifier allows the client to know which subscription caused this notification. A unique notification identifier is also created in order to prevent that a notification are processed two times by the client. The notification buffer is a FIFO list. There is a unique FIFO list in each channel. Data transfers is configured using two kinds of parameters: •
Parameters specific to the messaging server - all the clients calling this server use these parameters. Name
Description
SSL
If true, exchanges are made with https protocol.
TailleMaxFifo
Maximum number of data change notification that can be stored in the list.
TimeOutNotification
Time out of the notify service. return
TimeToLive
Maximum duration a channel can stay opened
•
Parameters specific to a communication channel
specified at the opening of this one. Name WatchDogPeriod
MaxNumberOfFailures
Description Period of watchdog notifications. This value cannot be 0. Maximum number of Watchdog failure tolerated. If this value is reached, the channel is closed. Minimum delay between two notifications sending.
NotificationPeriod
MaxNumberOfNotifications
Generation schedules
TSO
To ease the reusing and maintenance of WSDL files, the business data model and the model of data peculiar to the messaging are separated. The business data model is described in separated XSD files. The WSDL files then import these schemas. Our SIMS protocol is very flexible and easy to implement and be deployed as it uses the underlying Web Services. Web services can be invoked using different standard Internet protocols like SMTP, HTTP/HTTPS, etc. These protocols are widely available and can easily be integrated in trading desktop application. In addition, WSDL (Web Services Description Language) offers a flexible way to describe services. The current version of our SIMS protocol offers the upcoming OPC-UA (OPen Connectivity-Unified Architecture) alike services such as periodic data access and event-based data access. It also provides mechanisms to monitor the QoS (Quality of Service) of the point-to-point communication link between each side of the association. III. HYDRAULIC POWER PLANT TELECONTROL USING SIMS The SIMS messaging was first used in SCADA application to telecontrol 15,000 MW [2] hydro power plants (four hundred seventy hydraulic plants and one hundred telecontroled plants) from four dispatching centres. A three levels telecontrol architecture was defined to ensure the robustness of the controlled systems. First level concerns power unit control or dam control, second level, called PA (poste asservi or plant local control), deals with power
TM, TS Telecontrol Network
PC
TM, TS
in Lyon Generation schedules, Command
Maximum number of notification in one sending
Persistency means that even in case of a long communication cut, the client can reopen a channel and gets back all its previous features (Parameters and subscriptions)
Grid Network
Generation schedules, Command
This parameter is essential to prevent malfunctioning in case of massive data changes.
If true, the channel must be persistent. Persistency
distribution among all power units. And the third level, called PC (poste de conduite or dispatching center) deals with control, modification and supervision of generation schedules. SIMS is used as the communication protocol between a PC and hundreds of PA. The main requirement in this application was not to lose data, especially in case of timeout during the transmission. Hard real-time is not necessary thanks to the three levels architecture (Fig. 2).
PA Units/Gates control
EDF Optimization Center Other Producers
3rd Level: Dispatching Center
PA 2nd Level: Plant local control Units/Gates st control
1 Level: Unit/Dam control
Fig. 2. Three levels telecontrol architecture [2]. The first prototype was developed in 2003. Testing results were so good that EDF hydraulic generation division has decided to industrialize it by EDF hydraulic engineering unit in 2004-2005. It was first deployed between the pump station in Revin and telecontrol center in Lyon (Fig. 3).
Messaging based on Web Services Revin
Lyon Fig. 3. Using SIMS to exchange data between a hydraulic power plant and a telecontrol center.
IV. USING SIMS MESSAGING WITH AN EAI The SIMS Messaging was also used with success in more complex architecture based on EAI (Enterprise Application Integration) as shown in figure 4. EDF-Direction Optimisation Amont Aval et Trading, who is in charge of power generation optimization, needed to build a new infrastructure to acquire real time power generation data for its intra-day activities, including the monitoring of its balance perimeter. EDF R&D, with the participation of other EDF Divisions (Optimisation and trading division and power generation division), was in charge of studying the technical feasibility of solutions to acquire real time power generation data from existing power plants infrastructure and the already installed Enterprise WAN (Wide Area Network). This requirement aims at minimizing the TCO (Total Costs of Ownership) of the future infrastructure. We chose to use an EAI to orchestrate data exchanges between the data producers
413
Client Internet Explorer
DB Web server
Web Services
Di sp
The overall architecture of our generation supervision is as followed (Fig. 4):
Fossil fuel power generation WEB PORTAL
la y
(power plants) and a data consumer application which is located in the optimisation and trading center.
FLEET SUPERVISION DB
re a
lt
im e
agregate, validate and transform
EAI
transform and validate
DB
Fossil fuel power plant
DB
Fossil fuel power plant
We bS ervi ces DB Fossil fuel power plant
Hydroelectric power plant
Fig. 4. EDF centralized generation supervision The main constrain for the messaging in this application was to support the transfer of lots of data with very short delay (about 2000 data points every ten minutes). Typical performance test scenarios are as followed: 1514 telemeasures every hour, 2566 telemeasures every 5 minutes, 876 telemeasures every 10 secondes, 1474 telesignals (binary values) every 8 minutes. For example, in terms of data volume, 180 telemeasures10sec take typically 60Kbytes. Testing results showed that this architecture fits our requirements and shows the ability of a SOAP messaging to exchange a big amount of data with soft real time performance. SIMS messaging was also used in a project aiming to fill a web portal with power generation data extract from several fossil fuel power plant information system. The web portal used by fossil fuel power plant community to exchange information had to be filled with real time data pushed from a data access and storage application installed in the power plants. In this architecture, exchanges are also orchestrated by the EAI, so the source and destination applications are passives. The EAI is used to aggregate some data (compute new values from several values) and to validate the received data.
414
e
es vic er S b
DB
real time
Nuclear power plant
EAI
industrial network
W
DB
industrial network
Fig. 4. Real time web portal using SIMS. V. CONCLUSION AND FUTURE WORKS Through the three examples of application, our SIMS protocol has shown its ability to perform industrial data exchange with soft real time constraints over the enterprise wide area network and dedicated IP telecontrol network. More results will be available in the next few months as we continue to run further performance testing with more scenarios over satellite and wireless network. Historic data access service is an add-on feature that we are currently implementing. By adding such feature, our SIMS protocol will be able to offer services, which are very close to the ones defined in the upcoming OPC-UA specification [3] [4]. With the availability of the new OPC-UA Message Oriented Middleware specifications, new perspectives for industrial messaging are expected in the next few years. This protocol offers a completely new system design based on a service oriented architecture (SOA). Its specifications define a base set of generic services to browse and query namespace, read/write data and publish/subscribe events and data changes. This new protocol blurs distinction between the former OPC protocols DA, HDA or A&E since all data, no matter of what type, are transferred using the same base UA services. OPC-UA reduces application development costs since all data can be handled in a standard way and is compatible with earlier OPC specifications As a web services based protocol UA use TCP/IP, HTTP, SOAP, and XML instead of the obsolescent DCOM technology so it can be filtered with Firewalls and is not tied solely to Microsoft platforms. It is expected to be implemented on everything from embedded field devices to Linux or mainframe-based enterprise applications. OPC-UA allows also for unlimited node types and unlimited
relationships and so ensures that there is no existing or future model that is too large to be exposed. The evolution of our SIMS protocol toward an opensource OPC-UA is a possible option that we plan in our roadmap. So we would like to welcome people interested in such development project. ACKNOWLEDGMENT We express our gratitude to our EDF hydraulic engineering colleagues for their fruitful discussion and their collaboration. REFERENCES [1].
[2]. [3]. [4]. [5].
[6].
Tuan Dang and Robert Chéramy, “Impacts of electricity market liberalization on centralized generation and telecontrol infrastructure”, INDIN’06, August 16th – 18th 2006, Singapore. Laurent Bacon and Cédric Bellec, “Making the most of hydropower through a cascade center”, EDF I2C2 Seminar, October 2006, Chatou, France. OPC Unified Architecture, Specification – Part 1: Concepts, Version 1.00, July 28th, 2006, http://www.opcfoundation.org/ Thomas Hadlich, “Providing device integration with OPC-UA”, INDIN’06, August 16th – 18th 2006, Singapore. Data Distribution Service for Real-time Systems Version 1.2 http://portals.omg.org/dds January 2007 Data Acquisition from Industrial Systems Version 1.1 http://www.omg.org/technology/documents/formal/dais.htm
June 2005
415
