Surely many of you know or have even seen how large automated objects are controlled, for example, a nuclear power plant or a factory with many technological lines: the main action often takes place in a large room, with a bunch of screens, light bulbs and remote controls. This control complex is usually called the main control room - the main control panel for controlling the production facility.
Surely you were wondering how it all works in terms of hardware and software, how these systems differ from the usual personal computers. In this article, we will look at how various data gets to the main control room, how commands are given to the equipment, and what is generally needed to control a compressor station, a propane production unit, a car assembly line, or even a sewage pumping unit.
The bottom layer or field bus is where it all starts
This set of words, obscure to the uninitiated, is used when it is necessary to describe the means of communication of microcontrollers with subordinate equipment, for example, I / O modules or measuring devices. Usually this communication channel is called the “field bus”, because it is responsible for transmitting data to the controller that comes from the “field”.
“Field” is a deep professional term that refers to the fact that some equipment (for example, sensors or actuators) with which the controller interacts is somewhere far, far away, on the street, in the fields, under the cover of night. And 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 to be “in the field”. Most often, the signals from the sensors that come to the I / O modules still overcome 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 same sensors, is usually called a field bus or, less often, a lower-level bus or an industrial bus.
General scheme of automation of an industrial facility
So, the electrical signal from the sensor travels a certain distance along cable lines (usually along a conventional copper cable with a certain number of cores), to which several sensors are connected. Then the signal enters the processing module (input-output module), where it is converted into a digital language understandable to the controller. Further, this signal goes directly to the controller via the field bus, where it is finally processed. Based on such signals, the logic of the microcontroller itself is built.
Top level: from a garland to an entire workstation
The top level is everything that can be touched by an ordinary mortal operator who controls the process. In the simplest case, the top level is a set of light bulbs and buttons. Light bulbs signal to the operator about some ongoing events in the system, buttons serve to give commands to the controller. Such a system is often called a "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 the operator panel - a kind of flat-panel computer that somehow 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 you usually have to interact with it while standing, which causes inconvenience, plus the quality and size of the image on small-format panels leaves much to be desired.
And, finally, an 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 the microcontroller (otherwise why is it needed?). For such interaction, upper-level protocols and a certain transmission medium, for example, Ethernet or UART, are used. In the case of the Christmas tree, of course, such refinements are not needed, the bulbs 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 (the operator has nothing 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 is perhaps the oldest industrial communication protocol, it appeared as early as 1979.
The serial interface was initially used as a transmission medium, then Modbus was implemented over TCP / IP. This is a synchronous master-slave (master-slave) protocol that uses the request-response principle. The protocol is quite heavy and slow, the exchange rate depends on the characteristics of the receiver and transmitter, but usually the score is almost hundreds of milliseconds, especially when implemented 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 own unique and very original way, adding non-standard features. Therefore, this protocol has many mutations and deviations from the norm, but still successfully lives in the modern world.
The HART protocol has also been around since the 4s, it is an industrial communication protocol over a two-wire current loop that directly connects 20-XNUMX mA transmitters and other HART-enabled devices.
To switch HART lines, special devices are used, the so-called HART modems. There are also converters that at the output provide the user with, say, the Modbus protocol.
HART is noteworthy, perhaps, in that, in addition to the analog signals of the 4-20 mA sensors, the digital signal of the protocol itself is also 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 controller's USB port, connected via Bluetooth, or in the old way via a serial port. A decade ago, by analogy with Wi-Fi, the WirelessHART wireless standard appeared, operating in the ISM band.
The second generation of protocols or not quite industrial buses ISA, PCI (e) and VME
The Modbus and HART protocols have been replaced by non-industrial buses such as ISA (MicroPC, PC/104) or PCI/PCIe (CompactPCI, CompactPCI Serial, StacPC), as well as VME.
The era of calculators has come, having at their disposal a universal data transfer bus, where you can connect various boards (modules) to process a certain unified signal. As a rule, in this case, the processor module (computer) is inserted into the so-called frame, which provides bus interaction with other devices. The frame, or, as true automators like to call it, the “crate”, is supplemented with the necessary I / O boards: analog, discrete, interface, etc., or all this is glued together in the form of a sandwich without a frame - one board above the other. After that, this variety on the bus (ISA, PCI, etc.) communicates with the processor module, which thus receives information from sensors and implements some kind of logic.
Controller and I/O modules in a PXI frame on a PCI bus. Source:
Everything would be fine with these ISA, PCI (e) and VME buses, especially for those times: the exchange rate does not upset, and the system components are located in a single frame, compact and convenient, there may not be hot swapping of I / O cards, but still don't really want to.
But there is a fly in the ointment, and not one. It is rather difficult to build a distributed system in such a configuration, the exchange bus is local, you need to come up with something to exchange data with other slave or peer nodes, the same Modbus over TCP / IP or some other protocol, in general, there are not enough amenities. Well, the second thing is not very pleasant: I / O boards usually wait for some unified signal for input, and they do not have galvanic isolation with field equipment, so you need to fence a garden of various conversion modules and intermediate circuitry, which greatly complicates the element base.
Intermediate signal conversion modules with galvanic isolation. Source:
“What about the fieldbus communication protocol?” - you ask. But nothing. It does not exist in this implementation. Through cable lines, the signal goes from the sensors to the signal converters, the converters output voltage to a discrete or analog I/O board, and the data from the board is already read through the I/O ports, by means of the OS. And no specialized protocols.
How Modern Industrial Buses and Protocols Work
What now? To date, the classical ideology of building automated systems has changed a bit. Many factors played a role, from the fact that it should also be convenient to automate, and ending with the trend towards distributed automated systems with nodes remote from each other.
Perhaps, we can say that today there are two main concepts for building automation systems: localized and distributed automated systems.
In the case of localized systems, where data collection and control are centralized in one specific place, the concept of a certain set of I / O modules interconnected by a common fast bus, including a controller with its own exchange protocol, is in demand. 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 I / O modules and the controller, and there can be a lot of options.
In the case of distributed systems, everything that has been said about localized systems is true, except for this, it is important that individual components, for example, a set of I / O modules plus an information collection and transmission device - a not very smart microcontroller that stands somewhere in a booth in field, next to the crane that shuts off the oil, could interact with the same nodes and with the main controller at a great distance with an effective exchange rate.
How do developers choose a protocol for their project? All modern exchange protocols provide a fairly high speed, so often the choice of a particular manufacturer is not determined by the exchange rate on this same 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, which provides some internal exchange structure and is not designed for outside interference. Most often, attention is paid to practical characteristics: the performance of the calculator, the convenience of applying the manufacturer's concept to the task, the availability of the required types of input-output modules, the possibility of hot-swapping modules without breaking the bus, etc.
Popular equipment vendors offer their own implementations of industrial protocols: for example, the well-known company Siemens is developing its series of Profinet and Profibus protocols, B&R is developing the Powerlink protocol, Rockwell Automation is developing the EtherNet / IP protocol. The domestic solution in this list of examples: the version of the FBUS protocol from the Russian company Fastwel.
There are also more universal solutions that are not tied to a specific manufacturer, such as EtherCAT and CAN. We will explore these protocols in detail later in this article and see which are best suited for specific applications: automotive, aerospace, electronics, positioning systems, and robotics. Stay in touch!
Source: habr.com