MBLogic
for an open world in automation
Communications Basics
Overview
The abilty to communicate with other devices is at the heart of all control systems. A control system must be able monitor and control sensors and actuators if it is to do any useful work. MBLogic is based on the idea of open communications allowing better integration among automation systems.
Networking Basics
A communications network is a means of connecting devices together to allow them to communicate with each other. Two devices can communicate if they can exchange information and understand each other. A network is formed when you have two more more devices communicating.
Client - Server
Devices which communicate with each other can relate to each other in different ways. The most common is what is called "client-server". The client sends a "request", and the server answers with a "response". In other words, the client asks a question (request), and the server answers it (responds). If the client doesn't make any requests, the server doesn't respond.
This is a simple and robust means of communication. Another way to look at is is to imagine how you use a web browser to surf the internet. When you click on a link, you send a "request" to a web server asking for a web page. The web server sends you the web page you asked for and then patiently waits for the next request.
Client-Server vs. Master-Slave
In industry the term "master-slave" is often used. The "master" device issues a command, and the "slave" device responds to it. What is the difference between "client-server" and "master-slave" protocols? There isn't; they are identical. The different terms arose for historical difference, with "master-slave" originating in industry, and "client-server" originating in the computing/IT field. With industrial automation adopting technologies which originated in the computing/IT field, the term "client-server" is replacing the older "master-slave".
Just remember: server = slave, and client = master.
Ethernet Networks
Ethernet
At one time, industrial networks were based on a variety of RS-485, proprietary, and other hardware. However, as has already happend in the computing/IT world, Ethernet is replacing these older technologies.
Ethernet is an open standard. However it only defines some of the hardware and the rules used for accessing it. It doesn't by itself allow devices to actually talk to each other. In order for that to happen, you need to define what is known as a "protocol". Without a common protocol, you have some wires joining to devices together without any way for these devices to talk to each other.
Protocols
TCP/IP Protocol
When many people talk about Ethernet, they also talk about TCP/IP. TCP/IP is a protocol which operates on Ethernet (as well as on some other types of networks) and acts to get the bundles of data where they need to go. However, Ethernet does not automatically mean TCP/IP. In fact, many proprietary industrial protocols do not use TCP/IP.
TCP/IP looks after getting bundles of data to their destinations. However, although it is by far the most common protocol of its type, it isn't the only one. There is another type called UDP. The difference between TCP and UDP is that TCP tracks the data to make sure it gets where it is going, while UDP sends the data on its way and more or less hopes it gets there. In practice, there is little difference in overall reliability between the two, with the choice of one over the other being a matter of technical detail. This isn't a detail that most users have to worry about however. They just use whichever form their application chose to implement.
Application Protocols
TCP/IP and UDP can get the data where it is going, but they don't tell the recipient what the information means. For that, you need an application protocol. A good way of looking at this is you might dial someone on the telephone, you might get a connection, and you might hear their voice, but no real communication is going to take place unless you both speak the same language. An application protocol is a common language which both devices can "speak".
Proprietary vs. Open Networks
Are Ethernet Networks Open?
There is a lot of confusion about whether or not a network is "open" or not. Many people assume that if it uses Ethernet or TCP/IP it must be "open". Nothing could be further from the truth. Unlike in the computing/IT world where most proprietary networks faded away years ago, proprietary networks are still common in the industrial market. Vendors have moved to Ethernet to take advantage of the lower cost of Ethernet components and cables, not to allow their customers to connect their systems to those from other vendors. Proprietary protocols still act as a barrier to control systems working together. What matters is whether the protocol is open, not just whether the hardware is compatible.
When is a Protocol Open?
A protocol is "open" when anyone is free to implement it. That is, when anyone can get a copy of the specification and make their own implementation of the protocol without having to get permission from anyone else. Many vendors keep their protocols secret and protect them with patents and other restrictions. They may license these protocols to selected strategic "partners", but they don't allow just anyone to talk to their equipment.
What Does This Mean?
You may be wondering what the relevance of the above is to you. The reason it matters is because it means you have to know something about what protocols your hardware uses before you know whether you can get two different things to work together. Unfortunately, that is more a matter of vendor politics than a matter of technology. Device 'A' and device 'B' may both use Ethernet, but device 'A' won't be able talk to device 'B' if vendor 'B' doesn't want to get along with anyone else.