Ein Ansatz für ein modernes funktionales Sicherheitskonzept

Anbieter zum Thema

VEGA Grieshaber KG

Glatt Ingenieurtechnik GmbH

eschbach

Green Hills Software Ltd

Halbleitertrends und zunehmende Soft-Errors

In den 1980er Jahren waren CPU-Kerne relativ einfach aufgebaut. Die höchste Wahrscheinlichkeit eines Soft-Errors lag im externen Speicher. Moderne SoCs verfügen über erheblich mehr Logik auf ihrem Chip: n-stufige Pipeline, intelligente Crossbars, Caches, TLBs für die MMU etc. Dies erhöht das Risiko eines Soft-Errors in der komplexen Logik, der nur schwer zu erkennen und zu korrigieren ist. Durch die höhere Dichte der Prozessknoten (<65 nm [1]), niedrigere Spannungen (<1,8 V [1]) und höhere Taktraten nimmt die Wahrscheinlichkeit von Soft-Errors weiter zu.

Für die Anwendung von Halbleiterbausteinen in Sicherheitsanwendungen zeigen sich drei Trends: 1) spezielle sicherheitszertifizierte CPUs (Hardware Lock-Step-Technologie); 2) reguläre, nicht-zertifizierte Multicore-SoCs und 3) eine Mischung aus 1 und 2.

Zertifizierte Hardware: Lock-Step MCU

Bei der Hardware-Lock-Step-Technik re-pliziert spezielles Silizium die Cores (und optional andere Komponenten wie die MMU und den Interrupt-Controller). Dabei synchronisiert die Hardware die nachgebildeten Komponenten ständig und überprüft deren Übereinstimmung. Diese Art von MCUs [4] [5] stimmt häufig auch mit den oben genannten Bedingungen wie 65-nm-Technologie, mindestens 1,8 V und einer maximalen Taktfrequenz von einigen hundert MHz und ASIL-D-Einhaltung überein. Aus Sicht der Software (RTOS Scheduling) ist diese Art von MCU dann mit einem einzigen Core ausgestattet.

Nicht-zertifizierter Highend-SoC

Am anderen Ende des Spektrums steht z.B. ein Cortex-A57 [6] in 14- bis 28-nm-Technologie zur Verfügung. Er bietet eine 15-stufige Pipeline, eine Out-of-Order-Ausführung, eine zweistufige Branch-Prediction und wird mit einer Taktfrequenz von >1 GHz betrieben. Wir wissen, dass Soft-Errors auftreten werden. Entscheidend ist: Kann diese Art komplexer, nicht-zertifizierter SoCs [6] [7] in Sicherheitssystemen eingesetzt werden? Die Antwort lautet: ja, solange der Baustein die in den Standards festgelegten Fehlerkontrollmaßnahmen anwendet.

In der Praxis bedeutet dies eine begrenzte Menge an zusätzlicher Hardware und eine beträchtliche Menge an zusätzlicher Sicherheitssoftware, um diese Techniken zu implementieren. Da diese Sicherheitsebene frei von systematischen Fehlern sein sollte, muss sie bezüglich des erforderlichen (A)SIL-Standards zertifiziert bzw. bewertet werden.

Für ASIL C und D ist eine hohe diagnostische Abdeckung erforderlich. Betrachtet man die nachstehende Tabelle, stellt man fest, dass der traditionelle „Hardwaretest“-Ansatz nur eine mittlere diagnostische Abdeckung aufweist. Ein RAM-Test (Zeile 13) ist auf die Erkennung defekter RAM-Zellen beschränkt, erkennt aber keine Soft-Errors. Das Gleiche gilt für den Selbsttest der Hardware und Software (Zeile 9, 10). Aufgrund der Komplexität der heutigen SoCs ist sogar eine geringe diagnostische Abdeckung zu erwarten.

Eine zertifizierte Sicherheitsebene, die eine hohe diagnostische Abdeckung wie Zeitüberwachung, Terminüberwachung, Sequenzanzeige (Zeile 3), sichere Speicherung (Zeilen 4.1, 5), unveränderlicher RAM-Schutz, MMU-Seitentabellenprüfung (Zeile 4.2), sichere Interprozess-Kommunikation (Zeile 6.6) bietet, ist für den Entwickler, der mit der Sicherheit betraut ist, besonders hilfreich.

Auf der Treiberebene muss das Safety Board Support Package die Sicherheitsintegritätsfunktionen auf unterer Ebene und den Konfigurationsregistertest (Zeile 12) implementieren.

(ID:44535354)