Copyright ® IFAC Future Trends in Automation in Mineral and
`Metal Processing, Finland, 2000
`
`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.D.Box 5400, FIN-020I5 HUT, Finland tel. +35894515224, fax +35894515394,
`e-mail marko. mattila@hutfi
`•• Outokumpu Mintec Oy,
`P.D.Box 84, FIN-02201 Espoo, Finland
`te/. +3589421 35 62,fax +3589421 31 56, e-mail 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 up(cid:173)
`time 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
`
`I INTRODUCTION
`
`Maximizing the production up time and keeping the
`level are common goals of any
`desired quality
`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 high(cid:173)
`technology 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
`traveling 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.
`
`telecommunications
`and
`information
`Current
`technology offer many interesting possibilities to
`establish more efficient procedures for end-user
`support with lower cost. Remote operation support
`via telecommunications can substantially reduce the
`improve
`the speed of
`need of traveling and
`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
`CROSS) is not new and some pioneering research and
`development work is also reported in the literature.
`One such example is discussed in COllus & 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
`telecommunications solution. - Another example is a
`
`419
`
`Smart Mobile Technologies LLC, Exhibit 2012
`Page 2012 - 1
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`remote support system for diesel engines (Wfutsilli
`NSD). Wlirtsilli'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 ROSS(cid:173)
`concept 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
`input module for equipment
`• Data base
`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
`• Module for interactive diagnostics and data
`visualization (for remote monitoring and
`fault diagnostics by the expert)
`• Module for investigating remote databases
`and generating remote queries for remote
`monitoring
`
`420
`
`• Module 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
`eXlstmg
`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 ANAL YZER 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
`is
`measurement and operational safety. All this
`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.
`
`Analyzer
`
`/1\
`
`I Measuring CPU J
`l
`I Analysing CPU I
`'"
`Op='"';~~;O",
`
`D iagnostics
`Data
`
`Parameters
`
`\11
`Operating
`Station
`
`Plant
`Control
`System
`
`Fig. 1. Diagram of analyzer system
`
`Smart Mobile Technologies LLC, Exhibit 2012
`Page 2012 - 2
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`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 on(cid:173)
`stream 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
`the communication line. The development of the
`system proceeds very much in conjunction with the
`development of the services.
`
`421
`
`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 APPLICA nON
`
`One of the central parts of the remote operation
`is
`its software and operational
`support system
`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 - Browser
`• Two tier Web-server - Browser with XML
`• COMIDCOM distribution
`
`These are schematically presented in Fig. 2.
`
`The strength of the direct Web-server - Browser
`architecture is the lack of any dedicated client.
`Browser 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
`
`De OM distribution
`
`XML and HTM L
`
`Direct Web-server
`
`Fig. 2: Possible software architectures
`
`Smart Mobile Technologies LLC, Exhibit 2012
`Page 2012 - 3
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`transfer capacity problem by transferring only data
`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 W AP 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
`OPERA TIONAL FEATURES OF THE PILOT
`ROSS-SYSTEM
`
`The software system design was carried out based on
`the requirement analysis on the on hand and on the
`maximum generality principle on the other hand.
`Therefore,
`the
`two
`tier Web-server - Browser
`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
`
`software
`the
`COM software components was
`to small
`development process and
`its division
`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.
`
`remote client application provides a user
`The
`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 an html-page and
`sends the result to the expert's browser. By using two
`lIS's (Internet Information Server) and XML data
`one can manage with much smaller bandwidth
`requirement than by using only a single lIS and direct
`html transfer.
`
`Remote Station
`
`Operating Station
`
`Internet Infonnation Server
`
`Remote Client
`Application
`
`Fig. 3: System diagram of the pilot system
`
`XN1L over
`TCPIIP
`
`422
`
`Smart Mobile Technologies LLC, Exhibit 2012
`Page 2012 - 4
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`to work
`the system functionalities proved
`All
`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.M6nkk6nen,
`E.Pulkkinen,
`P.Tervola and K.Koskinen (1998). Systems for
`Support of Process Operations. In: Proc. of the
`Integration in Manufacturing 98 Conference,
`Gothenburg, Oct. 1998.
`OPC Foundation (1998), OPC Data Access Standard
`2.0. (http://www.opcfoundation.org)
`Wartsila
`NSD,
`Operational
`(http://service.wartsila-nsd.com)
`Remtec
`Oy,
`RPX
`(http://www.remtec.fi)
`
`Platform
`
`support
`
`Accesses from the remote server application to actual
`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 ODBC 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 ODBC
`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 Process Control,
`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 the 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
`Pyhasalmi 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 1999. The
`geographical distance between the both ends was ca.
`500 kilometers in this case. The communications
`media used was an ISDN line.
`
`423
`
`Smart Mobile Technologies LLC, Exhibit 2012
`Page 2012 - 5
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`