Safety-Prozessoren in
Automatisierungs-
anwendungen
Entwickler von Sicherheitsanwendungen für die Automatisierung sind, wenn es um die Auswahl geeigneter Prozessoren geht, seit ein paar Jahren mit einem stetig wachsenden Angebot von Safety-Prozessoren konfrontiert. Dieser Artikel will auf ein paar grundsätzliche Fragen in diesem Zusammenhang ein paar Antworten versuchen: Muss ich in meiner Safety-Anwendung einen Safety-Prozessor einsetzen? Was habe ich davon? Welche Fragen und Kriterien muss ich bei der Auswahl berücksichtigen?
Bisher war die Vorgehensweise beim Einsatz von Mikroprozessoren in Safety-Anwendungen ziemlich klar: es wurden ein oder mehrere Prozessoren ausgewählt, die die benötigten Features (Performance, Funktionen, ggf. Speicherplatz) bereitstellten. Zu Beherrschung von prozessorinternen Fehlern wurden Selbsttests gemäß der anzuwendenden Sicherheitsnorm (z.B. ISO13849 oder IEC61508) implementiert. Und für die Berechnung von Ausfallwahrscheinlichkeiten (PFD/PFH bzw. MTTFd) wurde der vom Hersteller angegebene FIT-Wert verwendet. Nachfragen bei verschiedenen Prüfstellen haben gezeigt, dass sich in absehbarer Zukunft an dieser Praxis nichts ändern wird: zumindest mittelfristig werden die kontaktierten Stellen auch in Zukunft die Verwendung von Standardprozessoren in Safety-Applikationen nach dem oben beschriebenen Verfahren akzeptieren. Die Forderung, nur noch Safety-Prozessoren einzusetzen, besteht nicht – so sehr sich das der ein oder andere Hersteller vielleicht auch wünschen würde.
Eine typische SafetyKomponente
Um den Einsatz von Safety-Prozessoren genauer zu betrachten, stellen wir uns eine typische Safety-Komponente vor (s. Abb. 1 (a)): die Komponente hat eine Feldbusschnittstelle, über die (auch) ein sicheres Protokoll kommuniziert wird und verschiedene (sichere) Ein- und Ausgänge. In der Komponente wird eine sichere Anwendung ausgeführt – das kann ein SPS-Programm sein oder auch nur die Vorverarbeitung der Ein- und Ausgänge. Evtl. gibt es zusätzlich auch noch eine nicht-sichere Anwendung. Abbildung 1 (b) zeigt die herkömmliche Realisierung: ein Standardprozessor übernimmt die Feldbuskommunikation und ggf. die nicht-sichere Anwendung, zwei weitere redundante Standard-Prozessoren realisieren zweikanalig die sichere Anwendung und steuern die sicheren Ein-/Ausgänge. Abbildung 1 (c) schließlich zeigt das Versprechen der Anbieter von Safety-Prozessoren: ein Prozessor vereinigt alle Funktionalitäten in sich, die vorher auf drei Prozessoren verteilt waren. Dieses Versprechen soll nun näher untersucht werden. Dabei soll unterschieden werden zwischen:
- • Prozessoren mit Sicherheitsarchitektur und
- • Prozessoren mit in Soft- oder Hardware bereitgestellter (Selbst-)Diagnose
Prozessoren mit Sicherheitsarchitektur
Die typische Sicherheitsarchitektur von Safety-Prozessoren weist zwei Kerne auf, die beide dieselbe Software ausführen, wobei ein Vergleicher überprüft, dass bei Kerne wirklich exakt identisch arbeiten (‚Lockstep-Mode‘).
- • Sicherheitsanwendung:
Bei der Sicherheitsanwendung, d.h. allen allein in Software realisierten Berechnungen und Verarbeitungen zeigt sich der entscheidende Vorteil dieser Prozessoren: der Entwickler muss nur eine Software entwickeln und braucht sich nicht um die Synchronisierung und Kommunikation zwischen zwei Prozessoren zu kümmern. In der Regel sind in diesen Prozessoren außerdem Speichersicherungsmechanismen implementiert (ECC oder CRC-Check), sodass auch diese nicht in Software realisiert werden müssen. Vorsicht ist allerdings geboten, wenn neben der sicheren auch nicht-sichere Anwendungen oder die nicht-sichere Feldbuskommunikation im selben Prozessor ausgeführt werden: dann muss die Rückwirkungsfreiheit der nicht-sicheren Software garantiert werden. Und selbst wenn ein sicheres Betriebssystem zusammen mit einer MMU die Trennung sicherstellt, so bedeutet der häufige Wechsel zwischen sicherem und nicht-sicherem Kontext doch in der Regel erhebliche Performance-Einbußen. Zu beachten ist auch, ob die Architektur die spezifischen normativen Anforderungen erfüllt. Sofern kein Prüfbericht entsprechend dieser Anforderungen vom Hersteller vorliegt, sollte diese Frage auf jeden Fall im Vorfeld mit der jeweiligen Prüfstelle geklärt werden. Besondere Vorsicht ist geboten, wenn für Maschinenanwendungen auch die ISO13849 erfüllt werden soll, da die meisten Hersteller, wenn überhaupt, nur eine Prüfung nach IEC 61508 vorweisen können: die Kategorien 3 und 4 fordern vollständige Einfehlersicherheit und mindestens die Betrachtung von Zweitfehlern. Letzteres bedeutet insbesondere, dass der Vergleicher zwischen den beiden Kanälen zyklisch geprüft werden muss, was häufig nur bei Power-Up möglich ist.
- • Ein-/Ausgänge:
Ein großes Problem stellen bei Safety-Prozessoren zweikanalige Ein-/Ausgänge dar. Die IEC61508-2 fordert bei on-chip Redundanz die Berücksichtigung umfangreicher Anforderungen an das Chip-Design, wenn die Unabhängigkeit beider Kanäle gewährleistet werden soll. Wenn der Hersteller das nicht nachweisen kann, so wird für zweikanalige Ein/-Ausgänge in der Regel zumindest für Kategorie 3/4 und SIL 3 ein weiterer Prozessor oder mindestens ein Port-Expander erforderlich. Auch in diesem Punkt gilt es, die vom Hersteller bereitgestellte Dokumentation genau zu untersuchen und diese Frage im Vorfeld mit der Prüfstelle abzustimmen.
