PL oder SIL1 über PNIO Ventilinsel ohne Profisafe

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Würde man mit einer "normalen" Ventilinsel über PNIO SIL1 erreichen können?

Also folgender Aufbau:
2 kanaliger Notaustaster-> F-DI-Karte->F-CPU->F-Programm->PNIO-Ventilinsel->Ventil

Also mir gehts um die PNIO-Ventilinsel, welche dann in der SPS keine F-Ausgänge besitzt, Aber trotzdem über die F-Software angesteuert wird.

Danke

 

[Tommi]

SIL 1 ist kompatibel zu PL b oder PLc.

PLb würde meiner Meinung nach gehen.
PLc nicht, da brauchst Du bewährte Bauteile, und die Elektronik
der Ventilinsel ist wahrscheinlich keins...
Die Ventile als solche wahrscheinlich schon.
Hersteller fragen.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist ne grenzwertige Sache. Ich würd's nicht machen.
Ich sehe auch so wie Tommi ... Max. PLb mit viel guten Willen.

 

[ducati]

Seh ich auch so. Hab da auch Bauchschmerzen. Muss ich mal versuchen, dem Anlagenbauer zu erklären, das die da an der Grenze zu Grobem Unfug agieren...
Hab mal den Hersteller der Ventilinsel angeschrieben.
Aber im F-Programm ists halt schon grenzwertig, dort normale Ausgänge zu verschalten...

 

[Elektriko]

Kannst Du die Insel nicht sicher abschalten?

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kannst Du die Insel nicht sicher abschalten?

Das würde ich so machen, wenn ichs geplant hätte. Bin aber in dem Fall nur Programmierer für ne externe Firma...
Soll halt 150 Signale im F-Teil programmieren, wovon aber nur 10 fehlersicher sind...

 

[ducati]

SIL 1 ist kompatibel zu PL b oder PLc.

PLb würde meiner Meinung nach gehen.

würde man dann PLb im F-Teil oder im normalen Teil programmieren?

 

[s_kraut]

würde man dann PLb im F-Teil oder im normalen Teil programmieren?

nenene ... PLb fällt auch schon in den SIL1 rein und da ist nichts grau.
Das ist gelb. Oder bewährte Hardware.

Es gibt regelmäßig wiederkehrend Bestrebungen aus dem Werkzeugmaschinenbau, PLb und c auch mit Standard-SPS abbilden zu können.
Ich persönlich finde das seriös, es liegt in der Herstellerverantwortung. Wenn da Prozesse existieren und eingehalten werden wie es zur Software kommt und wie diese hinreichend unabhängig verifiziert wird und die Prozesse hinreichend unabhängig überwacht werden, wird es unvorstellbar ein Problem geben. Sind wir ehrlich. Es sind dann 60% systematische Fehler umgangen: fehlerhafte oder mangelnde Spezifikation.

Software altert nicht. Sie funktioniert wie sie es soll - was zu verifizieren ist - oder sie funktioniert halt nicht. Zufällige Fehler darf man heute als unwahrscheinlich behandeln.

Daher warum nicht gesunde und durchgetestete Systeme nach z.B. 10^5 Betriebsstunden als bewährt ansehen - solange man nichts dran ändert.

DGUV mauert massiv dagegen denkt wie bisher bewährt rückwärts bewertend.

 

[s_kraut]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das würde ich so machen, wenn ichs geplant hätte. Bin aber in dem Fall nur Programmierer für ne externe Firma...
Soll halt 150 Signale im F-Teil programmieren, wovon aber nur 10 fehlersicher sind...

Sorry hatte ich überlesen.

Wenn es dein Job ist das so und so zu programmieren, dann sollst du es halt so machen.

Dann gilt es halt für dich dass du die Spezifikationen einhältst (und dass solltest du im eigenen Interesse dokumentieren) und wenn die Spezifikation falsch oder lückenhaft ist, dann bist du vorhersehbar nicht derjenige der das aufdecken kann.

Wenn da Dinge aufstoßen wie dass die Hardware nicht dem SIL taugt, dann nach dem Telefonat noch ein Mail setzen. Ball hochspielen.

In der Regel sind die Gefängnisse nicht voll Programmierer. Der Richter kennt sich mit Software eben so wenig aus wie der Staatsanwalt. Die schauen im ersten Ansatz beim Betreiber.

 

[Blockmove]

Wenn du es im F-Teil programmierst, dann hast du natürlich eine sichere Programmausführung.
Doppelter Code, Inverse Logik. Das ist sicher ein Vorteil.
Vielleicht kannst du FDBACK zur Ansteuerung verwenden.

Ich bin mir zwar sicher, dass es funktionieren wird und auch sicher wäre, aber ich hab keine Ahnung wie man es in der Sistema rechnen kann oder sonst den Nachweis bringen kann.

 

[ducati]

Wenn du es im F-Teil programmierst, dann hast du natürlich eine sichere Programmausführung.
Doppelter Code, Inverse Logik. Das ist sicher ein Vorteil.
Vielleicht kannst du FDBACK zur Ansteuerung verwenden.

Ich bin mir zwar sicher, dass es funktionieren wird und auch sicher wäre, aber ich hab keine Ahnung wie man es in der Sistema rechnen kann oder sonst den Nachweis bringen kann.

Wenn das alles im F-Teil ist, erschwert das aber ungemein das Händling bei Inbetriebnahme und auch danach...
Sind halt auch Messwerte die auf ner normalen AI Karte liegen mit Abschaltgrenzen für diese Ventile. Da muss man sicherlich zumindest in den ersten Wochen immer mal an den Grenzen ändern und das wäre halt unschön im F-Teil mit CPU-Stopp und neuer F-Checksumme und neuer F-Prüfung...

Die Ventile haben keine Rückmeldung und keine Endlagenschalter...

Achso, es sind auch noch diverse Ventile dabei, die zwar stromlos druckluftlos geschlossen sind, aber bei Notaus öffnen sollen.

Also das ganze wär meiner Meinung alles nur erlaubt, wenn es höchstens PLb wäre (untere SIL1) und dann müsste man es aber nicht zwingend im F-Teil programmieren. Also wie gesagt, die einzigen fehlersicheren Bauteile der Anlage sind die Notaustaster. Alle anderen Sensoren und Aktoren sind erstmal nicht fehlersicher.
Also daher die Frage, ob man das alles im normalen SPS Teil programmiert, weils eh höchstens PLb ist.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn du es im F-Teil programmierst, dann hast du natürlich eine sichere Programmausführung.
Doppelter Code, Inverse Logik.

Also ich verwende nen normalen DO im F-Teil. Im blödesten Fall, beschreibt den DO aber dann später nochmal jemand im normalen OB1 Programm... Das ist doch nie im Leben safe...

Hab mir schon überlegt, die Ventilinseln in nen eigenes Teilprozessabbild zu legen, welches nur dem F-OB zugeordnet ist. Dann geht zumindest mal ne einfache DO Beschaltung im OB1 nicht mehr raus. Wenn ich aber im OB1 dann ne 256 ins AB1000: P schicke, gehts vermutlich trotzdem raus.

Obs das sicherer macht, keine Ahnung.

 

[ducati]

Wenn es dein Job ist das so und so zu programmieren, dann sollst du es halt so machen.

Dann gilt es halt für dich dass du die Spezifikationen einhältst (und dass solltest du im eigenen Interesse dokumentieren)

Wie dokumentierst Du denn solche ungereimten Problemfälle?
Man könnte ja diverse E-Mails abspeichern... Aber wie machst Du das bei nem Arbeitgeberwechsel? Dann müsstest die E-Mails mit nach Hause nehmen und 30 Jahre aufbewahren?

Im blödesten Fall kommt es in 10 Jahren zu nem Unfall und ich muss in 12 Jahren vor Gericht nachweisen, dass ich damals schon drauf hingewiesen hab, dass es grober Unfug ist, ich den Unfug aber auf Anweisung trotzdem programmiert habe?

Und wer darf mich anweisen, Unfug zu programmieren? Mein Chef oder auch der Kunde...

Keine Ahnung, in der Praxis ist das alles ziemlich kompliziert, wenn man anfängt drüber nachzudenken..

 

[Blockmove]

Wenn das alles im F-Teil ist, erschwert das aber ungemein das Händling bei Inbetriebnahme und auch danach...
Sind halt auch Messwerte die auf ner normalen AI Karte liegen mit Abschaltgrenzen für diese Ventile. Da muss man sicherlich zumindest in den ersten Wochen immer mal an den Grenzen ändern und das wäre halt unschön im F-Teil mit CPU-Stopp und neuer F-Checksumme und neuer F-Prüfung...

Die Ventile haben keine Rückmeldung und keine Endlagenschalter...

Achso, es sind auch noch diverse Ventile dabei, die zwar stromlos druckluftlos geschlossen sind, aber bei Notaus öffnen sollen.

Also das ganze wär meiner Meinung alles nur erlaubt, wenn es höchstens PLb wäre (untere SIL1) und dann müsste man es aber nicht zwingend im F-Teil programmieren. Also wie gesagt, die einzigen fehlersicheren Bauteile der Anlage sind die Notaustaster. Alle anderen Sensoren und Aktoren sind erstmal nicht fehlersicher.
Also daher die Frage, ob man das alles im normalen SPS Teil programmiert, weils eh höchstens PLb ist.

Wenn letztlich nur der Not-Halt auf Safety geht und der Rest der Sensorik und Aktorik Standard-IO ist, dann kannst du den Not-Halt auch noch im Standard-Programm auswerten .

Mal nen anderen Vorschlag:
Sicheres Abschalten der Haupt-und / oder Steuerluft.
Bei den meisten Ventilinseln kann man Funktionsgruppen bilden.
Ähnlich wie mit Powermodule bei der ET200S
Also getrennte Einspeisungen von Haupt- und / oder Steuerluft.
Der Not-Halt geht auf ein sicheres Hauptventil und schaltet somit die Luft sicher ab.
Der Pneumatiker kann durch entsprechenden Aufbau der Insel und Auswahl der Ventile die Sichrheitsfunktionen bestimmen.
Du hat nur den Not-Halt als Safety. Der Rest geht im Standard-Programm. Kein Ärger mit SIL und Abschaltmatrix, Validierung, usw.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn letztlich nur der Not-Halt auf Safety geht und der Rest der Sensorik und Aktorik Standard-IO ist, dann kannst du den Not-Halt auch noch im Standard-Programm auswerten .

ja eben, frag mich halt, wofür die externe Firma ne F-CPU geplant hat
Aktuel gibts ca 10 F-DIs und 3 F-DOs und 2 Profisafegeräte. Alle anderen 100 Feldgeräte die in der Liste zum abschalten ausgeführt sind, sind nicht fehlersicher.

Mal nen anderen Vorschlag:
Sicheres Abschalten der Haupt-und / oder Steuerluft.
Bei den meisten Ventilinseln kann man Funktionsgruppen bilden.
Ähnlich wie mit Powermodule bei der ET200S
Also getrennte Einspeisungen von Haupt- und / oder Steuerluft.
Der Not-Halt geht auf ein sicheres Hauptventil und schaltet somit die Luft sicher ab.
Der Pneumatiker kann durch entsprechenden Aufbau der Insel und Auswahl der Ventile die Sichrheitsfunktionen bestimmen.
Du hat nur den Not-Halt als Safety. Der Rest geht im Standard-Programm. Kein Ärger mit SIL und Abschaltmatrix, Validierung, usw.

So machen wir das normalerweise auch wenn wir sowas planen...

Nur diese komische externe Firma machts halt anders. Ich glaub noch nichtmal, dass überhaupt ne Risikobeurteilung oder Gefährdungsbeurteilung gemacht wurde. Die basteln halt irgendwas zusammen...

Wenn ich halt damit ein schlechtes Gefühl hab, dann schalte ich den Murks jedenfalls nicht ein. Das könnens selber machen, wenn ich weit weg bin...

 

[Holzmichl]

Ich bin eher bei @Blockmove und würde ein 3/2-Wege-Zentralventil setzen und den Abgang drucklos schalten, wenn Not-Halt ausgelöst wird. Ob das ein spezielles "sicheres" Ventil sein muss bei PLc bin ich überfragt. Ich würde zumindest ein mit mechanischer Feder öffnendes Ventil einsetzen und als "bewährtes Bauteil" definieren.

Achso, es sind auch noch diverse Ventile dabei, die zwar stromlos druckluftlos geschlossen sind, aber bei Notaus öffnen sollen.

Das sehe ich als sehr grenzwertig an.
Dann lieber Ventile tauschen bzw. die Luftleitungen drehen und bei Stromlos öffnen lassen, dann aber Spulen sicher spannungslos schalten.

 

[ducati]

Ich bin eher bei @Blockmove und würde ein 3/2-Wege-Zentralventil setzen und den Abgang drucklos schalten, wenn Not-Halt ausgelöst wird.

Wir probieren grad, denen das ans Herz zu legen...

und die Ventile die öffnen sollen, müssen als NO, also stromlos/druckluftlos offen gebaut werden.

Aktuell ist das aber alles schon längst gebaut, wir solln das nurmal schnell programmieren, weil denen der eigene Programmierer davongelaufen ist...

 

[Holzmichl]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nach deinen Erzählungen kann ich mir gar nicht vorstellen, warum der ursprüngliche Programmierer die Segel gestrichen hat... [Ironie off]

müssen als NO, also stromlos/druckluftlos offen gebaut werden.

Deshalb grenzwertig: Wenn du mit einem Zentralventil die Druckluftversorgung abstellst, geht nichts mehr auf, egal wie das Ventil angeschlossen oder ausgeführt ist...

Du musst dann die Druckluft drauf lassen und elektrisch abschalten für die öffnende Bewegung. Oder es reicht nur kraftlos zu schalten.
Ich weiß natürlich nicht, was das für ein Aktor ist. Ob Zylinder der klemmt oder pneumatischer Antrieb, der ein Ventil oder Klappe öffnet macht hier schon einen großen Unterschied.

Ansonsten hast Du ja genug Erfahrung, eine gute Einschätzung zu treffen.
Und die Arbeit ablehnen kann auch in bestimmten Fällen eine richtige Entscheidung sein.

 

[ducati]

Es passt halt alles nicht so wirklich zusammen. Wie immer eigentlich. Nur bei normalem SPS-Programm nehm ich das nicht so krumm und programmier einfach dass es funktioniert und bau evtl. bei der IBN die schlimmsten Fehler um.
Bei fehlersicheren Dingen würd ich gern nur stur das abtippen, was sich der jenige der die Risikobewertung gemacht hat, ausgedacht hat. Nur wenn da vorn und hinten nix zusammenpasst dann geht das halt nicht

 

[s_kraut]

Wie dokumentierst Du denn solche ungereimten Problemfälle?

Als ich draußen war, hat man mich nicht dafür bezahlt Problemfälle zu produzieren und zu dokumentieren.
Man hat mich dafür gezahlt die Problemfälle bereits im Vorfeld zu vermeiden (idealerweise) oder die Dinge vor Ort zu lösen.

Am Ende unterschreibt eh der technische Leiter die CE und der hat auch kein Bock auf Ärger. Wenn der sagt IBN verzögert sich weil wir auf ein Sicherheitsbauteil warten dann ist das so.

Man könnte ja diverse E-Mails abspeichern... Aber wie machst Du das bei nem Arbeitgeberwechsel? Dann müsstest die E-Mails mit nach Hause nehmen und 30 Jahre aufbewahren?

Also ich hab da noch so ein Notizbuch, wo die wichtigen Punkte festgehalten werden. Das ist immer bei mir und nicht beim AG.

Im blödesten Fall kommt es in 10 Jahren zu nem Unfall und ich muss in 12 Jahren vor Gericht nachweisen, dass ich damals schon drauf hingewiesen hab, dass es grober Unfug ist, ich den Unfug aber auf Anweisung trotzdem programmiert habe?

Dann steht Aussage gegen Aussage. Vielleicht gibt es Zeugen?

Und wer darf mich anweisen, Unfug zu programmieren? Mein Chef oder auch der Kunde...

Keine Ahnung, in der Praxis ist das alles ziemlich kompliziert, wenn man anfängt drüber nachzudenken..

Naja normalerweise sind alle die mit Technik arbeiten Menschen, mit denen man reden kann. Wenn man sagt, dass man Bauchweh hat dann hören die schon zu.
Der Betreiber will ja auch keine Unfälle auf seinem Gelände und höhere Unfallversicherungsbeiträge auch nicht.

und die Ventile die öffnen sollen, müssen als NO, also stromlos/druckluftlos offen gebaut werden.

Ja, klar wenn es darauf ankommt! Sicherer Zustand ist immer der Energielose. Wenn man was anderes braucht dann wird es richtig kompliziert.

Aktuell ist das aber alles schon längst gebaut, wir solln das nurmal schnell programmieren, weil denen der eigene Programmierer davongelaufen ist...

Das wundert mich nicht, nachdem was du da schreibst

Ich bin eher bei @Blockmove und würde ein 3/2-Wege-Zentralventil setzen und den Abgang drucklos schalten, wenn Not-Halt ausgelöst wird. Ob das ein spezielles "sicheres" Ventil sein muss bei PLc bin ich überfragt. Ich würde zumindest ein mit mechanischer Feder öffnendes Ventil einsetzen und als "bewährtes Bauteil" definieren.

SIL1 PLc geht mit bewährten Bauteilen, wenn man die bewährten Sicherheitsprinzipien einhält - wie du schreibst.