Simatic OPC Server, AddNodes Service mit C++ bedienen

[xcompile]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
ich bin gerade dabei einen kleinen prototypischen OPC UA Client zu schreiben, basierend auf dem ANSI C SDK der OPC Foundation bzw. den C++ Quickstart Examples.
Als OPC-UA Server verwende ich den Simatic OPC-Server v 7.0.

Leider gibt es für C++ noch keine Toolkit/Example um den AddNode Service zu bedienen(UnifiedAutomation SDK verwende ich nicht).

Hat mir jemand Hinweise, Code Snippets, BestPractices oder Erfahrungswerte mit dem Simatic OPC Server oder mit dem AddNode Service über C++?

Mein momentaner Stand ist, dass ich beim Anlegen von Node Items in den Addressspace ein OpcUa_BadUserAccessDenied bekomme.

Ich konnte noch nicht herausfinden wie man die Zugriffsrechte hierfür einstelllt.

Danke

 

[xcompile]

Hab inzwischen herausgefunden, dass der Simatic OPC Server kein AddNode Service unterstütz...Adressraummanipulation ist also nicht möglich.

Unabhängig davon bin ich an C++ Beispielen zum Thema AddNode Service interessiert.

 

[Dr. OPC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nur mal so aus Interesse, was genau willst Du machen?
Adressraum-Manipulation an einem laufenden UA Server, warum? Und was sagen die anderen Clients dazu, wenn du zur Laufzeit Knoten hinzufügst? Mir ist schon klar das das technisch sicher irgendwie möglich ist, aber ist es in der Praxis auch sinnvoll?

Beschreibe doch mal den Anwendungsfall.

 

[xcompile]

Ich habe eine Hand voll Sensoren, welche ich mit semantischen Profilinformationen unterfüttern möchte, sprich ich möchte ein eigenes Informationsmodell anlegen um zusätzlich semantische Informationen zu den einzelnen Sensoren zu hinterlegen, eigene Referenzen erzeugen usw....

Da es aber keine Möglichkeit gibt, eigene Informationsmodelle zu laden, blieb mir letztendlich nur noch die Möglichkeit über den AddNode Service über einen Client Änderungen am Adressraum durchzuführen.

Was andere Clients dazu sagen ist ein guter Punkt, weiß ich noch nicht.

Die Alternative welche mir jetzt noch bleibt ist, ein Modell auserhalb des OPC Servers zu erzeugen welches dann eben auf OPC Verbindungen referenziert

 

[Dr. OPC]

Ok, verstehe, diese semantischen Informationen beschreiben den Sensor selbst und die eigentlichen Daten, die dieser liefert. Zunächst stellt sich also die Frage sind das nur Properties oder wirklich Typen? Beispiel: ein Temperatursensor hat neben dem Messwert selbst als semantische Information noch die Einheit Grad C. Dies in einen Typ zu modellieren würde nur Sinn machen wenn es auch typsicher konsistent dazugehört und auch immer mit übertragen werden soll. Für mich wäre es also eher ein Property.

Aber der Server muss diese Info ja "beschaffen" von der Datenquelle also dem Sensor. Oder mal anders gesagt, sebst wenn er den spezialisierten Typ eines bestimmten Sensors kennen würde, müsste er bei dessen Instanziierung ja noch wissen wo die Daten herkommen sollen. Oder nochmal anders: das ist "reinkompiliertes Wissen" und nicht "konfiguriertes Wissen". Einem "fremden" Server soetwas also nachträglich "beizubringen" halte ich für schwierig.

Daher war mein Verständnis eher so: Ein UA Server, der ein oder mehrere Geräte (von mir aus auch Sensoren) kapselt, sollte zunächst einmal das DI-Modell beherrschen. DeviceIntegration ist ein standardisiertes Typmodell und Mapping, das auf dem UA Basismodell aufsetzt. Auch Clients können dann damit umgehen wenn sie dieses DI-Modell beherrschen. Falls nun deine Sensoren noch ZUSÄTZLICH weitere Typen besitzen, kann dieses Modell weiter spezialisiert werden. Diese Spezialisierung verstehen dann aber nur noch wenige Clients bzw. nur noch ein Client und zwar dein eigener.

Der einzige Ausweg, alle Sensorhersteller setzen sich an einen Tisch und definieren standardisierte Sensortypen auf Basis von OPC UA bzw. auf Basis von DI (denn ein Sensor ist ja zunächst mal ein Device). Dies wurde bei ADI schon erfolgreich gemacht und für "Analytical Devices" wurde das DI-Modell weiter spezialisiert. So wissen nun z.B. Gaschromatographen wie sie ihre Informationen ADI konform über UA anzubieten haben.

 

[xcompile]

Zuviel Werbung?
-> Hier kostenlos registrieren

Aber der Server muss diese Info ja "beschaffen" von der Datenquelle also dem Sensor. Oder mal anders gesagt, sebst
wenn er den spezialisierten Typ eines bestimmten Sensors kennen würde, müsste er bei dessen Instanziierung ja noch wissen wo die Daten herkommen sollen.
Oder nochmal anders: das ist "reinkompiliertes Wissen" und nicht "konfiguriertes Wissen".
Einem "fremden" Server soetwas also nachträglich "beizubringen" halte ich für schwierig.

Die eine Problematik ist, dass meine Devices primitiv sind, also auch keinen Identifier o.ä. herausgeben. D.h. von Autokonfiguration bin ich weit entfernt - ist aber auch nicht meine Absicht so etwas umzusetzen.
OPC Server sowie Client müssen den individuellen Typ natürlich kennen. Das das Anlegen der Typen nachträglich erfolgt liegt daran, dass initial keine Typen angelegt werden können - wobei, wie ich nun vom Support erfahren habe, auch das nachträgliche Anpassen nicht unterstützt wird.

Ein UA Server, der ein oder mehrere Geräte (von mir aus auch Sensoren) kapselt, sollte zunächst einmal das DI-Modell beherrschen.

Es wäre eine gute Basis um Devices semantisch zu beschreiben...da es z.B. möglich ist Informationen wie Manufacturer o.ä. hinzuzufügen.
Allerdings befürchte ich, dass der SIMATIC OPC Server das DI-Modell nicht unterstützt.

Ich möchte beim Beschreiben der Devices noch ein Stück weitergehen z.B. wäre ein wichtiger Punkt ihnen eine Location vergeben zu können.

Bisher bin ich davon ausgegangen, dass ich meine Device Ontologie komplett im Adressraum des OPC UA Servers beschreiben kann z.B. über Erweiterungen an dem DI Informationsmodell. Aber vermutlich ist es einfacher die Ontologie extern aufzubauen und dort lediglich über Angabe einer Url als Datenquelle den OPC UA Server anzugeben.

 

[Dr. OPC]

Habe nochmal über Deine Ausführungen nachgedacht.

Man könnte sich einen UA Server vorstellen, den man über AddNodes selber konfigurieren kann (und auch Typen hinzufügen) wenn diese neuen Nodes nur und ausschließlich aus Referenzen zu bereits existierenden Nodes bestehen würden (denn nur dann wüsste der UA Server ja woher er die tatsächlichen Daten holen muss).

So könnte man sich aus dem tatsächlichen Datenvorrat sein eigenes Modell zusammenbauen. Im Prinzip sogar einem nicht-DI Server einen DI-konformem Adressraum "überstülpen". Quasi nur dadurch dass man die vorhandenen Daten in neue Nodes abbildet, die wiederum einfach nur durchgreifen auf das real vorhandene Modell.

Der SimaticNET OPC UA Server kann das heute sicher nicht, ob und welche Modelle (DI oder PLCopen oder sonstwas) er in Zukunft unterstützt bleibt abzuwarten und hängt sicher auch von der Nachfrage der Kunden ab. Auch ein konfigurierbares Modell wäre eine Variante, über die man nachdenken sollte. Eine derartige Konfiguration ist aber nur etwas für absolute Experten.

 

[xcompile]

Habe nochmal über Deine Ausführungen nachgedacht.

Man könnte sich einen UA Server vorstellen, den man über AddNodes selber konfigurieren kann (und auch Typen hinzufügen) wenn diese neuen Nodes nur und ausschließlich aus Referenzen zu bereits existierenden Nodes bestehen würden (denn nur dann wüsste der UA Server ja woher er die tatsächlichen Daten holen muss).

So in etwa hatte ich das auch vor, laut spec ist der ganze NodeManagement Bereich in dem die AddNode und RemoveNode spezifiziert sind dafür gedacht so genannte konfigurierende OPC UA Server zu erstellen, die bei Bedarf andere OPC UA Server umkonfigurieren.

Der SimaticNET OPC UA Server kann das heute sicher nicht, ob und welche Modelle (DI oder PLCopen oder sonstwas) er in Zukunft unterstützt bleibt abzuwarten und hängt sicher auch von der Nachfrage der Kunden ab. Auch ein konfigurierbares Modell wäre eine Variante, über die man nachdenken sollte. Eine derartige Konfiguration ist aber nur etwas für absolute Experten.

Eine derartige Konfiguration wäre doch aber im Sinne von OPC UA, denn nur so kann man eine individuelle Anlage nach eigenen Wünschen modellieren.
Ich bin momentan dabei die Informationen die ich gerne in dem Modell gehabt hätte(z.B. Hersteller, Sensor Typ) über eine extern gelagerte Ontologie zu modellieren, das wäre nicht in dem Umfang nötig gewesen würde der Simatic Server Modifizierungen am AddressSpace zulassen. Aber da muss man wohl abwarten und hoffen.