Fehlersichere Steuerung / festverdrahtete Sicherheitsrelais

Zuviel Werbung?
-> Hier kostenlos registrieren
Passwörter hat nur der Entwickler und nicht der Techniker für Hotline!

Hallo Tommi,

die Passwörter der Safety-SPS sollte der Entwickler für sich behalten, und niemandem weitergeben wenn die Maschine beim Kunden abgenommen wurde.

Die Safety - Prüfsumme muss unverändert bleiben, sonst ist der Sicherheitsgedanke weg. Wenn du auch nur eine kleine Änderung in die lebende Safety-SPS reinspielst geht erst einmal die CPU auf STOP und muss vor Ort die Safetyabnahme wiederholt werden. Rechtlich gesehen ist derjenige der die letzte Safetyänderung reingespielt hat, voll verantwortlich für alle Folgeunfälle.

Was ich meinte, war die Fehlersuche von einem Hotline-Techniker wenn die Maschine schon abgenommen wurde. Bei Siemens geht man im Fehlerfall auf den HW-Katalog und siehst sofort beim ET200 ist am Eingang Exxx.x der Kanal 1 passiviert. Der Kundentechniker (kann auch Schlosser sein) sollte nun die kaputte Sensorik tauschen.

Beim Pilz-Pnoz musst du umständlich für jeden Ein- und Ausgang selber ein Statusbyte umkopieren und über den Profibus zusätzlich verschicken. Das macht aber niemand den ich kenne, weil das zuviel Aufwand ist.
 
Die Valedierung muss im jedem Fall immer erfolgen, egal welche Art der
Steuerung. Nicht nur der Programmierer kann Fehler machen sondern auch
der Schaltschrankbauer oder der jenige der den Not-Aus in der Maschine
verdrahtet. Ein Umbau der Software wird automatisch durch einen Zeitstempel
dokumentiert und ist mal nicht mal ebend zu machen auf jeden Fall geht die
Steuerung in stop. Ein Türenschalter kannst du auch überbrücken wenn die
Machine arbeitet, bei den heutigen steckklemmen.
Wenn das SPS-Programm geschickt Programmiert ist, könnte mann eine
Valledierung erzwingen, das bei der Erstinbetriebnahme alle Schutzeinrichtungen
nach einen bestimmten Muster betätigt werden und erst dann wenn dieses
erfolgt ist, die Maschine freigegeben wird...so etwas geht bei nomalen schalt-
geräten nicht oder nur sehr schwerr.
Was ich damit sagen will, für mich ist der klare Sieger die SPS, vor allen dingen
weil die neue MRL so aufwendig ist, das Mann sehr schnell dahin kommt doch eine
Sicherheitssteuerung einzusetzen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Beim Pilz-Pnoz musst du umständlich für jeden Ein- und Ausgang selber ein Statusbyte umkopieren und über den Profibus zusätzlich verschicken. Das macht aber niemand den ich kenne, weil das zuviel Aufwand ist.

Wenn ich PNOZ'e einsetze nutze ich schon sehr wohl die Elemend ID der
Bausteine und melde da über den Bus an die SPS zb Rückführkreis nicht IO
oder diskrepanzfehler eines Sensor, das macht eigentlich nicht viel Mühe.
Im Gegenteil, diese Fehler melde ich auch bei einer S7-F, ehrlich gesagt schaffe
ich es nie alles auf der reihe zu bekommen ohne die endsprechenden Hand-
Bücher zu lesen, wo ist jetzt welches Bit versteckt. Das finde ich bei den
PNOZen schon besser gelösst.
Das gleiche gilt auch beim programmieren, die PNOZe sind viel sicherer und
intuitiver zu programmieren, alleine die Struktur die du bei Siemens erst erstellen
musst damit das F-Programm läuft ist echt daneben...aber bei TIA soll es ja
besser werden.
 
Rechtlich gesehen ist derjenige der die letzte Safetyänderung reingespielt hat, voll verantwortlich für alle Folgeunfälle.

Das stimmt so nicht.

Aber das ist ein anderes Thema.

Und unabhängig von der Maschine, ist es völlig normal, dass Kunden darauf bestehen die Passwörter zu bekommen.
Ich würde auch nicht darauf verzichten, denn wenn dann der Lieferant nicht mehr am Markt ist, kann keine Wartung nicht mehr erfolgen.
Der Kunde ist nicht der Gegner, sondern der Partner.


bike

P.S: Wovon wird denn hier geträumt? :confused:
 
Hallo Helmut,

wenn beim PNOZ ein Eingang depassiviert wird, wir genau so ein HEX-Byte beschrieben, wie bei der Siemens im Instanz-DB der Fxxx Bauteins.

Das ist völlig gleich kompliziert, aber bei der Siemens kannst du im Fehlerfall online gehen und in der HW-Konfig im Klartext lesen, dass ein Kurzschluss am Eingang Exxx.x existiert. Das ist schon ein Vorteil finde ich.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn du auch nur eine kleine Änderung in die lebende Safety-SPS reinspielst geht erst einmal die CPU auf STOP .

Hallo Superkater,

das stimmt, bekommt man die denn aus der Ferne mit dem Konfigurator nicht wieder gestartet? Da habe ich persönlich keine Erfahrung.

Ich habe bisher nur "in Sichtweite der Steuerung" über RS-232 gearbeitet.

Gruß
Tommi
 
Hallo bike,

die Passwörter den Kunden weiterzugeben ist ganz normal, wenn dies im Vertrag steht. Es gibt ja 2 Passwörter bei Siemens (eines für CPU flashen, und eines zum Erstellen des Safety-Programmes).

Die Safety Prüfsumme sollte bei der Kundenabnahme der Maschine in einem Protokoll unterschrieben werden. Manche Firmen zeigen diese Prüfsumme sogar in der VISU an und verweigern den zukünftigen Support, wenn der Kunde halt NOT-HALT Eingänge softwaremäßig überbrückt und auf "IMMER_1" hat.

Vor der Kundenabnahme muss man selbst ALLE Safetyfunktionen testen und quittieren und in einem Abhameprotokoll verewigen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wir liefern das Programm und ein Abnahmeprotokoll in dem die Funktionen der Sicherheit beschrieben und deren korrekte Funktion bestätigt wird, mit Datum und Checksum.

Wer will und kann einem Kunden verbieten mit seiner Maschine bzw Anlage was er will und was notwendig ist?


bike
 
wenn beim PNOZ ein Eingang depassiviert wird, wir genau so ein HEX-Byte beschrieben, wie bei der Siemens im Instanz-DB der Fxxx Bauteins.

Vielleicht solltest du dich mal genauer mit der PNOZ-Diagnose beschäftigen.
Du kannst für jede Element-ID ein Diagnoseelement benutzen und dort die entsprechenden Fehlercodes eintragen. Damit brauchst du dich nicht mit irgendwelchen Hex-Codes oder dergleichen rumplagen. Bei einer Schutztür habe ich in der Regel 4 Bits:

  • in Ordnung (geschlossen & verriegelt & quittiert)
  • offen
  • nicht quittiert
  • gestört
Diese Bits frage ich über das Feldbusmodul auf der S7 / Visualisierung ab.
Eigentlich habe ich damit genau das selbe wie bei einem normalen Auswertegerät.

Ich persönlich finde das Pilz-Konzept sehr gelungen ... z.B. im Vergleich zu einem Siemens 3RK3-System.

Gruß
Dieter
 
Ich denke ich würde auch nie eine Änderung über Fernwartung durchführen.
Wenn dann nur mit einem Kollegen vor Ort, der dann die Funktionen Prüft.


Die Möglichkeit der Fehlersuche jedoch habe ich schon öfters gebraucht als es mir lieb war ;) Habe ich nur ein paar LEDs an den Relais, muss ich daran glauben was der Mensch mir vor Ort erzählt. Leider ist das ja meistens schon ein Problem.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute,
ich schlage hier mal einfach in die schon etwas ältere Diskussion rein. Meine Frage passt glaube ich fast zum Thema.

Und zwar prüfe ich gerade den Umstieg von "Klappertechnik" auf eine F-SPS. Ich habe mich für eine Siemens F-SPS entschieden (Siemens Pflicht).
Ich habe ein paar F-AI, F-DI und F-DO neben ein paar Standard Modulen an einer F-317 2PN/DP

Da wir vorher "Klappertechnik" in Form von Siemens Sicherheitsrelais hatten, war die Verifizierung und Validierung der Steuerung immer E-Techniker arbeit.

Wenn wir nun die Sicherheitsabschaltungen o.Ä. über F-SPS und letztendlich über die Software machen, bleibt der Verifizierungs, und Validierungsprozess ja an den Programmierern hängen. Diese finden das gar nicht witzig und wir können uns noch nicht vorstellen, was da auf uns zukommt.

Nach der IEC61508 - Teil 3
Sicherheitsgerichtete Softwareentwicklung
gehört ja einiges dazu.

Meine Frage nun. Gibt es unterstützende Software Tools?
Hat jemand Erfahrungen mit der Verifizierung und Validierung von Software?

Viele Grüße
gweindir
 
Deshalb setzten wir z.B. Siemens 3RK3 oder Pilz PNOZmulti ein.
Im Prinzip haben diese Geräte nahezu die gleiche Funktionalität wie eine Sicherheits-SPS, ABER sie werden nicht programmierbare Steuerung verkauft sondern als KONFIGURIERBARE Sicherheitsbausteine. Damit wird die Validierung wesentlicher einfacher.
Gekoppelt werden die Bausteine per Profibus bzw. Profinet an die normale SPS.

Gruß
Dieter
 
Ja ich habe mir verschiedene Lösungen angeschaut und bewertet. Unter anderem eben auch die Pilz und Siemens Lösungen. Da ich, so weit ich weiß, aber keine fehlersicheren analogen Eingänge bei diesen Lösungen bekomme und wir aber eine Grenzwertabschaltung über analoge Sensoren mit im Sicherheitskreis haben fällt das leider weg.

*Edit: die PilzPnozMulti haben ja doch F-AI's aber insgesamt war es ziemlich teuer. (also jedenfalls nicht groß günstiger als die Lösung mit Siemens F-Baugruppen)
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
*Edit: die PilzPnozMulti haben ja doch F-AI's aber insgesamt war es ziemlich teuer. (also jedenfalls nicht groß günstiger als die Lösung mit Siemens F-Baugruppen)

Bei Pilz lohnt es sich den Vertrieb anzurufen und mal nach genauen Preisen zu fragen ;)

Gruß
Dieter
 
Hallo Leute,
ich schlage hier mal einfach in die schon etwas ältere Diskussion rein. Meine Frage passt glaube ich fast zum Thema.

Und zwar prüfe ich gerade den Umstieg von "Klappertechnik" auf eine F-SPS. Ich habe mich für eine Siemens F-SPS entschieden (Siemens Pflicht).
Ich habe ein paar F-AI, F-DI und F-DO neben ein paar Standard Modulen an einer F-317 2PN/DP

Da wir vorher "Klappertechnik" in Form von Siemens Sicherheitsrelais hatten, war die Verifizierung und Validierung der Steuerung immer E-Techniker arbeit.

Wenn wir nun die Sicherheitsabschaltungen o.Ä. über F-SPS und letztendlich über die Software machen, bleibt der Verifizierungs, und Validierungsprozess ja an den Programmierern hängen. Diese finden das gar nicht witzig und wir können uns noch nicht vorstellen, was da auf uns zukommt.

Nach der IEC61508 - Teil 3
Sicherheitsgerichtete Softwareentwicklung
gehört ja einiges dazu.

Meine Frage nun. Gibt es unterstützende Software Tools?
Hat jemand Erfahrungen mit der Verifizierung und Validierung von Software?

Viele Grüße
gweindir

Hallo,
ich denke bei Dir würden die Anfordrungen der DIN EN ISO 13849-1 reichen. Bedeutet vereinfachtes V-Model und Anhang J mal ansehen.
Was oft vergessen wird beim Steuerungskauf ist die Verifizierung und Validierung der Software. Das verwendete Tool oder Werkzeug wie es die Norm nennt ist hier absolut entscheidend. Warum denkt Ihr macht man bei Pilz eine so eingeschränkte Software und fast alles mit Zertifizierten Bausteinen?
Dann vergleicht mal die Anforderungen der Norm mit dem am Ende erzeugten Report.
Zertifizierte Bauteile und Softwarebausteine sparen eine Menge an Geld.
Ich wollte schon mal ein Thema zur Software Validierung eröffnen und besonders zum V-Model aber mir fehlt einfach die Zeit.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Morgen zusammen,

ich habe mir gerade mal die 13849-1 Anhang J angeschaut und bin nun sehr zuversichtlich.

Vielen Dank für die Antworten.

PS: Safety: So ein Artikel wäre sicher sehr informativ! ;-)

Einen schönen Tag
Gruß
gweindir
 
Zurück
Oben