LDS is a bit different case, though, since it's not a proper OPC UA Server and typically only used locally to locate the actual servers from client applications.

Opcua client (field) -> fw -> opcua gateway -> fw ——> Internet ——-> fw-> opcua gateway -> fw -> opcua server, opcua gds, opcua LDS (Data centre)

On the server side, you have still the option to disable the hardening, until March 2023.

Once the hardening is applied, only clients that have been updated respectively, can connect. But as said, te latest version of UaGateway should work fine.

You can check this article that I wrote for more details.

I need to come back at this issue since Microsoft's hardening of DCOM connections seems to have more impact than I thought at first.
It is not entirely clear to me whether UAGateway will continue to work remotely when the hardening requirements are enforced?
And I understand I need to change the DCOM configuration at the server side, but do I need to do anything at the UAGateway side?

Thanks,

Reinier

Remote DCOM is not tested on UaGateway and is out of the scope for warranty or our technical support. Additionally, Microsoft is hardening DCOM connections in Windows due to security concerns, which makes DCOM connections even more troublesome. See https://opcfoundation.org/foru.....om-update/ for more details. Therefore, the generic recommendation is to always install UaGateway in the same computer with the OPC DA server.

However, with proper configuration, DCOM technically works on UaGateway. You can find some instruction on how to create a connection between a remote OPC COM DA server and UaGateway at https://documentation.unified-.....m_sec.html. Please note that this instruction is only intended to provide hints for the "out-of-support" use case and does not guarantee a successful DCOM connection.

To my great distress I found in the documentation (section Limitations) of the latest version (1.5.10) of the UA Gateway a blown up version of the earlier:
No Remote DCOM Connections
Apparently I wasn't the first to have missed the old two-liner version of this section (or why would blow it up with a hure picture and more warning texts)
To my knowledge this quite severe limitation is nowhere else mentioned. It is also quite odd, as the whole idea of DCOM (D for Distributed) is to have remote connections.

The text however is less definitive than the old one. Actually the new text doesn't say it cannot be done, just that it isn't supported.
Which means that someone knows, at least to some extend, how it can be done.

My problem is that I cannot place the UAGateway at the same server as the OPC server. There is a categorical NO there.
So if no remote connection is possible, UAGateway is useless to me and I have wasted quite a lot of money on it.

So my question is whether anyone can help me with or give me a hint or a direction to search on how to accomplish a remote DCOM connection.

In general, you should be able to connect an OPC UA Client to a OPC UA Server. You might need to open some ports in the PLC's and the laptop's firewalls to make sure the applications can send messages to each other. Besides that, you should be able to connect to the Server by using its address in the Client. Are you having trouble connecting your applications?

Is it possible to connect a Phoenix AXC1050 PLC (OPC UA Server) Sierra RV50 Modem directly to a Laptop with TIA Portal Professional Scada (OPC UA Client).
And is there something special which I should keep in mind while setting this up? 

Thanks in advance! 🙂

1. Your server might support OPC DA and HDA. However, according to OPC Specifications, a server can't support both DA and HDA at the same time. They would be considered as 2 different servers (OPC DA server + OPC HDA server) from the OPC Client's point of view.

2. UA Gateway doesn't support writing history to an OPC HDA server. Reading the history should definitely work with UA Gateway. OPC HDA defines a couple of interfaces where some of them are mandatory and some are optional. UA Gateway supports IOPCHDA_SyncRead but not the optional interface IOPCHDA_SyncUpdate. Uisng UA Expert or Prosys OPC UA Client/Browser makes no difference.

3. If you are able to read historical values and browse the tags via UA Gateway, then it's functioning properly. You can ignore #3.

First a note that OPC Classic is not my personal expertise, but this is a combination of my interpretations and I did also ask Unified Automation (that develops the UaGateway) about this, a better answer might arrive later, but this is what I can do for this now. Thus some questions and notes:

1. It is not possible to have a Classic OPC Server that would support both DA and HA, they are different specifications and servers by the nature of OPC Classic (that is one of the reasons why OPC UA was made). Thus, I believe that they would be separate servers added to UaGateway, if this "OSISoft PI HDA" would actually also have a DA server in addition to a HA server. IF that is the case, maybe the other tool can somehow give the assumption of a single server, but in reality it would have both as a separate connections.

2. What do you mean by "Write" here? An OPC UA Write? Because that cannot never work to a HA server, there is no concept of a "Write" as OPC UA Write in HA (only in DA). There is a IOPCHDA_SyncUpdate in HA for updating the history data, though that per Unified is an optional interface that UaGateway doesn't support. It only support the IOPCHDA_SyncRead that is used to read the history. Did you mean IOPCHDA_SyncUpdate?

3. Could it be possible to produce a trace of UaGateway showing that attempt to read (AppTrace=Data, StackTrace=Debug). If is, send it to support@prosysopc.com and a note that I'll probably need to share that info with Unified Automation.

I'm at a loss here, there is no documentation available on how to solve this problem and our client is asking for a rapid solution, please provide some assistance!