Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 5 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 43

Thema: Sicherheitsrelevante Software für Maschinen

  1. #1
    Registriert seit
    01.06.2008
    Ort
    Ostwestfalen
    Beiträge
    1.867
    Danke
    405
    Erhielt 472 Danke für 375 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat von Safety vom 25.09.2011:
    Diese Betrachtung der Software ist sehr interessant, aber hierzu sollten wir eventuell ein eigenes Thema eröffnen
    Hallo zusammen,

    ich eröffne hiermit das o.g. Thema.

    neben der Hardware-Betrachtung mit Sistema muss man ja auch noch
    die Software (z.B. eines PNOZmulti) validieren.
    Das ist, wie auch schon gesagt wurde, viel Schreibarbeit.

    Mich würde mal interessieren, wie ihr das macht:

    Jeden Not-Halt, jede Schutztür und jedes Lichtgitter incl. Quittierung zu testen, ist sicherlich selbstverständlich. Hier muss man jetzt "nur" noch, vielleicht im Gegensatz zu früher, dokumentieren. Nach Norm vor und nach der Programmierung.

    Aber wie weit treibt ihr das mit den Modultests?
    Macht ihr wirklich mit einem Draht eine Brücke zwischen den zwei Kanälen eines Schutztürschalters oder klemmt ihr einen Draht eines Kanales ab um zu sehen, was passiert? Und das dann bei jeder Tür und jedem NOT-HALT Schalter?

    Wir bei uns diskutieren gerade darüber.

    Gibt es diesbezügliche Hilfen der Steuerungshersteller?

    Sollen wir hier im Forum mal Checklisten erstellen?

    Ich bin gespannt auf Antworten.

    Gruß
    Tommi
    Zitieren Zitieren Sicherheitsrelevante Software für Maschinen  

  2. #2
    Registriert seit
    14.06.2008
    Ort
    Pirmasens
    Beiträge
    1.794
    Danke
    94
    Erhielt 727 Danke für 457 Beiträge

    Standard

    Hallo,
    wir sollten mal versuchen die verschiedenen Punkte des vereinfachten V-Model durch zugehen.
    Also der erste Punkt wäre die Spezifikation, aber da Du nach Funktionstests und was man alles testen muss gefragt fast. Werde ich zunächst mal hierzu meine Meinung abgegeben, also meine Interpretation dieser Norm.
    Man muss zunächst mal feststellen mit welchen Systemen und Komponenten man eine Sicherheitsfunktion realisiert wird. Fangen wir mal mit der Software an, wenn man ein Zertifiziertes System verwendet also SPS, wurden die Tests wie Querschluss und Kanalfehler und so weiter alle durch geführt und auch bei einer Baumusterprüfung bestätigt. Wenn dies auf die Software bezieht, also konsequent, wenn möglich, mit Zertifizierten und geprüften Funktionsbausteinen arbeitet, dann muss ich viele Grundlegenden Tests und Versuch nicht machen da es ja im Detail schon vom Hersteller gemacht wurde und der muss auch durch entsprechende Qualitätskontrollen immer einen gleichbleibenden Stand bestätigen. Also was muss ich jetzt nachweisen. Wie komme ich zu meinem System, warum habe ich es so angeschlossen und warum habe ich diesen Funktionsbaustein ausgesucht. Also ausgehend von der Software-Spezifikation beschreiben wie ich zu allem komme, z.B. Schaltungsbeispiele vom Hersteller Datenblätter und Betriebsanleitungen konsequent umsetzten. Dann muss ich nach meiner Meinung nur noch Nachweisen das mein realer Anschluss auch stimmt. I/O Prüfungen und die Reaktionen bis hin zum messen der Spannungen am z.B. STO Eingang der Umrichter sind selbst verständlich. Anders sieht es bei selbst gestrickten Lösungen in Software wie im Hardwarebereich aus.
    Aufzeigen wie man zu der Lösung kommt und nachweisen das es auch so ausgeführt reicht nach meiner Meinung, Kurschlüsse, Querschlüsse nur wenn ich den Nachweis nicht führen könnte und bei Eigenkreationen.

  3. Folgende 2 Benutzer sagen Danke zu Safety für den nützlichen Beitrag:

    rostiger Nagel (23.10.2011),stevenn (25.03.2015)

  4. #3
    Registriert seit
    14.06.2008
    Ort
    Pirmasens
    Beiträge
    1.794
    Danke
    94
    Erhielt 727 Danke für 457 Beiträge

    Standard

    Hallo,
    ich konkretisiere das ganze mal, wenn ich ein Gerät wie eine zertifizierte Sicherheits-SPS kaufe muss ich davon ausgehen das die mir zugesicherten Funktionen nach dem angegeben Daten wie SIL/PL/Kategorie usw. eingehalten werden. Ich kann eventuell die Querschlusserkennung noch selbst testen aber die meisten Fehlererkennungssysteme kenne ich nicht und brauche ich auch nicht zu kennen. Also muss ich versuchen die von mir machbaren Fehler zu vermeiden.
    Wenn ich z.B. einen Verriegelungsschalter mit potenzialfreien zwangsöffnenden Kontakten an die Eingänge der PNOZmulti oder Mini anschließe dann gebe ich in der Software an Eingang 1 erwartet Testtakt 0, Eingang 2 Testtakt 1, alles andere wir vom System erkannt und führt zu einem sicheren Zustand. Also was könnten wir falsch machen, einen Testtakt direkt auf den Eingang, also eine Fehlverdrahtung, würden wir erkennen bei Auslösen des Verriegelungsschalter da ein Kanalfehler entstehen würde. Bei zweimal diesen Fehler würden die Eingänge nicht auf 0-Signal gehen.
    So dann sollten wir uns aber auf das V-Model stürzen.
    Geändert von Safety (23.10.2011 um 17:54 Uhr)

  5. Folgende 3 Benutzer sagen Danke zu Safety für den nützlichen Beitrag:

    hapr (23.10.2011),rostiger Nagel (23.10.2011),Tommi (24.10.2011)

  6. #4
    Registriert seit
    30.03.2010
    Ort
    OWL
    Beiträge
    155
    Danke
    56
    Erhielt 64 Danke für 61 Beiträge

    Standard

    Hallo,
    im Grunde genommen hat Safety ja schon alles gesagt. Der Maschinen- oder Anlagenbauer muss bei Sicherheitsbauteilen von der Funktionalen Sicherheit ausgehen. Dafür fordert er vom Hersteller zum Beispiel die EG-Baumusterprüfbescheinigungen. Eine reine EG-Konformitätserklärung dürfte eventuell ausreichen, wenn dort auf Normen und die EG-Baumusterprüfung angegeben ist. Aber eine EG-Konformitätserklärung ohne Angaben einer EG-Bumusterprüfung darf IMHO nicht ausreichen.

    Zurück zur Software:
    Auch für den Maschinen- oder Anlagenbauer kann das V-Modell verwendet werden:
    1.
    Spezifikation, Planung Systemtest (Was muss abgesichert werden?; Wie kann ich die Absicherung prüfen?)
    2.
    Design, Planung Integrationstest (Was müssen einzelne Funktion erfüllen?, Wie kann ich die Funktion prüfen?)
    3.
    Realisierung, Planung Modultest (Codieren der Sicherheitsfunktionen, Wie kann ich alle Verzweigungswege der SW prüfen?)
    4.
    Durchführung der Modultests (Simulation der Eingangsinformationen und Zwischenergebnisse)
    5.
    Durchführung der Integrationstests (Prüfen der Komponente in einer Testumgebung oder im unvollständigem System)
    6.
    Durchführung Systemtest (Prüfen des kompletten Systems mit allen Beingungen)

    So, schon wieder Essen fertig
    Harald.

  7. #5
    Registriert seit
    14.06.2008
    Ort
    Pirmasens
    Beiträge
    1.794
    Danke
    94
    Erhielt 727 Danke für 457 Beiträge

    Standard

    Die Sepzifikation einer Sicherheitsfuntkion ist sehr wichitg, da hier von alles ausgeht.
    Leider wird in der realität meist nichts gemacht und der Programmierer muss sich das alles aus den Fingern saugen, oft wird erst bei der IB angefangen sich Gedanken zumachen sowas kann nur zu Fehlern führen. Anbei ein Beispiel wie eine Spezifikation aussehen könnte.


    SF1
    Erforderlicher PLr=d Realiserung in mindestens Kategorie 3
    Wenn: Tür1 geöffnet
    Dann: Antrieb sicherheitsgerichetet Stopp
    Sicherer Zustand: Beibehaltung der sicheren Energietrennung STO bis Tür1 geschlossen und
    manuelle Rückstellfunktion betätig

    Beim Öffnen der Tür 1, verriegelte trennende Schutzeinrichtung mit Verriegelungsschalter PSENcs 4.2p -B1, angeschlossen an PNOZmulti Eingang-a1:IM0 Kanal 1 und Eingang –a1:IM1 Kanal 2, werden der Sicherheitsausgang -a1o0 und somit die Schütze -K1 und
    -K2 abgeschaltet. Der Sensor PSENcs 4.2 entspricht PLe und Kategorie 4, Querschlusserkennung im Eingangskreis nicht nötig da Fehlererkennung im Sensor.

    Antriebsmotor –M1: Stillsetzen der gefahrbringenden Bewegungen, STO - sicher abgeschaltetes Moment. Unverzügliches Abschalten STO, Stopp-Kategorie 0 nach DIN EN 60204-1.

    Unter Anwendung DIN EN ISO 13855 Abschnitt 9 ist sichergestellt, dass beim Öffnen einer der verriegelten trennenden Schutzeinrichtungen kein Gefährdungsbereich erreicht werden kann, bevor die Maschinenbewegungen gestoppt sind. Die Stoppzeit ohne die Programmlaufzeit beträgt 0,4 Sekunden. Es muss sichergestellt werden, dass auch mit Programm in PNOZmuti -a1 eine maximale Stoppzeit von 0,8 Sekunden nicht überschritten wird.

    Die Schütze besitzen zur Diagnose Mirrorkontakte gemäß DIN EN 60947-5-1 Anhang F (Rücklesekontakte) -K1:21/22, -K2:21/22, die in Reihe geschaltet sind; diese gehen auf PNOZmuti -a1 Eingang -a1:IM2 und müssen entsprechend in der Software ausgewertet werden.

    Schutz gegen unerwarteten Wiederanlauf nach Wiederherstellung der Energieversorgung muss softwareseitig in –a1 sichergestellt werden

    Die Abschaltung muss solange aufrechet erhalten bleiben, bis die Tür 1 geschlossen ist und somit dier Verriegelungsschalter PSENcs 4.2 -B1 wieder 1-Signal bringt und die Mirrorkontakte von -K1:21/22 und -K2:21/22 (Rücklesekontakte) geschlossen sind und die manuelle Rückstellfunktion mit dem Taster -S1, PNOZmuti -a1:I3, folgendermaßen betätigt wird: Darf nur erfolgen durch das Loslassen des Antriebselements in seiner betätigten (Ein)Position, negative Flanke.


    Dokumente:
    Datenblätter und Betriebsanleitungen mit Schaltungsbeispielen
    1.1 PSENcs 4.2, Seite 0815
    1.2 PNOZmulti Mini mm0.2p, Seite 0815
    1.3 Schütze -K1,-K2 x.y, Seite 0815 Funkenlöschglied Seite 0819

    2.1 Schaltplan:
    PSENcs4.2 Seite 31
    Manuelle Rückstellfunktion Seite 32
    Ausgang o0 Seite 105
    Schütze Seite 105 und 130
    Geändert von Safety (23.10.2011 um 20:22 Uhr)

  8. Folgende 2 Benutzer sagen Danke zu Safety für den nützlichen Beitrag:

    stevenn (25.03.2015),Tigerente1974 (23.10.2011)

  9. #6
    Avatar von Tommi
    Tommi ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    01.06.2008
    Ort
    Ostwestfalen
    Beiträge
    1.867
    Danke
    405
    Erhielt 472 Danke für 375 Beiträge

    Standard

    Hallo zusammen,

    @hapr:

    nicht daß wir beim Forumstreffen 2012 20kg mehr wiegen...


    @safety:

    Also, ich beschreibe meine Funktionen nicht ganz so ausführlich. Meinst Du wirklich, daß das in dieser Form erforderlich ist?

    Ich habe in der Softwarespezifikation des V-Modells eher an eine Tabelle gedacht:

    Waagerecht die Outputs, senkrecht die Inputs und die Betriebsarten. Dann in die Zellen z.B. SS1 oder STO. (ist das verständlich?, siehe Bild)

    Beschreibungen zu Quittierungen (z.B. überwachter Start) etc. in der Systemgestaltung. Ebenso z.B., daß Not-Halt immer Prio1 hat.

    Beschreibung der erforderlichen Verdrahtungstests etc. in der Modulgestaltung bei ausschließlicher Verwendung bereits validierter Module.

    Und das ganze dann von unten nach oben testen...

    Gruß
    Tommi
    Angehängte Grafiken Angehängte Grafiken

  10. #7
    Registriert seit
    14.06.2008
    Ort
    Pirmasens
    Beiträge
    1.794
    Danke
    94
    Erhielt 727 Danke für 457 Beiträge

    Standard

    Hallo Tommi,
    wie soll denn der Programmierer sonst wissen was er zu machen hat. Klar könnte man den einen oder anderen Satz weglassen, im Grunde muss man diese Spezifikation schon nach der Risikobeurteilung erstellen. Ein klare Angabe was und wie ist Grundvoraussetzung eine Tabelle kann die Spezifikation nicht ersetzen. Eigentlich fehlen noch Angaben von anderen Normen.
    Und ich wage zu behaupten dass viele Fehler vermieden werden können wenn man diese Beschreibung genau macht.

  11. #8
    Avatar von Tommi
    Tommi ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    01.06.2008
    Ort
    Ostwestfalen
    Beiträge
    1.867
    Danke
    405
    Erhielt 472 Danke für 375 Beiträge

    Standard

    Hallo Dieter,

    die Spezifikationen und teilweise auch die Risikobeurteilung macht bei uns, wie Du auch schon gesagt hast, der Programmierer selbst, sonst niemand.

    Aus Deiner Sicht (Pilz) mag das, was Du schreibst, richtig sein.
    Du hast mit allen möglichen Kunden zu tun. Wir sind "nur" ein Team im
    Betrieb und da ist so eine Tabelle meiner Meinung nach übersichtlicher.

    Damit kann man auch dem Laien (dem Meister vor Ort) erklären, was er
    bekommt.

    Alles was nicht laienverständlich ist, kommt in die Systemgestaltung des V-Modells, das ist für das allgemeine Verständnis nicht wichtig.

    Gruß
    Tommi

  12. #9
    Registriert seit
    14.06.2008
    Ort
    Pirmasens
    Beiträge
    1.794
    Danke
    94
    Erhielt 727 Danke für 457 Beiträge

    Standard

    Hallo Tommi,
    so eine Tabelle kann hilfreich sein wird aber bei komplexen Sicherheitsfunktionen versagen bzw. nicht ausreichen. Aber ich erlebe oft genau diese Reaktion, wenn Du die Spezifikation in einer einfachen Tabelle unterbekommst und damit dann an alles gedacht hast und der Programmierer der in Deinem Team ist das auch lesen kann reicht es. Aber lese Dir mal was bei dieser einfachen SF schon alles zu beachten ist und es ist nicht mal alles aufgeführt. Und wer macht die Validierung? Kann der auch alles aus dieser Tabelle lesen?
    Das ist nur die Angabe wie die SF zu funktionieren hat, wie prüft und dokumentiert Ihr die Tabelle 2 aus DIN EN ISO 13849-2? Grundlegende und Bewährte Sicherheitsprinzipien, Einhaltung der Kategorie Anforderungen usw. ?

  13. #10
    Avatar von Tommi
    Tommi ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    01.06.2008
    Ort
    Ostwestfalen
    Beiträge
    1.867
    Danke
    405
    Erhielt 472 Danke für 375 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo Dieter,

    bei der Validierung sind auch "Laien" dabei, z.B. der Meister, der
    die Anlage später mal betreibt, oder die SIFA. Die müssen das
    verstehen.

    Alles andere, z.B. auch Deine oben zitierte Tabelle, ist dann bereits
    durch die Modul- und Systemtests erledigt.

    So habe ich das V-Modell verstanden.

    Wie gesagt, wir sind ein kleines Team bei uns im Betrieb, wir müssen
    uns nicht um den Rest des Planeten kümmern, wie Pilz und Co.

    Gruß
    Tommi

Ähnliche Themen

  1. Gesamtheit von Maschinen
    Von Safety im Forum Maschinensicherheit - Normen und Richtlinien
    Antworten: 3
    Letzter Beitrag: 12.06.2011, 17:42
  2. Nicht Sicherheitsrelevante Endschlalter im Nothaltkreis???
    Von unwissender22 im Forum Maschinensicherheit - Normen und Richtlinien
    Antworten: 8
    Letzter Beitrag: 05.11.2010, 13:40
  3. Sicherheitsgerichtete Software für Maschinen
    Von Tommi im Forum Maschinensicherheit - Normen und Richtlinien
    Antworten: 15
    Letzter Beitrag: 15.07.2009, 09:17
  4. Messung von Maschinen.
    Von rostiger Nagel im Forum Maschinensicherheit - Normen und Richtlinien
    Antworten: 23
    Letzter Beitrag: 08.03.2009, 19:13
  5. Maschinen-Grundstellung
    Von HardAmLimit im Forum CODESYS und IEC61131
    Antworten: 12
    Letzter Beitrag: 21.10.2008, 16:52

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •