The Future of OPC UA

Hello,

Here we are interested in OPC UA as we are planning to build a complete new fabrication building.

OPC UA will be the standard in the future for communication between ERP, MES, SCADA and PLC. At this moment a Siemens 1500 PLC can be OPC UA server allready, however, connection of 2 1500 PLC's with OPC UA is not possible at this moment because a TIA PLC can only be OPC UA Server.

A question I had... What is OPC UA gonna replace and what is purpose.
The way I see it, it connects PLC's devices, MES, SCADA, ERP etc... data that is not critical. To control a drive, profinet is still needed, realtime devices that give remote IO and so on still need a fieldbus.

What is OPC UA going to do in the future, will it also do some things in the realtime layer or are we still going to stick with fieldbusses for connecting sensors to a PLC and will OPC UA only be there to make a unified network ?

Thanks for the info in advance,
Kind regards,
Gerry

OPC UA is supposed to be as you describe, a universal protocol on the higher-level.
It is not supposed to be a deterministic field-bus.
Maybe someone could use OPC UA as a field-bus anyway, in the same way as in the past before Profinet and Ethernet/IP, some people used TCP/IP as a "field-bus". Which worked OK if everyone had discipline and refrained from misusing the network.
OPC UA has added functions for security and redundancy that OPC DA does not have, so the data may be critical, but it cannot be deterministic.

It is true that S7-1500 can only be OPC UA servers for the moment, but there is nothing that stops Siemens from developing OPC UA Client for S7-1500.
If you need today to connect an OPC UA client to several S7-1500, then you have to use Simatic Net as the OPC UA server.

Beckhoff has an OPC UA component for their Twincat PLC that can be both server and client.

I think it is a matter of time before OPC UA gains critical mass, and when that happens we will see that all intelligent devices becomes OPC UA servers, and CPUs becomes OPC UA servers and clients.

You can register for free in the OPC Foundation and download the UA specifications. Part 1 has an extensive explanation of the fields of use.

To take in account that OPC UA specs define many services but most implementations only offers a part of them and surely the S7-1500 does not offer all.

Best Regards.

I just hope that it will be the standard and not yet another standard.

As others have said, OPC UA isn't intended to replace the fieldbus, its more for the supervisory communication. Right now, every vendor has proprietary protocols that HMIs need to develop drivers for. In the future, OPC UA could replace just about all of that, IF everyone plays nice. I don't really see any standards out there competing with OPC UA right now (except the old OPC DA), so that's a good thing.

Something that I see interesting, though, is that the OPC Foundation and Profinet International signed an agreement to create a working group to get Profisafe over OPC UA in some future spec.

https://www.profibus.com/newsroom/n...the-networking-of-machines-becomes-fail-safe/

[FONT=&quot]https://www.pc-control.net/pdf/032014/products/pcc_0314_twincat3-soa-sps_e.pdf[/FONT]

My small and recent experience with OPC UA:

For years I have written several C ++/Java libraries for SCADA to PLC communication with various protocols, Modbus serial & TCP, Profinet, several OMRON and Mitsubishi protocols etc.

During the last few months I have been studying the specifications and practicing with OPC UA, I am still far from having any functional code but I think I can highlight the following from OPC UA:

- Complexity: Far above the before mentioned protocols:
- Security: With its encryption capabilities and multiple verifications, if used correctly, it can work safely on the WAN
- Ease of configuration on the SCADA side: The SCADA programmer does not need to know the positions of tags in the memory of the PLC, she/he simply navigate through the server node tree and choose the desired ones.
- Speed: It may seem that the complexity + encryption will slow down the data transfer, but it is a minor thing compared with OPC UA's ability to read or write hundreds of variable values ​​of different mixed data types in a single request, not necessary they occupy correlative memory positions in the PLC. For example, a large SCADA monitoring screen with one hundred or more tags can be updated with a single request, if they all come from the same OPC UA Server. The requests sent or received to/from the server can be up to 4MBytes size and if the sending or receiving buffer is not big enough OPC UA has the ability to split/rejoin the request into several chunks.

I have a lot to learn still but day after day I am more convinced that OPC UA is the way to follow in the future, at least for PLC to SCADA comms

Regards.