I work at Inductive Automation (a SCADA/HMI compan...
# science
k
I work at Inductive Automation (a SCADA/HMI company) and I’m also the lead for the Eclipse Milo. If you have any questions about OPC UA stuff I can probably help 🙂
a
Thank you very much. Currently I am researching a way to better communicate with DOOCS system used in DESY: https://doocs.desy.de/. It is not quite open and is written in old C++. So using modern Milo seems to be easier than creating C++ wrappers on top of Sun onc
k
I don’t know how much it will help in this case. OPC UA provides data modeling capabilities and agreed upon communications/security/service layers, but all by itself OPC UA (and Milo) doesn’t somehow help you connect to PLCs or other legacy systems. The most common use for OPC UA in the past, and possibly still now, is essentially as a protocol conversion gateway, where legacy and possibly undocumented protocols are exposed via OPC UA, but somebody still has to write that conversion layer and understand the old protocol.
as a client, consuming data, this is a win, because you only need to have an OPC UA client
but you still have to find somebody who has built an OPC UA server product that can convert the system you’re interested in getting data from to OPC UA.
a
The thing is that DOOCS already supports opc-ua client. My idea is to make an OPC-UA server as a communication frontend. We mostly need only simple data structures. The idea of Controls.kt is exactly to patch the problem, you've mentioned - to create simple drivers for legacy/non-compliant devices and to expose data in some kind of universal format.
And the next step is to connect them to OPC-UA compliant systems
k
👍
h
@kevinherron Is there an actual project documentation beyond the repo landing page for Milo?
k
there’s some WIP docs in the wiki for the client SDK: https://github.com/eclipse/milo/wiki/Client