What are communication protocols?

  • In short, it is your trusty old but sophisticated pigeon with pre-written rules (Protocols) flying from one computing system to another carrying a message. These rules are specifically to direct this pigeon with instructions on what route to take, who not to fly to and so on. Some of these widely known pigeons in the modern day are named Wi-Fi, HTTPS, MQTT and so on.
  • Communication protocols are formal descriptions of digital message formats and rules which are required to exchange messages in or between computing systems maintaining consistency and universality for the sending and receiving of messages.
  • Before successful transmission can take place, networked communications devices must agree on many physical aspects of the data that is to be exchanged. Rules defining data transmissions are called “protocols.

Why do we need them?

  • Consider a scenario where an Industrial machine is controlled by an actuator, we program a PLC (Programmable Logic Controller, the brain of the machine in this case) to communicate with the actuator in the language (Communication Protocol) that it understands. In addition, the PLC needs additional information from other sensors in the car to make sure the car is driven safely which is done so by using the same protocol or a different one.

What is in them?

  • There are many properties of a transmission that a protocol can define. For example, properties addressed with protocols may include:
    • Packet size.
    • Transmission speed.
    • Error correction types.
    • Handshaking and synchronization techniques.
    • Address mapping.
    • Acknowledgment processes.
    • Flow control.
    • Packet sequence controls.
    • Routing.
    • Address formatting
  • Popular protocols include File Transfer Protocol (FTP), TCP/IP, User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), Post Office Protocol (POP3), Internet Message Access Protocol (IMAP), Simple Mail Transfer Protocol (SMTP). There are various protocols established for specific Industries and machines.
  • Here we narrow down the protocols essential to our focus towards Industrial Automation

Manufacturing Protocols:


  • MTConnect agents and their corresponding device adapters are simply small computer programs that work together so that MTConnect can enable equipment and networks readily connectible. Adapters enable existing shopfloor devices “to speak MTConnect,” and agents enable MTConnect messages and data files to be transmitted across a network to MTConnect-compatible applications.
  • It is an HTTP based protocol (which makes them usable on internet-enabled networks) MTConnect is described as a set of open, royalty-free standards intended to foster greater interoperability among machines, devices, control systems and software applications. It is a standard developed to translate machine tool data into a common, internet-based language interpretable by software applications. We can say that MTConnect is a standard that deals with making data Actionable
  • MTConnect is best suited for equipment with standardized functions, such as CNC controls or other equipment that has known capability.
  • MTConnect is read-only, where nothing can be written back to the machine, but it is Extensible (that is, more terms can be defined and added to its dictionary)
  • MTConnect provides a standard dictionary of data items. The advantage is that the vocabulary is consistent across all equipment, regardless of which machine tool builder is involved. For example, by looking at “execution,” an MTConnect data item, the state of the machine can be readily known, no matter what type of machine generates data with this label. This consistency makes it easy for machine-monitoring software to show which machines on a network are running or not running.
  • MTConnect requires someone to develop the MTConnect adapter, which is the software that collects the data from the machine and formats it for the MTConnect agent. The MTConnect agent, in turn, enables the data to be accessed by analysis and reporting software. MTConnect adapters may not be available for distinct types of machine tools or CNCs. (It should be noted here that, in some cases, OPC UA has been used to acquire data, which can then be provided to an MTConnect adapter for standard formatting.


  • Like MTConnect, OPC-UA is also an HTTP based protocol, named so because the Open Platform Communications (OPC) organization designated its protocol for industrial communication as the Unified Architecture (UA). It is a nonproprietary set of specifications that ensures that automation systems are compatible with one another. We can say that OPC UA is a standard that deals with making data Available
  • OPC UA is best suited for one-off integration projects that use programmable logic controllers (PLCs).
  • OPC UA can be a read-write protocol
  • OPC UA does not have a standard dictionary. When using OPC UA, it is necessary to know the address (or addresses) within the PLC where the running state (the equivalent to “execution”) is stored. This data location is likely to vary across diverse types of equipment. The end user will need to research to find where it is and may need to process the data to derive the desired result. This makes it more difficult for software to report whether the machines or devices are running.
  • A driver is needed for OPC UA to retrieve data from the PLC. This driver is a software utility written specifically for this purpose to be used on a specific device. OPC UA drivers are readily available for many PLCs from a variety of vendors.


  • MQTT is a lightweight, publish-subscribe network protocol that transports messages between devices. The protocol usually runs over TCP/IP; however, any network protocol that provides ordered, lossless, bi-directional connections can support MQTT. It is designed for connections with remote locations where a “small code footprint” is required or the network bandwidth is limited
  • The MQTT protocol defines two types of network entities: a message broker and several clients. An MQTT broker is a server that receives all messages from the clients and then routes the messages to the appropriate destination clients. An MQTT client is an end application (from a micro controller up to a fully-fledged server) that runs an MQTT library and connects to an MQTT broker over a network
  • The MQTT broker is software running on a computer (running on-premises or in the cloud) and could be self-built or hosted by a third party. It is available in both open source and proprietary implementations.
  • The broker is analogous to a post office, MQTT does not use the address of the intended recipient but uses the subject line called “Topic,” and anyone who wants a copy of that message will subscribe to that topic. Multiple clients can receive the message from a single broker (one to many capability). Similarly, multiple publishers can publish topics to a single subscriber (many to one).
  • Each client can generate and receive data by publishing and subscribing, i.e., the devices can publish sensor data and still be able to receive the configuration information or control commands (MQTT is a bi-directional communication protocol). This helps in both sharing data, managing, and controlling devices.
  • With MQTT broker architecture, the devices and application become decoupled and more secure. MQTT uses Transport Layer Security (TLS) encryption with user name, password protected connections, and optional certifications that requires clients to provide a certificate file that matches with the server’s. The clients are unaware of each other’s IP address.

The main advantages of MQTT broker are:

  • Eliminates vulnerable and insecure client connections
  • Can easily scale from a single device to thousands
  • Manages and tracks all client connection states, including security credentials and certificates
  • Reduced network strain without compromising the security (cellular or satellite network)

Message types

  • Connect: Waits for a connection to be established with the server and creates a link between the nodes.
  • Disconnect: Waits for the MQTT client to finish any work it must do, and for the TCP/IP session to disconnect.
  • Publish: Returns immediately to the application thread after passing the request to the MQTT client.