Sonstiges Reset der F-Teilnehmer (F-Devices) durch eine Safety-SPS?

S

shc

Level-2
Beiträge
21
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo SPS-Forum,

ich bin erst seit kurzem so richtig in der SPS-Welt und brauche deshalb wieder Rat von Experten in Sachen Safety-SPS:

Wir haben folgendes Ehternet APL-Profinet/Profisafe Nachrichten-Szenario zwischen den 3 Teilnehmern:

1. Safety-SPS (F-Host, wird vermutlich SIEMENS sein) <-> 2. sog. Kopfstation oder Vermittler <-> 3. Safety-Module (eigentl. F-Device)

Die "normale" Software-Kommunikationsüberwachung erfolgt ja über einen Heartbeat und Watchdog-Mechanismus zwischen Safety-SPS und F-Device.
Der Vermittler kann hier übergangen werden und kann als reine "Durchreiche" angesehen werden.

Meine Annahmen:
1. Sobald der Heartbeat (das toggle-bit im ControlByte bzw. StatusByte) aus irgendeinem Grund nicht zur Safety-SPS zurückkommt, schlägt der Watchdog der SPS zu und die SPS geht in Störung?
2. Ein Operator versucht nun die Teilnehmer (sprich das F-Device) zu Passivieren und wieder zu reaktivieren?
3. Gelingt das nicht (weil sich die FW des F-Devices verheddert hat, gecrasht ist, oder HW-Fehler, etc.), was dann?



Meine Frage:
Kann eine SPS oder eine Safety-SPS (als Ultima Ratio) seine Teilnehmer (F-Devices) mit einem Reset oder Hardware-Reset zum Neustarten bewegen?
Also über einen "Command" z.B. die Spannung der F-Devices über die APL-Leitung wegschalten und wieder zuschalten?
Oder müssen die F-Devices sich selbst um diesen Reset kümmern?

Vielen Dank für jede Hilfe, Hinweise oder Tipps.

Danke und Gruß,
shc
 
Ich verstehe nur Bahnhof… was soll da im Endeffekt rauskommen? Aber eines kann ich dir sagen: Wenn du im Forum fragen musst, brauchst du Hilfe von einem Experten.

Soll das Produkt auch vertrieben werden?
 
Moin shc,

Deine eigentliche Frage scheint ja zu sein, ob im Profinet der Controller die Devices reintegriert, oder?
Anwort: ja, das ist eine der Aufgaben des Controllers.

Aber ich habe das Gefühl, dass Du irgendwie tiefer einsteigen willst? Das hört sich fast an, als ob Du ein F-Device entwickeln willst?

Also, wenn das reintegrieren nicht (mehr) funktioniert, ist entweder eine Einstellung falsch, der Fehler liegt noch an oder das F-Device ist defekt.

VG
MFreiberger
 
Guten Morgen MFreiberger,
endlich ein Experte, danke für deine Antwort!
Ok, das ist gut zu wissen, dass der Controller (also der F-Host bei Safety) über Profinet die Devices integriert.
MFreiberger schrieb:
Aber ich habe das Gefühl, dass Du irgendwie tiefer einsteigen willst? Das hört sich fast an, als ob Du ein F-Device entwickeln willst?
Zum Vergrößern anklicken....
Yes, das ist es! Sehr gut. Genau das haben wir vor.

MFreiberger schrieb:
Also, wenn das reintegrieren nicht (mehr) funktioniert, ist entweder eine Einstellung falsch, der Fehler liegt noch an oder das F-Device ist defekt.
Zum Vergrößern anklicken....
Ja genau, das ist das Problem bzw. unsere Unkenntnis.
Es wird von den Projetbeteiligten sehr viel über Szenarien gesprochen, wie:
Was passiert wenn der Vermittler ausfällt? Oder das eigentliche F-Device?

Mein Verständnis über die Kommunikationsüberwachung des Controller ist die:
Im "normalen" Fehlerfall (toggle-bit kommt nicht und der Watchdog des Controller schlägt zu)
kann der Controller seine Devices Passivieren und versuchen wieder zu Aktivieren. Das kann ja funktionieren wenn es sich zuvor "nur" mal
um einen zu späten Trigger, Timer, wie auch immer gehandelt hat.

Wenn das aber nun nicht funktioniert weil z.B. die FW im F-Device durch Crash, Memory-Corruption, Exception, etc. im deadlock ist, was dann?

Kann der Operator am Controller dann einen Reset oder HW-Reset seiner F-Devices anstoßen, damit diese wieder einen Neustart machen, oder muss diese Reset-Möglichkeit durch das F-Device selbst erfolgen?

Danke schon mal für eine erneute Antwort!

Gruß,
shc
 
Zuviel Werbung?
-> Hier kostenlos registrieren
shc schrieb:
Kann der Operator am Controller dann einen Reset oder HW-Reset seiner F-Devices anstoßen, damit diese wieder einen Neustart machen, oder muss diese Reset-Möglichkeit durch das F-Device selbst erfolgen?
Zum Vergrößern anklicken....
Falls dieser Fall wirklich vorkommen kann, würde ich die Verantwortung alleine bei Dir als Entwickler sehen.

Ich würde das als Parameter sehen: Neustart bei Fehler ja/nein. Denn es kommt ja auf den Prozeß an. Wenn Du bspw. Ersatzwerte bei Fehler aufschaltest o.Ä. ist natürlich ein Neustart mit Wegfall des Ersatzwertes verbunden. Dann geht das nicht einfach, der unterlagerte Prozeß/die Sicherheit muß mit dem Wegfall der Ersatzwerte umgehen können.

Grundsätzlich brauchst Du einen internen Watchdog, der Deine Firmware überwacht und dann entsprechend auslöst: Entweder nur Meldung an den Controler oder aber (wenn zulässig) Neustart. Ein Reset vom entfernt sitzenden Controler würde ich nicht in Betracht ziehen.

Oder eben die Firmware so resilient machen, daß dieser Fall nicht vorkommen kann: Deine Aufgabe als Entwickler.
 
Hallo JSEngineering,

danke auch dir vor deine Antwort.

JSEngineering schrieb:
Falls dieser Fall wirklich vorkommen kann, würde ich die Verantwortung alleine bei Dir als Entwickler sehen.
Zum Vergrößern anklicken....
Ok, das ist aber noch nicht ganz die Antwort auf meine Frage, ob der Controller das auch könnte.
Vielleicht sehe ich das zu naiv, aber bei den heutigen Controllern ist doch viel möglich:
Könnte nicht der Controller, z.B. durch ein Kommando die Ethernet-APL-Versorgung der F-Devices weg- und wieder zuschalten?
Dadurch machen die F-DEvices doch automatisch einen Neustart!?
Ist das nicht möglich?

Wenn nein, dann muss man tatsächlich selbst einen Reset-UseCase dafür vorsehen.
Wir wollen nur nicht das Rad neu erfinden, sondern vorhanden Industrie- oder Systemarchitekturen dafür einsetzen.
JSEngineering schrieb:
Ich würde das als Parameter sehen: Neustart bei Fehler ja/nein. Denn es kommt ja auf den Prozeß an. Wenn Du bspw. Ersatzwerte bei Fehler aufschaltest o.Ä. ist natürlich ein Neustart mit Wegfall des Ersatzwertes verbunden. Dann geht das nicht einfach, der unterlagerte Prozeß/die Sicherheit muß mit dem Wegfall der Ersatzwerte umgehen können.
Zum Vergrößern anklicken....
Ja danke. Diese Szenarien sind bereits hinlänglich besprochen. Es geht nur noch darum, wer den Reset auslöst???

Danke und Gruß,
shc
 
NBerger schrieb:
Jetzt bekomme ich echt Angst!!!
Zum Vergrößern anklicken....
Zwischen der Entwicklung und dem Einsatz sollte bei F-Komponenten ja immer noch eine Zertifizierungsstelle sitzen, oder?

shc schrieb:
Warum?
Zum Vergrößern anklicken....
Weil jemand, der eine F-Komponente entwickeln (und vermutlich dann auch einsetzen oder vertreiben will) in einem Forum Fragen zu F-Thematiken stellt. Natürlich geht es in diesem Forum um den Austausch von Wissen. Ich selbst stecke auch nicht tief genug in dem Thema drin, um zu sagen, wie spezifisch deine Frage ist. Von daher kann es auch völlig legitim sein, solange du noch andere Experten in deinem Team hast.
 
Januar schrieb:
Zwischen der Entwicklung und dem Einsatz sollte bei F-Komponenten ja immer noch eine Zertifizierungsstelle sitzen, oder?


Weil jemand, der eine F-Komponente entwickeln (und vermutlich dann auch einsetzen oder vertreiben will) in einem Forum Fragen zu F-Thematiken stellt. Natürlich geht es in diesem Forum um den Austausch von Wissen. Ich selbst stecke auch nicht tief genug in dem Thema drin, um zu sagen, wie spezifisch deine Frage ist. Von daher kann es auch völlig legitim sein, solange du noch andere Experten in deinem Team hast.
Zum Vergrößern anklicken....
Also danke für die Antwort. Genau, die Experten machen es natürlich :-) Ich habe nicht behauptet, dass ich das F-Device mit der ganzen funktionalen Sicherheit entwickle will. Das würde schiefgehen, das stimmt. Das macht natürlich unser Partner, eine international anerkannt Firma, die diesen Part übernimmt. Wir als Team, sind natürlich neu in der Safety-Thematik. Aber wir können ja auch Programmieren mit Ethernet-APL-Technologie, z.B. den Vermittler oder auch Medien-Converter, den ich jetzt mal außen vor gelassen habe weil es nichts zur Sache tut.

Ich warte noch immer auf meine zuvor gestellte Frage, ob ein Controller seine F-Devices resetten kann oder nicht! Wir driften immer weiter vom Thema ab...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
shc schrieb:
Ich warte noch immer auf meine zuvor gestellte Frage, ob ein Controller seine F-Devices resetten kann oder nicht!
Zum Vergrößern anklicken....
Dann solltest Du Dich mit den entsprechenden Whitepapern beschäftigen, ob so ein Reset im Standard von F-Controlern vorgesehen und bei den Must-Have-Implementierungen gelistet ist.
Denn schön ist ja auch, wenn es zwar vorgesehen/möglich ist, aber von Controlern nicht umgesetzt wird, weil z.B. optional. Dann könnte Dein Gerät nur mit den Controlern zusammenarbeiten, die das implementieren.

Ich denke, die meisten hier sind Anwender der F-Technik, keine Entwickler. Daher wirst Du wohl um eine Lektüre der entsprechenden Standards/Normen nicht herumkommen :)
 
JSEngineering schrieb:
Dann solltest Du Dich mit den entsprechenden Whitepapern beschäftigen, ob so ein Reset im Standard von F-Controlern vorgesehen und bei den Must-Have-Implementierungen gelistet ist.
Denn schön ist ja auch, wenn es zwar vorgesehen/möglich ist, aber von Controlern nicht umgesetzt wird, weil z.B. optional. Dann könnte Dein Gerät nur mit den Controlern zusammenarbeiten, die das implementieren.

Ich denke, die meisten hier sind Anwender der F-Technik, keine Entwickler. Daher wirst Du wohl um eine Lektüre der entsprechenden Standards/Normen nicht herumkommen :)
Zum Vergrößern anklicken....
Ja danke, ist eine gute Antwort. Nur: Wir als Firma sind ja auch Bezahl-Mitglied bei der PNO. Ich könnte meine (evtl. naive) Frage dort auch stellen. Es dauert nach meinen Erfahrungen viel länger, bevor man eine Antwort bekommt, als hier im Forum. Das letzte Mal, als ich eine Frage zu diesem Projekt gestellt hatte, habe ich eine ziemlich treffende und sehr brauchbare Antwort bekommen! Von der PNO kam die Antwort nach ca. 2 Wochen und war nicht so treffend wie hier im Forum. Ihr unterschätzt Euch :)
Gut,ich gebe zu, vieles ist Neuland in diesem Projekt. Die Ethernet-APL-Technologie in Verbindung mit Safety-Devices, usw. Ich dachte nur, dass ein moderner Controller als Safety-SPS, F-Host, wie auch immer, evtl in der Lage ist, ein F-DEvice mit Hilfe der Ethernet-APL-TEchnolog z.B. über einen PF oder Phoenix-Switch die Spannung an dem F-DEvice zu schalten. Ok, ich werde nun besagt Whitepapers lesen...
 
Eben noch einen Artikel gelesen..

Erste praktische Erfahrungen mit Profisafe wurden bereits in der gleichen BASF-Testanlage gesammelt, in der bereits Profinet in Kombination mit Ethernet-APL erfolgreich geprüft wurde. Auf der Achema zeigen erstmals Endress+Hauser, Pepperl+Fuchs und HIMA am PI-Gemeinschaftsstand, wie eine Lösung mit Profisafe funktioniert.
Zum Vergrößern anklicken....
Vielleicht gibts hierzu mehr, oder sogar Whitepaper

Vielleicht kannst du auch mal in den wissenschaftlichen Bereich schauen, ob da schon jemand mit arbeitet

Eine Anlaufstelle wäre zB mal die https://www.smartfactory.de/ zu fragen, ob sie sich aktuell mit der Thematik auseinandersetzen praktisch/theoretisch
 
DCDCDC schrieb:
Eben noch einen Artikel gelesen..

Erste praktische Erfahrungen mit Profisafe wurden bereits in der gleichen BASF-Testanlage gesammelt, in der bereits Profinet in Kombination mit Ethernet-APL erfolgreich geprüft wurde. Auf der Achema zeigen erstmals Endress+Hauser, Pepperl+Fuchs und HIMA am PI-Gemeinschaftsstand, wie eine Lösung mit Profisafe funktioniert.
Zum Vergrößern anklicken....
Japp, gut antizipiert, in diese Richtung geht es :)

DCDCDC schrieb:
Vielleicht gibts hierzu mehr, oder sogar Whitepaper

Vielleicht kannst du auch mal in den wissenschaftlichen Bereich schauen, ob da schon jemand mit arbeitet

Eine Anlaufstelle wäre zB mal die https://www.smartfactory.de/ zu fragen, ob sie sich aktuell mit der Thematik auseinandersetzen praktisch/theoretisch
Zum Vergrößern anklicken....
Danke auch dafür. Kanns mal checken...
Das ganze Thema geht scheinbar doch viel tiefer ins Detail als ich dachte...
Ich danke auch allen anderen, die hier bei dem schweren Thema mitgeholfen haben!

Gruß,
shc
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es gibt immer noch Themen die sehr weit hinten in den unteren Schubladen liegen.. zB die Themen die auch die Smartfactory sich anschaut und in den wissenschaftlichen Arbeiten darstellt. Die Whitepaper sind ganz interessant.

Wir machen da viel in Richtung low-code/no-code für flexible Montagesysteme, ist auch ein spannendes Thema was aktuell viele Nerven kostet 🥶
 
Zurück
Oben