Tires and protocols in industrial automation: how it all works

Surely, many people know you or even have seen how large automated objects are controlled, for example, a nuclear power plant or a plant with a multitude of technological lines: the main action often takes place in a large room, with a bunch of screens, light bulbs and remotes. This control complex is usually called the main control board, the main control board for controlling the production facility.

Surely you were wondering how this all works in terms of hardware and software, how these systems differ from the usual personal computers. In this article, we will understand how various data get into the main control room, how equipment commands are given, and what is needed to control a compressor station, a propane production unit, a car’s assembly line, or even a sewer pump installation.

The bottom level or fieldbus is where it all starts.

This unclear for the uninitiated set of words is used when it is necessary to describe the means of communication of microcontrollers with subordinate equipment, for example, input-output modules or measuring devices. Usually, this communication channel is called the “fieldbus” because it is responsible for transmitting to the controller the data that comes from the “field”.
')
“Field” is a profound professional term meaning the fact that some equipment (for example, sensors or actuators) with which the controller interacts are located somewhere far, far away in the street, in the fields, under the cover of night. It does not matter that the sensor can be located half a meter from the controller and measure, say, the temperature in the automation cabinet, it is still considered that it is “in the field”. Most often, signals from sensors coming into I / O modules still cover distances from tens to hundreds of meters (and sometimes more), collecting information from remote sites or equipment. Actually, therefore, the exchange bus, through which the controller receives values ​​from these sensors itself, is usually called a fieldbus or, less commonly, a lower level bus or an industrial bus.


The general scheme of industrial automation

So, the electrical signal from the sensor passes a certain distance along the cable lines (usually through a conventional copper cable with a certain number of wires), to which several sensors are connected. Then the signal enters the processing module (I / O module), where it is converted into a digital language understandable to the controller. Further, this signal on the field bus goes directly to the controller, where it is already finalized. On the basis of such signals, the logic of the microcontroller itself is built.

Top level: from garland to the whole workstation

The top level refers to everything that can be touched by an ordinary mortal operator, who controls the process. In the simplest case, the upper level is a set of light bulbs and buttons. Light bulbs signal to the operator about certain events taking place in the system, the buttons serve to give commands to the controller. Such a system is often called “garland” or “Christmas tree” because it looks very similar (as you can see from the photo at the beginning of the article).

If the operator is more fortunate, then as the top level he will get an operator panel - some flat-panel computer, which in one way or another receives data for display from the controller and displays it on the screen. Such a panel is usually mounted on the automation cabinet itself, so it is usually necessary to interact with it while standing, which causes inconvenience, plus the quality and size of the image on the small-format panels leaves much to be desired.



And, finally, the attraction of unprecedented generosity - a workstation (or even several duplicates), which is an ordinary personal computer.

The top-level equipment must interact in some way with a microcontroller (otherwise why is it needed?). For such interaction, upper-level protocols and some transmission medium are used, for example, Ethernet or UART. In the case of the “Christmas tree,” such refinements are, of course, not necessary, the lights are lit using ordinary physical lines, there are no sophisticated interfaces and protocols there.

In general, this top level is less interesting than the field bus, since this top level may not exist at all (there’s nothing for the operator to watch from the series, the controller will figure out what to do and how).

“Ancient” data transfer protocols: Modbus and HART

Few people know, but on the seventh day of the creation of the world God did not rest, but created Modbus. Along with the HART protocol, Modbus, perhaps the oldest industrial data transfer protocol, it appeared already in 1979.

A serial interface was originally used as the transmission medium, then Modbus was implemented over TCP / IP. This is a synchronous protocol according to the master-slave (master slave) scheme, which uses the principle of "request-response". The protocol is rather heavy and slow, the exchange rate depends on the characteristics of the receiver and transmitter, but usually it takes almost hundreds of milliseconds, especially in the implementation via a serial interface.

Moreover, the Modbus data transfer register is 16-bit, which immediately imposes restrictions on the transfer of real and double types. They are transmitted either in parts or with loss of accuracy. Although Modbus is still widely used in cases where a high exchange rate is not needed and the loss of transmitted data is not critical. Many manufacturers of various devices like to extend the Modbus protocol in their exceptional and very original way, adding non-standard features. Therefore, this protocol has many mutations and deviations from the norm, but still it still lives successfully in the modern world.
The HART protocol has also existed since the eighties; it is an industrial exchange protocol over a two-wire current loop line, which directly incorporates 4-20 mA sensors and other devices that support the HART protocol.

For switching HART lines, special devices are used, so-called HART modems. There are also converters that, at the output, provide the user with, say, the Modbus protocol.

Perhaps HART, perhaps, is that in addition to analog 4-20 mA sensor signals, a digital signal of the protocol itself is transmitted in the circuit, this allows you to connect the digital and analog parts in one cable line. Modern HART modems can be connected to the USB port of the controller, connected via Bluetooth, or in the old way via the serial port. A dozen years ago, by analogy with Wi-Fi, the WirelessHART standard in the ISM band also appeared.

The second generation of protocols or not quite industrial bus ISA, PCI (e) and VME

Modbus and HART protocols were replaced by not quite industrial buses, such as ISA (MicroPC, PC / 104) or PCI / PCIe (CompactPCI, CompactPCI Serial, StacPC), and also VME.

The era of the calculators, which have at their disposal a universal data transmission bus, where you can connect various boards (modules) to process a certain unified signal, has arrived. As a rule, in this case, the processor module (computer) is inserted into the so-called skeleton, which provides interaction over the bus with other devices. The skeleton, or, as the automators like to call it, “crate”, is supplemented with the necessary I / O boards: analog, discrete, interface, etc., or it all becomes a sandwich without a frame — one board over the other. After that, this diversity on the bus (ISA, PCI, etc.) communicates with the processor module, which thus receives information from the sensors and implements some logic.


Controller and I / O modules in the PXI frame on the PCI bus. Source: National Instruments Corporation

Everything would be fine with these ISA, PCI (e) and VME tires, especially for those times: the exchange rate does not upset, and the system components are located in a single frame, compact and convenient, hot swapping of I / O boards may not be, but still not very desirable.

But there is a fly in the ointment, and not one. It is quite difficult to build a distributed system in such a configuration, a local bus, you need to think of something to communicate with other slave or peer nodes, the same Modbus over TCP / IP or which other protocol, in general, is not enough amenities. Well, the second is not a very pleasant thing: I / O boards usually wait for some kind of unified signal at the input, and they don’t have any electrical isolation from the field equipment, so you need to make a garden out of various conversion modules and intermediate circuitry, which greatly complicates the element base.


Intermediate modules of signal conversion with galvanic isolation. Source: DataForth Corporation

“And what about the exchange protocol on the industrial bus?” - you ask. And nothing. There is no such implementation. On cable lines, the signal goes from the sensors to the signal converters, the converters output the voltage to a discrete or analog I / O card, and the data from the card is already read through the I / O ports by means of the OS. And no specialized protocols.

How modern industrial tires and protocols work

What now? To date, the classical ideology of building automated systems has changed a bit. The role was played by many factors, starting with the fact that it should also be convenient to automate, and ending with the trend for distributed automated systems with nodes remote from each other.

Perhaps we can say that there are two basic concepts for building automation systems today: localized and distributed automated systems.

In the case of localized systems where data collection and control is centralized in one particular place, the concept of a certain set of I / O modules interconnected by a common fast bus is required, including the controller with its own exchange protocol. In this case, as a rule, I / O modules include both a signal converter and galvanic isolation (although, of course, not always). That is, it is enough for the end user to understand what types of sensors and mechanisms will be present in the automated system, count the number of required I / O modules for different types of signals and connect them into one common line with the controller. In this case, as a rule, each manufacturer uses its favorite exchange protocol between the I / O modules and the controller, and there may be a lot of options.

In the case of distributed systems, everything that is said with regard to localized systems is valid; in addition, it is important that individual components, for example, a set of I / O modules plus a device for collecting and transmitting information, is not a very smart microcontroller that stands somewhere in a booth in the field, next to the crane that blocks the oil, could interact with the same nodes and with the main controller at a great distance with an effective rate of exchange.

How do developers choose the protocol for their project? All modern exchange protocols provide a fairly high speed, so often the choice of one manufacturer or another is not due to the exchange speed on this very industrial bus. The implementation of the protocol itself is not so important, because, from the point of view of the system developer, it will still be a black box that provides some kind of internal exchange structure and is not designed for outside interference. Most often, attention is paid to practical characteristics: performance of the calculator, ease of application of the manufacturer's concept to the task, availability of the necessary types of I / O modules, the ability to hot-swap modules without breaking the tire, etc.

Popular equipment suppliers offer their own implementations of industrial protocols: for example, the well-known company Siemens is developing its Profinet and Profibus series of protocols, B & R companies — Powerlink protocol, Rockwell Automation — EtherNet / IP protocol. Domestic solution in this list of examples: the FBUS protocol version from the Russian company Fastwel.

There are more universal solutions that are not tied to a specific manufacturer, such as EtherCAT and CAN. We will examine in detail these protocols in the continuation of the article and see which ones are better suited for specific applications: the automotive and aerospace industries, electronics manufacturing, positioning systems, and robotics. Stay in touch!