Der Software-Lebenszyklus Architekturentscheidungen und daraus resultierende Kosten für die Sicherung eingebetteter Systeme

Anbieter zum Thema

Green Hills Software Ltd

MicroConsult Academy GmbH

emlix GmbH

RTI Real-Time Innovations

Grundlegende Software-Architekturentscheidungen zu Betriebssystem, Middleware und OTA-Updates beeinflussen nicht nur die Sicherheit eines Embedded-Systems. Sie haben auch langfristige Auswirkungen auf Entwicklungs- und Wartungskosten.

Embedded-Systeme haben generell eine Lebensdauer von mehreren Jahren. Insbesondere wenn strenge Sicherheitsanforderungen zu erfüllen sind, müssen mehrere Lebenszyklus-Iterationen berücksichtigt werden. Das beginnt bereits bei der Konzeption und Entwicklung: In seinem grundlegenden Werk „Software Engineering“ von 1999 hat Softwareingenieur Stephen R. Schach ein ungefähr relatives Kostenmodell für die Phasen des Software-Lebenszyklus aufgestellt (siehe Bild 1). Dieses Modell zeigt, dass etwa zwei Drittel der Lebenszykluskosten auf die Wartungsphase entfallen: Software-Updates nach Auslieferung, um Fehler zu beheben, neue Funktionen hinzuzufügen, sie auf neue Plattformen zu portieren oder sie an neue Technologien anzupassen. Es ist wichtig, frühzeitig die Auswirkungen eines Betriebssystems und seiner Middleware auf diese Softwareänderungen zu analysieren. Bereits bei den Entscheidungen für die Wahl einer zuverlässigen Softwarearchitektur muss gewährleistet sein, dass diese ohne großen Aufwand aktualisiert und in einer Fahrzeugflotte eingesetzt werden kann.

Die offensichtlichsten Faktoren, die zu den allgemeinen Softwareentwicklungskosten beitragen, sind Lizenzierung und Entwicklungszeit. Diese sind meist im Voraus bekannt. Wichtiger ist, die Kosten zu analysieren, die bei der Instandhaltung eines Systems anfallen. Dabei geht es nicht nur um die Entwicklungszeit für Funktionsaktualisierungen oder Sicherheitskorrekturen: solche Aktualisierungen können auch Änderungen an anderen Komponenten des Systems nach sich ziehen.

Zeit ist ein weiterer Kostenfaktor. Sowohl der Aufwand, den das Engineering und das Produktmanagement aufwenden müssen, um die bezogenen Softwarekomponenten auf potenzielle Risiken wie Sicherheitsmängel zu überwachen, als auch die Zeit, die das Engineering benötigt, um diese Änderungen einzubauen. Das umfasst die Aktualisierung und das Testen neuer Versionen, die Entscheidung, welche Komponenten zu berücksichtigen sind, und wie häufig Updates durchgeführt werden sollen.

Dabei ist es unvermeidlich, dass sich der Code während des Lebenszyklus ändert. Daher ist auch wichtig, ein geeignetes Design für die Durchführung von Systemaktualisierungen zu wählen. Eine flexible und sichere Over-the-Air-Update (OTA)-Lösung, die Updates für ein einzelnes Fahrzeug oder eine ganze Flotte bereitstellt, kann die Entwicklungszeit für die Bereitstellung weiter minimieren und so einen Teil der Lebenszykluskosten senken.

Betriebssystem: Proprietär vs. Open-Source

Die Abwägung zwischen der Verwendung eines proprietären Betriebssystems und einer Open-Source-Lösung, beispielsweise für ein Embedded Linux, hat unterschiedliche Auswirkungen. Bei der Wahl eines eingebetteten Linux-OS gibt es viele versteckte Kosten in Bezug auf die Entwicklungszeit, da Abhängigkeiten zwischen einer Vielzahl von Softwarepaketen bestehen. Die Entscheidung für ein Open-Source-Linux kann daher versteckte Kosten verursachen, die zu Beginn des Programms nicht vorhersehbar sind, da durch diese Abhängigkeiten zusätzliche Entwicklungszeit anfällt, um sie fehlerfrei zu lösen.

Außerdem ist zu bedenken, dass eine solche Lösung aus einem Linux-Kernel mit Millionen von Codezeilen und einer Vielzahl von Softwaremodulen besteht, die mit dem Kernel interagieren und jeweils ihren eigenen Wartungszyklus haben. Nicht nur der Kernel, sondern auch diese Module und die Interaktionen zwischen selbigen benötigen während des Software-Lebenszyklus Updates zur Erweiterung von Funktionen oder Patches. Um den Fortschritt dieser Kernel-Änderungen zu überwachen, ist ein erheblicher technischer Aufwand erforderlich.

Wenn Sie sich für ein proprietäres Betriebssystem entscheiden, müssen Sie sich nicht selbst um die Überwachung kümmern. Sie können sich in der Regel darauf verlassen, dass der Anbieter diese Informationen bereitstellt. Dies verringert den technischen Aufwand und setzt technische Ressourcen frei, die sie auf den Lebenszyklus der Anwendung und nicht auf systembedingte Abhängigkeiten verwenden können. Obwohl proprietärer Code und Lösungen gewisse Lizenzkosten verursachen können, stellt sich dies in vielen Fällen als eine einfachere und kostengünstigere Lösung heraus.

Ein weiterer wichtiger Parameter, den es zu berücksichtigen gilt, ist die Sicherheit. Im Bereich der Embedded Software gibt es einige bewährte Betriebssysteme, z. B. das Integrity RTOS von Green Hills Software, die auf einem sicheren Design basieren und eine angemessene Isolierung und garantierte Ressourcenzuweisung bieten. Eine solche stabile und sichere Basis garantiert, dass die Rate der Sicherheitsupdates für den Betriebssystemkern in der Regel sehr niedrig bleibt.

Wie gut ist Ihre Middleware?

Die Grundprinzipien der Wartung gelten auch für Middleware. Im Gegensatz zu einem proprietären System enthält ein eingebettetes Linux-System auch hier mehr Komponenten, die im Zuge ihres Lebenszyklus auch mehr Änderungen durchlaufen.

Außerdem wird eingebettetes Linux in der Regel von top-down konfiguriert, was zu einer Vielzahl von Paketabhängigkeiten führt. Die am Markt etablierten proprietären Betriebssysteme verfolgen hingegen einen Bottom-up-Ansatz, bei dem nur die erforderlichen Middleware-Komponenten hinzugefügt werden. Dies reduziert die Codebasis und damit verbunden auch das Risiko für Schwachstellen. Es ist zwar immer noch möglich, Open-Source-Frameworks in einem ansonsten proprietären System zu verwenden. Aber die Wartungsmaßnahmen für diese Middleware bleibt bestehen – es sei denn, der Anbieter unterstützt auch diese Art der Integration.

Die Auswirkungen der Software-Architektur

Die Kommunikation zwischen Anwendungen stützt sich auf Mechanismen, die vom Betriebssystem unterstützt werden, und auf Dienste, die von der Middleware bereitgestellt werden. Der Rückgriff auf unterschiedliche Betriebssysteme und Middleware-Mechanismen birgt Risiken, insbesondere in stark vernetzten Systemen. Daher ist eine saubere Trennung durch klar definierte Schnittstellen erforderlich, um die Wartung zu erleichtern.

Die Trennung von Anwendungen wird in der Regel durch die Aufteilung in Prozesse beibehalten. Einige Systeme gehen sogar noch weiter: Integrity RTOS oder ähnliche Betriebssysteme führten das Konzept des Separation Kernels ein, das ursprünglich von John Rushby in einem Beitrag aus dem Jahr 1981 vorgestellt wurde. Dieses bietet völlige „freedom from interference“ und unterstützt eine Aufteilung der Anwendungen in mehrere Stufen der Kritikalität. Das ist für die Gesamtsystemarchitektur von erheblicher Bedeutung und trägt dazu bei, eine Architektur zu schaffen, die ein einfacheres Modell für Updates und potenzielle Sicherheits-Patches aufrechterhalten kann.

In einer Software-Architektur, die auf einem Separation Kernel aufbaut, ist jede Anwendung vollständig vor den anderen geschützt. Nur die Anwendungen, welche Erlaubnis zum Datenaustausch erhalten haben, können dies tun. In Bild 2 kann die Anwendung D intakt gehalten werden, während die Anwendungen A, B und C miteinander verbunden sind. Eine Wartungsaktualisierung von A wird sich also niemals auf D auswirken.

Mit Hilfe des Trennungsprinzips kann eine vollständig unabhängige Systemarchitektur aufgebaut werden, bei der nur die notwendigen Ressourcen, Anwendungen oder Middleware-Komponenten miteinander verbunden sind. Das Separation-Kernel-Konzept erweitert diesen modularen Ansatz auch auf seine Middleware-Komponenten und Gerätetreiber, die sich auf die Trennungsprinzipien stützen und im Benutzerbereich ausgeführt werden. Dies bietet weitere Zuverlässigkeitsschritte hin zu einem System mit geringerem Wartungsbedarf.

Ein Separation-Kernel-System kann auch Sicherheitsaktualisierungen für den Kernel bereitstellen, ohne dass sich dies auf die Anwendungen auswirkt. Das liegt daran, dass die Trennung über eine feste Schnittstelle erfolgt, die sich nicht ändern kann. Solche Aktualisierungen werden bei Betriebssystemen mit Separation-Kernel nur sehr selten vorgenommen. Dies unterscheidet sich von großen monolithischen Betriebssystem-Kerneln wie Linux, bei denen häufige Änderungen vorgenommen werden, die sowohl Sicherheitsprobleme als auch kleinere Funktionsänderungen betreffen.

Das Prinzip der Trennung von Anwendungen in Prozesse gilt wohl für alle Betriebssysteme, allerdings ist das Schutzniveau in Linux nicht dasselbe. Eine Schwachstelle wie die Privilegienerweiterung stellt ein Risiko dar, da bestimmte Anwendungen ein höheres Privileg und damit Zugriff auf geschützte Ressourcen erhalten können. Dies kann in einer Separation-Kernel-Architektur aufgrund der Definition der Funktionsweise eines Separation Kernels nicht geschehen.

Faktoren der Over-the-Air-Wartung

Mit OTA-Lösungen hat sich die Art, wie Software-Elemente an Fahrzeuge übertragen und Aktualisierungen durchgeführt werden, geändert. In diesem Hierbei kann es sich um die ausgeführte Binärdatei handeln, aber auch um Konfigurationseinstellungen oder sogar um Kryptografie-Schlüssel oder Sicherheitszertifikate.

Der treibende Faktor für die Aktualisierung ist die Softwarewartung. Es gibt aber auch andere geschäftsbezogene Faktoren. Darunter zählt beispielsweise die Vermeidung teurer Rückrufe, die Erweiterung von Funktionen auf dem Aftermarket, neue Umsatzmöglichkeiten oder die Überwachung der Produktnutzung.

OTA-Systeme bestehen aus einem Systemhost und einem Zielagenten, der den eigentlichen Aktualisierungsprozess durchführt (Bild 3). Das Host-System muss unter Umständen die Paketierung von Software für viele verschiedene Geräte unterstützen und die Anmeldeinformationen für alle Geräte verwalten. Es muss zudem in der Lage sein, wertvolle Ressourcen wie Kryptografie-Schlüssel sicher aufzubewahren. Darüber hinaus muss es die Codesignierung und andere sicherheitsrelevante Schritte verwalten, bevor es die Aktualisierung an die eingesetzten Geräte weiterleitet. Das Host-System sollte auch mit möglichen Leistungsproblemen während der Bereitstellung fertig werden. Die Entscheidung für eine OTA-Lösung führt wahrscheinlich zu zusätzlichen Lizenzkosten für Infrastrukturhardware und -software.

Die Entwicklung einer eigenen, vollständig integrierten OTA-Lösung ist zwar technisch möglich. Aufgrund der beschriebenen Voraussetzungen ist dies aber in der Regel keine kosteneffiziente Herangehensweise.

Die frühe Planung vermeidet später Kosten

Software-Wartung ist während der gesamten Lebensdauer eines eingebetteten Systems erforderlich. Eine sorgfältige Auswahl der Komponenten spart Zeit und Entwicklungskosten und trägt zum Aufbau eines sichereren Systems bei. Wenn Sie diese Schritte befolgen, sollte der Weg zu einem stabileren System klar sein:

• Wählen Sie ein Betriebssystem, das auf einem Separation Kernel basiert, um die Trennung der Softwarekomponenten zu verbessern.

• Wählen Sie Middleware-Komponenten, die weniger voneinander abhängig sind und auf einer soliden Trennung beruhen.

• Die Architektur sollte auf einer soliden Trennung und einer geringeren Komplexität beruhen. Es gilt, schlussendlich völlig unabhängige Anwendungen zu schaffen, die unterschiedlich kritisch sein können.

• Entscheiden Sie sich für eine OTA-Lösung, die benutzerfreundlich, sicher und effizient ist, um den Update-Verteilungsprozess so weit wie möglich zu automatisieren.

Diese sorgfältige Planung eines Systems zur Entwurfszeit wirkt sich automatisch positiv auf die Lebenszykluskosten des Fahrzeugs aus, da die Wartungstechnik einfacher und seltener wird. Die Zeitkosten für die Wartungstechnik müssen gegen die Lizenzkosten für verschiedene Komponenten abgewogen werden, deren Vergleich nicht immer trivial ist. (sg)

(ID:50306764)