Fragen zu Risikobeurteilung ISO 12100 und sichere Roboter

Hallo,

in letzter Zeit setzen wir immer mehr 'Sichere Roboter' ein. Also Roboter die mit zusätzlichen Hard- bzw. Software Optionen (wie Safe Move, Safe Operation oder Dual Check Safety) abgesichert werden.
Nun haben wir Programmierer auch Schulungen bekommen und wissen wie man diese Optionen konfiguriert. Doch wer legt eigentlich fest was zusätzlich abgesichert werden muss und was nicht?

Von den Roboterherstellern wurde uns mitgeteilt, dass wir Programmierer diese Safe Optionen „nur“ konfigurieren müssten. Was aber als sicherheitsrelevant letztlich mit diesen Optionen abgesichert werden muss, würden die Fachleute festlegen, die auch die Risikobeurteilungen erstellen.
Wir Programmierer würden mit unserer Unterschrift nur bestätigen, dass der Roboter nach dieser Risikobeurteilung richtig konfiguriert wurde.

In unserer Sicherheitsabteilung werden dazu auch Risikobeurteilungen nach ISO 12100 erstellt.
Jedoch steht im Bereich Roboter dort sehr wenig. Oft steht nur dort, dass eine sichere Software zum Schutz angewendet wird, manchmal nicht mal das. Siehe angehängtes Bild.
Die Meinung unserer Sicherheitsabteilung ist, dass ich als Programmierer selber festzulegen habe, was zusätzlich geschützt werden muss.

Wie soll ich mich nun verhalten? Das Problem ist, dass ich als Programmierer nicht beurteilen kann, ob Bereiche der Schutzbehausung stabil genug sind oder ob sie extra abgesichert gehören.
Das Dilemma ist, gehe ich auf Nummer Sicher, dann wird höchstwahrscheinlich die Taktzeit der Anlage nicht erreicht oder ganze Bereiche sind vom Roboter nicht zu erreichen.

Was würde passieren wenn ich die Sicherheitssituation falsch einschätze?

Wie würdet ihr an meiner Stelle entscheiden und wie handhabt das ihr in eurer Firma.

Vielen Dank,
Gruß Martin

Vielen Dank für eure Antworten.
Ihr seit also auch der Meinung, dass die angehängte Risikobeurteilung für den Roboter nicht ausreichend ist.
Ich will mal anders fragen. Wie kann ich meine Vorgesetzten von der Notwendigkeit überzeugen, was würdest ihr an meiner Stelle tun?
Das Problem ist, es will bei uns keiner hören...

Hauptsächlich geht es um folgenden Punkt:
Die Rückhaltewirkung des Zauns, die in der Regel nicht gegeben ist. Nicht wenn der Greifer 150 KG wiegt!

In meinem derzeitigen Projekt kommt noch erschwerend hinzu, dass es mehrere Greifer gibt, mit unterschiedlichen Außenkonturen. Auch unserer Kunde möchte seine eigenen 150 KG Greifer mit der Anlage fahren. Diese Greifer kennen wir noch gar nicht.
Diese Greiferkodierung müsste über die Safe SPS mit sicheren Eingängen abgefragt werden, aber zur Zeit wird diese Notwendigkeit bei uns noch nicht gesehen.

Zitat von Dos 6.22

Nun du machst ja schon alles richtig. Nur mach das ganze per Email und behalte selber eine Kopie davon. Wenn der Chef nicht hören will, diese Email als Kopie an die Geschäftsführung. Wenn das die gleiche Person ist, der noch mitteilen, dass du die Safetyprotokolle so nicht unterschreibst. Dass müsste dann jemand anders machen. Oder noch besser, du machst den Test und schreibst dann da rein, durchgefallen. Mit Unterschrift und dem Hashwert des Programmes. Das ganze dann in Kopie aufbewahren.
Und wenn der Chef dann immer noch will, dass du das Ding an den Kunden übergibt, nun wie schon gesagt, das Ding hat keine CE. Das darf gar nicht betrieben werden und der Geschäftsführer haftet dann.

Nun, von mir will keiner eine Unterschrift! Das CE-Zeichen unterschreiben andere, egal ob eine sichere Software verkauft wurde oder nicht. Es interessiert sich einfach niemand dafür. Ich werde dann meine Bedenken per Email mitteilen, sie werden es zur Kenntnis nehmen, mehr nicht.
Möglicher Weise ist diese Tatsache für mich juristisch von Vorteil, ist mir aber egal. Ich möchte so nicht arbeiten!

Dabei hat es sogar Sicherheitsabnahmen von sicheren Robotern gegeben. Mein Vorgesetzter hat sich das angeschaut und erklären lassen. Wir haben die Doku und die Checklisten ihm überreicht.
Das geschah aber nur, weil wir unseren Vorgesetzten in diesem Fall zumindest überzeugen konnten. Und nein, mein Vorgesetzter hat keine Sicherheitsschulung erhalten!

Zitat von Dos 6.22

Zum Roboter jetzt, ist das ein Safety Roboter? Weil der kann ja so programmiert werden, dass er nicht in den Zaun fährt. Das muss dann natürlich eingestellt werden und getestet. Also händisch zum Zaun fahren und prüfen ob der Arbeitsraum gesperrt wird. Per Hand aber auch mit einem Automatikprogramm, was bewusst in den Zaun fahren will.
Du musst dann Berechnungen von der Konstruktion erhalten, wann der Roboter mit dem Bremsen anfangen soll.
Der Zaun ist in diesem Fall wirklich nur dafür da, den Menschen abzuwehren....

Und noch als Update. Wir aus unserer Firma waren bei KUKA vor Ort. Die haben da natürlich alles mit Safety Robotern vollstehen. Auch die grossen Kaliber. Die standen auch sehr dicht am Zaun. Klar der Roboter kann so einen Zaun umhauen. Aber dafür ist das Safety ja gedacht. Die Software wird so eingerichtet, dass er Roboter soetwas bemerkt und dann ihn sicher abbremst damit er vor dem Zaun stehen bleibt.
Damit das geht, brauchst du von deinen Konstrukteuren oder jemand anderen der sich damit auskennt, die Entfernung zum Zaun für den Arbeitsbereich.

Ja genau das ist das Problem! Die Konstrukteure zeichnen ihren Zaun direkt neben dem Arbeitsbereich des Roboters, weil angeblich der Kunde kein Platz hat, und wir Programmierer sollen dann mit safety es so gestalten dass der Roboter nicht in seinen Zaun fahren kann.
In Teachgeschwindigkeit ist das kein Problem, aber bei 100% Automatik ist da ja noch der Bremsweg, wie du schon erwähntest. Und die Zykluszeit ist selbst bei 100% meist zu knapp! Aber richtig, man müsste hart bleiben und sagen, schneller geht halt nicht, pasta!
Dann gibt es noch unterschiedlich große Greifer und der kleinste bleibt dann schon in Teach 1m vor dem Zaun stehen :(.

Wir bekommen keine Bremswege von der Konstruktion. ABB hat das uns auch gesagt, dass das eigentlich so sein müsste.
Wir testen dann die Bremsrampen per Hand in full speed. Scheiben ausbauen und so. Aber meistens ist zu wenig Platz. Ich sehe das so, dass dann Safety wirkungslos ist, aber wir haben es verkauft und können sagen die Anlage ist sicher so scheint es mir fast.

Und wenn es dann nicht geht, wird es auf die Safety SW geschoben, oder man wirft es uns vor. Dann hat man eine unsichere Greiferodierung, ausreichend für den Ablauf und fragt sich warum die Safety SPS diese Informationen nicht hat...

Ja Safety SPS! Ähnlich Geschichten können unsere SPSler erzählen wenn es um Siemens oder Pilz geht.

Hallo,

seit meinen letzten Posting hat sich in unserer Firma in Sachen Sicherheit was getan. Wir haben jetzt einen SiFa der auch für die Risikobeurteilung sicherer Roboter zuständig ist.
In der letzten Zeit mussten wir Programmierer ja das mehr oder weniger selber festlegen. Doch einige dieser Vereinbarungen wurden jetzt leider von unserem neuen SiFa gestrichen. Er nennt sie wörtlich "eine überzogene Sicherheitsspirale".

Also wir haben einen sicheren Roboter, der mit einer SSPS kommuniziert. Es ist ein Arbeitsplatz hinter dem Schutzzaun (siehe Bild) bei einem Worst Case zu schützen. Dieser Schutz soll mit der sicheren SW -Option des Roboters bewerkstelligt werden.
Dass wir so eine Absicherung brauchen steht ja schon von vorn hinein fest, sonst hätten wir ja nicht für tausende Euros diese sichere Option bestellt.

Habe mal folgendes Bild aus dem bgi5123.pdf hier angehängt:

Zitat

– ein ausreichender Abstand des Roboters zur Umzäunung,

[Leider nicht vorhanden]

Zitat

– mechanische Anschläge (Puffer),

[Nein, weil nur schwer möglich und außerdem durch Sichere SW ersetzt]

Zitat

– eine ausreichende Festigkeit der Umzäunung,

[Nein, im Regelfall nicht gegeben]

Zitat

– eine sicher überwachte Robotersteuerung,

[Ja, kommt zum Einsatz]

Zitat

– sichere kontaktbehaftete oder elektronische Achsnocken,

[Nein, weil nur schwer möglich und außerdem durch Sichere SW ersetzt]

Zitat

– innen angeordnete Lichtschranken bzw. -vorhänge.

[Nein, weil durch Sichere SW ersetzt, wäre aber auch eine der Lösungen]

Erschwerend kommt hinzu, dass der Roboter ein Greiferwechselsystem hat. Die Greifer (Endeffektoren) haben unterschiedliche Formen, die sich nicht als einen gemeinsamen Sicherheitsraum zusammenfassen lassen.
Beim Wechsel zwischen großen und kleinen Endeffektor verändern sich die Arbeitsbereiche erheblich. Es ist aber problemlos möglich verschiedene Werkzeugbereiche mit der sicheren Robotersteuerung zu verwalten.
Die Information, welcher Endeffektor tatsächlich sich im Roboter befindet bekommt die sichere Roboter-Steuerung über sichere Signale von der SSPS.
Doch diese Information wird Regel über die normale SPS, über eine einfache 16bit Kodierung, mit Kontakten abgefragt, also:

0000 0001 = Greifer 1
0000 0010 = Greifer 2
0001 0000 = Greifer 16 u.s.w

Unserer neuer SiFa möchte auf diese "unsichere" Kodierung auch mit der SSPS zugreifen, er hält das für ausreichend. Ich habe aber meine Bedenken! Und die Kommunikation mit ihm ist schwierig, da brauchen wir schon stichhaltige Argumente.

Wenn es nun zu einem Drahtbruch in der Kodierung käme, kann doch die Sicherheit dieses Arbeitsplatzes nicht mehr gewährleistet werden, weil dann der falsche Werkzeugraum in der Sicherheits-SW aktiviert werden würde? Also ich kann mir nicht vorstellen, dass es erlaubt ist in einem durchdachten sicheren System, sicherheitsrelevante Information unsicher zu verarbeiten!
Was meint ihr dazu? Was würdet ihr tun, wenn ihr sowas projektieren oder programmieren müsstet?

In einem anderen Forum wurde geschrieben, dass hier die DIN EN ISO 10218-2 anzuwenden sei. Aber gibt es konkrete Richtlinien bei der die Verwendung von unsicheren Signalen in einem sicheren System zulässig sind?

Nun es ist so, dass wir schon einige Ideen haben die auch plausibel erscheinen. Auch haben wir einige Möglichkeiten die Greifer plausibel abzufragen, damit ein Drahtbruch nicht zu einen Worst Case führen kann. Technisch sehe ich da keine Probleme.
Hat aber alles keinen Sinn weil unserer SiFa hier anderer Meinung ist.

Nun, im Grunde geht es mich ja nichts an. Ich schreibe nicht das SPS-Programm und ich erstelle auch nicht die Risikobeurteilung in unserem Betrieb. Ich habe nur meine Bedenken zum Ausdruck gegeben.
Allerdings viel der Emailverkehr nicht so konstruktiv aus, was die Sache leider nicht einfacher macht. Ich habe mir mal erlaubt, diesen Emailverkehr hier anzuhängen:

Dazu schrieb ich:

Zitat

Im Prinzip möglich. Da habe ich aber ein Frage: Wie wird dann eine Fehlkodierung z.B. aufgrund eines Defektes verhindert?

Erläuterung:
1100 = 12
1101 = 13 -> 110X = 12

Letztes PIN hat kein Kontakt, es wird statt Code 13, Code 12 erkannt, somit der falsche Greifer.

Dazu kam folgende Mail von unserer Sicherheitsfachkraft:

Dazu schrieb ich:

Zitat

Doch genau dafür gibt es doch sichere Signale! Wenn wir diese nicht nehmen stellt sich für mich die Frage wie wir eben so eine Fehlkodierung verhindern, die du selber oben beschreibst.
Das würde doch sonst das ganze sichere System in Frage stellen. Entweder ist es "sicher" oder nicht. Und sollten die Greifer keine Gefahr darstellen, so brauchen wir auch keine sichere Software, oder?
Wenn du es so in der Risikobeurteilung verantworten kannst ist das deine Sache. Ich werde meine Bedenken aber auf dem Protokoll vermerken, das ich unterschreibe, wenn dem so sei.
Ich sehe es aber als meine Pflicht Bedenken anzumelden.

Dazu kam wiederum folgende Mail von unserer Sicherheitsfachkraft:

Vielen Dank im Voraus
Martin