Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
Application and Device are Server and Client at the same time (is it a common practice to do so?)
April 29, 2020
9:53, EEST
Avatar
rocket science
Member
Members
Forum Posts: 21
Member Since:
March 16, 2017
sp_UserOfflineSmall 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!

April 29, 2020
14:13, EEST
Avatar
Teppo Uimonen
Moderator
Members

Moderators
Forum Posts: 20
Member Since:
November 28, 2018
sp_UserOfflineSmall 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 Smile

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.

April 29, 2020
19:57, EEST
Avatar
rocket science
Member
Members
Forum Posts: 21
Member Since:
March 16, 2017
sp_UserOfflineSmall 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, …

May 6, 2020
14:02, EEST
Avatar
Teppo Uimonen
Moderator
Members

Moderators
Forum Posts: 20
Member Since:
November 28, 2018
sp_UserOfflineSmall 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 🙂

May 27, 2020
19:18, EEST
Avatar
rocket science
Member
Members
Forum Posts: 21
Member Since:
March 16, 2017
sp_UserOfflineSmall 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!

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 267

Currently Online:
14 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 100

pramanj: 86

ibrahim: 69

kapsl: 57

gjevremovic: 49

TimK: 41

Fransua33: 39

fred: 36

Rainer Versteeg: 32

Thomas Reuther: 26

Member Stats:

Guest Posters: 0

Members: 1037

Moderators: 14

Admins: 1

Forum Stats:

Groups: 3

Forums: 14

Topics: 968

Posts: 4078

Newest Members:

NilsonChalie, markblue523, savannah3880, darrenyo, pokapoka95, roscoedomingo7, kathrinrohde588, aleidamott69222, mp, corinapzx0505

Moderators: Jouni Aro: 845, Otso Palonen: 32, Tuomas Hiltunen: 5, janimakela: 0, Pyry: 1, Terho: 0, Petri: 0, Bjarne Boström: 508, Heikki Tahvanainen: 402, Jukka Asikainen: 1, Teppo Uimonen: 20, Markus Johansson: 15, Matti Siponen: 18, Lusetti: 0

Administrators: admin: 0