Sicherheitsfunktion nur bei bestimmten Prozesschritten aktiv

R

redtraxx

Level-1
Beiträge
3
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,

bei einer Kundenanlage wurde durch den Versicherer eine HAZOP durchgeführt und Maßnahmen zur Erhöhung der Sicherheit vorgeschlagen.

Darin sind unter anderem Maßnahmen mit SIL2 gefordert, wie z.B. Abschaltung Pumpe bei zu hohem Druck, das ist alles kein Problem.

Schwierig wird es hier ...
Die Sicherheitsfunktion soll nur aktiv sein und ggf. auslösen bei bestimmten Prozessschritten des Programmablaufs.
Also wenn z.B. ein Rezepturablauf in der Standard-SPS im Schritt 5 ist, soll diese Funktion des Prozess absichern. Sonst nicht, da bei anderen Prozessschritten der Druck erwünscht ist und die Pumpe auch.

Kann man solche Kombinationen machen? Gefühlt zerhaut es mir da jedwede Nachrechnung im Sistema.

Hattet ihr sowas schon mal?
Wie kann man das umsetzen?

Danke!
Gruß VG
 
redtraxx schrieb:
Hattet ihr sowas schon mal?
Wie kann man das umsetzen?
Zum Vergrößern anklicken....
Kommt stark auf dein Gesamtkonzept an.
Je nach verfügbarer Hardware/Sensorik könnte man über eine Muting-artige Umsetzung nachdenken.

Einen kleinen Zustandsautomaten für die Drucküberwachung innerhalb eines F-Programms der SPS zu erstellen könnte auch eine Variante sein.
Dieser könnte dann z.B. per Handshake mit dem "normalen" Prozess + evtl. notwendige/sinnvolle Plausibilisierung der Handshake-Anforderung über F-Sensoren die verschiedenen Zustände der Drucküberwachung durchschalten.
Hab sowas ähnliches für Atmosphärenwechsel von Härteöfen im Einsatz.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Sowas hatten wir vor etlichen Jahren an einer Bestandsanlage.
Damals haben wir zusammen mit TÜV Süd ein Sicherheitskonzept ausgearbeitet und zusammen umgesetzt.
Nach der gemeinsamen Validierung gab es dann ein Protokoll mit Stempel und Unterschrift.
Die Umsetzung war so ähnlich wie es @Botimperator beschrieben hat.
Handshake zwischen F-Steuerung und normaler SPS und alle möglichen Plausibilätsprüfungen von beteiligten E/A-Signalen.
Die Zustände und Übergänge wurden als Petri-Netz dokumentiert. An Hand dessen dann die Software erstellt und die Validierung durchgeführt.
 
Danke für die Infos!
Petri-Netz sieht fürchterlich aus 😄

Wenn man solche Sachen vorhat, also Sicherheitsfunktionen die an einem Prozess oder Ablauf hängen muss man dann das gesamte Programm im F-Teil schreiben?
Ich kann mich erinnern das wir mal eine Inertisierungsschrittkette komplett im F-Teil gemacht haben. Das waren aber 10 Schritte oder so mit einem sicheren Zustand am Ende.

Das halte ich aber doch nur für eine gewisse Größe bzw. Umfang für machbar und sinnhaft.
Wenn man ein kompliziertes Auftrags/Rezeptur-Monster hat, bliebe wohl nur das mit der Statusmaschine.

Aber auch da habe ich ja immer einen Transfer aus unsicher in sicher. Da sagt mein Gefühl mir auch, das wenn mein Status per Definition im F-Teil ist, sich aber aus unsicheren Signalen/Merkern/DB und anderem Gedöns zusammensetzt ist das eher ein grün gefärbter Zustand.
Am Ende müsste man dann mit einem irgendwie "geprüften und getesteten Ablauf" in den abgenommenen Zustand segnen denke ich.

Danke jedenfalls!
Gruß
VG
 
redtraxx schrieb:
Wenn man solche Sachen vorhat, also Sicherheitsfunktionen die an einem Prozess oder Ablauf hängen muss man dann das gesamte Programm im F-Teil schreiben?
Zum Vergrößern anklicken....
Nicht zwingend das komplette Programm.
Dir würde es, bezogen auf dein Beispiel, ausreichen sicher zwischen Hoch- und Niederdruckbetrieb hin und her zu schalten.
(also ab welchem Druck deine Sicherheitsfunktion auslöst und einen sicheren Zustand erzwingt)

Der funktionale Teil (Regelungen, Schrittketten, usw) kann weiter im normalen Programm bleiben.

redtraxx schrieb:
Aber auch da habe ich ja immer einen Transfer aus unsicher in sicher. Da sagt mein Gefühl mir auch, das wenn mein Status per Definition im F-Teil ist, sich aber aus unsicheren Signalen/Merkern/DB und anderem Gedöns zusammensetzt ist das eher ein grün gefärbter Zustand.
Zum Vergrößern anklicken....
Deswegen der Vorschlag die Anforderung für den Zustandswechsel der Sifu mit sicheren (dem SIL/PLr der Funktion entsprechenden) Signalen zu plausibilisieren, beispielsweise mit einer Grundstellung.

Du kannst aber auch durchaus über einen bestimmten Ablauf der Signale aus dem Standard Programm eine sichere Umschaltung realisieren, so wie es beispielsweise die sichere Quitierfunktion macht.

Final muss das aber der Projektierer des F-Programms parallel zum Entwurf der Sifu entscheiden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
redtraxx schrieb:
Darin sind unter anderem Maßnahmen mit SIL2 gefordert, wie z.B. Abschaltung Pumpe bei zu hohem Druck, das ist alles kein Problem.

Schwierig wird es hier ...
Die Sicherheitsfunktion soll nur aktiv sein und ggf. auslösen bei bestimmten Prozessschritten des Programmablaufs.
Also wenn z.B. ein Rezepturablauf in der Standard-SPS im Schritt 5 ist, soll diese Funktion des Prozess absichern. Sonst nicht, da bei anderen Prozessschritten der Druck erwünscht ist und die Pumpe auch.
Zum Vergrößern anklicken....
hmm, also wie soll man sich das konkret vorstellen?

Welche Gefahr besteht bei zu hohem Druck? Und warum besteht diese konkrete Gefahr bei bestimmten anderen Prozessschritten NICHT?

Grundsätzlich gehts ja bei Safety IN DER REGEL erstmal um Personenschäden (z.B. wenn das Rohr platzen könnte und jemand daneben steht) Um Anlagenschäden oder Prozessprobleme unter bestimmten Umständen zu verhindern, muss es vielleicht DAFÜR nicht SIL2 sein?

Am Ende muss jemand der sich damit auskennt konkret über die Safetyfunktionen nachdenken. In der Prozessautomatisierung ist das in der Regeln auch nochmal komplizierter als mit der Maschinenrichtline im Maschinenbau... Kommt dann auch noch auf die Branche drauf an.

Bei Siemens gibts ne Schulung für Safety in der Prozessautomatisierung (mit PCS7) Soll ganz gut sein, hab ich aber auch noch nicht besucht.

Wenn die Sicherheitsfunktion in bestimmten Situationen nicht gewünscht ist, weil die Anlage in diesen Situationen anderweitig geschützt ist, müsste man diesen anderweitigen Schutz in SIL2 "erkennen" und verarbeiten. So würd ich da rangehen... Also in Schtitt 5 ist vielleicht immer ein bestimmtes Ventil offen, welches den Schutz darstellt, dann die Öffnung des Ventils SIL2-mäßig erfassen...
-> Freigabe_Pumpe := Ventil_offen OR Druck_OK;
 
Zuletzt bearbeitet:
Petri Netz sieht zwar grausig aus, schafft aber eine visuelle Basis für eine programmtechnische Umsetzung welche genauso vollzogen werden kann
 
Zuviel Werbung?
-> Hier kostenlos registrieren
DCDCDC schrieb:
Petri Netz sieht zwar grausig aus, schafft aber eine visuelle Basis für eine programmtechnische Umsetzung welche genauso vollzogen werden kann
Zum Vergrößern anklicken....
Ausserdem kannst du es auch für die Validierung verwenden

itsdarkdownhere schrieb:
Könnte man das nicht auch mittels Grafcet, bzw. Teil-Grafcets?
Zum Vergrößern anklicken....
Kann man auch machen ... wird aber auch nicht übersichtlicher.
Du musst daran denken, dass die Sicherheitsfunktionen mehr eine Verknüpfungssteuerung als eine Schrittkette sind.

Eine Cause and Effekt Matrix ist auch eine recht gute Möglichkeit.
 
ducati schrieb:
hmm, also wie soll man sich das konkret vorstellen?

Welche Gefahr besteht bei zu hohem Druck? Und warum besteht diese konkrete Gefahr bei bestimmten anderen Prozessschritten NICHT?

Grundsätzlich gehts ja bei Safety IN DER REGEL erstmal um Personenschäden (z.B. wenn das Rohr platzen könnte und jemand daneben steht) Um Anlagenschäden oder Prozessprobleme unter bestimmten Umständen zu verhindern, muss es vielleicht DAFÜR nicht SIL2 sein?

Am Ende muss jemand der sich damit auskennt konkret über die Safetyfunktionen nachdenken. In der Prozessautomatisierung ist das in der Regeln auch nochmal komplizierter als mit der Maschinenrichtline im Maschinenbau... Kommt dann auch noch auf die Branche drauf an.

Bei Siemens gibts ne Schulung für Safety in der Prozessautomatisierung (mit PCS7) Soll ganz gut sein, hab ich aber auch noch nicht besucht.

Wenn die Sicherheitsfunktion in bestimmten Situationen nicht gewünscht ist, weil die Anlage in diesen Situationen anderweitig geschützt ist, müsste man diesen anderweitigen Schutz in SIL2 "erkennen" und verarbeiten. So würd ich da rangehen... Also in Schtitt 5 ist vielleicht immer ein bestimmtes Ventil offen, welches den Schutz darstellt, dann die Öffnung des Ventils SIL2-mäßig erfassen...
-> Freigabe_Pumpe := Ventil_offen OR Druck_OK;
Zum Vergrößern anklicken....
Moin,

oben war ein Beispiel.
Konkret ist es ein Vorschlag einer Maßnahme des Explosionsschutz der die Bildung einer ATEX Atmosphäre verhindern soll. Alles in einer Bestandsanlage (bzw. Behälter und Abluft) die per Definition keine ATEX-Zonen sind. Aber der Kunde wohl gelernt hat, das sie doch "ein bisschen Ex sein kann". Also soll das Auftreten dieser Zone wirksam verhindert werden in bestimmten Prozessschritten.

Das war jetzt ein Vorschlag aus der Hazop des Kunden und noch keine konkrete Planung für die umzusetzende Maßnahme, die wahrscheinlich noch andere Möglichkeiten bringt.

In der Hazop hat er alle Gefahren an die jeweiligen Prozessschritte geknüpft, was ich es als Anlass genommen habe, mal grundsätzlich zu fragen wie sowas funktioniert, wenn unsicheres Programm und sichere Anforderungen aufeinander treffen.

Deswegen waren eure Hinweise sehr hilfreich!
Danke!
 
redtraxx schrieb:
In der Hazop hat er alle Gefahren an die jeweiligen Prozessschritte geknüpft, was ich es als Anlass genommen habe, mal grundsätzlich zu fragen wie sowas funktioniert, wenn unsicheres Programm und sichere Anforderungen aufeinander treffen.
Zum Vergrößern anklicken....
Soweit ja ok, aber dann sollte der erste Schritt sein, dass du Hazop weiter detailierst und versuchst anstelle der Prozessschritte die beteiligten Sensoren und Aktoren zu ermitteln. Das wurde auch schon weiter oben vorgeschlagen. Das ganze kann man auch in ner Matrix (Excel-Tabelle) darstellen. Sehr wahrscheinlich gibt es dann Kombinationen für sichere und nichtsichere Zustände. Darauf hin kannst du dir die Hardware genauer anschauen und sichere Sensoren und Aktoren nachrüsten.
Die ganzen Vorschläge mit Plausibilitätsprüfungen, Handshake, usw. gelten eigentlich nur, wenn nicht möglich ist gefährliche Zustände an Hand von Sensorik und Aktorik zu erkennen.
Hast du z.B. ein Ventil oder einen Mischer mit dem du eine gefährliche Komponente zumischt, dann kannst du das Ventil mit einer sicheren Stellungsabfrage versehen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bei EX-Zonenreduzierung wird halt oft der Spieß umgedreht, trotzdem meist ziemlich kompliziert...

Also, wenn z.B. ein Ventilator zur EX-Zonenreduzierung laufen muss, dann nimmt man z.B. ne sichere SIL2-Strömungsüberwachung her und verriegelt damit SIL2-Aktoren, die die EX-Zone einbringen (z.B. Magnetventile die ein Gas einbringen, Zulaufventile für bestimmte Medien usw.)

Das ist dann trotzdem unabhängig von Prozessschritten, da in den Prozessschritten, wo die Überwachung nicht benötigt wird, die Aktoren welche die EX-Zone einbringen nicht aktiv sein sollten...
 
Blockmove schrieb:
Soweit ja ok, aber dann sollte der erste Schritt sein, dass du Hazop weiter detailierst und versuchst anstelle der Prozessschritte die beteiligten Sensoren und Aktoren zu ermitteln. Das wurde auch schon weiter oben vorgeschlagen. Das ganze kann man auch in ner Matrix (Excel-Tabelle) darstellen. Sehr wahrscheinlich gibt es dann Kombinationen für sichere und nichtsichere Zustände. Darauf hin kannst du dir die Hardware genauer anschauen und sichere Sensoren und Aktoren nachrüsten.
Die ganzen Vorschläge mit Plausibilitätsprüfungen, Handshake, usw. gelten eigentlich nur, wenn nicht möglich ist gefährliche Zustände an Hand von Sensorik und Aktorik zu erkennen.
Hast du z.B. ein Ventil oder einen Mischer mit dem du eine gefährliche Komponente zumischt, dann kannst du das Ventil mit einer sicheren Stellungsabfrage versehen.
Zum Vergrößern anklicken....
ja die DIN EN 62881 zeigt da ein paar Möglichkeiten. Verriegelungsmatrix, die DIN EN IEC 61511 schlägt ja dieses Verfahren auch vor, ohne dann aber ins Detail zu gehen.

Wir haben das auch probiert, man muss aber Kosten&Nutzen anschauen, damit man nicht mehr Zeit mit Matrizes ver(sch)wendet als mit der tatsächlichen Umsetzung. Ich persönlich finde textuelle Beschreibungen auch immer sehr hilfreich, neben solchen Tabellen.

Temporäre Überbrückung von Sicherheitskreisen oder Betriebsartenwahlen sind zwar auch kein Unding, aber sollten sorgfältig geplant und dokumentiert werden. Im Endeffekt muss der Herr Betreiber es dann ja durch die Jahre hinweg wissend und dementsprechend betreiben können.
Interessant sind auch stehende Aussagen wie dass Betriebsartenwahlen keine Sicherheitsfunktionen seien und daher im "grauen" SPS-Teil ausgeführt werden können.
 
Zurück
Oben