Offene Schnittstellen ermöglichen die Einbindung von Bediengeräten der Zukunft – zum Beispiel der ­Microsoft Hololens.

© Inosoft

Wer selbst programmiert, hat die volle Freiheit, seine Bedienkonzepte und Anwendungsideen umzusetzen – sofern sich der damit verbundene Aufwand wirtschaftlich vertreten lässt. Auch bei der Realisierung stehen sämtliche technischen Türen offen, wenn es etwa um Programmiersprachen oder Entwicklungs-Frameworks geht. Dies ist insofern relevant, als gerade die Schnittstellen für neue Geräte, beispielsweise für Datenbrillen wie Microsofts Hololens, nur in aktuellen Umgebungen zu realisieren sind. Dementsprechend hoch sind die Anforderungen an die Programmierer: Sie müssen fit sein in den aktuellen Programmiersprachen und -Tools.

Wer diesen Aufwand nicht leisten kann oder will, greift zu einer vorgefertigten Lösung, die sich einfach an die eigenen Wünsche anpassen lässt – zumindest im Rahmen der vorgegebenen Funktionen. Ebenso unterliegt man unter Umständen gewissen Einschränkungen beim grafischen Design der Oberfläche. Als Maschinenbauer ist man in diesem Fall darauf angewiesen, dass der Anbieter alle benötigten Optionen realisiert oder entsprechende APIs und Schnittstellen bereitstellt, die eine Ergänzung mit zusätzlichen Produkten oder die Einbindung neuer Bediengeräte und Bedienkonzepte zulassen.

Die Anforderungen an Bedienkomfort, Funktionalität und Design von HMI-Oberflächen steigen. Andererseits verschaffen hochwertige Oberflächen Maschinenherstellern einen Wettbewerbsvorteil.

© Inosoft

Die zahlreichen auf dem Markt erhältlichen Lösungen unterscheiden sich hier zum Teil gravierend. Hier gilt es genau hinzuschauen, an welchen Hersteller man sich bindet – sowohl in Hinblick auf die aktuelle Technik als auch auf den Entwicklungspfad, der für künftige Versionen gezeichnet wird. Ebenso ist zu prüfen, welche Schnittstellen zu Anwendungen außerhalb der HMI-/SCADA-Welt eine Lösung unterstützt – etwa zu ERP-Systemen und Cloud-Anwendungen –, und welche Protokolle für den Datenaustausch zur Verfügung stehen. Je nach verfolgter Strategie ist sehr genau zu prüfen, ob mit der vorgesehenen Lösung das Ziel überhaupt zu erreichen ist.

Doch nicht nur die Lösungen selbst unterscheiden sich stark – auch Entwicklung und Pflege haben je nach gewählter Strategie einen völlig anderen Charakter. Wer seine HMI-Anwendung selbst entwickelt, braucht hochqualifizierte Entwickler. Diese sind auf dem Markt nicht leicht zu finden – größere Unternehmen, die attraktive Konditionen bieten können, sind deshalb oft im Vorteil. Nicht zu unterschätzen sind die ‚Nebeneffekte‘ einer selbst programmierten Anwendung: Anpassung an neue Hardware sowie an aktualisierte Betriebssysteme und Frameworks. Dies kann eine Stärke sein, wenn die selbstentwickelte Lösung die Vorteile der technischen Innovation aufgreifen und daraus Mehrwert für den Nutzer generieren kann. Besondere Aufmerksamkeit verlangt das Versionsmanagement der eigenen Codes sowie der eingesetzten Bibliotheken von dritter Seite. Darüber hinaus muss über die Laufzeit des Systems hinweg die Security gewährleistet sein. 

Wer auf eine zugekaufte Lösung setzt, muss sich um solche Probleme nicht kümmern, das ist Sache des Anbieters. Allerdings muss dieser auch verlässlich und zeitnah seinen Pflichten nachkommen. Häufig sind zugekaufte Lösungen jedoch proprietär, also nicht an gängigen offenen Standards orientiert, sondern nutzen herstellerspezifische Daten- und Schnittstellenformate. Damit bindet man sich eng an den HMI-Anbieter, teils nicht nur bei der Software, sondern auch bei der Hardware. Solange der Hersteller sein Produkt regelmäßig an neue Rechner- und Ausgabetechniken anpasst, hat der OEM viel Aufwand gespart. Bleibt das Produkt dagegen auf einer Entwicklungsstufe mit zunehmend veralteter Hardware stehen, kann der Maschinenbauer dies nicht selbst beheben. Im schlimmsten Fall bleibt nur der Wechsel des Anbieters – und damit ein aufwendiger Neubeginn auf der nächsten Plattform.

Der Mittelweg

Neben diesen beiden ‚idealtypischen‘ Strategien – Programmieren oder Parametrieren – gibt es einen Mittelweg, der die Vorteile der beiden Welten in sich vereint. Solche Systeme bieten einerseits eine breite Palette von Standardfunktionen, die sich einfach per Parametrierung aufsetzen lassen. Zum anderen lassen sich damit  komplexe Funktionen mit Hilfe objektorientierter Programmiersprachen und den dafür verfügbaren professionellen Tools nachrüsten, während vorgefertigte Lösungen allenfalls mit Scriptsprachen in geringem Umfang modifizierbar sind. 

Die Idee hinter solchen Lösungen: das ‚Pflichtprogramm‘ der HMI lässt sich mit geringem Aufwand erstellen. Diese Aufgabe können erfahrene Fachkräfte aus der Automation übernehmen. Erst für zusätzliche Erweiterungen kommen dann Software-Experten zum Einsatz. Funktionen, die auf dem Markt nicht als fertige Lösungen erhältlich sind, spezielle Anwendungen und Services des Maschinenbauers sowie die Berücksichtigung kundenspezifischer Technologien und Anforderungen sind nur einige Beispiele für solche Ergänzungen.

Ein wichtiger Aspekt ist auch die Gestaltung der Oberfläche, beispielsweise im Design des Maschinenbauers oder nach Wunsch von dessen Kunden. Entscheidend dabei ist, dass sich die programmierten Erweiterungen nahtlos in die Teile der HMI einfügen, die auf Parametrieren basiert.

Ein Beispiel für ein solches offenes System ist VisiWin von Inosoft. Diese Lösung ist tief in das Microsoft-Ökosystem zur Entwicklung grafischer Systeme eingebettet. Dazu zählt an erster Stelle Visual Studio, daneben das Designwerkzeug Blend und als Technologie das .Net-Framework inklusive Windows Forms sowie das GUI-Framework WPF (Windows Presentation Foundation). Diese Integration gewährleistet eine kontinuierliche Weiterentwicklung und Anpassung an aktuelle Windows-Betriebssystemversionen und moderne PC-Technik.

Eine große Entwickler-Community und zahlreiche Download-Plattformen bieten sogar außerhalb des weitgehend kostenlosen Hersteller-Services umfangreiche Möglichkeiten, Unterstützung zu bekommen, auch in Form von fertigen Funktionsbausteinen, die zum Download bereitstehen. Die Gefahr eines ‚Hersteller-Lock-In‘ ist bei dieser Lösung also denkbar gering.

Wer selbst Zusatzfunktionen für VisiWin programmieren will, kann auf verschiedene Technologien und Sprachen zurückgreifen. Im Fokus stehen C# und VB.NET (Visual Basic.NET) von Microsoft sowie Web-Technologien wie HTML5, CSS, XAML und Javascript. Selbstverständlich sind auch aktuelle Kommunikationsprotokolle wie OPC UA integriert.

Zusammenfassend lässt sich festhalten: Jede Lösung hat ihre Berechtigung, jedoch ist jede Anwendung individuell zu betrachten. Grundlagen für eine Entscheidung sind ein gründliches Abwägen von Vor- und Nachteilen sowie der verfügbaren Kompetenzen im Unternehmen.

Autor:
Stefan Niermann ist Vertriebsleiter bei Inosoft.