Improving industrial application’s performances with an Historian Aline FRAS, Tuan DANG EDF Research and Development Performance Optimization of Industrial Process Department, Industrial Informatics Lab. 6, quai Watier, BP 49, 78401 Chatou Cedex, France Phone : 33-1 30 87 79 18, Fax : 33-1 30 87 82 61 Email : [email protected], [email protected]

Abstract- The Centralized Power Generation Optimization Center of EDF uses several applications dealing with real time data from power generating stations and consummation trends. Helicooptere is the application that acquires real time power generation data from all the EDF nuclear, conventional thermal and hydraulic power plans. The particularity is that these data are first acquired by the Transmission System Operator, who retransmits them to Helicooptere using TASE.2 protocol. Helicooptere was developed on a specific EDF solution to response to immediate needs. After 4 years of utilization, we noted an inadequate level of performance of the application, mainly due to the increasing number of web based clients and an untimely redundancy of the database Moreover, the maintenance costs are getting higher than initially foreseen and the application can’t cope with the rapid evolutions of the user needs. Our work’s objective was to propose several solutions for rebuilding Helicooptere with MES based data Historian software. We made two testing models based on two data Historians leaders: IP21 (by Aspentech) and PI (by OSIsoft). Their abilities to integrate the three stages (Acquisition task, Application logic and data Publication), to interpret timestamps, to support multiple acquisition protocols, to support complex data models, and to propose a high availability and secured architecture, make the testing models so conclusive that EDF decided to rebuild Helicooptere with a data Historian. Key Words: Historian, TASE.2, OPC, CIM, High Availability, Redundancy.

1

Introduction

In 1999 the decision to separate EDF (Electricity of France) from its Transmission System Operator1 (TSO) was taken following the EC directive to liberalize the European electricity market. Historically the TSO owned the entire infrastructure to get the power data from all the Generating Units. Following the separation, EDF Centralized Power Generation Optimization Center 1

Now called RTE.

(CPGOC) was created and became in charge of its power production optimization, and so needed to acquire real time power generation data. The application, named Helicooptere was developed in order to get the data back from the TSO application. EDF properties

Generating Units

TSO properties

TSO application

EDF properties

Helicooptere

Real time power system data

EDF Research and Development Division (RDD) realized a prototype of Helicooptere on a specific solution in one year. Because of the CPGOC pressing need, the prototype was deployed as it was. After 4 years of utilization we noted an inadequate level of performance, intensified by a changing context: the number of web-based clients has increased by 300% and users needs have changed. Moreover, the current context of deregulated electricity market emphasises the vital function of this application. Faced to this established fact, EDF RDD proposed two solutions, one specific (redimensioning of the existing application), the other consisted in rebuilding Helicooptere with a MES (Manufacturing Executive System) based on data Historian software. RDD realized two testing models with two data Historians leaders of the market, IP21 (AspenTech) and PI (OSIsoft), and also analysed the costs and the delivery time of both solutions. Finally, with the obtained results, CPGOC decided to rebuild Helicooptere with a data Historian software. In this paper, we will present the specific requirements of Helicooptere, a quick overview of data Historian software, the methodology and the technical results of the testing models, the reason of the choice between both tested and the benefits of the solution.

2 Why rebuilding Helicooptere with a data Historian?

The specific solution of Helicooptere was developed in 1999 on the purpose to allow users at the GPGOC to monitor in real time the power production data from all the Generating Units, and then identify (with help of alarms) any difference with the daily generation schedule. The following layout (figure 1) represents a simplified view of the specific solution architecture before rebuilding. Generating Units TSO Information System

P2TR

Power TM,TS System Dispatching

ICCPNT

TASE.2

Oracle

TASE.2

CPGOC IS: HELICOOPTERE ICCPNT Master

Oracle

SQLnet

Oracle

ICCPNT Slave

Replication WebObject HTTP Server WebClients

Fig. 1: Helicooptere’s architecture before rebuilding

This architecture was based on a master ICCPNT server and a slave one, which didn’t work at the same time, but switched from one to the other as soon as a broken TASE.2 communication was detected. The replication of the two Oracle databases was triggered by the switching event. After 4 years of utilization, the requirements of Helicooptere in terms of functionalities and quality of service had increased as new rules and performance contract agreements were introduced in the electricity market. Moreover, the balance between the maintenance tasks and the functional evolutions of Helicooptere was more and more difficult and costly. • The needs of new functionalities The deregulated market context brings new process which need to be taken into account by Helicooptere: modification of the data computation algorithms, new data model based on the CIM (Common Information Model), modifications of the

user interface, and in the medium term a new way to acquire data directly form the Generating Units. All the modifications could not be realized on the former Helicooptere without important developments and major changes in its architecture. The underlying effort of development was estimated at 2 men-year work. • Better quality of service needed This application was a prototype that had been designed initially for few users. The performance of the user request strongly depended on the number of simultaneous client connections and the volume of the data required. Moreover we noted untimely replication of the Oracle databases, which was due to the lost of the TASE.2 link. Of course, each time the replication occurs, it penalizes the performance of Helicooptere. • Maintenance too costly The maintenance required 3 full time persons, one for the software, the two others for the functional support. Those 3 reasons lead CPGOC to ask RDD to study an alternative solution for rebuilding Helicooptere with a more robust and expandable architecture. After analysing the technologies that were available on the market, we proposed to carry out testing and evaluation with data Historians.

3

Data Historian overview

Historian software is presented as Enterprise Operations Management software or as a kind of Manufacturing Execution System. Their objective is to integrate real time process data (possibly transformed) with other more or less complex data from the enterprise Information System. The aggregate data can then be published to different users inside the company (workshop, engineering centre, managers…). Historians are a kind of real time database technology that is particularly well suited to manage efficiently huge volume of time stamped data. The following figure (figure 2) shows a typical functional architecture of a Historian. Historian Web Server Historian Kernel Server Real Time Database

Interface Node

Historian Calculation Module Historian Clients Module

Interface Node

Fig.2: Simplified view of Historian architecture

Interface Node is a kind of “device driver” which is used to acquire data from systems such as PLC, DCS, RDBMS (via ODBC) and SCADA (via OPC), etc. The real time database is typically designed to be able to acquire about 50000 data points per second. Moreover, the database can be shaped with a more complex conceptual data model such as CIM (IEC TC57). Native interpretation of timestamps makes the time to answer to a user request or a treatment be almost independent of the database volume. Thus, users can work on large historical data (10 years period for example) without any performance deterioration. Most of the available products on the market are based on a 3-tier architecture: acquisition, data management server and client which is in charge of the presentation of data, receiving user events and controlling the user interface. In terms of market share, Aspentech and OSIsoft are two leaders of this technology. Other contenders are Wonderware with Industrial SQL, Siemens AD with SIMATIC IT Historian, Automsoft with RAPID Base, GE Fanuc with Proficy Historian, etc. It is worth pointing out that these products are only available on Windows platform. Product like Cascade Historian (Cogent RealTime Systems Inc.) is the one that is available on Linux, QNX and Windows.

4

• • •

5

•

Acquisition: the purpose is to test the flexibility of the product to support common industrial communication protocols, and to be able to acquire huge volume of data sets. Our incoming data set is composed of 2000 analog tags (a tag is composed of 4 elements [name, timestamp, value, quality]) very 15 minutes and 2000*3*48 data points each 24hrs corresponding to the next day power generation schedule received from the CPGOC and the TSO.

•

Database model: how well is the product able to integrate complex data model over time-sequence data sets derived from process data? Our Helicooptere data model is formalized in UML (Unified Modelling Language) and is composed of 10 object classes (Measure, PointofMeasure, Alarm, etc) with static and dynamic attributes. Computation: the purpose is to test the ability of the product to perform complex calculation models (periodically and on events) on process data. We program cyclic calculations on received power data state and “on events” treatments (for example: invaliding of incoming values or alarms).

Client-tier tools: we want to know the flexibility and the performance of the client toolkit. Availability: how does the product support redundancy and high availability in its architecture? IT Security: how well is the product able to cope with company IT security rules? Administration: the purpose is to evaluate the administration and configuration toolkit, and the ability to integrate enterprise information system monitoring toolkit.

The technical results

The evaluation process took 2 weeks work with some help from Coris (Aspentech’s distributor in Europe) and OSIsoft. The product version we used was: V5 SP1 for IP21 and V3.3 for PI •

Acquisition None of the products supports directly TASE.2 protocol. However, they both propose an OPC interface. To resolve this issue, we used an OPC/TASE.2 gateway available from SISCO. The configuration of this gateway and the interface Node were somewhat laborious but ended up working without any loss of data.

•

Database model The particularity of IP21 database (mixed of object and relational) make this Historian handle our Helicooptere model for the best compared to the other product. With the help of Coris, a tool is developed to automatically configure the database model and static attributes from an Excel data file. PI data management server tier is composed of two databases, one is devoted to real time tags and the other is devoted to additional information storage. The two databases are linked as an alias using a proprietary technology. However, in the version OSIsoft provided us for the test, the information database was unable to handle directly the data model we required.

•

Calculation Both products are able to manage complex calculation, but we realize calculation configuration faster and simpler with IP21 thanks to their SQL+ module. Moreover in IP21, treatment configuration is in the database, as any other variable, so that the period of the cycle or the variable concerned can be easily changed.

•

Clients tools Helicooptere users are using web-based clients to monitor the power generation. The user interface is particularly supercharged with multiple colour and dynamic graphics, tags searching tool, alarms blinking with sound, etc. Both products are

Methodology and testing models

To evaluate the two pre-selected products, we have decided to analyze their features according to the following criteria:

•

•

theoretically able to handle that, but in 2 weeks, only Coris was able to develop satisfying web pages on IP21. Concerning the client performance, both need around 4sec to bring back 100000 events in a JSP (Java Server Page) request. Moreover, the data are exportable in Excel and XML format.

6 The new Historian

architecture

based

on

a

Following our testing results, CPGOC has decided to rebuild Helicooptere with IP21. The following architecture was then chosen for Helicooptere for high availability. Other applications

Web clients

LDAP

EAI

Https

LAN Web21 / IIS

Web21 / IIS IP21 SERVER

IP21 SERVER

Shared disk

CIM/IO Change Over

CIM/IO Change Over

LAN

Fig.3: Example of a client web page on the IP21 model CIM/IO server for OPC

•

•

•

Availability Both products propose to use clustering technique to provide high availability. More precisely, it is necessary to deploy a Windows cluster infrastructure to run the kernel server. Concerning the acquisition node in OPC, IP21 offers an automatic redundant interface (piloted by the kernel server). Moreover, each IP21 interface node owns an internal database, which can store and forward acquired data in case of broken communication link with the kernel server. Security Both Historian offer connections filter (especially PI) and rules of accessing data. Both are also able to use an LDAP server for authenticating users. However, the security mechanism of these two Historians lies mostly on the Windows services, especially for IP21. The communication between different modules of IP21 use dynamic TCP port. Whereas PI’s modules always use the same TCP port that is more suitable for firewall architecture.

Exploitation Helicooptere server is exploited through administration tools such as PATROL (from BMC). None of the products is natively connectable to this IT monitoring infrastructure. However, they offer other administration tools. But it seems possible to develop a portion of code to send control information from Historians to a PATROL server. We have chosen not to test further this possibility in the model. During our test, all from all, IP21 model was more conclusive than the PI one.

CIM/IO server for OPC Store&Forward

Store&Forward OPC/TASE.2 gateway

P2TR Server (RTE)

Natural flow Rescue flow

Fig.4: Simple view of Helicooptere’s new architecture

7

Conclusion and future works

Currently, the rebuilding phase is being achieved. Users are testing new web pages interface and the deployment is expected in November. Yet, we are already working on the next specification version: migrating the existing data model through a CIM-EDF model and replace the existing way to acquire data. Indeed, our centralized supervisory of power generation project aims to provide CPGOC with real time power generation data from all the generating units without using the TSO infrastructure. Thanks to the very flexible Historian architecture, this operation will only consist of changing the acquisition interface on Helicooptere. Thus, we can preserve the existing investment on development. All from all, the lesson we have learnt is that such Historian technology is also suitable for SCADA application. We bet that in a near future, the SCADA software world and the data Historian world will become closer and closer as the users need will be increasing on online data analysis of long historical time period.