Designpraxis

Funktionale Sicherheit in der Praxis – Teil 2

29. Mai 2013, 15:07 Uhr | Von Kurt Böhringer und Markus Kroh
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Sicherheit als Systemanforderung

Nun muss aber darauf hingewiesen werden, dass der Mikrocontroller zur Verhinderung von sogenannten Common-Cause-Fehlern (Mehrfachfehler mit gemeinsamer Ursache) die Entscheidung, ob ein Test, ein Vergleich von Ergebnissen oder eine Programmlaufzeit in Ordnung ist, selten selbst treffen darf. Hierfür wird ein weiterer Baustein im System benötigt, der Safety-Watchdog.

Einsatz des CIC61508 als Safety-Monitor.
Bild 2. Einsatz des CIC61508 als Safety-Monitor.
© Infineon Technologies

Diesen gibt es in unterschiedlichen Ausführungen. Viele Systeme haben einfache Window-Watchdogs integriert, die z.B. den sicherheitskritischen Pfad deaktivieren oder einen Reset durchführen, sollten sie nicht in gewissen Zeitperioden bedient werden. Für einen Mikrocontroller wie den XC2300 wird ein intelligenteres System mit sicherer Kommunikation benötigt. Dies kann durch einen weiteren Mikrocontroller erfolgen oder einen speziell entwickelten Baustein. Hier wird von Infineon der CIC61508-Companion-IC angeboten. Dieser ist auf die XC2300-Familie und die Safety-Core-Software abgestimmt. Er übernimmt Monitoraufgaben, Vergleiche von redundanten Rechnungen und Fehlermanagement (Bild 2).

Er dient als unabhängige Entscheider-Instanz und bietet dem Nutzer weiterhin eine Konfigurierbarkeit durch einen eigenen programmierbaren Flash-Speicher, welche Funktionen benötigt werden und wie auf unerwartete Ereignisse reagiert werden soll.

Nicht zuletzt braucht der Integrator noch die passende Dokumentation. Diese umfasst ein Safety Manual, wie die Safety-Funktionalität von Software, Hardware und Watchdog im System integriert werden muss und welche FIT-Raten (Failure In Time) zu erwarten sind. Da diese Dokumentation im Gesamtsystem betrachtet und interpretiert werden muss, bietet es sich an, dies als Dienstleistung mit anzubieten. Für die XC2300-Familie wird daher die Safety-Dokumentation über ein Partnerunternehmen zur Verfügung gestellt, die Firma Hitex. Diese kann Integratoren ein Gesamtpaket zur Verfügung stellen. Damit stellt Infineon ein umfassendes Paket zur Verfügung, um die bereits im breiten Einsatz befindlichen XC2300-Produkte für bestehende Systeme und für neue Entwicklungen auf die harschen Anforderungen der IEC 61508 und der ISO 26262 abzustimmen.

Die drei TriCore-Kerne sind über eine Schaltmatrix verbunden, die mit der hohen CPU-Geschwindigkeit arbeitet und Zugriffskonflikte in der Hardware verhindert
Bild 3. Die drei TriCore-Kerne sind über eine Schaltmatrix verbunden, die mit der hohen CPU-Geschwindigkeit arbeitet und Zugriffskonflikte in der Hardware verhindert.
© Infineon Technologies

Neue Multicore-Microcontroller

Das gleiche PRO-SIL-Konzept existiert auch für die 32-bit-TriCore-Familie. Hier möchten wir aber auf die Zukunft eingehen. Infineon hat dafür eine neue Familie von Multicore-Microcontrollern auf Basis der TriCore-Architektur definiert, mit denen sich die steigenden Anforderungen an Rechenleistung, Speicherkapazität und Sicherheit erfüllen lassen (Bild 3). Die neue Familie heißt Aurix und ist die Folgegeneration der sehr erfolgreichen Familien Audo und Audo Max. Die Aurix-Familie wurde von Grund auf neu und nach einem ISO-26262-konformen Prozess entwickelt, um die anspruchsvollsten Leistungsmerkmale auf die energieeffizienteste und leistungsstärkste Art und Weise bereitzustellen.

Der TriCore-Prozessorkern wurde verbessert und erweitert. Es existieren nun zwei Derivate: ein superskalarer Core, der mit 300 MHz getaktet wird, sowie ein skalarer Core mit 200 MHz und besonders niedriger Leistungsaufnahme, der nur wenig Fläche beansprucht und eine sehr effiziente Lösung für Applikationen im mittlerem Leistungsbereich darstellt. Die beiden TriCore-Derivate gibt es als Lockstep-Versionen, mit denen eine hervorragende Fehlererkennung und eine schnelle Reaktionszeit in ASIL-D-Sicherheitssystemen gewährleistet werden. Die Skalierbarkeit in Hinblick auf Rechenleistung, Speicherkapazität und Gehäuse innerhalb der Aurix-Familie ermöglicht einen gemeinsamen Sicherheitsansatz für die verschiedenen Bausteine. Damit ist es möglich, eine einzige Applikation auf einem kleineren Baustein, aber auch mehrere Applikationen parallel auf einem größeren Baustein zu implementieren, ohne dass die Software-Architektur oder die Sicherheitsstrategien modifiziert werden müssen. Das ist vor allem deshalb möglich, weil in jedem Peripherie-Block ein einzigartiger Mechanismus integriert wurde, wodurch jeder interne Bus-Slave nur Zugriffe von definierten Quellen akzeptiert.

Dieser Mechanismus, Register-Access-Protection genannt, macht es möglich, dass der Zugriff (und damit eine mögliche Beschädigung) von jeder CPU, DMA oder einem anderen Bus-Master auf jede intern geteilte Ressource (SRAM, Peripherien, I/O) permanent blockiert oder eben erlaubt werden kann. Damit können Entwickler jede mögliche Kombination zwischen Peripherie/Speicher und CPU/DMA festlegen. Viele der Peripherie-Elemente wurden außerdem dupliziert, wodurch jede Applikation ihre eigenen privaten Ressourcen hat und damit von vornherein Interferenzen verhindert werden, vollkommen unabhängig vom Speicherschutz oder anderen Kapselungsmechanismen.

Signifikante Einsparungen

Die Einsparungen, die bei der Entwicklung der Software für die Domänen-Controller und bei der Analyse erreicht werden können, sind signifikant. Denn jetzt können Systeme mit unterschiedlichen Sicherheitsanforderungen einfach realisiert werden: Auf dem einen Core läuft ein Betriebssystem für eine SIL3-Applikation, auf dem anderen läuft parallel ein anderes Betriebssystem ohne Speicher- oder Timing-Schutz.

Es ist trotzdem ausgeschlossen, dass die nicht sicherheitsrelevante Applikation die sicherheitsrelevanten Aktivitäten auf dem Mikrocontroller stört. Wenn mehrere Safety-Applikationen implementiert werden sollen, dann kann der Aurix auch mehrere OS-Applikationen hosten und das kooperative Modell vollständig unterstützen. Dieser Anwendungsfall wird durch das neue Temporal-Protection-System unterstützt. Dieses überwacht die Zeitbudgets für die einzelnen Tasks und die Interrupt-Rate auf den CPU-Cores. Damit kann man komplexe sicherheitsrelevante Applikationen realisieren, denn jede Interaktion zwischen den Cores kann Hardware-mäßig überwacht und über vordefinierte Grenzen beschränkt werden.

Der Hardware-seitige Zwang einer Kapselung ist ein wichtiger Sicherheitsaspekt, wenn Überwachungsfunktionen in bestehende Systeme inte-griert und Interferenzen direkt ausgeschlossen werden können. Zusammengenommen sind diese Mechanismen der erste Ansatz für eine Paravirtualisierung. Da heute virtuelle Maschinen auf Mikrocontrollern nicht realisierbar sind, stellen sie einen pragmatischen Schritt in Richtung vollständiger Virtualisierung und Hypervisor dar.

Die Mikrocontroller-Familie bietet eine skalierbare Lösung, mit der die höchsten Ansprüche an Rechenleistung erfüllt werden und gleichzeitig auch viele Sicherheitsfunktionen in Hardware realisiert sind. Die Möglichkeit, mehrere Applikationen von unterschiedlichen Anbietern und mit unterschiedlichen Sicherheitsanforderungen auf einen Controller zu bringen, öffnet die Tür für neue Domänen-Controller-Architekturen.

 

Die Autoren:

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 Schwerpunktthema 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 2
  2. Sicherheit als Systemanforderung

Lesen Sie mehr zum Thema


Das könnte Sie auch interessieren

Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Hitex GmbH

Weitere Artikel zu Automatisierung