Software ist für einige Embedded Hersteller noch etwas das sie brauchen und nicht etwas das sie wollen. Wie ihre Kunden schätzen sie den Wert von Hardware, möchten jedoch in Software möglichst wenig investieren. Mit dieser Strategie sind sie über viele Jahrzehnte gut gefahren und es braucht gute Gründe, warum sie in Zukunft davon abweichen sollten. Wir werden diese Gründe und die Innovationspotentiale von Software aufzeigen, sowie Wege diese Potentiale zu Nutzen, die nicht die Transformation der gesamten Firmenstruktur erfordern.
Folgende Gründe sprechen für die Wertschätzung von Software bei Embedded Herstellern:
- Software als Enabler: Letztendlich sind für den Kunden die Features eines Produkts entscheidend. Die Hardwareausstattung gibt im Embedded Bereich zwar den Rahmen der Möglichkeiten vor, ihre Realisierung erfolgt jedoch Großteils in Software. Häufig wird ein Abheben vom Wettbewerb durch Zusatzfunktionen erreicht, die rein in Software umgesetzt werden. Beispielsweise wird mittlerweile bei vielen Geräten mit KI-Features geworben. Durch Sonderversionen oder Scripting-Integration kann man leicht kundenspezifische Funktionen einbauen. Software erlaubt, das Produkt auch nach Verkauf noch zu verbessern und zu erweitern.
- Zunehmende Komplexität: Die Komplexität vieler Systemkomponenten hat in den letzten Jahrzehnten stark zugenommen. Wo früher ein Dipschalter ausgereicht hatte, gibt es heute hunderte von Konfigurationsparametern. Die Integrationsfähigkeit mit anderen Komponenten oder Systemen spielt eine immer größere Rolle. Diese Komplexität muss in der Software behandelt werden.
- Steigende gesetzliche Anforderungen: Je nach Branche war bisher die Qualität und Cybersicherheit von Software mehr oder weniger im Fokus. Nicht selten liegt die Release-Kadenz von Embedded-Geräten bei über einem Jahr und kann aufgrund von manuellen Prozessen auch kaum verkürzt werden. Mit dem Cyber-Resilience-Act sind nun branchenübergreifend alle Hersteller zu Qualitätsmaßnahmen und zur zeitnahen Lieferung von Security-Updates verpflichtet.
- Lebenszykluskosten: Es gibt viele Beispiele von Firmwaren, bei denen jede kleine Änderung einige Wochen Aufwand bedeutet und Bugbehebungen sich über etliche Monate hingezogen haben. Daher ist es mitnichten so, dass bei der Softwareentwicklung Qualität und Kosten austauschbar wären. Vielmehr gibt es einen Punkt guter Qualität, bei dem die langfristigen Kosten minimal sind.
Wir betrachten nun spezieller einen Embedded Hersteller, der ein umfangreiches Produktportfolio entwickeln, zeitnah, stufenweise auf den Markt bringen und jahrelang supporten möchte. Die Produkte besitzen eine Menge von Variantenmerkmalen. Jede Kombination ergibt eine Produktvariante, die er seinen Kunden anbieten möchte. Dies können Leistungsklassen, Kommunikationsschnittstellen, Messprinzipien und vieles mehr sein. Dadurch entstehen schnell duzende oder gar hunderte Varianten. Der Hersteller möchte sowohl die initiale Entwicklung, als auch die Wartung der Geräte mit einem moderat großen Softwareteam bewältigen können. Was die Kosten angeht, möchte der Hersteller:
- mit moderaten Investitionskosten für das Hochfahren der Softwareentwicklung auskommen;
- sinkende Entwicklungskosten mit jedem neuen Produkt des Portfolios haben und
- die Lebenszykluskosten über alle Produkte bzw. Varianten minimieren.
Es droht eine Falle für den Hersteller, wenn er an seinem „klassischen“ Vorgehen festhält:
- Er entwickelt Software weiter wie bisher und hat keine Investitionskosten.
- Er bringt das erste Produkt schnell und mit minimalen Entwicklungskosten auf den Markt.
- Für das zweite Produkt kopiert er die Firmware des ersten Produkts und hat so sinkende Entwicklungskosten und gute Time-to-Market.
- Er erzeugt weitere Produkte und Produktvarianten auf diese Weise.
- Die Firmwarestände der einzelnen Produkte und Varianten divergieren mittelfristig stark.
- Die Aufwände für Integration neuer Features und für Fehlerbehebungen nehmen stetig zu, da sie manuell in alle Produktvarianten eingepflegt oder sogar jeweils individuell neu entwickelt werden müssen, was wiederum zu subtil unterschiedlichem Verhalten führt.
- Neuentwicklungen verzögern sich immer mehr, da ein stetig wachsender Teil der Entwickler mit Wartungsaufgaben beschäftigt ist.
- Testaufwände steigen, da durch fehlende Traceability meist unklar ist, welche Produktvarianten von einem bestimmten Fehler betroffen sind.
- Die Qualität sinkt, da bei der Vielzahl der Produktvarianten, die Tester nur noch einen Bruchteil der Anwendungsfälle manuell validieren können.
- Nun wird ein kritischer Bug oder eine Sicherheitslücke entdeckt, der/die sich bereits im ersten Produkt eingeschlichen hatte. Es soll schnell ein Update geliefert werden, doch dies bedeutet Änderungen in allen Produktvarianten inklusive manueller Tests und Releases.
Der Hersteller steckt in der Wartungsfalle, die er nur mit mehr Entwicklern und Testern abmildern kann. Die Einarbeitung neuer Kollegen verzögert die Entwicklungen weiter. Die Lebenszykluskosten der Produkte schießen in die Höhe und übersteigen bald jedes wirtschaftliche Maß. Die Motivation der Entwickler mit der Firmware zu arbeiten ist gering. Die der Tester, die immer gleichen Features in zig Varianten manuell zu testen, ebenso.
Ein bewährter Weg die oben genannten Schwierigkeiten zu vermeiden, ist es eine Produktplattform aufzubauen. Prominentestes Beispiel sind die Fahrzeugplattformen von Automobilherstellern, allen voran von VW. Grundidee ist es eine gemeinsame technische Basis zu entwickeln, auf der dann Produkte und Varianten aufgebaut werden können. In der Softwareentwicklung spielen verschiedene Arten von Plattformen eine wichtige Rolle. Ihnen gemeinsam sind folgende Vorteile:
- Technologisches Fundament: Gemeinsame technische Basis, wie Tools, Dienste und Bibliotheken.
- Standardisierung und Wiederverwendung: Verringerung von Komplexität und Redundanz; Förderung einheitlicher Datenformate und Protokolle; leichtere Integration und Interoperabilität.
- Sicherheit und Governance: Zentrale Mechanismen für Cybersecurity, Datenschutz und Compliance.
- Beschleunigung der Entwicklung: Teams können sich auf eigentliche Businesslogik konzentrieren.
- Innovationsförderung: Durch Prototyping und leichterem Zugang zu neuen Technologien über die Plattform.
- Kostenreduktion: Degressionseffekte durch Vermeiden von Doppelentwicklungen.
Die folgende Abbildung zeigt die plattformbasierte Struktur einer Firmware:
Ein häufiges Beispiel sind PaaS-Cloud-Plattformen, die konfigurierbar genau das mitbringen, was man zur Entwicklung einer Applikation benötigt. Da im Embedded Bereich bislang solche fertigen Plattformen nicht existieren, muss sich ein Hersteller eine eigene Plattformstrategie zurechtlegen.
Die folgende Abbildung zeigt, wie Firmware, Systemtests und Plattformen im Entwicklungsprozess auf Basis einer internen Entwicklerplattform entstehen:
Eine moderne Softwareentwicklung mit Plattformen besteht aus folgenden Teilen:
- einem normgerechten Softwareentwicklungsprozess, der sich an der TR-03185 des BSI anlehnt;
- einem agilen Vorgehensmodell, dass im Kleinen auf Scrum oder Kanban und Großen auf Teilen des Scaled-Agile-Frameworks (SAFe) basiert;
- einem agilen Architekturrahmenwerk, dass eine aktive, evolutionäre Systemgestaltung, durch Balance zwischen intentionalem und emergentem Design, ermöglicht;
- einer internen Entwicklerplattform, die standardisierte Workflows (Builds) und technische Umgebungen (Tooling) über den gesamten Produktlebenszyklus unterstützt;
- einer Infrastrukturplattform, die eine hardware- und betriebssystemunabhängige Firmwareumgebung für alle Produkte liefert;
- einer Produktplattform, die die Basis für die Erzeugung unterschiedlicher Produktvarianten bildet und
- einer Produkttestplattform, mit deren Infrastruktur, Testumgebungen und abstrakten Testfällen alle Produktvarianten automatisiert validiert werden können.
Entscheidend ist es nun strategisches Plattformdenken mit agilem Vorgehen zu kombinieren. Dies führt uns zum inkrementellen Ansatz „Think Big Start Small“. Man hat zwar eine klare Vision, wie Prozesse und Software einmal sein sollen, aber man entwickelt nicht erst jahrelang ausschließlich Plattformen. Vielmehr ist folgendes Vorgehen sinnvoll:
- die Transformation zur normgerechten agilen Entwicklung kann unabhängig über mehrere Jahre Schritt für Schritt mit Unterstützung eines externen Beraters ablaufen;
- der Hersteller übernimmt ein bewährtes Architekturrahmenwerk von einem externen Partner mit Erfahrung in Plattformentwicklung;
- er übernimmt Teile der internen Entwicklerplattform des externen Partners und entwickelt diese dann Schritt für Schritt weiter;
- der Hersteller beginnt die sequenzielle Entwicklung der Produkte in seinem Portfolio;
- er übergibt die Entwicklung der Infrastrukturplattform seinem externen Partner, der sich beispielsweise zunächst auf jeweils ein Gerät der Leistungsklassen klein, mittel und groß fokussiert;
- der externe Partner stellt eine API mit einer Ausführungsumgebung für Desktoprechner zur Verfügung (Simulation);
- der Hersteller entwickelt selbst das erste Produkt in einer bestimmten Variante, zunächst in der Simulation und dann auf der Infrastrukturplattform;
- er entwickelt danach ein zweites Produkt oder eine Variante und übernimmt dazu Komponenten des ersten Produkts, wobei vorübergehend eine gewisse Redundanz akzeptabel ist;
- der externe Partner unterstützt dabei Produktplattformkomponenten aus dem Produktcode herauszurefaktorieren, bis sich mit dem dritten Produkt die Plattform stabilisiert hat;
- die Parteien achten darauf, dass offensichtliche Querschnittskomponenten den Weg in die Infrastrukturplattform finden, wie Stacks, Protokolle, Parameterverwaltung, u.v.m.;
- die Parteien achten auf Einheitlichkeit bei den UIs, M2M-Protokollen und den Gegenstellen wie Firmwareupdater, Konfigurationstools oder Apps;
- der externe Partner stellt dem Hersteller ein Grundgerüst einer Produkttestplattform, die den Prinzipien der generischen Testautomatisierungsarchitektur des ISTQB folgt, zur Verfügung und entwickelt diese parallel zur Firmware weiter, bis die Testplattform sich mit dem dritten Produkt stabilisiert hat und der Hersteller übernehmen kann.
Das oben beschriebene Vorgehen ist zukunftssicher und bläht das Softwareteam des Herstellers nicht auf. Er kann seine Entwickler mit Erfahrung in seiner Domäne dort einsetzen, wo sie am produktivsten sind. Der externe Partner kann dagegen seine Stärken ausspielen und benötigt keine Einarbeitungszeit in die Domäne des Herstellers.
Besitzen die Geräte des Herstellers eine breite öffentliche Parameterstruktur, die sich an vielen Kommunikationsschnittstellen widerspiegelt, sollte er zusätzlich über den Einsatz modellgetriebener Softwareentwicklung nachdenken. Kerngedanke dabei ist es ein Modell als „Single Source of Truth“ zu verwenden und dieses dann mittels Generatoren in unterschiedliche Zieltechnologien abzubilden. Dadurch kann das für die Softwareentwicklung fundamentale Konzept „Don’t Repeat Yourself“ technologieübergreifend realisiert werden. Änderungen werden zentral am Modell durchgeführt und propagieren sich automatisch in alle abhängigen Teile. So können beispielsweise die WebUI und mehrere Feldbus DDs automatisch erzeugt und konsistent gehalten werden.
Mit der oben beschriebenen Strategie kann der Hersteller eine qualitativ hochwertige, wartbare, moderne Software erzeugen und über den gesamten Lebenszyklus supporten:
- durch das inkrementelle Vorgehen werden die Investitionskosten über die Lebenszeit des gesamten Portfolios verteilt;
- durch den Fokus auf Wiederverwendung vom ersten Gerät an sinken die Entwicklungskosten und die Time-to-Market mit jedem Produkt und
- durch das Plattformkonzept bleiben die Wartungskosten trotz Variantenvielfallt im Rahmen.