Added OPC UA server support

[guqinchen]

Mapped all Modbus I/O (discrete and analog) to OPC UA server.

[thiagoralves]

I just skimmed through the code and it looks really good! It appears to be in sync with the current OpenPLC coding scheme. Thank you for the contribution! Just two quick questions:

1. Both Modbus and DNP3 standards define that inputs are read-only from the protocol. I’m not familiar with OPCUA, so I don’t know what is the right approach for this, but I noticed that your code has inputs with what appears to be only write permissions (opcua.cpp lines 137-152 and 174-185)

2. Have you tested this on all three platforms (Windows, Linux, and Raspberry Pi)? If not, I’ll test it first and then merge.

[guqinchen]

@thiagoralves In my understanding, the OpenPLC takes inputs from the OPC UA server, which may be set by a sensor device or simply software; conversely, after the PLC program executes based on the inputs, the outputs are updated in the OPC UA server for actuators to read. Thus, I have set the inputs as writable (and also readable by default), and outputs as read-only, as they can only be updated by the PLC program.
I haven't tested this on all three platforms. I would appreciate if you can test it. But feel free to remove the support for Windows/Raspberry Pi and other non-Linux platforms for now.

[epgodoy]

Even though the operation described by guqinchen is interesting for other applications, in my opinion, the OpenPLC must use the input values from the physical PLC inputs. And the OPC UA should be used for monitoring purposes.

[thiagoralves]

@guqinchen The operation you described is more suitable for the Slave Devices module. This module currently uses Modbus to communicate with slave devices, and therefore reads their inputs and update their outputs, just like you described. However, this module only has access to a small portion of the OpenPLC address space (%IX100, %QX100, etc), and not the whole thing. As @epgodoy explained, it is not wise to let OPCUA applications overwrite what OpenPLC is reading through its physical inputs. If you want to use the whole address space like Modbus and DNP3 protocols are doing, you must change the OPCUA implementation to be a slave instead of a master, i.e. software will connect for monitoring purposes.

[thiagoralves]

Just to get back on this, it seems that the operation described by @guqinchen is more suitable for a Hardware Layer than a protocol addition. From my understanding, this code is using data from an OPC Server as internal I/O. That's exactly what a Hardware Layer does. The slave devices support on OpenPLC is very similar to this, but instead of using OPC, it uses Modbus. It was added as a Hardware Layer (file modbus_master.cpp)