Cause und Effect Charts in der Praxis Effiziente Applikationsentwicklung für funktionale Sicherheit

Die Entwicklung von Sicherheitsfunktionen gehört heute zum Alltag der Applikationsentwicklung in der Automatisierungstechnik. Genau wie bei nicht-sicherheitsgerichteten Funktionen herrscht Zeit- und Kostendruck. Dennoch sind die hohen normativen Anforderungen bei Sicherheitsfunktionen zu erfüllen. Cause und Effect Charts können dieses Dilemma lösen. Wir zeigen anhand eines Fallbeispiels, wie C&E Charts verwendet werden können.

Kostensparende Entwicklung ist in vielen Bereichen noch ein Wunschtraum. Besonders bei der Applikationsentwicklung im Bereich der funktionalen Sicherheit besteht noch ein großes Potenzial für Einsparungen. Die treibende Kraft bei der Verbesserung von Programmiersystemen in der Automatisierungstechnik ist also derzeit vor allem die Senkung der Engineeringkosten. Die strengen normativen Anforderungen aus der IEC61508 oder abgeleiteten Standards, die unter anderem an die Qualität des Entwicklungsprozesses gestellt werden um systematische Fehler zu vermeiden, legen einen relativ starren Rahmen fest. Wirksame Maßnahmen dazu sind z.B. die Reduktion der Ausdrucksmöglichkeiten von Programmiersprachen oder die automatische Generierung von Programmcode. Durch die Verwendung von Ursache-Wirkungs-Diagramme (Cause & Effect Charts kurz C&E Charts) für die Erstellung von Sicherheitsfunktionen können genau diese Maßnahmen umgesetzt werden. Mit C&E Charts lassen sich Sicherheitsfunktionen sehr übersichtlich spezifizieren. Durch die Verwendung einer formal definierten Syntax und Semantik können sie direkt in IEC61131-3 konformen Programmcode übersetzt werden. Die manuelle Tätigkeit der Implementierung entfällt und somit auch eine mögliche Fehlerquelle. Die Grundlage für den Sicherheitsnachweis bilden dann die Entwurfsspezifikation und die Testprotokolle. Der Analyseaufwand wird deutlich reduziert. Der Artikel gibt eine kurze Einführung in die Verwendung von C&E Charts im Kontext der Applikationsprogrammierung nach IEC 61131-3 für sicherheitsgerichtete Anwendungen. Entstehung eines C&E-Charts Sicherheitsfunktionen, die auf Applikationsebene umgesetzt werden, sind meist durch eine geringe Komplexität gekennzeichnet. Mittels Sensoren wird ein kritischer Maschinen- oder Anlagenzustand erfasst. Es genügen meist wenige Verknüpfungen um eine Reaktion zu berechnen. Durch Aktoren wird der sichere Zustand herbeigeführt. Solche Funktionen sind z.B. die Begrenzung des Drucks, der Temperatur oder das Verhindern kritischer Bewegungen. Die Komplexität auf der Anwendungsebene steigt mit der Größe der Anlagen und der damit verbundenen, steigenden Anzahl an Sicherheitsfunktionen. Aus diesem Grund wurden C&E Charts in der Prozessindustrie schon in der Vergangenheit als Spezifikationsmittel oder zum Sicherheitsnachweis genutzt. Da es aber bisher keine internationale Standardisierung für C&E Charts gibt, definiert jeder Anwender eine eigene Syntax und vor allem Semantik. Die Charts werden dabei meist manuell in SPS-Programme in Form von Funktionsplänen umgesetzt. Für die Generierung von SPS-Programmen aus C&E Charts ist also zuerst eine geeignete Syntax und Semantik zu definieren. Dabei sollen die Charts nicht mit Informationen überfrachtet, aber auch keine Informationen verborgen werden. Die Ausdrucksmöglichkeiten müssen also im Vergleich zu anderen IEC61131-3 Sprachen (wie z.B. ST) eingeschränkte werden. Um das Verständnis der C&E Charts für SPS-Programmierer intuitiv zu gestalten, werden Zeit- und Logikfunktionen aus dem IEC61131-3 Standard genutzt. Ein C&E Chart wird in eine POE umgesetzt, so dass auch die Abarbeitung der Charts der IEC61131 entspricht. Beispiel zur Erläuterung Zur Erläuterung soll folgendes Beispiel dienen: Die Risikoanalyse hat SIL3 für die Funktion Berstschutz ergeben. Ein Druckbehälter braucht einen Berstschutz durch die PLT-Schutzeinrichtung. In dem Druckbehälter findet eine exotherme Reaktion statt, die durch Zufluss von Stoff 1 gesteuert werden kann (siehe Abbildung 1). Wird die Zufuhr von Stoff 1 gestoppt, kommt die Reaktion zum erliegen. Der Stoff 3 ist toxisch und deshalb sicherheitsrelevant. Ein Austritt kann schwere gesundheitliche Schäden beim Bedienpersonal auslösen. Die Schutzeinrichtung wird daher zweikanalig ausgelegt. Die Überwachung soll aus einem Drucksensor (S2) und einem Temperatursensor (S1) bestehen. Da Druck und Temperatur proportional sind, kann so eine diversitäre Erfassung realisiert werden. Für die Unterbrechung der Stoffzufuhr werden die Ventile V1 und V2 vorgesehen. Der sichere Zustand ist erreicht, wenn die Zufuhr von Stoff 1 unterbrochen ist. Das Ventil V1 wird betrieblich genutzt und daher auch kontinuierlich überwacht. Das Ventil V2 ist nur für die Sicherheitsfunktion vorgesehen. Die Diagnose des Ventils V2 soll von der PLT-Schutzeinrichtung übernommen werden. Dazu soll der Operator das Ventil manuell über das Scada-System schließen und wieder öffnen, wenn es der Prozess erlaubt. Das Prüfintervall soll durch die PLT-Schutzeinrichtung überwacht werden. Dazu wird ein Kontakt am Ventil V2 (I0.1) zurückgelesen. Die Abbildung 2 zeigt den Entwurf der Sicherheitsfunktion als C&E Chart. Der Cause \’break_protection\‘ und der zugeordnete Effect \’stop_flow1\‘ stellen die Sicherheitsfunktion dar. Dem Cause \’break_protection\‘ sind die Eingangsvariablen \’R_T_I1\‘ (Temperatursensor S1) und \’R_P_I2\‘ (Drucksensor S2) zugeordnet. Durch die OR Verknüpfung reicht es aus, wenn einer der beiden Sensoren seinen Grenzwert erreicht, um den Cause zu aktivieren. Die Grenzwerte werden als Aktivierungsbedingung (AC) für Variablen vom Typ REAL definiert. In diesem Fall sind es obere Grenzwerte (HL) mit entsprechender Hysterese. Bei der Zuordnung von Causes zu Effects wird festgelegt, wie sich der Effect verhalten soll, wenn der Cause aktiviert oder deaktiviert wird. Ein N steht für nicht speichernd, d.h. wird der Cause de/aktiviert, so wird auch der Effect de/aktiviert. Für den Effect \’stop_flow1\‘ wurde die Zeitfunktion TP definiert. Der Effect bleibt dadurch nach der Aktivierung mindestens 5 Minuten aktiv. Ist der Cause \’break_protection\‘ danach nicht mehr aktiv, so wird auch der Effect \’stop_flow1\‘ deaktiviert. Ist ein Effect aktiv, so werden die zugehörigen Ausgangsvaribalen entsprechend ihrer Aktivierungsbedingung aktiviert. Die Ausgangsvariablen sind hier \’SB_Q0.1\‘ (Ventil 1) und \’SB_Q0.2\‘ (Ventil 2). Sie sind vom Typ SAFEBOOL. Für SAFEBOOL- und BOOL-Variablen sind die Aktivierungsbedingungen \’energize-to-trip\‘ (ETT) oder \’deenergize-to-trip\‘ (DTT) möglich. Im Beispiel sind beide Ventile stromlos geschlossen, d.h. ist der Effect \’stop_flow1\‘ aktiv, werden die Ventile stromlos geschaltet (DTT) und schließen dadurch. Die Causes \’V2_closed\‘ und \’operator_check\‘ sowie die Effects \’V2_check_intervall\‘ und \’V2_op_check\‘ dienen der Diagnose von Ventil V2. Der Cause \’V2_closed\‘ wird aktiv, wenn die Eingangsvariable SB_I0.1 aktiviert wird, d.h. das Ventil fährt zu und der Rücklesekontakt schließt (ETT). Dadurch wird der Zugeordnete Effect \’V2_check_intervall\‘ aktiviert (N) und die Ausgangsvariable \’SB_V2_check\‘ gesetzt. Die Aktivierung bleibt durch die Zeitfunktion TP eine definierte Zeit aktiv. Diese Zeit ist das Prüfintervall. Nach Ablauf des Prüfintervalls (36h) wird die Ausgangsvariable \’SB_V2_check\‘ zurückgesetzt. Da sie auch als Eingangsvariable für den Cause \’operator_check\‘ definiert ist, wird dieser Cause aktiv (Aktivierungskondition DTT). Dies führt zur gespeicherten Aktivierung (S) des zugeordneten Effects \’V2_op_check\‘. Gespeicherte Aktivierung bedeutet, auch wenn alle Causes eines Effects deaktivierte werden, bleibt der Effect aktiv bis das Rücksetzen (R) über einen anderen Cause erfolgt. Dem Effect \’V2_op_check\‘ ist die Ausgangsvariable \’SB_V2_op_check\‘ zugeordnet. Diese Variable ist mit einer Meldung im Scada-System verbunden. Sie lässt sich nur durch das Schließen des Ventils V2 quittieren (Eingangsvaraible SB_I0.1). Eine solche Verwendung von Ausgangsvariablen eines Effects als Eingangsvariablen eines Causes ist u.a. auch für die Spezifikation von Shut Down Sequenzen notwendig. Das Beispiel kann natürlich nicht die vollständige Syntaxdefinition darstellen, es verdeutlicht aber das Prinzip des Entwurfs von Sicherheitsfunktionen mittels C&E Charts. Wie stehen die C&E Charts zu den anderen Sprachen der IEC61131-3? Vielfach wird angenommen, C&E soll die bisher verwendeten Funktionspläne und die von der PLCopen definierten Funktionsbausteine ablösen. Das ist ein Missverständnis! Vielmehr setzen C&E Charts in einer früheren Entwicklungsphase der Sicherheitsapplikation ein. Ausgehend von der Risikoanalyse, werden Sicherheitsfuktionen und die darin definierten \’Causes\‘ direkt verwendet, um Abschaltfunktionen – die sog. \’Effects\‘ – auszulösen. Diese unmittelbare Nähe zu den Ergebnissen der FMEA oder anderer Methoden zur Fehleranalyse, ist der wesentliche Vorteil dieser bewährten Methode. Das ist prinzipiell nicht neu, sondern wird vor allem im Erdölgeschäft schon seit Jahrzehnten eingesetzt. Seine Wurzeln liegen im heißen Texas, wo in den Siebzigern des letzten Jahrhunderts nach einer einheitlichen Form gesucht wurde, Risiken bei der Exploration von Erdölfeldern adäquat darzustellen. Fazit C&E Charts eignen sich als zusätzliche Sprache für Sicherheitsfunktionen in IEC61131-3 Programmierumgebungen. Sie unterstützen die Vermeidung von Fehlern beim Entwurf. Außerdem tragen sie deutlich zur Aufwandsreduktion bei. Die wesentlichen Schnittstellen zwischen einem Editor für C&E Charts und einem Programmiersystem dienen dem Austausch von Variablen (Eingabe, Ausgabe und Merker), der Übergabe des generierten Programmcodes und der online-Visualisierung. Die online-Visualisierung kann z.B. durch farbige Darstellung aktiver Causes und Effects auf Basis eine OPC-Verbindung zum Target realisiert werden. Der C&E Editor von infoteam Software wurde mit Microsoft .NET 4.0 in C# implementiert. Er zeichnet sich durch eine intuitive Benutzerführung aus und nutzt moderne Elemente zur Oberflächengestaltung wie Windows Presentation Foundation (WPF) und bedienerfreundliche Ribbons. Der Bediener hat hierdurch einen maßgeblichen Vorteil: er ist in der Windows Anwendungsumgebung zu Hause und muss sich nicht umgewöhnen, sondern erfasst die Funktionalitäten im Handumdrehen. Der C&E Editor wird als Komponente angeboten, die sich einfach in jedes MS Windows-basierte Programmiersystem integrieren lässt.

infoteam Software AG
http://www.infoteam.de

Das könnte Sie auch Interessieren

Weitere Beiträge