Ein Angebot von

Embedded System: Sein Lebenszyklus von der Wiege bis zum Grab

| Autor / Redakteur: Alfred Ressenig, Remo Markgraf* / Sebastian Gerstl

Welche Phasen durchläuft ein Embedded System während seines gesamten Lebenszyklus – von der Konzeption bis hin zur Abkündigung? Und welche Maßnahmen müssen in welchen Abschnitten getroffen werden? Ein Praxis-Bericht aus dem Leben eines Embedded Systems für einen Kaffeeautomaten.
Welche Phasen durchläuft ein Embedded System während seines gesamten Lebenszyklus – von der Konzeption bis hin zur Abkündigung? Und welche Maßnahmen müssen in welchen Abschnitten getroffen werden? Ein Praxis-Bericht aus dem Leben eines Embedded Systems für einen Kaffeeautomaten. (Bild: StockSnap auf Pixabay / CC0)

Nehmen wir eine Steuerung für einen Kaffeeautomaten und betrachten für dieses Embedded-System den Lebenszyklus von der Geburtsstunde bis zum Ruhestand. Die Steuerung erzählt eine spannende Geschichte mit vielen Überraschungen. Die eine oder andere Episode aus dem Lebenslauf des Embedded-Systems ESKA01 kommt Ihnen mit Sicherheit sehr bekannt vor.

Das systematische Management des Lebenszyklus ist ein wirksames Steuerungsinstrument in so heiklen Phasen wie Entwicklung, Integration und Einführung von Embedded-Systemen in den Markt. Es sorgt für Struktur und Ordnung, spart Ihnen Zeit und Geld und erspart Ihnen verärgerte Kunden. Dieser Beitrag stellt den Lebenszyklus und das Management des Lebenszyklus von Embedded-Systemen und Produkten vor. Er erläutert die Vorteile und gibt Ihnen praktische Tipps und Best-Practice-Empfehlungen für die Umsetzung mit auf den Weg.

Für jedes Embedded-System gilt: Es hat eine Geburtsstunde, und es wird eines Tages in den Ruhestand verabschiedet. Jedes Embedded-System hat somit ein Leben, und dieses Leben wollen wir näher betrachten, indem wir es in Phasen unterteilen. Lassen wir ein Embedded-System seine eigene Lebensgeschichte erzählen.

1. Die Lebensgeschichte von ESKA01

Hallo, darf ich mich vorstellen? Mein Name ist ESKA01. Ich bin ein Embedded-System für einen Kaffeeautomaten. Geboren bin ich am 5. April 2011. Herr Müller von der Kaffeeautomatenfirma hatte die Idee, dass ich eines Tages die Steuerung und Bedienung eines neuen Kaffeeautomaten übernehmen sollte. Er hat auch gleich das erste Konzept erstellt, was ich so alles machen sollte. Meine Embedded-Firma erhielt danach den Auftrag, mich zu entwickeln. So fing alles an.

Ideenfindungsphase
Die erste Phase nennen wir die Ideenfindungsphase. Im Embedded-Umfeld überwiegen kundenspezifische Auftragsarbeiten, wie in unserem Beispiel für die Steuerungs- und Bedienkomponente eines Kaffeeautomaten. Die Phase der Ideenfindung erfolgte hier also beim Auftraggeber, der Kaffeeautomatenfirma.

Entwicklungsphase
Die zweite Phase ist die Entwicklungsphase bestehend aus der Konzepterstellung, der eigentlichen Entwicklung und der Integration. In unserem Beispiel wurde das Grobkonzept vom Auftraggeber vorgegeben. Das Feinkonzept, die Entwicklungstätigkeit und der Modultest erfolgen beim Auftragnehmer. Das läuft dann ungefähr so ab:

Oliver sollte die Software entwickeln und Martina die Hardware. Blöd nur, dass gleich nach der Beauftragung die Urlaubszeit begann. Herr Müller war drei Wochen auf den Malediven und nicht erreichbar. Sein Stellvertreter kannte sich nicht so recht aus und konnte bei Klärungen kaum helfen. Anschließend fuhr Oliver zwei Wochen zum Nordkap. Am letzten Urlaubstag hat er sich das Handgelenk derart verstaucht, dass er zwei weitere Wochen nicht am Computer arbeiten konnte. Immerhin konnte er telefonieren, und Herr Müller war ja auch wieder da.

Meine Entwicklung war deshalb von Beginn an in Verzug. Der Chef von der Kaffeeautomatenfirma wurde bald ganz schön nervös. Er kann ja den Kaffeeautomaten nicht ohne mich an Kunden verkaufen. Da wurde mir zum ersten Mal bewusst, wie wichtig ich eigentlich bin.

Ein Projektverzug ist nichts Ungewöhnliches. Ein Redesign auch nicht. ESKA01 erzählt:

Oliver meinte, wir könnten den anfänglichen Projektverzug gut aufholen, wenn wir das Konzept etwas abspecken. Das war der Auslöser für mein erstes Redesign. Martina war total beleidigt, weil sie die ganze Arbeit wieder von vorne beginnen musste. Sie kam frisch von der Uni und meinte damals noch, das sei eine Ausnahme. Viele Überstunden später gab es eine erste Version von mir.

Am Ende der Entwicklungsphase steht die Integration des Embedded-Systems in das Referenzprodukt an. Diese Aufgaben mit den Systemtests werden gemeinsam von den beiden beteiligten Firmen durchgeführt und bergen so manche Überraschungen:

Die Kaffeeautomatenfirma hat groß angekündigt, dass Kunden uns ab 15. November kaufen können. Für meine Integration in den Kaffeeautomaten haben sie allerdings nur vier Wochen angesetzt. Das erste Unglück war ein Verständnisproblem über die Wassermenge im Kaffee. Es ließ sich nicht mehr nachvollziehen, wer was vereinbart, geändert oder entschieden hat. Auf alle Fälle hat es Oliver falsch programmiert. Dann gab es noch den Bug von Martina bei den Anschlüssen, den wir lange nicht gefunden haben. Am 15. November waren wir noch mitten im Integrieren. Der Chef der Kaffeeautomatenfirma war fuchsteufelswild. Herr Müller war nahe daran zu kündigen. Oliver ging zur Nachbehandlung des verstauchten Handgelenks. Martina wurde immer hektischer.

Marktphase
Nach Abschluss der Integration kann das Produkt in den Markt eingeführt werden, und es beginnt die dritte Phase für ein Embedded-System, die Marktphase. Das Referenzprodukt mit dem Embedded-System als Teilkomponente kann von Kunden gekauft und benutzt werden.

Die Markteinführung war ein Desaster. Der Chef der Kaffeeautomatenfirma bestand auf dem 1. Dezember als allerspätesten Einführungstermin. Von wegen ruhige Weihnachtszeit. Unser Servicepersonal war fast nur mehr bei den Kunden und hat es mit viel Kreativität und üblen Tricks geschafft, dass die Tasse Kaffee und der Espresso einigermaßen genießbar waren. Nach dem dritten Patch, den Oliver und Martina geliefert haben, gingen dann auch die Beschwerden über den Cappuccino deutlich zurück.

Die Marktphase dauert so lange, wie das Referenzprodukt auf dem Markt von Kunden neu gekauft werden kann. Für den Hersteller eines Embedded-Systems gilt es, Mängel zu beheben und Garantieverpflichtungen nachzukommen. Gegebenenfalls gibt es zusätzlich Produktanpassungen und -erweiterungen. Das bedeutet, dass auch in der Marktphase Budget und Ressourcen für das Embedded-System einzuplanen sind.

Nach der mühsamen Markteinführung ist es dann doch noch ganz gut gelaufen. Der Kaffeeautomat schnitt bei Vergleichstests sehr gut ab und hat sich dann prächtig verkauft. Oliver und Martina bekamen großes Lob von Herrn Müller. Martina konnte endlich in den Urlaub gehen.

Abkündigungsphase
Die vierte und letzte Phase für ein Embedded-System ist die Abkündigungsphase. Das Referenzprodukt wird nicht mehr auf dem Markt angeboten. Bestehende Kundenverpflichtungen müssen jedoch noch erfüllt werden. Im Allgemeinen sind dies wiederum Garantieverpflichtungen. Die Abkündigungsphase endet, wenn es keine Kundenverpflichtungen mehr gibt und keine weiteren Aufwände mehr anfallen. Weder Budget noch Ressourcen müssen in Zukunft vorgehalten werden. Das Embedded-System wird beim Hersteller in den wohlverdienten Ruhestand verabschiedet.

Schön war mein Leben als Embedded-System! Der Anfang war ausgesprochen turbulent. Schlussendlich gab es dann aber doch viele zufriedene Kunden. Mein Nachfolger ESKA02 steht in den Startlöchern. Ich wünsche ihm viel Erfolg und ein langes Leben.

2. Lebenszyklus eines Embedded-Systems als Auftragsarbeit

Das soeben vorgestellte Embedded-System wurde als Dienstleistung und kundenspezifische Auftragsarbeit hergestellt. Es hat vier Lebenszyklusphasen (siehe Bild 1). Das Geschäftsmodell ist unabhängig von der Anzahl der verkauften Referenzprodukte. Der Auftraggeber bezahlt den Auftragnehmer entweder entsprechend des Projektfortschritts, oder er begleicht die vereinbarte Gesamtsumme am Ende der Entwicklungsphase.

3. Lebenszyklus von Massenprodukten

Produkte, die für den Massenmarkt vorgesehen sind, wie der Kaffeeautomat in unserer Embedded-Lebensgeschichte, haben ein ganz anderes Geschäftsmodell. Sie müssen sich möglichst oft verkaufen. Erlöse fließen nicht am Ende der Entwicklungsphase wie bei der Auftragsarbeit, sondern jeweils nach dem Verkauf eines Produkts an Kunden. Die Marktphase im Lebenszyklus ist wesentlich komplexer und wird in fünf eigene Phasen unterteilt: Einführung, Wachstum, Reife, Sättigung und Degeneration. Bild 2 erklärt die einzelnen Phasen.

4. Management des Lebenszyklus

Ein systematisches Management des Lebenszyklus liefert einen signifikanten Beitrag zu einer erfolgreichen Geschäftsentwicklung.

Grundlegende Idee
Ein Unternehmen plant und steuert den Lebenszyklus eines Embedded-Systems oder eines Produkts. Das funktioniert über Meilensteine, auch Gates genannt, die als Türöffner für einen neuen Zustand im Lebenszyklus dienen. Die Tür wird geöffnet, wenn alle Voraussetzungen für den nächsten Zustand erfüllt sind, in der Lebenszyklussprache – wenn alle Kriterien für den entsprechenden Meilenstein erfüllt sind.

Die Hauptaufgabe im Lebenszyklusmanagement besteht darin, die Meilensteine terminlich zu planen (z.B. Markteinführung am 6. Februar 2018) und anhand der definierten Kriterien zu überprüfen, ob ein Meilenstein für das geplante Datum erklärt werden kann. Um bei dem Beispiel zu bleiben, werden in einer eigenen Besprechung auf Managementebene circa eine Woche vorher die Voraussetzungen überprüft, ob die Markteinführung tatsächlich am 6. Februar 2018 erfolgen kann.

Die Basis für das Lebenszyklusmanagement bilden ein Modell, das den Lebenszyklus abdeckt, sowie die Meilensteine, die die wesentlichen Zustandsübergänge im Modell definieren. Modelle kennen wir bereits, siehe Bilder 1 und 2. Meilensteine gibt es in drei Ausprägungen:

  • Marktmeilensteine
  • Entwicklungsmeilensteine
  • Vermarktungsmeilensteine

Marktmeilensteine
Acht Marktmeilensteine M0 bis M7 decken den kompletten Lebenszyklus eines Produkts von der Ideenfindung bis zum Ende der Produktabkündigung ab (Bild 3). Beispiel: Der Marktmeilenstein M3 gibt an, dass das Produkt an ausgewählte Pilotkunden ausgeliefert werden kann. Kriterien für diesen Meilenstein können sein:

  • Das Produkt leistet in einer Vorabversion die Grundfunktionalität in ausreichender Qualität.
  • Pilotkunden sind ausgewählt und bereit, das Produkt in einer Vorabversion zu erproben.
  • Das Produkt kann als Vorabversion an die Pilotkunden ausgeliefert und verwendet werden.

Für ein Produkt oder ein Embedded-System in Auftragsarbeit sind nur ausgewählte Marktmeilensteine relevant: M1, M3 und M4 für die Entwicklung und Markteinführung sowie M6 und M7 für die Abkündigung.

Entwicklungsmeilensteine
Bild 4 zeigt die vier Entwicklungsmeilensteine rfd, rfp, ga und eod, die die Entwicklungstätigkeit für ein Embedded-System oder Produkt abdecken.

Beispiel: Der Entwicklungsmeilenstein ready for piloting (rfp) gibt an, dass die Entwicklung des Produkts für einen Piloteinsatz abgeschlossen ist. Kriterien für diesen Meilenstein können sein:

  • Das Produkt steht in einer ausreichend getesteten Vorabversion zur Verfügung.
  • Die Grundfunktionalität des Produkts ist fertig entwickelt.
  • Die Qualitätskriterien für eine Vorabversion werden erfüllt.
  • Das Produkt kann als Vorabversion an Pilotkunden ausgeliefert werden.

Für ein Embedded-System in Auftragsarbeit sollte noch ein weiterer Entwicklungsmeilenstein in Betracht gezogen werden: ready for integration (rfi).

Vermarktungsmeilensteine
Bild 5 zeigt die vier Vermarktungsmeilensteine rfm, eom, rfo und eoo, die die Produktvermarktung und den Produktvertrieb abdecken.

Beispiel: Der Vermarktungsmeilenstein ready for ordering (rfo) wird erklärt, wenn das Produkt an Kunden verkauft werden kann. Kriterien für diesen Meilenstein können sein:

  • Preise und Rabatte sind festgesetzt.
  • Bestellnummern sind definiert.
  • Rechnungen können erstellt werden.
  • Kundenverwaltung ist eingerichtet.
  • Verkaufspersonal ist geschult.

Die Marktmeilensteine sind für ein Produkt oder Embedded-System in Auftragsarbeit nicht relevant.

Agile Entwicklung und Lebenszyklusmanagement
Das Lebenszyklusmanagement beeinflusst die Entwicklungsmethodik nicht. Es ist übergeordnet und stellt durch Meilensteine sicher, dass definierte Voraussetzungen erfüllt sind, bevor eine bestimmte Tätigkeit beginnen kann.

Ein Beispiel soll dies verdeutlichen. Logische Voraussetzungen, dass die Entwicklungsarbeit für ein Embedded-System beginnen kann, sind:

  • Entwicklungspersonal ist für die neue Aufgabe zugeteilt und steht zur Verfügung.
  • Scrum-Teams sind gebildet.
  • Geforderte Kompetenzen sind vorhanden.
  • Entwicklungsinfrastruktur und -tools sind vorhanden und einsatzbereit.
  • Allgemeine Beschreibung, grundlegende Epics und ein initialer Product Backlog für das zu erstellende Embedded-System sind vorhanden.

Genau diese Voraussetzungen können als Kriterien für die Erklärung des Meilensteins ready for development (rfd) definiert werden. Bevor die Entwicklung mit der eigentlichen Arbeit beginnt, werden die Kriterien in einem Gremium verifiziert. Grünes Licht für die Entwicklungsarbeit wird gegeben, wenn die Kriterien und damit die Voraussetzungen für diese Tätigkeit erfüllt sind.

5. Vorteile des Lebenszyklusmanagements

Die Vorteile sind vielfältig (siehe Tabelle):

Tabelle 1: Vorteile des Lebenszyklusmanagements
Tabelle 1: Vorteile des Lebenszyklusmanagements (Bild: RealSkills)

6. Tipps und Handlungsempfehlungen für die praktische Umsetzung

Struktur und Ordnung in den Geschäftsabläufen bilden eine wichtige Stütze für den wirtschaftlichen Erfolg eines Unternehmens. Das Management des Lebenszyklus leistet dafür einen wesentlichen Beitrag, indem es durch Meilensteine und sorgfältig definierte Kriterien für die Erklärung der Meilensteine eine Grundstruktur vorgibt. Es betrifft alle Organisationseinheiten eines Unternehmens, die einen Beitrag zur Definition, Entwicklung, Produktion und Vermarktung liefern.

Die Best-Practice-Empfehlungen für ein wirkungsvolles Lebenszyklusmanagement beziehen sich auf drei Bereiche, siehe Abbildung 6:

  • Schaffen von Rahmenbedingungen
    Sie benötigen ein Modell für den Lebenszyklus, welches die Lebensphasen Ihrer Embedded-Systeme oder Produkte darstellt. Abbildungen 1 und 2 zeigen einen Ansatz dafür. Aufbauend auf dem Modell benötigen Sie Meilensteine mit zu erfüllenden Kriterien, die als Türöffner für eine neue Phase dienen. Beides kann von einem gut ausgebildeten Produktmanagement geliefert werden.
  • Fokus auf kritische Bereiche
    Die Markteinführung ist so ein kritischer Bereich. Die Anzahl von Fehlerquellen und Stolpersteinen ist enorm. Das Lebenszyklusmanagement unterstützt Sie dabei, dass Ihr Embedded-System oder Produkt nicht zu früh und in unreifem Zustand in den Markt kommt und dadurch nachhaltiger Schaden entsteht. Ein weiterer sensibler Bereich ist die Abkündigung, die häufig übersehen und unterschätzt wird. In der Praxis bedeutet dies, dass genau diese Meilensteine mit großer Sorgfalt definiert und überprüft werden.
  • Einbettung der Aufgaben in das Unternehmen
    Stellen Sie sicher, dass das Lebenszyklusmanagement in Ihre Prozesslandschaft integriert wird. Die Gesamtverantwortung kann dem Produktmanagement zugewiesen werden. Marktmeilensteine gehören ebenfalls in den Verantwortungsbereich des Produktmanagements, Entwicklungsmeilensteine zur Entwicklung, Vermarktungsmeilensteine zu Marketing und Vertrieb. Definieren Sie Gremien und die Teilnehmer, die erforderlich sind, um Meilensteine zu erklären.

Der Lebenszyklus von Embedded-Systemen und Produkten ist komplex und birgt viele Überraschungen. Ein sorgfältig definiertes und integriertes Management des Lebenszyklus bringt Ordnung und Planungssicherheit in viele Vorgänge und unterstützt unternehmerische Entscheidungen. Ein gut ausgebildetes Produktmanagement ist die bevorzugte Wahl für die Umsetzung des Lebenszyklusmanagements in modernen Unternehmen.

Warum Anforderungsmanagement eine lebenslange Verantwortung darstellt

Warum Anforderungsmanagement eine lebenslange Verantwortung darstellt

08.02.19 - Anforderungsmanagement ist nicht mit dem Start eines Projekts abgeschlossen. In der Softwareentwicklung müssen Requirements und Entwicklungskomponenten von Beginn an wie auch dauerhaft verbunden und gepflegt werden. lesen

Funktionale Sicherheit über den Entwicklungs-Lebenszyklus hinaus sicherstellen

Funktionale Sicherheit über den Entwicklungs-Lebenszyklus hinaus sicherstellen

15.11.18 - Im Zeitalter konstant mit dem Internet verbundener Systeme kann Softwareentwicklung nie als endgültig abgeschlossen betrachtet werden – sobald eine neue Sicherheitslücke auftaucht, muss diese auch sofort geschlossen werden. Wie bekommt man diesen Kreislauf in den Griff? lesen

Zukunftssicherheit von Embedded-Software

Softwaresicherheit, Teil 3

Zukunftssicherheit von Embedded-Software

29.01.13 - Im dritten Teil unserer Serie geht es um den etwas schwieriger zu definierenden Begriff der Zukunftssicherheit. Dabei soll es nicht ausschließlich darum gehen, dass künftige Anforderungen der Betriebs- und Angriffssicherheit, der Funktionalität, des Designs und der Standards auch in Zukunft wettbewerbsfähig erfolgen lesen

(Dieser Beitrag wurde mit freundlicher Genehmigung der Autoren dem Tagungsband Embedded Software Engineering Kongress 2017 entnommen.)

* Alfred Ressenig ist Gründer und Inhaber der Firma RealSkills. Als Dozent an der Hochschule München hält er Vorlesungen über technisches Produktmanagement.

* Remo Markgraf ist Senior Management Consultant bei der MicroConsult GmbH. Er lehrt und berät umfassend zu den Themengebieten Cortex-M, Testen, Test-Driven Development und agile Entwicklung.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45833217 / Software Engineering)