11th International Conference on DEVELOPMENT AND APPLICATION SYSTEMS, Suceava, Romania, May 17-19, 2012
Introducing ACE in distributed systems for monitoring and process control Elisabeta TATULESCU, Vasile Gheorghita GAITAN, Andrei Valeriu SMOLENIC Simona Anda GHERASIM, Mihai Florentin URSULEANU “Stefan cel Mare” University, Department of Computers- Electronics - Automation Suceava, Romania
[email protected]
a standard that uses Component Object Model in application development. The result was OPC. The first OPC specifications [1] were defined in 1996 by a nonprofit organization called OPC Foundation comprised of technicians representing several renowned automation companies. The main goal of the OPC designers is to define a common interface to be defined once and reused by any type of device. The first OPC specifications, later known as OPC Data Access, include a range of solutions for problems that may occur in the automation field referring to data access, alarms and events, historical, XML, etc. Fig. 1 Overview of the OPC family [2]Fig. 1 shows the general architecture of the classical OPC specification.
Abstract— The OPC (OLE for Process Control) specifications have been defined to replace the original manufacturer specific drivers for SCADA (Supervisory Control and Data Acquisition) with a common interface defined a single time that can then be used by any device comprised in the SCADA system. To eliminate platform dependencies, OPC Foundation defined a new service-oriented specification called OPC UA (Unified Architecture). This paper proposes an alternative to OPC UA specification. This involves porting the classic OPC specification from DCOM to CORBA middleware. Keywords-ACE, CORBA, distributed systems, OPC, SCADA.
I.
INTRODUCTION
One of the biggest challenges in distributed systems is communication between objects situated on different platforms or written in different programming languages. This is the reason why OPC specifications have been defined, based on the DCOM standard (Distributed Components Object Model). This standard was developed by Microsoft to describe the object model required to implement applications in a distributed environment built on the client server principle. Another standard developed to guide and facilitate the integration of separately developed systems into a single heterogeneous distributed environment is CORBA (Common Object Request Broker Architecture), developed by a consortium of over 700 developers, called OMG (Object Management Group). This paper will present an opportunity to develop a server based on CORBA standard by adapting OPC Data Access specifications. Server-client communication will be achieved using TAO middleware (The ACE ORB) which is based on the templates contained in the ACE framework (ADAPTIVE Communication Environment). II.
Fig. 1 Overview of the OPC family [2]
According to the OPC standard, client-server communication is the basis of the whole system [2]. Client applications are not directly involved in the management of devices but are controlled by server applications using standard interfaces. However, the platform dependency and inability to pass the firewall provoked criticism directed to the OPC technology [3]. Also, high response times, vague messages for connection interruptions and the need to disable security measures during the setup of DCOM standard, have been criticized by OPC users. For these reasons, the OPC Foundation introduced the OPC UA (Unified Architecture) specification, a serviceoriented and platform independent specifications, to provide new opportunities for communication with Linux / UNIX systems and to allow implementation of OPC technology over the Internet [4]. This completes the OPC classical standard [5] offering new features such as a unified address space, abstract functions to allow communication between objects on different platforms, etc. Thus, the UA specification [6] meets all the requirements of a platform-
OPC
Before OPC (OLE for Process Control), manufacturers of automation equipment were developing a custom interface and a control system for each of their products to allow realtime data acquisition. The problem of developing their own interfaces is that users had to rewrite the code for communication with different devices, because each device used a different API. For this purpose, Microsoft introduced the OLE (Object Linking and Embedding), COM and DCOM (Distributed COM) technologies. With these technologies, software applications can interact with distributed modules. Thus, manufacturers of automation hardware and software have formed an organization to define
79
11th International Conference on DEVELOPMENT AND APPLICATION SYSTEMS, Suceava, Romania, May 17-19, 2012 independent interface, scalable from embedded systems to SCADA, DCS, MES and ERP systems. Another OPC specification, called OPC.NET 3.0 (WCF), solves DCOM related problems, but still remains dependent on Microsoft's WCF technology, so Windows operating system is still required. III.
middleware, was proposed by [9]. The main requirements on which this model was built are: To be SCADA oriented in order to enable data acquisition; To support a wide range of heterogeneous distributed systems; To be scalability; To be based on existing technologies and to be able to adapt to newer technologies.
ACE
Because software systems have become more complex [7], software developers have turned their research to find ways to facilitate the development of these applications. A solution found by them refers to patterns and frameworks. ADAPTIVE Communication Environment (ACE) [8] is a set of open source tools containing a comprehensive range of wrappers, reusable classes and frameworks by which we can achieve common network programming tasks on different platforms. The ACE development environment was written in C++ and includes several components that simplify the development of network applications, thereby increasing efficiency, safety, flexibility and portability. ACE features network programming capabilities such as: concurrency and synchronization, memory management, inter process communication (IPC), timers, thread management, connection establishment and service initialization, distributed communication services - logging service, naming service, time synchronization and event handling. The ACE architecture was designed using a layered model, presented in Fig. 2. The bottom layers are represented by the wrappers encapsulating the mechanisms of the existing operating systems (processes, streams, virtual memory). On the upper levels are located the classes and frameworks that extend the wrappers from the bottom layers and together they form the patterns that are to be used in implementing the applications. Using the ACE components, the designers have developed a real-time implementation of the CORBA standard (Common Object Request Broker Architecture) called TAO (The ACE ORB). The ORB core of the TAO architecture uses a multithreading and priority-based connection, thus providing a very effective Inter-ORB communication protocol.
The general system architecture is presented in Error! Reference source not found. 3. As can be seen, the proposed model includes three main components. These are the application's server, the client, and the middleware bus used for client-server communication. Communication [10] is achieved using a component composed of an acquisition module that will define the object dictionary, and a communication module that contains the custom communication drivers of each device on the network. An implementation example of the architecture presented in Fig. 3 is the data server application, which is a modular application designed and implemented on the OPC specifications. The modules comprising this application are: The data server. Its role is to create and manage the OPC DCOM objects, to manage the application's GUI, to expose data to clients and receive data from them, and to interface with the communication component; The communication component. It manages the acquisition modules and stores in a buffer the data acquired from devices. The server then reads this data and makes it available to clients. Also the communication component allows the configuration of the industrial networks (acquisition rates, device detection, individual device configuration) and interfaces with the acquisition modules; The acquisition modules. Their role is to communicate with the network devices (read data from devices, send the data to the communication component), to configure the network parameters and to detect the potential communication errors. Data flow through the network occurs as follows: the acquisition modules read data from the devices and send the data to the communication component, which stores the data in a buffer (cache memory) called object dictionary. The OPC clients will connect to the data server and will create item groups (items represented by device data, device information, etc.) and will update them at certain time intervals. At each update, the required data will be transferred from the communication component's cache memory (the object dictionary) to the client.
Fig. 2 The ACE components [8]
IV.
ARCHITECTURAL MODEL OF THE SCADA SYSTEM
A generalized architectural model of a heterogeneous system oriented towards SCADA applications, based on
80
11th International Conference on DEVELOPMENT AND APPLICATION SYSTEMS, Suceava, Romania, May 17-19, 2012
Fig. 3 General architecture of the proposed model [9]
V.
necessary for the client to navigate the server's address space to view the available items, and the methods necessary for creating and managing groups out of the available items. To exemplify the parameter adaptation from DCOM standard to CORBA, we selected the function that allows clients to add a group in an already created list of groups. The method defined in the OPC DA specifications is a part of the IOPCServer interface and is described below:
MAPPING THE IDL FILES
To demonstrate the portability of the OPC DA specifications from DCOM to CORBA, a data server will be developed based on the OPC specifications adapted to the architectural model presented in section IV. Although both DCOM and CORBA middleware describe interfaces that can be accessed by clients through an interface description language (IDL), the definitions found in the DCOM IDL files use the data types of the C programming language, while in CORBA IDL files are used only data types that are common to many programming languages. This enhances interoperability between objects written in different programming languages. Firstly, in order to obtain the files necessary in the servant implementation, the IDL file will be compiled using the TAO_IDL compiler, a real-time implementation of the CORBA standard based on the ACE components presented in section III.
HRESULT AddGroup( [in, string] LPCWSTR szName, [in] BOOL bActive, [in] DWORD dwRequestedUpdateRate, [in] OPCHANDLE hClientGroup, [unique,in] LONG * pTimeBias, [unique,in]FLOAT * pPercentDeadband, [in] DWORD dwLCID, [out] OPCHANDLE * phServerGroup, [out] DWORD * pRevisedUpdateRate, [in] REFIID riid, [out,iid_is(riid)] LPUNKNOWN * ppUnk );
The IDL file contains the object's interface and the functions that can be called by the client. This section will describe the parameter adaptation of some data server specific functions contained in the OPC DA specifications, from DCOM standard to CORBA. The methods for which the mapping is done are: the methods
According to the OPC DA specifications, the parameters passed to the AddGroup function are described as follows: szName – the name of the group as a string;
81
11th International Conference on DEVELOPMENT AND APPLICATION SYSTEMS, Suceava, Romania, May 17-19, 2012
based on the CORBA specification, using the ACE components offers several benefits to distributed software developers, such as increased portability, the ability to pass through the firewall, reusable patterns and components, etc. The development of the data server presented in section V will continue with the servant implementation and performing some comparative tests between the DCOM data server model described in section IV and the CORBA data server model. Future work will include porting the data server to the MICO framework.
bActive – a boolean type parameter that specifies if the created group will be active, TRUE or FALSE; dwRequestedUpdateRate – parameter by which the client specifies to the server the update rate of the items that will be added later to the group; hClientGroup - the group's identifier within the client; pTimeBias – a pointer to the time in the area in which the data was aquired; pPercentDeadband – a percentage specifying how much an item needs to modify its value in order to be sent to the client using a callback mechanism; dwLCID – a DCOM specific parameter specifying the language used by the server to return values; riid – a DCOM specific parameter that states the desired interface type; ppUnk – a DCOM IDL specific pointer that holds the pointer to the returned interface. To define the AddGroup function in a CORBA specific manner, the DCOM specific parameters have been replaced and data types of the parameters have been adapted. The definition of the adapted method is presented below:
VII. ACKNOWLEDGEMENT This paper was supported by the project "Improvement of the doctoral studies quality in engineering science for development of the knowledge based society-QDOC" contract no. POSDRU/107/1.5/S/78534, project co-funded by the European Social Fund through the Sectorial Operational Program Human Resources 2007-2013.
VIII. REFERENCES
long AddGroup( in string szName, in boolean bActive, in long dwRequestedUpdateRate, in long hClientGroup, in ::CORBA::LongSeq pTimeBias, in ::CORBA::LongSeq pPercentDeadband, out ::CORBA::LongSeq phServerGroup, out ::CORBA::LongSeqpRevisedUpdateRate );
[1]
X. Hong, W. Jianhua, „Using standard components in automation industry: A study on OPC Specification,” Computer Standards & Interfaces 28, pp. 386 - 395 , 2006. [2] C. Sahin, E. D. Bolat, „Developement of remote control and monitoring of web - based distributed OPC system,” Computer Standard & Interfaces 31, pp. 984 - 993, 2009. [3] S. Cavalieri, G. Cutuli, S. Monteleone, „Evaluating Impact of Security on OPC UA Performance,” Human System Interactions, pp. 687 - 694, 2010. [4] S. Cavalieri, G. Cutuli, „Performance Evaluation of OPC UA,” Emerging Technologies and Factory Automation, pp. 1 - 8, 2010. [5] L. Huiming, Y. Zhifeng, „Research on Key Technology of the Address Space for OPC UA Server,” Advanced Computer Control, pp. 278 - 281, 2010. [6] A. Gîrbea, R. Demeter, F. Sisak, „Automatic address space generation for an OPC UA server of a flexible manufacturing system,” 6th IEEE International Symposium on Applied Computational Intelligence and Informatics, pp. 483 - 488, 2011. [7] S. M. YACOUB, H. H. AMMAR, Pattern-Oriented Analysis and Design: Composing Patterns to Design Software Systems, Addison Wesley, 2003. [8] D. C. Schmidt, „The ADAPTIVE Communication Environment An Object - Oriented Network Programming Toolkit for Developing Communication Software,” CONFERENCE, pp. 214--225, 1993. [9] N. C. Gaitan, V. G. Gaitan, St. Ghe. Pentiuc, I. Ungurean, E. Dodiu, „Middleware Based Model of Heterogeneus Systems for SCADA Distributed Applications,” Advances in Electricl and Computer Engineering, pp. 121 - 124, 2010. [10] V. G. Gaitan, V. Popa, C. Turcu, N. C. Gaitan, I. Ungurean, „The Uniform Engineering of Distributed Control Systems Using the OPC Specification,” vol. 8, 2008.
Because CORBA IDL doesn't allow pointers, they have been mapped using sequences. Thus, the expression “::CORBA::LongSeq” is mapped to an array of long elements. To use these sequences, pseudoIDL files have been included, files defined in the ACE_ROOT package. For the AddGroup function we need a pointer to the long data type, so, at the top of the IDL file we will include the pseudoIDL file that defines a long sequence as follows: #include "../ACE_ROOT/TAO/tao/LongSeq.pidl"
Similarly, the other IDL interface functions can be adapted from DCOM to CORBA. Of course, this adaptation implies rewriting the methods using patterns available in ACE. VI.
CONCLUSIONS
Introducing the ACE programming environment in distributed systems for monitoring and process control offers a new solution in data server development. Because it is
82
