Ein Angebot von

Zertifizierung: Ein Ansatz für ein modernes funktionales Sicherheitskonzept

| Autor / Redakteur: Peter Hoogenboom * / Franz Graser

Funktionale Sicherheit: Für die Betriebssicherheit gibt es zahllose Normen und Richtlinien. Die Zertifizierung von Softwareprodukten nach diesen Normen ist in der Regel ein aufwendiger Prozess.
Funktionale Sicherheit: Für die Betriebssicherheit gibt es zahllose Normen und Richtlinien. Die Zertifizierung von Softwareprodukten nach diesen Normen ist in der Regel ein aufwendiger Prozess. (Bild: Green Hills Software)

Firmen zum Thema

Kann ein nicht-zertifizierter SoC in einer Sicherheitsanwendung zum Einsatz kommen? Der Beitrag deckt wichtige Architektur- und Design-Abwägungen moderner Sicherheitseinrichtungen ab.

Sicherheit wird definiert als die Gewissheit, vor inakzeptablen Risiken wie Körperverletzung oder Gesundheitsbeeinträchtigungen entweder direkt oder indirekt infolge von Sach- oder Umweltschäden geschützt zu sein [1]. Funktionale Sicherheit ist Teil der Gesamtsicherheit, die von einem System abhängig ist, das eine Sicherheitsfunktion als Reaktion auf seine Eingaben ausführt. Beispiele für Sicherheitssysteme und die entsprechenden Sicherheitsfunktionen in der Automobilelektronik sind eine Warnanzeige auf einem Grafikdisplay eines Instrumenten-Clusters und ein Fahrerassistenzsystem (ADAS).

Funktionale Sicherheit basiert auf zwei Säulen: Fehlervermeidung und Fehlerkontrolle.

Die Fehlervermeidung handhabt systematische Fehler, die durch Fehler verursacht werden, die vor der Systeminstallation entstehen. Diese werden durch Standards abgedeckt, indem ein Off-Target-Entwicklungsprozess spezifiziert wird. Das entsprechende Zertifikat ist der Nachweis, dass das Sicherheitselement für den Einsatz geeignet und frei von systematischen Fehlern ist. Dies ist jedoch nur die eine Seite der Medaille.

Die Fehlerkontrolle ist die andere Seite und muss sich sowohl mit systematischen Hardwarefehlern (Hard-Errors, defekter Hardware) als auch mit zufälligen Hardwarefehlern (Soft-Errors, z.B. temporäre Bit-Wechsel aufgrund von Strahlung) befassen. Beide werden durch Fehler verursacht, die nach der Systeminstallation entstehen und von der Hardware und Software im Zielsystem (Target) adressiert werden müssen. Die Standards beschreiben Diagnostik und Techniken, die angewendet werden sollen.

Die Tabelle 1 (siehe unten) listet eine Reihe von Techniken auf, einschließlich der entsprechenden Diagnose-Abdeckung: Niedrig (60 Prozent), Mittel (90 Prozent) oder Hoch (>= 99 Prozent). Je höher die erforderliche Sicherheitsintegritätsstufe (SIL, Safety Integrity Level; ASIL für ISO26262), desto strenger ist der Entwicklungsprozess (Fehlervermeidung) und die Diagnoseabdeckung (Fehlerkontrolle) durchzuführen bzw. anzuwenden.

Trends bei Geräten, Einrichtungen und Systemen

Software wird immer mehr zum Unterscheidungsmerkmal eines Produkts. Sie ist oft weniger teuer als Hardware, erlaubt es, mehr Funktionen in einer flexibleren und skalierbaren Weise hinzuzufügen und ist oft die erste sichtbare Benutzerschnittstelle.

Im Automotive-Bereich zeigt sich noch ein weiterer Trend: Konsolidierung. In einer Super-ECU werden eine Reihe kleiner ECUs (elek-tronische Steuergeräte) zusammengefasst. Der (sicherheitskritische) Instrumenten-Cluster wird mit dem (nicht-sicherheitsbezogenen) Infotainment-System kombiniert. Beide Trends erfordern leistungsfähige, moderne Multicore-SoCs (System-on-Chip).

Tabelle 1: Beispiel-Techniken/Methoden/Tests für eine höhere diagnostische Abdeckung [1] [2]
Tabelle 1: Beispiel-Techniken/Methoden/Tests für eine höhere diagnostische Abdeckung [1] [2] (Bild: Green Hills Software)

In der Vergangenheit konnte nur das komplette System bzw. Gerät zertifiziert werden. Mit den aktuellen Sicherheitsnormen [1], [2] und [3] ist es möglich, eine Komponente wie eine CPU (Hardware) oder ein Echtzeit-Betriebssystem (RTOS, Software) zu zertifizieren. Die ISO 26262 nennt dies ein Safety Element out of Context (SEooC). Der Entwickler der Sicherheitseinrichtung kann sich auf den Bewertungsbericht der gekauften Komponente beziehen und nachweisen, dass das Sicherheitshandbuch des SEooC erfüllt ist.

Die IEC 61508 schreibt Störungsfreiheit in Bezug auf die „Unabhängigkeit der Ausführung“ zwischen Software-Elementen vor, die auf einem einzigen Computersystem gehostet sind. Der Begriff „Unabhängigkeit der Ausführung“ bedeutet, dass Elemente das Ausführungsverhalten anderer Elemente nicht nachteilig beeinflussen, so dass ein potenziell gefährliches Versagen auftreten würde. Die Unabhängigkeit der Ausführung soll sowohl auf räumlicher als auch zeitlicher Ebene erreicht und nachgewiesen werden. All dies kann durch einen zertifizierten Separationskernel erreicht werden, wie etwa das INTEGRITY RTOS von Green Hills Software.

Die Vorteile dieser Trennung sind vielfältig: nicht-kritische und kritische Software-Partitionen können nebeneinander auf dem gleichen System laufen. Damit erübrigt sich die erneute Zertifizierung des Systems/Geräts, wenn nicht-kritische Partitionen aktualisiert werden. Zusätzlich können standardmäßige (nicht zertifizierte) Kommunikations-Stacks (TCP/IP, CAN) aus nicht-kritischen Partitionen betrieben und Daten über einen „grauen Kanal“ an eine Sicherheitsanwendung in einer kritischen Partition übergeben werden. Letztere führt alle erforderlichen Sicherheitsüberprüfungen des verwendeten Sicherheitsprotokolls durch (End-to-End-Schutz vom Sensor bis zum Computer). Damit muss weniger Software zertifiziert werden, was die Entwicklungskosten erheblich verringert, ohne das erforderliche Sicherheitsniveau zu beeinträchtigen.

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.

Im Gleichschritt: Software Lock-Step

Eine zertifizierte Sicherheitsebene, die für den Betrieb auf einem Multicore-SoC geeignet ist, kann die Sicherheitsalgorithmen parallel auf mehreren Cores ausführen. Dabei werden die Zwischenergebnisse automatisch überprüft, wenn ein Core seinen Synchronisationspunkt erreicht hat. Dieser Ablauf wird Software Lock-Step genannt und ist eine äußerst leistungsfähige (High Coverage) Technik zum Erkennen von Soft-Errors (Zeile 11). Die Compiler-Technologie kann dabei helfen, verschiedene (A/B) Anweisungen für denselben zertifizierten Sicherheitsalgorithmus zu generieren, der in Software Lock-Step ausgeführt wird. Dadurch verringert sich das Risiko möglicher systematischer Hardwarefehler im Core.

Reguläre homogene Multicore-CPUs werden durch das RTOS (Scheduling) ebenfalls als Multicore behandelt, wobei mehrere Tasks gleichzeitig auf verschiedenen Cores ausgeführt werden (symmetrisches Multiprocessing, SMP). Bezüglich der Störfreiheit zwischen kritischen und nicht-kritischen Software-Partitionen muss eine neue Dimension berücksichtigt werden: die Cores. Sie teilen sich Ressourcen wie Crossbars, Cache und Speicher, könnten sich also gegenseitig stören. Das heißt, die zertifizierte Software (Separationskernel, Sicherheitsebene) muss die Störfreiheit der Cores garantieren und trotzdem Soft-Errors mit hoher Diagnoseabdeckung (mittels Software Lock-Step) erkennen.

Einsatz nicht-zertifzierter SoCs in einem Sicherheitssystem

Bei der Entwicklung eines Sicherheitssystems auf Basis störfreier Software-Partitionen ist ein zertifizierter Separationskernel erforderlich. Kommt zusätzlich noch eine zertifizierte Sicherheitsebene zum Einsatz, die alle erforderlichen diagnostischen Abdecktechniken unterstützt, kann ein moderner, nicht-zertifizierter Multicore-SoC verwendet werden.

Literaturhinweise:

[1] IEC 61508:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems, Parts 1-7[2] EN 50128:2011, Railway Applications - Communications, Signalling and Processing Systems - Software for Railway Control and Protection Systems[3] ISO 26262:2011, Road Vehicles – Functional Safety, Part 1-10[4] Renesas’ RH850-Familie[5] Infineons AURIX-Familie[6] Cortex-A57 – https://en.wikipedia.org/wiki/Comparison_of_ARMv8-A_cores[7] Intels Denverton-Familie

* Peter Hoogenboom ist als EMEA Engineering Manager bei Green Hills Software mit Sitz in den Niederlanden tätig.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44453390 / Safety & Security)