Log In
Register
Forum
Topic RSS
9:53, EEST
March 16, 2017
Offline
Good morning Prosys Forum!
We are having some OpcUa related discussion with one of our customers.
Originally there was the idea that there is an ‘application’ (which is an OpcUaClient) which communicated to a ‘device’ which acts as OpcUaServer. The device provides the process data and the appplication subscribes to it and provides the data.
On further discussion it came up, that the device also has to inform the application about things like material was placed on the device, has started processing, material has finished processing and also that the device request recipe information from the application.
We were talking also about that the device may send out events for this type of infomations and the application reacts to this events by calling methods on the device. As we found out, that device software is not capable of sending out OpcUa Events – so this seems to be not an option right now.
But, the device can be OpcUaServer and also be OpcUaClient.
So finally the idea came up to implement the application to be OpcUaClient and also an OpcUaServer as also the device to be OpcUaServer and Client at the same time.
This would lead to the situation, that the application can call methods on the device and the device can also call methods on the application.
The question now is if this is something what is expected to do with the concepts of OpcUa or if this would be some kind of ‘exotic’ setup to let the application be Client and Server and also to let the device be Server and Client simultaneously?
Thank you & have a nice day!
14:13, EEST
Moderators
November 28, 2018
Offline
Hi!
When Events are not supported by OPC UA Client or Server, you can “emulate” them by creating a status variable in the Server and then subscribing to this Node. In your case, you would possibly have a Node of type String, and whenever processing starts you would write to this Node “Processing started” and so on. When the status changes, the new value would then be received in the Client side with Subscription and the functionality would be close to Events.
This is a somewhat common scenario that comes up when dealing with devices, and I suggest you to think if the solution above is also applicable in your scenario 
If, for any reason, it doesn’t make sense in your case, you may also implement both Client and Server on both sides as you proposed. It’s completely possible, but with this knowledge of the use case it seems that it could be solved with a more simple solution.
19:57, EEST
March 16, 2017
Offline
Hi, thanks for your reply.
let me comment to your thoughts…
>> you can “emulate” them by creating a status variable in the Server and then subscribing to this Node
>> If, for any reason, it doesn’t make sense in your case
>> with this knowledge of the use case it seems that it could be solved with a more simple solution
I know, for me this kind of ’emulation’ for the missing event functionality on the device side makes totally sense. I would also have suggested such kind of communication handling, because it seems a simple solution.
BUT 😉
The customers argument is that they did this already many years ago when doing such things with OPC DA or ModBus interfaces to have some kind of status variable to emulate an event mechanism.
Now as they have OPC UA, they like to do it – let’s say – in a more ‘sophisticated’ way. As their device does not support sending out events via OPC UA, but the device is an OpcUa server and is also capable of being a OpcUa client, they came up with the idea, that the counterpart can maybe also act as Client and Server.
Personally I do not really like this idea when I think about that in such a case, the device always has to know for which application it is working.
In the kind of industry where I’m mainly working, the normal way is to have an ‘application’ which is connected to devices, and other manufacturing system like material tracking systems, database storages and other high level system which will manage the process flow through a fab. Typically such ‘applications’ have different fail over mechanism, clustering, … (whereas the device is always running on the same place) – so normally the application is the only one who knows to which systems and devices it is connected.
This works fine if we assume that the application is the OpcUa Client and the device is the OpcUa Server. In case that the device and the application are both togehter Client and Server, there is the problem, that the device always has to know where the application is running.
E.g. application is running on system A1 and the device is running on system D, everthing is good. But if the application process is switched because of a failure of system A1 to another system A2 then there is the problem, that the device if it reacts as client is no more possible to connect to A1 – so someone has to reconfigure the device to connect to A2. On the other hand, if the device is only the OpcUa Server, it does not matter if the application runs on A1 or A2 because the application is an OpcUa Client and can in any case always connect to the device which is running on system D.
I’ve read a little bit of the idea of both systems are beeing server and client at the same time in following blog article – https://www.rtautomation.com/rtas-blog/opc-ua-client-vs-server/ – but I do not know if this is something which more theortical or can be applied in practice. I’m sure it would be usable unless you’ll think about such kind of failover mechanism, redundancy, …
14:02, EEST
Moderators
November 28, 2018
Offline
Yeah, thanks for the explanation and it’s nice to see you have also been speculating about different architectural approaches of OPC UA since sometimes you can achieve a certain task in various ways. As you mentioned, having Client and Server on both the application and the device seems to create new drawbacks in your case, possibly some that cannot be solved in a sophisticated way either. Just to start, you pretty much double the amount of connections in your system when you make it bidirectional. Is this really more elegant than using status nodes to emulate events? We for sure don’t know all the details about your case, and this forum is not the exact place for general OPC UA consultation. It’s pretty much up to you and your customer to really test and understand the benefits and limitations of both options. I hope you take the time to think about the solution and find the best one for your needs 🙂
19:18, EEST
March 16, 2017
Offline
Teppo Uimonen said
I hope you take the time to think about the solution and find the best one for your needs 🙂
We’ll do 😉 – I think we’ll go for using status nodes to emulate events right now. Maybe they will add support for having events later.
Thank you!
Most Users Ever Online: 518
Currently Online:
11 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
hbrackel: 135
pramanj: 86
Francesco Zambon: 81
rocket science: 77
ibrahim: 75
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
fred: 41
Member Stats:
Guest Posters: 0
Members: 685
Moderators: 16
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1467
Posts: 6259
Newest Members:
fidelduke938316, Jan-Pfizer, DavidROunc, fen.pang@woodside.com, aytule, rashadbrownrigg, christi10l, ahamad1, Flores Frederick, ellenmossModerators: Jouni Aro: 1009, Otso Palonen: 32, Tuomas Hiltunen: 5, Pyry: 1, Petri: 0, Bjarne Boström: 983, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 26, Teppo Uimonen: 21, Markus Johansson: 42, Niklas Nurminen: 0, Matti Siponen: 321, Lusetti: 0, Ari-Pekka Soikkeli: 5
Administrators: admin: 1
