Operate - Observe - Control
with embedded graphics

Designing and creating graphical user interfaces made easy

Time is money! With the innovations in XiBase9, a proven embedded graphics system for industrial applications, you will reach your goal faster. Sophisticated graphical user interfaces, which enable ergonomic and functional machine and device operation under Linux, Windows or common real-time operating systems, are created quickly and efficiently.

We will show you these innovations at the Embedded World 2020 in Nuremberg, from 25.2.-27.2.2020 in Hall 4 / 4-338, as a co-exhibitor at the booth of the entrepreneurs' association Embedded4You e.V.

From design to functional, animated screen masks in record time

Today, functional diversity alone hardly leads any graphics program package to success in the market. What is important is the operability, the ergonomics of a user interface and thus the manageability of a machine.

You can achieve results faster with this approach:

After an in-depth analysis of the tasks of a machine, the operating concept is created as a result. This is then implemented in the form of user-dependent screen masks and possibly a click dummy. This makes it possible to get to know or document the new operating concept depending on the user role.
Once this conceptual work has been completed, the work of the software programmers begins, who must now bring the static proposals to life. At the moment, it is still very common to provide screen masks as rasterized images to the developer. Generating animated individual objects from these screens is a challenge and often only possible with a lot of effort.
The tools of the designers can also provide the screen masks as vector graphics, without additional effort. The SVG format (Scalable Vector Graphics) is preferred here. It has a wide distribution and can be used immediately in most browsers. The graphics platform XiBase9 and the associated tools also support SVGs.
The developer will break down the supplied screen templates into logical objects, link them to tasks and reassemble them into final screen templates.
A prerequisite for efficient processing of screen masks is their construction from individual vectors. With the vector editor, the templates are imported and objects are separated in a few easy steps.
Objects often must fulfill certain dynamic properties. For example, a pointer object is expected to allow the pointer to move. This can be done playfully, without any programming effort, using the vector editor. The result is an object which is dynamized via freely definable animation inputs. These inputs can be linked with variables from a middleware and thus display states of a machine or, if desired, also change states of the machine. The assembly of the masks and the linking with the variables from the middleware is carried out with the HMI editor from XiSys.

Support of modern HMI concepts with middleware

The middleware enables the complete decoupling of hardware, sequence program and visualization by data abstraction. Several different middleware platforms can be integrated simultaneously. Furthermore, this technology allows easy adaptation to any existing company-specific middleware.

The variable model of the middleware can be adapted in a wide range. In the simplest case, a variable can only serve as a source for a display value. However, it could also take over more complex tasks, such as scaling via limit values, automatic unit conversions, function generators, diagrams, controlling the visibility and operability of objects.

Modularity

Starting with version 8, a modular concept was introduced. It enables the execution of additional visualization modules in container objects, similar to iFrames in a browser. Visualization modules can be either single screen masks or complete independent visualizations. Thus, interfaces can be composed of function modules individually.

High-performance graphics with gesture control on slim devices

For touch applications with gesture control, a Raspberry Pi, for example, is already sufficient. The required RAM for this is no larger than 256 MB and the required storage space on external media is less than 50 MB.

Customizable output format

Preferably, vector graphics are used for a new design. This makes it possible to define or change the final screen resolution and, within certain limits, the geometry later. The graphics server supports different scaling factors in X and Y direction if required. Thus, surfaces developed for a HD screen, for example, can also be displayed on a 4K screen without any problems.

Distributed systems in networks and WAN

All visualizations can be distributed with a display redirection to different systems in the network. Since version 7 a, the web server is integrated in the graphic server. This extension enables the visualization to be executed in any browser. No special modifications or APP installations are necessary.

Visualization of a heating system using a browser. No cookies or additional apps are required for a browser-based display.

Conclusion

With the newest version of XiBase9, programming is replaced by configuration. The advantages are obvious: "faster project implementation, simplified maintainability and cost savings", says Klaus Gerstendörfer, Managing Director of XiSys Software GmbH.

Local user interfaces -
available everywhere

This article is currently only available in German.

Ein performanter Ansatz, um unabhängig vom Endgerät zu werden

Die Ansprüche an die Benutzeroberflächen von embedded Systemen steigen mit der Einführung von IoT und Industrie 4.0. Existierende lokale Bedienoberflächen sollen möglichst ohne Probleme und Aufwand auf nahezu jedem denkbaren Endgerät, vom Smartphone bis zum Laptop, dargestellt werden können. Dazu wird üblicherweise die Bedienoberfläche als Webanwendung gestaltet und damit die Visualisierung der Oberflächenlogik auf den Webbrowser verlagert.

Embedded Systeme im industriellen Umfeld müssen in vielen Fällen direkt an der Maschine bedient werden und verwenden daher eine stationäre Bedienoberfläche. Zurzeit sind solche Anforderungen durch eine klassische Grafiklösung, basierend auf einem lokalen Grafikserver und lokaler Grafikhardware, am effektivsten abbildbar. Im Zuge von IoT und Industrie 4.0 tritt jedoch immer häufiger die Forderung nach Weboberflächen oder Remotefähigkeiten via browserbasierten Lösungen auf. Mit der Einführung von HTML 5 und den immer leistungsfähigeren Grafikmöglichkeiten kann nun dieser Forderung genüge getan werden. Man muss sich jedoch bewusst sein, dass webbasierte Lösungen von der technischen Seite einen erheblichen Mehraufwand bedeuten und auch schwieriger gegen Angriffe von außen abzusichern sind. Soll eine lokale Browserlösung implementiert werden, so steigen die Anforderungen an die benötigte Hardware erheblich und sind im industriellen Umfeld kommerziell oft nicht mehr darstellbar.

Remote-Desktop mit VNC, RDP, ...

Die gängigste Methode eine lokale Grafik weiterzuleiten ist die Verwendung einer Remote-Desktop-Software. Für unterschiedliche Betriebssysteme stehen Lösungen wie VNC (Virtual Network Computing), RDP (Remote Desktop Protokoll) usw. zur Verfügung. Auf dem embedded System muss ein entsprechender Service laufen, der die Inhalte des Videospeichers oder eines Framebuffers auf Änderungen untersucht und diese mittels eines geeigneten Protokolls an das Visualisierungsgerät weiterleitet. Auf dem Anzeigegerät muss immer ein entsprechender Empfänger installiert sein, der die Daten entweder in einem eigenen Fenster oder in einem Browser visualisiert. Da weder der Ort noch der Zeitpunkt von Änderungen genau vorhergesagt werden können, ist ein relativ hoher Aufwand nötig, um die Änderungen zu erfassen. Kleinere Systeme kommen hier relativ schnell an ihr Limit.

Remote via HTML5

Mit den Möglichkeiten die HTML5 bietet, kann auch eine Web-basierte Remote-Visualisierung realisiert werden. Diese übernimmt die Aufgaben einer Remote-Desktop-Software und kann auch als reine Webvisualisierung funktionieren. Die Applikationslogik verbleibt immer auf dem embedded System. Die Aufwendungen für das Zeichnen verschieben sich dann je nach Einsatz vom embedded System zum Anzeigesystem. Nach erfolgreicher Verbindung erhält der Browser ein Regelwerk in Javascript, welches Befehle, die der Webserver versendet, zur Laufzeit interpretiert. Der Browser erhält so die Grundfunktionalität einer externen Grafikkarte. Dieses Konzept erfordert auf der Anzeigeseite keine Apps, Plug-Ins oder Cookies.

Websockets vs. http oder warum HTML4 nicht als Plattform geeignet ist

Mit HTML4 war nur http-basierte Kommunikation möglich. Das heißt bekanntermaßen, dass eine zustandslose Verbindung, mit diversen "Hacks" wie AJAX simuliert werden musste. Mit Websockets wird eine permanente Full-Duplex Verbindung mit einem im Vergleich zu http nicht existenten Overhead ermöglicht. Diese Eigenschaften des Protokolls ergeben zudem eine extrem geringe Latenz im Millisekunden-Bereich und öffnen damit die Tür zu Echtzeit-ähnlichem Verhalten der Benutzeroberfläche. Durch die Websockets-basierte Kommunikation ist die Animation der grafischen Objekte nahezu in Echtzeit möglich.

Konzept

Mit Augenmerk auf eine möglichst performante Visualisierung muss unnötiger Kommunikations-Overhead zwischen Grafikserver und Webserver vermieden werden. Der Webserver muss in möglichst kurzer Zeit und mit möglichst geringem Aufwand Zugang zu den Änderungsinformationen erhalten. Der effektivste Weg dorthin, besteht darin, den Webserver als integralen Bestandteil des Grafikservers zu realisieren. In diesem Fall können Änderungen ohne nennenswerten Zeitverlust vom Grafikserver an das Anzeigegerät weitergeleitet werden.

Eine weitere Effektivitätssteigerung wird durch Strukturieren der Webseite im Browser erzielt. Solange nur gerasterte Bildinformationen aus dem Videomemory an das Anzeigegerät weitergeleitet werden, genügt ein Canvas-Element für die komplette Darstellung. Scrollen, Verschieben oder Löschen von Objekten wird in diesem Fall mit sehr hohem Datenverkehr erkauft. Die Effektivität steigt deutlich, sobald für jedes Objekt ein eigenes Element angelegt wird. Der Grafikserver sendet dann - je nach Anforderung - gerasterte Bilder oder skalierbare Vektoren in Form von SVGs, die das jeweilige Objekt beschreiben. Die Aufwendungen für das Zeichnen verschieben sich damit mehr auf die Browserseite. Als angenehmer Nebeneffekt verringert sich die zu übertragende Datenmenge. Der Browser setzt aus den überlagerten Elementen das Gesamtbild des Displays oder einer Applikation zusammen. Um z.B. ein Objekt zu verschieben, muss nur die entsprechende Koordinate des jeweiligen Elements im DOM-Baum angepasst werden.

Hybrid-Grafik-Server

Die Firma XiSys Software hat einen Grafikserver entwickelt, der nicht nur über einen integrierten Window- und Objektmanager verfügt. In der neuesten Version ist auch die Funktionalität eines Webservers implementiert. Mit dem Objektmanager ist der Server in der Lage, einen hierarchisch strukturierten Objektbaum aufzubauen und zu verwalten. Sobald sich ein Teilnehmer über eine Websocket-Verbindung anmeldet, wird die komplette Objekthierarchie aller auf einem Display dargestellten Objekte als DOM-Baum im Webbrowser abgebildet. Im DOM-Baum stehen in Abhängigkeit der Objekteigenschaften für jedes Objekt ein oder mehrere Canvas-Elemente oder SVG-Elemente zur Verfügung. Jedem Element werden automatisch individuelle Eventhandler zugeordnet, welche die Eventeigenschaften des Objektes am besten unterstützen. Z.B.: Beim Berühren eines Eingabeelementes wird automatisch ein Softkeyboard eingeblendet, das Element wird, falls nötig, in den sichtbaren Bildausschnitt geschoben und die Tastatureingaben an den Webserver weitergeleitet.

Ist im lokalen System keine Grafik-Hardware vorhanden oder soll nur eine Applikation im Browser visualisiert werden, kann der Browser auch eine asynchrone virtuelle Visualisierung anfordern. In diesem Fall wird ein Klon des Hybrid-Grafik-Servers erzeugt. Anstelle ein Objekt lokal zeichnen zu müssen, wird aus der Verktorliste ein SVG-Element abgeleitet und an den Browser verschickt. Der Browser übernimmt nun alle Renderaufgaben. Das embedded System kann sich hierbei auf reine Verwaltungsaufgaben beschränken - was natürlich dem Ressourcenverbrauch sehr entgegenkommt.

Performance Aspekte

Um eine hohe Akzeptanz der Bedienoberfläche zu erreichen, sollte diese ohne Verzögerungen auf Eingaben reagieren. Bei statischen Bildaufbauten ist dies kein Problem. Komplexe animierte Grafiken sind dagegen eine Herausforderung. Um flüssige Animationen und gleichzeitig schnelle Reaktionen auf Benutzereingaben zu gewährleisten, muss das Hauptaugenmerk auf einen möglichst hohen verzögerungsfreien Datendurchsatz gelegt werden. Latenzzeiten, verursacht durch lange Signallaufzeiten, schlechte Verbindungen oder die Überlastung eines Anzeigesystems müssen unbedingt vermieden werden. Daher darf weder der Server noch der Browser auf eine Quittierung eines abgesetzten Befehls warten müssen. Solange die Netzverbindung schnell genug ist und das Anzeigesystem die eingehenden Kommandos schneller bearbeiten kann als neue ankommen, läuft alles rund. Die Praxis zeigt, dass vorwiegend bei mobilen Geräten bisweilen Performance-Probleme auftreten können. Diese äußeren sich in erster Linie durch langsame Reaktionszeiten. Um dem entgegenzuwirken, ist es notwendig, im Webserver einen Algorithmus zu implementieren, der erkennt, welche Gesamtverzögerungszeit aufgrund von aufgestauten Befehlen zu erwarten ist. In Abhängigkeit dieses Ergebnisses muss dann die Abarbeitungsgeschwindigkeit des Grafikservers angepasst werden. Dieser Algorithmus wird auch zur Synchronisation mehrerer paralleler Anzeigegeräte verwendet.

Implementierungsaufwand

Ein bestechender Vorteil des hybriden Grafikservers ist der geringe Aufwand bei der Entwicklung mobiler Anwendungen. Die Benutzeroberfläche muss nur ein einziges Mal entwickelt werden, die Adaption an unterschiedliche Endgeräte wird vom Grafikserver automatisch geleistet. Es ist nicht erforderlich, eine parallele Infrastruktur mit den dabei anfallenden Entwicklungsaufgaben zu erstellen.

Alle Vorteile im Überblick

• Für die Visualisierung in einem Browser werden weder eine App, Plug-Ins oder Cookies benötigt. Die Visualisierung hinterlässt keine Spuren.
• Visualisierung mehrerer Systeme in iFrames möglich.
• Durch die Vorhersagbarkeit und Eingrenzbarkeit von Änderungen wird das zu steuernde System nur minimal belastet.
• Der integrierte Webserver kann quasi ohne Zeitverlust auf bereits gerenderte Daten zugreifen und diese sofort verteilen.
• Die Organisation eines DOM-Baumes für alle Objekte ermöglicht es, Bildschirmmasken vom Browser zusammensetzen zu lassen. Entfernen, Verschieben und Scrollen von Objekten wird vom Browser übernommen.
• Das Verwenden von SVGs erspart das Rendern von Objekten seitens des embedded Systems.
• Es können asynchrone virtuelle Sessions gestartet werden, die z.B. nur den Zugriff auf eine Applikation erlauben.
• Der Programmierer muss sich nicht um die Inkompatibilitäten verschiedener Browser kümmern. Er entwirft mit einem GUI-Builder nur einmal seine Bildschirmmasken. Diese werden dann lokal und im Browser identisch abgebildet.

Fazit

Das vorgestellte Konzept besticht durch seine Flexibilität. Damit können sowohl die Aufgaben eines lokalen GUI und einer Remote-Desktop-Software als auch Visualisierungen, welche nur eine Web-basierte Anzeige unterstützen, realisiert werden. Das GUI ist für alle Szenarien identisch. Der Programmierer muss sich nie mit den Techniken unterschiedlicher Anzeigesysteme auseinandersetzen.

Web visualization

WEB based Machine Operation by Smart Devices and locally by a regular HMI

IoT and Industry 4.0 require new approaches to operate machines. In addition to local human machine interfaces at the machine, web based services to manage and survey functions remotely are a key ingredient to move forward in industrial automation applications. Fast reliable and secure communication infrastructures, established browser technology and smart devices are the foundation for location independent man machine interaction. A technological challenge hereby is to create a local and browser based visualization to accommodate typical embedded systems. They are usually not designed as power horses for compute intense graphic applications. For that XiSys, known for its industrial proven embedded graphics solution XiBase 9, has developed a hybrid server which combines both functionalities very efficiently.

The hybrid server supports local embedded graphic platforms and in addition, WEB based display and interaction on smart devices. To achieve this into the local graphic library a WEB server has been integrated.

Innovative enhancements of XiBase9 offer now the option to operate a machine locally or on smart devices supporting standard browser like Edge, Chrome, Firefox, Internet Explorer, Opera or Safari. Secure access is guaranteed by SHA1 encryption technologies.

Since HTML5 software standards like WEB sockets, canvas, objects and/or java script are the basis for the enhancements, the smart devices do not require any modifications nor the installation of additional apps, plugins, cookies or a java engine. Furthermore, no traces of usage are left behind on the remote devices. The innovative software architecture creates graphic objects in real time and within different browser environments even concurrently.

Overview on the key features of the new XiBase9 embedded graphic solution:

local visualization on local hardware

WEB based visualization in standard browsers under Windows, Linux, iOS or Android

on smart devices no additional apps, plugins, cookies nor java are required

automatic support of local user interface, e.g. touch, multi touch

supports individual, animated objects

display on up to 25 devices concurrently, local graphics in addition

asynchronous display of single programs in browser

supports completely the concept: visualize without programming

downward compatible

language independent

allows a small system footprint, e.g. low power, high performance, cost effective system designs

local graphics available for ARM, PowerPC and x86 CPU architectures

supported operating systems: Linux, Windows and RTOS Microware OS-9

SPES 2020 - Software Platform
Embedded Systems

SPES 2020 is a BMBF-funded research project to develop a methodology to consistently model-based development of embedded systems.

As part of the national innovation alliance "Software Platform Embedded Systems 2020" solutions for the cross-domain and model-based development of embedded software are worked out. On the premis of a solid mathematical foundation, model-based methods allow the efficient development of embedded systems starting with the initial customer requirements on the design and implementation to verification and certification of systems.
In the research and development 21 partners from industry and academia from all over Germany are involved.

Informationbrochure SPES 2020

Description of the exemplary implementation of a modeling approach for embedded graphics systems by XiSys Software GmbH-E4Y

Model based graphical
development

The complexity of "embedded" machines is increasing. Given the expectations of customers, the impact of the "Consumer world" and the competition, more and more new features have to be added. If, in addition, a graphical interface is required, then the development effort, even for extremely small devices is enormous.

It is therefore obvious to start thinking about alternative development methods. A closer analysis has shown that many devices operate with similar rules and could be developed accordingly. Similar patterns can be mapped in models. They project the tasks on an abstract level and work it from there. Based on these considerations, one can speak of a new method, the "model-based development". An approach that is also supported by the BMBF as part of "Software Platform Embedded Systems (SPES) 2020."

The focus is on a data model that reflects and connects all the components (hardware, software, networking, sensors, actuators, ...) associated with a device on an abstract level. This model is called a software plug. The data model itself represents a completely applicable program which collects and administrates all data of the corresponding components and provides them in an abstract form for further processing - locally or on the network. The individual components have to be adjusted only at the driver level. The amount of work for the programmer is reduced to the mere configuration of the model. The use of a data model saves an enormous amount of time, but it is only the first step in the new development concept. The data provided from the data model are processed with a sequential programm. There is an increasing need to visualize the data and to enable interventions in the program sequence by using a GUI.

The example of a display instrument demonstrates however the tremendous effort and creative abilities which are necessary to meet today's requirements. Due to the widespread use of devices like iPhones with pleasing surfaces are the rising expectations of the customer in the "embedded" environment. A few years ago it was sufficient to use a schematic diagram with a labelled bar or pointer to represent a value, realizable for programmers with reasonable costs. Meanwhile, modern display devices require a much more elaborate presentation. Consumers demands for gradients, shadows, glass effects, etc. exceed the design expertise of most programmers. The significantly higher effort for the mathematical model of such a display object alone is beyond the bounds of proportionality.

The first step is realized

Within the framework of SPES 2020 we have been able to develop a concept that makes programming of display objects unnecessary. Designers can now undertake design and animation.

The following step

The display objects have to be linked with the data from the data model. This logic will also be replaced by configuration in a following step.

We are convinced that it is possible to consistently implement the model-based concept to replace most parts of programming by configuration. The advantages are obvious: faster project implementation, simplified maintenance, cost savings.