Small automation, or how to send two bytes

Few words about myself

I do industrial automation. Literally from head to ass, i.e. from the field level (sensors / actuators) to the upper level (PLC programming / SCADA development). It so happened that most of all I was engaged in adjustment, but the last year - mainly development. In addition, for me, the software and hardware are divided into Siemens and everything else.

about the project

The essence of the project is to upgrade automation systems at a fairly large number of pumping stations (water and sewer). In addition to the actual update, the task was to collect and transfer the current values ​​of a number of parameters to a common control room for centralized archiving and monitoring. Geographically, all this economy is located in the Lower Galilee, in Israel.
At the time of commencement of work, automation equipment at various stations represented a very diverse zoo: from ET-200S CPU controllers on more recent stations to relay logic on older ones. Currently, Siemens, Twido (Schneider), Koyo, GE Fanuc controllers work at different stations.
It so happened that formally this project is implemented by Schneider Electric, our company is a subcontractor. This determined the choice of SCADA for the control room (Vijeo Citect) and controllers for stations where their replacement is required.

Features and Difficulties

And there are not many of them. The main and almost the only thing is how to transfer technological information from stations sufficiently remote from each other to a dispatch center. For this purpose, a system from Realiteq was used . The idea is quite simple: the company sells its devices (internals from Motorola) that have a ModBus interface (it is possible to use RS-232, 485, Ethernet), a cellular terminal and are configured using a special utility. Further, these terminals receive Modbus data and transmit them to the company server. For this, the company takes a monthly fee, the exact size of which is unknown to me. To get this data and use it in SCADA, you need to install another utility - the OPC server, which via the Internet requests data from the company’s server and sends it over the OPC protocol.
The configuration stored in the module itself is minimal. This is the name of the project, the name of the node in the project (there may be several nodes), settings for connecting to the controller and settings for the cellular terminal.
This is what the terminal itself looks like:

All data settings that the terminal exchanges in the PLC are made through the web interface or through a special utility. “Access to the body” is no longer required, only the Internet is needed. This is how the web interface looks:


In addition to collecting data, the web interface has minimal SCADA functionality, i.e. You can implement simple pictures.

And here is the water station on the operator’s screen in the Citect system:


Naturally, all the inscriptions in Hebrew do not forget where the project is located :) In a nutshell, on this screen we see the water level in the tank, the state of the float level sensors (upper, lower and two intermediate - on the left on the tank), the state of all three pumps (gray - off, green - in operation, red - malfunction), turn-on sequence (number in the window above each pump), water pressure at the inlet and outlet of the pumping station, level settings (full / empty tank alarm, pump shutdown level, first inclusion level pump, backup pump activation level). Below is a graph of the level change over the past 12 hours, the history is stored for 3 years.

Additional difficulties with water stations

In general, the algorithm of the water station’s operation is almost the same as that of the sewer: at one level in the tank, turn on the pump, and at the other - turn it off. The difference lies in the fact that at the sewer station, the tank and the pumps are in one place, and at the water pump, they are quite far from each other. Strictly speaking, due to the remoteness, the pumping and supply tanks are two different stations, each with its own controller.
The need for pressure stations is due to the fact that some settlements are located on the slopes of the mountains, and the pressure in the central water supply system is insufficient to raise water to the desired height. Therefore, consumable containers were built on the hills (the principle is similar to water towers), and below - pumping tanks that increase pressure and fill these tanks as needed.

Let's get back to our project. This territorial remoteness creates the main difficulty. The tank along with the level sensor is located too far from the pump room and at different times attempts were made to provide radio communications, but at the time of the implementation of our project this system did not work for reasons unknown to me.
But the data collection system that we use allows us not only to receive data, but also to transfer them between different stations within the project. Thus, the tasks of the controller on the supply capacity are minimal: to receive a signal from a level sensor (4..20 mA), convert it to engineering units and, using the Modbus protocol, send it upstairs and to the pump room. This Modbus register is the very 2 bytes put in the header, without which the pump cannot work. In the first screenshot, I circled in red the source register and the destination register in the second controller.
In fact, this controller conveys a bit more information. During operation, it is possible that we see at the pump room: the level has decreased, it is time to fill the tank. And turn on the pump. The pump is running, the tank is filling, and at some point the connection is lost. The level in the tank rises, but the pump information does not arrive at the controller. And the capacity is full.
To prevent this, we transfer one more value from the tank to the pump room. This is a counter whose value increases every minute. Also, once a minute, the pump controller stores the obtained value and compares it with the previous four. If they all match, it means that for 5 minutes we have lost communication.
At the pump room, at each start-up of the pumps, a timer starts at the same time with them, the setting of which can be changed. If the timer has finished counting and the controller “sees” the loss of communication, the pumps stop. Thus, protection is implemented.

Status of the project today

In total, the project plans to update the automation and connect 12 stations to the control room. Currently, 8 of them have completed the work, the hardware has been updated as necessary, if necessary, changes have been made to the controller programs, and the information is regularly transmitted to the control room.

And, for dessert, a general view of the village where the pumping and consuming tanks are located:


Also popular now: