Scalability Research of Web Scada Systems
Zeng Mingchang, Chen Zhijin
(Chengdu Ruike Electric Co., Ltd., Chengdu, Sichuan 610043)
Abstract : This paper addresses the challenge of better adapting to changes in user scale within Web Scada systems. It analyzes the limitations of existing implementations in building scalable systems and proposes a solution based on WCF technology to create a scalable Web Scada system. The core of the system adopts a service-oriented SOA architecture, pushing or fetching various data from data collection terminals of users of different sizes, and publicly distributing data access and push interfaces. The system enables web clients to respond to push services or query collected data, displaying the data on a monitoring page.
Keywords : Web Scada system; scalable; monitoring page; service-oriented; WCF
Research of Flexibility of Web Scada System
Web-based Scada systems not only improve the adaptability and reliability of Scada systems, but also make the management and maintenance of Scada systems simpler and more convenient, and have become the de facto standard of Scada systems in China. From the homogeneous platform based on DCOM and ActiveX technology on the Windows platform, to CGI/PHP, and then to the heterogeneous platform of SOAP and SOA, it involves Web data publishing technology, real-time graphics generation and processing, real-time client graphics refresh technology, remote operation image hotspot processing technology, system management and security technology, etc. [2] . Due to the characteristics of Scada systems, it is necessary to handle the data acquisition of remote communication devices with varying numbers of devices. Due to the limitations of current data acquisition technology, the data acquisition source points may vary greatly, which brings scalability requirements to Web data publishing. It can be said that whether or not it has scalability is the foundation for Web Scada systems to enter large-scale engineering applications. Many other technologies must be built on its foundation to have practical significance. The layered design of Web Scada systems is as follows [3] :
The key to building a scalable Web Scada system is to have the monitoring logic layer handle the complex and ever-changing communication layer changes and provide a stable data source for the interface layer.
This paper aims to develop a practical Web Scada system, utilizing .NET Framework 4.0, VS2010, IIS, and HTML technologies to build a scalable Web Scada system. The core of this system is the establishment of a monitoring logic layer situated between the communication layer and the user interface layer. This layer enables scalable connections with the communication layer and stable connections with the Web interface layer.
I. Existing Web Scada System Model
Existing Web Scada systems primarily aim to present collected data on the web, with their main function being to display the data collected from the communication layer within web pages. Due to varying user scales, numerous Web Scada systems have emerged, but they generally fall into one of two categories:
1. Distributed Web Scada System (hereinafter referred to as Distributed System)
The system has multiple servers that handle remote device (RTU) data acquisition at different intervals, forming a distributed network database. Users can connect to different servers as needed to monitor their connected remote devices. This architecture includes a web server. It can add more servers to meet the scalability requirements of different user groups, as shown in Figure 2.
2. Centralized Web Scada System (hereinafter referred to as the centralized system)
The system uses a single server to handle data collection from remote devices (RTUs) within a given interval. This forms a centralized network database, allowing users to monitor their connected remote devices. This architecture includes a web server. It can accommodate varying user scale by adding more remote devices and using better servers to meet scalability requirements, as shown in Figure 3 above.
II. Scalable Web Scada System Mode
The two system models described above each have their own advantages and disadvantages when solving practical problems.
The advantage of a distributed system is that the number of servers can be expanded to meet the needs of a larger user base. It is suitable for situations with a large user base. The disadvantages are: if the client pull method is used [2], it is necessary to query periodically even when there is no updated data, resulting in high network traffic; if the server push method is used [2] , the number of clients is limited because the connection channel needs to be maintained. At the same time, if the data of multiple servers is to be monitored at the same time, the servers need to establish corresponding connections, which will destroy the independence between the servers and greatly increase the cost of expansion.
Centralized systems obviously do not have these drawbacks of distributed systems. Their advantages include: simple structure, unified data management, simple and stable web page design, and low page refresh latency. However, their disadvantages are also obvious: limited scalability; to add data from remote devices, the only solution is to improve server performance. They are only suitable for situations with a small user base.
When developing our Web Scada system, we set the following goals:
Stable interface layer
Flexible to different user sizes
Because our users are distributed across various industries with significantly different levels of automation, our goal is to minimize development and maintenance costs. The system structure is shown in Figure 4 below:
Comparing it to a distributed system architecture, we can see that the Web Server is no longer included. It adds a Web Server for publishing web pages, a data server for data management, a file transfer server for file management, and so on (in our actual system, it also includes an event management server, a password management server, a data forwarding server, etc.). Because it is configured according to the required functions, it is scalable. For example, to add an event SMS alarm function, an SMS alarm server can be added to the network.
In terms of scalability for user scale, the Web Scada Server, data server (historical data, real-time data), file transfer server, event management server, password management server, data forwarding server, and other servers are all configurable and automatically loaded, allowing for online switching.
In terms of implementation, each server exposes a WCF interface and is developed according to the SOA architecture. Each service is configurable (binding, endpoint), facilitating flexible deployment in complex networks. Furthermore, the data forwarding server can add, modify, and delete forwarding instances, laying the foundation for scalable user scale. The deployment structure is shown in Figure 5.
III. Implementation of Key Technologies
1. Flexible data forwarding
We know that the number of remote communication devices varies depending on the user base. To establish a stable data source for the interface layer, we need to build a server that processes all similar data in the system. Then, we need to submit all relevant data to this server for processing and web data publishing. Taking historical data processing as an example, its software structure is shown in Figure 6 below:
In this way, by configuring a corresponding number of historical data forwarders in the system for multiple communication servers (corresponding to different user scales), we can adapt to the expansion and change of the number of users' remote communication devices. The number of running instances of the historical data forwarder is automatically generated according to the configuration file. Moreover, it must be automatically loaded after the server system starts up and monitored during operation.
2. Data server push
As shown in Figure 1, the monitoring logic layer publishes data to the interface layer, which is the basis for the interface layer to present the collected data to the user. Since we adopt the SOA architecture and the module connection adopts the WCF interface, we can easily implement server data push by establishing a bidirectional channel [1] .
As shown in Figure 7, after the real-time data forwarder obtains real-time data from the communication server, it stores the real-time data in the real-time data access server. When the real-time data access server detects a change in the data, it uses the callback channel established in advance between the real-time monitoring screen and the real-time data access server to push the real-time data to the real-time monitoring screen. In WCF technology, TCP channels are generally used because they are connection-oriented, while HTTP channels are stateless and not suitable for bidirectional channels. Of course, there are also bidirectional HTTP channels, but the callback is subject to some limitations because it requires specifying the well-known port of the callback [4] . The specific implementation interface is as follows:
public interface IPushCallback
{
///
/// Data push callback interface, a one-way operation used to notify the client that there is data to push.
///
/// type
/// Site Name
/// Unit Name
/// Data Fields
/// Data Values
[OperationContract(IsOneWay = true)]
void PushData(string type, string station, List strUnit, List strField,
List fValue);
}
The type indicates whether it is telemetry, remote signaling, or electricity measurement; the site name indicates the communication server; the unit name is the remote communication unit under the communication server; and the data field is the unique identifier name of the data volume under each unit.
On the client side, monitor the webpage response callback function, similar to the following:
void back_callback(string type, string station, string[] strUnit, string[] strField, float[] fValue)
{
for (int i = 0; i < strField.Length; i++)
{
switch (type)
{
case "YC":
myCAnalog analog = dtmng.getdata(station, strUnit[i], strField[i]) as myCAnalog;
analog.Fresh(fValue[i]);
break
case "YX":
myCDigital digital = dtmng.getdata(station, strUnit[i], strField[i]) as myCDigital;
digital.Fresh(fValue[i] ==0 ? (byte)0:(byte)1);
break
case "DD":
myCAccumulate accumulate = dtmng.getdata(station, strUnit[i], strField[i]) as myCAccumulate;
accumulate.Fresh(fValue[i]);
break
}
}
… …
}
IV. Conclusion
By adopting a service-oriented system architecture, we can combine the advantages of distributed and centralized models in Web Scada systems to form a scalable Web Scada system. This system consists of a simple data communication server, data management server, file transfer server, password management server, etc. It integrates the advantages of centralized and distributed systems. Since the communication server is responsible for data communication with remote devices, its flexible deployment and configuration can adapt to the needs of users of different sizes. Similarly, the flexible deployment of various functional servers can adapt to different user functional requirements, thus forming a scalable Web Scada system. In the future, we will also develop dedicated functional servers for single-force systems, such as multi-level hot backup functions, fault recording and analysis servers, power flow analysis servers, harmonic analysis servers, and data preprocessing systems.
About the author:
Zeng Mingchang (1966- ) Male, from Deyang, Sichuan Province. Undergraduate research interests: WCF applications, SOA, network data management.
Chen Zhijin (1988- ) Male, from Neijiang, Sichuan Province. Postgraduate research interests: configuration software, ARM.
Zeng Mingchang, Yinhe West Road, High-tech West Zone, Chengdu, Sichuan Province, 610041, [email protected], 13281246733
