iSyTester – Enge Zusammenarbeit zweier
Firmen im Verein E4You

XiSys und iSyst, beide Firmen sind Mitglieder im Verein E4You e.V., kooperieren und realisieren dabei eine grafische Benutzeroberflächen für den iSyTester – eine kleine Echtzeit-Testplattform.🤝

XiSys ist auf die Entwicklung und die Vermarktung seiner Graphischen User Interfaces (GUIs) für den embedded Markt und hier besonders für kleine und kompakte Systeme spezialisiert.

iSyst ist ein unabhängiges Testhaus und konzentriert sich auf die Funktions- und Qualitätssicherung von embedded Systems.

Der iSyTester ist eine kosteneffiziente und platzoptimierte Lösung für einen Entwickler-Testplatz. Die HW-Auslegung reicht von kleinen ARM9-Systemen bis hin zu Intel-i7-Lösungen. Automatisierte Testabläufe werden via Python und durch einen Touchscreen mit der grafischen Bedienoberfläche XiBase9 des Partners XiSys gesteuert und visualisiert.🧰

Grafische Oberflächen zu erzeugen ist zeitraubend und komplex

Zeitgemäße Anzeigegeräte erfordern zunehmend aufwendigere grafische Darstellungen. Der Markt verlangt zunehmend grafische Oberflächen, die wir aus dem Umgang mit Smartphones und Tablets gewohnt sind. Die Entwicklung solcher komplexen Umgebungen ist von kleinen Teams in Bezug auf Gestaltung, Programmierung und der Integration physikalisch-technischer Maschinenabläufe zu vernünftigen Kosten und in akzeptablen Zeiträumen kaum zu stemmen.

Grafische Oberflächen zügig zu erstellen, ohne aufwendige Programmierarbeiten ist der neue Ansatz.👍

Das Grafik Tool Set XiBase9 wurde so erweitert, dass das Programmieren von Anzeigeobjekten weitgehend überflüssig wird. Das Gestalten (Artwork) und Animieren (dynamisches Darstellen von Maschinenzuständen) kann dabei von einem Designer übernommen werden. Die Verknüpfung der grafischen Objekte mit dem Ablaufprogramm, sprich der Repräsentation der maschinellen Abläufe eines Geräts, einer Maschine oder Anlage, wird in weiteren und getrennten Entwicklungsschritten über Konfiguration realisiert. Ein Spezialist für die Grafik entwirft die Elemente für die Darstellung der Funktionen. Der Fachmann für die Maschinenfunktion programmiert das Ablaufprogramm. Verheiratet werden beide „Fachbereiche“ zur endgültigen Applikation über einfach zu handhabende Konfiguration bzw. Verknüpfung.

Im Mittelpunkt dieses neuen Ansatzes steht ein Datenmodell, das die völlige Entkopplung von Hardware, Ablaufprogramm und Visualisierung ermöglicht.

Bedienen - Beobachten - Steuern
mit embedded Grafik

Gestalten und Erstellen von grafischen Bedienoberflächen leicht gemacht

Zeit ist Geld! Mit den Neuerungen in XiBase9, einem bewährtem embedded Grafiksystem für Industrieanwendungen, sind sie schneller am Ziel. Anspruchsvolle grafische Benutzeroberflächen, die ergonomische und funktionsgerechte Maschinen- und Gerätebedienungen unter Linux, Windows oder gängigen Echtzeitbetriebssystemen ermöglichen, werden zügig und effizient erstellt.

Wir zeigen Ihnen diese Neuerungen auf der Embedded World 2020 in Nürnberg, vom 25.2.-27.2.2020 in Halle 4 / 4-338, als Mitaussteller auf dem Stand der Unternehmervereinigung Embedded4You e.V.

Vom Design zu funktionsfähigen, animierten Bildschirmmasken in Rekordzeit

Funktionsfähigkeit allein führt heute kaum ein Programmpaket zum Erfolg im Markt. Wichtig ist die Bedienbarkeit, die Ergonomie der Benutzeroberfläche und damit die Handhabbarkeit einer Maschine.
Nach einer tiefgreifenden Analyse der Aufgaben einer Maschine wird als Resultat das Bedienkonzept erstellt. Die Umsetzung erfolgt anschließend in Form von benutzerabhängigen Bildschirmmasken und eventuell einem Klickdummy. Dieser ermöglicht es das neue Bedienkonzept in Abhängigkeit der Benutzerrolle kennenzulernen bzw. auch zu dokumentieren.
Nach Abschluss dieser Konzeptarbeiten beginnt die Arbeit der Softwareprogrammierer, die die statischen Vorschläge nun mit Leben füllen müssen. Zur Zeit ist es noch sehr verbreitet, Bildschirmmasken als gerasterte Bilder dem Entwickler zur Verfügung zu stellen. Daraus animierbare individuelle Objekte zu generieren ist schon eine Herausforderung und oft nur mit hohem Aufwand möglich.
Die Werkzeuge der Designer können die Bildschirmmasken ohne zusätzlichen Aufwand auch als Vektorgrafiken zur Verfügung stellen. Bevorzugt bietet sich hier das SVG-Format (Scalable Vector Graphics) an. Es hat eine weite Verbreitung und kann in den meisten Browsern sofort verwendet werden. Die Grafikplattform XiBase9 und die zugehörigen Tools unterstützen ebenfalls SVGs.
Der Entwickler wird die gelieferten Bildschirmmasken in logische Objekte zerlegen, diese mit Aufgaben verknüpfen und anschließend wieder zu finalen Bildschirmmasken zusammensetzen.
Voraussetzung für eine effiziente Bearbeitung der Bildschirmmasken ist, dass diese aus einzelnen Vektoren aufgebaut sind. Mit dem Vektoreditor werden die Vorlagen importiert und mit wenigen Handgriffen Objekte separiert.
Häufig müssen Objekte gewisse dynamische Eigenschaften erfüllen. Z.B. wird von einem Zeigerobjekt erwartet, dass sich der Zeiger bewegen lässt. Das lässt sich spielerisch, ohne jeglichen Programmieraufwand, mit dem Vektoreditor erledigen. Als Resultat entsteht ein Objekt, welches über frei definierbare Animationseingänge dynamisiert wird. Diese Eingänge können mit Variablen aus der Middleware verknüpft werden und so Zustände der Maschine anzeigen oder falls gewünscht, auch Zustände der Maschine ändern. Das Zusammensetzen der Masken und die Verknüpfung mit den Variablen aus der Middleware erfolgt mit dem HMI-Editor von XiSys.

Unterstützung moderner HMI-Konzepte mit Middleware

Die Middleware ermöglicht die völlige Entkopplung von Hardware, Ablaufprogramm und Visualisierung durch Datenabstraktion. Es können mehrere unterschiedliche Middlewareplattformen gleichzeitig eingebunden werden. Weiterhin ist mit dieser Technologie die Anpassung an eventuell bereits vorhandene firmenspezifische Middleware einfach möglich.

Das Variablenmodell der Middleware kann in einem weiten Bereich angepasst werden. So kann eine Variable im einfachsten Fall nur als Quelle für einen Anzeigewert dienen. Sie könnte jedoch auch komplexere Aufgaben wie Skalierung über Grenzwerte, automatische Einheitenumrechnungen, Funktionsgeneratoren, Diagramme, bis hin zur Steuerung der Sichtbarkeit und Bedienbarkeit von Objekten übernehmen.

Modularität

Ab Version 8 wurde ein modulares Konzept eingeführt, mit dem ähnlich wie mit iFrames in einem Browser, zusätzliche Visualisierungsmodule in Containerobjekten ausführbar sind. Visualisierungsmodule können entweder einzelne Bildschirmmasken oder auch komplette eigenständige Visualisierungen sein. So können Oberflächen aus Funktionsbausteinen individuell zusammengesetzt werden.

Performante Grafik mit Gestensteuerung auf schlanken Geräten

Für Touchanwendungen mit Gestensteuerung reicht z.B. ein Raspberry Pi bereits aus. Der benötigte Arbeitsspeicher dafür ist nicht größer als 256 MB und der benötigte Speicherplatz auf externen Medien ist nicht größer als 50 MB.

Anpassbares Ausgabeformat

Bevorzugt werden bei einem Neudesign Vektorgrafiken verwendet. Damit ist es möglich die finale Bildschirmauflösung und in gewissen Grenzen auch die Geometrie später festzulegen oder zu ändern. Der Grafikserver unterstützt bei Bedarf in X- und Y-Richtung unterschiedliche Skalierungsfaktoren. So können Oberflächen die z. B. für einen HD-Bildschirm entwickelt wurden problemlos auch auf einem 4K-Bildschirm dargestellt werden.

Verteilte Systeme in Netzwerken und im WAN

Alle Visualisierungen können mit einer Displayumlenkung auf unterschiedlichen Systemen im Netzwerk verteilt werden. Seit der Version 7 ist im Grafikserver ein Webserver integriert. Diese Erweiterung ermöglicht es die Visualisierung in einem beliebigen Browser auszuführen. Hierzu sind keine gesonderten Modifikationen oder APP-Installationen notwendig.

Visualisieren eines Heizsystems mit Hilfe eines Browsers. Es werden keine Cookies oder zusätzliche Apps für ein browserbasiertes Anzeigesystem benötigt.

Fazit

Mit dem neuen XiBase9 wird Programmieren durch Konfigurieren ersetzt. Die Vorteile liegen auf der Hand: „zügigere Projektumsetzung, Vereinfachung der Wartbarkeit und Kosteneinsparungen“, sagt Klaus Gerstendörfer, Geschäftsführer der XiSys Software GmbH.

Lokale Benutzeroberflächen -
überall verfügbar

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 ist ein vom BMBF gefördertes Forschungsprojekt zur Entwicklung einer Methodik zur durchgängig modellbasierten Entwicklung von eingebetteten Systemen.

Im Rahmen der nationalen Innovationsallianz "Software-Plattform Embedded Systems 2020" werden Lösungen für die domänenübergreifende und modellbasierte Entwicklung von eingebetteter Software erarbeitet. Modellbasierte Verfahren auf Basis eines soliden mathematischen Fundaments ermöglichen eine effiziente Entwicklung eingebetteter Systeme beginnend bei den initialen Kundenanforderungen ¨ber den Entwurf und die Implementierung bis hin zur Verifikation und Zertifizierung von Systemen.

An den Forschungs- und Entwicklungsarbeiten sind 21 Partner aus Wirtschaft und Wissenschaft aus ganz Deutschland beteiligt. Im Laufe des Projektes ist geplant, weitere, insbesondere kleinere und mittlere Unternehmen zu beteiligen, so dass ein breiter Transfer der Ergebnisse in die deutsche Wirtschaft gewährleistet wird.

Informationsbroschüre SPES 2020

Beschreibung der exemplarischen Umsetzung eines Modellierungsansatzes für embedded Grafiksysteme von XiSys Software GmbH-E4You

Modell-basierte grafische
Entwicklung

Die Komplexizität von "embedded" Maschinen steigt zunehmend. In Anbetracht der Erwartungshaltung der Kunden, der Einflüsse aus der Consumerwelt und des Konkurrenzkampfes müssen immer mehr und mehr neue Features eingebaut werden. Besteht zusätzlich die Notwendigkeit einer grafischen Oberfläche, erfordern auch kleine Geräte einen riesigen Entwicklungsaufwand.

Es ist also naheliegend, sich Gedanken über alternative Entwicklungsmethoden zu machen. Bei genauer Analyse ist festzustellen, dass viele Geräte mit ähnlichen Regeln arbeiten und dementsprechend auch entwickelt werden könnten. Ähnliche Schemata lassen sich in Modellen abbilden. Sie projizieren die Aufgaben auf eine abstrakte Ebene und arbeiten sie dort ab. Basierend auf diesen Betrachtungen kann von einer neuen Methode, der "Modellbasierten Entwicklung" gesprochen werden. Ein Ansatz, der auch durch das BMBF im Rahmen von "Software Plattform Embedded Systems (SPES) 2020" gefördert wird.

Im Mittelpunkt steht ein Datenmodell, welches alle zu einem Gerät gehörigen Komponenten (HW, SW, Netzwerk, Sensoren, Aktuatoren, ...) auf einer abstrakten Ebene abbildet und verbindet. Wir bezeichnen dieses Modell als Softwarestecker. Das Datenmodell ist ein fertig einsetzbares Programm. Es sammelt und verwaltet alle Daten der zugehörigen Komponenten und stellt diese in abstrahierter Form zur weiteren Verarbeitung - lokal oder im Netzwerk - zur Verfügung. Die einzelnen Komponenten müssen lediglich auf Treiberebene angepasst werden. Der Arbeitsaufwand beschränkt sich ausschließlich auf das Konfigurieren des Modells. Der Einsatz eines Datenmodells spart enorm viel Zeit, ist jedoch nur der erste Schritt in dem neuen Entwicklungskonzept. Die vom Datenmodell zur Verfügung gestellten Daten wollen verarbeitet werden. Dies erfolgt mit einem Ablaufprogramm. Zunehmend besteht die Notwendigkeit, die Daten zu visualisieren und mittels eines GUI auch Eingriffe in den Programmablauf zu ermöglichen.

Natürlich können diese Aufgaben mit der klassischen individuellen Programmierung erledigt werden. Am Beispiel eines Anzeigeinstruments wird jedoch schnell ersichtlich, welch immenser Aufwand und welch gestalterische Fähigkeiten notwendig sind, um den heutigen Anforderungen gerecht zu werden. Durch die weite Verbreitung von Geräten mit ansprechenden Oberflächen wie iPhones steigt auch die Erwartungshaltung beim Kunden im "embedded" Umfeld. Vor einigen Jahren war es ausreichend, eine schematische Darstellung mit einem Balken oder einfachen Zeiger mit Beschriftung zur Darstellung eines Wertes einzusetzen. Dies ist für Programmierer mit einem vertretbaren Aufwand umsetzbar. Zeitgemäße Anzeigegeräte erfordern eine wesentlich aufwändigere Darstellung. Es werden Farbverläufe, Schattenwürfe, Glaseffekte usw. verlangt. Dies übersteigt die gestalterische Kompetenz der meisten Programmierer. Allein schon der wesentlich höhere Aufwand für das mathematische Modell eines solchen Anzeigeobjektes sprengt die Grenzen der Verhältnismäßigkeit.

Der erste Schritt ist umgesetzt

Im Rahmen von SPES 2020 ist es uns gelungen, ein Konzept zu entwickeln, welches ein Programmieren von Anzeigeobjekte überflüssig macht. Das Gestalten und Animieren kann von einem Designer übernommen werden.

Der nächste Schritt

Letztlich müssen die Anzeigeobjekte mit den Daten aus dem Datenmodell verknüpft werden. Diese Logik wird in einem nächsten Schritt ebenfalls durch Konfigurieren ersetzt.

Wir sind überzeugt, dass es bei konsequenter Umsetzung des modellbasierten Konzeptes möglich ist, das Programmieren zum größten Teil durch Konfigurieren zu ersetzen. Die Vorteile liegen auf der Hand: Schnellere Projektumsetzung, Vereinfachung der Wartbarkeit, Kosteneinsparung.