Archiving and providing access to process variables ...

4 downloads 1001 Views 578KB Size Report
Key words: monitoring, mySQL, agent. 1. Introduction. This paper ... host – controlling device communication (in our example the CQM1 PLC),. √ write in the ...
ARCHIVING AND PROVIDING ACCESS TO PROCESS VARIABLES USING THE WEB Stanisław FLAGA AGH University of Science and Technology, Department of Process Control, Al. Mickiewicza 30, 30-059 Kracow, Poland, [email protected]

Abstract: the paper describes a system for archiving and providing access to process variables; its demo version (the internet part) is available on-line at address http://www.plclab.agh.edu.pl/oa/. The full version requires an agent to communicate with the controlling device. A demo version of the agent compatible with selected Omron controllers is available at http://galaxy.uci.agh.edu.pl/~flaga_st. The demo agent supports 1 word from the DM area and can save history data only in the test base called DBOmron available at 149.156.106.108. Key words: monitoring, mySQL, agent 1.

Introduction.

This paper presents a way to execute a project with the objective of collecting data on the process being monitored and of making it available on the Internet, and at the same time equipping the user with the possibility to create new monitoring tasks. The system works with selected controllers of the C family PLCs by Omron. The paper presents the consecutive steps, from the design to selection of tools, to presentation of a ready solution. The design, as presented in more detail hereinafter, is divided in to parts: √ local, responsible for direct communication with the controlling device (in this case a CQM1 PLC) in accordance with the parameters sampled from the monitoring queue and for saving the process variables in the database, √ internet part, enabling the creation of new monitoring orders and to process the data written to the database by the local part. At this stage the system can be practically used in situations when no advanced large SCADA type system options are required.

2.

System analysis

The task of the system is to collect and provide access to data on the monitored process on the Internet and to enable the creation of new tasks, including the definition of process input parameters. To meet the above requirements the part of the system which is responsible for monitoring process variable values (local) must have three basic functionalities: √ browse the database in order to select the monitoring task coming from the internet part, √ host – controlling device communication (in our example the CQM1 PLC), √ write in the database the data derived from the process variable controlling device. Additional functionalities include data visualisation, in the form of 2-D graphs, report generation and records of communication between the computer and the controlling device. The other part of the system, in the form of a dynamically generated website provides the functionalities connected with: √ the process of creating new monitoring tasks, √ browsing the database and displaying the tasks, settings and process variable values for a given task, in table form. 3.

Control flow

The control flow in the system, schematically represented in Fig. 1, starts with a single client, which symbolises one session involving the creation of new task or browsing the Fig. 1. Control flow in the system values of the monitored data. The task creation mechanism consists of correct filling of the forms on the www server, while access is provided via a web browser (the only limitation being whether the browser supports Java scripts). User sent data is then verified and fed to the database, describing the status vector of the monitoring task. The entire process is initiated when a remote system user ascribes values to the elements of the monitoring task status vector (task start and end time, addresses of the process variables observed, sampling time value, values describing the sequence commencing and ending events). At this stage task initialisation begins. The local part of the system, operating on a computer coupled to the controller via an RS 232C serial port (work is in progress on using the net coupler, which would eliminate the need to use a local station) browsing the database

table cyclically, at set intervals, searching for tasks to perform. As soon as a record is recognised that meets the time criterion, it sets the monitoring parameters and ceases to browse the database. At the moment the tasks are queued and it is not possible to perform two monitoring tasks concurrently. From this stage onwards the system expects to synchronise the computer system time at the moment of commencing the task. If, additionally, the launch of a task is made dependent on the occurrence of a certain event, monitoring will commence the moment it occurs, not earlier. however, than indicated by the starting time recorded in the database. From then on, each successfully completed communication session between the local part of the system, and the controlling device, resulting in the Pw vector, is recorded in the database. The current task is completed when the time criterion is met or when a predefined event occurs. At this stage the system will switch to the task search mode.

Fig. 2. Structure of the system for archiving and providing access to process variable values [2] Note that the structure of the system as presented in Fig. 2 is so selected as to provide maximum scalability within the range of the system platform (excluding the local part for host – controlling device communication) and physical deployment of all components. Both the database MySQL engine, the Apache server and the PHP may operate under various operating systems, and their distributions are disseminated on an Open Source basis. It is possible to install the system fully on one PC, or to allocate the individual components among several workstations which are only limited in terms of Internet or local network access. Moreover, system destratification is recommendable, as the operating systems perform better on Linux platforms.

4.

Local part of the system The part of the data acquisition and distribution system which is responsible for the host – controlling device and host – database communication has been built in the form of a routine under the working name plcAgent. Its algorithm is presented in Fig. 3. It was developed from a RAD type platform named Borland Delphi. The tool is a combination of modern programming language, integrated programmer environment IDE and library of visual components. Communication with the database has been based on access functions written in C++. That was possible as Delphi allows for the addition of binary resultant files made by other compilers, including C++ compiler, to the executable file EXE or the DLL module. Thus, a module written in Object Pascal may use the procedures and functions contained in the.OBJ file. The plcAgent is equipped with an intuitive interface, so that users may easily access the data collected by the system data and view it in the form of a table or the values of the registered time based variables. Both the tables with data and the graphs generated may be printed, in line with the documentation template selected. 5.

Fig. 3. Algorithm of the local part of the system (plcAgent).

Data base and internet part of the system

The internet part of the system consists of a dynamically created website written in PHP, supported with Java scripts. The website is fully responsible for creating any new monitoring task and providing access to variable values on the web. The whole has been designed for easy navigation and should not be difficult to use [1, 3] The structure of the menu of the internet part of the system is presented in Fig. 4. The form of the new task and all other forms are equipped with automatic error service consisting in checking the integrity of the data before applying the POST method of the web server.

Processing the results of analysis, the DBOmron database has been designed. The Website with demo database consists of three tables in a Master http://www.plclab.agh.edu.pl/oa/ – Detail arrangement. The master table is TASKS New task Tbl_Main, which contains a task schedule. Task database The individual fields store a unique number Parameters of the new task of the next task which at the same time is MONITORING the main key, task start/end time and date, Settings read start and stop events, description field and Monitored data read sampling time between readings of full data series from the controller. The time is INFO entered in milliseconds and it must be Fig. 4. Structure of the menu of the internet selected carefully, so that it is not shorter part of the system than the time required for one full host – controller transmission. The table which contains the detailed parameters for each task is the Tbl_Params table. It consists of six fields. The first is an Autoincrement field, which is the main key, the second – task number (foreign key), the third defines whether a given process variable will be read or written. The last three fields characterise the data area, word address and its value in the case of writing. The last table is Tbl_Values collecting the results of the monitoring process. Each entry is provided with a unique index (main key) and, as in the case of Tbl_Params, an ID_Main field pointing to the task number. Just like in the case of controlling in the system, it is possible to represent schematically the input and output data streams for the DBOmron database. Such diagram is presented in Fig. 5. Input data include both the physical record and the query in SQL, which reaches the server. Output data (Database derived data) is defined as the return of specific records in reply to a query that may be originated either in the Internet or in plcAgent. Considering that the MySQL engine is a multistrand system, it is possible to perform simultaneously all the input and output operations, without compromising data cohesion. However, it is recommended not to use other functions of plcAgent during data monitoring, especially the report generating mechanism, as serial transmission is a significant burden on the computer system’s resources and in extreme cases

Fig. 5. Flow of input and output data streams for the database system.

(a large volume of data read from the database) there may occur uncontrolled pauses between the protocol commands sent. 6.

Conclusions from system tests

An experiment that has been performed (heater workstation controlled by a CQM1 controller) proved the correct operation of the designed system for the acquisition and distribution of process variable data. As expected, the plcAgent sampled the temperature values from the DM100 at equal two-second intervals over five minutes and entered them in the database. No attempt has been made to accurately estimate individual transmission time, as such operation would only yield reliable results for specific stable conditions, i.e. when the entire system is installed on one computer, without access from client stations. The reason is that the time of one full transmission consists of the time of sending the command to the controller, the time of receiving the reply and the time it takes to write the value in the database (the time it takes to write the value in the database is also part of the total time as any next command is only authorised when the reply received is correctly written). If the system components are distributed across several workstations and other client stations use the database resources (browse the monitored data values, browse the task database, create new task), the MySQL will not execute the write command immediately, as it indeed queues the tasks and when the number of clients is high or connection quality is poor, the time to write the record is changed. This must be borne in mind when the interval between the full series of monitored data is selected. In the case of our experiment the transmission time is not very important as temperature measurement is a slow change process and the sampling interval (2 [s]) was selected with a substantial margin. Acknowledgement The research work has been supported by the AGH-UST agreement No. 11.11.130.136 References [1] Coverse T., Park J.: "PHP 4. Biblia", HELION 2001 [2] Flaga S., Kwaśniewski J.: The Internet technologies for control and monitoring systems, ICCC 2003 [3] Laurie B., Laurie P.: "Apache. Przewodnik encyklopedyczny", HELION 2000

Suggest Documents