An approach to build high-performance OPC-XML DA server system based on MONGODB and Comet

Xiaoping Dai Department of Computer Science Anhui University of Technology

Ma’anshan, China xpdai@ahut.edu.cn

Qiyu Xie Department of Computer Science Anhui University of Technology

Ma’anshan, China xieqiyu@gmail.com

Abstract—A simple implementation for OPC XML-DA has been achieved by the traditional XML-DA server. However, little has been attracted to the design and improvement of the capability. An OPC-XML DA server system of high performance is designed in this paper. We use .net asynchronous framework to design asynchronous subscription mechanism which is based on the Comet. New caching mechanism is designed by non-relational database such as MongoDB. Historical data storage is achieved based on the raw data compression method. Through a set of testing, we found that this system greatly improve the ability under high concurrency and high volume of data.

Keywords-high performance; opc-xml; asynchronous subscription; web service

I. INTRODUCTION Modern process control systems face increasing challenges,

and are required to integrate the different types of underlying control networks for different regions, to realize internet-based real-time management. But the data standards used in the control systems in the different area are not uniform, therefore, the control systems are difficult to be integrated. Using OPC (OLE for Process Control, Process Control Object Linking and Embedding) technology, these problems can be solved. However, OPC DA technology is based on COM/DCOM, and is deficient in cross-platform and connectivity. OPC XML-DA technology eliminates the OPC DA's defects. In this paper, we design XML-DA server system with new asynchronous subscription mechanism, caching mechanisms, and historical data storage mechanism. The system performs well with high concurrency and high volume of data.

II. OPC XML KEY TECHNOLOGIES

A. OPC XML Specification OPC Foundation released OPC XML-DA 1.0

specification[1] in July 2003, for the OPC data access to be described as a Web service[2]. XML-DA specification defines eight types of Web services, using XML-based SOAP protocol[3]. Table 1 describes the OPC XML-DA Web service.

B. The design of traditional OPC XML-DA servers

1) Subscription mechanism OPC XML-DA created a pseudo-callback mechanism

(pseudo-callback)[4],and it's basic services are Subscription,

SubscriptionPolledRefresh and SubscriptionCancel, and the basic operating mechanism is shown in Figure 1. As can be seen from Figure 1 that the pseudo callback mechanism is based on a query (polled-pull). In order to simulate a callback better, a high-level subscription mechanism[5] was also designed, the operating mechanism of that shown in Figure 2.

Figure 1. Basic subscription mechanism

Figure 2. Advanced Subscription Mechanism

Under the advanced subscription mechanism, the server immediately enter a Holdtime after receiving a request for a SubscriptionPolledRefresh, the Holdtime is used for waiting for data to change. Only after the Holdtime ending, if the value has changed the request is return to the client, so that the number of communications can be reduced. After the Holdtime, if there is no change in the value then enter the Waittime.During the Waittime, if there are changes in the value

This research is supported by Natural Science Foundation of AnHui Education Bureau of China. (No. KJ2009A007Z)

Hold Time Wait Time

minimum response time

maximum time for service to response

2881978-1-4244-8165-1/11/$26.00 ©2011 IEEE

items, it is sent immediately to the clients. In this mode, the clients don't need to poll, but still waiting. The setted minimum value of maximum waiting time is the server's maximum response time, while server will increase the burden of waiting.

2) Data Management Optimization When the clients request to the server, they and the server

enter a loosely coupled relationship. Clients can request that some of the properties are set to optimize the relationship between the server and the clients and increase server management data. These properties include:

RequestedSamplingRate EnableBuffering DeadBand

By RequestedSamplingRate property, the clients can recommend a suitable SamplingRate (sampling time) to server according to their refresh rate. In the case of multiple clients, by setting EnableBuffering property to true, the server can save all the changed values which are collected within the actual sampling time into one buffer,then sends to the clients according to the client sampling time, to avoid unnecessary data transmission.DeadBand attribute is used to determine if the value has changed, and only the values changed exceed DeadBand are taken as changed.

C. Traditional OPC XML-DA server's Architecture OPC XML-DA server's architechture[6] can be classified as

service monitoring module, the data processing modules, OPC DA interface module. Its functions are:

1) Service monitoring modules: Monitor OPC XML-DA client's SOAP request, receive data from data buffer; start the corresponding data processing module to process the received data, and publish the completed XML document through the HTTP protocol.

2) Data Management Optimization: Responsible for the interpretation of the received XML format SOAP message, and conversion between XML and OPC , and conversion between the data specification and service types of XML document and OPC interface protocol , and to complete the assembly , split, and resolution of XML documents and OPC data formats according to communication requirements.

3) OPC DA interface module: To achieve OPC DA client, and complete access to data on the underlying device. OPC client defines the transfer of information and access methods between the business layer and between OPC server, and complete data exchange with OPC server.

D. Flaws in traditional OPC XML-DA server Traditional design XML-DA server has two major flaws:

1) Subscription mechanism: OPC XML-DA subscription is the pseudo callback mechanism. The connection between client and server are low coupling, cross-platform, Non-permanent, and can not provide a callback mechanism. The subscription mechanism is still based on the client's repeated polling. Every time, in order to get data, the client needs to

repeat the procedure of requesting to establish a connection, waiting for data, closing the connection process.

2) Cache and history data storage rarely mentioned: For the caching mechanism, OPC XML protocol has only outlined a function of data cache, no mention of how to design caching mechanism and how to store. The storage of historical data is done by the relational database, but, the amount of XML-DA data per day grows in the level of GB, and relational database can not complete such a massive task of real-time data storage.

III. IMPROVEMENT AND IMPLEMENTATION OF OPC XML-DA SERVER

Regarding the traditional OPC XML-DA server design flaws, this paper made the following improvements:

1) Subscription mechanism: this paper designed asynchronous subscription mechanism based on .net, to release processing threads of the server-side in time and to achieve the long connection between client and server based on comet. In order to overcome the excessive background threads caused by long connecting, and excessive resource consumption, net interface is extended, therefore, the client request is no longer assign to thread directly, but is added to a thread queue in background thread pool through the hash algorithm, for a thread to service multiple requests.

2) Cache and history data storage: the non-relational database mongoDB is used to store real-time and historical data. Server subscribe for information to all lower nodes. The information is stored in the memory buffer, and updated when the node value changes. Historical data is compressed raw data, which stores only the updated node information.

B. Subscription mechanism OPC XML-DA uses a pseudo-callback mechanism. Call

back the subscribe process is expensive for the system and not very good to reduce the amount and frequency of data exchange. Combine .net platform features and Comet principle, this paper have achieved the server push subscription mechanism in web service, whose operating mechanism is shown in Figure 3.

Figure 3. Comet subscription mechanism

2882

In this mode, after the client subscribes to request, the server and client establish connection. The server find the data-update request then return the data immediately. If the data update still do not arrive when time out, then return time out mark to the client. After receives the timeout mark from the server, client automatically connect to the server. After the client cancels the subscription, the server stops the connection with the client.

With the asynchronous subscription, the requested data are returned only if the data is updated, therefore, the amount and frequency of data exchange are significantly reduced. And because that a reasonable timeout is set, connection times are less than traditional XML-DA subscription. However, when a high number of concurrent clients happening, because that the server is assigned a process for each request thread.

Therefore, we have achieved and expanded on .Net IAsyncHttpHandler interface based on asynchronous IO communication. The so-called asynchronous IO is that the thread which the server assigned can be released back to the thread pool to serve other requests. The request sended by the client is monitored by self-defined programme and processed in BeginProcessRequest method, and join this request to the thread queue, the thread handle their own requests in the queue circularly, then return the contents of the response to the client by the EndProcessRequest way. When a request reaches timeout, the thread will remove the request. The operating mechanism is shown in Figure 4.

Figure 4. .Net asynchronous HTTP connection mechanism

The key code is as follows:

public class CometAsyncHandler : IHttpAsyncHandler{

BeginProcessRequest(HttpContext ct, AsyncCallback cb, object extraData){

// Generate a an asynchronous return variable from context CometResult result = new CometResult(ct, cb, extraData);

// Add the request into a thread queue the thread pool

CometThreadPool.QueueRequest(new CometRequest(this));}

EndProcessRequest(IAsyncResult result){

// Write stream to the response and return to the client serializer.WriteObject(result..OutputStream,result.Response);

result.HttpContext.Response.End();}}

C. Cache and history data storage For high-performance XML-DA servers, the rational use

of caching mechanism will significantly improve system performance. In this paper, non-relational database mongoDB is used to build data module including cache and history data storage.

MongoDB[7] is an open sourced, storage-for-document database. MongoDB is easy to store data with object types, including documents-insert objects and number group, and suit for a large number of data to insert real-timely, update and query, and have the ability to copy and high scalability the application programme needed to do real-time data storage.

In this paper, buffer memory for real-time data is established, and all the node information is subscribed from OPC DA server through OPC DA client interface. For the first subscription, all node information saved as a document; later when the data is updated, the updated data is stored as a document ,therefore, the compression storage of raw data is achieved. The storage format of nodes is a Bson (Binary-encoded Serialization Object Notation) document, as shown in Figure 5.

Figure 5. mongoDB nodes information stored in the document

Data module handling mechanism shown in Figure 6: 1) When the client sends a request, mongoDB memory

buffer is searched. If there is no cache, OPC DA client subscribe all the node's information from the DA server.

2) If there is cache, the node information user requests is extracted from the cache and return.

3) Whenever the DA server push to send data the memory buffer is updated. At same time only the latest node information store as a document.

2883

Figure 6. Data processing module activity diagram

The key code is as follows:

Public class DataHelper {// Data processing class

Public Array GetData(list){

// Get the latest data of specified node

if(NodeInfoCacheHelper.GetCurrent()!=null) {

// If the memory buffer is not empty

return TransferData(NodeCacheHelper.GetCur(),list) }

// Extract request data from the buffer

else{

Array array = NodeInfoCacheHelper.BeginGetData();

// Start to subscribe all nodes and to return the latest data.

return TransferData(array,list);}}}

IV. INTEGRATION TEST

A. Test platform and the method The testing platform:

OPC DA SERVER: wincc server and Intel Pentium D CPU2.8GHz win2003 operating system

XML DA SERVER: Intel Pentium D CPU2.8GHz win2003 server operating system

CLIENT: Intel Pentium D CPU2.8GHz, winxp operating system

Test method:To perform 4 groups of reading and subscription, namely 1000 nodes / 30 requests, 1000 nodes / 300 requests, 50 nodes / 30 requests, 5000 nodes / 300 requests. The request frequency is 1s, server refresh rate is 1s. Read operation tests the fastest response time, the slowest response time, average response time. Subscription operation tests server resource consumption and the number of requests to be interrupted.

B. Test Results Test results are shown in Table 2. In the case of small

number of requests (30), with the number of nodes increasing from 1000 to 5000, no significant change happened in response time, and the response is quick. Therefore, it is confirmed that the increase in the number of nodes will not have much impact on both the traditional server and the new server, and they both have a good frequency response. But once a large number of concurrent requests (300) happen, the node number increases from 1000 to 5000, the traditional server, which has too many threads, will seriously slow down the response speed. When the performance dramatically change, there are many requests are interrupted. With the same conditions, the new server still

has fast response speed, no major change in performance and keep a more stable service. Test data prove that the new server has outstanding performance in a large data flow and high concurrency.

TABLE I. THE COMPARISON OF TEST RESULTS

Node / request

Server type

the fastest

response (ms)

the slowest

response (ms)

the average response

(ms)

the number of requests

being interrupted

1000/ 30

Traditional server

390 440 410 0

1000/ 30

new server 320 410 330 0

1000/ 300

Traditional server

480 800 640 30

1000/ 300

new server 370 500 440 2

5000/ 30

Traditional server

440 550 470 2

5000/ 30

new server 330 520 400 0

5000/ 300

Traditional server

470 900 760 40

5000/ 300

new server 550 650 600 3

V. SUMMARY OPC XML-DA standard is a current development trend

for OPC and is a good method to achieve long-range and cross-platform data exchange. In this paper, a high-performance OPC XML-DA server is built, which has achieved effective real-time management to the underlying control system, and improved the industrial on-site data access flexibility, and increased remote access to data from the on-site, and offered an effective solution for industrial real-time control. It has great significance for improving the on-site industrial management.

REFERENCES

[1] OPC Foundation.OPC XML-DA specification,version 1.01 [EB/OL].(2004-12-18). http://www.opcfoundation.org/DownloadFile.aspx?CM=3&RI=231&CN=KEY&CI=283&CU=20.

[2] Peng Jin,Wang Jin Biu, “A OPC Specification-- OPC XML-DA” metallurgical automation,vol. 28(1), pp. 6-9,2004.

[3] SHONNARD A. Understanding SOAP [EB/OL].[2009-12-20]. http://msdn.microsoft.com/en-us/library/ms995800.aspx.

[4] Yuan xiaofang, Wang dong, “Subscribe to the realization of the mechanism analysis in OPC” Computer Engineering and Applications, vol. 45(1), pp. 89-91,2009.

[5] Liu li, Wang wenhai., “Realize the remote OPC real-time monitoring of research and design based on XML-DA” Control and Instruments in Chemical Industry, vol.34(2), pp. 32-35, 2007.

[6] Kang lingyan Wang jinlin and Zuo zejun, “Process of information integration method based on the OPC-XML” Computer Engineering, vol.35(10), pp. 283-285, 2009.

[7] MongoDB. http://www.mongodb.org.

2884