SMALL INTERNET MONITORING AND CONTROL DEVICE

Transcription

1 International Carpathian Control Conference ICCC 2002 MALENOVICE, CZECH REPUBLIC May 27-30, 2002 SMALL INTERNET MONITORING AND CONTROL DEVICE Marcin JACHIMSKI, Grzegorz HAYDUK, Grzegorz WRÓBEL, Henryk ZYGMUNT and Paweł KWASNOWSKI Institute of Electrical Drives and Industrial Equipment Control Systems AGH - University of Mining and Metallurgy Cracow, Poland, hazet@uci.agh.edu.pl Abstract: The paper presents a comprehensive description of a SMALL INTERNET MONITORING AND CONTROL DEVICE, named as: INTERNET LOGGER elog, designed and manufactured by the Experimental Department of Scientific Equipment and Automation Ltd in Cracow. It is a miniature, microcomputer remote data concentrator, using real-time operating system, designed for direct connection to the Internet/Intranet network. Visualization of acquired signals, as well as configuration and programming of the device are performed by means of www browser (using Java platform). For this purpose it was provided with the Ethernet 10BaseT interface, TCP/IP protocol and a www server (www@elog ). Additional services installed are: Telnet, FTP, ( @elog ), PPP and sending short text messages to mobile phones (SMS@eLOG ). The internet concentrator is designed for operation in distributed systems of data acquisition and recording. It provides an input/output unit for analog and binary signals. Also a method, developed for programming simple control strategies by selecting functions from an available set (list on the configuration www page) and some details of developed programming tools are presented. Key words: internet, monitoring, data-acquisition and remote control. 1 Introduction Quite often a remote monitoring of manufacturing processes is necessary in industrial automatics systems and the notion "remote" frequently means "whole country" or even further. As the Internet and Intranet in these days are being more and more accessible, nearly everywhere, the authors began to search for solutions of remote monitoring, using technologies available in those networks. [COMER 2000]. 697

2 To reach this goal, a small internet monitoring controller was developed and studied both in industrial and laboratory conditions. We called it Internet Logger elog and its task is to support remote monitoring and control of manufacturing processes, using Internet/Intranet networks. This device can be directly plugged into Ethernet network without need of additional interfaces and a standard www browser can be used to perform online visualization of signals being monitored, configuration and programming of the device. 2 Device functions All input and output signal states of the device can be seen on the main www page of Internet Logger. Each signal has its own area on screen, which is filled with information about it. Analog signals area shows name of the signal, its current value (in configured physical units), current trend pointer (increasing, decreasing, constant) and trend graph over a predefined period of time. Digital signals area shows name of the signal and text description of the current state. The page also contains Event Log area. All areas are automatically updated and gently refreshed thanks to applying Java technology [BIELECKI 1997, PARKER 2000]. The authors developed a method of programming simple control strategies, notifying and data acquisition. The programming is carried out using developed Java applet with password restricted access. The method allows to define logical function and the device may take a predefined action when the function changes its state from false to true. Time of the change is called an event. The functions are defined by selecting components (digital input and output states or analog high or low alarm limits) and operators (logical product, logical sum, negation) available in combo box. Besides the event functions a user can select and define actions to be taken. The actions include sending: message on main www Event Log area, , SMS and message on auxiliary RS-232 port. Additionally seting or reseting of digital outputs for given period of time with given timeout is possible. Configuration of all elog parametres is possible using forms on password protected configuration www page. Basic configuration form allows to set the following data: current time and date, device name which will be shown on main www page, SMTP server IP address, sender address and reports address. Analog inputs configuration form allows for each input to define name of the input signal, formating string, units, scaling and alarm limits (high and low). The form for configuring digital signals allows to define name of the signal together with names of the states. 3 The hardware Internet Logger elog [JACHIMSKI 2001] was built up using two highly integrated circuits. First one is an 8-bit microcontroller integrated together with analog to digital converter (based on 87c552 microcontroller) [PHILLIPS 1998]. It's task is to operate directly on I/O 698

3 signals of elog. It operates on 4 analog inputs (ranges are V or 4-20 ma, their ADC resolution can be set by program to 10 or 12-bit), 8 digital inputs (adapted to work with no-voltage contacts or to count pulses) and 2 bistable relay outputs with open-contact configured as an inactive state. Buffering of input samples is possible thanks to 512 KB RAM; a non-volatile RAM and RTC allow to assign time to the samples. Internal communication with the second IC (communicating with Internet) is done using serial link RS 232. The second IC is a hybrid embedded PC compatible microcomputer (by German company Beck GmBH, named IPC@CHIP) [BECK 2001]. Its main function is to support Internet functionality through integrated Ethernet 10BaseT interface or modem. 3.1 Overview of IPC@CHIP microcomputer IPC@CHIP is a hybrid IC in DIL32 housing ( mm, see fig. 1), containing among others: MHz 16-bit CPU, 512 KBytes RAM, 515 KBytes Flash, operating system (on the Flash memory), I/O pins to support: Ethernet 10BaseT, 2 fast RS-232 serial ports (RXD, TXD, CTS, RTS), I 2 C Bus, 2 Timer Out, 2 Timer IN, 14 programmable I/O pins, Watchdog, Powerfail detection (NMI) with data retention Fig. 1. IPC@CHIP microcomputer 3.2 Operating It would be much more harder to use IPC@CHIP without its firmware. Some options the firmware provides to the user and programmer are: simultaneous execution of up to 35 tasks (spawned by max. 12 *.exe programs), simultaneous counting of up to 15 timers, using up to 60 semaphors and 2 message exchanges, Filesystem allowing to work on internal RAM-disk, internal Flash-disk or external IDE disk, TCP/IP stack with TCP, UDP, ARP, ICMP, Sockets interface (up to 64 at once), 3 device interfaces ( Ethernet / PPP client / PPP server ), embedded TCP/IP applications: HTTP, FTP and Telnet servers and DHCP client, packet driver interface, allowing user to access ethernet device directly, not using TCP/IP stack, DOS-like command shell, supporting subset of DOS-commands specific commands, accessible through telnet or serial port, 699

4 scalability making optimal Flash utilization possible (6 versions with different functionality are available to downloading through Ethernet or serial link), API for: - basic DOS functions, - additional realtime operating system services, - TCP/IP sockets or ethernet device access through packet driver, - HTTP server with CGI, - I 2 C bus and two serial ports (Fossil), - using I/O lines directly. Because executable file format is compatibile with DOS, development process is possible on any desktop PC with any development environment able to compile on processor (i.e. Turbo Pascal, Microsoft C/C++ or Borland C/C++). 3.2 IPC@CHIP microcomputer in Internet Logger elog Access to I/O of Internet Logger Internet Logger has arised from connecting logger based on 87c552 microcontroller with IPC@CHIP microcomputer. For coupling with a physical I/O of Internet Logger, the software which resides in IPC@CHIP must communicate through internal RS-232 link with 87c552 microcontroller using protocol similar to Modbus protocol (fig. 2). I/O 87c552 Beck IPC@Chip binary analog CPU RAM PROM RS RS-232 Modbus RS EXT CPU RAM RAM, C:\ Flash BIOS, A:\ I/O pins Ethernet Fig. 2. Internet Logger architecture 4 Software Internal software of the monitoring controller can be divided into two parts: software in 87c552 microcontroller, which directly handles inputs and outputs, software in IPC@CHIP microcomputer, which interoperates with Internet. Dedicated software in 87c552 microcontroller was written in C and partially in assembler and provides handling of I/O signals. When communicating through internal serial link with IPC@CHIP using protocol similar to Modbus protocol and receiving commands, this module operates as a slave. Firmware of IPC@CHIP consists (among other things) from realtime operating system, TCP/IP stack with www, telnet, FTP and PPP services. Proprietary software written 700

5 by one of the authors of the paper includes helper tasks (NXP - exchanging of pointers by name, MLgr - access to console from within many tasks, elogsvr - communication with 87c552 through serial line) and main task (elogcgi). 4.1 Proprietary software in IPC@CHIP While writing the software to be run on IPC@CHIP fulfilling the previously presented functions of Internet Logger an assumption was made, that the software should be easily modificable and reusable in further developing applications, which may arise (basing on Internet Logger hardware). This goal has been reached thanks to modular architecture of written software, supports. The software consists of several tasks, stored on Flash-disk and started during Internet Logger bootup. These are server-tasks (NXP, MLgr, elogsvr) making available described below services and main task elogcgi. When developing the software, experience gained while applying QNX OS in industrial manufacturing process control systems had been utilized NXP - Exchanging pointers by name NXP is a server-task which allows to register (on NXP's internal list) memory pointer under given name, query the pointer (giving its name), deregister it and (for diagnostics purposes) retrieving list of registered pointers. All of the functions (registration, querying, deregistering and retrieving list) are available through following API functions: int NXP_SendNamedPtr( char *Name, void far *ptr ); int NXP_GetNamedPtr( char *Name, void far * far * ptr ); int NXP_DelNamedPtr( char *Name ); int NXP_GetNamesArray( NameXPtrItem_t far * far * ptr ); An example of NXP application is a situation, where (to achieve fast inter-process communication as shared memory) one of the tasks (T1) registers (using NXP_SendNamedPtr) address of its memory block under some name (i.e. "FunArray") and another task (T2) using NXP_GetNamedPtr reads that address knowing only the name (here "FunArray"). Additionaly, using semaphores, those two tasks using memory block registered by task T1 can now communicate synchronically (access to memory buffer also can be guarded by semaphore) MLgr - access to system console from within many tasks During development of IPC@CHIP it came out, that using printf() function in one moment only one task can print messages on command shell console. However during development it is very usefull to print out tracing messages from any task. To reach this goal, MLgr server task was created (nb. registering pointer to its message queue using NXP), which all the time has exclusive access to printing messages on the console and prints messages that other tasks will send them. This task is a kind of buffer and another advantage is that tasks (which normally would printf() message and block) now don't block on sending message to MLgr. Its the MLgr which blocks on printf() function. Synopsis of API function is given below: int MLoggerSend( char *format_str,... ); 701

6 4.1.3 elogsvr - communication with 87c552 elogsvr is a server-task which allows in easy way (thanks to implemented API) to communicate with 87c552 microcontroller (which directly couple with I/O of elog ). The API was modeled on Photon microgui API (used under QNX and Neutrino) and consists of the following functions: void LgSetArg( LgArg_t *arg, char cmd, void *bufptr, int bufsize ); void LgSetArgIO( LgArg_t *arg, char cmd, void *inbufptr, int inbufsize, void *outbufptr, int outbufsize ); int LgGetResources( LgArg_t *args, int nargs ); First, the user has to fill arguments table (LgArg_t type) and call LgGetReources function passing the pointer and size of the table. The argument contains command (read or write I/O) and pointer to read/written data. In case of extending hardware of Internet Loger or 87c552 software, the user to use new features calls the same API functions passing new commands in arguments elogcgi - main task To achieve above described functionality of elog the main task was written and performs the following functions: periodically communicates with elogsvr to read inputs and write outputs, allowing any www client (through CGI functions called by webserver) to read inputs states and write outputs, periodically evaluating event functions and performing actions - set by the user - assigned to the events (changing outputs, sending , SMS or message on main elog www page), allowing I/O and event functions (up to 10) configuration. 4.2 How Java applets and CGI functions cooperate To allow most effective usability of the software created on IPC@CHIP, several Java applets have been written. [BIELECKI 1997, PARKER 2000, SUN 2001]. They make use of elog from www browser easier and more comfortable. They are briefly described below, together with their cooperation with implemented CGI functions. When WWW client requests main elog www page, retrieves Java applet elogview.class which displays current I/O state. The applet automatically sets its size according to the size of www browser window and periodically queries elog for current I/O states and refreshes its view avoiding flickering effect (the user always can see current I/O state and www messages). Requesting data is done by calling CGI function named elogdata.txt and decoding response. Some example response is shown below: WeA1:Temperature:22.4 C:+:1:0:-10:40:22.375; ;...; WeD1:998:1: :Alarm! WyD1:Ring:0:Silent:Rings M01:06/05/00 00:00:07 : Temp. normal... If the client requests elog parameters configuration www page, GenConf CGI function is called. It creates HTML page containing forms with currently set parameters. After the user modifies the parameters, each of the forms can send its data back to 702

7 GenConf CGI function, which can save the parameters on Flash-disk, making changes permanent. When requesting elog event functions configuration page, JEvtConf.class applet is called which allows user to define and modify event functions definitions together with actions assigned to the functions. The applet talks with elog thangs to another CGI function called elogevt.txt. The data being sent between the applets and CGI functions is slightly coded to achieve compromise between easiness of human reading and size of the data. Event functions and the actions are coded into lines like this: M0=Temp. high!!! S0= A0=ac0000 F0=0f0100 Additional CGI function implemented in elog is OneLine, which allows reading and writing of I/O in very simple way: all the values are put in one line, i.e.: DI0= , AI0=0x059e, AI1=0x0000, AI2=0x0000, AI3=0x0000, DO0= , ERR=0 Utilizing this CGI function it was easy to write such programs like HTTP2DDE Bridge or elogger ActiveX control. They work on desktop PC in MS Windows environment. First one works as DDE server, periodically requesting I/O states from elog and passing the data to other applications connected with DDE link. Writing to elog outputs is also possible. And above mentioned ActiveX control allows any application being OLE container (i.e. MS Office applications, Visio, Matlab, InTouch by Wonderware or Fix32 by Intelution) to communicate with elog using VBA code or GUI. 4.3 Further extensibility of software Because elog is based on it is possible to create any software strictly fulfilling given application requirements. Above described software is an example of using this hardware and because of its modularity (server tasks and API functions libraries), it certainly would be much easier for developers to create their own software. 5 Application examples One of example of application elog is monitoring remote heating node in one of buildings at University of Mining and Metallurgy in Kraków, whose connections diagram is shown in figure 3. It collects information on actual values of temperatures: heating medium at central heating installation supply (Tzco) and return (Tpco), sanitary hot water supply (Tzwu) and on input of heat exchanger for lecture hall air supply (Twent), and also the heating medium flow rate (Fm) and amount of heat (Wm) supplied to the building. Figure 4 shows web page containing these values. [GREGA 2002]. Another application example (not yet realised) is monitoring cooling storehouses from all over the country. Monitoring signals include 4 analog inputs (temperatures) and 8 relay inputs (occupancy sensors, smoke sensors, door and window open sensors), whereas two relay outputs control acoustic and light signaling devices. To communicate with elog, Ethernet TP and auxiliary RS-232 port were provided. 703

8 Impulses (heat, water flow) Supply (24 V AC/DC) Ethernet TP (to hub) Temperatures RS-232 (AUX) Fig. 3. elog connections in heat-node monitoring application Fig. 4. Heat node visualization screenshot 6 Conclusions Developed and tested Internet Logger elog for remote monitoring of manufacturing processes through Internet or Intranet network, proved its high usefulness in practical applications. The device could be directly plugged to the net without need of additional interfaces. Visualization of monitored signals, configuration and programming are possible using a standard www browser. A method of programming simple control strategies was designed, allowing user to select conditions and actions from available options. The method is easy enough for every user holding basic technical knowledge and the rest of the device functionality also doesn't require from user any additional training. References BIELECKI J.: Java od podstaw, Warszawa, Intersoftland, COMER D.: Sieci komputerowe i intersieci, Warszawa, WNT, PARKER T., SPARTACK M.: TCP/IP - księga eksperta, Gliwice, Helion, PHILLIPS Semiconductor North America Corporation, IC20 Data Handbook, 87C552 Product Specification, 1998 May 01. SUN Microsystems Inc.: Java SDK Documentation, JACHIMSKI M., WRÓBEL G., HAYDUK G., ZYGMUNT H., KWASNOWSKI P.: Monitorowanie procesów przemysłowych przez internet; Studia Informatica 2001, Volume 22. Number 4 (46), pp , Silesian University of Technology Press, Gliwice 2001 PL ISSN BECK GmBH, IPC@CHIP, GREGA W., KOŁEK K. 2002; 704