OPC UA vs socket programming

user_9404007 0
Viewed 139

A factory has a MES (manufacturing execution system), and I have a machine. The factory wants to use their MES to control my machine (start/stop producing, etc.) and monitor real-time manufacturing data (such as how many products produced).

To be short, the goal is:

MES ---controls--> machine
MES <--reports data---  machine

Be noted that My machine already has a .NET WinForm application (deploying the MVP pattern), which contains all the business logic, and could be easily used by workers offline. To meet the factory's need, I have to do some upgrade/transform to my .NET code.

After some investigation, I found 2 possible ways to achieve the goal:

  1. let my machine acts as an OPC UA server, let MES to adapt to my machine
  2. use socket programming to communicate between MES and the machine

I don't have any experience in either of the 2 methods above, so could you please tell the pros and cons of each? Or is there a third better way?

opc-ua sockets .net
4 Answers

If your machine has a built-in OPC UA server and your MES can act as an OPC UA client then point 1 is a good solution.

If, on the other hand, you have to program an OPC UA server on your machine, forget about it, it is a very difficult job, since OPC UA is surely the most complicated of all most common industrial protocols.

If raw socket programming is used then you have to define your own protocol and that's like reinventing the wheel.

Perhaps you could choose to use a simpler industrial protocol, for example Modbus TCP.

user_76903760

OPC UA is the preferred option in long run. It may seem may seem quite extensive, and there is a bit of a learning curve, but that's because it comes with a lot of features built in (Security, Address Space, Read, Write, Method Calls, Data Changes, Events, Alarms, History Read, etc.). You won't, of source, need all of these right away, but you also don't need to use more than you need.

For .NET, you can use the OPC Foundation Standard Stack, which provides you implementations of most of the stuff. It is free (GPL for non-members), but lacks documentation, so you might like to consider commercial options.

Especially, if you wish to make connections from MES easy and reliable, it does not really make any sense to define your own socket protocol. This will take a lot of your time, is error-prone and in the end, you will be the only one who can debug the problems with it. And in the end, you will probably need to figure how your MES could use your protocol in practice.

There are obvious benefits in sticking to a standard solution.

user_12828350

I got some experience with OPC UA and must admit that it has a very steep learning curve. Jouni Aro is right with his answer. But a third option would be another existing protocol that may have less features but is easier to use, like MQTT for example. There are plenty of open source implementations available for nearly every language.

user_40922400

Assume you have a classic OPC server as well besides OPC UA from your vendor, here comes a simple and flexible solution, WebSocket4OPC. It uses http and supports different programming languages. It uses JSON as return so it is easy to parse with existing libraries. Most importantly there is ZERO learning curve comparing with clumsy OPC UA since you are dealing with http/JSON instead of DCOM. I agree with from56 that OPC UA is the most complicated industrial protocol - thinking about its thousands page documents. I don't think there is any reason your MES can't talk to it through http/JSON. Cheers!

user_197212610
Related