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:
- let my machine acts as an OPC UA server, let MES to adapt to my machine
- 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?
CodePudding user response：
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.
CodePudding user response：
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 rights 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.