Viele Embedded-Hersteller steigern ihre Produktivität durch „Produktlinien Software Engineering“ (PLSE) seit Jahrzehnten erheblich. Für andere ist es noch kein Begriff oder sie sind der Ansicht, dass es sich für ihre Anwendungsfälle nicht eignet. Tatsächlich können gerade Embedded-Hersteller bereits ab einem moderaten Produktportfolio stark von PLSE profitieren, da für sie Plattformen und Frameworks von der Stange nicht in Frage kommen, um ihren Entwicklungs- und Wartungsaufwand mit steigender Produkt- und Variantenvielfalt in Grenzen zu halten.
Das Ziel von PLSE ist es, eine Familie verwandter Softwareprodukte systematisch und effizient zu entwickeln, so dass eine gute Wiederverwendung und Variabilität erreicht werden kann. Bei erfolgreicher Umsetzung erhält man folgende Vorteile:
- Variantenvielfalt: Der Hersteller kann ein breiteres Produktportfolio anbieten oder Produkte leichter individuell nach Kundenwünschen bereitstellen.
- Qualität: Durch Standardisierung und Wiederverwendung können einzelne Komponenten viel ausgiebiger gereviewed und getestet werden. Querschnittsanforderungen, wie Cybersecurity oder einheitliche Benutzerschnittstellen, können in geeignetem Kontext adressiert werden.
- Kostenreduktion: Durch Wiederverwendung entstehen bei wachsendem Produktportfolio Degressionseffekte, so dass neue Produktvarianten immer günstiger hergestellt werden können.
- Time to Market: Da neue Produktvarianten Großteils aus bewährten Komponenten bestehen, reduziert sich die Entwicklungszeit auf die spezifischer Features.
Eine häufig beim PLSE angewandte Technik um Gemeinsamkeiten und Unterschiede zwischen Produktvarianten herauszuarbeiten sind Feature-Modelle. Dabei werden Features eines Systems mit ihren Beziehungen beschrieben:
- Mandatory: Ein Feature muss in jeder Produktvariante enthalten sein;
- Optional: Ein Feature kann enthalten sein, muss aber nicht;
- Alternative: Genau ein Feature muss gewählt werden;
- Or: Mindestens ein Feature muss gewählt werden;
- Requires: Ein Feature erfordert ein anderes oder
- Excludes: Zwei Features schließen sich gegenseitig aus.
Eine weitere wichtige Technik beim PLSE ist die Unterscheidung zwischen Domänenanalyse und Anforderungsanalyse. Die erste liefert das Verständnis der Welt, in der die Produkte operieren sollen. Die zweite beschreibt, was ein Produkt in dieser Welt leisten soll.
- Die Domänenanalyse beschreibt Entitäten und Prozesse in einem bestimmten Fachgebiet, die unabhängig von einer konkreten Softwarelösung existieren. Ihr Ergebnis ist ein Domänenmodell.
- Die Anforderungsanalyse beschreibt funktionale und nicht-funktionale Anforderungen an ein konkretes Produkt, um bestimmte Prozesse aus der Domäne umsetzten zu können. Als Ergebnis entsteht eine Liste von Requirements.
Um die Unterschiede zwischen PLSE und einem klassischen Vorgehen besser zu verstehen, ist es hilfreich zwischen Problemraum und Lösungsraum zu differenzieren. Der erste beschreibt was passieren soll und der zweite wie etwas passiert. Die Analysetechniken für die Produkte liegen demnach im Problemraum und die Architektur und die Implementierungsdetails im Lösungsraum.
Beim klassischen Vorgehen werden die Domänen- und Anforderungsanalyse häufig vermischt und auf das Domänenmodell verzichtet. Es existieren nur konkrete Requirements mit deren Hilfe ein konkretes Produkt entwickelt wird. Daher können Problem- und Lösungsraum sehr eng zusammenrücken. Dies hat häufig zur Folge, dass auch die Klassenstruktur in der Software von technischen Begriffen dominiert wird und man Konzepte aus der Domäne auf den ersten Blick kaum erkennen kann. Softwareentwicklern und Fachexperten fällt es dann schwer in einer einheitlichen Sprache zu kommunizieren. Businesslogik muss häufig aus dem Code reverse engineered werden.
Beim PLSE existiert eine klare Trennung zwischen Domänen- und Anforderungsanalyse. Neue oder geänderte Produktfeatures bedingen stets eine Erweiterung bzw. Anpassung des Domänenmodells. Der Entwicklungsprozess läuft nicht wie beim klassischen Vorgehen ab, sondern es existiert eine neue Tätigkeit: die Domänenimplementierung. Dabei werden Komponenten mit den Features implementiert, die bei der Domänenanalyse herausgearbeitet wurden. Es entstehen rein fachliche Klassen ohne technischen Ballast, die produktunabhängig und damit wiederverwendbar sind. Dieser Lösungsraum spiegelt nun direkt den Problemraum wieder. Im nächsten Schritt bedienen sich dann konkrete Produkte an den Komponenten der Domänenimplementierung und fügen technischen Aspekte gemäß ihren Requirements hinzu. Dazu können beispielsweise die Techniken aus dem Domain-Driven-Design angewandt werden.
Einige Embedded-Hersteller sehen zwar die Vorteile des PLSE, bleiben jedoch skeptisch weil sie befürchten, dass es sich für eingebettete Systeme nicht eignet. Dabei sehen sie folgende Punkte:
- Ressourcenbeschränkungen: PLSE erzeuge schwergewichtige Firmware, die mit den vorhandenen Einschränkungen in Speicher, Rechenleistung und Energieverbrauch nicht vereinbar wären. Natürlich ist es korrekt, dass generische Software im Vergleich zu Speziallösungen immer einen gewissen Overhead mitbringt. Mit den richtigen Techniken, wie modellgetriebener Softwareentwicklung und Compile-Time-Polymorphismus lässt sich dieser jedoch stark minimieren. PLSE ist ein mächtiges Werkzeug, mit dem sich aber schlanke Anwendungen bauen lassen.
- Komplexität: PLSE erzeuge komplexe Software, die nur schwer zu verstehen und zu warten sei. Es ist korrekt, dass PLSE elaborierte Techniken, Architekturen und Design-Patterns benötigt. Um diese zu etablieren braucht man erfahrene Entwickler. Außerdem ist die Modellierung einer Produktfamilie komplex. Diese Komplexität kommt aus der Domäne die das Produktportfolio abdecken soll und ist damit essentiell und nicht akzidentell.
- Initialaufwand: PLSE erzeuge einen hohen initialen Aufwand. Es ist ein Fakt, dass sich PLSE erst rentiert, wenn man damit mehrere Produkte und Varianten umsetzen kann. Entscheidet sich ein Hersteller jedoch gegen PLSE und setzt duzende Produkte individuell um, werden diese einen Wartungsaufwand erzeugen, die ihn kaum mehr ein neues Produkt entwickeln lässt.
Spätestens mit der Verpflichtung aus dem Cyber-Resilience-Act zeitnah Patches für Sicherheitslücken in allen Geräten liefern zu müssen, kommen Embedded-Hersteller mit größerem Produktportfolio nicht mehr an einer Produktplattform vorbei. Wie Embedded Hersteller zu einer plattformbasierten Softwareentwicklung kommen können, ohne vorher ihre gesamte Firmenstruktur transformieren zu müssen, zeigt unser Artikel über Plattformstrategie.