Real time monitor in SVG, a use case in Machining Technology HMI

Writing proceedings for the SVG Open 2008 conference

Alex Mufatti

Software Engineer
Mikron Agno SA
PEL


                        Agno - Lugano
                        via Ginnasio, 17
                        6982
                        Switzerland
                        ++41-91 610 6 111
                        ++41-91 610  6 680
                    

Alex Mufatti is the software enginner that coordinates and implements miHMI over customer machines.

Gabriele Sozzi

Project Manager
Mikron Agno SA
PEL


                        Agno - Lugano
                        via Ginnasio, 17
                        6982
                        Switzerland
                        ++41-91 610 6 111
                        ++41-91 610  6 680
                    

Gabriele Sozzi is the miHMI Project Manager.

Marco Beretta

Project Manager
Mikron Agno SA
PEL


                        Agno - Lugano
                        via Ginnasio, 17
                        6982
                        Switzerland
                        ++41-91 610 6 111
                        ++41-91 610  6 680
                    

Marco Beretta is a Senior Software Developer of miHMI.

Francesco Rigillo

Senior Manager
Mikron Agno SA
PEL


                        Agno - Lugano
                        via Ginnasio, 17
                        6982
                        Switzerland
                        ++41-91 610 6 111
                        ++41-91 610  6 680
                    

Francesco Rigillo is the miHMI Team Leader.

Giulio Roggero

Software Engineer Consultant
Isola Software
Software


                        Milan
                        Via Durer, 6
                        20147
                        Italy
                        ++39-02 36 50 96 36
                        
                    

Giulio Roggero is the Architect of miHMI software.

Carlo Ballabio

Software Developer Consultant
Isola Software
Software


                        Milan
                        Via Durer, 6
                        20147
                        Italy
                        ++39-02 36 50 96 36
                        
                    

Carlo Ballabio is a Software Developer of miHMI.

Domenico Fabiano

Software Developer Consultant
Isola Software
Software


                        Milan
                        Via Durer, 6
                        20147
                        Italy
                        ++39-02 36 50 96 36
                        
                    

Domenico Fabiano is a Senior Software Developer of miHMI.

Fabio Ghislandi

Consultant
Fabio Ghislandi
Software


                        Seriate
                        
                        Italy
                        
                        
                    

Fabio Ghislandi is a Machining Technology consultant for miHMI.


Table of Contents

Introduction
Architecture & Implementation
SVG Page Load
SVG Live Data Management
Stencils
Configuration
Lesson Learned
Performances
Real Application
Conclusions
References

miHMI is a product developed by Mikron Agno SA, designed to provide a new HMI framework for Transfer Machines. The primary requirements for miHMI are flexibility and adaptability because it must be installed on the several different lines of products that the company sells. Moreover each customer may customize the miHMI pages to satisfy his production needs.

To reduce time and costs miHMI should provide also a simple configuration editor that allows, without programming skills, to simply design pages for controlling and monitoring the machines.


Mikron Agno SA imposed some constraints in technologies and infrastructure:

  • All communication between components must use TCP/IP as transport protocol and in particular HTTP for user interfaces to allow the remote monitoring of the Machine through the Internet.

  • Adopt .NET technologies for server side and run over Windows XP/Vista/2003 Server.

  • Adopt IIS as web server.

  • Adopt Microsoft SQL Server as DBMS.

  • Provide a User Interface adaptable for both touch screen and normal LCD screen with sizes from 12’’ to 17’’.

  • Guarantee a latency from the Machine to the user interface below 300 ms.

  • Allow pages configuration using Microsoft Visio.

  • Allow machines configuration using Microsoft Excel.

  • Integrate on the user interface 3rd party ActiveX and 3rd party stand alone programs.

These constraints have been the main requirements for miHMI. The user interface layout has been the subject of several meetings and prototypes because it must be suitable for industrial environments, usable with a touch screen and it must always show the most important data regarding the actual working state of the machine. The Fig. 2 shows the layout.


The Main Bar is always present on the screen and shows the main data and messages, warnings and alarms of the machine. The Side bar allows starting the navigation of SVG pages or running a standalone application that is constrained inside the content area. The Status bar is complementary to the main bar and shows other useful information such as the machine doors status.

On one side (WPF), the integration of WPF and SVG allows to manage standalone applications in an easy way and to get full control of the desktop; on the other side (SVG) it allows to design new miHMI pages very quickly without writing source code. These technologies both support vector graphics and therefore satisfy the constraint of scaling on screen resolution.

Even if miHMI is a big project, about 10 years’ work, this paper will focus only on the SVG aspects of miHMI. The next chapters cover the SVG engine architecture, the user interface and performances.

miHMI is a complex project where SVG plays a crucial role for customizing and rendering live data on the screen. Behind the SVG there are four tiers that abstract the Machine and provide the data asynchronously each time any value from the field changes.

The idea behind miHMI architecture is to identify each field data of the Machine using an auto-explain dotted notation called Alias. For example the status of a door, represented by the bit in the memory address E.101.1 of the PLC, is identified by the miHMI Alias WC01.FK6107.RTDATA.DOOR1.STATUS. This alias is written inside the SVG file using custom properties element. "DATA POINTS & SVG" paragraph explains this mechanism in detail.

By saving that drawing into the web server directory, the engine binds each graphic SVG element configured with an Alias with the PLC/CNC memory in real time. The workflow is the following: when a page is loaded the JavaScript calls via Web Service a method called Subscribe. This method propagates a Subscribe Message to the server side registering the subscription to the Driver. Each time the subscribed Alias changes its value, the driver sends a Change Of Value message that is routed to the Web Server. The JavaScript polls the Web Server and when new values are ready it updates the SVG Page.


The communication between tiers differs depending on the tier level:

  • Machine to/from Monitor Driver Plug-in: use OPC or custom dlls provided by the manufacturer.

  • Monitor Driver Plug-in to/from Server Plug-in: Message Queue with publish/subscribe pattern.

  • Web Server/Web Services to/from Server Plug in/ Monitor Driver Plug-in: Message Queue with publish/subscribe pattern.

  • JavaScript & SVG Player to/from Web Server: web services polling with AJAX.NET.

This chain allows decoupling machine and web server and providing the new values to SVG each time any value changes on the Machine. To improve performances and reduce the workload of the whole application, only the values showed on the SVG page are monitored by the driver. In fact every time the page changes a new subscribe/unsubscribe message is sent to the server in order to load the correct data and reduce the load of the CPU for the data that is no more shown.

Next two chapters explain the two main phases of miHMI SVG page management:

  1. SVG Page Load: how a new page, that represents the live data on Machine, is loaded.

  2. SVG Live Data Management: after a page is loaded, the process to keep data updated and to send commands to Machine.

To allow the navigation through the SVG pages without having to wait for live data to be loaded, the connection with the live data is entirely asynchronous. After SVG page is loaded, as described in the previous paragraph, the JavaScript starts a new process that parses the DOM of the SVG page finding Stencils that define the live elements and in particular the Aliases; then it subscribes all Aliases and waits for new values or, when an onClick event is fired, executes a command.


In detail, the vertical solution is:

  1. A driver abstracts the machine exposing data point called Alias.

  2. The SVG file embeds several Stencils with custom properties. Each custom property identifies the type of the stencil and the Alias to connect.

  3. The Stencil, via JavaScript, subscribes the Aliases to be updated. The subscription passes through a web service that sends a message on the server queue.

  4. The router reads the server queue, saves the subscription and tells the driver to send a message each time the Alias changes the value.

  5. Each time the alias changes the value, the driver sends a message and the router routes the new value to the IIS queue.

  6. Meanwhile the JavaScript, using AJAX.NET libraries, polls asynchronously, via Web Service, with a timeout of 100ms, the IIS queue and get the new message that contains the new value and its quality. The quality is GOOD when the data is still valid, BAD if the read process went in timeout.

  7. SVG Object Model, depending on the type of stencil, prepares the list of JavaScript functions to call. This allows to speed-up the execution and reduces the load on JavaScript side.

  8. The browser gets back a string with the list of JavaScript functions to call. Each function modifies the value or format of the Stencil using DOM.

The miHMI Stencil Library implements several SVG objects that can be added to the SVG just with a drag&drop from an SVG Editor. A Stencil is a SVG group (<g>…</g>) that gathers one or more graphic SVG symbols like a Text, Path, Rect or Ellipse.


 Actually implemented Stencils are:








A set of common configuration can be applied to all stencils:

  1. Changing background color depending on the Alias value.

  2. Changing text color depending on the Alias value (for example a Label can blink when a value on the machine keeps changing or a Link Area that changes the color in function of the Machine value).

  3. Locking/unlocking the stencil depending on the Alias value. If the stencil is a Command, when it is locked, the user cannot execute the command. If the stencil is an Edit Box the user cannot change the value. If the stencil is a Link area the user cannot click on it.

To provide a reliable and trustable monitor we have worked on performances from the beginning. Since January 2007 we have implemented the vertical solution and we have been monitoring the time each tier took.

The test has been performed over a test bench Machine with similar performances of the customers Machines: Pentium V 2 Ghz, 1 GB of Ram, Windows XP sp2, IIS 5, PLC Fanuc. The times are traced using a JavaScript ad-hoc function for the SVG side and a C# ad-hoc function for the server side. The test is replicated 100 times with a SVG pages that monitors 100 Aliases at the same time.

The Fig 16 describes the trend of the 100 tests. The performances are quite stable. In fact the average is 240,21 ms and the Standard Deviation is 67,08 ms.


The Fig. 17 illustrates the average times in relation with the Architecture stack.


For the SVG Use Cases the interesting times are:

  1. PGP4 (178ms , 25 ms in simulation): the SVG refresh time calculated from the Driver to the SVG update

  2. PGP6 (88 ms): the time that takes a command, executed pressing a button on SVG, to arrive to the Driver

The 25 ms for PGP4 means that, if the Driver is simulated in memory, and therefore it doesn’t effect the overall times, the late from the Data to the SVG is just 25ms, near to the perception of the human eye.

In the real case, because of the Driver and the latency of TCP/IP, the time is near to 300ms in line with the constraints imposed to the project.

miHMI was born for Machining Technology applications but can be adopted as a visual control system for several different applications: from the Water Monitor to the Airport Traffic Monitor; from the IT Network Dashboard to Lego Mindstorm remote control.

Actually miHMI is installed on Mikron MFT Machine and Mikron NRG50 Machine (work in progress). We tested, for demo purpose, also an application on Lego Mindstorm.



The miHMI choice to base the monitoring and controlling of live data on SVG pages has been demonstrated as a good approach. The pages, using a tool like Microsoft Visio, are easy to design and the performances are in line with the constraint imposed for these kinds of applications (latency < 300ms). The XML DOM compliant format of SVG and AJAX via Web Service has allowed managing the behavior of the page easily, only using JavaScript keeping the server side and the client side always separated.

The vector nature of SVG has been the solution for screen adaptation: without redesigning pages, miHMI can be viewed over a LCD 12’’ or a 17’’ touch screen: texts and images scale without any problem keeping the quality of the pages always high.

SVG, as a XML file, has been the good choice for automatic page generation with XSLT.

The SVG engine is based on .NET technologies but can be successfully integrated with other technologies like J2EE or PHP that provide, via Web Services, the live data re-implementing the server side of SVG Live Data Management.

The only big issue that is rising with this framework is the technology evolution. XML GUI definition language, such SVG, XAML (WPF), XUL and others are all in competition and choose the perfect technology that fits to all needs is, at the moment, not possible.

We hope that in the near future these technologies will converge in a standard that embrace all peculiarities of the current ones and avoid, to the software designers, the hard task of choosing one of them with the hope that will be the correct and stable solution for the whole lifetime of the application.