Funktionale Sicherheit Hardware oder Software? - Was ist sicherer?

Funktionssicherheit eines leistungsstarken System mit spezifischen Einheiten, die man kennen muss.
Die Abschottung kritischer Funktionseinheiten ist das A und O um funktionale Sicherheit zu erreichen.

Um funktionale Sicherheit bei Elektronik zu garantieren, dürfen sich die Funktionseinheiten eines Systems nicht gegenseitig beeinflussen. Das kann man mit Hardware oder Software erreichen. Jede Methode hat ihre spezifischen Eigenheiten, die man kennen sollte.

Leistungsstarke Systeme, die in kritischen Anwendungen zum Einsatz kommen, enthalten meist Multicore-Prozessoren, die mit mehreren Kernen ausgestattet sind. Um Aufgaben mit minimaler Latenz zu verarbeiten, wird in der Regel ein Echtzeit-Betriebssystem (RTOS) verwendet. Bei der Wahl eines solchen Betriebssystems ist jedoch zu berücksichtigen, ob es auch funktionale Sicherheit unterstützt. Hinzu kommt die generelle Forderung nach funktionaler Sicherheit für die Hardware und Software des Hochleistungssystems.

Eine der Voraussetzungen für die Software, die auf einer bestimmten Hardware-Plattform läuft, liegt darin, dass die Hardware selbst ihre Funktion erfüllt und den Code korrekt ausführt. Während des Betriebs können im System jedoch Störungen auftreten, die möglicherweise auf dessen Umgebung oder Alterung zurückzuführen sind. Folglich muss das System selbst die zufällig auftretenden Hardwarefehler behandeln, was eine Sicherheitsarchitektur erforderlich macht. In der Regel findet sich in Hochleistungssystemen Hardware, die nicht mit Hardware-Fehlertoleranz oder Selbstdiagnosefunktionen ausgestattet ist. Eine typische 1oo1D-Systemarchitektur (one out of one diagnostics) ließe sich also verwenden, die eine separate Diagnoseabdeckung zur Fehlererkennung hinzufügt (Bild 1).

Diagnosen ermöglichen die Umwandlung eines erkannten gefährlichen Ereignisses in einen »sicheren Fehler«, um das Vertrauen in das System und die zugrunde liegende Hardware zu erhöhen. Damit erhöht sich wiederum das Sicherheitsintegritätsniveau des Systems. Dies ist eine wichtige und komplexe Maßnahme, und das Verständnis des Sicherheitskontexts ist nicht gerade einfach. Der Vorgang muss bei der Entwicklungsdauer berücksichtigt werden, da Sicherheit von Anfang an mit entworfen werden muss.

Sicherheit durch Trennung

Es sind also korrigierende Maßnahmen erforderlich, um die Anforderungen hinsichtlich der Robustheit zu bedienen. Die Standards rund um die funktionale Sicherheit erlauben eine Trennung der Funktionalität in verschiedene Elemente. Jedes Element kann dann auf einer unterschiedlichen Kritikalitätsstufe behandelt werden, solange das Trennungsverfahren Störungsfreiheit garantiert. Diagnosekanäle lassen sich ebenfalls trennen, um die Sicherheitsarchitektur zu vereinfachen. Die einfachste Trennung wäre die Einteilung in verschiedene Hardwarekomponenten, wie z. B. mehrere CPUs, oder die Aufteilung der Funktionalität zwischen hetero¬genen CPU-Cores, wie in modernen SoCs (System-on-Chip-Bausteine).

Die Aufteilung der Funktionalität zwischen homogenen Cores eines Multicore-SoC reicht nicht aus, da keine ausreichende Trennung erreicht wird. Zum Beispiel teilen sich solche Bausteine den Cache-Speicher, den Speicherbus und andere chipinterne Schalt¬kreise. Diese Systeme müssen die Trennung und Funktionalität in Software verwalten. Eine solche Trennung kann mit einem Separationskernel oder einem Hypervisor erfolgen.

Getrennte CPUs

Kommen separate CPUs in leistungsstarken Systemen zum Einsatz, werden diese häufig in Hochleistungs-CPUs, möglicherweise mit einer GPU, und getrennten Mikrocontrollern (MCUs) mit niedrigerer Taktrate unterteilt, die dann die Sicherheitsanforderungen überwachen und sicherstellen.

Obwohl die physikalische Trennung aus Sicht des Sicherheitsstandards gut ist, muss dennoch der Kommunikationspfad berücksichtigt werden. Komplexe Busse wie Ethernet und PCI erfordern eventuell, dass der Gerätetreiber auch den formellen Prozess der Zertifizierung nach funktionaler Sicherheit durchläuft – sofern in diesem Pfad ein Störeinfluss auftritt. Und selbst wenn der Treiber auf Sicherheits-MCUs läuft, die eine Memory Protection Unit zum Speicherschutz verwenden, ist dies keine einfache Aufgabe. Dies ist einer der Gründe, warum in Sicherheitslösungen eher einfachere Busse verwendet werden, da sich damit einfacher beweisen lässt, dass sie korrekt arbeiten. Ein Beispiel für die Hardware-Trennung ist in Bild 2 beschrieben.

Im Vergleich zu den komplexeren aber schnelleren Bussen können diese einfacheren Busse jedoch mit einer Leistungseinbuße einhergehen. Wenn das System viele Daten zwischen verschiedenen Einheiten transportieren muss, d. h. zwischen den Sicherheits- und Performance-Domänen, kann der Bus hinsichtlich der Leistungsfähigkeit als auch bei der Sicherheits-MCU zu einem Engpass werden, da nicht genügend Daten zwischen den Domänen ausgetauscht werden können. Hinzu kommt, dass sich bei dieser Architektur die Algorithmen nicht skalieren lassen. Soll ein leistungsintensiver Algorithmus in der Sicherheitsdomäne ausgeführt werden, gibt es eine Grenze bei der Ausführungsfunktion, die kleinere MCUs bewältigen können.
Die kleinere MCU kann sehr wohl ein RTOS ausführen, um einige der oben genannten Einschränkungen zu beseitigen – aber der wesentliche Nachteil beim Ablauf von Sicherheitsalgorithmen auf einer MCU mit niedriger Leistungsfähigkeit besteht weiterhin. Darüber hinaus muss die Performance-CPU möglicherweise auch ein RTOS ausführen, das nicht unbedingt sicherheitskritisch ist, aber dennoch in der Lage ist, die Echtzeit-Anforderungen für die Systemvorhersagbarkeit zu erfüllen.