A practical approach SCADA HMI monitoring industrial automation Rodrigo García García Mr Ph.D Candidate

Software Engineering Laboratory Swiss Federal Institute of Technology Lausanne (EPFL) CH-1015 Lausanne Switzerland rodrigo.garcia@epfl.ch http://lgl.epfl.ch/members/~rodrigo

Rodrigo García García is a Telecommunication Engineer from the Technical University in Madrid. He is currently doing his PhD studies in the School of Computer and Communication Sciences of the Swiss Federal Institute of Technology Lausanne (EPFL). His collaboration with ABB Switzerland led him to study the applicability of SVG Scalable Vector Graphics for developing operator interfaces for the industrial automation domain. Esther Gelle Ms Dr ès Sciences EPFL

Information Technologies Dept. ABB Switzerland Ltd Corporate Research CH-5405 Baden-Dättwil Switzerland

In this paper, we study the applicability of SVG to SCADA Supervisory Control and Data Acquisition systems. One of the main purposes of a SCADA application is to provide an operator with the graphical interface needed to monitor and control the production processes in an industrial plant. Currently, most SCADA systems are based on bitmap graphics or proprietary vector formats to build the operator's interface. We investigate here the advantages and some of the emerging technical challenges of using a web standard such as SVG for developing the graphical components of a SCADA system and how to connect these components to the data sources that determine their appearance.

The term SCADA defines a computer system used for gathering and analyzing real time data coming from industrial processes. SCADA systems are used to monitor and control a plant or equipment in industries such as water and waste control, energy, oil and gas refining, pulp and paper etc. While many of the tasks of a SCADA system do not need user interaction, some of them require the supervision or the actuation of a human operator. The operator's interface plays therefore a very important role in a SCADA system. All relevant information has to be shown to the operator in a clear and convenient way, conforming to current standards in process display graphics. This part of a SCADA system is commonly known as the HMI Human Machine Interface . An important role in the context of an operator interface play the various symbols as defined in . In order to represent a motor, for example, the motor symbol shown in is used. The motor symbol consists of circle with a border containing the uppercase letter M standing for motor. Additionally, the symbol may be framed by a rectangle. The color of the circle, its border and the letter as well as the color of the rectangle and its border are defined by the state (off, on, alarm) of the device representing the motor symbol. A motor in on or run status for example will be represented by a green circle with a black border and a black letter M. The off status will simply make the background color of the circle change to grey. The alarm status on the other hand will be represented by the motor symbol in off status framed by an orange rectangle with black border. As shown, the motor symbol consists of various subcomponents that have a shape and that are assigned colors. However, the motor symbol is always handled in its entirety, it is placed, removed, clicked on by operators and engineers as a whole. In addition, each company may use its own color scheme in a systematic way. Therefore, such process display graphics require means for combining graphical root elements into symbol libraries and means for applying various standardized color schemes to these symbols. Some parameters such as the size of symbols should be applied to a symbol library as a whole in order to guarantee a standard look and feel.

Symbol	Description
	Motor in off state.
	Motor in running state
	Motor in alarm state.

Nowadays, this field is dominated by the use of ActiveX controls and bitmap graphics. However, we think that there is a chance for SVG to gain acceptance in this market. It is well-known, for instance, that bitmap images do not scale well. If an image is zoomed in, it soon appears "pixelized" to the human eye. Moreover, in order to change the state of a device represented by a bitmap image, it is necessary to load a completely different image file; even if the original image just required a color change to represent the new device state. Vector graphics, on the other side, describe an image by means of primitives such as a line, a circle, a rectangle etc. The image obtained is the result from rendering the specified set of primitives, which are independent of the specific user's display device. Consequently, a zoomed vector graphic does not loose quality, since the final value of the image pixels is calculated each time that the zoom is applied and a vector graphic is usually smaller in file size that its bitmap counterpart. Besides, changing the state of a device is usually simpler with vector graphics than with bitmap images, since it suffices to change a property like the color applied to a line or to a rectangle to get the new device state. In some cases though, it can be faster to replace one bitmap image by another than to change a property in a vector graphic and perform its rendering. However, the vector graphics approach is advantageous from the points of view of modularity, customizability and extensibility. Modularity The change in the state of a device only affects those graphical elements which have to change their properties. These single changes can be combined to represent a wide variety of different states. With bitmap images, one single image is required for each component state. For relatively complex graphical components, the combination of all possible values of graphical properties such as color, opacity or stroke thickness can lead to a state explosion, requiring lots of bitmap files just to be able to represent all the possible states of a component. Customizability Companies usually have their own standards for expressing the state of graphical components. Although there is a generally accepted use of specific graphical properties for representing a determined state, such as the use of the red color for showing an alarm state, the concrete graphical properties applied by one company can be subtly different from those used by another. A component delivered in an open vector format can have its state properties easily customizable by the user, since they can be directly exposed. On the other hand, a component delivered as bitmap images has to be edited with a graphics tool for being able to modify it. Since it is the pixels of the image which are directly modified, even for simple changes it can be difficult to get the desired results (e.g. changing stroke thickness). Extensibility Similarly to customization, it is easier to extend the number of possible states of a vector graphic than those of a bitmap image for almost the same reasons explained above. Many modern HMI displays are built using ActiveX controls. This technology relies on COM Component Object Model , a component framework by Microsoft, and on the programming languages that can be used to build COM components, especially C++ and Visual Basic. ActiveX controls can include Windows forms, bitmap images or vector graphics for their visual appearance. Many companies in the industrial automation field have developed their set of symbol libraries for HMI based on ActiveX controls. The graphical quality of these controls may vary widely depending on the quality of the graphical libraries used. Typically, the interfaces based on vector graphics are built procedurally using the primitive functions of GDI Graphics Device Interface , a graphics Windows API, contrasting with the declarative nature of SVG. GDI, however, also allows to store vector graphics in metafiles which can later be processed calling the appropriate library functions. This mechanism allows the development of drawing tools able to load, manipulate and save metafiles, keeping the user from directly programming the graphical library. ActiveX controls, like SVG, can also be embedded in web pages, but only a Windows system with Microsoft Internet Explorer will be able to show them. This is one of the most important drawbacks of ActiveX technology: it is proprietary. Besides, ActiveX controls execute native Windows code, posing serious security problems to web users. In any case, ActiveX is a successful technology in the HMI domain thanks to the ubiquity of the Windows operating system, the maturity of COM and the relative easiness to script ActiveX components with Visual Basic.

One of the ideas behind SVG diffusion is that each domain community would develop libraries of graphical symbols to meet their needs. The ]]> tag allows to reuse the symbols defined in the same or other SVG files. These SVG fragments can then be combined to form control-flow diagrams, electronic circuits, UML class diagrams or any other domain specific drawing. Industrial automation is one of the fields where a graphical components infrastructure is certainly useful, as demonstrated by the success of ActiveX components in this domain. Our idea was to verify the suitability of SVG graphics to the needs of industrial automation interfaces. Our original architecture for industrial SVG components was based on four concepts:

Each SVG component is described in a separate SVG file.

Each SVG component is associated to a different CSS style sheet that holds the set of possible states of the component.

Each SVG component is bundled with a piece of Java code (a Javabean) to allow its configuration and define its run-time behavior.

An HMI interface is built from these components by means of the ]]> tag. The Java code would apply a different style to each component, depending on the real-time data received from the plant and the user interaction.

However, we realized that this vision suffers from many problems with the current implementation of SVG and the way CSS style sheets are applied to SVG content. CSS was originally conceived to style HTML pages, not SVG. In a typical web (HTML) page, each tag defines a logical part of the document. For instance, the tag ]]> indicates that the text inside it is a main header. In this case, a CSS style sheet can use a selector h1 to define the style of the text enclosed by a ]]> tag. HTML tags define the logical structure of the document, whereas CSS defines the style of each document structure. In SVG, however, it usually does not make sense to use a selector for a specific tag like in HTML because a graphic document is not a logically structured document. It is generally useless, for instance, to define the style for all the rectangles in a drawing (it would be rather uniform and not in accordance with a specified standard definition of symbols). The simplest and more used CSS selector in HTML pages is therefore rather useless in SVG. On the other hand, HTML has a tag that does not describe the logical structure of its content and it only serves to group other elements. We are talking here about the ]]> tag. Similarly to what happens to SVG tags, it is not very useful to give a single style to all the ]]> tags in a HTML page. It often happens as well that we may want to apply a specific style to different elements of an HTML page, no matter what its tag is. The class attribute makes this possible by associating an HTML element to the specified class. CSS style sheets can define then a selector .classname that applies to all elements of the class classname. This is particularly useful in the case of SVG: we may not want to define a specific style for all the rectangles but only for those belonging to a certain class. In fact, there exists in SVG a tag very similar to the ]]> tag of HTML that only serves to group other graphical elements: the ]]> tag. As it happens with the ]]> tag, the ]]> elements especially benefits from the possibility of being assigned to a class, since it is usually a nonsense to apply the same style to all groups defined in a SVG file. Finally, each element in a SVG or HTML page can be uniquely identified thanks to an ]]> attribute. CSS allows to select a single element by using the notation ]]> and apply the style to that single element. CSS selectors can also be combined to reach specific elements of the SVG or HTML tree. This latter point is very important for our SVG components architecture, as we will see below. The ]]> allows to reference a SVG component defined in the same or in an external file. This tag is the basis of our component architecture. However, the combination of the ]]> tag and CSS has two drawbacks:

The ]]> tag hides the tree structure of a SVG component.

An external component (defined in an outer SVG file) can use a style sheet associated to the external document.

In the first case, that means that CSS selectors cannot access the inside structure of the component, which reduces the usefulness of styling ]]> elements to none but the simplest cases. For instance, we can associate a style to an use element by means of the class attribute. But this style will affect all the subcomponents inside the component referenced by the ]]> tag (at least all those that inherit the style property). It is not possible, for example, to select a subcomponent and give one color to it and, at the same time, specify another color for another subcomponent of the used complex component. In the second case, the problem comes from the fact that the external style sheet is unknown to the hosting document: it is importing the SVG component but not the style sheet. In our original architecture, we proposed to have a different style sheet per SVG component. However, we have just seen that the style sheet defined for one SVG component is not automatically imported by another SVG file using the component. Therefore, the style sheet has to be manually imported into the SVG file, but even adding it manually does not solve all the problems. CSS is not namespace aware and it was not conceived to be applied to fragments of a document but to a document in its entirety. The mechanism used to link a XML file to a style sheet only allows one style sheet per document. If all the components used by a SVG file come with their own set of states defined in a different CSS file, there is still the possibility of importing all the CSS files by using the import command within the ]]> element. However, the selectors names can clash or be combined following the cascade rules of CSS. The result is that each component defined styles are not guaranteed to be kept separated when combining the CSS files where they are declared.

Although the concept could seem interesting in the beginning, our original architecture is not valid with the current implementations of SVG and CSS. The facts that style sheets are applied to whole documents rather than to specific components and that the full SVG tree of a component is hidden when it is used in another SVG file really limits our vision of how a component infrastructure could be built upon SVG and CSS. We shall follow the evolution of SVG with the arrival of SVG 1.2 and RCC Rendering Custom Content , an extension to SVG that allows user defined XML to reference SVG content and that serves primarly to create GUI widgets. RCC exposes the internal structure of the graphical components by means of shadow trees and it will probably make possible to apply styles in a component based way, instead of the document based way of CSS. We will follow as well the evolution of different markup languages to define GUIs such as XUL XML User-interface Language and XAML XML Application Markup Language , on which RCC seems to be inspired. We are sure that XAML will be a particularly important competitor of SVG on Microsoft platforms since, opposite to XUL, it also includes all the necessary to create high quality vector graphics.

During the realization of this project, we have tested three tools for visualizing our SVG components: Corel SVG Viewer 2.1, Adobe SVG Viewer 3.0 and Batik Squiggle 1.5.1 (). The two former viewers have been developed by well established firms in vector graphics and computer graphics in general and they are distributed as plug-ins for different web browsers. The latter viewer is a Java application developed by the Apache Software Foundation and it is distributed as part of the open source Batik project. The Batik toolkit provides the necessary libraries to generate and manipulate SVG content from Java programs, as well as some utilities to transform SVG to raster formats (PNG, JPEG...). All three viewers have a similar rendering quality and they all support JavaScript/ECMAscript for user interaction, although Adobe SVG Viewer is the only one that provides SMIL Synchronized Multimedia Integration Language based animation. Nevertheless, there were two viewer features that we considered particularly important for our project: the ability to link to external SVG resources and the possibility of using a compilable and modular language for scripting. One of the main goals of this project was to demonstrate wether it was possible to build an operator's interface by using SVG component libraries. That is why it was very important to have a SVG browser that allowed links to SVG content located in external files. Adobe SVG Viewer does not render SVG fragments located in external SVG filesThe pre-release (beta version) of Adobe SVG Viewer 6.0 does allow links to external resources.. Squiggle is the most flexible: allows external links and scripting in the Java programming language as described in Appendix D of the SVG 1.1 specification. Besides, Squiggle can be configured to restrict access or not to external resources, to enable or disable scripting or to allow or not the scripting language to access the file system or the network.

Comparison among available SVG viewers.

	Adobe SVG Viewer 3.0	Corel SVG Viewer 2.1	Batik Squiggle 1.5.1
External SVG resources	No	Yes	Yes
Java Binding	No	No	Yes
SVG/SMIL animation	Yes	No	No
Browser plug-in	Yes	Yes	No

ANSI/ISA-S5.5 Instrument Society of America (ISA), ANSI/ISA-S5.5 Graphic Symbols for Process Displays, 1985. Bézaire 2003 Benoît Bézaire, The Next Generation of SVG Files: SVGFragments, Proceedings of the 2nd Annual Conference on Scalable Vector Graphics, SVG Open 2003, July 2003, Vancouver (Canada). Avalilable: SVG 1.1 W3C (MIT, ERCIM, Keio), Scalable Vector Graphics (SVG) 1.1 Specification, 2003. Available: SVG 1.2 W3C (MIT, ERCIM, Keio), Scalable Vector Graphics (SVG) 1.2, Working Draft, 2004. Available: Adobe SVG Viewer Adobe Systems Incorporated, Adobe SVG Viewer, 2004. Available: Corel SVG Viewer Corel Corporation, Corel SVG Viewer, 2003. Available: Squiggle The Apache Software Foundation, Squiggle - The SVG Browser, 2002. Available: