Make or Buy Software-Bausteine für Aurix-Mikrocontroller

Systementwicklung beschleunigen heißt Kosten einzusparen.
Systementwicklung beschleunigen heißt Kosten einzusparen.

Die Systementwicklung zu beschleunigen bedeutet Kosten einzusparen. Das ist für sicherheitskritische Systeme besonders wichtig, weil gerade hier der Aufwand immens ist. Bei den Aurix-Mikrocontrollern von Infineon können existierende Software-Komponenten einen wichtigen Beitrag dazu leisten.

Die Anforderungen von funktionaler Sicherheit (Safety) und Sicherheit gegen ungewünschte Manipulation (Security) betreffen immer mehr Embedded-Applikationen. Oder in einfachen Worten ausgedrückt: Der Schutz der Umwelt vor Embedded-Systemen und der Schutz von Embedded-Systemen vor der Umwelt muss bei immer mehr Entwicklungen beachtet werden.

Dabei ist es inzwischen allgemein bekannt, dass beide Anforderungen – sowohl Safety als auch Security – durch die geforderten Entwicklungsprozesse – z.B. nach dem V-Modell – einen wesentlich größeren Aufwand erfordern als nach Standard-Qualitätsmanagement-Prozess. Dies kann bis zu einem Faktor vier an Mehraufwand bedeuten. Nicht nur dieser Fakt lässt die Frage „Make or Buy?“ neu bewerten. Einfluss darauf hat auch die Tatsache, dass ein Nutzer, der die Interna des Mikrocontrollers nicht genau kennt, nicht dieselbe Software-Qualität erreichen kann, wie es mit Zugriff auf die Chip-IP möglich ist. Am Beispiel des neuen Mikrocontrollers TriCore TC2x (Aurix) und der dafür verfügbaren Software-Komponenten soll hier das Für und Wider aufgezeigt werden.

Betriebssystem – integraler Bestandteil der Applikation

Natürlich gilt für alle Software-Komponenten die Frage, ob ein Kauf günstiger ist als die eigene Entwicklung. Für allgemeine Komponenten wie Kommunikations-Stacks und Dateisysteme würde das im Rahmen dieses Artikels aber zu weit führen. Hier soll es um die Software-Komponenten gehen, die spezifisch für den Aurix-Mikrocontroller sind. Dazu zählen Peripherie-Treiber, Echtzeit-Betriebssystem sowie Safety und Security Libraries. Für die meisten Komponenten gilt, dass sie immer sicherheitsrelevant sein müssen. Wenn das nicht der Fall ist, können einzelne Komponenten von der Sicherheitsbetrachtung des Systems ausgeschlossen werden, sofern sie durch eine Absicherung, wie z.B. eine Memory Protection Unit, davon abgehalten werden können, das sichere System zu stören.

Ein Echtzeit-Betriebssystem (RTOS) ist ein Kernteil einer Applikation. Da das RTOS selbst die Aufgabenverteilung der sicheren und unsicheren Tasks übernimmt, muss es selbst sicher sein und kann nicht von einer Memory Protection Unit von sicheren Teilen abgetrennt werden, ansonsten würde das RTOS seinen Sinn verlieren.

Angeboten werden unterschiedliche sichere Echtzeit-Betriebssysteme. Hier sollen beispielhaft zwei unterschiedliche Konzepte genannt werden. Das SafeRTOS ist ein zertifiziertes Betriebssystem, das bei mehreren Cores jeweils auf jedem Core in einer Instanz läuft. Dies bedeutet, dass beim Build der Applikation die Verteilung der Tasks auf die Cores festgelegt wird. Selbstverständlich können die Tasks auf den verschiedenen Cores über die Betriebssystemobjekte kommunizieren, z.B. über Message Queues oder Semaphore. Durch die deterministische Verteilung der Tasks bei der Erzeugung der Applikation wird das System sehr überschaubar und ist gemäß Sicherheitsaspekten leichter berechenbar.

PXROS ist ein zertifiziertes dynamisches Betriebssystem, das die Verteilung der Tasks auf die Cores zur Laufzeit optimieren kann. Hierdurch hat man den Vorteil der dynamischen Optimierung im Betrieb und ggf. Performance-Vorteile. Auch ist die Kommunikation der Tasks bei Laufzeit etwas schneller.

Welches der beiden Konzepte für die eigene Applikation besser ist, hängt von den Anforderungen und dem Sicherheitskonzept der gesamten Applikation ab und muss individuell bewertet werden. Beide Echtzeit-Betriebssysteme sind zertifiziert und werden mit den entsprechenden Dokumenten geliefert. Neben diesen beiden „Buy“-Varianten gibt es auch die Möglichkeit der eigenen Entwicklung inklusive Sicherheitskonzept und Validierung. Ob der Aufwand hierfür günstiger ist, bleibt zu bezweifeln.

Safety Libraries: Baustein für Zertifizierung

Solche Selbsttest-Bibliotheken beziehen sich sehr stark auf das Know-how der Interna des Mikrocontrollers. Die verfügbare SafeTlib für Aurix basiert auf der FMEDA (siehe Auswirkungsanalyse FMEDA) und kommt mit einem kompletten Sicherheitskonzept mit externem Watchdog. Die Bibliothek unterstützt die im Mikrocontroller eingebauten Sicherheitsfunktionen wie Lockstep und ECC, aktiviert diese und testet auch deren korrekte Fehlererkennung. Darüber hinaus übernimmt sie die Kommunikation mit dem Watchdog und führt die Tests aus, die nicht per Hardware unterstützt werden. Ein Anwender, der die „Assumptions of Use“ beachtet und die Funktionen nach Bedienungsanleitung einsetzt, setzt damit auf ein bewährtes System, das bereits mehrfach erfolgreich zertifiziert wurde. Hier schätzt der Autor das selbst Entwickeln als nahezu unmöglich für höhere Sicherheitsstandards ein.

Wird bei der Konzeption bereits die Unterstützung eines erfahrenen Inte¬grators zu Hilfe genommen, ist die Nutzung der SafeTlib ein zielsicherer Weg zur Sicherheit des Systems und der Zertifizierung, der zeitaufwändige Iterationen vermeidet.

Auswirkungsanalyse FMEDA

FMEDA steht für Failure Modes Effects and Diagnostic Analysis und ist ein Verfahren zur detaillierten Ermittlung von Fehlerursachen und deren Auswirkung auf das System. Sie kann bereits in frühen Phasen der Systementwicklung effizient eingesetzt werden, um Schwachstellen frühzeitig zu erkennen.

Sicherheitsstandards fordern, Fehler in einem sicherheitsrelevanten System zu vermeiden und bis auf eine zulässige Restfehlerwahrscheinlichkeit bzw. Restfehlerrate zu reduzieren. In Abhängigkeit von der gewählten Systemstruktur und des zu erreichenden Safety Integrity Level muss das Verhältnis der ungefährlichen Fehlerfälle (Safe Failure Fraction; SFF bzw. SPFM) berechnet werden. Hierfür kommt die FMEDA mit mathematischen Modellen und Berechnungsmethoden zum Einsatz, um die aus Ausfällen resultierenden Restfehlerwahrscheinlichkeiten bzw. Restfehlerraten abzuschätzen.