REMOTE OPERATIONS SUPPORT SYSTEM FOR ON-LINE ANALYZER

Size: px

Start display at page:

Download "REMOTE OPERATIONS SUPPORT SYSTEM FOR ON-LINE ANALYZER"

Maximillian Ford
6 years ago
Views:

1 REMOTE OPERATIONS SUPPORT SYSTEM FOR ON-LINE ANALYZER Marko Mattila *, Kari Koskinen *,Kari Saloheimo ** * Information and Computer Systems in Automation, Helsinki University of Technology P.O.Box 5400, FIN HUT, Finland tel , fax , marko.mattila@hut.f ** Outokumpu Mintec Oy, P.O.Box 84, FIN Espoo, Finland tel , fax , kari.saloheimo@outokumpu.com Abstract: Remote, telecommunications based support for process equipment operation and maintenance can offer substantial benefits for the end-user in terms of improved uptime and better quality of operation. Equipment vendors can utilize this kind of facility to improve their after-sales services for the end-user. A remote operations support system has been designed and realized. The prototype system has been applied to and experimented with an on-line X-ray fluorescence analyzer manufactured by Outokumpu Mintec Oy. The system comprises software modules in the analyzer operating station end and in the remote expert station end. The communications between both ends uses TCP/IP protocol and the communications media can be Internet, or wired and/or wireless or satellite-based telephony network. Copyright 2000 IFAC Keywords: remote support, remote maintenance, remote diagnostics, technical support, COM, OPC, Internet, XML, VPN 1 INTRODUCTION Maximizing the production up-time and keeping the desired quality level are common goals of any production process. Usually they are possible only by high availability and consistent performance of all key process equipment. One reason why this is problematic is that the processing plants are often located in regions where it is difficult to recruit technically skilled personnel to maintain hightechnology instruments or equipment. In many cases the maintenance is arranged by a contract between the end-user and the equipment vendor. In a trouble situation, an expert from the vendor company is often required to travel to the site. The travelling time causes a delay in solving the trouble and, at worst, a corresponding loss of production. Moreover, in several cases the original reason for the fault has been quite simple and could have easily been fixed by the local personnel, if they only had known it. Current information and telecommunications technology offer many interesting possibilities to establish more efficient procedures for end-user support with lower cost. Remote operations support via telecommunications can substantially reduce the need of travelling and improve the speed of troubleshooting. Moreover, embedded intelligent fault diagnostics used interactively by the remote expert helps to decide and schedule preventive maintenance actions. The idea of a remote operations support system (ROSS) is not new and some pioneering research and development work is also reported in the literature. One such example is discussed in (Ollus & al) where a ROSS was designed, realized and tested for a specific type of a pulp washer. The system featured videoconferencing, multimedia product documentation, a training simulator and a remote process-monitoring module. Modem and ISDN connections over telephony network were used as the

2 telecommunications solution. Another example is a remote support system for diesel engines (Wärtsilä NSD). Wärtsilä s web based diagnostic tool is a result of decade long industrial product development. Although some examples of ROSS-systems already exist, there is a lot of unused potential left for such systems in various industries. This paper deals with the design, realization and experimenting of a ROSSconcept and system for a set of instruments and equipment used in the mineral and metal processing industries. The pilot system application was made for a Courier 3SL on-line X-ray fluorescence analyzer manufactured by Outokumpu Mintec Oy. While all testing and experimenting was carried out using the analyzer as the pilot instrument the aim is to design the system as generic as possible so that it can be utilized as a basic building block for later realizations of ROSS systems for other process equipment. The maximum generality poses a tough challenge for the research works in methodological and especially in software issues. 2 CONCEPTUAL MODEL OF ROSS Following the reasoning presented in (Ollus et al) a conceptual model for ROSS can be presented by listing the functions in the site and remote ends: The site end system may include the following modules: Multimedia product documentation (locally or accessed via extranet, to support in equipment operation and maintenance) Videoconferencing to get expert help and to transfer image information from site Local diagnostic module to automate some of the equipment condition monitoring and fault diagnosis Data base query module for equipment variables and their histories for remote monitoring Data base input module for equipment control variables to remote control the equipment Communication module for safe and secure communications The remote end system may include the following modules: Multimedia product documentation (locally or accessed via extranet) Videoconferencing for interactive diagnostics and data visualization (for remote monitoring and fault diagnostics by the expert) for investigating remote databases and generating remote queries for remote monitoring for generating database input for remote database to remote control the equipment Communication module for safe and secure communications The communications media can be chosen from a set of possibilities, depending on the existing communications infrastructure in the end-user site. The media can be Internet, or wired, wireless or satellite-based telephony system. Different modules are described in more details in Chapter 6. 3 THE ON-LINE ANALYZER AND ITS OPERATOR STATION Courier 3SL is an on-line X-ray fluorescence (XRF) analyzer for concentrator processes. In typically 10- minute cycles, it automatically takes samples from up to three sampling lines, analyzes the concentrations of elements in the samples and sends the results to the automation system. Besides the XRF measurement and its signal processing, the device includes mechanics and controls for sample handling and presentation, internal reference sample measurement and operational safety. All this is handled by an embedded control application running on the analyzer s CPU. In addition to the on-line concentrations, the analyzer produces about 3000 analog and 300 digital data items per analysis cycle that are useful for diagnostic purposes. These include primary X-ray spectra of sample and internal reference measurements, and operational status data of the measurement control processes. The diagnostic data are passed and logged to the operator station, a dedicated Windows NT PC connected to the analyzer by a serial line. Diagram of the system is described in figure 1. Diagnostics Data Measuring CPU Analysing CPU Operating Station Operating Parameters Analyser Concentrations Plant Control System Fig. 1. Diagram of analyzer system

3 the communication line. The development of the system proceeds very much in conjunction with the development of the services. The operator station hosts a runtime monitoring application built on top of Cimplicity HMI by GE Fanuc. It displays the analyzer status, receives certain controls from the user, and logs data on various time bases into a MS Access database. Moreover, the operator station includes tools for editing and loading the analyzer parameters. There are over 500 parameters that control the measurement sequences and processing of the measurement signals. The Parameter Manager application also facilitates special data reads from the analyzer CPU. 4 THE REQUIREMENTS ANALYSIS STUDY The functional requirements of the ROSS for onstream analyzers were surveyed by an inquiry among the analyzer service personnel and some individual customers. The largest expected benefits were higher instrument availability, faster repair times and savings in unnecessary service trips or waiting periods for spares to the site. The most typical uses of a ROSS system, accordingly, were seen as Expert preventive maintenance between regular service calls to the site Quick and reliable troubleshooting in fault situations Supplying specialized services for analyzer calibration The functionality of the ROSS was derived from the needs of these uses. Data transfer as files and queries of the history database are needed for troubleshooting. Parameter modification and loading from the remote end to the analyzer were seen necessary as many of the past problems are related to the parameter setup. Live video image, even with a limited bandwidth, was seen very useful in locating possible mechanical problems. Security was seen as one of the central challenges of the development of the ROSS. The basic requirements include, the analyzer must be left to a safe condition in all abrupt communication breaks the communication line must not create a hole to the plant s IT safety system the local end must be in complete control of any data passed to the remote end One of the central themes of the survey results was that, after all, the essential benefits gained by a good ROSS are very much dependent on the availability and skill of the experts that work in the other end of Combining of remote support system and support service seems to be crucial to commercial exploitation of remote support system. Main reason for this is the difficulty of selling extra feature for problem situations. When the ROSS is integrated to service and its commercial exploiter is the equipment manufacturer this selling problem is avoided. 5 SOFTWARE ARCHITECTURES FOR REMOTE DIAGNOSTIC APPLICATION One of the central parts of the remote operation support system is its software and operational architecture. Architecture defines the usability of the system and the future possibilities. Open and flexible software architecture makes system development, maintenance and upgrades easier. For this purpose a purely customized Client-Server architecture was assessed too restrictive. To gain more open and flexible solution the following three architectural possibilities were considered and evaluated. Direct Web-server Two tier Web-server with XML COM/DCOM distribution These are schematically presented in fig. 2. The strength of the direct Web-server architecture is the lack of any dedicated client. is enough. The clear disadvantage is the need to transfer also GUI (graphical user interface) over the network connection. This can be a real problem when using mobile links with very low transfer rate. The two tier Web-server solution that uses XML as a middle information transfer format resolves the transfer capacity problem by transferring only data DCOM Client DCOM Object DCOM distribution XML WWW- Server XSL HTML WWW-Server XML and HTML WWW-Server Direct Web-server Fig. 1: Possible software architectures

4 over the remote connection. The GUI is created locally for the browser from transferred XML data. Need of local server is clear disadvantage, but it also makes possible to use the same system to produce information to different user interfaces like WAP and SMS. The third possible architecture uses COM objects and their distribution over network using DCOM. This solution needs a dedicated client and more transfer capacity than XML-data transfer. On the other hand COM-objects are very flexible to use and with windows 2000 and COM+ their security has increased significantly. 6 THE SOFTWARE STRUCTURE AND OPERATIONAL FEATURES OF THE PILOT ROSS-SYSTEM The software system design was carried out based on the requirement analysis on the other hand and on the maximum generality principle on the other hand. Therefore, the two tier Web-server architecture with the module interfaces to system resources were defined and chosen to allow for minimal effort in later replacement of equipment specific software components like the database and SCADA software. Another reason for the use of COM software components was the software development process and its division to small independent parts that is natural for software components. Use of COM objects also includes possibility to later easily change from two tier web architecture to DCOM distribution based software architecture. The support system application consists of server and client applications and interface modules. The client and server applications are integrated to Microsoft s Internet Information Server as extensions, using the RPX platform by Remtec Oy, Finland (Remtec Oy) for information logistics. The remote client application provides a user interface for the expert s browser and sends queries to the remote server as XML-documents. The remote server interprets these queries and performs the actual data collection and editing to produce a response XML-document. The remote client then transforms this XML-document to a html-page and sends the result to the expert s browser. By using two IIS s (Internet Information Server) and XML data one can manage with much smaller bandwidth requirement than by using only a single IIS and direct html transfer. Accesses from the remote server application to actual Remote Station Operating Station Access Database ADO/OC Cimplicity HMI SCADA OPC Configuration- and log files Internet Information Server OPC File Remote Client Application Internet Information Server Remote Server Application VPN VPN RAS XML over TCP/IP RAS Fig. 1: System diagram of the pilot system

5 data sources are implemented using separate COM objects. There are separate objects for database, SCADA, file and direct analyzer access. The analyzer access is implemented using COM interfaces in two phases. There is an application that communicates with the analyzer through the RS-485 line. This communication application can either be used by a local user or remotely through a COM automation interface access module. The database module uses ADO (ActiveX Data Objects) with OC drivers for database access. Some efficiency of database access is lost but at the same time we gain generality on possible database engines. For example, if one keeps the OC registration and database structure the same and changes the database from Access to SQL-server, no reconfiguration of the database module is necessary. The OPC module uses OLE for Control, a COM based process automation standard, for communication with the SCADA system. (OPC Foundation) The system also included a portable camera set that is not shown on the system diagram in fig 2. The camera equipment consists of small camera and a transmitter unit that are fitted to operators hearing protector. There was also audio receiver and transmitter in the hearing protector so the operator and the expert could speak while the expert is shown the operators view through the video link. The audio/video receiver was in the operating room where the signals were digitized and transmitted to the expert s computer via ISDN or Internet. 7 THE PILOT EXPERIMENTS The system was gradually tested during the design and implementation period. Some specific parts, like the wireless WLAN based portable videoconferencing set was experimented in the Pyhäsalmi mine separately before the demonstration and testing of the complete prototype system. The remote end was situated in the Helsinki University of Technology in Otaniemi during the complete system testing in the end of November The geographical distance between the both ends was ca. 500 kilometers in this case. The communications media used was an ISDN line. All the system fuctionalities proved to work successfully during testing. The quality of the video image from the site was not very good due to the chosen low resolution portable videoconferencing set, but was assessed having certain value for troubling shooting purposes even as such. The quality of the video image can be improved just by using a higher resolution videoconferencing set, but then the used communications channel bandwidth should be increased too, by e.g. adding another ISDN channel. However, it is possible to transfer good quality still images even if the used communications bandwidth is rather modest. 8 CONCLUSIONS The pilot ROSS-system was tested successfully. The requirements study indicated clear and definite needs for these kinds of systems to improve the quality of after-sales services for the end-user and to reduce the cost of the service provider. The generality objective of the system design has evidently been reached quite well, too. By using separate interface components for data communication, a modular software structure has been gained. Modularity helps in the developing and maintaining the tools in the future. In the future work we will evaluate the generality level more closely. This is studied in connection with ROSS applications for various other equipment manufactured by Outokumpu. REFERENCES M.Ollus, K.Kuhakoski, A.Niemenmaa, M.Uusitalo, J.Koponen, M.Mönkkönen, E.Pulkkinen, P.Tervola and K.Koskinen (1998). Systems for Support of Operations. In: Proc. of the Integration in Manufacturing 98 Conference, Gothenburg, Oct OPC Foundation (1998), OPC Data Access Standard 2.0. ( Wärtsilä NSD, Operational support ( Remtec Oy, RPX Platform (

SCADA Software. 3.1 SCADA communication architectures SCADA system

SCADA Software. 3.1 SCADA communication architectures SCADA system 3 SCADA Software 3.1 SCADA communication architectures 3.1.1 SCADA system A supervisory control and data acquisition (SCADA) system means a system consisting of a number of remote terminal units (RTUs)