Ein Thermoschrank ist auf den ersten Blick technisch banal. Man gibt eine Temperatur ein und liest an einer Anzeige die tatsächliche Temperatur ab. Jedoch verfügen moderne Thermoschränke über eine Vielzahl an Optionen und Gerätevarianten, welche die Anforderungen an Steuerung und Leistungselektronik erheblich beeinflussen. Nebst verschiedenen Heizkreisen sind auch Umluftventilatoren oder Vakuumkomponenten anzusteuern. Zu diesen Hardwareanforderungen kommen zahlreiche Softwarefunktionalitäten wie Datenlogging, Datenexport, Userverwaltung, Sprachumschaltung oder die Erstellung anwenderspezifischer Heizprogramme hinzu. Im folgenden Beispiel soll die Bedieneinheit zudem in sechs verschiedene Gerätetypen mit bis zu fünf Ausbaustufen eingebaut werden können.
Mit Qt auf Linux für Embedded Linux programmieren
Eine Systemanforderung umfasst nebst umfangreichen Hardwarekonfigurationen und Softwarefunktionalitäten auch eine intuitiv zu bedienende Benutzeroberfläche – was meist deutlich konkreter und anspruchsvoller ist, als es klingt. In diesem Beispiel war mit Embedded Linux das Betriebssystem bereits vorgegeben, nur die Frage nach der geeigneten Plattform für das Benutzerinterface (GUI) war noch offen. Aus einer Auswahl von mehreren Plattformen fiel der Entscheid zugunsten von Qt. Nebst der grossen Community und der Möglichkeit, mit C++ eine vertraute Programmiersprache zu verwenden, bietet Qt mit dem Crosscompiler eine Funktionalität, mit der die Applikation auf dem Desktop unter Linux entwickelt werden und danach für das Embedded Linux crosscompiliert werden kann. Die meisten COM-Hersteller (Computer on Modules) rüsten die Board Support Packages direkt mit Qt für Embedded-Linux aus.
Wie baut man eine intuitive Software auf, die in sechs verschiedenen Gerätetypen mit je bis zu fünf Ausbaustufen verfügbar ist?
Um die unterschiedlichen Gerätetypen und ihre unterschiedlichen Funktionen in einer Software zu vereinen, sollten die jeweils angezeigten Funktionen parametrierbar sein. Dieser scheinbare Zusatzaufwand bietet den Vorteil, dass immer ein und dieselbe Software verwendet werden kann. Wichtig ist, dass das Menü einfach und von nahezu allen Orten in der Software zugänglich ist. Dies erhöht die Bedienbarkeit des Systems, stellt den Programmierer aber vor das Problem, dass er scheinbar Funktionalitäten mehrfach implementieren muss.
Klassisch wählt man für eine solche Software die Model-View-Control-Architektur. Diese basiert auf dem Ansatz, dass mehrere Ansichten, sogenannte Widgets, vorhanden sind. Jedes dieser Widgets besteht aus den Teilen View, Model und Control. Zwischen diesen Widgets kann innerhalb der Software gewechselt werden. Auch dies lässt sich in Qt sehr gut umsetzen.
Model, View, Control – und Widgets
Mit der Model-View-Control-Softwarearchitektur wird sichergestellt, dass sich die entsprechenden Klassen nur um die Aufgaben kümmern, welche in ihren Zuständigkeitsbereich fallen.
- Models sind für die Verarbeitung und Speicherung der Daten verantwortlich und stellen diese der ganzen Applikation zur Verfügung. Im Model werden unter anderem auch komplexere Berechnungen ausgeführt
- Ein View stellt die gespeicherten Daten eines Models für den Benutzer grafisch dar. Mithilfe von Signalen wird die Oberfläche stets über Änderungen im Model benachrichtigt und aktualisiert. So verfügt beispielsweise eine Temperatur- oder Druckeinstellung über eine View. Die Controls kümmern sich um die Kommunikation mit der Hardware, oder aber auch um den Betrieb des Ofens
- Ein exemplarisches Control fragt zyklisch alle aktuellen Betriebswerte des Ofens ab und speichert die Daten in das entsprechende Model, so dass diese wiederum der ganzen Applikation zur Verfügung stehen
Jede View besteht aus einem Widget. Dieses entspricht einem GUI-Layer, welcher sich aus entsprechenden Anzeigeelementen wie Buttons oder Labels zusammensetzt. Alle Widgets werden in einem Stacked Widget abgelegt. Dadurch liegen alle Widgets übereinander, wobei das jeweils Oberste auf dem Bildschirm ausgegeben wird.
Das Signal-Slot-Konzept von Qt erlaubt eine ereignisgesteuerte Programmierung. Diese ermöglicht eine Kommunikation zwischen Bedienerinteraktionen, Softwarecontrols und Widgets. Die Hauptansicht des GUIs ist in vier einfache Kacheln gegliedert. Jeder Kachel wird eine spezifische Funktion zugewiesen. Durch Betätigen einer der Kacheln wird eine Aktion ausgeführt. So können zum Beispiel Einstellungen wie Temperatur oder Lüfter- geschwindigkeit vorgenommen oder der Heizvorgang gestartet werden.
Fernbedienung, Debug-Varianten oder Schnittstellenprotokolle
Die Software deckt verschiedene Ofentypen mit unterschiedlichem Funktionsumfang ab. Eine entsprechende Konfiguration der Ofentypen ist als XML-File hinterlegt. Darin werden alle notwendigen Parameter, beispielsweise für die Regelung, verwaltet. Basierend auf den Angaben der Ersteinrichtung wird eine Datenbank angelegt. Diese speichert im späteren Betrieb alle durch den Bediener veränderlichen Einstellungen sowie die Kalibrationsdaten der vorhandenen Sensoren. Da der Einrichtbetrieb lediglich beim ersten Starten angezeigt wird, ist gleichzeitig sichergestellt, dass der Endbenutzer nicht die Grundeinstellungen der Geräte verändern kann.
Welche Netzwerkdienste soll ein Gerät heute zur Verfügung stellen? Ein im Netzwerk agierender Teilnehmer wird nach den Bedürfnissen von Kunden realisiert, welche sich stark unterscheiden. Fernbedienung per Computer oder App, Debug-Möglichkeiten, oder ein einfacher Aufbau des Schnittstellenprotokolls sind ein paar Beispiele. Auf die Realisierung einer Schnittstelle mit Hilfe des JSON-Datenformats wird nachfolgend eingegangen. Ziel ist eine universelle Lösung, welche von Beginn der Entwicklung bis zur Nutzung durch den Entwickler oder Kunden Verwendung findet.
Einfache, XML-ähnliche Schreibweise
Die JavaScript-Object-Notation (JSON) ist ein Textdatenformat, welches sich für die Übertragung von verschiedenen Datentypen und von kompletten Klassenobjekten eignet. Das Datenformat ähnelt XML und zeichnet sich durch einen sehr einfachen Aufbau aus. Dem Beispielthermoschrank sollen über das Netzwerk eine neue Zieltemperatur und weitere Parameter gesetzt werden. Mit Hilfe eines JSON-Objekts wird diese Information folgendermassen verschickt:
{
„Zieltemperatur“: 125.6,
„Steigung“: 4.5,
„Regler“: 1
}
Jedes Feld wird eindeutig mit einem String gekennzeichnet. Dies ermöglicht einen einfachen Zugriff auf die Daten, entsprechende Funktionen sind in den meisten Programmiersprachen bereits vorhanden. Nach dem Doppelpunkt folgt der Datenwert. JSON bietet die Möglichkeit, die gängigsten Datentypen zu verschicken. Dazu gehören Booleans, Strings, Arrays sowie Nulls. Die geschweiften Klammern umschliessen ein Objekt und erlauben auch eine einfache Verschachtelung. Das Beispiel zeigt, wie leserlich die Daten sind. In der Entwicklungsphase eines Produktes kann es hilfreich sein, Simulationen von anderen Geräten oder Anpassungen von Nachrichten vorzunehmen. Durch den einfachen Aufbau können die Daten auch mit Hilfe eines simplen Terminal-Programms verschickt werden.
Die bestehende MVC-Architektur wird um den JSON-Controller erweitert. Damit wird das Setzen einer neuen Temperatur durch JSON ermöglicht. Durch die Kapselung der verschiedenen Aufgabenbereiche kann mit dem Einfügen eines neuen Control-Objekts für die Schnittstelle der Thermoschrank bereits ferngesteuert werden. Dabei werden die vorangehenden Mechanismen, wie das Anzeigen der aktuellen Solltemperatur oder die Aktualisierung der Isttemperatur, nicht beeinträchtigt. Dies erfolgt weiterhin mit dem ereignisgesteuerten Signal-Slot-Prinzip. Der Ablauf vom Absetzen des Kommandos durch die MVC-Architektur bis zur Regelung sieht folgendermassen aus: Der JSON-Controller beinhaltet einen TCP-Server, welcher die JSON-Nachricht für das Setzen einer neuen Temperatur empfängt. Das JSON-Objekt wird danach in das passende Model weitergeleitet, wo die Zieltemperatur gespeichert wird. Durch diese Änderung wird auch die View aktualisiert und die bestehenden Mechanismen funktionieren wie bisher. Es ist also möglich, sowohl über die Bedienoberfläche wie auch über das Netzwerk die Zieltemperatur zu ändern.
Eigenständige Geräte, clever vernetzt – ganz im Sinne der Industrie 4.0
Mit der Realisierung des JSON-Interface kann der Thermoschrank über das Netzwerk ferngesteuert werden. Bereits ausgelieferte Geräte können mit Hilfe dieses Features ferngewartet werden und der Entwickler hat die Möglichkeit, Serviceinformationen einfach über das Netzwerk auszulesen. Von einer MVC-Architektur mit Netzwerkinterface kann man bereits zu Beginn einer Entwicklung profitieren und die für Debug-Zwecke notwendigen Werkzeuge können anschliessend im fertigen Produkt weiterverwendet werden. Dadurch sind die Funktionalität und die Wartbarkeit optimal gewährleistet. Das Gerät ist fit für die Industrie 4.0 !
Infoservice
MEquadrat AG
Platz 4, 6039 Root D4
Tel. 041 541 99 10, Fax 041 541 99 11
info@mequadrat.ch, www.mequadrat.ch
