What about OPC UA Companion Specifications support by PLC Next?
Hello,
With the tests I did on the PLC Next Engineer and also with some research done here in the forum, I can't find anything regarding the support of OPC UA information models.
Many organizations and associations already have standardized OPC UA information models for industry-specific systems, for example Robotics, Machine Vision and Euromap.
Is there some kind of tool like "Siemens OPC UA Modeling Editor", that allow us to define our own OPC UA information model or mapping an existing companion specification to our PLC Next?
Best Regards,
André Martins
Comments
Hi Andre,
thanks for the interesting question, I'll talk with our OPC UA specialists and come back to you asap.
cu
Frank
Hello Andre,
this feature is under the top 3 Requirements.
But this not only a OPC UA Server functionality, it has to fit in the engineering process.
I have different usecases in mind.
1) Only create a new view on existing Information model
2.) Create a new functionality beside the PLC programm. Adapt this functionality parallel to the PLC programm.
3.) Create the PLC functionality and the OPC information model
Have you a clear idea what at the end is the feature you're looking for? Do you want create own information model, use existing?
What are your user success criteria? Could you describe the workflow starting from offline engineeering and how you want to reach the operation state?
I would be glad to get some feedback.
Best regards
Robert
Hello Frank and Robert,
First of all thanks for your quickly response to my question.
What I have in mind is a feature that allow us to import a NodeSet2.xml file (from an existing companion specification) and with the DataTypes from this file modeling an information model for our specific application, like we can do in "UAModeler" from Unified Automation.
When we have our information model ready the software should allow the mapping of our information model to our PLC Next variables, like in "Siemens OPC UA Modeling Editor".
In my opinion there is no need for a new software just to this functionality (like Siemens did), it can be simply added as a new feature on a later release of "PLCNext Engineer" software.
I hope this can help in the development of this required functionality.
Best Regards,
André Martins
Hello Together,
I would like to second that notion - import a Companion Specification via e.g. XML (or other file formats), to have the OPC UA Server readily configured with the variables. In the PLC Program, I would like to be able to use these variables or map them in some alternative way to existing variables (e.g. variables from the code, Input Ports, etc.).
This would allow to seamlessly integrate Axioline Controls into factory networks, which would be very helpful to combine legacy machines and equipment with very recent and new machinery - which all go by the same information model. I consider this a very helpful function.
The going right now is to recreate the variables artificially, which is like manually hacking a template into the PLCnext project. So it would save a great deal of time and effort, avoids mistakes, ensures compliances with existing Companion Specifications and allows for easy upgrades and maintenance of existing projects.
Are there any news on the development?
Thank you in advance and kind regards,
Thomas
The development is proceeding very well.
We are working on support for external information models with data access and methods support. We added methods in our first step, because they are part of a lot of customers and in companion specification we analyzed.
We added a linking functionality to between PLC variables and OPC nodes to the nodeset file. You have to add this information in the nodeset file directly.
We integrated already a concept of cascaded Information models. So you can copy e.g. the nodeset file of a companion specification onto the target and add additionally then in a second nodeset the instances or private project specific types nodes. In this - lets call Instance-related - nodeset you add the variable you want to link with the new node. Here a question. Do you think these files should be a fixed part of the project and downloaded/updated always with the project by the PLCnext Engineer or is this an additionally workflow, when the controller was already programmed with PLCnext, or should both possible?
With this approach the UA client can still access the PLC (GDS) variables which are marked with OPC and also the address space created by the external nodeset files. Is it required to hide the GDS Variables in that case? Are there scenarios where both need to be accessible?
There will be in the beginning no integrated or external tool support for creating this linking between nodeset nodes and the PLC application. This has to be part of the nodeset file. You have to do this manually. I'm still convinced that we have to provide something here. In machine building environment this could be a fixed mapping, but in plants like applications with huge flexibility, we have to support this mapping much easier. What is your use case? Where do these instance nodes for the external information model come from and how would you link them to PLC variables?
There will be today no information in the PLCnext Engineer, that the variable is linked to a node of an another information model. It's completely hidden internal functionality done in the UA server. How critical is this for the use of external models?
So we are in short term ready to create a first version for this feature. We look still for the right features to be implemented in Engineering. We are planning to check this with a list of first internal and external applications. If you are interested to provide your nodeset and your detailed working model, I could put you on the list as well.
Please send me a short notice: rwilmes@phoenixcontact.com