Safety-Ziele leichter erreichen

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. 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

Bild 2: Erreichung der Tracebility ausgehend von den Requirements durch ReqXChange. Hitex

Aus Safety-Sicht bietet die Modellierung mehrere Vorteile, die folgend kurz aufgezeigt werden.

Aus Sicht der Normen ist ein elementarer Schritt der Entwurf und die Dokumentation der Software-Architektur und des Designs. Dieses kann sehr gut mithilfe der UML geschehen. Die Anwendung der UML auf Basis eines Modells mit einem Modellierungswerkzeug hat den Vorteil, dass das Design an sich bereits weitestgehend die Dokumentation darstellt (Single source of truth).

Auf Modellebene ist es möglich verschiedene Aspekte der Architektur bereits in frühen Phasen durch die Modellsimulation zu verifizieren. Einige Aspekte können auf Modellebene mit deutlich weniger Aufwand als auch Codeebene verifiziert werden.

Auf Basis von Codegenerierung können Modellaspekte automatisch in Code transformiert werden. Das hat den Vorteil, dass die definierte, dokumentierte und in Teilaspekten verifizierte Architektur auch kongruent im Code repräsentiert wird und abgesichert ist.

Die Normen fordern auch die sogenannte Traceability zwischen den Anforderungen, Systemspezifikation und dem Design. In der Regel kann die Systemspezifikation (zum Beispiel auf Basis des ReqIF-Standards) in das Modell importiert werden. Dort ist es sehr einfach möglich per Drag’n Drop mit der Maus oder alternativ in sehr übersichtlichen Matrizen Darstellungen die Spezifikationsartefakte mit den Designartefakten zu verlinken. Auf Basis dieser Linkbeziehungen lässt sich dann automatisch die geforderten Traceability darstellen.

Auch hier ist es möglich auf Basis der Codegenerierung die Tracebility der Anforderungen bis in den Code auszuprägen. Die Auswirkungen von Anforderungsänderungen lassen sich auf diese Weise über „Suspect Links“ bis in den Code nachvollziehen.

Die Modellierung bietet darüber noch weitere Vorteile, die helfen den Aufwand für Zertifizierungen zu reduzieren, was an dieser Stelle nicht weiter ausgeführt werden kann.

Thema der nächsten Seite: Vermeidung von systematischen Fehlern mit Matlab/Simulink & Stateflow

Bild 3: Algorithmen Erstellung, Simulation, Build und Flash Prozess für Aurix Shield Buddy direkt aus Matlab/Simulink heraus. Hitex

Ähnlich wie bei der Modellierung und Code-Generierung mit Rhapsody hilft der Einsatz von Matlab/Simulink und dessen Erweiterung Stateflow gerade bei komplexen Berechnungs- oder Regelalgorithmen beziehungsweise bei der Erzeugung, Simulation und Code-Generierung von Statemachines. So kann direkt zu Beginn der Entwicklung bereits die notwendige Rechenperformance des Embedded-Mikrocontrollers abgeschätzt werden und ob ein Single- oder ein Multicore-Mikrocontroller notwendig ist. Mittels des Simulationsmodells können Fehler untersucht werden, die beispielsweise durch eine begrenzte Genauigkeit bei Fließkommaberechnungen in Filtern oder Regelungsalgorithmen hervorgerufen werden. Je nach Safety-Integrity-Level des jeweiligen Standards ist eine Simulation auch vorab gefordert.

Hitex hat für Matlab/Simulink ein Simulink-Blockset für Aurix entwickelt. Ohne sich um Startup oder die Wechselwirkung der verschiedenen Aurix-internen Module zu kümmern, ist es hiermit möglich, sehr schnell ein Aurix-Mikrocontroller-Board (Shield Buddy mit TC275 und drei verwendbaren Cores mit bis zu 200 MHz) in Betrieb zu nehmen. Direkt aus Matlab Simulink heraus können alle notwendigen Einstellungen für das Aurix-Entwicklungsboard Shield Buddy sehr einfach getätigt werden. Gleichzeitig ist es möglich, das Simulationsmodell direkt auf dem Aurix auszuführen. Es stehen für die Interaktion mit der äußeren Beschaltung des Shield Buddys verschiedene Hitex-Simulink-Blöcke zur Verfügung, zum Beispiel für das Einlesen von analogen oder digitalen Spannungspegeln an den Pin-Eingängen mittels mehrerer 12 Bit ADCs beziehungsweise GPIOs. Darüber hinaus gibt es vorgefertigte und konfigurierbare Blöcke für die Ausgabe mittels GPIOs sowie mittels der USB-Verbindung, die direkte serielle („UART“) Kommunikation zwischen Aurix und einem Hyperterminal.

Damit ist es möglich, nicht nur den Algorithmus, sondern bereits zu einem frühen Entwicklungsstadium das komplette System, bestehend aus Sensoren, Aurix, Algorithmen und Aktoren zu untersuchen und zu optimieren.