Die meisten Sicherheitskonzepte für Leit- und Bedienstände konzen­trieren sich standardmäßig auf die Absicherung der automatisierten Steuerungen nach den SIL-Anforderungen (Safety Integrity Level). Eine Sicherheitslücke bleibt dabei häufig offen – die Anzeige der Prozesszustände. Denn auch bei weitgehend automatisierten Systemen haben Bedienhandlungen Auswirkungen auf die Sicherheit oder Gefährdung von Menschen, Material und Umwelt. Deswegen nehmen verschärfte gesetzliche Anforderungen an die Sicherheit von Maschinen und Anlagen wie das Geräte- und Produktsicherheitsgesetz (GPSG),

Maschinenverordnung (9. GPSGV) oder die Betriebssicherheitsverordnung (BetrSichV) Hersteller und Betreiber stärker in die Pflicht, für einen angemessen hohen Sicherheitsstandards zu sorgen. Beispielsweise schreiben sie vor, dass potenzielle, durch falsch angezeigte Daten verursachte Fehlbedienungen, auf die aber folgerichtig reagiert wurde, durch geeignete Gegen- beziehungsweise Absicherungsmaßnahmen ausgeschlossen oder soweit entschärft werden müssen, dass von ihnen keine Gefährdung mehr ausgeht.

Schließlich können verfälschte oder gar nicht angezeigte Prozessgrößen die Ursache für Unfälle sein. Sicherheit gibt es jedoch nur, wenn sichergestellt ist, dass die von der Steuerung und Visua­lisierung ausgegebenen Prozess­werte zuverlässig und korrekt auf den HMI-Geräten dargestellt werden. Die Herausforderung an die elektronische Sicherheitstechnik besteht nun darin, für alle relevanten Einsatzgebiete – das sind branchenübergreifend alle manuellen Bedienarbeitsplätze mit Sicherheitsrelevanz – den notwendigen Sicherheitsnachweis zu erbringen.

SIL-konforme PC – ein steiniger Weg

Funktionsprinzip der Anzeigenüberwachung: IconTrust nutzt das Black-Channel- Prinzip der sicherheitsgerichteten Feldbusse für die sicherheitsgerichtete Überwachung von PC-Hardware.

© Deuta

In der Theorie ist es einfach, PC-kompatible Anzeige- und Bediengeräte sicher zu machen. Praktisch sind dazu viele Maßnahmen notwendig, die strenge Qualitätsanforderungen an jede Software- und Hardware-Komponente stellen. Und nach jeder Modifikation, egal ob eine Bauteil-Abkündigung oder eine Software-Anpassung, ist der komplette Sicherheitsnachweis erneut zu belegen. Daher führt der notwendige Sicherheitsnachweis bislang meist zu proprietären und kostspieligen Speziallösungen – häufig verbunden mit dem Verlust der Vorteile einer PC-Architektur wie Flexibilität, einfache Wartbarkeit und geringe Kosten.

Im Bereich Bedienung und Beobachten kommen überwiegend TFT-Displays in Verbindung mit PC-Technologien zum Einsatz, da sie eine gute Skalierbarkeit mit minimalen Auswirkungen auf die Applikationssoftware ermöglichen. Sollen PC-Technologien auch in sicherheitsrelevanten Applikationen verwendet werden, ist eine vorherige systematische Sicherheitsanalyse der Architektur und deren Softwarekomponenten unerlässlich. Als Fehlerquellen erweisen sich:

• CPU (Hauptprozessor)

• Datenschnittstellen (Hardware und Software)

• Speicher

• Grafikcontroller

• TFT-Signaltreiber

• Betriebssystem

• Software-Bibliotheken

• Grafiktreiber und sonstige Treiberpakete

• Fehler in der Stromversorgung

• Fehlerhaftes TFT-Display

Eine FMEA (Failure Mode and Effects Analysis) offenbart potenziell sicherheitskritische, oft systematische Fehler. Bei einem Software-Verifika­tionstest sollte beispielsweise jede Programmzeile getestet werden. Unter anderem kann eine sicherheitsrelevante Information durch eine andere Infor­mationseinheit überdeckt werden.

Die Applikationssoftware nutzt für die Darstellung von Informationen innerhalb dafür bestimmter Bereiche auf dem Display einzelne „Software-Threats“. Sind Koordinaten dieser Bereiche fehlerhaft, kann die Überdeckung von Information an einem Softwarefehler, einem CPU-Fehler oder einem Speicherfehler liegen.

Standard-PC-Hardware: Ein Restrisiko bleibt

Grafikcontroller haben verschiedene Bildspeicher, einen Arbeitsbildspeicher, in dem im Hintergrund die Informationen für das nächste Bild aktualisiert werden, und einen Speicher für das gerade auf dem TFT-Display angezeigte Bild. Sind im Arbeitsbildspeicher die aktuellen Daten verarbeitet, schaltet der Grafikcontroller diesen Bildspeicher auf dem TFT-Display sichtbar und der andere Bildspeicher ist dann der Arbeitsbildspeicher. Eine Fehlfunktion des Grafikcontrollers kann dazu führen, dass der Wechsel zwischen den Bildspeichern fehlschlägt und somit alte – unter Umstände falsche – Informationen angezeigt werden. Wirken diese alten Daten für den Bediener schlüssig, hat er keine Möglichkeit, deren Korrektheit zu prüfen und reagiert eventuell falsch.

Ebenso können Grafikcontroller per Farbkalibrierung die Farbdarstellung der Displays anpassen. Eine Fehlfunktion der Kalibrierung könnte zum Verlust von Farbinformationen führen. Dieser Fehler kann bei Alarmen kritisch sein, lässt sich aber nicht durch die Prüfung des Bildspeichers erkennen. Zufällige Fehler, die im Betrieb aufgrund von Bauteil-Defekten auftreten können, müssen in sicherheitskritischen Anwendungen durch zyklisches Testen der Hardware erkannt werden. Aufgrund der Komplexität PC-basierter Anwendungen ist eine nachweisbare vollständige Testabdeckung allerdings kaum zu erreichen. Eine Überprüfung der Hardware-Architektur auf systematische oder zufällige potenzielle Fehler gibt noch mehr Anlass zu zweifeln, Standard-PC-Hardware könnte aufwendig, aber nicht vollständig SIL-konform geprüft und mit einem gewissen Restrisiko sicherheitsgerichtete Aufgaben übernehmen.

Dass eine PC-Hardware millionenfach verkauft wurde, heißt nicht, dass die Hardware keine systematischen Fehler hat. So genannte „Errata Sheets“ von Mikrocontrollern belegen das Gegenteil: Selbst Datenblätter einfacher Prozessoren führen dutzende Fehler auf; bei den Prozessoren der aktuellen x86-Baureihe sind rund einhundert „Bugs“ dokumentiert. Für die meisten Fehler gibt es „Workarounds“ im Bios oder sie werden von den Chipsätzen toleriert. Ein Gutachter wird sich jedoch mit den vagen Aussagen in den Datenblättern der Hardware- oder Bios-Hersteller zu möglichen Auswirkungen auf das sicherheitsrelevante System nicht zufrieden geben.

Als problematisch erweist sich daneben der „Microcode“, den Prozessorherstel­ler verwenden, unter anderem, um interne Fehler der CPUs zu beseitigen. Die Liste derartiger Unwägbarkeiten lässt sich beliebig fortsetzen. Deshalb ist es im Rahmen eines Projekts mit begrenzten Budget, Zeitplan und Personalressourcen nicht möglich, aus einem Standard-HMI mit PC-Architektur einen nachweislich sicheren Computer zu entwickeln, wie er nach SIL gefordert ist.