OPC UA package? ( Open Platform Communications Unified Architecture)

Is there a Julia version of python-opcua or something equivalent?

2 Likes

Not that I know of. About four years ago I had Julia program that called a Python opc package through PyCall as a proof-of-concept that we never pursued further (I can’t remember which Python package it was). Back then I wasn’t surprised that Python had the package and Julia didn’t.

Fast-forward to today, I’m actually surprised I can’t find a Julia package for this; I’d half expect to find one that was further along than Python. MATLAB has had opc-ua for ages, and over the past four years, Julia’s package ecosystem has become generally better at covering MATLAB functionality than Python, especially in anything related to the process control space. All these packages are excellent and very useful for industrial data science and (advanced) process control:

They even have a lot of this wrapped up in their JuliaSimControl product. All this and yet no straightforward way to provide an opc-ua connection to make all these amazing tools to seamlessly talk to the outside world. It’s really quite a shame to have all this great stuff metaphorically locked away in a box with no easy opc-ua protocols (although it’s kind of a weak box, you can always call another language to implement the opc-ua communication). It just seems like it would be a natural fit to the Julia ecosystem though.

1 Like

I think this is a general problem. Julia is mostly academic and you can’t write a paper about an OPC-UA package or an interface for a DB.

Well, how do people go about this? Import data through OPC and matlab/python? Then feed back through matlab/python whatever needs controlling? Seems a little, well, hacky.

Anyone wanting to start a project on this?

Probably this would be a good starting point https://www.open62541.org/

I suppose one would first create a JLL package for the open62541 library before making a julia interface/wrapper package?

I guess someone tried that already: https://github.com/JuliaPackaging/Yggdrasil/tree/master/O/open62541

1 Like

Yes, and here’s the jll: JuliaBinaryWrappers/open62541_jll.jl (github.com)

It’s for a Aug 2021 version and as far as I can tell ( open62541_jll · JuliaHub) it has no dependents.

So, first step would be to maybe update the JLL and then think about a wrapper package? I’ll see what I can get done regarding the former this week. (I never did that before, so if there’s someone willing to volunteer who did it before: be my guest :slight_smile: ).

This might just require changing the version and GitSource SHA

name = "open62541"
version = v"1.3.7"  # <-- updated to v"1.3.7" (Sept 7 release)

# Collection of sources required to complete build
sources = [
    GitSource("https://github.com/open62541/open62541.git",
              "b8ac9e77f703e6ba5c012b886a8821037503daa6"), # <-- updated
    DirectorySource("./bundled"),
]

The author of that Yggdrasil build_tarball.jl also seems to have an unregistered wrapper package on their personal GitHub page: GitHub - martinkosch/open62541.jl: A Julia wrapper for the open62541 open source implementation of OPC UA

Ok, updated the jll package to the latest release of open451, link as above. Turned out that some tweaking was necessary (removing the outdated patches etc.).

I’ll fork the .jl package later and will give it a brief test with this new version of the jll.

Also will contact the original author. Maybe there is some scope of moving the package to an organization.

1 Like

Hi. I am also interested in the OPC-UA for Julia. Is there any development or plans related to this topic? I can help (at least with testing).

Hi,
I made some progress after my last post. Turns out that the wrapper package didn’t work anymore with the new open62541 versions that I got onto Yggdrasil (which wasn’t as straightforward either - as usual, I guess).

Then spent some time to improve the wrapper package (open62541.jl mentioned above). Focussing on automating and cleaning up code generation, introducing very primitive tests (essentially testing against some of the tutorials on the open62541.org website) and fixing some bugs.

I am now close to being able to push an update to the wrapper package. Trying to get there by end of this week :slight_smile:

The original author has also been kind in replying to my issue post on the wrapper package. So, there is some scope to getting things rolling!

3 Likes

Just an update: the original author, Martin Kosch, and I are working on a PR. Mainly introducing tests and adding some basic functionality. Status is visible here: Thomvet patch by thomvet · Pull Request #5 · martinkosch/open62541.jl · GitHub

1 Like

We merged a PR that brings the package back to a usable state.

There will be some more improvements necessary before we are cutting a release and register it in the General registry. Not least of all, we will have to generate some documentation and usage examples, because right now the documentation exists of only the automatically generated docstrings (via Clang.jl, i.e., these are comments that are in the C header file…) - very barebones obviously.

Also, a warning: At the moment, we are exporting everything, so the API surface is huge and we would technically have lots of breaking changes. There’s a discussion to be had what we want to export. Work in progress :slight_smile:

If you want to start using it, that’s of course welcome, but thread carefully and do expect things to break for now. :slight_smile: