| Re: [milo-dev] what is the best practice of build a opc ua server with milo? |
_______________________________________________Hi,
If heartbeat exists between OPCUA client and server in milo? I have a problem about reconnection mechanism that when the OPC UA server does not work and normal again, how does the client reconnect to OPCUA server?
Thanks!
Regards,
Tony
From: milo-dev-bounces@xxxxxxxxxxx <milo-dev-bounces@xxxxxxxxxxx> On Behalf Of Kevin Herron
Sent: Saturday, August 24, 2019 07:29 PM
To: milo developer discussions <milo-dev@xxxxxxxxxxx>
Subject: Re: [milo-dev] what is the best practice of build a opc ua server with milo?
I'm not sure there's any reason to implement your own NodeManager.
It's not possible to implement your own SessionManager and plug that into the SDK right now.
On Fri, Aug 23, 2019 at 7:50 PM 黄超 <longren239368608@xxxxxxx> wrote:
actually, I think I should implement all the methods, because the data can be modified by other systems. Browse, Read, Write, Subscription.. All of them should be implemented. That is plenty of work. And I found I should create a subclass of ManagedNamespace, and implement my own NodeManager and SessionManager. I don't know if it is correct.
At 2019-08-23 19:37:49, "Kevin Herron" <kevinherron@xxxxxxxxx> wrote:
also* used, not always used.
On Fri, Aug 23, 2019 at 4:37 AM Kevin Herron <kevinherron@xxxxxxxxx> wrote:
I should mention I've always used a hybrid approach, where I create UaNodes to model everything, but still override read() and write().
When the attribute is Value I do something special like read from or write to a PLC, but for any other attribute I just read/write from the UaNode like the managed address space implementation would.
On Fri, Aug 23, 2019 at 4:27 AM Kevin Herron <kevinherron@xxxxxxxxx> wrote:
You seem to have a pretty good grasps of the tradeoffs between the 2 approaches.
When there's too much data being modeled to reasonable fit into memory I use approach #1 - override the read() and write() on AttributeServices interface (which is part of AddressSpaceServices interface). This requires more work but allows you to implement reads/writes in such a way that you never even have to have an instance in memory of UaNode for the NodeId being read from or written to.
In fact, you'll notice all of the APIs you implement from AddressSpaceServices allow for this possibility. The SDK was carefully designed to minimize the amount of *required* nodes you keep in memory.
This makes things more difficult to implement though, which is where approach #2 comes in - use UaNodes for everything and let the ManagedAddressSpace implementation handle reads and writes against the nodes. When you do this approach you have to either install a bunch of AttributeDelegate (or AttributeFilter in 0.4 branch, which replaces deprecated AttributeDelegate), or handle syncing data from your external system to the UaNode instances periodically so that the data is refreshed.
Unfortunately there's no public example of approach #1 demonstrating a "real life" system, but I'm hoping to have one by the end of the year.
On Fri, Aug 23, 2019 at 2:21 AM 黄超 <longren239368608@xxxxxxx> wrote:
I am working on a poc of opc ua server demo with milo. I have a backend system that is already running, and I want to make it an opc ua server. Other opc ua clients can commucate with this server using services defined in opc ua spec such as addNodes, read, write, browse, query, call method, createSubcription...
I encounts some problems, and I have some questions:
1. when receives `read` requests from clients, how the server obtains data from my existing backend system? Choice-1, with implementing some interfaces or overriding some methods, when the server receives `read` requests from clients, it can invoke overriding methods to read real data from backend system. I tried it, but found it difficulty. Did I find a wrong way? Choice-2, Read the data from backend system to the ua server's memory with `write`, then no methods would be overrided. In this case, all data would be loaded into memory.
2. If the best practice is choice-1, what should I do? What interfaces should be implemented?
3. If the best practice is choice-2, huge data would be the new problem. It is not a good idea to load them all into the memory.
4. If all data is loaded into memory, when original data changes, sync will be another problem.
_______________________________________________
milo-dev mailing list
milo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/milo-dev
_______________________________________________
milo-dev mailing list
milo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/milo-dev
milo-dev mailing list
milo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/milo-dev