Remote Monitoring & Diagnostics

Remote Monitoring & Diagnostics RAAK-PRO Veiligheid op de Werkvloer

Enschede, 31-07-2012 Auteur: Piet Griffioen

Veiligheid op de werkvloer is een initiatief van het kenniscentrum Design en Technologie van Saxion. Het project richt zich op de vraag hoe de veiligheid op de werkvloer te bevorderen met behulp van ambient technologie. Het gaat daarbij om persoonlijke veiligheid, een veilige omgeving en veilig gedrag. Het project is gestart op 1 januari 2011 en heeft een looptijd van vier jaar. De consortiumleden zijn Saxion, Universiteit Twente, Novay, Thales Nederland, Norma MPM, PANalytical, TenCate Protective Fabrics, Alten PTS en Noldus Information Technology. Daarnaast is er een wisselende groep van deelnemende bedrijven die bij gelegenheid deelneemt in het programmateam. Het project ontvangt subsidie van de Stichting Kennis Ontwikkeling HBO onder registratienummer RAAK PRO-2-013.

Remote Monitoring & Diagnostics RAAK-PRO Veiligheid op de Werkvloer

ISBN/EAN: Titel: Remote Monitoring & Diagnostics Subtitel: Auteurs: Piet Griffioen Projectreferentie: RAAK-PRO Veiligheid op de Werkvloer Uitgever: Saxion Kenniscentrum Design en Technologie Verschijningsplaats: Enschede Verschijningsdatum: 31 juli 2012 Status document: Publiek

Veiligheid op de werkvloer; Remote Monitoring & Diagnostics

Pagina 2 van 15

Summary Accidents at work are often the result of human behavior, how people interact with each other and how people cope with risks and guidelines. Through courses, training and risk assessment a better understanding and acceptance level is created for safety at work. This is the scope of the Health and Safety Act (Dutch: Arbowet) and is a prerequisite for safety at work. Situation Awareness (SA) is also an important aspect for safety at the workplace. An adequate understanding of the current situation is important in order to judge the consequences of any actions taken in relation to the safety of the work, in order to avoid adverse events. An adequate understanding of the current situation includes also the performance and functioning of equipment used at the workplace. Malfunctioning of equipment or out of range performance could result in potential dangerous situations and should be detected in an early stage. The project Remote Monitoring & Diagnostics deals with the remote monitoring of equipment. Remote monitoring enables the equipment manufacturer to perform diagnostics from its own premises without having to travel to remote, far-away locations. This is also an extra maintenance and support service that can be offered to customers. Remote Monitoring & Diagnostics consists of gathering equipment status information, sending this information to a server at the manufacturer premises (intranet) and providing a web interface to enable service engineers and product engineers to view the status information. In addition, alerts are generated in case of malfunctioning or out of range performance of the equipment. The alerts are sent by SMS and / or email to the responsible service engineers. This project has resulted in a prototype version of Remote Monitoring & Diagnostics. The project has been carried out by students of the Saxion University of Applied Sciences.


Pagina 3 van 15


Pagina 4 van 15

Table of Content Summary

3

Table of Content

5

List of Figures

6

List of Tables

6

1.

7

Introduction 1.1

PANalytical

7

1.2

Epsilon 3

7

1.3

Problem description

8

1.4

Objectives

8

2.

Methodology and approach

3.

Design & Implementation

9 10

3.1

Architecture

10

3.2

Implementation and Test

11

4.

Conclusions and Recommendations

14

5.

Abbreviations

15


Pagina 5 van 15

List of Figures Figure 1

Epsilon 3 .............................................................................................................. 7

Figure 2

Transport over bad roads ..................................................................................... 8

Figure 3

Physical Architecture .......................................................................................... 10

Figure 4

Functional Architecture ...................................................................................... 11

List of Tables Table 1

Test Cases for the RD Session Software (subset) ................................................ 12

Table 2

Test Cases for the RD Client (subset) ................................................................. 12

Table 3

Unit Tests for the DAO layer (subset) ................................................................. 13


Pagina 6 van 15

1.

Introduction

1.1

PANalytical

The project Remote Monitoring & Diagnostics has been carried out for and in cooperation with one of the consortium members, namely PANalytical. (Source: panalytical.com / about us) PANalytical is the world's leading supplier of analytical instrumentation and software for Xray diffraction (XRD) and X-ray fluorescence spectrometry (XRF), with more than half a century of experience. The materials characterization equipment is used for scientific research and development, for industrial process control applications and for semiconductor metrology. PANalytical was founded in 1948 as part of Philips and was formerly known as Philips Analytical. It employs around 1000 people worldwide and has its headquarters in Almelo, the Netherlands. The product portfolio includes a broad range of XRD and XRF systems and software widely used for the analysis and materials characterization of products such as cement, metals and steel, nanomaterials, plastics, polymers and petrochemicals, industrial minerals, glass, catalysts, semiconductors, thin films and advanced materials, pharmaceutical solids, recycled materials and environmental samples.

1.2

Epsilon 3

The Epsilon3 energy dispersive X-ray fluorescence (EDXRF) spectrometer is taken as a reference for the project Remote Monitoring & Diagnostics. Epsilon 3 is an affordable, highly flexible analytical tool suitable for a wide range of applications.

Figure 1

Epsilon 3


Pagina 7 van 15

1.3

Problem description

Once put in use at the customer premises, the Epsilon 3 is liable to normal wear-and-tear and to ageing for which (preventive) maintenance is advise and required on periodic intervals. But also non-periodic and ad-hoc maintenance checks can be required, for example due to non-regular transport of the equipment during fife-cycle of the product which could give rise to performance related issues.

Figure 2

Transport over bad roads

PANalytical would like to have the ability to monitor the status of the equipment remotely without the need for a user PC or the need for an SMS modem attached to the user PC. The status information is sent to a web server at the premises of PANalytical. The web server provides web interfaces for service engineers and product engineers to inspect the data. Engineers should also be able to configure and calibrate the equipment and to setup Statistical Process Control (SPC) rules to optimise product performance and apply (preventive) maintenance checks. In case of malfunctioning or out of range performance of the equipment, the responsible service engineers should be alerted by means of SMS and / or email. The solution should be secure and robust. Security covers a site-to-site Virtual Private Network (VPN) from the customer premises over the Internet to the PANalytical premises. Security covers also authentication and authorization of the engineers that use the Remote Monitoring & Diagnostics facilities. The solution should be robust against unreliable, low bandwidth connections down to 1200 baud. Not all remote, far-away locations have the luxury of permanent, high-bandwidth internet connections. The solution should cope with wireless 2G and 3G connections and satellite connections.

1.4

Objectives

The objective of the project Remote Monitoring & Diagnostics is a prototype implementation of the desired functionality. Veiligheid op de werkvloer; Remote Monitoring & Diagnostics

Pagina 8 van 15

2.

Methodology and approach

Starting point for the project was a Target Specification of the Remote Monitoring & Diagnostics system. The Target Specification has been provided by the equipment manufacturer. The Target Specification contains functional requirements (user tasks) and non-functional requirements. Based on the Target Specification, technical requirements have been derived as well as usecases with test criteria. These requirements were input for the global and detailed design, the implementation and the integration and verification.


Pagina 9 van 15

3.

Design & Implementation

3.1

Architecture

The physical architecture of the Remote Monitoring & Diagnostics system with its hardware components is shown in the figure below.

Figure 3

Physical Architecture

The RD box is an embedded computer at the customer premises that is locally connected to the instrument. The RD box collects status data of the instrument, performs SPC and calibration settings of the instrument. Loggings and alerts are sent to the RD server. The RD server is located at the equipment manufacturer premises. The RD server collects the loggings and alerts and stores them in a database. The RD server stores also the parameter bank of the instrument for back-up purposes. In case of an alert, an SMS / mail is generated for the responsible service engineer. The RD server provides interfaces to RD clients to browse through the stored data and to perform settings. The functional architecture of the Remote Monitoring & Diagnostics system with its functional building blocks is shown in the figure below.


Pagina 10 van 15

Figure 4

Functional Architecture

The RD box contains the instrument control software (ICSW) that interfaces with the instrument and collects status data. The ICSW can also perform configuration settings. The data is logged into files. The RD Session Software is responsible for the connection and communication with the RD Web Server. It sends the logged data at regular, adjustable, time periods or event based. When the connection is not available, the RD Session tries to send the data the next time. The RD Web Server stores the loggings in a database together with configuration information of the instrument. Alerts are sent by SMS / email to service engineers. The Web Server provides RD Web Clients with the possibility to inspect the configuration, to add comments (blog), to inspect generated alerts and to inspect the status loggings graphically. The RD Session Software, the RD Web Server with the database and the RD Web Client have been prototyped in this project.

3.2

Implementation and Test

For the implementation the following tools are used: 

Windows Communication Foundation (WCF) for the communication between the RD Session Software and the RD Web Server based on SOAP.



Data Access Objects (DAO) for the insertion and retrieval of data to / from the database at the Web Server



ASP.NET together with MVC3 for the creation of RD web clients

The target platform is C# with .NET. Veiligheid op de werkvloer; Remote Monitoring & Diagnostics

Pagina 11 van 15

Test have been developed for the RD Session Software on the RD Box, for the RD Web Client and for the DAO data layer on the RD Web Server using Unit Tests.

Test Case

Preconditions

Expected Result

Result

OK / NOK

Basisfunctie: Versturen data op interval 2 minuten

Er moet in de config file onder IntervalMinute een getal ingevoeld worden. 2 minuten- gestart om 13:03uur Het logging activeren en handmatig waarde in het logging file veranderen. Logging activeren en drempelwaarde in config file inzetten. Logging file handmatig met juiste waarden aanpassen.

Applicatie verzoekt data om 13:05uur te versturen. Meldingen in GUI geven dit aan.

Applicatie verzoekt data om 13:05uur te versturen. Meldingen in GUI geven dit aan.

OK

Errormelding in GUI en in log file

Errormelding in GUI en in log file

OK

Applicatie verzoekt data en alerts te versturen. Meldingen in GUI geven dit aan.

Applicatie verzoekt data en alerts te versturen. Meldingen in GUI geven dit aan.

OK

Functie Errorlogging: Geen internet verbinding Functie Alerts: Alert versturen naar server

Table 1

Test Cases for the RD Session Software (subset)

Test Case

Preconditions

Expected Result

Result

OK / NOK

Het weergeven van alerts van een RD Box

De RD Box bestaat, en er zijn alerts in de database

Een lijst met alerts inclusief timestamp wordt weergegeven

OK

Het weergeven van de system values van de laatste meting van een RD Box

De RD Box bestaat in de database, inclusief minimaal 1 measurement

Een lijst met variabelen met daarachter de waarden van de laatste meting wordt weergegeven

Het weergeven van een system value over een bepaalde periode in een grafiek

De RD Box bestaat in de database, inclusief meerdere metingen

Een grafiek met de waarde tegenover de tijd afgezet wordt weergegeven

Een lijst met alerts inclusief timestamp wordt weergegeven Een lijst met variabelen met daarachter de waarden van de laatste meting wordt weergegeven Een grafiek met de waarde tegenover de tijd afgezet wordt weergegeven

Table 2

OK

OK

Test Cases for the RD Client (subset)

VariableDaoTest: Hier wordt alleen getest of je een Variabele uit de database kan halen. Dit is omdat er geen Insert methodes zijn in de Dao. Om dit te kunnen testen moeten er handmatig Variabelen aan de database toevoegd worden. Vervolgens moeten deze waarden overeenkomen.


Pagina 12 van 15

StatisticsDaoTests: Deze klasse test het ophalen van statistieken van 1 Variabele van 1 RD Box over een te kiezen tijd. Bij deze test wordt er vanuit gegaan dat de MeasurementDaoTests succesvol zijn uitgevoerd. De gebruikte waarden moeten overeenkomen met de waarden in de MeasurementDaoTests. AlertDaoTests: In deze klasse wordt het inserten en ophalen van Alerts getest. Hierin wordt gebruik gemaakt van de naam van een Variabele en een Id, deze moeten overeenkomen met respectievelijk de KeyName van een Variable en de ID van een RD Box. De expectedVariableID moet overeenkomen met de ID van de Variable met de gebruikte KeyName. Table 3

Unit Tests for the DAO layer (subset)


Pagina 13 van 15

4.

Conclusions and Recommendations

In this project a prototype implementation has been realized of a Remote Monitoring & Diagnostics system. The prototype does not yet cover all the user requirements, but the prototype shows the feasibility of a Remote Monitoring & Diagnostics system. Based on the current implementation and the tests that have been performed the following recommendations can be made: 

Sending large logging files can result in timeouts. This problem can occur when there is no connection between the RD Box and the RD Server for a long period of time. This is either a matter of tuning or the loggings should be sent in pieces (chopped).



The communication is based on SOAP. However, SOAP has a relative large overhead that might become problematic in case of low bandwidth connections. In that case alternatives could be JSON or named pipes that are also part of WCF.



Some of the DAO implementations are not optimal qua performance. The use of Joins in database queries could improve this.



Smart alerting. Currently, every time an alert arises an email is sent to a service engineer. An alert can arise every 30 seconds so, every 30 seconds a mail is sent. Smart alerting should take into account whether the alert has already happened before and how long ago.


Pagina 14 van 15

5.

Abbreviations

DAO

Data Access Objects

ICSW

Instrument Control Software

RD

Remote Diagnostics

SPC

Statistical Process Control

VPN

Virtual Private Network

WCF

Windows Communication Foundation


Pagina 15 van 15

Remote Monitoring & Diagnostics

Recommend Documents