Suchen

Sicherheit durch Hardware FPGA, Safety und Security – 5 Punkte, auf die es ankommt

Autor / Redakteur: Thomas Mack * / Sebastian Gerstl

Um Sicherheits- und Security-Features in industriellen Anwendungen zu gewährleisten kommen immer häufiger FPGAs in entsprechenden Systemen zum Einsatz. Doch welcher Baustein ist für die angestrebte Applikation der Sinnvollste? Um das richtige FPGA zu wählen, sollten Entwickler zuvor fünf wesentliche Fragen beantworten.

Firma zum Thema

Bei der Entwicklung sicherheitsgerichteter industrieller Anwendungen (im Bild: SafeFlex Functional Safety Development Kit von NewTec) kommt es auf mehrere grundlegende Faktoren an, die die Auswahl eines geeigneten FPGA-Bausteins maßgeblich beeinflussen.
Bei der Entwicklung sicherheitsgerichteter industrieller Anwendungen (im Bild: SafeFlex Functional Safety Development Kit von NewTec) kommt es auf mehrere grundlegende Faktoren an, die die Auswahl eines geeigneten FPGA-Bausteins maßgeblich beeinflussen.
(Bild: NewTec)

In einer zunehmend automatisierten, vernetzten und autonomen Produktion ist die Sicherheit der computergesteuerten Prozesse von zentraler Bedeutung. Hardware-basierte Lösungen mit Hilfe von Field Programmable Gate Arrays (FPGA) haben sich als effiziente und kostensparende Variante für verschiedenste Umgebungen erwiesen. Die integrierten Schaltkreise bestehen aus tausenden konfigurierbaren Logikblöcken, die anwenderspezifisch angepasst und miteinander vernetzt werden. Wer eine FPGA-Sicherheitslösung erwägt, sollte einige Dinge beachten:

1. Welche Sicherheitsstufe soll das System erreichen?

Eingebettete Systeme sind heute aus den meisten Industriebranchen nicht mehr wegzudenken. Mit ihrem Vormarsch ist die Frage nach der funktionalen Sicherheit für Entwickler zentral geworden. Sie müssen dafür sorgen, dass ihre Systeme verlässlich funktionieren und Gefährdungen durch Fehler vermieden werden (Safety). Dann gibt es noch die Notwendigkeit, das System vor feindlichen Angriffen von außen zu schützen – zum Beispiel durch Viren, Würmer und andere Software-Schädlinge (Security).

Seien es Fließbänder in Industriebetrieben, der Einsatz von Software in Autos, Flugzeugen oder der Medizintechnik – überall müssen die Gefahren durch Fehlfunktionen oder Sicherheitslücken der Systeme analysiert werden. In den vergangenen Jahren sind verschiedene Normen verabschiedet worden, die Verfahren für die Entwicklung und den Betrieb elektrischer oder programmierbarer elektronischer Systeme festlegen.

Branchenübergreifender Grundstandard ist die DIN EN IEC 61508. Dazu kommen branchenspezifische Normen wie die ISO 13849 für den Maschinenbau oder die ISO 26262 für den Autobau. Abgeleitet aus der DIN EN IEC 61508 wird auch der Sicherheits-Integritätslevel (SIL), nach dem Hersteller die Sicherheit ihrer Systeme bewerten können. Gängig sind bei dieser Kritikalitätsnorm vier Stufen: Bis zu SIL 2 kann der Hersteller die Beurteilung seines Produkts entlang geltender Normen selber festlegen; ab SIL 3 muss er sich einem Zertifizierungsprozess unterziehen.

Nicht alle vernetzten Systeme bedürfen einer hohen Sicherheitsstufe: Es ist zum Beispiel nicht lebensgefährdend, wenn computergesteuerte Haltestellen-Ansagen in der U-Bahn nicht funktionieren. Wenn aber ein Roboter in einer Fertigungsstraße eng mit einem menschlichen Kollegen zusammenarbeitet, muss er im Fall einer Fehlfunktion schnell abschalten. Für solche Konstellationen empfiehlt sich auch bei der Auswahl FGPA-basierter Sicherheitslösungen, immer den Level SIL 3 anzustreben.

2. Müssen Sicherheits-/Safety-Funktionen schnell und parallel erfolgen?

In vielen Anlagen ist es entscheidend, dass die Sicherheit im laufenden Produktionsprozess ständig überwacht und schnell auf Fehlfunktionen reagiert wird. Arbeiten Mensch und Maschine auf engem Raum, muss diese unverzüglich abgeschaltet werden, wenn durch eine Fehlfunktion Leben oder Gesundheit von Menschen gefährdet sind.

In solchen Kontexten mit hoher Sicherheitsanforderung können auf FPGAs basierende Lösungen ihre Stärken voll ausspielen, denn sie können deutlich schneller reagieren als prozessorbasierte Systeme.

Eine CPU führt die eigentliche Kontrollaufgabe und die Diagnosemaßnahmen nacheinander aus, was sie bei komplexen Aufgaben an Performance-Grenzen stoßen lässt. Die Unterbrechung wirkt sich oft negativ auf die entscheidende Reaktionszeit aus.

Bei der FPGA hingegen lässt sich der kritische Signalpfad direkt in der Hardware abbilden, er wird parallel zur „normalen“ Funktionalität ausgeführt. Es sind keine zusätzlichen Prozessortakte für die Software nötig, die Reaktion auf Systemfehler oder -ausfälle kann schneller erfolgen.

3. Benötigt das System die Implementierung von „Soft-Core“-Prozessoren?

Wenn in einem Steuerungsprozess komplizierte Aufgaben zu erledigen sind, werden oft Soft Cores – also Software-Kerne – in das FPGA-Design integriert.

Kompliziertere Regelschritte, dazu gehört zum Beispiel das Ansteuern von Motoren oder Displays, lassen sich über diese als virtuelle Einheit auf einem FPGA integrierten Mikrokontroller oder Signalprozessoren effizienter durchführen. Soft Cores werden mitunter nachträglich auf FPGAs installiert, wenn etwa der Funktionsumfang erweitert werden muss, weil Aufgaben komplexer werden.

Soft-Core-Prozessoren können auch eine wichtige Rolle spielen, wenn es um die Gewährleistung von Systemsicherheit geht: Je nach angestrebtem Sicherheitslevel kann es sinnvoll sein, auf einem FPGA zwei Soft-Core-CPUs zu installieren.

Der Programmcode wird dann redundant in beiden CPUs ausgeführt. Durch einen Vergleich des Outputs pro Rechenzyklus können Fehler, Time-outs oder Endlosschleifen schnell entdeckt werden und das System gegebenenfalls in einen sicheren Zustand (safe state) zurückversetzt werden.

4. Welche Komplexität erreicht das System?

Die Komplexität eines Systems ist davon abhängig, wie viele – unterschiedliche – Elemente an einem Prozess beteiligt sind. Auch kommt es darauf an, welche Beziehungen und Wechselwirkungen zwischen ihnen bestehen und wie hoch der Grad der Vernetzung ist. Durch die Vernetzung sind industrielle Automatisierungsprozesse flexibler und effizienter geworden – aber auch komplexer. An sicherheitssensiblen Produktionsschritten sind heutzutage die verschiedensten Komponenten beteiligt: Roboter, Sensoren, Lichtschranken, Ein- und Ausgabe-Slots, programmierbare Steuerungen.

Wie eine FPGA-basierte Sicherheitslösung gestaltet wird, hängt entscheidend von der Komplexität des Systems ab, das kontrolliert werden soll. Wenn beispielsweise verschiedene sicherheitsrelevante Sensoren wie Lichtschranken oder Notschalter zu beobachten sind und zeitgleich der Arbeitsbereich eines Roboters kontrolliert werden soll, müssen die Diagnosedaten abgeglichen werden. Dies wird möglich durch spezielle Sicherheitsroutinen, die über Feldbus-Protokolle wie zum Beispiel Powerlink laufen.

Je nach dem potenziellen Risiko, das etwa von einem Industrieroboter ausgeht, benötigen solche Anwendungen das Sicherheitslevel SIL 2 oder 3. Um das besonders hohe SIL 3 zu erreichen, ist es nur mit großem Diagnoseaufwand möglich, einkanalig zu arbeiten, also mit einem FPGA. Bei einer einkanaligen Lösung wird ein SFF (Safe Failure Fraction) von 99 Prozent verlangt. Der SFF-Faktor repräsentiert den Anteil der sicheren (nicht gefährlichen) und erkannten Ausfälle an der Gesamtzahl möglicher Ausfälle. Meist wird eine sogenannte „One-out-of-two-Architektur“ (1oo2) realisiert, bei der zwei unabhängige Mikrokontroller sämtliche sicherheitsrelevanten Schritte redundant ausführen.

Eine Alternative ist die sogenannte Lockstep-Architektur mit zwei auf einem FPGA integrierten Soft-Cores, zum Beispiel vom Typ Nios II, die den Programmcode redundant ausführen. Fällt eine CPU aus, kann der Fehler immer noch von der anderen entdeckt werden.

5. Sind relevante Dokumentationsunterlagen für das FPGA verfügbar?

Diese Frage gilt es vor der Entscheidung für eine FPGA-Lösung in jedem Fall zu prüfen. Denn eine ausführliche Dokumentation der Sicherheitsvorkehrungen ist zentral für alle, die einen zertifizierten Sicherheitslevel anstreben. Dies gilt besonders, wenn in einem Produktionsprozess Änderungen anstehen und Sicherheitsroutinen auf dem FPGA ergänzt oder neu entworfen werden müssen.

Änderungen an der Gestaltung der funktionalen Sicherheit könnten in einem aufwändigen Prozess von Dokumentation und Rezertifizierung resultieren. Je ausführlicher das bestehende System dokumentiert ist, desto einfacher wird die Entscheidung, ob eine erneute Zertifizierung überhaupt nötig ist. Zudem können Änderungen gezielter vorgenommen werden.

Altera (nun bekannt als Intel Programmable Solutions Group) bietet dafür beispielsweise ein „Functional Safety Data Package“ an, das einen Safety-Design-Prozess, IP-Cores und Entwicklungswerkzeuge, die einem SIL 3 entsprechen, umfasst.

Manche Anbieter, wie zum Beispiel Altera, trennen in ihren FPGA-Lösungen den für funktionale Sicherheit zuständigen Bereich vom Rest. Diese können, wenn ein automatisierter Prozess geändert werden muss, separat angepasst werden, ohne die Safety-Partition anzufassen. Auf eine kostspielige vollständige Neu-Zertifizierung kann so verzichtet werden, und auch bei der Entwicklung kann gespart werden. Altera nennt dieses Paket „Safety Separation Design Flow“, es kommt nach Angaben des Unternehmens bei Anwendungen in der Industrie, der Autobranche, bei medizinischen, militärischen und Luftfahrt-Systemen zum Einsatz.

* Thomas Mack ist Senior Safety Consultant und Produktmanager SafeFlex bei der Firma NewTec.

(ID:44110068)