Writing proceedings for the SVG Open 2008 conference
Abstract
In this paper we aim to explain how SVG (Scalable Vector Graphics) have been used to implement miHMI: a Human Machine Interface for Industrial Applications. miHMI monitors and controls transfer machines based on PLC/CNC devices. Our approach exploits the use of SVG pages bound through Web Services to the PLC/CNC data. The application must satisfy performance constraints that set the latency time between the change of the value on the PLC/CNC and the visualization of that value on screen to 300ms. We present also a configuration engine based on SVG/XSLT/DOM/.NET C# that allows designing new miHMI pages just using a simple SVG editor without writing a single line of code.
Table of Contents
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.
Figure 2. Fig 2 - miHMI layout: in the center the content area that hosts the SVG page; the other 3 areas are in .NET WPF. The whole User Interface scales on the screen size and resolution.
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.
Figure 3. Fig 3 – Architecture Vision. Four tiers are identified: Driver plug-ins, Server plug-ins, Web Server and Client. Al tiers communicate via TCP/IP. The server side use Microsoft Message Queue and the Client side Web Services.
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:
-
SVG Page Load: how a new page, that represents the live data on Machine, is loaded.
-
SVG Live Data Management: after a page is loaded, the process to keep data updated and to send commands to Machine.
SVG is embedded inside a .NET WPF application that hosts the Internet Explorer (IE) web browser component and the Adobe SVG 3.0.3 plug-in. This allows offering a nice user interface that restricts the access to the Operative System for non authorized users.
Fig. 4 shows the process of page loading: the IE Component load the SVG page using the URL
http://servername/Page.aspx?Alias=<page name>
For example the page that shows the global machine is loaded by this URL
http://servername/Page.aspx?Alias=WC01.MFT0001.PAGES.MACHINE.INFO
Each time the IE points to a Page.aspx URL the Web Server:
-
Loads from the Alias DB the SVG Page name that corresponds to the <page name>.
-
Instruments the SVG adding the link to an external JavaScript (JS) file that allows live data management.
-
Prepares in memory, storing into the user SESSION, the SVG Object Model. This Model is the list of SVG Objects included into the page and is used to update the SVG page when a data from machine changes.
-
Returns the instrumented SVG to the Adobe SVG Player and the related JavaScript.
At this point the JavaScript, via Web Services, loads the live data as explained in the next chapter.
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:
-
A driver abstracts the machine exposing data point called Alias.
-
The SVG file embeds several Stencils with custom properties. Each custom property identifies the type of the stencil and the Alias to connect.
-
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.
-
The router reads the server queue, saves the subscription and tells the driver to send a message each time the Alias changes the value.
-
Each time the alias changes the value, the driver sends a message and the router routes the new value to the IIS queue.
-
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.
-
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.
-
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.
Figure 6. Fig 6 – An Ellipse stencil named shape99-200. On the left the SVG representation, on the right the relative render on browser.
Actually implemented Stencils are:
-
Figure 7. Fig 7 – Label (eg: CYCLE): simple text that changes the value depending on the value of the linked Alias.
-
Figure 8. Fig 8 – Edit Box (eg 12000): editable text box with data validation control. The editing is done using an on-screen keyboard for the touch screen written in JavaScript that interacts with the SVG text element. To identify an editable text a pencil is represented near the value.
-
Figure 9. Fig 9 – Toggle Button (eg: AIR ON): button that sends a command to the machine. A miHMI command is a value written into an Alias and propagated to the Machine. Toggle button can send two different values to the Machine depending on the status of the button: if not pressed it sends a value, if pressed it sends another value. To identify a command a lightning is represented on the button.
-
Figure 10. Fig 10 – Pie: a representation of the Machine table and the status of the stations/units of the Machine. The pie is generated by an XSLT 2.0 transformation that takes machine elements number as input and their corresponding Aliases and returns an SVG page as output.
-
Figure 11. Fig 11 – Multi level Bar: bars are used to represent analog values with thresholds. It’s possible to define the lower and upper limit and the zero and max of the scale. Each time a value is lower or bigger than limits, the bar color changes as configured for the stencil.
-
Figure 12. Fig 12 – Led: it is a colored circle/ellipse that has different colors depending on Machine values.
-
Figure 13. Fig 13 – Link area: shapes that react to the events onMouseOver, onMouseOut and onMouseRelease and simulate the HTML link. All SVG shapes can be used as links. To identify a link an anchor is represented on the area.
A set of common configuration can be applied to all stencils:
-
Changing background color depending on the Alias value.
-
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).
-
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.
A typical setup of miHMI is composed by 10.000 of Aliases and 150 SVG Pages. We needed an automatic configuration tool that sets the Aliases up and generates the SVG pages for a given machine. miHMI Configurator has been developed for this purpose. It receives as input a project file including:
-
Xml configuration files generated by CAD/CAM applications.
-
Parametric SVG Pages templates designed for each Machine line and customizable for each installation.
Processing these files the miHMI Configurator produces as output SVG Pages for the machine and configures the miHMI Database.
The generated SVG pages can be customized with an SVG editor like Microsoft Visio. The user can set any of the available properties that are associated to stencils; properties define the binding between the stencil and the Machine.
Figure 15. Fig 15 – Custom properties visualized by Microsoft Visio and custom properties written inside the SVG file automatically by Visio.
The custom properties are the configuration for the stencil and the reference for the SVG instrumentation and update.
During the implementation of miHMI we faced several problems related to AJAX, JavaScript and SVG. The Internet was the most important source of information and for some problems we found out solutions that can be applied to other similar applications:
-
Interactive SVG elements with text: when the mouse is over, show the text selection. For this trivial problem we apply this approach: for each interactive element, usually a group <g> that contains several elements, we clone the group creating a dummy element that overlaps the real one and that doesn’t contain the text. In this way we can also lock the stencil or overlap the stencil with other colors.
-
Complex graphical forms: Fig.2 shows a “Pie” of the Machine. This pie can be clicked or can change value or color. In order to design the pie we used XSLT that creates the SVG from an XML file that defines the numbers of slices, the color for each slice depending on the Alias value and the link area of slices. The pie is concentric. After the generation the Pie can be modified in Microsoft Visio to improve the look&feel
-
Very complex user interfaces with Data Tables, with sorting and paging functionalities are not easy to implement in SVG and a complementary technology, such Microsoft Silverlight 2, is more appropriate.
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:
-
PGP4 (178ms , 25 ms in simulation): the SVG refresh time calculated from the Driver to the SVG update
-
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.
Figure 18. Fig 18 – Mirkon MFT and Mikron NRG50 are two Machines that mount miHMI for monitor, program and control the whole producion cycle.
Figure 19. Fig 19 – Lego Minstorm control. With the SVG pages it's possible to monitor all sensors and control all motors.
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.