Sonstiges Wie Profinet- und Profisafe-Nachrichten programmatisch unterscheiden?

[shc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo SPS-Forum,

ich bin neu hier im Forum und relativ neu im Thema Profinet und Profisafe.
Ich habe für untenstehende Frage schon viel gegoogelt und recherchiert, leider ohne Erfolg, weil keine Systembeschreibung (sei eis Profinet/Profisafe) so
detailliert auf das Ganze eingeht.

Meine Aufgabe:
Es kommen Nachrichten von einer SPS (vermutlich SIEMENS 15xx, mit Safety-SPS) über Ethernet-APL auf unser Empfangsmodul (ist hier jetzt aber nicht so wichtig).
Die Nachrichten von der SPS/Safety-SPS müssen nun bezüglich Profinet und Profisafe unterschieden und ausgewertet werden.

Das ganze erst mal für zyklische Daten auf Layer 2, also mit den RT-Classes 1...3, etc.
Dazu habe ich mich nun ein bisschen mit den Layer, Payloads, PDU, SPDU beschäftigt.
Nach meinen unvollständigen Erkenntnissen, wird für eine Profisafe-Nachricht (F-Nachricht) die SPDU in den RT-Data-Block der Profinet-Payload gesteckt (mal ganz grob, evtl. habe ich hier Begriffe nicht ganz richtig wiedergegeben, bitte um Verzeihung).

Meine Frage:
Mit welchem Indikator (sei es nun im Profinet-Profisafe-Bereich) kann man nun EINDEUTIG F-Nachrichten von "normalen" Profinet-Nachrichten programmatisch (C++-Code) unterscheiden?

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

Danke und Gruß,
shc

 

[Michitronik]

PROFIsafe ist ein Profil was auf Profinet/Profibus aufbaut. Genauso wie PROFIdrive und PROFIenergie.
Auf der Seite der PNO gibt es dazu mehr Informationen.
Als Mitglied bekommt man hier natürlich mehr Informationen.
Wireshark bietet eine gute Möglichkeit die Telegramme zu analysieren. Es gibt auch dort Protokoll Unterstützung für Profinet, die das Analysieren vereinfachen. Zudem gibt es dort z.T. threads in Wireshark Foren zu. Habe die Links nicht parat,aber g...gle kann da bestimmt helfen.

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo SPS-Forum,

ich bin neu hier im Forum und relativ neu im Thema Profinet und Profisafe.
Ich habe für untenstehende Frage schon viel gegoogelt und recherchiert, leider ohne Erfolg, weil keine Systembeschreibung (sei eis Profinet/Profisafe) so
detailliert auf das Ganze eingeht.

Meine Aufgabe:
Es kommen Nachrichten von einer SPS (vermutlich SIEMENS 15xx, mit Safety-SPS) über Ethernet-APL auf unser Empfangsmodul (ist hier jetzt aber nicht so wichtig).
Die Nachrichten von der SPS/Safety-SPS müssen nun bezüglich Profinet und Profisafe unterschieden und ausgewertet werden.

Das ganze erst mal für zyklische Daten auf Layer 2, also mit den RT-Classes 1...3, etc.
Dazu habe ich mich nun ein bisschen mit den Layer, Payloads, PDU, SPDU beschäftigt.
Nach meinen unvollständigen Erkenntnissen, wird für eine Profisafe-Nachricht (F-Nachricht) die SPDU in den RT-Data-Block der Profinet-Payload gesteckt (mal ganz grob, evtl. habe ich hier Begriffe nicht ganz richtig wiedergegeben, bitte um Verzeihung).

Meine Frage:
Mit welchem Indikator (sei es nun im Profinet-Profisafe-Bereich) kann man nun EINDEUTIG F-Nachrichten von "normalen" Profinet-Nachrichten programmatisch (C++-Code) unterscheiden?

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

Danke und Gruß,
shc

Kannst du mal kurz umreißen was du machen willst?

Es gibt in dem Sinne keine "Profisafe Nachrichten". Profisafe ist ein Profil bzw. ein Tunnelprotokoll welches beispielsweise Profinet als Transportprotokoll nutzt. Ein Profinet-RT Frame enthält i.d.R. sichere und nichtsichere Pakete, und die Sicherheit wird durch Prüfungen, Sequenzierung, Timeout usw. sichergestellt.

 

[shc]

Hallo Michitronik,

danke für die Antwort.

PROFIsafe ist ein Profil was auf Profinet/Profibus aufbaut. Genauso wie PROFIdrive und PROFIenergie.
Auf der Seite der PNO gibt es dazu mehr Informationen.
Als Mitglied bekommt man hier natürlich mehr Informationen.
Wireshark bietet eine gute Möglichkeit die Telegramme zu analysieren. Es gibt auch dort Protokoll Unterstützung für Profinet, die das Analysieren vereinfachen. Zudem gibt es dort z.T. threads in Wireshark Foren zu. Habe die Links nicht parat,aber g...gle kann da bestimmt helfen.

Also die Theorie mit Profisafe als aufgesetzter Datenblock in Profinet ist mehr alles bekannt.
Hier geht es auch nicht um ein Standardverhalten (also F-Host <-> F-Device und alles tunneln so wie in der anderen Antwort beschrieben), sondern um eine ganz spezielle, projekt-spezifische Architektur. Ich muss reine Profinet-Nachrichten (iParameter, F-Parameter) bzw. reine F-Nachrichten (IO-Daten des Endgerätes) am Eingang unseres Empfangsmoduls auswerten, die SPDU ausschneiden und an ein sog. Safety-Modul in einem neuen Frame weiterleiten.
Die F-Nachricht darf dabei aber nicht verfälscht werden, sonst stimmt ja der CRC-Wert nicht mehr.
Danke für deinen Hinweis, aber die ganze Doku, die ich bisher gefunden habe, gibt das so im Detail nicht her. Ich denke man muss tatsächlich den Wireshark an beide Nachrichten-Typen dranhängen und dann alles minutiös untersuchen. Oder halt Mitglied bei der PNO werden, damit man hier wirklich detaillierte Infos bekommt. Ich werde mal die von Dir erwähnten Stellen suchen...

Gruß,
shc

 

[shc]

Kannst du mal kurz umreißen was du machen willst?

Es gibt in dem Sinne keine "Profisafe Nachrichten". Profisafe ist ein Profil bzw. ein Tunnelprotokoll welches beispielsweise Profinet als Transportprotokoll nutzt. Ein Profinet-RT Frame enthält i.d.R. sichere und nichtsichere Pakete, und die Sicherheit wird durch Prüfungen, Sequenzierung, Timeout usw. sichergestellt.

Hallo,
danke für die Antwort.
Siehe bitte meine Antwort an Michitronik. Hier geht es um einen ganz speziellen Fall, dass hat relativ wenig mit dem "normalen" F-Host <-> F-Device-Verhalten zu tun.

Danke und Gruß,
shc

 

[olliew]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da gibt es keine Magie woran man erkennen kann ob die zyklische E/A Daten PROFIsafe oder nicht PROFIsafe sind. Die E/A Daten bekommen eine Slot/Subslot Zuordnung (das kann hoffentlich euer PROFINET Stack) über den ConnectRequest. Und das wird dann halt an die entsprechende Module / Komponenten / ... verteilt, also genau das was eine PROFINET Applikation so oder so zu tun hat. Keine Magie, keine Tricks...

 

[shc]

Da gibt es keine Magie woran man erkennen kann ob die zyklische E/A Daten PROFIsafe oder nicht PROFIsafe sind. Die E/A Daten bekommen eine Slot/Subslot Zuordnung (das kann hoffentlich euer PROFINET Stack) über den ConnectRequest. Und das wird dann halt an die entsprechende Module / Komponenten / ... verteilt, also genau das was eine PROFINET Applikation so oder so zu tun hat. Keine Magie, keine Tricks...

Hallo olliew,
danke für die Antwort. Also, so wie von dir beschrieben, läuft das hier nicht, ist kein Standardverhalten zwischen Safety-SPS und Safety-Device.
Hier ist viel mehr manuelle Arbeit notwendig. Ich (ich bin hier so eine Art Broker) habe einen Medienwechsel von APL auf UART und muss entsprechend die erhaltenen Nachrichten in neuen Frames and das Safety-Modul senden. Nur die eigentliche SPDU muss unverändert bleiben, damit der CRC noch stimmt. Ich muss also sehr wohl wissen, ob es sich um eine reine Profinet-Nachricht (z.B. iParameter) oder um eine F-Nachricht mit SPDU handelt. Ich muss diese Unterscheidung auch in das Telegramm im neuen Frame (als MessageType) schreiben, damit das Safety-Modul das auch unterscheiden kann. Also irgendwie muss man es doch unterscheiden können. Muss man denn wirklich den RT-Data-Bereich und darin die SPDU minutiös durchkämmen und die SPDU-Struktur verifizieren? Mir scheint es so, als ob meine Architektur doch stark vom Standardverhalten abweicht, und deshalb keiner so richtig weiß was ich machen will.

Gruß,
shc

 

[DCDCDC]

Wäre es nicht sinnvoll mal sich beim Konsortium zu melden?

Kontakt

de.profibus.com

Die Downloads habt ihr da wahrscheinlich schon durchgekämmt.. ich verlink sie aber noch mal:

PROFIsafe Technology and Application - System Description​

PROFIsafe Technology and Application - System Description

One of the major events within the lifetime of the PROFIBUS and PROFINET International (PI) community was the first release of a specification for safety

www.profibus.com

PROFIsafe: Frequently Asked Questions for Downlaod​

PROFIsafe: Frequently Asked Questions for Downlaod

PROFIsafe V2.6 FAQ

www.profibus.com

 

[shc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wäre es nicht sinnvoll mal sich beim Konsortium zu melden?

Kontakt

de.profibus.com

Die Downloads habt ihr da wahrscheinlich schon durchgekämmt.. ich verlink sie aber noch mal:

PROFIsafe Technology and Application - System Description​

PROFIsafe Technology and Application - System Description

One of the major events within the lifetime of the PROFIBUS and PROFINET International (PI) community was the first release of a specification for safety

www.profibus.com

PROFIsafe: Frequently Asked Questions for Downlaod​

PROFIsafe: Frequently Asked Questions for Downlaod

PROFIsafe V2.6 FAQ

www.profibus.com

Hallo,
ja, danke für den Vorschlag und für die Links. Ich habe tatsächlich auch schon einige dieser Docs studiert. Als Bezahl-Member kommt man da ja gut ran.
Sind definitiv hilfreich und bringen einem auch weiter, da sie viel tiefer in eine Nachricht/Telegramm reinleuchten, als die normalen Systembeschreibungen von Profinet/Profisafe. Ich werde auch die FAQs noch mal checken.

Ich dachte nur, dass jemand "so was in der Art" wie ich vor habe, schon Mal gemacht hat und es sofort weiß.
Ich konzentriere mich nun vor Allem auf den PN-Header-Bereich (die 40 Bytes Offset vor der eigentlichen Data-Payload).
Wenn ich endlich mal eine Safety-SPS bekommen würde, dann könnte man ja den Wire-Shark dränhängen und beide Nachrichten-Typen genau untersuchen.
Ich freue mich in der Zwischenzeit weiter auf Tipps und werde auch hier wieder posten, wenn ich mehr weiß!

Gruß,
shc

 

[DCDCDC]

Produktanbieter sind zwar auch hier im Forum.. von Geräten bis Netzwerkanalyse etc.. aber das sind ja denke ich alles Supportmitarbeiter und nicht die Integratoren des Netzwerk Stacks.. und der Rest der normalen Benutzer sind eben auch nur Menschen welche mit Tia Portal arbeiten und nicht so viel Hardwareentwicklung betreiben.

 

[maxder2te]

Wenn ich endlich mal eine Safety-SPS bekommen würde, dann könnte man ja den Wire-Shark dränhängen und beide Nachrichten-Typen genau untersuchen.

Woran scheitert das?

 

[shc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Woran scheitert das?

Hallo,
das Projekt läuft erst an und das Equipment (Safety-SPS, Eval-Boards) ist noch nicht da. Kommt bald hat man mir gesagt.

Gruß,
shc

 

[shc]

Produktanbieter sind zwar auch hier im Forum.. von Geräten bis Netzwerkanalyse etc.. aber das sind ja denke ich alles Supportmitarbeiter und nicht die Integratoren des Netzwerk Stacks.. und der Rest der normalen Benutzer sind eben auch nur Menschen welche mit Tia Portal arbeiten und nicht so viel Hardwareentwicklung betreiben.

Danke für die Klarstellung!

 

[olliew]

Wie bereits gesagt, in die nachrichten gibt es keine Erkennung.
Und bevor du da selbst anfängst ein PROFINET Device Stack zu schreiben, wurde ich mich zuerst damit beschäftigen wie du zu ein funktionierendes PROFINET Device kommt. Dann genauer hinschauen wie das denn funktioniert. Erst danach PROFIsafe.

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Michitronik,

danke für die Antwort.

Also die Theorie mit Profisafe als aufgesetzter Datenblock in Profinet ist mehr alles bekannt.
Hier geht es auch nicht um ein Standardverhalten (also F-Host <-> F-Device und alles tunneln so wie in der anderen Antwort beschrieben), sondern um eine ganz spezielle, projekt-spezifische Architektur. Ich muss reine Profinet-Nachrichten (iParameter, F-Parameter) bzw. reine F-Nachrichten (IO-Daten des Endgerätes) am Eingang unseres Empfangsmoduls auswerten, die SPDU ausschneiden und an ein sog. Safety-Modul in einem neuen Frame weiterleiten.
Die F-Nachricht darf dabei aber nicht verfälscht werden, sonst stimmt ja der CRC-Wert nicht mehr.
Danke für deinen Hinweis, aber die ganze Doku, die ich bisher gefunden habe, gibt das so im Detail nicht her. Ich denke man muss tatsächlich den Wireshark an beide Nachrichten-Typen dranhängen und dann alles minutiös untersuchen. Oder halt Mitglied bei der PNO werden, damit man hier wirklich detaillierte Infos bekommt. Ich werde mal die von Dir erwähnten Stellen suchen...

Gruß,
shc

Ganz verstehe ich den Zugang trotzdem nicht. Du möchtest Profisafe-Telegramme herausschneiden und weiterleiten - ok. Die Endstelle verarbeitet die Profisafe-Pakete, ist aber selbst kein Profinet-Teilnehmer. Soweit klar. Solche Lösungen gibt's ja am Markt, zB alle Siemens F-EA-Module für ET200SP, die DFS22B von SEW mit den unterlagerten DCS..B, IO-Link EAs mit Profisafe von Balluff, usw.

Allen gemein ist dass hier ein Profinet-Device die erste Gegenstelle der CPU ist und die Pakete entgegen nimmt. Das wäre in deinem Fall das APL-Gerät welches in die Rolle des Profinet-Devices schlüpft und für die Profisafe-Endstelle den Proxy darstellt. Soweit klar.
Es wird darauf hinaus laufen dass du auf deinem APL Gerät einen Profinet-Device-Stack packen musst der dir die Profisafe-Daten aus dem Profinet-Verkehr extrahiert und dir zur Weitergabe auf dein per UART angebundenes Gerät liefert.

Ohne diesen Profinet-Device Zwischenschritt gibt's da mal gar keine Möglichkeit - schließlich musst du deiner SPS ja auch irgendwie beibringen wie es mit deinem Gerät spricht ubd F-Telegramme überhaupt produziert. Der dafür vorgesehene Weg ist gsd - also die Beschreibung des Profinet-Proxies.

 

[shc]

Es wird darauf hinaus laufen dass du auf deinem APL Gerät einen Profinet-Device-Stack packen musst der dir die Profisafe-Daten aus dem Profinet-Verkehr extrahiert und dir zur Weitergabe auf dein per UART angebundenes Gerät liefert.

Ja, sehr gut. Alles richtig erkannt! Profinet-Stack mit APL-Profinet-Kommunikation zur SPS ist bereits da, Profisafe und die UART und die ganze Kommunikationslogik muss noch erstellt werden.

Ja, es gibt viel am Markt. Aber nichts, was unsere Bedarfe decken würde. Wir driften aber jetzt ein bisschen ab.
Ich wollte ja eigentlich, wissen wie man die einzelnen Telegramme und Nachrichten unterscheiden kann. Angeblich geht das aber gar nicht, laut Aussage von @olliew.
Ich melde mich wieder, wenn ich weitere Infos habe.

Gruß,
shc

 

[shc]

Und bevor du da selbst anfängst ein PROFINET Device Stack zu schreiben, wurde ich mich zuerst damit beschäftigen wie du zu ein funktionierendes PROFINET Device kommt. Dann genauer hinschauen wie das denn funktioniert. Erst danach PROFIsafe.

Ja, danke. Siehe meine Antwort zu maxder2te.

Gruß,
shc

 

[olliew]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also wenn du bereits ein PROFINET Device Stack hast, dann gibt es dazu auch eine Beschreibung (idR 2 Callback Funktionen) wie denn deine Prozessdaten einzelne Slots/Subslots zugeordnet werden.
Wenn jetzt euer Gerät so konfiguriert wird das Slot 1 / Subslot 1 den PROFIsafe Aufkleber hat in GSDML, dann hast du ohne wenn und aber deine xx Bytes zusammen.

Ein PROFINET Frame (SPS -> Device) sieht zum Beispiel so aus, welches Slot/Subslot auf welcher Offset steht im ConnectFrame. Da ist aber kein PROFIsafe Flag dran, "black channel" halt. Dein PROFINET Device braucht das auch nicht wissen, die x Bytes werden an die entsprechende Periferie verschickt. Ob das dann ein Ruckwandbus ist (I/O Klemmen, Ventilinsel, ....) oder ein UART dingens, ist vollkommen egal. Erst der Empfänder (F-Klemme / F-Scheibe) muss das dekodieren können.

 

[maxder2te]

Ja, sehr gut. Alles richtig erkannt! Profinet-Stack mit APL-Profinet-Kommunikation zur SPS ist bereits da, Profisafe und die UART und die ganze Kommunikationslogik muss noch erstellt werden.

Verstanden.

Ich wollte ja eigentlich, wissen wie man die einzelnen Telegramme und Nachrichten unterscheiden kann. Angeblich geht das aber gar nicht, laut Aussage von @olliew.

Da sehe ich auch keine Möglichkeit das direkt aus den Daten zu erkennen.

 

[shc]

Also wenn du bereits ein PROFINET Device Stack hast, dann gibt es dazu auch eine Beschreibung (idR 2 Callback Funktionen) wie denn deine Prozessdaten einzelne Slots/Subslots zugeordnet werden.
Wenn jetzt euer Gerät so konfiguriert wird das Slot 1 / Subslot 1 den PROFIsafe Aufkleber hat in GSDML, dann hast du ohne wenn und aber deine xx Bytes zusammen.

Hallo olliew,
ich glaube langsam, dass dein Ansatz der Beste ist. Keiner antwortet konkret auf meine Anfragen (auch im Profinet-Forum nicht).
Ok, ich muss mich wohl von meiner fixen Idee einer eindeutigen Kennung (FrameId, PN-Header, RT-Daten, wo auch immer) verabschieden.

Ich fasse deinen Vorschlag zusammen:
D.h. nun, es wird in der GSD-Datei das Safety-Modul mit den Slots/Subslots der iParameter (1.Bereich, azyklisch), F-Parameter (2.Bereich, azyklisch), IO-Daten (3.Bereich, zyklisch) konfiguriert. Es gibt nun für die 3 Bereiche (das ist jetzt meine eigene Namensgebung als Unterscheidung), jeweils Callbacks, die den Slots dann zugeordnet sind. So kann ich nun die 3 Bereiche unterscheiden und mir die eigentlichen Nutzbytes herausholen. Nun baut man sich damit ein neues Telegramm auf und schickt es auf die UART an das Safety-Modul. So bekommt das Safety-Modul (also das F-Device) den Black-Channel quasi durchgereicht.
Ist das in etwa deine Idee?
Danke für deine Rückmeldung!

Gruß,
shc