9. Process Images / Visualization

The runtime visualization can be operated either as a standalone application or in a web browser. For each licensed user interface (control station), several autonomous display modules can be opened in parallel. Thus, in multi-monitor operation, an alarm screen can always be opened on one monitor, the plant overview always on another, and the currently operated process image on a third.

The integrated zooming and panning can either be initiated by the user himself with the mouse or via buttons. An automated specification via an algorithm (depending on process sizes) is also possible. The 8 display levels can be individually switched on or off depending on the current zoom level (cluttering/decluttering). The internal representations of process images and symbols are vector graphics, which allow a constant display quality regardless of the zoom level.

To be able to use large video projection walls efficiently, the expansion of control and process images may also be a multiple of a simple monitor dimension. The theoretical limit is only at 32767 x 32767 pixels. The color display supports both TrueColor and dynamic colors (blinking) for alarm state display. The symbol representation of devices can be created by the user in the form of a reusable object (Typical) together with the associated control and information dialogs. In general, each device object in the data space corresponds exactly to one or more graphic objects. These objects are stored in structured, graphical catalogs and can be recognized by a name or a graphical symbol representation. The insertion and placement in overview, plant, and detail images is done with the mouse by dragging & dropping (Drag&Drop).

Changes to the data model, the symbol representation, or in the control and information dialogs only need to be made once in the template object (reference). All symbol representations already present in process images change automatically. Symbol representations can be built up cascaded hierarchically, while the inheritance of properties as previously shown continues to apply.

The following graphic objects for building your own symbols (references) are provided: Line, multiple line, freehand line, polygon, ellipse/circle, circle/ellipse segment, circle/ellipse sector, circle/ellipse section, arc, simple text, button, cascade button (menu), pop-up, text field, selection list, combo box, check box, radio box, spin buttons, table, trend, bar trend, clock / date display, tabs, frame, ActiveX control.

The following types of animation are provided by the system: Foreground color, background color, hover color, visibility, operability, rotation, scaling (size change) x/y, position (movement) x/y, geometry, both angles in arc/sector/segment/section, display of static image files, dynamic display of image files (image change), animated image files, video, movement of objects along freely definable paths, text/value, font/style/size.

The following external graphic formats can be integrated into process images and symbols: GIF, Animated GIF, BMP, XPM. The additional integration of the vector formats WMF and EMF allows the transfer from almost all CAD applications (AutoCAD, MicroStation, Smartplant and similar tools) and clipart libraries. Several hundred automation technical illustrations are already available as a finished graphic library in the system.

The total number of process images per project is only limited by the available disk space.

The system should be able to display PDF files integrated into its interface. If PDFs are used in the user interface, it should also be possible to jump to defined anchor points in the document based on the integrated EWO.

To support the operator in process control, all process images can be positioned hierarchically in a tree view. For this hierarchy, automatic navigation elements (Tree View, Direct Selection, List, …) as well as automatically generated total messages are provided. This means that all alarms of a subordinate process image are represented in a higher-level process image by a total alarm display without additional engineering effort. This tree view should also make it possible to generate identical process copies for new structures. After creation, these should be inserted hierarchically into the tree view.

Through automatic panel generation, panel files can be dynamically generated and saved. Shapes and objects as well as caching settings can be added using scripts.

9.1. Style Sheets, Widgets, Color Schemes, and Icon Sets

By using widgets, special functions and display variants can be integrated into the user interface. Among these possibilities should be tables, charts, menu trees, EWOs, bar charts, heat maps, progress bars, as well as embedded modules. EWO stands for External Widget Object and describes a special support to integrate third-party widgets into the user interface.

Personalized style sheets (CSS) can be defined for individual designs for a complete SCADA project or for certain subareas and displays. Style sheets allow the personalization of the appearance of widgets and applications in addition to the attributes defined in the graphical interface. The concepts, terms, and syntax of the style sheets are strongly inspired by cascading HTML style sheets (CSS), adapted to the available widgets. Style sheets are an addition to the current widget style and can support the development of an optimized “look and feel” for the desired applications for easier operation.

In the CSS stylesheet, the use of system-native color names should be enabled. This allows a consistent use of terms and there is no need to always refer to different standards.

During runtime, an adjustment of color schemes (e.g. day and night colors) should be possible, which can be switched event triggered. With the activation of the respective color scheme, the colors in all opened panel files are updated by the newly chosen color and redrawn. Several color schemes can be created and switched between.

It should be possible to use editable icons that can also change with changes in the design specifications. This should also be offered as part of the basic software and this behavior should be activatable and deactivatable. In defined cases, it should also be possible to choose static icons based on predefined design guidelines in the user interface. The change between static and changeable icon sets should be possible during runtime.

9.2. Animations of graphic elements

• Every graphic property can be animated

• Extensive functions for controlling animations are available

• Creation of animation groups

The modules can move in real time. The following functions are provided in addition to directional animations:

• Change of visibility / transparency of modules

• Change of size of modules

• Definition of animation duration

• Definition of different animation curves

9.3. Responsive Design and Graphic Requirements for Applications

The solution should support responsive design, which enables the implementation of designs on a wide variety of end devices with a wide variety of display aspect ratios. These settings should be instantiable and can also be set up graphically.

To meet the requirements of modern user interfaces and to use the possibilities of the latest screens and displays, the chosen solution should support layout management. In this context, it is also essential to provide a possibility for zooming in the corresponding area.

In addition to common resolutions, special attention should be paid to the support of FullHD (1920 × 1080 pixels), Ultra HD (3840 × 2160 pixels) and 4K (4096 × 2160 pixels). A mix of different display sizes must be supported and the system must start the correct display according to the specifications for the format in the sense of responsive design.

9.4. Multilingualism and Font Language Support

The system supports simultaneous multilingualism of the control stations of a project. Each user can be assigned a preferred language according to their login. In addition, the language can be changed online, during operation, in a process image.

The system must be able to create projects in the standard utf8 for the use of characters. By using the Unicode UTF-8 encoding, characters and symbols from all languages can be displayed simultaneously within a text.

An individual font and size can be chosen for each language. The font size should be defined in pixels and not in points. A representation of Far Eastern character languages is just as possible as the visualization of Cyrillic or Arabic character sets. For each project, it is necessary to define the same languages at each station and in each project component so that communication remains possible. Country variants (e.g. English USA and English UK, German Germany, or German Austria) count here as a different language and therefore the same variant must be chosen.

By using dictionaries in the program and by supporting the import of a predefined language library, all text parts in the user interfaces can be translated by simple language selection during operation. The import of the various language texts can be done collectively or defined or supplemented on the object if necessary.

A native translation tool should be available in the program to reduce engineering effort and at the same time enable easier administration of multi-language interfaces.