Eckdaten

Dieser Artikel soll beispielhaft am für Safety entwickelten Mikrocontroller Aurix als auch an den Model-basierten Entwicklungswerkzeugen Rhapsody und Matlab aufzeigen, was deren Vorteile sind.

Obwohl es für verschiedene Branchen sehr unterschiedliche Safety-Standards gibt, sind doch alle in den Grundanforderungen gleich. Es müssen Fehler vermieden oder erkannt werden, die zu einem Schaden führen können. Hier werden zwei Arten von Fehlern unterschieden, systematische Fehler und statistische Fehler. Für beide Arten gibt es unterschiedliche Vermeidungsstrategien, da die Fehler in verschiedenen Zeiten des Produktlebenszyklus auftreten können.

Bild 1: Hardware Maßnahmen des AURIX zur Erkennung von statistischen Fehlern.

Bild 1: Hardware Maßnahmen des AURIX zur Erkennung von statistischen Fehlern. Hitex

Systematische Fehler entstehen zum Beispiel durch falsche oder ungenügende Anforderungsdefinition (Requirements), falsche Spezifikation oder fehlerhafte Umsetzung (Implementierung). Solche Fehler können durch einen entsprechenden Entwicklungsprozess und ausgiebige Verifikation und Validierung (beispielsweise V-Modell) verringert werden. So ist vorgeschrieben, dass beginnend von den Anforderungen (funktionale und auch Safety-Anforderungen) eine Architektur definiert wird, die dann in Hard- und Software aufgeteilt wird. Weiter geht es dann mit dem Herunterbrechen in Module, die anschließend in Detailed-Design-Spezifikationen festgelegt werden. Jeder Schritt wird ausgiebig dokumentiert und durch Reviews im 4-Augen-Prinzip kontrolliert. Teilweise sind sogar „Walk-through-Meetings“ in Gruppen vorgeschrieben. Ausgehend von den Spezifikationen und Requirements werden die Validierungsschritte definiert, beginnend bei Unit-Tests über Integrationstests bis hin zu Systemtests. Die Dokumentation ist so weitgehend, dass nachvollziehbar sein muss, welche Spezifikationen und Requirements mit welchen Tests abgedeckt werden.

Statistische Fehler entstehen zur Laufzeit durch Störungen wie Höhenstrahlung, Umgebungsstörungen oder auch auftretende Fehler oder Defekte in Bauteilen der Hardware. Hier ist eine Fehleranalyse vorgeschrieben (FMEA oder FMEDA). Führt die Fehleranalyse zu einer Fehlerrate, die höher liegt, als die als „sicher“ akzeptierte (was üblicherweise der Fall ist), dann müssen Maßnahmen ergriffen werden um solche gefährlichen Fehler zu erkennen und das System in einen sicheren Zustand schalten, bevor es zum Schaden kommen kann. „Sichere“ Fehlerraten sind zum Beispiel weniger als 10-7 Fehler pro Stunde für SIL3 oder eine minimale mittlere Zeit bis zum Fehler (MTTF) von 300 Jahren.

Erkennung statistischer Fehler

Um solche statistischen Fehler zu erkennen gibt es Hardwaremaßnahmen oder Software-Tests. Es ist wichtig, die Fehler zu erkennen, bevor ein Schaden eintritt. Diese Zykluszeit ist von der Applikation abhängig und bestimmt die Zeit, in der alle nötigen Tests erfolgreich durchgeführt worden sein müssen. Üblicherweise werden solche Tests beim Hochlaufen des Systems (POST) und zur Laufzeit (BIST) durchgeführt. In manchen Systemen sind solche Tests auch beim Abschalten vorgesehen.

Modellbasiertes Entwickeln und Aurix

In Zusammenarbeit von Willert Software Tools und Hitex entstand eine Anbindung vom Modell-basierten Entwicklungstool Rhapsody an den für Safety geschaffenen Mikrocontroller Aurix. Anhand dieser Anbindung sollen die Vorteile zur Vermeidung und Erkennung von systematischen und statistischen Fehlern erläutert werden.

Am Ende dieses Artikels wird noch kurz auf die Anbindung von Matlab an Aurix eingegangen.

Erkennen und vermeiden von statistischen Fehlern mit Aurix

Es gibt nur wenige Mikrocontroller, die beim Design und der Entwicklung bereits auf funktionale Sicherheit ausgelegt sind. Ein solcher ist der Aurix, eine 32-bit-Mikrocontrollerfamilie von Infineon.

Voraussetzung, dass der Mikrocontroller in sicherheitskritischen Systemen eigesetzt werden kann ist natürlich, dass er zur Vermeidung von systematischen Fehlern nach einem Sicherheitsprozess entwickelt wurde. Diese Dokumentation des Entwicklungsprozesses ist vorhanden und für Nutzer im „Safety Case“ zur Vorlage bei den Zertifizierern zusammengefasst.

Der größte Vorteil des Aurix für funktionale Sicherheit sind aber seine eingebauten Sicherheitsmaßnahmen. Bild 1 zeigt die wichtigsten Maßnahmen. Zur Absicherung der CPU ist eine weitere CPU vorhanden, die den gleichen Code durchführt aber 2 Clocks versetzt. Die Ergebnisse dieser CPU werden mit den Ergebnissen der ausführenden CPU verglichen und somit werden Fehler in der Ausführung erkannt (Lockstep).

Um den möglichen äußeren Einwirkungen bestmöglich entgegenzuwirken, werden die gleichen Berechnungen um zwei Takte versetzt in einer räumlich getrennten und mit invertierter Logik ausgestatteten CPU ausgeführt. Durch diesen Ansatz werden zwei unterschiedlich entwickelte CPUs verwendet, was systematischen Fehlern entgegenwirkt. So lassen sich Common-Cause-Fehler vermeiden. Die Speicher sind mit ECC (DEDSEC bei SRAM beziehungsweise TEDDEC bei Flash) gesichert, dies gilt auch für die Bussysteme. Sämtliche in solchen HW-Maßnahmen gefundenen Fehler werden an eine Safety-Management-Unit (SMU) gemeldet. Diese kann konfiguriert werden, um selektiv für die einzelnen Fehler unterschiedliche Reaktionen auszulösen und so entsprechend auf den Fehler zu reagieren und das Gesamtsystem in einen sicheren Zustand zu versetzen.

Die Peripherals sind redundant ausgeführt oder haben Monitoring-Funktionalitäten, damit analoge und digitale Inputs und Outputs kontrolliert werden können.

Zu dem Sicherheitskonzept gehört noch ein externer Watchdog (TLF35584), der nicht nur die nötigen Spannungen für den Aurix erzeugt, sondern diese auch überwacht. Ebenfalls kann dieser als Functional und Windowed Watchdog fungieren, der vom Aurix in definierten Zeitfenstern Signaturen aus den durchgeführten Tests oder auch aus der Applikation bekommt und diese auf Richtigkeit und richtige Zeitfolge prüft um somit ein Fehlerverhalten des Aurix zu erkennen. Wird ein solches Fehlverhalten erkannt, ist auch der Watchdog in der Lage, das System in einen sicheren Zustand zu schalten. Hierfür kann dieser den AURIX mittels eines Power On Resets (Porst) neu starten und gleichzeitig über Safe-State-Ausgangspins eine externe Schaltung zum Auslösen des Safe-States ansteuern.

Zusätzlich gibt es noch die SafeTlib, eine Software-Bibliothek (auch nach Safety-Standard entwickelt), die die Hardwaremaßnahmen richtig konfiguriert, testet und zusätzliche Tests in SW ausführt. Als Dokumentation bekommt der Anwender das Safety Manual des Aurix und des TLF35584 Watchdogs, sowie das User Manual der SafeTlib. Damit kann er einem Zertifizierer nachweisen, dass er die nötigen geforderten Maßnahmen aus den Safety Manuals (Assumptions of Use) richtig durchgeführt hat und somit die Sicherheit des Mikrocontroller-Teils leicht zertifiziert bekommt.

Thema der nächsten Seite: Vermeidung von systematischen Fehlern mit Rhapsody

Seite 1 von 3123