Die acht Phasen des Produktlebenszyklus
Embedded-Geräte entwickeln – mit System
Durch einen fragmentierten Lebenszyklus von Embedded-Produkten verlieren OEM viel Zeit und Geld. Aber der Lebenszyklus lässt sich systematisieren – durch organisatorische Maßnahmen und mittels geeigneter Software.
Der Lebenszyklus eines vernetzten Embedded-Geräts – von der Entwicklung bis zur Entsorgung am Ende seines Lebens – kann 10, 20 oder noch mehr Jahre betragen und besteht aus einer Reihe klar abgegrenzter Phasen. Die Analyse von Foundries.io zählt acht Phasen. Bei vielen OEM entsteht beim Übergang zwischen diesen Phasen ein hohes Maß an organisatorischer und technischer Fragmentierung.
Diese Fragmentierung widerspricht den geschäftlichen Interessen jedes Produktherstellers. In einer rein rationalen Welt würden die OEM ihre Produkte so auslegen, dass sie sich im Feld leicht und kostengünstig sichern, warten und aktualisieren lassen. Das Produkt ist während seiner gesamten Lebenszeit eine einfache wirtschaftliche und physikalische Einheit. Das heißt, dass die Kosten zur Wartung des Produkts im Feld sowie zu seiner Entsorgung nicht isoliert vom Business Case betrachtet werden dürfen, der den Kaufpreis des Produkts rechtfertigt. Im Gegenteil müssen bei der Berechnung der Rentabilität eines Produkts dessen Kosten über die gesamte Lebensdauer mit dem Kaufpreis in Einklang gebracht werden. Das gilt auch für etwaige Einnahmen aus dem Kundendienst.
Leider beeinträchtigt die organisatorische Fragmentierung diesen rationalen Ansatz stark. In der Praxis wirken sich Entscheidungen und Maßnahmen des Entwicklungsteams im weiteren Verlauf auf die Test-, Produktions- und Wartungsteams aus. Konflikte zwischen den Teams und deren Arbeitsergebnissen können die Markteinführung von Produkten verzögern, ein höheres Risiko von Sicherheitsschwachstellen und entsprechender Haftung verursachen und die Prozesse zur Aktualisierung der Produkte behindern. Die Sicherheit wird häufig erst während der späteren Phasen der Produktentwicklung ernsthaft angegangen, was im weiteren Verlauf zu Problemen führt.
Derartige Komplikationen und Konflikte lassen sich vermeiden. Ein gewisses Maß an organisatorischer Fragmentierung ist unvermeidlich, denn es ist nur natürlich, dass beispielsweise die Entwicklung in einer anderen Abteilung als die Wartung erfolgt. Von der Technologie her besteht die Möglichkeit, die technische Basis eines vernetzten Embedded-Geräts über seinen gesamten Lebenszyklus zu vereinheitlichen.
Dieser Beitrag beleuchtet die acht Phasen im Lebenszyklus eines Produkts und zeigt den Wert einer neuen Generation von Embedded-DevSecOps-Plattformen auf (Development/Security/Operations). Diese stellen Werkzeuge bereit, um die Anforderungen zur Entwicklung, zur Sicherheit während der Lebensdauer, zur Wartung und zum Flottenmanagement eines Produkts zu erfüllen – und das ab dem Augenblick, an dem der OEM mit der Entwicklung beginnt.
Jobangebote+ passend zum Thema
Wert und Kosten der acht Phasen
Das Acht-Phasen-Modell für den Lebenszyklus eines Produkts gilt mehr oder weniger universell für alle Arten vernetzter Embedded-Geräte und alle Marktsegmente. Die Phasen sind:
1. Auswahl der zentralen Komponente – die Festlegung auf einen bestimmten Mikroprozessor, FPGA, Mikrocontroller, GPU oder anderen Bauteiltyp, um den herum die Hardware implementiert werden soll. Die Auswahl dieser Komponente bestimmt weitgehend den Typ der Software, die in dem Produkt ausgeführt werden kann, und die Anwendungen, die es unterstützt.
2. Vorbereitung – In dieser Phase planen die Entwickler einen ersten Ablauf für die Softwareentwicklung zur in der ersten Phase ausgewählten Komponente. Hierbei werden die Funktion des Supportpakets des Chipanbieters für das Board und Grundfunktionen wie das Flashen der ersten Boot-Images, die Konfiguration des sicheren Boot-Pfads und die Herstellung einer sicheren Netzwerkverbindung überprüft.
3. Entwicklung –Die Vorbereitungsphase liefert die Hardwarebasis für das Produkt. In Phase 3 erstellen die Entwickler die Anwendung, die den gesamten Wert des Produkts ausmacht. In dieser Phase lernen die Entwickler, mit dem Unerwarteten zu rechnen. Die Reaktion auf geänderte Marktverhältnisse oder technische Gegebenheiten kann dazu führen, dass in der Vorbereitungsphase erstellte Werkzeuge, Softwareplattformen oder Sicherheitsprozesse überarbeitet werden müssen oder sogar das in Phase 1 ausgewählte System-on-Chip (SoC) geändert werden muss.
4. Prototyp – Nach den ersten drei Phasen weiß der OEM, dass das SoC die meisten gewünschten Funktionen auf dem Evaluierungs-Kit ausführt. In der Prototypenphase erstellen die Entwickler die Anwendungssoftware für einen in Form, Größe und Funktionen spezifischen Prototyp. In dieser Phase macht sich das Produktionsteam mit dem Entwicklungsteam daran, das DFM (Design for Manufacturing) zu implementieren. Das heißt, dass das Team, das die Plattform entwickelt, neben dem BSP des ursprünglichen Evaluierungs-Kits gleichzeitig ein neues BSP für die kundenspezifische Hardware erstellt und pflegt.
5. Test – Jetzt kann das Testteam die vorgesehenen Funktionen der Anwendung überprüfen und sicherstellen, dass künftige Updates der Firmware und Anwendungssoftware vor der Implementierung getestet und validiert werden können.
6. Werkzeugerstellung – Die Systeme für die Serienproduktion werden nun implementiert. In dieser Phase könnte der OEM feststellen, dass die zu Erstellung der Prototypen im Labor eingesetzten Werkzeuge für die Produktion nicht geeignet sind. Sicherheitsabläufe für Funktionen wie Root-of-Trust und Schlüsselverwaltung sind jetzt besonders wichtig. Die Produktionsingenieure müssen häufig feststellen, dass die Abläufe zur Entwicklung und Erstellung der Prototypen in der Produktion nicht eingesetzt werden können.
7. Produktion – der entscheidende Moment, in dem der OEM nach allen bisherigen Arbeiten feststellt, ob die Produktentwicklung in der Produktion realisiert werden kann. Besonders wichtig ist es, festzustellen, ob die Produktionsabläufe für die Sicherung des Geräts, das Management seines Root-of-Trust und die Bereitstellung von Cloud-Service-Zugangsdaten mit dem Mechanismus für Firmware-Updates verknüpft werden können, der das Produkt während seiner Lebensdauer im Einsatz unterstützt.
8. Wartung – Gesetzliche Haftung, das Management des Rufs der Marke und behördliche Vorschriften setzen die OEM einem immer höheren Druck aus, regelmäßige Updates der Produkte im Einsatz vorzunehmen, um sowohl Sicherheitsschwachstellen zu beseitigen als auch den Betrieb des Produkts entsprechend den berechtigten Erwartungen der Kunden aufrechtzuerhalten.
Die Kosten der ersten sieben Phasen und der Wert, den sie schaffen, werden durch interne Faktoren bestimmt, etwa Fähigkeiten und Engagement der Entwickler und die Effektivität, mit der sie gemanagt werden.
Bei der achten Phase sehen die Dinge anders aus. Hier bestimmt die Außenwelt, wie oft und wie schwerwiegend ein Produkt durch Cyberangriffe gefährdet wird. Externe Faktoren bestimmen auch, wie oft Änderungen der Umgebung, etwa neue Anforderungen an die Zugangsdaten für die Cloud, Produktupdates im Einsatz erforderlich machen. Wenn auf eine CVE-Bekanntmachung (Common Vulnerabilities and Exposures) nicht richtig reagiert wird oder das Produkt Opfer eines Cyberangriffs wird, kann der OEM vor erheblichen rechtlichen und technischen Kosten stehen, die die Profitabilität des Produkts zunichtemachen. Eine effektive Wartung ist ein guter Schutz des OEM gegen solche Risiken.
Allzu oft wird die Wirksamkeit der Produktwartung in Phase 8 durch Entscheidungen in früheren Phasen beeinträchtigt.
Tatsächlich müssen die Produktmanager auf den Augenblick vorbereitet sein, in dem eine neue CVE-Bekanntmachung erfolgt und die Unternehmensleitung Antworten auf die folgenden Fragen verlangt:
● Was haben wir wann getan, um nicht zum Opfer einer Schwachstelle zu werden?
● Waren unsere Maßnahmen erfolgreich?
Das ist der Zeitpunkt, an dem viele OEM feststellen müssen, dass die Entwicklung eines Produkts schlechte Voraussetzungen für die Wartung und das Flottenmanagement geschaffen hat.
Fragmentierung im Entwicklungsprozess
Diese Exponierung gegenüber Risiken während der Lebensdauer ist eine häufige Folge von Fragmentierung im Entwicklungsprozess. In der Entwicklungs- und Prototypenphase sind andere technische Kompetenzen, Werkzeuge, Strukturen und Managementprozesse erforderlich als beim späteren Testen, in der Produktion und bei der Wartung.
Die dadurch entstehende organisatorische Trennung bewirkt unterschiedliche Anreize und Zeithorizonte in der Struktur der Produkteinheiten eines OEM. Dabei besteht die Gefahr, dass jedes Team Entscheidungen aus seiner eigenen engen Perspektive trifft, statt das gesamte Produkt im Blick zu haben. So hilft es beispielsweise, das SoC in der Vorbereitungsphase (Phase 2) zu sichern, weil diese Sicherung in einer späteren Phase mehr Zeit benötigt sowie kostspielige und zeitraubende Überarbeitungen der Firmware und Software erfordern kann.
In dieser Phase werden die Entwickler jedoch danach bewertet und belohnt, wie schnell sie eine funktionsfähige Plattform bereitstellen können, auf der die Anwendung erstellt werden kann. Das verleitet dazu, die Sicherheit zu vernachlässigen.
In ähnlicher Weise sorgt in der Entwicklungsphase das Erstellen einer Inventarliste der Codebasis (SBOM, Software Bill of Materials) dafür, dass ein Echtzeitprotokoll der Softwarekomponenten jeder Produktvariante entsteht. Eine SBOM wird zu einem wichtigen Element bei der Einhaltung der Spezifikationen für bei Behörden eingesetzte Software, und Einrichtungen wie die US Cybersecurity and Infrastructure Security Agency empfehlen dringend, umfassende SBOM zu erstellen und zu pflegen.
Natürlich verlangsamt das Ausarbeiten einer SBOM den Fortschritt des Produkts in der Entwicklungsphase (Phase 3), statt ihn zu beschleunigen, und so hat das Entwicklungsteam keinen Anreiz, sie zu erstellen. Deswegen gibt es zu vielen OEM-Produkten heute keine vollständige und aktuelle SBOM.
Generell haben sich die Prozesse zur Produktentwicklung in den ersten sieben Phasen des Produktlebenszyklus dahin entwickelt, die Interessen und Bedürfnisse der achten Phase zu vernachlässigen. Und die Entwicklungskultur bei vielen OEM für Embedded-Geräte fördert eine gewisse Ignoranz der Produktentwicklerteams für die Notwendigkeit, die Flotte der Produkte im Einsatz zu sichern, zu warten und zu aktualisieren.
DevSecOps-Plattformen: eingebaute Sicherheit und Wartung von Anfang an
Heutzutage bringen die Regeln der Behörden zur Gerätesicherheit und die hohen finanziellen und rufschädigenden Folgen von Sicherheitsproblemen immer mehr OEM von Embedded-Geräten dazu, nach Möglichkeiten zu suchen, um die Wartungsphase im Lebenszyklus des Produkts bereits vom Anfang der Produktentwicklung an zu unterstützen.
Ein vielversprechender Ansatz ist das Konzept der DevSecOps-Softwareplattform. Diese Art von Plattform stellt eine anpassbare Linux-Betriebsumgebung für eine große Zahl von SoC und Prozessoren bereit und unterstützt einen integrierten Ablauf für das Board-Enablement, die Sicherheit, Entwicklung und Wartung sowie das Flottenmanagement während des gesamten Produktlebenszyklus.
Der Einsatz einer integrierten DevSecOps-Plattform schafft die erforderlichen Verbindungen zwischen den einzelnen Phasen des Lebenszyklus. Beispiel:
● Die Unterstützung von SoC der führenden IC-Hersteller bedeutet, dass die Auswahl-, Vorbereitungs- und Entwicklungsphasen gleichzeitig und verzahnt ablaufen.
● Anwendungsentwickler können ihre Software gleichzeitig auf dem Evaluierungs-Kit des SoC und der kundenspezifischen Hardware einsetzen und dabei direkt und synchron zum Entwicklungsablauf auf die Produktionsbereitschaft hinarbeiten.
● Die Entwicklung auf dem Evaluierungs-Kit und der Ablauf vor der Produktion erfolgt mit demselben Backend-Build, den sicheren und Implementierungs-Frameworks, die auch in den Test-, Werkzeugerstellungs- und Produktionsphasen eingesetzt werden.
● Dabei entsteht automatisch eine SBOM, die für jede Instanz der Firmware und des Anwendungscodes des Produkts aktualisiert wird. In der Produktion wird anschließend für jede aus dem Werk versandte Produktionseinheit eine SBOM erzeugt. Die Bereitstellung einer SBOM für jeden einzelnen Node erlaubt es den Produktmanagern, bei einer CVE-Bekanntmachung schnell und ohne großen Aufwand auf Fragen zur Exponierung eines Produkts zu reagieren.
● Die Produktionswerkzeuge sind kompatibel zu den Entwicklungswerkzeugen, sodass die Produktionsteams frühere Builds innerhalb von Minuten wiederherstellen, alte Entwicklungen auf neue Firmware migrieren, detaillierte unveränderbare Protokolle für Aktualisierungen während der Lebensdauer des Geräts bereitstellen und die Implementierung des Anwendungscodes auf jedem einzelnen Node managen können.
● Alle diese früheren Phasen sind umfassend in die Werkzeuge zum Flottenmanagement sowie die sichere Bereitstellung und Implementierung von OTA-Updates integriert.
Mit der Implementierung der Produktentwicklung auf einer DevSecOps-Plattform wie dem Produkt »FoundriesFactory« von Foundries.io (https://foundries.io/products/) können OEM die Risiken bei der Sicherheit und der Produktwartung ausschließen, die sonst durch die natürliche Fragmentierung der organisatorischen Einheiten entstehen.
Eine vereinheitlichte Plattform mit gemeinsamen Werkzeugen von Phase 1 bis Phase 8 schafft auch mehr Möglichkeiten zur Entwicklung und Implementierung neuer Features und für mehr Gelegenheiten, zusätzliche Umsätze in der installierten Basis vernetzter Geräte zu generieren. Damit kann der Einsatz einer DevSecOps-Plattform die Wartungsphase 8 des Produktlebenszyklus von einer potenziellen Quelle für finanzielle Verluste und Rufschäden in eine Möglichkeit verwandeln, zusätzliche Umsätze zu erzielen.
Der Autor
John Weil ist Chief Marketing Officer bei Foundries.io.
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
