Viele eingebettete Geräte haben altmodische GUIs oder besitzen überhaupt keine GUI. Das bedeutet nicht, dass jedes Produkt ein Full-HD-Display mit einer flüssigen, modernen und absurd animierten grafischen Benutzeroberfläche benötigt. Manche Geräte benötigen überhaupt keine GUI. Die Gewohnheiten und Erwartungen der Benutzer haben sich jedoch im Laufe der Zeit weiterentwickelt, daher planen Hersteller bzw. Ihre Wettbewerber ganz selbstverständlich GUIs für die eingebetteten Systeme, die sie entwickeln.
In diesem Artikel werde ich das Gebiet der GUI-Entwicklung für eingebettete Systeme untersuchen. Wir werden auf praktische Probleme eingehen und darauf, wie man sie lösen kann. Wir werden die häufigsten Themen erklären, wie zum Beispiel:
- die Wahl eines GUI-Software-Frameworks – Qt, LVGL oder vielleicht etwas anderes?
- schlechtes UX/UI-Design
- die Wahl der Hardware-Zielplattform
- Zugang zu Fachwissen und Kosten – unsere Tipps für schnelle und effiziente GUI-Programmierung.
Was qualifiziert mich, über dieses Thema zu schreiben? Ich bin der Gründer von Somco Software – einem Unternehmen für die Entwicklung eingebetteter Systeme mit starkem Fokus auf GUI, Linux (Buildroot, Yocto, Torizon) und Konnektivität. Jedes Jahr starten wir bis zu 20 neue Projekte für Kunden, die Experten in Design, Implementierung und Deployment von GUIs für ihre Embedded-Systems-Projekte suchen. Früher habe ich selbst programmiert und hatte die Gelegenheit, an einer breiten Palette von GUI-Projekten zu arbeiten, die von Fahrzeugnavigation für einen führenden US-Hersteller bis hin zu medizinischen Geräten zur Behandlung schwerwiegender Erkrankungen reichten.
Eine moderne GUI für Ihre eingebetteten Systeme ist kein Luxus mehr
Warum ist das so? Lassen Sie uns das am Beispiel der Automobilhersteller erklären. Trotz einiger Ausnahmen sind die meisten neuen Autos mit einem Cockpit-Display ausgestattet. Nicht unbedingt nur mit einem, sondern oft sogar mit mehreren. Und sie werden immer größer. Auch wenn die Mehrheit der eingebetteten Systeme dieses Maß an „Verrücktheit“ nicht benötigt, bringt eine GUI, die gut aussieht, ästhetisch ist und den Bedürfnissen der Kunden entspricht, Ihr Produkt auf die nächste Stufe.
Nach mehreren Jahren Arbeit in diesem Bereich bin ich zu einigen traurigen Schlussfolgerungen gekommen, und eine davon ist, dass Menschen Bücher nach ihrem Einband beurteilen. Das ist keine Überraschung, und es gibt keinen Grund, sich von der Realität beleidigt zu fühlen. Ein Produkt, das visuell ansprechend ist, hinterlässt einen besseren Eindruck und gibt einem das Gefühl, dass es die eigenen Bedürfnisse besser erfüllen wird. Deshalb sind es bei vielen Kunden von Somco Software deren Marketingabteilungen, die den Wandel vorantreiben, um eine GUI für die von ihnen entwickelten eingebetteten Systeme einzuführen oder zu verbessern.
Natürlich ist es Ihre Aufgabe sicherzustellen, dass dieses Aussehen keine bloße Fassade ist und Ihr Gerät ein hervorragendes Produkt darstellt, aber das ist ein Thema für einen anderen Artikel.
Es gibt noch einen weiteren, praktischen Blickwinkel auf dieses Thema: Kosten und Wartung. Langfristig ist es günstiger (ich weiß, Sicherheitsaspekte einmal außen vor gelassen), einen großen Bildschirm in der Mitte zu haben, anstatt dutzender physischer Schalter, Drehknöpfe und Tasten. Warum mehrere physische Bedienelemente für die Klimaanlage (Ein/Aus, Temperatur, Luftstromrichtung, Lüftergeschwindigkeit usw.) haben, wenn man all das in der Software abbilden kann? Physische Bedienelemente müssen ebenfalls entworfen, produziert und gegebenenfalls ersetzt werden, wenn sie beschädigt werden.
Darüber hinaus öffnen Sie mit dem Übergang zur Software die Tür für Updates. Nehmen wir an, es gibt eine Funktion im Auto oder in Ihrem eingebetteten System, die mit der gesamten Hardware realisiert werden kann, die sich bereits in Ihrem Gerät befindet, aber Sie müssen das Produkt so veröffentlichen, wie es ist, und hatten keine Zeit, diese Funktion zu implementieren. Mit Software können Sie einfach einige Zeit nach der Veröffentlichung ein Update herausgeben. Ein zusätzliches physisches Bedienelement für diese neue Funktion in Geräten zu installieren, die bereits an die Kunden ausgeliefert wurden, wäre hingegen zumindest umständlich.
Die Auswahl eines GUI-Software-Frameworks
Qt, LVGL, TouchGFX, Flutter, Slint, Candera, Web-Frameworks, Kotlin, MAUI, Unity, Unreal… Diese Liste könnte wahrscheinlich noch viel länger sein, aber wir haben all diese Frameworks bei verschiedenen Projekten für Embedded-System-GUIs im Einsatz gesehen. Gibt es eine Lösung, die für alle Fälle deutlich besser ist? Natürlich nicht. Jede Technologie hat ihre eigenen Vor- und Nachteile sowie Anwendungsfälle, für die sie sich am besten eignet. Dennoch ist eine solche Entscheidung wichtig, da sie viele Dinge direkt beeinflusst, wie etwa die Wahl der Hardware, aber auch indirekt Ihr Business beeinflusst (Entwicklungskosten, Lizenzen, Lieferzeit).
Es gibt viele Faktoren, die berücksichtigt werden müssen. Einige davon sind:
- Leistungsanforderungen (FPS, Bootzeit, GPU-Nutzung)
- Unterstützung der Zielhardware
- Speicherbedarf
- Display-Eigenschaften (Touch, Multi-Touch, Auflösung, Farbtiefe)
- Grafische Fähigkeiten (2D/3D, Anti-Aliasing, Video)
- Entwicklungsgeschwindigkeit und Time-to-Market
- Einfache Integration
- Lizenzierung und Kosten
- Compliance (wir kennen dieses Thema sehr gut, da Somco Software ein nach ISO 13485 und ISO 9001 zertifiziertes Unternehmen für Embedded-Software ist und wir viel mit Kunden aus dem medizinischen Bereich und anderen regulierten Branchen arbeiten)
- Reifegrad der Community und des Ökosystems
Auch diese Liste könnte noch viel länger sein. Das Dilemma wird zusätzlich dadurch kompliziert, dass „Embedded Systems“ ein sehr weiter Begriff ist. Ein In-Vehicle-Display, ein großes medizinisches Gerät zur Wirbelsäulenoperation und eine Smartwatch sind alles eingebettete Systeme. Die beste Definition, die ich dafür gehört habe, lautet, dass es sich um ein „geschlossenes System“ handelt.
Die Faustregel lautet also: Sie werden keine gute Entscheidung treffen, wenn Sie Ihre Ziele und das, was Sie bauen müssen, nicht verstehen. Zuerst müssen Sie die Stakeholder (Management, Marketing, Engineering) zusammenbringen und die Anforderungen klären, dann das Budget festlegen, und erst danach können Sie Entscheidungen treffen. Ich kann Ihnen garantieren, dass Sie, wenn Sie den umgekehrten Weg gehen und zuerst ein bestimmtes Framework auswählen, nur weil Sie Python mögen oder aus irgendeinem anderen Grund, am Ende nur darauf wetten und beten können, dass Sie Glück haben und später keine Probleme auftreten.
Eines der bedeutenden Projekte, die wir kürzlich entwickelt haben, war die Embedded-Software für Cutera Inc. – einen Hersteller ästhetischer Lasergeräte aus den Vereinigten Staaten. Somco Software entwickelt verschiedene Aspekte der Software von Cutera, darunter das Yocto-Linux-Image, die Konnektivität zwischen Mikrocontrollern, Sicherheitsupdates und natürlich die eingebettete GUI. Wenn wir also dieses Beispiel verwenden: Was waren die Ziele dieses Kunden?
Sie sind im Beauty-Sektor tätig. Ich habe einmal eine ästhetische medizinische Klinik besucht (für einen Produktworkshop, nicht um mein Aussehen zu verbessern), in der Geräte von Cutera standen. Und ich kann Ihnen sagen, dort sah alles so aus, als wäre es absurd teuer, die Menschen waren reich und glücklich und die Welt war ein besserer Ort. Daher traf Cutera die strategische Entscheidung, dass die GUI ihrer eingebetteten medizinischen Geräte diesen Standards entsprechen muss. Sie benötigt Animationen, 3D und flüssige Übergänge.
Und genau das bestimmte die Gründe, warum Cutera sich an Qt-Entwicklungsexperten wie das bescheidene Somco gewandt hat. Dieses Framework ist die am häufigsten verwendete Technologie in unserem Unternehmen und der Kern unseres Technologie-Stacks.
