Log In
Register
Forum
Topic RSS
11:58, EET
October 17, 2013
Offline
Hi im looking into how to provide some query and listening services as a service in my application. So what i first of all wonder about:
Do I have create a client to be able to query the data through the server? Or is this something the server can open up itself?
The difference here is if I have to create a small client for providing query services to my OSGi application? Or if the server itself can export an interface towards methods that may query the standarized data on the server?
12:40, EET
December 21, 2011
Offline
I am not sure if I understand what you mean. Do you mean the OPC UA QueryService or something of your own?
18:11, EET
October 17, 2013
Offline
Im sorry if im not clear.
But by Query service to mean the service that the server provide to cients with the AddresseSpace.browse(nodeId) and all its possibilites?
What I wonder is, for me to get a hold of this service and provide my own API for spesific hardware, as an OSGi service interface, do I have to start up a OPC-UA client to be able to provide the service or is it something that the OPC-UA server can provide.
I will try to create my own API which i register as a service in OSGi, but the I have to implement this service somehow. And this implementation i wonder if have to rely on the client or if the server SDK can provide this?
Is it alittle bit more clear now?
8:14, EET
December 21, 2011
Offline
OK, I am still a bit uncertain what you are trying to do, but I try to answer 
In the server code, you can use the NodeManager objects to access the nodes that are in the server. The browseNode is a protected method, though, but you have getNode() and findNode() available – and if you are using UaNode objects, you can get the references from the node objects directly.
So you should not need to use an UA client inside your application to access the (internal) server information, if that is what you ask.
11:09, EET
October 17, 2013
Offline
Yeah I dont know if you are familier with OSGi but I just try to figure out how I can solve that issue.
Ok, so browsing the server throuhg the mentioned way here, is just as easy as using a client and addresseSpace?
You dont have any limitations browsing internal information?
One can receive the same information as a client can?
What do you think is the best way?
11:24, EET
December 21, 2011
Offline
Well, yes, all the information is in the server anyway The interfaces are a bit different, but I think you should be able to get to all the information. The node objects are the easiest way to browse the address space in the server. For example, you can get the Root folder from UaServer.getNodeManagerRoot().getRoot() (there are also getObjectsFolder(), getTypesFolder(), getViewsFolder() and getServerData()) and start browsing via UaNode.getReferences().
12:22, EET
October 17, 2013
Offline
Well that is ofcourse true:)
But what about listeners such as serverstatuslistener and eventlisteners. Would it be easier to go through a client to get served update information from the server on a listener basis? Or are there any way to do this directly to the server aswell?
13:15, EET
December 21, 2011
Offline
Well, in principle the events and data changes occur, when your server generates them. So you should already have that information available before the events are triggered, in principle.
The StatusListener is only useful for the client, since it’s monitoring the connection status to the server. On the server side you can monitor the client sessions using the SessionManagerListener, which you can plug into UaServer.getSessionManager().
Or maybe you are thinking that since your UA server will be an independent module in the server application, you would use UA to communicate to other modules in the server application. That is of course a useful pattern and in that case it might be usable to just create an UaClient to the other modules. Sounds interesting I don’t think anyone else has thought about such a design yet.
10:30, EET
October 17, 2013
Offline
Yeah that is understandable that the server produces them, but its not thought of an easy way to get a listener to these events?
You are very correct in that assumption. We are trying to design it so that the UA-server is an independent module with self designed services that allows for new hardware to be deployed to this station, without any form of restart of the system. It should also have services which provide opportunities to control the state of the server incase something happens to the current station.
There will be different type of applications using different data from the server, and having listeners on different objects. And each application\module should then maybe have a client each communication with a spesific node and subnodes in the server.
Im trying to create this as modularized and dynamic as possible using OSGi and something called Reactive Blocks, writing a thesis about it. To figure out if these technologies can solve different problems when combined.
But to browse in a complex addresse space it would be nice to have some client functionallity right?
Aswell I wonder if a client is needed to be able to use gateways to for example use ‘out of the box’ OPC classic to OPC-UA gateways to attach “old” sensorsystems\types?
10:39, EET
October 17, 2013
Offline
Also, what do you think would be a nice pattern. One OPC-UA server per station or one per hardware connected?
As for addresse spaces, I thought that maybe one root addresse space and then one new addresse space for each type of hardware, but which is populated down from root in this sense “rootSpace/” then hardware “rootSpace/hardware1” and “rootSpace/hardware2”
8:16, EET
December 21, 2011
Offline
Yes, I think an OPC UA client will be the most dynamic alternative. In principle you should be able to use UA for various things with its versatile information modeling techniques. Also you can use the UA client to connect traditional OPC servers (via the UaGateway, for example).
And yes, it is easier to work with a single server, which has a “complete” model than with several servers. You can define the address space structure so that it best describes your system design. If you are working with field devices, for example, you should take a look at the Device Information model as well.
17:01, EET
October 17, 2013
Offline
Jouni Aro said
Well, in principle the events and data changes occur, when your server generates them. So you should already have that information available before the events are triggered, in principle.
Or maybe you are thinking that since your UA server will be an independent module in the server application, you would use UA to communicate to other modules in the server application. That is of course a useful pattern and in that case it might be usable to just create an UaClient to the other modules. Sounds interesting
Jouni, can you confirm that it would be more difficult to use the OPC-UA server to browse its own address space, rather than providing each module with an client to browse with? Because you mentioned here that it would work in principal but is more facilitaded for the client than the server?
8:04, EET
December 21, 2011
Offline
vonGohren said
Jouni, can you confirm that it would be more difficult to use the OPC-UA server to browse its own address space, rather than providing each module with an client to browse with? Because you mentioned here that it would work in principal but is more facilitaded for the client than the server?
Well, on the server itself you just need to do a bit differently. So it rather depends on how exactly you wish to provide the information and to what. The UA interface is anyway a clear definition how to do it and it is available for the “internal” clients the same way as for other clients. But I admit that I have not probably understood the complete picture you have in mind yet very well.
19:24, EET
October 17, 2013
Offline
Wow, I just wrote a long post and pushed post. I had not logged in so i had to do that. Bam my post was gone! That sucks! Dont know if its inside some database somewhere, but it did not get posted.
But what i basically wrote was that im working with an ITS station architecture. it will have multiple applications doing different things installed. Where each application can be dependent on multiple hardware. One ITS station will have one server running, which holds the datamodel for each hardware. Think that would be the proper solution
Some important aspects for us is robustness, upgrading and expantion. The reason why we are using OPC-UA is for easy communication and proper standarization towards the hardware part.
So an example is that we have an aplpication which consists of a sensor and a light. There is applicaiton logic which is dependent on states and events from these two hardwares. Since we have the connecetion Hardware–>Datamodel–>OPCUA server, the question is then how to we get the data out to the logic abstraction.
This could have been done by generating OSGi services that the OPCUA server implemented, meaning that we could browse and listen to events this way. Then there would be alot of modules using the same service\opcua server implementation.
Or we could try to create an opcua client service which could connect to the different hardware datamodels and react on events and get data when wanted. Then we could abstract the logical level by using services that provide the data, events and methods from the client.
Does this make sense?
My questions was then if you think it would be smarter to go for the client osgi service way, or create a complicated service for the server which would be used instead?
11:07, EET
December 21, 2011
Offline
Yes it makes sense. But it’s difficult to say which exact architecture would be correct for you. I am afraid you need to sort it out yourself depending on the details of your system. It might even be a good idea to prototype with different alternative architectures.
Most Users Ever Online: 518
Currently Online:
17 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: 681
Moderators: 16
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1467
Posts: 6259
Newest Members:
DonaldPooma, fidelduke938316, Jan-Pfizer, DavidROunc, fen.pang@woodside.com, aytule, rashadbrownrigg, christi10l, ahamad1, Flores FrederickModerators: 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
