funktionale Sicherheit nach 13849, Doku

Koch

Level-1
Beiträge
82
Reaktionspunkte
6
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

mal eine Frage zur 13849 zum Thema Dokumentation. Ich habe mich in die Norm entsprechend eingearbeitet, den BGIA-Rport 2/2008 durchgearbeitet und kenne mich auch mit SISTEMA aus. Jetzt habe ich ein Regalbediengerät damit bewertet, doch was Doku und Prüflisten angeht bin ich da noch nicht so ganz 100, wie das denn aussehen soll.

Laut 13849-1 muss folgende Doku entstehen:
1-"Spezi der Sicherheitsanforderungen"
2-"Spezi der Sicherheitsfunktionen"

dann noch der 13849-2 Teil: Validierung:
3-"Analyse der SRP/CS und Fehleranalyse" und daraus
4-"die Prüflisten"

Diese Aufzählung ist nicht komplett aber mal ein kleiner Überblick. SW lasse ich mal absichtlich beiseite, da werd ich wohl noch einen 2. Thread öffenen.

Also die Fragen:

a)
Ich würde einen Grossteil der Doku gerne über SISTEMA erschlagen, da ich denke die Doku 1-3 (s.o.) lässt sich mit SISTEMA gut darstellen und mit diversen angehängten Dokumenten ergänzen.
Was mir dabei Sorgen bereitet, ist das ich mich zu erinnern glaube gelesen zu haben (ist immer so ne Sache mit so viel Papier), das die einzelnen Dokumente klar voneinander unterschieden werden können müssen.

b)
Wie macht Ihr das mit den Schaltbildern der SF? Ich würde entsprechende Seiten aus dem Stromlaufschema nehmen und ev. die relevanten BT farblich hinterlegen, oder auf dem Anschlussplan des Sicherheitsrelais.
Wenn ich meinem Chef sage, das alle SF-Schaltbilder noch einmal einzeln erstellt werden müssen, der Übersicht halber, dann wird der nicht begeistert sein.
(nicht die sicherheitsspezifischen Blockdiagramme, bei denen ist klar)

c)
Noch zur Analyse aller relevanten Fehler. Da heisst es man kann eine FMEA machen, aber würde ich gerne vermeiden.
Denke man kann z.T. die Fehlerlisten abarbeiten, aber selbst das wäre gelinde gesagt arbeitsintensiv, kann man da nicht mit gesundem Menschenverstand ran, und wenn ja, wie begründe ich das und in welcher Form.

Bin schonmal gespannt, was rüberkommt. Hab übrigens grad meinen Abschluss gemacht *plöpp*

Euer koch

P.S. noch ein Bild zum Anwebdungsbereich von SISTEMA, vom IFA/BGIA



ach ja und den *vde*
 

Anhänge

  • Anwendungsbereich SISTEMA.pdf
    74,1 KB · Aufrufe: 153
Zuletzt bearbeitet:
Hallo,
Gratulation zu Deinem Abschluss!
Habe wenig Zeit wenn Du Interesse hast kann ich aber nach dem Stress was dazu schreiben mache gerade ein Seminar wo es genau um dieses Thema geht.
13849 und die Validierung.
 
Hallo,
also die SiSteMa als führendes Tool sehe ich nicht.
Meine Vorgehensweise orientiert sich an der DIN EN 13849-1 Bild 3, dass was da steht muss man nachweisen. Also Arbeite ich in einem von mir erstellten Worddokument alles ab, stelle die mir die einzelnen Fragen und erarbeite für jede einzelne SF die Antworten. Den Anteil der mir am wichtigsten erscheint ist die Dokumentation der Anforderungen der Kategorien, hierzu benutzte ich die Tabelle 2 aus der prEN ISO 13849-2 hier steht genau was man Dokumentieren muss. Das alles wird vom Konstrukteur der SF erstellt die aller meisten Dinge musst Du doch sowieso ermitteln, dann muss man dies eben nur noch eintragen in die Dokumente. Man stellt sehr schnell fest wenn man das richtig macht, dass man daraus auch die Software Spezifikation herauslesen kann und viel mehr noch die Funktionsprüfungen auch. Dann gibt es für jede SF noch ein Validierungsdokument, welches bei höheren Anforderungen von einem zweiten erstellt wird. Ich hinterlege alles in einem PDF-Portfolio, Schaltpläne, Datenblätter, Zertifikate, die einzelnen SF Doku, die Software Doku. zum Nachweis des Einfachen V-Model, SiSteMa Berechnung, Strukturiere alles und beziehe mich in den SF Doku auf die Nummer des Dokument und gebe die Seite an wo es steht, so kann man sehr schnell prüfen on alles i.o. ist. Stellt am Anfang einen großen Aufwand dar aber dann geht es sehr schnell da man die meisten SF eh immer wieder hat. Man muss nur noch die Verweise anpassen und eben auch schauen das man sich an alles gehalten hat. Standards sind hier gefragt. Die Validierung erstelle ich im gleichen Still mit einem Worddokument, hier halte ich mich an die 13849-2 arbeite Schritt für Schritt die Fragen ab und weise so mit einer Prüfung nach das alle Dokumente da sind und alles Plausibel ist. Dann muss man noch die Funktionsprüfung machen die ergibt sich aus der Spezifikation der SF die bei mir eine genaue Angabe ist wie und was zusammen spielt und zwar so genau das man draus ableiten kann man zu ermitteln ist.
Zur FMEA, wenn Du z.B. Baumuster geprüfte Lösungen einsetzen kannst, sehe ich hier keinen Grund für eine FMEA. Hier kann man sich auf vorhandene Schaltungsbeispiele und genaue Manuals berufen. Und genau das versuche ich sooft wie möglich da hat man viel weniger Aufwand. Aber man kommt nicht immer um eine FMEA, also freunde Dich damit an. Es hilft sehr oft Schwachstellen zu entdecken.
War eine grobe Vorgehensweise von mir, es gibt natürlich viele Wege. Was ich da mache ist nicht immer 100% Norm, aber ob es überhaupt möglich ist dies zu erreichen überlassen ich dann Dir.


Es ist eben sehr schwer die Anforderungen mit Leben zufüllen.
 
Hallo Safety

Vielen Dank für die Ablaufbeschreibung, hilft mir den Vorgang zu veranschaulichen.

Das die SW-Spezi aus den Anforderungen für die SF kommt, habe ich auch vor so zu realisieren. Scheint mir am stimmigsten. Allein die Anforderungen zu formulieren und zu dokumentieren, da bin ich gespannt, aller Anfang ist schwer. Dabei habe ich die nicht zu verachtende Hürde zu nehmen, das ich dass meinem Chef und dem Hardwareplaner verkaufen muss.
- Der Hardwareplaner hatt (natürlich) keine Lust auf die Doku, bzw. meine Doku zu lesen. Im Moment ist es eher so, das ich zu ihm renne und nachfragen muss, wie er es denn realisiert, er will von mir nur wissen ob das geht. Da hat man das Problem, das zwar viele Sachen, die in der Norm vom Vorgehen vorgeschlagen werden zwar umgesetzt werden, aber in der falschen Reihenfolge und keiner dokumentiert nix.
- Mein Chef unterschätzt in meinen Augen den Umfang der Arbeit (Zeit und Form). Er glaubt es reiche die SISTEMA-Berechnung mit ein paar Dokumenten (Funktionsbeschreibungen, Schaltplänen und Blockschaltbilder) zu schmücken und der Rest liegt auf der Hand. Schwer ihn vom Gegenteil zu Überzeugen. Bei den prüflisten geht er davon aus das es v.a. auf ein paar Funktionstests rausläuft. Habe das Gefühl, er verteidigt da eine Position, die er gegenüber dem Management bezogen hat, hm. Allerdings verstehe ich seine Einwände, wenn er meint, das wenn wir die Doku und Prüfungen in dem Umfang betreiben, wie mir das vorschwebt, dann würden wir unrentabel.
In diesem Zusammenhang habe ich die Frage: Für mich sieht es so aus, als benachteilige die Norm die Anlagenhersteller (und andere Hersteller von Sondermaschinen), denn selbst unsere Regalbediengeräte sind oft an den Kunden angepasst, ganz zu Schweigen vom Rest des automatisierten Lagers.


Zum PDF-Portfolio: Von einigen Herstellern habe ich zwar SISTEMA-Bibo-Bauteile, aber die Datenblätter die ich beim Hersteller kriege enthalten keine sicheheitsspezifischen Werte (MTTFd, DC, etc.). Ein Vertreter hat mir für bestimmte BT ein "inoffizielles" Dokument zugespielt, das ich offiziell nicht verwenden soll. Lustig, nicht?


Noch eine Spezialfrage: Von einer Firma haben wir sichere Logikbaugruppen und die meinten man könnte ev. die Überwachung der Aktoren über ein anderes Bauteil realisieren. Besser ein Beispiel zum Verständnis:

Sensor: Türkontakt (Kat 1)

Logik: sichere Eingänge (Kat 1)
sichere Ausgänge mit Logik (Kat 4)

Aktor: 2 Schütze in Reihe, redundant

Um beim Aktor Kat 3 od. 4 zu erreichen kann ich "direkte Überwachung" (DC:99%) verwenden. Der Hersteller der Logik meinte nun ich könnte die Aktoren auch über die SPS (nicht sicher) überwachen lassen. ==> Kat 4 ohne zusätzliche (teure) sichere Eingänge.
Wäre schön wenn das ginge, aber in meinem Augen entspricht das nicht dem Prinzipschaltbild Kat 4 und es ist auch seltsam, das da (zumindest bei SISTEMA) die sicherheitstechnischen Werte der SPS nicht verrechnet werden (oder ich häng sie einfach als Sub mit rein, trotzdem doof).


Abschliessend bleibt nur zu sagen, das Du recht hast, die Norm 100% zu erfüllen, dazu ist es zu früh. Ich denke es sollte als Prozess betrachtet werden, da man auch auf Hersteller und Kunden angewiesen ist. Ausserdem ist die Norm noch lange nicht perfekt, aber sie ist ein guter Ansatz zum methodischen Vorgehen und zum Erstellen dokumentarischer Nachweise.


Ich beginne gerade eine ambivalente Beziehung zu dieser Herausforderung aufzubauen. Hat auch was lebendiges.:wink:


Koch
 
Zuviel Werbung?
-> Hier kostenlos registrieren
C-Norm

Hallo,

für Regalbediengeräte gibt es die C-Norm EN 528. Da sind alle geforderten Sicherheitsfunktionen haarklein aufgelistet, sogar mit gefordertem PLr. Du musst zwar die Einhaltung nachweisen, sparst Dir aber eine Menge Aufwand bei der Ermittlung der Anforderungen. Die Listen sind AFAIK abschließend, d.h. Du musst Dir i.A. keine darüberhinausgehenden Gedanken mehr machen.
 
Hallo kpf

ja die meisten Anforderungen kann ich bei Regalbediengeräten (RBG) aus der 528 nehmen. Nur Schnittstellen werden da über eine Risikoanalyse gemacht, z.B. Übergabeplätze an einen Horitontalförderer.

Die Validierung muss ich aber trotz 528 komplett machen, oder?
 
Hallo,
es ist immer eine C-Norm anzuwenden wenn es eine gibt bzw. Teile davon.
Aber die Validierung der DIN EN ISO 13849-1 ist immer anzuwenden.
Aus der C-Norm kommt der PL.
 
Noch eine Spezialfrage: Von einer Firma haben wir sichere Logikbaugruppen und die meinten man könnte ev. die Überwachung der Aktoren über ein anderes Bauteil realisieren. Besser ein Beispiel zum Verständnis:

Sensor: Türkontakt (Kat 1)

Logik: sichere Eingänge (Kat 1)
sichere Ausgänge mit Logik (Kat 4)

Aktor: 2 Schütze in Reihe, redundant

Um beim Aktor Kat 3 od. 4 zu erreichen kann ich "direkte Überwachung" (DC:99%) verwenden. Der Hersteller der Logik meinte nun ich könnte die Aktoren auch über die SPS (nicht sicher) überwachen lassen. ==> Kat 4 ohne zusätzliche (teure) sichere Eingänge.
Wäre schön wenn das ginge, aber in meinem Augen entspricht das nicht dem Prinzipschaltbild Kat 4 und es ist auch seltsam, das da (zumindest bei SISTEMA) die sicherheitstechnischen Werte der SPS nicht verrechnet werden (oder ich häng sie einfach als Sub mit rein, trotzdem doof).


Hallo,
du hast einen Sensor mit Struktur Kategorie 1, eine Logik mit Struktur Kategorie 1, wie soll man denn da ohne alles in einen großen Fehlerausschluss zu erschlagen eine Struktur von Kategorie 4 erreichen? Man kann durchaus eine Diagnose über eine SPS machen, aber wenn es in einer Standard SPS passiert musst Du die Software als Sicher Software in dieser schreiben , was dies bedeutet kannst Du nachvollziehen. Auch muss Du wissen, dass man nicht nur erkennen muss sonder auf den Fehler reagieren, was bedeutet in einen sicheren Zustand zu kommen, z.B. das Einschalten verhindern nach Ausfall eines Kanals. Aber mit einer Einkanaligen Struktur und Diagnose kann man auch nicht mehr als Kategorie 1 erreichen, ob man es als Testeinrichtung sehen kann bezweifele ich, aber dazu benötigt man mehr Informationen. Bedenken muss man die Test rate die ja höher sein muss wie die Anforderungsrate.
Du hast Dich intensiv mir der Norm beschäftigt lese einfach die Anforderungen der Kategorien, dann wirst an der Hauptforderung der KAT3 schon scheitern. Einfehler sicher, wie geht das mit eine KAT1 auch wenn Du erkennst das da was faul ist die Sicherheit ist schon ausgefallen.
 
Hallo Safety,

es geht nur darum, ob man das Subsystem (SUB4) "Aktoren" auf Kat. 3 oder 4 kriegt:

(SUB1)Sensor: Kat. 1

(SUB2)sich. Eingang: Kat. 1

(SUB3)Logik+sich. Ausgang Kat. 4

jetzt wird es tricky (siehe Bild im Anhang): Der Zustand der beiden Leistungsschütze (Schütz 1 und Schütz 2), wird über 2 (nichtsichere) Eingäng der SPS eingelesen und via (nichtsicheren) Profibus an die Sicherheitslogik übermittelt. Ergibt einen Dreizeiler in S7-FUP. Also die SPS macht keine Auswertung, sondern übermittelt nur die Zustände an die Sicherheitslogik.
Die Sicherheitslogik verfügt nat über eine Monitoring-Funktion, die dort genutzt wird. "Testrate >= 100xAnforderung" ist gegeben, da man mit einer Anforderung der SF von 1/h rechnen kann.

Ziel: "direkte Überwachung" mit DC=99%
==> (SUB4) "Aktoren" Kat. 4

(Man würde in jedem Fall Kat.4 erreichen, wenn man die Zustände der Aktoren über sichere Eingänge der Sicherheitslogik einliest. Also von den Schützen je einmal auf (SUB2). Doch genau diese 2 zusätzlichen sicheren Eingänge will mein Chef einsparen.)

Die Begründung (von meinem Chef) ist das die Zuverlässigkeit der SPS keine Rolle spielt, da sie an der Auswertung nicht beteiligt ist, sondern nur die Zustände an die Sicherheitslogik weiterreicht. Er hat diesen Vorschlag von der Firma, die die Sicherheitslogik liefert, die meinten das ginge so.
Was mich stört, ist die Überlegung, das der MTTFd von SPS und Profibus nicht mit eingerechnet werden sollen.
Mein Chef Vorschlag:
(SUB4)Aktoren, Kategorie 4:

Channel1: Schütz1
Channel2: Schütz2

Meiner Meinung nach müssten durch diesen Aufbau drei zusätzliche Dinge bewertet werden:
-SPS (mit Eingängen)
-Profibus (da kein sicherer Bus)
-S7-FUP (nach V-Modell)
Wenn ich das aber so aufbaue, dann weiss ich nicht recht, wie ich die SPS da reinhänge. 2-kanalig?
Mein Vorschlag:
(SUB4)Aktoren, Kategorie 3 od 4:
(hängt von MTTFd vom Standart-Profibus-Protokoll ab, nix gefunden dazu bisher)
Channel1: Schütz1 - SPS - Profibus
Channel2: Schütz2 - SPS - Profibus

Bin auch im Kontakt mit den Leuten der Firma, die meinten, man könne das so machen wie mein Chef meint, aber ich fürchte das war eher ein Missverständniss. Aber trotzdem finde ich das eine gute Fragestellung dazu wie man denn die "direkte Überwachung" realisieren kann. Scheint mir trotz allem etwas strittig, gerade das Thema "sichere Eingänge" sparen ist in diesem Zusammenhang ein Motivator.
 

Anhänge

  • direkte Ueberw mit SPS.pdf
    45,8 KB · Aufrufe: 64
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
zunächst eine Erklärung zum DC bzw. DCavg.
Quelle BGIA Bericht 2/2008 Seite 237, also man geht davon aus das ein Ausfall der Testeinrichtung vor dem Ausfall des Kanal sehr unwahrscheinlich ist, aber nur bei KAT3 und KAT4. Lese es Dir aber mal durch dann verstehst Du das schon. Wichtig ist aber, dass ein erkennen eines Fehlers immer auch zu eine Reaktion zur Folge hat. Auch kann man in Deinem Fall durch eine Dynamische Überwachung in der SPS einen Ausfall der Testeinrichtung erkennen. Einschalten der Schütz beide Eingänge 0-Signal und beim Ausschalten wieder beide 1-Signal, aber auch die Software ist hier zu Validieren. Und sehe Dir mal das Beispiel 28 an oder auch die Hydraulischen Beispiele. Da sind z.B. Druckschalter im Diagnose Pfad also auch keine Sicheren Bauteile die dann auch mit einer nicht sicheren SPS ausgewertet werden und auch nicht berechnet. Die gesamte Prozesserkennungsdiagnose läuft auf unsicheren Systemen. Also ist es möglich, aber wie Du schon Schreibst macht es bei einem Einsatz einer Sicherheits-SPS keinen Sinn.

Auch kann ich immer noch keinen Sinn in dem Aufbau sehen, Ihr habt ein KAT1 Sensor und eine KAT1 Logik also kann da nie mehr als KAT1 werden. Warum also der Aufwand?
 
Hallo Safety

hat leider etwas länger gedauert mit dem Antworten, sry. Musste mich erstmal in die Funktionsweise der Sicherheitsbaugruppen einarbeiten.
Ausserdem noch andere Projekte. Aber ich beantworte erstmal noch einige offene Fragen.

Zitat von Safety
Auch kann ich immer noch keinen Sinn in dem Aufbau sehen, Ihr habt ein KAT1 Sensor und eine KAT1 Logik also kann da nie mehr als KAT1 werden. Warum also der Aufwand?
Für die SF "Überwachung der Schutztüre" ist nur ein PLr = b benötigt, aber die Abschaltung muss alle Achsen der Maschine betreffen (Thema: überschneidende Gefährdungsbereiche).
Es gibt noch weitere Sicherheitsfunktionen, die dieselben STO (Achse 3), SS1 (Achse 1) und SS2 (Achse 2) bewirken, z.B. den "Not-Halt" der benötigt einen PLr = e...... u.v.a.
=> also benutzt man da den gleichen Abschaltpfad, deswegen ist der in Kat.4 ausgelegt
Deswegen war die "direkte Überwachung" der Schütze so wichtig. Die macht jetzt allerdings doch die fSPS, da die Reaktion in selbiger steckt.


Jetzt soll ich prüfen ob man nicht einige der PLr = b Sicherheitsfunktionen nicht über die Standard-SPS abwickeln kann. Hab mal verlauten lassen, dass das schon geht, nur die SW-Entwicklung nach V-Modell bereitet mir da Kopfzerbrechen, bzw. die damit einhergehende Doku.

"Modulare und Strukturierte Entwicklung":
Heisst wohl für jede SF ein eigener Baustein. Momentan stecken die nötigen Parameter der Ein-Ausgänge in mehreren funktionalen Bausteinen, wird lustig das herauszuklamüsern.

SRASW od. SRESW:
Die Sprache der Wahl in S7 ist FUP = SRASW
Die wollen zwar AWL, aber dann muss ich das als SRESW betrachten, oder sehe ich das falsch?

Der Entwickler der Software fragte mich, wie die SW-Doku denn aussehen soll. Ich hab ich gesagt er soll eine Entwurfdoku machen, die SW-Spezi schreib ich schon. Der erwartet wohl, das ich den Entwurf auch noch schreibe, grmblz. Wie geht Ihr denn mit diesen Herausforderungen um?

Was mir dabei Kopfzerbrechen bereitet ist die Verwendung eines Standart PROFIBUS Protokolls. Da es kein sicheres protokoll ist, das weniger als 1% des PFH einnimmt, müsste ich es wohl mitbewerten, doch nirgends hab ich sicherheitsbezogene Werte für gefunden.



:cool:Schöne Weihnachten an alle:cool:

und ein grosses Dankeschön an die Götter dieses Forums und an die hilfsbereiten Mitglieder:rolleyes:
 
Zuletzt bearbeitet:
"Modulare und Strukturierte Entwicklung":

Hallo Koch,

zunächst mal Respekt, was Du Dir für Gedanken machst.

Bei Softwareentwicklung im Safety- und auch QM-Bereich ist
Modulare und Strukturierte Entwicklung wichtig, wenn man
überprüft wird!

Wir stellen Medizinprodukte her und werden im QM-Bereich regelmäßig
auditiert. Die Software der Endprüfstände wird dann ebenfalls
nach V-Modell geplant, erstellt und validiert.

Ich habe das V-Modell der 13849 mal "beschriftet".
Hänge es mal als Anhang zur Info an.
Die Begriffe Pflichten- und Lastenheft sind aus Sicht des Softwareerstellers.

Gruß
Tommi
 

Anhänge

  • V-Modell.JPG
    V-Modell.JPG
    46,4 KB · Aufrufe: 76
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Koch,

zunächst mal Respekt, was Du Dir für Gedanken machst.

Bei Softwareentwicklung im Safety- und auch QM-Bereich ist
Modulare und Strukturierte Entwicklung wichtig, wenn man
überprüft wird!

Wir stellen Medizinprodukte her und werden im QM-Bereich regelmäßig
auditiert. Die Software der Endprüfstände wird dann ebenfalls
nach V-Modell geplant, erstellt und validiert.

Ich habe das V-Modell der 13849 mal "beschriftet".
Hänge es mal als Anhang zur Info an.

Gruß
Tommi

Hallo,
eine Strukturierte Vorgehensweise ist beim schreiben von SRASW immer ein MUSS!
Es gibt viele Wege wie man es machen könnte aber die DIN EN 13849-1 gibt das V-Modell vor. In welcher Wirksamkeit man es anwenden muss liegt besonders auch an dem Software Werkzeug und ob es Zertifizierte Funktionsbausteine gibt. Bei einer Standard SPS ist da schon einiges mehr zu machen. Aber er hat auch nur einen PLr von b.
Ich kann nur davon abraten, die Sicherheitsfunktionen, auch wenn Sie nur PLr = b haben, mit einer Standard SPS zu erstellen. Lese dazu bitte auch die DIN EN ISO 13849-2:9.5 und DIN EN ISO 13849-1 Anhang J.
Ein weiters großes Problem ist die Ermittlung des MTTFd, Du bekommst keine Werte für die SPS. Wenn Du Dir die Anforderungen auch bei PLb ansiehst wirst Du sehr schnell erkennen, macht nur wenig Sinn hier viel Energie zu investieren. Die Zeit für die Software Erstellung, Validierung und Bewertung nach DIN EN ISO 13849-1 ist oft viel teurer als ein paar I/O mehr an der Safety-PLC. Besonders die Validierung wird hier einiges an Zeit in Anspruch nehmen.
Wir haben dieses Thema auch aufgegriffen und zeigen bei unserem Seminar wie eine Umsetzung des V-Modell anhand eines Beispiels für eine komplette Maschine aussehen kann. Aber dies mit einer Safety-PLC mit LVL-Teilmenge und Zertifizierten Funktionsbausteinen.
 
Hallo,
Für die SF "Überwachung der Schutztüre" ist nur ein PLr = b benötigt, aber die Abschaltung muss alle Achsen der Maschine betreffen (Thema: überschneidende Gefährdungsbereiche).
Es gibt noch weitere Sicherheitsfunktionen, die dieselben STO (Achse 3), SS1 (Achse 1) und SS2 (Achse 2) bewirken, z.B. den "Not-Halt" der benötigt einen PLr = e...... u.v.a.
=> also benutzt man da den gleichen Abschaltpfad, deswegen ist der in Kat.4 ausgelegt
Deswegen war die "direkte Überwachung" der Schütze so wichtig. Die macht jetzt allerdings doch die fSPS, da die Reaktion in selbiger steckt.


Das verstehe ich nun nicht!!!!
SF verriegelte trennende Schutzeinrichtung ist PLr=b und die SF Not-Halt eine PLr=e.
Wie kommt Ihr zu dieser Bewertung?
 
Danke für die Inputs und frohes Fest.

@safety

Not-Halt (mit Taster) PLr e wird in der EN 528 "Regalbediengeräte - Sicherheitsanforderungen" vorgegeben, wenn man eine elektronische Steuerung verwendet. Wir nehmen für die Sicherheitsfunktionen eine LPSDO von Phoenix (obwohl ich lieber eine fSPS gehabt hätte, aber auf den frisch ausgelernten hört ja keiner), diese LPSDO muss man auch als komplexe Logik betrachten.
Bei der Realisierung ohne komplexe Logik könnte man PLr c nehmen, hab ich mir auch schon überlegt, dann bräuchte man aber einen Hilfsschütz dazwischen für die Kontaktvervielfältigung, denk ich. So könnte man diesen Abschaltpfad an der Komplexen Logik vorbei legen.

Die Überwachung der Türe muss nach der EN 528 ein PLr b haben. Dabei ist die Tür allerdings verriegelt und über ein Schlüsselsystem wird die Maschine abgeschaltet, dann erst wird mit demselben Schlüssel die Tür geöffnet.


@Tommi

Ja bei Sicherheit muss man sich diese Gedanken machen, bzw aus der Norm lesen. Die Sache ist, es kommt nicht drauf an ob man überprüft wird, denn man wird überprüft, wenn einer von deiner Maschine verletzt wird. Und dann schauen die schon nach, wie man das entwickelt hat.
Danke noch für das beschriftete V-Modell. Habs schon ausgepackt:rolleyes:

Jetzt gib es gleich mehr Geschenke...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie schon geschrieben ist es für mich nicht nachvollziehbar wie man eine Verriegelte Trennende Schutzeinrichtung in PLb haben kann und dann einen Not-Halt in PLe.

Begründung:
Häufigkeit und/oder Dauer der Gefährdungsexposition F1 und F2, kann bei Not-Halt nie höher sein als bei der Schutztür.
Wenn es wirklich so sein sollte, ist die Anforderung der DIN EN ISO 13850 4.1.2 die Not-Halt-Funktion darf nicht als Ersatz für Schutzmaßnahmen oder andere Sicherheitsfunktionen verwendet werden, aber sollte als ergänzende Schutzmaßnahme konzipiert sein. Die Not-Halt-Funktion darf die Wirksamkeit von Schutzeinrichtungen oder von Einrichtungen mit anderen Sicherheitsfunktionen nicht beeinträchtigen, nicht erfüllt.

Jetzt mal in deutsch, der Werker wird beim öffnen der Verriegelten Trennenden Schutzeinrichtung mit Zuhaltung einem Risiko ausgesetzt das nur PLb entspricht und bei Not-Halt kommt dann PLe zum Tragen? Egal wie man es betrachtet die Anforderung der Situation Not-Halt wird wohl nie Häufig sein.

Wenn es wirklich eine C-Norm gibt die so was fordert, würde mich sehr stark die Begründung interessieren.
 
Zitat von Safety
Wie schon geschrieben ist es für mich nicht nachvollziehbar wie man eine Verriegelte Trennende Schutzeinrichtung in PLb haben kann und dann einen Not-Halt in PLe.
Wenn ich ehrlich bin, find ich das auch seltsam..... aber inzwischen hab ich mir das etwas zurechtgedacht. Kann nur auf die entsprechende Norm zurückgreifen, und habe keine genaueren Begründungen von den Normenerstellern. Ich versuche mal darzulegen, was meiner Meinung nach sinnig ist, und womit ich ein logisches Problem habe.

Der Haken dazu liegt in der Begründung zur PLr Anforderung für den "Not-Halt" begraben. Zitat EN 528 Tabelle C.2 Nr. 3 "Not-Halt-Funktion" in Spalte Kommentare:
"Wenn einzelne Einrichtungen mit elektronischen Teilen (z.B. Not-Halt-Relais) für das Not-Halt-System verwendet werden, müssen diese PLr c mit permanenter Überwachung entsprechen.
Wenn elektronische Einrichtungen das einzige Mittel sind um Not-Halt-Befehle zu übertragen oder wenn programmierbare Steuerungen im Not-Halt-System enthalten sind, muss das System PLr e entsprechen."

==>Da nur elektronisch (via Bus und DI/O) übertragen wird muss ich von PLr e ausgehen (Ich denke die Verwendung von elektromechanischen Not-Halt-Tastern zählt noch nicht als "Übertragung", wenn doch, dann belehrt mich bitte eines besseren). Also kann ich auch gleich bei der LPSDO bleiben, die als Mini-SPS von mir eingeschätzt wird.

Grundsätzlich gehe ich davon aus, dass die Normenhirsche auf einen PLr c kommen, was die Gefährdung einer Person in einem Hochregallager bei Automatikbetrieb angeht (siehe Bild im Anhang). Bei Eintritt in die Regalgasse steht man ein paar Meter vor dem Wirkbreich des Regalbediengerätes und dieses kann man nicht übersehen, oder -hören und wenn man öfter als einmal pro Tag in die Regalgasse muss, dann stimmt eh was nicht. Soweit nachvollziehbar....
Aber wie kommen die darauf von c auf e hochzustufen, nur weil man rein elektronisch arbeitet?? (c auf d könnt ich ja noch akzeptieren, damit man mind. Kat.2, besser Kat.3 verwenden muss).

Zur Schutztürüberwachung muss ich den Systemaufbau genauer erklären, denn ich denke man kann es als einen Kanal eines redundanten Systems betrachten:
Schlüsselschalter Betriebsartenwahl (PLr c) kann nur in Stellung "Hand"=0 abgezogen werden. Dann sollte das Regalbediengerät schon stehen und man kann es nur im Tippbetrieb von einer Bedienstation mit gesteckten Schlüssel (es gibt nur einen) fahren. Mit demselben Schlüssel wird die Tür aufgeschlossen, Positionsschalter an der Tür (PLr b).
Entweder beide Kanäle versagen, dann war es aber auch ~Kat. 3
oder jemand bricht das Schloss auf, dann war es eben nur Kat. b, aber mit weniger Aufwand lässt sich über den Schutzzaun klettern.


Ich hoffe nun ist es nachvollziehbar geworden.
Was mich brennend interessieren würde ist eine sinnvolle Begründung für die Hochstufung von PLr c auf PLr e wegen rein elektronische Übertragung, bzw. Verwendung einer SPS.
 
Hallo,
wie geschrieben für mich nicht nachvollziehbar, wieso man mit einer Sicherheits-SPS PLr=e benötigt, ansonsten PLr=b. Wenn man die DINJ EN ISO 13849-1 und -2 mit den Anforderungen an die Erstellung für SRASW erfüllt ist dies genau so sicher wenn nicht besser, da viele Querverdrahtuhngen mit entsprechende Fehlerausschlüssen entfallen und man eine Sichere Busleitung dafür hat.
Zum Verriegelungsschalter an der Tür, Du machst da meiner Meinung nach einen Denkfehler.
Zuerst muss man die Spezifikation der SF mal genau definieren. Der Schalter hat die Aufgabe beim öffnen in Automatik die Antrieb sicher abzuschalten und den Wiederanlauf zu verhindern.
Das ist die Ursprüngliche Sicherheitsfunktion, hier muss man nach Anhang A DIN EN ISO 13849-1 eine Risikoeinschätzung machen. Bei Plr=b sind da kaum Gefährdungen und die Eintrittswahrscheinlichkeit ist sehr gering. Kann ich mir fast nicht vorstellen aber gut. In den C-Normen steht meist, abhängig von tatsächlichen Gegebenheiten und Risikobeurteilung ist die technische Schutzmaßnahme mit ihrem Anteil an der Risikominderung zu bewerten. Es sind also Mindestanforderungen.
Originalsatz:
[FONT=&quot]Sofern in dieser Norm nicht anderweitig festgelegt oder durch die Risikobeurteilung für sicherheitsbezogene Teile von Steuersystemen angezeigt, die eine Beurteilung des Beitrags der sicherheitsbezogenen Teile der Steuerung zur Risikominderung beinhalten sollte, gelten die nachfolgend aufgeführten Mindestanforderungen:[/FONT]

Bei der Sonderbetriebsart hat Du jetzt wieder mehrere SF, Umschalten auf Zustimmbetrieb, Umschalten auf sichere Geschwindigkeit, der Verrigelungsschalter ist hier nicht enthalten, Du überbrückst diesen mit einer anderen SF die dann genau so sicher sein muss, deshalb auch das verminderte Risiko durch die Geschwindigkeit.
Sehe Dir mal das Beispiel 21 in BGIA Bericht und die SISTEMA Berechnung dazu an. Hier erkennst Du, es wird alles einzeln gesehen.
Wenn ich was Falschverstanden habe, gib mir Bescheid.
 
Zurück
Oben