Design Guide Lines for Implementing High Performance Communication Between PLC and PC using Network Sockets.

Network Sockets is a technology that is available in all PCs and some PLCs for quite some time, unfortunately due to the lack of integration between OT and IT this technology and its capabilities are not explored as it could be...

• I have been working in a way to efficiently communicate PLCs to PCs for data exchange, data collection and processing and frequently hear from the OT engineers that we need a gateway to promote this communication between the two devices even when both devices are ethernet capable...
• Indeed this is not entirely true if both devices are network capable and have "Socket Communication Functionalities", the direct communication besides reducing the failure points between the two communicating devices also improves the communication performance.
• With good network programming technics on both sides we can achieve high performance communications between PLC and PC with no extra hardware in between; For this post I'm considering the network socket communication functionalities available in some PLCs and the Sockets APIs available in both Windows and Linux operating systems.
• Both Windows and Linux multithread application models (Windows IOCP or Linux Epoll) combined with Sockets programming allows for codding very high performant Socket Server applications capable of ingesting data from several PLCs simultaneously.
• Some PLC Makers including Siemens with it's Open User Communications model present in their Simatic Step 7 Series PLCs offer a Socket communication model and functions which allow us to build up very performant Socket applications on the PLC side, by using Socket communications we are able to achieve communications with data sampling and transference in the order of milliseconds which sometimes is not possible using PLC gateways and other higher level protocols.
• The points listed below are some hints and key points to observe when designing and implementing an application to communicate a PC to a PLC using network sockets:

1. Select UDP in favor of TCP as the socket transport protocol: This might seems to be controversial as UDP is not reliable and is not connection oriented, but the fact is that it is fast and simpler to implement than TCP; and even if you use TCP you will need to implement some kind of "handshake" between the Client and the Server to guarantee that the data sent was received by the communication partner; That said why not to implement this "handshake" as part of the application protocol and use the speed and reduced overhead of the UDP communication!
2. Consider using a Load Balance mechanism on the Server Side: This will help you to guarantee that no data will be lost and you can scale out if needed; UDP is not connection oriented and is ideal for using along with Windows NLB or any other load balancing mechanism.
3. Consider Using ODBC: Most of the time the data communicated needs to be persisted on the server side, consider using a Database with support to ODBC protocol, this will simplify and make the data persistence layer of your application flexible.
4. Consider some kind of buffering on the PLC Side: Most of modern PLCs offer a Memory Card and data Read and Write utility functions, keep in mind that ethernet connections might fail and that a buffering mechanism on the PLC side is crucial to avoid data loss in case the connection between the PLC and the socket server fails.
5. Consider buffering also on the Server Side: Connections between the Socket Server and the Database server might also fail, so it is necessary to consider a data buffer on the server side to receive the data from the PLC and store it locally in case the database is offline by some reason. (Patching and Updates, Network Failure, Cluster Service Failover, etc...)
6. Design a flexible and robust Data Structure to communicate: Remember that PLCs are not so powerful and flexible as PCs, consider using a good data structure capable of collecting all kind of information you need to exchange, most modern PLCs are capable of defining User defined Data types which makes the information exchange between PLC and PC much more easier, consider using an event driven architecture when implementing PLC data collection.
7. Data Types and Flexibility: Flexibility is a key point in the data structure design and PLCs, PCs and Databases can deal with flexible data types; Don't make assumptions regarding the data types, be prepared to store several different data types and do not have prejudice against the "infamous" VARIANT data type, if well used it can solve some difficult data storage problems.
8. Data Endianness: Be aware that PLCs and PCs might have different byte endianness and you will need to provide conversions preferably on the PLC side when the data types communicated are larger then a byte, remember that socket communication data flow happens in network byte order.
9. Memory Management: Pay careful attention to the memory management functions and if you use C++ for the Server application coding prefer using RAII (Resource Acquisition Is Initialization) Paradigm to avoid memory leaks, communication control loops normally runs very fast and failing in deallocating allocated memory can lead to an unusable PC or server very quickly.
10. Programming Paradigms: Prefer a State Machine Paradigm to program the PLC side of the application, it will make your live easy to debug and implement changes in the future.

• If you have experience in this or other related fields, please share it with me, if not and is starting, I hope this guidelines help you in your journey. I'm interested in all topics related to Industry 4.0, M2M, AI, ML, Databases, Machine Sensors and Data Collection and other related technologies.