Diagnosedeckungsgrad nach DIN EN ISO 13849-1 Anhang E

Safety

Level-3
Beiträge
2.013
Reaktionspunkte
826
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Tommi,
ja klar Du kommst gleich mit dem schwierigsten Thema.
Spaß beiseite DC kommt ohne Gewähr ist meine Interpretation:
Ich fange mal mit den Sensoren an
Anhang E
1. Zyklischer Testimpuls durch Dynamische Änderung der Eingangssignale
Was bedeutet das, hier steht im BGIA Report 2/2008:
Periodische Generierung eines Signalwechsels mit Überwachung des Ergebnisses.
Sowas machen wir z.B. mit den Taktsignalen, die man an unsere Steuerung ausgeben kann.
Aber oft werden die Maßnahmen in der entsprechenden Betriebsanleitung angeben. So dass man hier nicht lange überlegen muss. Was bei diesem Punkt fehlt ist die Erkennung von Querschlüssen.
Aber dies kommt dann noch später.

2. Plausibilitätsprüfung z.B. Verwendung der Schließer Öffner Kontakte von zwangsgeführten Relais.
Dürfte klar sein.
3. Kreuzvergleich von Eingängen ohne Dynamische Testung
Anmerkung der Norm: 0-99% Abhängig davon wie oft ein Signalwechsel durch die Anwendung erfolgt.

Dies ist z.B. so bei Sicherheitsrelais ohne Taktsignale, hier werden zwei Verschiedene Spannungen auf die Kanäle gegeben und im Relais getestet ob die Kanäle gleiche oder eben ungleiche Zustände haben.
Man kann durch diese Maßnahme einen DC von 99% erreichen, wenn eine Anforderung der SF auch in entsprechenden Zeittakten passiert. Eine Anforderung die nur einmal im Jahr kommt kann nicht so gut sein wie eine die einmal alle Stunde kommt. Da die erste einmal pro Jahr eine Fehler bzw. eine Fehleranhäufung erst erkennt wenn alles zu spät ist. Der Abschnitt 4.5.4 geht von mindestens einmal pro Jahr aus. Was kann man z.B. bei Not-Halt SF machen, die wahrscheinlich nur sehr selten benutzt werden, man könnte eine Auslösung pro Monat zum Test in der Betriebsanleitung vorschreiben.
Also bei verriegelnden Trenneden Schutzeinrichtungen, Schutztüren oder Klappen kann man von einer Anforderungsrate ausgehen die entsprechend hoch ist und somit auch eine DC von 99% zulässt. Wenn eine Tür nur einmal im Jahr aufgemacht wird kann man diesen auch durch andere Maßnahmen absichern siehe hierzu DIN EN 953.
Geht dann bald weiter!
 
Hallo Dieter,

danke für Deine Ausführungen.

Hatte und habe z.Zt. keine Zeit, es sorfältig zu lesen.
Sobald ich Zeit habe, melde ich mich.

Gruß
Thomas
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also weiter:
Immer noch Eingabeeinheit.
Kreuzvergleich von Eingangssignalen mit dynamischem Test, wenn Kurzschlüsse nicht bemerkt werden können (bei Mehrfach-Ein/Ausgängen) DC 90%
Die IFA-BGIA schreibt zu diesem Thema:
Mit Dynamisierung ohne hochwertige Fehlererkennung.
Sowas ist dann wenn man eine Querschluss nicht erkannt wird also eine weniger gute Fehlererkennung. Hier finde ich den DC von 90% also mittel sehr hoch angesetzt.
Kreuzvergleich von Eingangssignalen mit unmittelbaren und Zwischenergebnis in der Logik und zeitliche und logische Programmablaufüberwachung und Erkennung statischer Ausfälle und Kurzschlüsse (bei Mehrfach-Ein/Ausgängen) DC 99%
BGIA:
Elektrik :
Kreuzvergleich von Eingängen und Ausgängen mit Kurzschlusserkennung und Erkennung statischer Fehler z.B. mithilfe von Sicherheitsbausteinen.
(Programmierbare) Elektronik
Kreuzvergleich von Signalen und zwischenwerten mit Kurzschlusserkennung. Erkennung statischer Fehler und zeitliche und logische Programmablaufüberwachung: Dynamischer Kreuzvergleich unabhängig gewonnener Stellungs,- oder Geschwindigkeitsinformationen
Beispiel: Verriegelungsschalter mit Integrierter Sicherheitslogik, also OSSD Ein,- und Ausgängen die alle Fehler erkennen und die Kanalüberwachung übernimmt die Sicherheitssteuerung mit einem Zertifiziertem Baustein. PSENcode mit PNOZMulti
Oder eine Abfrage der Stellung vom Ventilschieber, da aber bei diesen Ventilen meist keine zwangsöffnende Diagnoseschalter angebracht sind müssen diese Zyklisch Überwacht werden also bei jedem Ein und Ausschalten eine Plausibilitätsprüfung der Signale „Ausgang Ventil“ und „Eingang Diagnose Sensor“.
Oder Einlesen von zwei Drehzahlsignalen und entsprechendem Vergleich in einer Sicherheitslogik PSEN sigma S30 oder PNOZmulti mit Erweiterungsbaustein. Hier wieder zertifizierte Bausteine und Produkte bevorzugt einsetzte macht vieles einfacher.

Eingabeeinheiten immer noch nicht komplett aber jetzt sollten wir mal Diskutieren.
 
Hallo Dieter,

kann man die Tabelle eigentlich unterteilen?

1. Die Maßnahmen, die der Maschinenhersteller erfüllen muß.

2. Die Maßnahmen, die der Sicherheitsbauteilehersteller erfüllen muß.

Das würde die Sache vereinfachen. Ich weiß nicht, ob ich mich da
richtig ausdrücke?
Kreuzvergleich ist doch eigentlich "Pilz-Sache", oder? Dann muss der
Maschinenhersteller doch nur nach Pilz-Vorgabe verdrahten und hat
sowieso schon einen PL-Wert von Euch für das Bauteil.

Ich habe das noch nie gewählt oder ich habe was falsch gemacht.

Indirekte Überwachung... kommt bei Eingabe- und Ausgabeeinheiten vor, einmal für Antriebe und einmal für Aktoren.:confused:


Gruß
Tommi
 
Hallo Tommi,
wenn Du zertifizierte und Baumustergeprüfte Lösungen einsetzt hat doch der Hersteller das alles schon getan!
Also hier die Datenblätter und Betriebsanleitungen beachten dann hat man nach einer Überprüfung die Grundlegenden und Bewährten Sicherheitsprinzipien, CCF die angegebene Kategorie und den entsprechenden PL eingehalten. Wann benötigt man nun diese Tabelle?
Z.B. wenn man an den Ausgängen der Multi Pneumatische Aktoren hat die dann mit einer entsprechenden Diagnose ausgestattet werden müssen. Hier hilft die Tabelle den DC abzuschätzen.
Oder wenn man was selbst basteln will.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wann benötigt man nun diese Tabelle?

Hallo Dieter,

ich habe mal die Maßnahmen der Tabelle E1 herausgesucht, welche meiner Meinung nach für Maschinenbauer wichtig sind.

Sie sind im Anhang grün umrandet.

Die Tabelle wird meiner Meinung nach für den SPS-Programmierer hauptsächlich für Stellglieder benötigt.

Einige ähneln sich auch sehr.

Schönen Sonntag noch.

Gruß
Tommi
 

Anhänge

  • DINENISO13849_1_AnhangE.pdf
    966,6 KB · Aufrufe: 212
Hallo Tommi,

Bei der Logik würde ich den Punkt "Verarbeitungseinheit: Selbsttest durch Software" nicht für den Maschinenbauer markieren. Letztendlich wäre das ein Punkt für den Hersteller, den internen Programmablauf abzusichern. Der Maschinenbauer setzt nur die auszuführenden Abhängigkeiten im Programmablauf ein.

Ein anderer interessanter Punkt ist die Handhabung bei mehreren zutreffenden Punkten. Hier könnte es zwei Verfahren geben. Beim ersten wird der maximale Wert genommen, beim zweiten wird gemittelt.

Nach meinem Empfinden ist es zulässig, den Punkt mit dem maximalen Wert zu berücksichtigen, weil zusätzlich eine Anforderung erfüllt wird. Im Umkehrschluss wird durch eine zusätzliche Maßnahme mit einem geringeren Wert der Gesamtwert nicht reduziert.

Aber wie schon gesagt, es gibt hier kein Schwarz und Weiß, sondern ein helleres und ein dunkleres Grau.

So, Essen ist fertig ;-)
Harald.
 
Hallo Harald,

Danke für Deine Rückmeldung. Bei dem Punkt war ich mir auch nicht
sicher.
Aber man kann als Maschinenbauer gut auf ihn verzichten, da man die Software ja zusätzlich noch nach V-Modell bewerten soll.

Wir waren heute auf dem Stiftsmarkt in Bielefeld-Schildesche essen,
ich wünsche Dir Guten Appetit gehabt zu haben. ;)

Gruß
Tommi
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich nochmal,

<Zitat>
Aber man kann als Maschinenbauer gut auf ihn verzichten, da man die Software ja zusätzlich noch nach V-Modell bewerten soll.
</Zitat>
Da stolpere ich etwas drüber, will aber nicht zu stark darauf herum reiten.

Die Software soll nach V-Modell entwickelt werden und besagt eigentlich nichts anderes als, von Top-down planen (Implementation und Test) und von Bottom-up implementieren und testen. Das gilt dann sowohl für die Software des Herstellers als auch für die Anwendungssoftware durch den Maschinenbauer. Also, nur eine Bewertung nach V-Modell ist IMHO nicht möglich.

Die Verwendung eines V-Modells für die Software Entwicklung ist nicht bindend vorgeschrieben. Es kann auch ein anderes Modell benutzt werden, soweit Anforderungen, Realisierungen, Testabläufe und Testdurchführungen nachvollziehbar dokumentiert werden. Das ist der eigentliche Haken, wo sich viele schwer tun (so viel Schreibarbeit).

<Offtopic>
Nach Forumstreffen und Geburtstagsfeier haben wir heute mal zu Hause gegessen ;-) Jetzt ist gerade mal Zeit für ein bischen Arbeit am Computer, bevor es mit dem nächsten Termin weiter geht. Morgen kann ich dann wieder in Ruhe arbeiten ;-)
</Offtopic>

Bis dann
Harald.
 
Ich nochmal,

<Zitat>
Aber man kann als Maschinenbauer gut auf ihn verzichten, da man die Software ja zusätzlich noch nach V-Modell bewerten soll.
</Zitat>
Da stolpere ich etwas drüber, will aber nicht zu stark darauf herum reiten.

Die Software soll nach V-Modell entwickelt werden und besagt eigentlich nichts anderes als, von Top-down planen (Implementation und Test) und von Bottom-up implementieren und testen. Das gilt dann sowohl für die Software des Herstellers als auch für die Anwendungssoftware durch den Maschinenbauer. Also, nur eine Bewertung nach V-Modell ist IMHO nicht möglich.

Die Verwendung eines V-Modells für die Software Entwicklung ist nicht bindend vorgeschrieben. Es kann auch ein anderes Modell benutzt werden, soweit Anforderungen, Realisierungen, Testabläufe und Testdurchführungen nachvollziehbar dokumentiert werden. Das ist der eigentliche Haken, wo sich viele schwer tun (so viel Schreibarbeit).

<Offtopic>
Nach Forumstreffen und Geburtstagsfeier haben wir heute mal zu Hause gegessen ;-) Jetzt ist gerade mal Zeit für ein bischen Arbeit am Computer, bevor es mit dem nächsten Termin weiter geht. Morgen kann ich dann wieder in Ruhe arbeiten ;-)
</Offtopic>

Bis dann
Harald.

Hallo,
Normen muss man ja bekanntlich nicht anwenden, aber wenn dann ist auch der Abschnitt 4.6 der DIN EN ISO 13849-1 im Normativenbereich dieser Norm.

Diese Betrachtung der Software ist sehr interessant, aber hierzu sollten wir eventuell ein eigenes Thema eröffnen. Es wird in vielen Fällen nichts gemacht, noch nicht mal eine ordentliche Spezifikation.
Durch das mehr oder weniger gute Werkzeug zur Softwareerstellung wird dann auch der Rahmen vorgegeben den man dann umsetzten muss.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Tommi,
bei den Eingabeeinheiten sind meiner Meinung nach alle relevant für den Maschinenbau. Siehe Beiträge weiter oben.
Bei den Logikeinheiten hier ist es wieder sehr abhängig vom System, wenn man eine Sicherheits-SPS benutzt wie z.B. PNOZmulti oder PSS4000 dann ist schon viel vorgegeben und die zugehörigen Zertifizierten Bausteine nehmen einem vieles ab. So das nur wenig Punkte greifen.
Es ist doch auch in den meisten Fällen so dass die Logik in Verbindung mit den Eingabeeinheiten und den Ausgabeeinheiten die Maßnahme bilden. Aber das was Du da markiert hast sehe ich ähnlich.
Den Punkt Verarbeitungseinheiten: Selbsttest durch die Software. Sehe ich wie hapr.
Bei den Ausgabeeinheiten sehe ich wieder Möglichkeiten dass alle Punkte
für den Maschinenbau relevant sein könnten.
 
Hallo Dieter,

ich habe mir Deine obigen Ausführungen mal angesehen.

Bei den Eingabeeinheiten gebe ich Dir recht, die können irgendwie alle
für den Maschinenbauer relevant sein.

Harald (hapr) hat auch recht mit seiner Betrachtung zu "Selbsttest durch Software".

Bei den Ausgaben habe ich noch nicht den genauen Unterschied bzw. die
Abgrenzung zwischen "Kreuzvergleich" und "redundantem Abschaltpfad" verstanden.
Vielleicht kannst Du da helfen ;).

Ich habe mal Schaltungsbeispiele aus dem Handbuch PNOZmulti angehängt und Kategorien bzw. Diagnosedeckungsgrade eingetragen.

Bitte um Info, ob das so sein kann.

Danke und schönen Feiertag noch...

Gruß
Tommi
 

Anhänge

  • Eingangsbeschaltung_PNOZmulti.jpg
    Eingangsbeschaltung_PNOZmulti.jpg
    48,9 KB · Aufrufe: 95
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Tommi,

mal kurz meine Interpretation (es ist ja wieder kurz vor Mittagessen fertig ;-) )

Redundanter Abschaltweg:
Die Sicherheitsfunktion wird in zwei unabhängigen Pfaden ausgeführt. Es gibt keine Information, die zwischen diesen beiden Pfaden ausgetauscht und bewertet wird. Ein Fehler in einem Pfad wird nicht erkannt. Dann ist im Fehlerfall die Sicherheitsfunktion nur noch einkanalig.

Kreuzvergleich:
Die Sicherheitsfunktion wird ebenfalls in zwei Pfaden ausgeführt. Zusätzlich werden Informationen der Zwischenergebnisse zwischen den Verarbeitungseinheiten der Pfade ausgetauscht und bewertet. Bei einem Fehler in einem Pfad wird eine Fehlerhafte Information vom anderen Pfad erkannt und führt zu einer dauerhaften Abschaltung (Fehlerhaltung), auch wenn die Eingangsinformation wieder in Ordnung ist.

Ich hoffe, dass ich Dir auf die Schnelle mit den Worten etwas Licht bringen konnte.

Essen ist gerade fertig ;-)
Harald.
 
Ich nochmal,

Hier die Grafik für Kat. 4 Architektur aus der EN ISO 13849-1. Für den Kreuzvergleich ist die Verbindung C zwischen den beiden Logikeinheiten (L1, L2) zuständig.


attachment.php

IMHO ist der Kreuzvergleich ein wesentlicher Bestandteil eines Sicherheitsauswerters oder einer Sicherheitssteuerung. Daher ist der Kreuzvergleich meines Erachtens nicht relevant für die allgemeine Maschinensteuerung, bei der Sensoren (I1, I2) und Aktoren (O1, O2) allerdings einfach redundant angewendet werden können.

Bis dann
Harald.
 

Anhänge

  • Kat 4 Architektur.jpg
    Kat 4 Architektur.jpg
    5,1 KB · Aufrufe: 112
Hallo Tommi,
Schaltung links oben= Kat B oder 1, PLb oder c, DC nicht relevant
Schaltung links unten = Kat B oder 1,PLb oder c, DC nicht relevant
Schaltung rechts oben Kat b bis 3, PLb bis d, DC für diesen Ausschnitt max. 60%
Begründung: Es wird ein schwerwiegender Fehler nicht erkannt, Querschluss zwischen den Kanälen. Würde ich auch nur für die Handlung im Notfall empfehlen. Kategorie 3 erfüllbar, da auch bei einem Fehler die Sicherheitsfunktion erhalten bleibt. Aber für diese Schaltung sprechen nur Wirtschaftliche Gründe.
Schaltung rechts unten Kat B bis 4, PLb bis e für diesen Ausschnitt DC 99%.


Ich gehe bei diesen Bewertungen von PNOZmulti oder mini aus mit entsprechender Auswertung im Programm.
 
IMHO ist der Kreuzvergleich ein wesentlicher Bestandteil eines Sicherheitsauswerters oder einer Sicherheitssteuerung. Daher ist der Kreuzvergleich meines Erachtens nicht relevant für die allgemeine Maschinensteuerung, bei der Sensoren (I1, I2) und Aktoren (O1, O2) allerdings einfach redundant angewendet werden können.

Hallo Harald,

Danke für die Antwort während des Suppenkomas.

Was meinst Du mit "allgemeiner Maschinensteuerung"?

Mir fällt gerade auf, daß Kreuzvergleich in der DC-Tabelle für Logikeinheiten gar nicht auftaucht.

Gruß
Tommi
 
Zuletzt bearbeitet:
Hallo,
Schaltung rechts oben Kat b bis 3, PLb bis d, DC für diesen Ausschnitt max. 60%
Begründung: Es wird ein schwerwiegender Fehler nicht erkannt, Querschluss zwischen den Kanälen. Würde ich auch nur für die Handlung im Notfall empfehlen. Kategorie 3 erfüllbar, da auch bei einem Fehler die Sicherheitsfunktion erhalten bleibt. Aber für diese Schaltung sprechen nur Wirtschaftliche Gründe.
Hier habe ich mal eine FMEA gemacht mit verschiedenen Szenarien und komme auf 75% bzw. 80% DC. Das kann bei der Berechnung mit z.B. Pascal oder Sistema helfen da hier mit DC zwischenwerten gerechnet wird. Also liege ich mit meiner konservativen Schätzung von 60% auf der sicheren Seite.
 
Zurück
Oben