Designpraxis

Funktionale Sicherheit in der Praxis - Teil 3

4. Juli 2013, 11:37 Uhr | Dr. Kurt Böhringer und Markus Kroh
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Beispiel Drive-Applikation und Fazit

Beispiel Drive-Applikation

Die folgende Beispielrealisierung zeigt, wie die PRO-SIL-SafeTcore-Bibliothek für TriCore in eine Drive-Applikation, in der das EGAS-Überwachungskonzept eingesetzt wird, integriert werden kann.

Schema des EGAS-Konzepts
Bild 4. EGAS-Konzept-Übersicht.
© Elektronik

Das EGAS-Überwachungskonzept (Bild 4), auch das Drei-Ebenen-Konzept genannt, ist ein standardisiertes Überwachungskonzept für Motorsteuerungen und ist in der Automobil-Industrie weit verbreitet. Das EGAS-Konzept wird vom „Arbeitskreis EGAS“ herausgegeben und ist für den Einsatz in Otto- und Dieselmotoren vorgesehen. Es wird aber auch in leicht abgewandelter Form in anderen sicherheitskritischen Systemen in Fahrzeugen eingesetzt. Das EGAS-Konzept schreibt eine Drei-Ebenen-Architektur vor:

Ebene 1 stellt die Funktionsebene dar und beinhaltet die Motorsteuerungsfunktionen. Ebene 2 ist die Funktions-Überwachungsebene. Wie der Name schon sagt, überwacht diese Ebene die korrekte Ausführung der Funktionsebene (Ebene 1). Die Ebene 2 kann z.B. verifizieren, ob die tatsächliche Ist-Beschleunigung des Fahrzeugs die zulässige maximale Beschleunigung des Fahrzeugs überschreitet. Ebene 3 ist die MCU-Überwachungsebene. Diese soll prüfen, ob die MCU noch ordnungsgemäß funktioniert. Dabei wird auch ein unabhängiges Überwachungsmodul (ASIC, Watchdog) für die MCU gefordert.

Die Ebenen 1 und 2 sind applikationsspezifisch und können deshalb durch eine Bibliothek nicht abgedeckt werden. Ebene 3 beinhaltet dagegen meist nicht applikationsspezifische Anforderungen, die von dem PRO-SIL-SafeTcore-Paket abgedeckt werden. Ebene 3 ist in zwei unabhängige Module aufgeteilt: den Funktions-Controller in diesem Beispiel, den TriCore, und einen unabhängigen Überwachungsmonitor, den CIC61508-Watchdog von Infineon.

Um die Anforderungen der Ebene 3 an den Funktionskontroller, den TriCore, zu erfüllen, müssen nur die in der Bibliothek enthaltenen Startup- und zyklischen Tests aufgerufen werden. Wobei an dieser Stelle erwähnt werden muss, dass die PRO-SIL-SafeTcore-Bibliothek mehr Tests enthält, als im EGAS-Konzept gefordert werden. Weiterhin kann auf einige durch EGAS geforderte Tests aufgrund der Hardware-Eigenschaften des TriCore und der SafeTcore-Bibliothek verzichtet werden. So müssen die zyklischen RAM- und ROM-Tests nicht zwingend durchgeführt werden, da sowohl das RAM als auch der Flash-Speicher durch ECC-Logik geschützt werden. Zusätzlich wird die korrekte Funktionsweise der ECC-Logik in den Startup-Tests geprüft. Sollte es wegen applikationsspezifischer Anforderungen nicht ausreichend sein, die ECC-Logik nur beim Startup zu testen, können die entsprechenden Tests auch zyklisch zur Laufzeit ausgeführt werden.
Der unabhängige Überwachungsmonitor wird durch den CIC61508 umgesetzt. Dadurch, dass das Handling des CIC61508 komplett durch die PRO-SIL-Bibliothek übernommen wird, müssen bei einer Integration nur der Window-Watchdog entsprechend dem Diagnose-Testintervall und die Grenzwerte für die Spannungsüberwachung im CIC61508 eingestellt werden.

Der Einsatz einer fertigen Bibliothek darf natürlich die Echtzeitfähigkeit des Systems nicht beeinträchtigen. So sind bei Motorsteuerungen Abtastintervalle in einem Bereich von 50 µs bis 100 µs typisch, die nicht nur eine hohe Interrupt-Last verursachen, sondern auch strenge Anforderungen an den Jitter mit sich bringen. Dieser Jitter darf nur im Bereich von wenigen µs liegen. Gleichzeitig muss aber mit Hilfe der PRO-SIL-Bibliothek die Funktionsfähigkeit der MCU nachgewiesen werden. Da die Tests in die CPU und andere Peripherie eingreifen, kann eine testbedingte Interrupt-Sperre nicht vermieden werden. Um die Echtzeitfähigkeit des Systems zu erhalten, können die von PRO-SIL bereitgestellten Synchronisierungsfunktionen genutzt werden. Diese werden von SafeTcore jedes Mal aufgerufen, wenn die Interrupts gesperrt werden sollen, sie ermöglichen ein auf die kritischen Interrupts abgestimmtes Scheduling. Mit Hilfe dieser Synchronisierungsfunktionen kann z.B. ein niederpriorisierter Ebene-3-Task so verzögert werden, dass die hochpriorisierten Interrupts der Ebene 1 immer noch zu richtigen Zeitpunkten ausgeführt werden können.

Wie oft die zyklischen PRO-SIL-Tests ausgeführt werden, hängt von der Prozesssicherheitszeit ab. Das ist die Zeit, in der ein Fehler im System bestehen kann, bis dieser zur Verletzung des Sicherheitsziels führt. Diese Zeitspanne wird für jedes Sicherheitsziel festgelegt und kann in einer Drive-Applikation abhängig von den Anforderungen an das System in einem Bereich von ca. 12 ms liegen. Innerhalb dieser Zeit müssen die Fehler erkannt werden und das System muss in den sicheren Zustand gebracht werden. Diese kritische Zeitanforderungen kann mit der PRO-SIL-Bibliothek problemlos erfüllt werden, indem z.B. das Diagnose-Testintervall auf 6 ms eingestellt wird.

Des Weiteren muss berücksichtigt  werden, dass es sich bei der Ebene 1 meistens um Software handelt, die nur einen niedrigen ASIL oder auch nur ASIL-QM hat. Die Ebenen 2 und 3 hingegen beinhalten meistens Funktionen mit höheren ASIL. Damit Funktionen mit unterschiedlichen ASIL in einem System koexistieren können, muss die Rückwirkungsfreiheit zwischen den unterschiedlichen ASIL-Leveln nachgewiesen werden, d.h. es muss sichergestellt werden, dass die Ebene-1-Software, die evtl. nur ASIL-QM ist, die Ebene-2- und Ebene-3-Funktionen nicht beeinflussen kann. Die Rückwirkungsfreiheit wird zum einen durch ein entsprechendes Scheduling, zum anderen durch den Einsatz der Speicherschutzeinheit (MPU) erreicht.
Das PRO-SIL-SafeTcore-Paket bietet eine Möglichkeit, den Task-Verlauf zu überwachen. Mit dieser Funktion kann die geforderte Programflusskontrolle für die Ebene-2-Task umgesetzt werden. Dazu müssen nur die entsprechenden SafeTcore-Funktionsaufrufe jeweils zur Beginn und am Ende der Ebene-2-Task erfolgen. Die Überprüfung, ob die Ebene-2-Task immer ausgeführt wurde, findet dann anschließend in der Bibliothek auf der PCP-Seite statt. Der PCP-Teil der SafeTcore-Bibliothek wird mit der gleichen Frequenz wie die zyklischen Tests und der CIC61508 getriggert, nämlich mit dem Diagnose-Testintervall.

Die SafeTcore-Bibliothek hat die Möglichkeit, zwei redundant berechnete Ergebnisse miteinander zu vergleichen. Diese Schnittstelle kann dazu verwendet werden, um die Entscheidung, ob beim Überwachen der Funktionsebene durch die Ebene 2 ein Fehler entdeckt wurde, nicht nur durch den TriCore-Core fällen zu lassen, sondern zusätzlich durch eine zweite Instanz - den PCP-Core. Ebene 2 vergleicht dabei nicht nur die berechneten Ergebnisse mit den erwarteten, sondern übergibt diese anschließend durch eine definierte Schnittstelle auch an die SafeTcore-Applikation auf dem PCP-Core. Hier erfolgt ein zusätzlicher Vergleich. Entdeckt der PCP-Core beim Vergleich einen Fehler, wird zum einen der TriCore-Core benachrichtigt, zum anderen wird die Triggerung des CIC61508-Watchdog eingestellt und damit das System durch den CIC61508 in den sicheren Zustand gebracht, sofern dies noch nicht durch die Ebene 2 erfolgt ist.

Realisierung in der Gas-Detektor-Applikation

Verglichen mit der Drive-Applikation sind die Anforderungen an die Software in einem Gas-Detektor nicht so umfangreich. Es muss zwar auch eine Erfassung und Verarbeitung von Eingangsdaten sowie eine rechtzeitige Reaktion auf eine Änderung dieser erfolgen, die Menge an Funktionen, die in Software umgesetzt sind, und die Echtzeitanforderungen sind jedoch nicht mit einer Drive-Applikation zu vergleichen. Je nach Anwendungsgebiet kann die Prozesssicherheitszeit eines Gas-Detektors im Bereich von 100 ms bis einigen Minuten liegen. Da auch die entsprechenden Algorithmen zur Auswertung und evtl. Anzeige der Messdaten keine hohen Anforderungen an die Rechenleistung des Mikrocontrollers stellen, kann hier eine MCU mit geringer Taktrate wie z.B. ein XC2300 eingesetzt werden.

Da die meisten XC2300-Derivate mehr Rechenleistung haben, als in einem typischen Gas-Detektor benötigt wird, bietet es sich an, durch redundante Sensoren und diversitäre Programmierung die SIL-Anforderungen zu senken. Die Sensoren werden an unterschiedliche A/D-Wandler angeschlossen. Dabei benutzt das erste Software-Modul zur Erfassung der Daten den ersten A/D-Wandler und zur Verarbeitung die ALU. Das zweite Software-Modul verwendet den zweiten A/D-Wandler und die MAC-Einheit des XC2300. Anschließend werden die zwei redundant berechneten Ergebnisse sowohl im XC2300 selbst als auch durch den CIC61508-Watchdog miteinander verglichen. Bei einem Fehler wird das System entweder schon durch den XC2300 oder im schlimmsten Fall durch den CIC61508-Watchdog in den sicheren Zustand gebracht. Um sicherzustellen, dass die beiden diversitären Berechnungen nicht durch einen Fehler in der CPU ein gleich falsches Ergebnis liefern, wird zwischen den beiden Berechnungen der Instruktionstest (SBST) ausgeführt. Dieser stellt sicher, dass die CPU noch richtig funktioniert.

Wie in jedem System, gibt es auch bei den Gas-Detektoren sicherheitskritische und nicht sicherheitskritische Funktionen in der Software. Um nicht die komplette Software nach IEC61508-SIL2-Anforderungen zu entwickeln, empfiehlt sich wieder der Einsatz der MPU. Da SafeTcore für XC2300 für die Verwendung mit der MPU ausgelegt wurde, läuft die Integration auch mit Verwendung der MPU problemlos und zügig ab. Die größte Herausforderung dabei ist zumeist die Strukturierung des Speicher-Layouts der Applikation.

Die Startup-Tests verifizieren, ob die XC2300-MCU fehlerfrei funktioniert; deshalb müssen diese im System zuerst ausgeführt werden, d.h. bevor die Initialisierung der von der Gas-Detektor-Applikation benötigten Peripherien wie A/D-Wandler und Timer durchgeführt wird. Da das System bis zum Beenden der Startup-Tests im sicheren Zustand ist, wird so ein fehlerhaftes Verhalten von vornherein vermieden. Nach dem Beenden der Startup-Tests sind nicht nur die CPU und andere Peripherien getestet, sondern alle von SafeTcore benötigten Peripherien wie PLL, SPI und Timer initialisiert.

Die zyklischen Tests wie Peripherie-Konfigurations-Test, ECC-Logik-Test und SBST werden entweder in einem niederpriorisierten Task oder, wenn kein Betriebssystem eingesetzt wird, in zeitgetriggerten State Machines ausgeführt. Da die Prozesssicherheitszeit relativ groß ist, ist es ausreichend, wenn die zyklischen Tests z.B. alle 48 ms ausgeführt werden.

Fazit

Durch die weite Bandbreite der XC2300- und TriCore-Mikrocontroller bezüglich Preis, Rechenleistung, Speichergröße und Peripherie können mit dem SafeTcore-Konzept vielfältige Applikationen funktional sicher gestaltet werden. Ein weiterer Vorteil gegenüber anderen Angeboten ist auf jeden Fall die Praxisbewährtheit, da das Konzept bereits in einigen Produkten erfolgreich eingesetzt wurde, nicht nur im Automobilbereich, sondern auch in industriellen Applikationen.

Bei einer Machbarkeitsprüfung können Experten von Hitex unterstützen, was eine sichere Konzeptentscheidung erleichtern und beschleunigen kann. Auch bei der Integration oder gar Modifikation kann Unterstützung angeboten werden, was insbesondere für Anfänger bezüglich funktionaler Sicherheit eine große Hilfe sein kann.

 

Dipl.-Physiker
Dr. Kurt Böhringer
ist seit über 20 Jahren in der Embedded-Welt bei Hitex tätig. Als Head of Technology & Innovation ist er unter anderem mit dem Schwerpunkt-thema Funktionale Sicherheit beschäftigt.
kurt.boehringer@hitex.de

Markus Kroh
ist seit 12 Jahren bei der Infineon Technologies AG tätig. Als Marketing Manager ist er u.a. für den Bereich „Business Development Functional Safety“ verantwortlich.
markus.kroh@infineon.com


  1. Funktionale Sicherheit in der Praxis - Teil 3
  2. Beispiel Drive-Applikation und Fazit

Lesen Sie mehr zum Thema


Das könnte Sie auch interessieren

Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Hitex GmbH

Weitere Artikel zu Infineon DC GmbH

Weitere Artikel zu Infineon Technologies AG

Weitere Artikel zu INFINEON Technologies AG Neubiberg

Weitere Artikel zu Infineon Technologies AG Warstein

Weitere Artikel zu Infineon Technologies AG, B Fiber Optics

Weitere Artikel zu Sicherheitssteuerungen