In this guide we cover the background, history and specifics of communications protocols used in industrial automation applications.
High-speed communication of various devices and software systems is the key component of any industrial automation system. You could even say that real-time data exchange and coordination of tasks between different network elements is the essence of process control and automation in general.
In light of the above, it seems appropriate for us to talk about standards and protocols that enable efficient communication of multiple devices from different vendors.
Communication protocols is a whole separate field of computer science, with a long and complicated history (full of “wars” between researchers and market players) and a long list of protocols and standards that have been published since the 1970s, designed for various applications and technology types.
In this article, we are going to mostly talk about the communication protocols that are used in industrial automation applications and thus, are the most relevant to the current users of Clarify or anyone looking for knowledge in our field.
A communication protocol is a combination of rules utilized in the process of data exchange of various network devices and software systems. Communication protocols normally incorporate a list of all formal requirements and standards, including syntax, restrictions, procedures, error recovery, and synchronization of communication.
Communication protocols in network data exchange are utilized with the same purpose as programming languages in computations. Similarly to programming languages that use syntax (a set of command words, phrases, punctuation, context and other structural elements) to define a single standard of instructions for computation processes, communication protocols specify how network devices should interact with each other. You can also compare the protocols to algorithms instead of programming languages.
In industrial automation, communication protocols are being used by both hardware and software solutions, as well as combinations of both.
There is a large variety of structural patterns for data exchange that can be used in network communication protocols. When it comes to industrial communication protocols, the two patterns that are used most commonly are “request–response” and “publish-subscribe.”
Request–response pattern
Request-response is one of the most commonly used messaging patterns in industrial communication protocols and network communications in general. In line with this model, a client, or caller, which can be a computer, software solution or other network device, requests data or services from a server (or responder) — any server or software that can provide the data).
Publish-subscribe pattern
In the publish-subscribe pattern, messages aren’t transmitted from one source to another directly, with an intermediary node being used instead. Senders of messages, or publishers, categorize the data into classes and direct it to the intermediary node where they can be distributed to corresponding receivers, or subscribers.
Some other messaging patterns commonly used in industrial communication protocols are asynchronous messaging, various types of multicasting pattern, queues, message brokers, etc.
In order to establish functional information exchange between different components of a modern industrial automation network, a number of various communication protocols is typically required. A group of related protocols that were designed to work together, enabling different aspects of communication, are called protocol suite or protocol stack (also sometimes being called a protocol family).
To make the design and implementation of communication protocols easier and simpler, they are frequently designed to serve only a very narrow purpose or to enable communication between a certain set of network components. Each communication protocol typically communicates with at least two others, which is why specific protocols within a single protocol suite are structured in the form of layers. The lowest layers in the stack are typically responsible for hardware communication, with every new layer adding additional capabilities and network environments.
Origins of the communication protocols term can be traced to the second half of the 1960s. First records describing communication protocols are related to ARPANET (U.S. Advanced Research Projects Agency Network), the first public computer network, initially launched in 1969 and finally decommissioned in 1989. The 1822 protocol was implemented on the ARPANET as a starting point, defining the transmission of messages to an IMP (Interface Message Processor).
In 1970, the Network Control Protocol (NCP) was implemented on the ARPANET. NCP was one of the earliest examples of protocol layering as NCP’s interface allowed software solutions to connect with each other across ARPANET networks by leveraging higher-level communication protocols for these purposes. The Transmission Control Program (TCP) was formulated in 1970 as well (by researchers Robert E. Kahn and Vint Cerf).
The development of the X.25 standard, based on virtual circuits by the ITU-T, in 1976 was another major milestone in the history of the communication protocols field. Over the years, major computing hardware manufacturers developed their own proprietary protocols, such as Xerox Network Systems and Systems Network Architecture (SNA) by IBM.
In 1982, the US Department of Defense declared TCP/IP as the standard communication protocol for all military computer networking. TCP/IP was installed on SATNET (an early satellite network that formed an initial segment of the Internet) in 1982 and on the ARPANET in 1983. Over the course of the 1980s, TCP/IP was gradually developed as a complex modular protocol suite, which became a core component of the emerging Internet.
The so-called Protocol Wars is a period, which lasted roughly from the 1970s to the early 1990s, when different parties in the international computer science community, including individual researchers, groups of scientists and organizations, continuously had a heated debate about the choice of a communication protocol suite that would support the best network performance.
Essentially, the Protocol Wars were a battle of two fundamental communication standards architectures: TCP/IP, developed by the United States Department of Defense (DoD), and interface standards developed by computer researchers in Europe, mainly the U.K. and France — X.25 standard first and OSI Standards later.
Origins of the “conflict”
The debate about communication interface standards for computer networks began in the early 1970s, when the global computer science research community first faced the need to come up with a universal set of communication standards that would allow various hardware and software components in a computer network to exchange information with each other.
Originally, it was a conflict of visions and approaches to communication infrastructure in general between the pioneers in computer science and telephone companies, mainly in the U.S. and the United Kingdom. AT&T in the U.S. and PTT (Postal, Telegraph and Telephone service) in the U.K. had a monopoly on communications infrastructure and understandably wanted to stick to the traditional use of already built communication infrastructure for phone calls and other established telegraphic techniques.
Pioneering scientists and researchers in the emerging computer science field — such as Paul Baran in the U.S. and Donald Davies in the U.K. — were pushing for an innovative concept of packet switching in data communication networks, when information would be divided into message blocks and sent over distributed networks.
TCP/IP against X.25
An early version of the Transmission Control Program (TCP), which preceded the TCP/IP protocol, was formulated in 1974. The research for a universal network communication protocol was supported by the ARPANET infrastructure, and ARPANET researchers were part of the International Networking Working Group, created to form a protocol for internet working. The International Networking Working Group also included experts from European Informatics Network, French CYCLADES project and British scientists working on the NPL network.
Researchers from different international organizations and groups aimed to jointly agree on an end-to-end protocol standard. But the debate between supporters of two different approaches to data communication — datagrams and virtual circuits — turned the processes into what Computerworld magazine in a report about the process of forming a standard interface for packet-switched communication networks, described as "battle for access standards."
European PTTs developed and promoted the X.25 standard based on the virtual sockets concept, as opposed to the datagrams approach.
A few words about these two approaches to data communications.
What is the datagram concept?
In line with the datagram mode, a connectionless datagram service transmits each data independently of other packets.
What is the virtual circuits concept?
Virtual circuits, on the other hand, is a connection-oriented approach, with virtual circuits transporting packets between terminals in sequence. Virtual circuits emulate physical circuits and don’t need to contain any routing information for better channel efficiency.
The Transmission Control Program, which incorporated both connection-oriented virtual sockets and datagram services, in 1978 was split into two protocols, adding the Internet Protocol (IP) as a connectionless layer.
What is TCP/IP or the Internet protocol suite?
The protocol (originally it was named IP/TCP) in its 4th version was installed on SATNET in 1982 and on the ARPANET in 1983 and became a standard networking model now known as TCP/IP (also sometimes referred to as DARPA model, ARPANET model or Department of Defense (DoD) model.
Eventually TCP/IP, containing multiple protocol layers and utilizing different approaches to data communication, became known as the Internet protocol suite.
What is the OSI model?
The OSI (Open Systems Interconnection) reference model was defined in the late 1970s and published in 1984. It provides a foundation for the coordination of ISO standard development from the purpose of system interconnection. In the OSI model, communication interfaces are organized into seven abstraction layers:
Internet vs. OSI standards
The Internet protocol suite utilizes a different architecture, combining the physical and data link layers of the OSI model into a single link layer. Additionally, the Internet protocol suite has one application layer for all protocols as opposed to application, presentation and session layers in the OSI model.
The debates around the most appropriate basic protocol model were especially heated, which allowed historians of this field of computer science to ultimately dub the period that lasted from the late 1980s to mid-1990s the Internet–OSI Standards War.
The “war” was ultimately won by the Internet protocol suite that continued to expand and eventually evolved to IPv6, which remains the most recent version of the standard. The OSI protocols reference model didn’t get such wide popularity and adoption. Nevertheless, it still remains relevant and is used today in certain fields such as cloud computing. The X.25 standard also did not disappear completely and has applications in some market niches.
When it comes to automation of work processes, both industrial and in other fields, the number of protocols used to establish effective communication of machines, devices, and software solutions is quite significant. Which is understandable given the variety of automation technologies and large number of specific applications within industrial automation.
Let's review some of the most notable and established industrial communication protocols that you need to be familiar with primarily.
MQTT (Message Queuing Telemetry Transport) is a lightweight publish-subscribe network protocol that transports messages between devices. MQTT was designed for remote locations and connections with high-latency, low-bandwidth and unreliable networks.
MQTT is one of the main messaging protocols used in IIoT (Industrial internet of things) systems.
Due to its simplicity and flexibility, today MQTT is commonly used in embedded environments for machine-to-machine communication and becoming a de-facto standard open-source protocol for connecting IoT devices.
Brief history of MQTT protocol
The first version of the MQTT protocol was created in 1999 by Andy Stanford-Clark and Arlen Nipper, engineers working for IBM. The original goal of the project was to create a new—lightweight and bandwidth-efficient—messaging protocol that could be used to monitor oil pipelines within the SCADA industrial control system, eliminating the need for expensive satellite link connections that were utilized for these purposes at the time.
In 2013, IBM submitted MQTT protocol (v3.1) to the OASIS (Organization for the Advancement of Structured Information Standards), which is a non-profit consortium supporting open data standards across various tech fields, such as IoT, robotics, and cloud computing. OASIS released MQTT (v3.1.1) as an open standard in 2014. A more substantial upgrade to MQTT version 5 was released by OASIS in 2019.
The naming of this protocol can look somewhat confusing, as the full version—Message Queuing Telemetry Transport—isn’t exactly accurate. The original name of the protocol was MQ Telemetry Transport, where the ‘MQ’ came from IBM MQ (Message Queueing) line of products. The MQTT protocol, however, relies on a publish-and-subscribe messaging architecture and doesn’t use queues at all. When submitted to OASIS, the formal name of the protocol was MQ Telemetry Protocol (MQTP), but in the related documentation it was most commonly referred to as MQTT, which is why the protocol kept this somewhat misleading name.
What is MQTT Sparkplug?
MQTT Sparkplug is an open-source software specification that provides MQTT clients with an interoperability protocol to seamlessly integrate data from various applications, devices, sensors and other elements of MQTT infrastructure. The specification was initially developed by Cirrus Link and is managed today by the Eclipse Foundation as part of the Eclipse Tahu project.
Sparkplug was designed specifically for IIoT applications based on MQTT, to be a common language for IIoT systems. It was released in 2015 as a specification that defines how to use MQTT in a mission-critical, real-time OT (operational technology) environment. An MQTT broker responsible for distributing the data is required to use Sparkplug.
Sparkplug provides all the components of IIoT systems with a common data format and specifications on how specific data should be received, published and interpreted, allowing both hardware and software parts of IIoT solutions to exchange data in a fully secured environment. Sparkplug requires TLS for all data transport and having no open ports for new devices. This protocol also allows the integration of data from non-MQTT devices and other popular industry protocols like OPC UA and Modbus.
OPC (Open Platform Communications) is a platform-independent suite of communication protocols. Based on the OLE (Object Linking and Embedding), COM (Component Object Model), and DCOM (Distributed Component Object Model) technologies developed by Microsoft for its Windows operating systems, OPC was designed primarily for the process control in industrial automation applications but is widely used for other purposes as well.
Brief history of OPC
The protocol was originally created in 1996 under the name OLE for Process Control by a task force that was formed by several industrial automation vendors — Rockwell Software, Opto 22, Fisher-Rosemount, Intellution, and Intuitive Technology — with a goal to develop a single standard of data access protocols for their devices.
The OPC Foundation, a non-commercial association of industrial automation companies that creates and maintains standards for open connectivity, was founded in 1994. Today, the OPC Foundation continues to manage various aspects of the OPC standards, including compliance, certification and interoperability.
Since the OPC standard has quickly gained adoption across industrial automation applications beyond just process control, in 2011 the OPC Foundation changed its name to Open Platform Communications.
About OPC
The OPC standards define the protocols of communication for various kinds of industrial automation devices and software systems, including sensors, PLCs, SCADA (supervisory control and data acquisition) systems, HMI (human-machine interface) solutions, etc. The OPC specification covers all layers of data access and exchange in an industrial automation network, such as process data, historical time series data, alarms and events.
OPC Data Access is the most frequently used OPC specification. It is utilized for real-time data exchange between network nodes in an industrial automation network. OPC HDA (Historical Data Access), used to establish the exchange of historical process data, is another OPC specification maintained by the OPC Foundation.
Other specifications that are part of OPC standards are OPC Alarms and Events, OPC Batch, OPC Data eXchange, OPC Security, OPC XML-DA, OPC Complex Data, OPC Commands, and OPC Certification.
The OPC UA, an entirely new platform-independent set of communication standards, is another widely used protocol maintained by the OPC Foundation.
OPC Unified Architecture (OPC UA) is a platform-independent service-oriented machine-to-machine communication protocol for industrial automation developed by the OPC Foundation. OPC UA combines the functionality of the individual OPC Classic specifications into one extensible framework.
History of OPC UA
The first version of OPC UA was released by OPC Foundation in 2006. The goal of this project was to extend the original OPC communications model—which was mostly focused on COM/DCOM architecture—with new specifications that would be more relevant to the industrial automation needs. The architecture of OPC UA is service-oriented (SOA) and is based on different logical levels.
About OPC UA
COM/DCOM communication standards used in the OPC model had a number of weaknesses that were the main driver of the decision to develop a new protocol. Some of the main issues of COM/DCOM were poor security, support of Microsoft Windows systems only, and configuration issues with DCOM.
OPC UA was developed as a platform-independent and fully secure protocol that is also easily scalable, supporting comprehensive information modeling and including all COM OPC Classic specifications mapped to unified architecture. OPC UA incorporates multiple hardware platforms, including PLCs, micro-controllers, PC, and server hardware, as well as various operating systems, such as Windows, Linux, Android, and iOS. OPC UA servers are scalable down to 15 kB RAM and 10 kB ROM, which makes them usable at chip level.
Strengths and weaknesses of OPC UA
Thanks to its multi-layered architecture, OPC UA provides an easy way to incorporate innovative technologies and solutions, such as new encoding standards, security algorithms, transport standards, etc., without disrupting backwards compatibility for existing products. This allows the manufacturers of OPC UA based devices to make sure their solutions will be compatible with new products added in the future.
One of the most fundamental elements of OPC UA is the information modeling framework that is used to define rules and basic elements necessary to expose an information model with OPC UA. The protocol also defines necessary access mechanisms to information models.
Security is another strength of the OPC UA protocol compared to the OPC model. It is firewall-friendly and supports session encryption, authentication, user control, message signing, user session auditing and other features addressing security concerns.
Some of the disadvantages of OPC UA is overcomplexity and issues with enabling full interoperability of the systems. Full OPC UA protocol specification consists of 14 documents, 1250 pages-long in total. The majority of existing implementations of OPC UA are incomplete due to this complexity. Additionally, OPC UA supports several serialization formats and allows selective implementation of some services. This makes it difficult to develop client applications that are truly platform-independent.
The OPC UA protocol keeps evolving, however, and is viewed by the OPC Foundation more as a stage of standardization of machine-to-machine communication for industrial automation rather than an established standard.
Developed by Modicon company back in 1979, Modbus is a data communications protocol that was originally designed to be used with Modicon’s programmable logic controllers (PLCs) and over the time became a de facto standard communication protocol for industrial electronic devices. Today, Modbus can be seen as a common way of connecting a plant/system supervisory computer with a remote terminal unit (RTU) in supervisory control and data acquisition (SCADA) systems in industrial automation solutions.
Brief history of Modbus protocol
Modicon company is known as the creator of the first programmable logic controller (PLC) in the United States in 1968.
Modicon was formed in 1968 by Bedford Associates Group, which consisted of four engineers—Dick Morley, Tom Boissevain, George Schwenk, and Jonas Landau—who had just invented the Modular Digital Controller. The invention was a result of Bedford Associates winning a proposal for an electronic replacement for hard-wired relay systems requested by GM Hydramatic (the automatic transmission division of General Motors).
After calling their invention of a new controller, Bedford Associates decided to start a new company, named Modicon, which stood for MOdular DIgital CONtroller. The new company was established to focus on developing, manufacturing, selling, and servicing this new product.
Features that made original Modicon digital controllers a market success were their rugged design, modular inputs/outputs (I/0), which made it easy to connect a wide range of field devices, and a new programming language, called Ladder Logic. The new language simulated the behavior of the relay contacts and coils that were already familiar to industrial process engineers.
The term PLC (Programmable Logic Controller), describing the devices of this kind, was coined several years later, in 1971, by Allen-Bradley, another legendary brand of industrial automation equipment.
In 1977, Modicon was acquired by Gould Electronics who subsequently sold it to AEG in 1989. In 1994, AEG and Groupe Schneider merged to form AEG Schneider Automation, which became solely owned by Groupe Schneider in 1996. Groupe Schneider was renamed as Schneider Electric in 1999.
In 2004, Schneider Electric gave up its ownership of Modbus and transferred it to Modbus Organization, an association of users and suppliers of Modbus-compliant devices, created for the promotion and development of Modbus protocol.
What is the Modbus Organization?
The Modbus Organization, headquartered in Massachusetts, is a nonprofit, membership-based trade association of users and suppliers of Modbus-based automation devices. The organization members include automation equipment suppliers, system integrators, end users, open source developers, educators and other parties. It was formed to support the Modbus protocol, drive its adoption, provide information and tools for individuals and companies using Modbus, and to address architectures for distributed automation systems across multiple market segments.
The Modbus Organization maintains the modbus.org website with information about Modbus, its applications and certifications required to simplify the implementation of this protocol. The organization also engages in various activities related to the maintenance and proliferation of Modbus, including maintaining and evolving a conformance testing program to insure greater interoperability of Modbus devices, as well as educational and promotional efforts.
About Modbus
Originally designed to be used with Modicon’s newly invented Modular Digital Controller and published as an open and royalty-free protocol, Modbus soon became a de facto standard communication protocol in industrial environments.
Modbus gained popularity in industrial applications due to its simplicity and lack of restrictions, which made it easy to deploy and maintain Modbus communication compared to other standards. When it comes to the transport layer, Modbus supports Ethernet, the Internet protocol suite, and character serial communication lines. The protocol also allows the communication of multiple devices connected to the same Ethernet network or a cable.
Today, Modbus is commonly used to connect a plant/system supervisory computer with a remote terminal unit (RTU) in supervisory control and data acquisition (SCADA) systems in the electric power and other industries. There are multiple versions of the protocol for different kinds of connections. They include Modbus RTU (Remote Terminal Unit), Modbus ASCII, Modbus TCP/IP, Modbus over UDP, and other variants.
Interestingly, there is also the Modbus Plus protocol, which is not a version of Modbus but a separate protocol that involves token passing. The rights to Modbus Plus belong to Schneider Electric.
What is Modbus Security protocol?
In 2018, the Modbus Organization announced the publication of the Modbus Security protocol. The new protocol provides robust protection through the blending of Transport Layer Security (TLS) with the traditional Modbus protocol. TLS encapsulates Modbus packets to provide both authentication and message-integrity protection. The new protocol leverages X.509v3 digital certificates for authentication of the Server and Client.
AMQP (Advanced Message Queuing Protocol) is a binary, open standard application layer protocol designed to enable rapid communication between all message-oriented middleware. AMQP supports a wide range of messaging applications and communication patterns and provides flow controlled communication with message-delivery guarantees.
Brief history of AMQP
The project to develop AMQP was initiated by the investment bank JPMorgan Chase in 2003 as an open effort to develop a universal application layer communication protocol. The initial work on the new protocol was conducted by JPMorgan Chase till 2006 with some help from third-party contractors.
In 2005 JPMorgan Chase started approaching a number of large technological companies, such as Red Hat, Cisco Systems, Microsoft and other big players, to form a co-operative working group for the development of AMQP protocol in collaboration. Red Hat was one of the earliest partners to join JPMorgan Chase in this project. In 2005, Red Hat also started the development of Apache Qpid, an open-source messaging system that implements AMQP.
Eventually, the AMQP working group included 23 companies: JPMorgan Chase, Red Hat, Microsoft, Barclays, Goldman Sachs, Cisco Systems, Credit Suisse, Deutsche Börse, Bank of America, VMware (it acquired Rabbit Technologies which was also a part of the group), HCL Technologies Ltd, Progress Software, IIT Software, INETCO Systems Limited, Informatica, my-Channels, Novell, Software AG, Solace Systems, StormMQ, Tervela Inc., TWIST Process Innovations, and WSO2. In 2011, the AMQP working group was reorganized into an OASIS Technical Committee on AMQP. OASIS is a nonprofit consortium that works on the development, convergence, and adoption of product-independent standards in various technology fields.
First early version of AMQP (v.0.8) was released in June 2006, followed by a number of other releases over the next two years. AMQP 1.0 was released in 2011 at a conference in New York, followed by a demonstration of software solutions running the protocol that were developed by Microsoft, Red Hat, VMware and a number of other working group members. AMQP was approved as an OASIS open standard in 2012. In 2014, AMQP was also approved as an ISO and IEC International Standard.
About AMQP
Even though AMQP was initiated by JPMorgan Chase as a protocol primarily for the financial services industry, it is broadly applied across industries and in a wide range of middleware solutions.
As the AMQP protocol was designed to enable a wide range of communication patterns and messaging applications, the AMQP specification is defined in a number of layers, such as type system, a performance protocol for transferring messages from one process to another, a standard message format, and messaging capabilities.
AMQP is a wire-level protocol, which is a way of getting data from point to point by sending it across the network as a stream of bytes. This allows any tool to create, receive and interpret such messages regardless of the implementation language. Some of the most notable features of the AMQP protocol is flow controlled communication with message-delivery guarantees and the support authentication and encryption based on TLS (Transport Layer Security) protocol and SASL (Simple Authentication and Security Layer) framework.
There are a number of other open protocol specifications that are viewed as an alternative to AMQP. One of them is MQTT (Message Queuing Telemetry Transport), a lightweight publish-subscribe network protocol that transports messages between devices. Others include JMS (Java Message Service), STOMP (Streaming Text Oriented Messaging Protocol), XMPP (Extensible Messaging and Presence Protocol) and OpenWire.
CAN (Controller Area Network) bus is a message-based protocol that was originally designed for applications in the automotive industry, but it can be used in various technology fields. CAN bus was created to allow various devices and microcontrollers inside a vehicle to exchange information with each other directly, without using a host computer as an intermediary.
Brief history of CAN bus
The CAN bus protocol was developed at Robert Bosch GmbH (commonly known as Bosch). German engineering and technology conglomerate. Designed for multiplex electrical wiring — to reduce the need for copper wires in automobiles, — CAN bus was officially released in 1986, with first CAN bus controller chips released in the following year. The International Organization for Standardization (ISO) released the CAN standard ISO 11898 in 1993.
CAN 2.0, published in 1991, was the last numbered specification of this standard. The Bosch company, however, continues to use and extend this standard to this day. In 2012, they released CAN FD 1.0 (CAN with Flexible Data-Rate) specification. Compatible with existing CAN 2.0 networks, CAN FD relies on a different frame format, which allows a different data length and faster bit rate.
About CAN bus protocol
The CAN bus is a two-wired communication protocol. Designed to be used in passenger vehicles, buses and trucks, today the CAN bus protocol is also commonly applied in many other kinds of equipment and machinery. To name a few, CAN bus is used in vessels and other maritime equipment, in elevators and escalators, in construction automation systems, in medical equipment, in lighting control solutions, etc.
CAN bus is among the five protocols that are part of OBD-II (on-board diagnostics) vehicle diagnostics standard, which in 1996 was made mandatory for all automobiles and light trucks sold in the U.S.
One of the key distinctive features of the CAN bus is that it is a broadcast type of bus. In a CAN network, data is transmitted to all the nodes, including gateways, microcontrollers, sensors and other devices. Since CAN bus is a message-based protocol, each message across devices carries an identifier used to decide on priority. The data in a frame is submitted serially for each device, but if a number of devices transmit information at the same time, the identifier allows to establish the highest priority device, which gets to send the message ahead of others.
Today CAN bus is most commonly used to enable communication between various systems and subsystems in modern vehicles. Automotive systems communication via a CAN bus network include cruise control, electric power steering, transmission, audio systems, mirror adjustment, doors, windows and many others.
Profibus (Process Field Bus) is a family of communication protocols built on top of a standard field-bus technology bundle. Originally developed in the end of the 1980s by German computer systems researchers and manufacturers, Profibus is one of the oldest communication standards, still widely used in the industrial automation field to this day.
Brief history of Profibus
The development of Profibus was a public initiative by the association of more than 20 German electronic systems manufacturers, such as Siemens, and social institutions such as BMBF (German department of education and research). Started in 1986, the goal was to create a universal field bus based on the basic requirements of the field device interfaces, and to promote its use by global industry players.
The Profibus User Organisation (PNO) was formed in 1989, mainly composed of German companies and institutions. In the following years, a number of regional Profibus and Profinet Associations (RPAs) were established, mostly across Europe.
In 1995, the Profibus and Profinet International was established as a single international entity that incorporates all RPAs. Today, Profibus and Profinet International are considered to be one of the most influential interest groups in the field of industrial communication. It includes 25 regional RPAs with over 1500 automation solutions manufacturers and service providers as its members.
About Profibus
Originally, the Profibus User Organisation specified two versions of the communication protocol: Profibus FMS (Field bus Message Specification) and Profibus DP (Decentralised Peripherals).
Today, Profibus DP is the most commonly used specification of Profibus. It is used in industrial applications to monitor and control sensors and actuators within an automation system. Profibus PA (Process Automation) is the second Profibus specification used today. It’s an application-specific protocol which is mostly utilized in process control systems to monitor various measuring sensors and solutions. The Profibus architecture relies on four types of messages, designed for specific applications: SD1 (contact check), SD2 (data transport), SD4 (token) and SC (short answer).
According to the latest report, the number of installed Probus devices rose by more than 22% in 2020 compared to the previous year, reaching a total number of 1.7 mln, which includes around 0.8 mln devices used in the process industry applications.
Profinet (Process Field Net) is an open industrial Ethernet communication protocol based on international standards. Profinet was designed for industrial automation applications primarily, to enable communication between various sensors, controllers, devices, machinery and software solutions. Maintained by the Profibus and Profinet International organization, Profinet is one of the most commonly used industrial Ethernet standards thanks to its robust message delivery capabilities and compatibility with other Ethernet-based protocols such as OPC UA or MQTT.
Brief history of Profinet
The idea to create a new Ethernet communication standard as a replacement for Profibus emerged in 2000 at a meeting of Profibus user organization. The first Profinet CBA (Component Based Automation) specification was released in 2001 and became part of the IEC international standard in 2002 (to be removed in 2014 as Profinet CBA didn’t get wide enough adoption on the market).
First specification of Profinet IO (Profinet Input Output) was released in 2003 and became part of the international standard IEC 61158 / IEC 61784-2 in 2006. The Profinet protocol was augmented with Time-Sensitive Networking (TSN) in 2019.
According to the latest report by Profibus and Profinet International, the total number of installed Profinet devices globally has surpassed the 40-million mark in 2020, with 7.3 mln new devices added (22% more than was added in 2019).
About Profinet
The Profinet protocol is based on a cascading real-time concept, defining the communication of centralized control systems and nodes with Ethernet-based peripheral devices connected to an industrial automation network.
A Profinet standard assumes three types of network devices: IO-Controller, IO-Device and IO-Supervisor.
A Profinet network should contain at least one IO-Controller, monitoring and controlling one or more field-connected IO-Devices that can include multiple modules and submodules. The IO-Supervisor typically is a software solution installed on a host computer and used to manage system settings and monitor connected devices.
Additionally, in a Profinet IO-System, any Ethernet-based device can function as an IO-Controller and an IO-Device at the same time. An Application Relation (AR) is used to define Communication Relations (CR) between IO-Controllers and IO-Devices, enabling effective coordination and prioritization of tasks within a Profinet network. Even when IO-Controllers simultaneously function as without IO-Devices, the protocol architecture allows to coordinate tasks without the need for additional devices.
With rapid and reliable data exchange between system nodes as its key strength, Profinet is commonly used in critical applications within industrial automation systems. Profinet supports information delivery over a number of communication channels: TCP/IP, UDP/IP, Profinet Real-Time (RT), Profinet Isochronous Real-Time (IRT), and Time Sensitive Networking (TSN).
Typically, TCP/IP and UDP/IP communication channels are used for non-time-critical tasks. For time-critical applications, the other three communication methods are normally utilized, enabling the creation of a real-time Profinet channel for robust and coordinated data delivery between nodes.
CIP (Common Industrial Protocol, previously used to be known as Control and Information Protocol) is a media independent, object oriented communication protocol designed for industrial automation applications and based on the producer-consumer communication model. The CIP protocol incorporates a comprehensive stack of messages and services that support the integration of industrial automation applications with enterprise Ethernet networks and the Internet, facilitation of data exchange between network components, monitoring and control, synchronization, network management, etc.
About ODVA
The CIP protocol was originally developed by Rockwell Automation in the late 1990 and is now managed by ODVA (Open DeviceNet Vendors Association) organization. Founded in 1995, ODVA operates as a global organization representing developers and suppliers of industrial automation solutions. The organization has over 15 technical working groups, overseen by ODVA’s technical review board, that develop and maintain communication standards and other specifications for its technologies.
Besides CIP, ODVA manages a number of network adaptations of this protocol. They are DeviceNet, EtherNet/IP, ControlNet and CompoNet. The organization also provides a number of CIP-related services, such as CIP Safety, CIP Security, CIP Energy, CIP Sync, and CIP Motion.
About CIP
CIP is an object oriented protocol designed for the upper layers of network communication. The protocol incorporates a large object library for various kinds of industrial applications, such as general network communications, exchange of data, tracking and monitoring of network devices, as well as custom automation functions.
Each object in CIP has attributes (data), services (commands), connections, and behaviors (relationship between attributes and services). The CIP ensures that the same object or group of objects implemented in two or more devices will behave identically, thus enabling interoperability of all CIP devices.
A group of objects in a CIP device is called the Object Model. Based on the producer-consumer communication model, it enables network components to exchange data with a more efficient use of network bandwidth as a sending device and many receiving devices can communicate without requiring data to be transmitted multiple times by a single source to multiple destinations.
Additionally, CIP defines a standard grouping of objects known as Device Profiles to ensure interoperability of multiple devices from different vendors within a single CIP network. Device Profiles specify configuration options, I/O data formats, and other characteristics required for devices from different vendors with the same Device Profile to have the same network behavior and respond to the same commands.
EtherNet/IP is a communication protocol that adopts the CIP protocol to standard Ethernet, allowing users to deploy Ethernet networks in industrial automation applications. Managed by the ODVA organization along with CIP, ControlNet and a number of other protocols, EtherNet/IP is one of the most commonly used communication standards in industrial automation environments.
About EtherNet/IP
The development of EtherNet/IP was initiated in the 1990s by the ControlNet International organization. ControlNet International and ODVA formed a joint technology agreement (JTA) for the development of EtherNet/IP in 2000. The JTA was terminated in 2009, and the standard became a part of ODVA’s portfolio of protocols.
Like all ODVA’s protocols, EtherNet/IP follows the OSI model and uses CIP for its upper layers. CIP’s object-oriented design provides EtherNet/IP with services and device profiles required for real-time control applications. The standard also incorporates the most common Ethernet standards — the Internet Protocol suite and IEEE 802.3, — adapting them to the CIP object model framework.
A development of portable open-source implementation of the EtherNet/IP stack for I/O adapter devices, named OpENer, was started in 2009. It supports multiple I/O and explicit connections and includes objects and services for making EtherNet/IP-compliant products as defined in the ODVA specification. The OpENer is available on GitHub.
ControlNet is an open network communication protocol designed for industrial automation applications. ControlNet is a part of the CIP protocol family adapted for highly deterministic and scheduled purposes.
The ControlNet protocol is managed by ODVA along with CIP, DeviceNet, EtherNet/IP, and CompoNet.
ControlNet shares the identical application layer protocol with CIP, DeviceNet and EtherNet/IP. All upper (based on the OSI model) layers of ControlNet are also based on CIP. The uniquely adapted layers of ControlNet are physical layer, data link layer, transport layer, and network layer.
The design of ControlNet is focused on providing reliable and high-speed data connections that are scheduled for specific timing over the network. The protocol architecture supports the execution of critical messaging that does not rely on timing to be transmitted without interfering with time-critical tasks. ControlNet includes the support for fully redundant cables and is interoperable with multiple types of industrial automation hardware and devices, including PLCs, HMIs, robots, PCs, industrial machinery, etc.
EtherCAT (short for Ethernet for Control Automation Technology) is an Ethernet-based protocol. Developed by Beckhoff Automation and originally introduced in 2003, EtherCAT was primarily designed for real-time and short update time applications in industrial automation.
Today the EtherCAT protocol is managed by the EtherCAT Technology Group (ETG), a non-commercial association of various industrial automation technology vendors, service providers, OEMs and other parties. With over 6,750 member companies from 69 countries, ETG is considered to be the biggest industrial Ethernet user organization in the world.
About EtherCAT
Standardized in IEC 61158, EtherCAT is transported directly within the standard IEEE 802.3 Ethernet frame. The protocol was optimized for process data transmissions through Ethernet networks with fast response and lower hardware requirements. EtherCAT supports network data exchange in any order, independent of the physical order of the system nodes, and the connection of Ethernet devices (via switch ports) and frames.
Short cycle times in EtherCAT are achieved by changing the interpretation of data for Ethernet packets or frames. The data is no longer received at every node. Instead, critical messages and short-time/real-time data is prioritized over other types of data transmissions.
Remote control and monitoring of industrial automation systems, machines and devices are the most frequent applications for EtherCAT. Some examples of EtherCAT implementation would be industrial measurement systems, robotic devices, assembly systems, semiconductor solutions, packaging machines, etc.
FINS (Factory Interface Network Service) is a network communication protocol developed by Omron, a Japanese electronics manufacturer, for its PLCs and other devices to exchange data and perform various services.
About FINS
The FINS protocol allows Omron PLCs and compatible devices from other vendors connected to an Ethernet network to communicate. The protocol is compatible with network standards besides Ethernet, including DeviceNet, RS-232C, Controller Link, Host Link, SYSMAC LINK, Toolbus, and a number of others.
FINS uses a command/response system in which a command is sent along with parameters (including the destination node) and a response is returned by the destination node. It is also possible to specify command parameters so that a response is not returned if one is not needed. Commands can also be sent to every node on a local network.
The FINS protocol relies on a three-stage addressing system. Communications between various network nodes can be established by specifying the network address, number, and the unit address of the node. Unit addresses are required because communications are possible with more than one unit at each node.
BACnet (BAC stands for Building Automation and Control) is a communication protocol developed for various applications in building automation and control systems, such as fire detection, access control, lighting control, heating, elevators, air-conditioning, etc.
Brief history of BACnet
The BACnet protocol was developed by the BACnet Committee, a technical committee of the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE).
The development of the standard was initiated in 1987 at the inaugural committee meeting. BACnet was initially released as ASHRAE/ANSI Standard 135 in 1995, and became the ISO 16484-5 standard in 2004.
Maintenance and support of the BACnet protocol is done by the ASHRAE Standing Standard Project Committee 135. BACnet Testing Laboratories (BTL) is responsible for maintaining a list of products with global BACnet certification.
About BACnet
The BACnet protocol provides an independent communication standard based on the client-server model. Designed for building automation devices, equipment and software, the standard defines messages, formats and rules for exchanging data, commands and status information.
BANnet comprises a number of services for communication between building automation solutions, as well as 60 object types that are acted upon by the services. Some examples of services provided by BACnet are Read-Property and Write-Property for data sharing, Who-Is, I-Am, Who-Has, and I-Have for device and object discovery, etc. In total, BACnet offers 38 types of services divided into five categories: Alarm and Event Services, File Access Services, Object Access Services, Remote Device Management Services, and Virtual Terminal Services.
BACnet supports multiple data link and physical layers, including Ethernet, Point-To-Point over RS-232, BACnet/IP, BACnet/IPv6, BACnet/MSTP, ARCNET, ZigBee, LonTalk, and others.
Today BACnet is the most widely implemented building automation-specific communication standard. According to the BACnet Committee, it is specified in more than 60% of projects globally.
KNX is another widely used network communication protocol for building automation equipment and systems. Based on the OSI model, KNX is a royalty-free open standard most commonly applied in building security systems, fire detection and access control, lighting control, heating, elevators, air-conditioning, and other home and building automation solutions.
The KNX standard has evolved from, and is based on, three original communication standards: the European Home Systems Protocol (EHS), BatiBUS, and the European Installation Bus (EIB, also known as Instabus). Specifically, KNX relies on EIB’s communication stack augmented with the physical layers, configuration modes and application layers of BatiBUS and EHS.
The architecture of KNX protocol relies on Datapoints — inputs, outputs, parameters, and diagnostic data — to represent process and control variables. Datapoints have to conform to standardized datapoint types organized into a number of functional blocks.
KNX is managed by the KNX Association, a non-profit organization founded in 1999. KNX Association has over 500 building automation technology vendors and service providers as members.
KNX was developed to meet the needs of electrical installations in buildings. There are several thousand KNX-certified product groups for different applications in the home and building field. The protocol also ensures that all KNX-based products are compatible with all major communication standards used by automation electronics vendors.
With such a huge variety of communication standards across multiple components of an industrial automation system, the effective collection and analysis of data can be a problem. Clarify is a time series data solution that reduces the complexity of turning your industrial automation data into value. It is easy to integrate with automation systems and databases regardless of what messaging protocols they are using.
Clarify provides industrial teams with a next-gen level of time series data intelligence, helping to make data points from historians, SCADA and IoT devices useful for the whole workforce, from field workers to data scientists.
Clarify makes it easy to visualize time series data from your IoT network, access it on web and mobile devices, as well as sharing data to coworkers and collaborating on it in real time. With Clarify, your organization can focus on key business goals instead of configuring dashboards or developing expensive custom solutions.
We use data (in the form of cookies) to give you a better experience on our web page.
Find out how we handle your data in our privacy policy
