TIA Signale einlesen auf Safety

[Drumfan159]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mahlzeit zusammen,

bin letztens das erste Mal so richtig mit einem Safetyprojekt konfrontiert worden. Bei der Anlage geht es um handling von Prozessmedien...sprich es gibt neben etlichen VOLL Signalen auch sehr viele ÜBERVOLL Signale, Leckagen, etc.
Ich soll mich nun um eine Art Grundprojekt kümmern. Meine Frage nun, ob es überhaupt Sinn macht z.B. ein Übervoll-Signal eines Behälters auf der Safety einzulesen und zu verarbeiten, wenn es mal überhaupt nicht Zeitkritisch ist.
Wenn Netzschütze oder der Not-Aus-Kreis in der Safety realisiert werden---OK----dafür ist es ja auch geeignet. Oder wenn es um etwas Zeitkritisches geht wie Servoantriebe oder dergleichen.

Aber wenn es nur um ein Öffnerkontakt geht, der als sichere Erkennung/Abschaltung dienen soll, macht das doch wenig Sinn den Eingang in der Safety einzulesen und dann in diverse Standartbausteine außerhalb der Safety zu verarbeiten, oder ist das auch nichts anderes wie wenn ich das auf die Safety verdrahtete Signal außerhalb der Safety einlese und weiter benutze??

Das Problem ist wenn ich dann in diesen Bausteinen mal eben kurz eine Kleinigkeit ändern will, geht mir zwecks Safetyanbindung die CPU immer auf stopp und unterbricht den gesamten Prozess.

LG Drumfan.

 

[MSB]

Naja, bei Übervoll, Leckage und so Sachen, geht es dann ja eher um SIL, WHG, evtl. dann doch wieder um Personensicherheit wenn sich irgendwas vermischt, was irgendwie reagiert ...
Also kurzum: Pauschal gesprochen ist meine Glaskugel gerade in Reparatur.

Die nächste Frage wäre dann natürlich im Anschluss, welche Möglichkeit der Reaktion du in dem Fall hast:
Das kann eine sichere Hupe sein, Prozessventile die den Zu oder Ablauf sicher stoppen ...

Aber auch hier: Ohne detailierte Anlagenkenntnis, ist das ein wenig wie Kaffeesatzlesen oder Bleigießen.

Mfg
Manuel

 

[Drumfan159]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja das ist schon schwierig das stimmt....ist halt dann wieder Projektbezogen.
Nehmen wir mal an ich steuere einen Absperrschieber bzw. Ventil in der Safety an, was genau macht dann da die Safety anderst als in einem FC/FB der keine F-Signatur hat?

Oder macht das einen großen Unterschied wenn ich z.B. ein Leckagesignal in der Safety einlese oder den Safety-Eingang in einem normalen FB einlese? Weil dieser ist ja tzd als Safety eingang deklariert?

Vielleicht ist mir schon geholfen wenn ich den unterschied diesbezüglich richtig verstehe...dann kann ich besser entscheiden was wie wo ich am Besten umsetze

 

[m_w]

Mal unabhängig davon, ob deine Safety-Auslegung jetzt richtig ist oder nicht.

Ich meine gelesen zu haben, dass Siemens empfiehlt, einen DB für die Kommunikation zwischen F-Teil und normalem Programm anzulegen.

Du legst einen DB an mit "Daten_Zur_Safety" und in diesem DB ist dann die Variable für deinen Aktor in der Safety. Diese Variable kann man dann zu den anderen Schaltfreigaben in der Safety an den Ausgang parametrieren aber auch im normalen Programm beschreiben.

Der Aktor in der Safety hat dann neben dem Signal aus dem DB halt noch andere Bedingungen die entscheiden, wann geschalten wird.


Oder habe ich die Fragestellung falsch verstanden?

 

[MSB]

Typischerweise würde dein Schieber ebenfalls an einem F-Ausgang(en) hängen.
F-Eingänge kannst du generell nur verwenden im Standard-Programm, wenn mindestens ein F-Eingang von jeder F-Karte, mindestens einmal im F-Programm verwendet wurde.
F-Ausgänge können generell nur im F-Programm beschrieben werden.

Der Vorteil, bzw. rechtliche Notwendigkeit ist hier dann u.a.: Die Signatur ist fälschungssicher, d.h. sollte irgendwer den Baustein ändern, ist dies eindeutig in der geänderten Signatur ersichtlich.
Zum anderen, da es ja eine Sicherheitsfunktion ist, ist es ja alleine deshalb auch schon sinnvoll, das diese nicht mal eben so, quasi Versehentlich geändert werden kann.

Der Nachteil natürlich primär der, dass Änderungen hier einen CPU-Stop erfordern, weswegen es durchaus sinnvoll sein kann, die übergeordnete Sicherheitsebene auf eine eigene F-CPU zu ziehen.

Mfg
Manuel

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja das ist schon schwierig das stimmt....ist halt dann wieder Projektbezogen.
Nehmen wir mal an ich steuere einen Absperrschieber bzw. Ventil in der Safety an, was genau macht dann da die Safety anderst als in einem FC/FB der keine F-Signatur hat?

Oder macht das einen großen Unterschied wenn ich z.B. ein Leckagesignal in der Safety einlese oder den Safety-Eingang in einem normalen FB einlese? Weil dieser ist ja tzd als Safety eingang deklariert?

Vielleicht ist mir schon geholfen wenn ich den unterschied diesbezüglich richtig verstehe...dann kann ich besser entscheiden was wie wo ich am Besten umsetze

Kurz und bündig:

Wir sprechen heutzutage, wenn es um Personensicherheit geht, davon, dass eine Funktion einen gewissen Performance Level erfüllen muss, die gibts von a bis e (kurz: PLa bis PLe)
Welcher Level das sein muss sollte idealerweise für jede Funktion durch eine Risikoanalyse heraus kommen - lassen wir das der Kürze halber mal weg.

Mit einem Standard SPS-Ausgang und einem Standard-FB wirst du nicht über PLa hinaus kommen - zumindest nicht ohne Zusatzmaßnahmen. Das wird für eine Beleuchtung oder für ein Lüftungsklappe schon mal reichen.
Kann man jemanden verletzen bist du schnell mal in PLc oder PLd. Um an einem Aktor PLd zu erreichen, muss, vereinfacht gesprochen, die gesamte Kette PLd entsprechen - vom Sensor bis zum Aktor (inkl. Software) - und dann machen Safety-Eingänge und Safety-Bausteine schon mal Sinn.
Umkehrschluss: Wenn du Sensorik auf Safety-Eingänge führst, damit aber nichts sicherheitsrelevantes abschalten kannst, weil es die Aktorik oder die Anbidnung der Aktorik nicht her gibt, dann stellt sich natürlich die Sinnhaftigkeitsfrage bei den Eingängen.

Nehmen wir mal an ich steuere einen Absperrschieber bzw. Ventil in der Safety an, was genau macht dann da die Safety anderst als in einem FC/FB der keine F-Signatur hat?

Naja, das Programm wird halt von der F-CPU redundant verarbeitet und die Zwischenergebnisse überprüft - und fall da mal was schief geht werden Fehler erkannt usw....

 

[Drumfan159]

Okei danke für eure Antworten!
Der Richtigkeithalber werde ich dann wohl alles was als Sicherheitsabschaltung/-erkennung dienen muss auf die Safety legen und werde es mit einem Art Kommunikations DB zwischen Safety und normalen Programmablauf umsetzen, die Lösung gefällt mir doch sehr gut.

Oder eben einen direkten Eingang in der Safety lesen und das Bit dann auf eine E/A-Zwischen DB und damit sollte dann alles abgefrühstückt sein, so wie ich das verstehe.