1. Anbindung der Hardware-Signale und Steuergeräte
Sämtliche Hardware-Signale werden über eine zentrale Business-Logik-Komponente verarbeitet. Es hat sich bewährt, dass diese in einem eigenen Prozess am embedded Linux System umgesetzt ist, so können Echtzeit-Anforderungen mittels Prozessprioritäten noch besser berücksichtigt werden. Die Abstraktion der Hardware in dieser Komponente hat auch große Vorteile bei Test und Simulation des Endproduktes. Über eine Hardware-unabhängige offene Schnittstelle wird dann mit der Visualisierung kommuniziert.
2. Produkt-Variationen und Konfiguration
Die Wiederverwendung von gut konzipierten Gesamtprodukten in unterschiedlichen Produktvariationen spielt eine sehr wichtige Rolle. Wiederverwendete Komponenten sind bereits erprobt, müssen nicht neu entwickelt werden und helfen die zu wartende Code-Basis überschaubar zu halten. Um diese Wiederverwendung zu ermöglichen, ist es sinnvoll insbesondere bei der Entwicklung von UI-Komponenten ebenfalls auf ein modellbasiertes Vorgehen zu setzen. Ansätze, welche UI-Komponenten-Code automatisch aus Vorgaben des Grafikers generieren (z.B. GUI-Editoren, GUI-Designer oder Studio-Software) mögen für die Prototypen-Entwicklung noch hilfreich sein, haben sich aber für die Entwicklung wartbaren größeren Produkten als nicht besonders hilfreich erwiesen.
3. Abbildung der Variationen in Benutzerführung und Anwendungs-Design
Die erstellten UI-Komponenten bilden die Varianten implizit ab und helfen so die Präsentations-Logik schlank und übersichtlich zu halten. Das Design ist zentral als Design-Theme in einer Konfiguration abgelegt, die Grafiken liegen in unterschiedlichen Auflösungen und Farbvarianten in strukturierten Verzeichnissen. So können unterschiedliche Display-Größen oder Produktvarianten implizit durch die Komponenten abgedeckt werden und müssen nur einmal entwickelt werden. Ein Update des User Interface mit neuen Design-Elementen ist im besten Fall durch die Ersetzung von Grafik-Elementen in den Verzeichnissen erledigt.
4. Simulation und Test des Produktes
Mit der zunehmenden Komplexität eines Produktes wird der Aufbau eines Sicherheitsnetzes in Form von automatisierten Tests immer wichtiger. Da im embedded Umfeld die zu testende Software meist stark integriert mit weiteren Systemen ist (z.B. via CAN-Bus, Ethernet oder externen Sensoren), ist es sinnvoll, eine hardwareunabhängige Simulation und Test des Produktes von Anfang an mit zu berücksichtigen. Dies erfordert unter Umständen zu Beginn einer Entwicklung einen geringfügigen Mehraufwand bei der Wahl der Schnittstellen und der Architektur. Es rechnet sich jedoch meist relativ bald, wenn neue Ansätze (im Home Office) ohne verfügbare Hardware evaluiert werden sollen oder komplexe Zusammenhänge zwischen den Steuergeräten virtuell simuliert oder demonstriert werden sollen.
Einen weiterführenden Bericht zu diesem Thema können Sie übrigens auch bei unserem Kunden Rosenbauer hier nachlesen: https://www.rosenbauer.com/blog/en/introducing-a-new-way-of-software-development-at-rosenbauer/. Das Header-Bild dieses Artikels ist aus diesem Kunden-Bericht entnommen.
Haben Sie Fragen? Gerne stehe ich für Auskünfte bereit: stefan.larndorfer@sequality.at