Industrial Communications Protocols – the benefits of each – a non-PLC-Vendor look!

Industrial Communications Protocols – the benefits of each – a non-PLC-Vendor look!

Abstract

With an array of automation network protocols available today, what should automation and process engineers be looking for to ensure they choose the correct protocol and network topology for their control system?

Data communications’ technology for automation systems have been around for a long time. First introduced by Modicon in the late 70’s, Modbus is a typical example of a protocol developed for the industrial arena which, amazingly enough, is still popular today.

Today’s automation engineer has a wide choice of protocols to choose from. Many of these are based on different transport media types (Serial, Ethernet, Manchester Coding etc.), as well as different areas of application.

In many cases these protocols are driven by the PLC, DCS or Instrument vendors and involve a “buy-in” by the end user into a specific Control System.

This paper will take an independent look at some of the various protocols on offer and pose questions the end-user should ask of the Control System’s vendors to ensure the right protocol is being used for the application.

 

Introduction

For many years the Process Controls and Industrial Automation system’s vendors have been developing proprietary protocols to operate with their Programmable Controllers and Distributed Control Systems.

These protocols were developed mainly for configuration (downloading, uploading and monitoring of programs) and the IO systems which would allow the distribution of digital and analogue IO throughout the plant being controlled. These had to be robust, reliable and fast acting.  They were designed by the vendors themselves to operate with their own IO systems

Then came the need to interface these control systems to other intelligent systems, either at the factory floor (other controllers or intelligent instruments) or at a plant management level (interfacing to higher level systems) for overall plant control and process information.

Over the last 20 years we have seen a growth in the requirement for information technology. This has been a requirement in the control room for real time data to allow the efficient control of plant by operators, as well as historical data being captured and stored for use by company management for planning and utilization.

Then more recently we have seen the combining of IT and automation technologies to allow for more seamless integration between the factory or plant environments to corporate data systems.

Industrial protocols were developed by PLC & DCS vendors to make their systems more powerful and functional. The concept of a control center with distributed clusters of IO to replace relay technology has been around since the early 1970’s.

PLC technology was derived from requirements in the auto makers and other manufacturing technologies to replace sequential relay banks on production lines.

Distributed Control System was used extensively in the Petrochemical and Food Processing Plants. In these industries large volumes of analogue signals are required to be looked at to control the process.

The first “open” standard for control systems was developed by Modicon in the late-70’s; Modbus was based on a serial protocol and used to program Modicon PLCs. It was adopted by many instrument vendors as a method of gaining access to their devices, rather than using discrete IO channels.

Many vendors still use Modbus as an interface today. It is simple to use and virtually all PLC and SCADA vendors have interfaces for Modbus.

The one problem with Modbus is that it is a single master, multiple slave protocol. If slave devices need to communicate with each other, they need to do it via the Master Controller.

After Modbus was released, virtually every PLC vendor released a proprietary serial protocol to allow connection to their own system (mainly for programming the PLC).

In the mid-80s the trend moved away from digital mimic display panels to Supervisory Control and Data Acquisition (SCADA) systems. In many cases these ran on personal computers and the means of connection to the PLCs was via serial programming protocols.

Due to the increasing volumes of data being required from the plant floor by both process and management personnel, faster protocols were developed to allow the rapid collection of this data.

Protocols such as Modbus II, Modbus Plus, Data Highway Plus, and Profibus FMS & FDL became prolific. Each vendor had their own proprietary system and many end users purchased systems based on their communications qualities.

In the late 80’s we started to see the first Ethernet protocols appearing, although these were ISO Layer 4 protocols (the Internet and TCP/IP were still a way off yet),

Siemens with H1, Telemecanique with ETHWAY and Allen Bradley with their PCCC Ethernet protocols appeared at this time.

This was also the time for multiple field IO protocols to start appearing: Profibus DP, Interbus, CAN, DeviceNet, LONWORKS, FIP, DNP3. The concept was to utilise field devices which had embedded interfaces built into the device and could therefore be read from and written to, by other devices requiring that data.

In addition to the protocols mentioned above, field instrument protocols such as HART (for existing 4-20mA signals), Profibus PA, and Foundation Field Bus also started to gain momentum.

All these protocols are today considered as standard and open (available to other vendors).

In the mid-1990’s, with the adoption of the Windows OS and the Internet as a means of collecting and transporting data, the use of Ethernet via Transmission Control Protocol / Internet Protocol (TCP/IP) became widespread. Slowly the Controls Systems vendors began to start embedding their serial and proprietary protocol features into the transport and application layers of TCP/IP.

Today virtually every control processor has an interface for an Ethernet link running on TCP/IP. No vendor dare be caught without one.

 

Read more here …

 

Share this post

Leave a Reply

Your email address will not be published.