TIA Datenstruktur für OPC UA

Tmbiz

Level-2
Beiträge
578
Reaktionspunkte
15
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Morgen,

ich werde mich in den nächsten Wochen mit dem Thema OPC UA beschäftigen müssen. Ich suche nach allgemeinen Erfahrungswerten, um das Thema von Angang an auf eine tragfähige Ebene zu bringen. Insgesamt geht es um eine Maschine, welche kein Siemens Panel hat. Die Schnittstelle Mensch/Maschine (HMI) wird von einer externen Firma programmiert und enthält verschiedenste Themen. Z.B. ein komplexe Rezept und Datensatzverwaltung, Aufzeichnung der Istwerte zur Protokollierung (Abtastrate ist aktuell noch nicht bei 200ms aber gewünscht) usw.. Die gesamte Maschine wird über diese externe Eben (aus Sicht der PLC) gesteuert. Die Verbindung soll über OPC UA laufen. Die einzelnen Maschinen haben tendenziell einen geringen Projektanteil. Es geht dann immer nur um kleinere Anpassungen und Variationen. Das Konzept muss also nicht extrem flexibel sein.

Ich kann hier leider nicht schreiben, um welche Art von Maschinen es geht. Mir geht es hier auch nicht im eine konkrete Lösung, sondern um eure Erfahrung in dem Bereich. Könnte ihr mir Tipps geben, welche Themen klassisch auftauchen, wenn ein Maschine komplett über UPC UA angesteuert wird. Speziell auf Datenstruktur der Schnittstellen usw.
 
Hallo

je nach CPU ist der maximale Datendurchsatz zu beachten wenn man den OPC UA Server der S7 CPU nutzt.

Wieviele Datenpunkte in 200 ms sollen es den werden ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo

je nach CPU ist der maximale Datendurchsatz zu beachten wenn man den OPC UA Server der S7 CPU nutzt.

Wieviele Datenpunkte in 200 ms sollen es den werden ?
Im Kern ist die Vorgabe, dass so viele wie möglich so schnell wie möglich übertragen werden sollen. Ich kann leider gerade nicht sagen, wie viel es sind. Aber an der Maschine gibt es jede Menge Sensorik, aus verschiedenen Drücken für verschiedene Gase, Temperaturen, Strömungen usw. usw.

Ich stelle mir z.B. die Frage, ob man das ganz so trennt, und alles was für die Steuerung der Maschine nötig ist, über den OPC UA Server der SPS laufen lässt. Und alles was mit der Datenerfassung usw. zu tun hat, über einen externen UPC UA Server.

Ich trennte die Maschine konzeptionell in zwei Bereiche: A. was ist nötig, um eine erteilte Aufgabe nach Vorgaben umzusetzen. Damit meine ich Einschalten der Maschine, Starten und Stoppen des Prozesses, Fehler beheben usw. Bereich B wäre alles was nötig ist, damit die Maschine die Aufgabe umsetzen kann. Also Datensätze (Rezepte), Freigeben vom Leitsystem, Aufgaben Planung, Aufzeichnen von Prozesswerten, Auswerten von Prozesswerten usw.
 
Wenn ich jetzt mal dabei bleibe dann sind viele von dir genannte Info's KEINE daten, die im 200ms-Takt übertragen werden müssen.
So, wie ich das sehe, kann das Meißte wahrscheinlich im Sekunden-Takt oder noch langsamer aktualisiert werden (z.B. Start, Stop, Rezept-Daten, reine Visu-Daten) - schnell musst du eigentlich nur bei den Daten sein, die echte Steuerfunktionen im Sinne von zu erfolgenden Reaktionen erfordern.
Vielleicht solltest du das Ganze einfach mal erfassen und nach den genannten Kriterien bewerten. Soviel wie möglich und so schnell wie möglich ist nicht sinnfällig ...!!!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn ich jetzt mal dabei bleibe dann sind viele von dir genannte Info's KEINE daten, die im 200ms-Takt übertragen werden müssen.
So, wie ich das sehe, kann das Meißte wahrscheinlich im Sekunden-Takt oder noch langsamer aktualisiert werden (z.B. Start, Stop, Rezept-Daten, reine Visu-Daten) - schnell musst du eigentlich nur bei den Daten sein, die echte Steuerfunktionen im Sinne von zu erfolgenden Reaktionen erfordern.
Vielleicht solltest du das Ganze einfach mal erfassen und nach den genannten Kriterien bewerten. Soviel wie möglich und so schnell wie möglich ist nicht sinnfällig ...!!!
Ja, da hast du Recht. Im Kern ist es nur nötig die Daten für die Datenaufzeichung schnell zu übertraten. Aber das sind auch noch sehr viele. Wie gesagt, ich mache mir gerade auch erst mal ein Bild über das Ganze.

Mir geht es hier in diesem Beitrag auch erst mal mehr um allgemeine Themen des UPC Weges. Kann man z.B. mehrere UPC Server parallel verwenden? Also einmal den aus der PLC und dann noch einen externen? Denn dann wäre eine Trennung der Aufgaben möglich.
 
Klar kann man auch mehrere OPC Server nutzen. Einer der CPU und einer auf einer externen Hardware (z.B. für MES Kopplung)

Ob das sinnvoll ist muß man prüfen.

Mit einem OPC Server auf externer HW kann man ca. 2000 Datenpunkte in 200-300ms aktualisieren. Weiterer Vorteil: die OPC Kommunikation belastet nicht die Zykluszeit der SPS.
Ein Neustart des OPC Servers stoppt nicht die Maschine.

Die HW des OPC Servers dient gleichzeitig als Firewall zwischen Maschine und MES.
 
Klar kann man auch mehrere OPC Server nutzen. Einer der CPU und einer auf einer externen Hardware (z.B. für MES Kopplung)

Ob das sinnvoll ist muß man prüfen.

Mit einem OPC Server auf externer HW kann man ca. 2000 Datenpunkte in 200-300ms aktualisieren. Weiterer Vorteil: die OPC Kommunikation belastet nicht die Zykluszeit der SPS.
Ein Neustart des OPC Servers stoppt nicht die Maschine.

Die HW des OPC Servers dient gleichzeitig als Firewall zwischen Maschine und MES.
Ah, gut zu wissen. Das heisst, auch der PLC interne OPC Server hat keinen Einfluss auf die Zykluszeit?

Ich hatte mal bei einem HMI das Problem, dass das HMI auch innerhalb des PLC Zyklus Daten geschrieben hat. Wenn man eine Variable an zwei Orten im Quelltext verwendet, kann es sein, dass sie sich in einem Zyklus verändert und an Anfang ein 0 und an ende ein 1 hat.

Wie ist das beim OPC Server? Werden da die Daten in das Prozessabbild geschrieben? Oder können sich die Daten innerhalb eines Zyklus verändern?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie ist das beim OPC Server? Werden da die Daten in das Prozessabbild geschrieben? Oder können sich die Daten innerhalb eines Zyklus verändern?
Ins Prozessabbild werden sie sowieso nicht geschrieben - aber auch nicht zum Zykluskontrollpunkt (das war nur bei den alten 300er noch so).
Die Daten werden irgendwann in den Speicher geschrieben ... (wie auch beim HMI)
 
Moin,
dann will ich auch mal zu den wenigen Informationen meinen Senf dazugeben:
wenn Du langsame Daten und schnelle Daten hast, würde ich die pauschal erstmal auf zwei DBs aufteilen, dann kann man die im OPC-Server dann relativ einfach den unterschiedlichen Gruppen zuordnen:
DB-Steuerung kann dann einer Gruppe z.B. mit 1s zugeordnet werden, ohne einzelne Datenpunkte rausfriemeln zu müssen.
DB-Messwerte kann dann einer Gruppe z.B. mit 200ms zugeordnet werden.

Ah, gut zu wissen. Das heisst, auch der PLC interne OPC Server hat keinen Einfluss auf die Zykluszeit?

Der OPC-Server auf der Hardware benötigt ja Ressourcen, je mehr Datenpunkte Du hast und je schneller Du aktualisieren mußt, desto mehr Last erzeugt der OPC-Server auf der Hardware = der CPU.
Wenn Du den OPC-Server außerhalb der CPU hostest (=PC/Server) hast Du "unbegrenzte" Ressourcen, nur die Kommunikation belastet die CPU.
Es kommt auch darauf an, wie viele Clients auf den Server zugreifen sollen. Meistens haben die Server auf der CPU ein geringeres Client-Limit als PC-basierte, wegen der geringeren Ressourcen.

Dann habe ich auch mal was läuten gehört, daß sich Siemens bei der Namensvergabe nicht 100% an die vereinbarten Konventionen hält - hier mag man mir widersprechen, denn Hörensagen.
Daher war seinerzeit (2013) die Empfehlung, lieber einen externen OPC-Server zu nutzen, um sicherzustellen, daß beliebige Clients drauf zugreifen können.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,
dann will ich auch mal zu den wenigen Informationen meinen Senf dazugeben:
wenn Du langsame Daten und schnelle Daten hast, würde ich die pauschal erstmal auf zwei DBs aufteilen, dann kann man die im OPC-Server dann relativ einfach den unterschiedlichen Gruppen zuordnen:
DB-Steuerung kann dann einer Gruppe z.B. mit 1s zugeordnet werden, ohne einzelne Datenpunkte rausfriemeln zu müssen.
DB-Messwerte kann dann einer Gruppe z.B. mit 200ms zugeordnet werden.
Die Aufteilung haben wir hier auch besprochen. Aus unserer Sicht, der technischen, wäre das eine gute Lösung. Dagegen steht z.B. das Argument, dass jeder Server Lizenzgebühren verursacht.

Ich habe mich z.B. gefragt, ob man auch ein PN/PN Koppler über einen externen auslesen kann. Also von einem externen Server über Profibus die Verbindung aufgebaut wird. Möglicherweise gibt es ja auch ein PN/PN Koppler von einem anderen Hersteller, welche den Zugriff über einen Server ermöglicht.

Der OPC-Server auf der Hardware benötigt ja Ressourcen, je mehr Datenpunkte Du hast und je schneller Du aktualisieren mußt, desto mehr Last erzeugt der OPC-Server auf der Hardware = der CPU.
Wenn Du den OPC-Server außerhalb der CPU hostest (=PC/Server) hast Du "unbegrenzte" Ressourcen, nur die Kommunikation belastet die CPU.
Es kommt auch darauf an, wie viele Clients auf den Server zugreifen sollen. Meistens haben die Server auf der CPU ein geringeres Client-Limit als PC-basierte, wegen der geringeren Ressourcen.

Hat der OPC Server auf der PLC auch bei maximaler Auslastung einen Einfluss auf die Zykluszeit?
 
Die Aufteilung haben wir hier auch besprochen. Aus unserer Sicht, der technischen, wäre das eine gute Lösung. Dagegen steht z.B. das Argument, dass jeder Server Lizenzgebühren verursacht.
Was hat die Aufteilung in DBs mit Lizenzgebühren zu tun?

Ich habe mich z.B. gefragt, ob man auch ein PN/PN Koppler über einen externen auslesen kann. Also von einem externen Server über Profibus die Verbindung aufgebaut wird. Möglicherweise gibt es ja auch ein PN/PN Koppler von einem anderen Hersteller, welche den Zugriff über einen Server ermöglicht.
Das Konzept verstehe ich nicht ganz!?

Hat der OPC Server auf der PLC auch bei maximaler Auslastung einen Einfluss auf die Zykluszeit?
Ich weiß nicht, wie Siemens das gelöst hat, kann mir aber bei Vollauslastung vorstellen, daß es Einfluß hat.
Mußt Du mal in den Unterlagen nachschauen oder mit dem Support klären.
 
Was hat die Aufteilung in DBs mit Lizenzgebühren zu tun?
Das ist ein Missverständnis. Die Überlegung war, dass wie mehrere OPC UA Server verwenden. Für die Steuerung der Maschine vom HMI z.B. einen UPC Server auf der PLC und für die Aufzeichnung der Werte vom Prozess dann einen OPC UA Server, welcher extern auf einem PC läuft. Aber da wird von Seiten des Produktmanagement gesagt, dass das zusätzliche Lizenzkosten verursacht.
Das Konzept verstehe ich nicht ganz!?
Ich versuche es dann mal anders zu erklären. Bei einem PN/PN Koppler wird über Profinet auf verschiedene Variablen zugegriffen. Das bedeutet, es gibt eine Software, welche auf einer bestimmten Hardware läuft. Die Hardware ist meist eine SPS. Ich frage mich, ob man z.B. von einem Desktop PC auch auf die Variablen im PN/PN Koppler zugriffen kann?

Ich frage mich z.B. ob es einen PN/PN Koppler eines beliebigen Herstellers gibt, welcher den Zugriff über PC erlaubt. Dann könnte man die Anlage über den Koppler steuern. Also die Zugriffe nicht per OPC UA sondern über den Koppler. Sei es Siemens oder sonst ein Hersteller.

Eine weitere Frage:
Über welches System greift denn eine Siemens HMI auf die Variablen der SPS zu?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich frage mich, ob man z.B. von einem Desktop PC auch auf die Variablen im PN/PN Koppler zugriffen kann?
Wenn dein PC ein Profinet-IO Master sein kann ( z.B. SoftSPS ), dann ja.

Vielleicht schreibst du mal ganz genau, was du machen möchtest. Das mit dem PN/PN Koppler wird nicht die Lösung sein für deine Aufgabe.
 
Also ich würde sagen (aber das wurde auch schon mal gesagt) :
Erst einmal überlegen, was alles passieren soll und vor Allem um was es überhaupt geht.
Diese Überlegungen mit dem PN/PN-Koppler und anderem ähnlichen Kram deuten für mich darauf hin, dass deine Firma da zwar was machen will, aber gar nicht weiß wie ... ABER schon ganz genau weiß, dass es teuer wird ... und da muss man natürlich schon mal frühzeitig ans Sparen denken :unsure:
Bevor man hier ins Detail geht (und das versuchst du ja @Tmbiz) sollte man sich erst einmal GENAUE Gedanken über die Erfordernisse machen. Dann kann man das auch als Frage formulieren um ggf. zum WIE zu kommen. Dafür braucht es dann aber (auf alle Fälle für mich) viel mehr Info's und Details, die du dann schon anbieten müsstest ...

Eine weitere Frage:
Über welches System greift denn eine Siemens HMI auf die Variablen der SPS zu?
Diese Kommunikation nennt sich Bedienen und Beobachten - das kann aber nicht nur Siemens - dafür gibt es auch Software-Tools, die sich das auch zunutze machen. Das nützt dir aber gar nichts wenn es dein MES nicht kann. Da mußt du schon das nehmen was die können ...
 
Dann habe ich auch mal was läuten gehört, daß sich Siemens bei der Namensvergabe nicht 100% an die vereinbarten Konventionen hält - hier mag man mir widersprechen, denn Hörensagen.
Damit könnte gemeint sein, dass die 15xx PLCs beim "Standard SIMATIC Interface" String-NodeIds verwenden, die Anführungszeichen enthalten. Das liegt daran, dass die NodeIds algorithmisch aus der Hierarchie (dem Pfad) im Projekt gebildet werden, und in TIA Portal für Namen alle Unicode-Zeichen außer dem Anführungszeichen erlaubt sind. D.h. es standen keine geschützten Separator-Zeichen zur Verfügung. Eine Alternative wäre ein Escape-Mechanismus gewesen um Separator-Zeichen zu schützen (z.B. . = Separator, \. = . innerhalb Name, \\ = \ innerhalb Name).
Das Anführungszeichen ist nach OPC UA Spezifikation nicht verboten, aber einige Clients haben damit nicht gerechnet.

Sollte etwas anderes gemeint sein, wäre ich sehr daran interessiert!
 
Siemens schreibt zum OPC-UA-Mengengerüst ja einiges:


jedenfalls stark vom CPU-Typ und Firmware und TIA-Version und was die SPS sonst noch machen muss abhängig...

1712743912215.png

1712743926547.png
 
Zuletzt bearbeitet:
Ich frage mich z.B. ob es einen PN/PN Koppler eines beliebigen Herstellers gibt, welcher den Zugriff über PC erlaubt. Dann könnte man die Anlage über den Koppler steuern. Also die Zugriffe nicht per OPC UA sondern über den Koppler. Sei es Siemens oder sonst ein Hersteller.

Ich würde die Daten zyklisch mit GET/PUT (muss aktiviert werden) via S7Online von der SPS auslesen. Die Bibliothek Snap7 unterstützt unterschiedliche Programmiersprachen.

Die entsprechenden DBs dürfen dann aber nicht optimiert sein, da der Zugriff sonst nicht möglich ist.
HMI <> SPS können normal via Profinet kommunizieren.

PS: Man hat dann aber z.B. nicht die Abstraktion der Subscriptions, die man bei OPC-UA hat.
 
Zurück
Oben