Industrial Programming, or a few words about ACS TP
There is such a profession - to automate production. The acronym ACS TP means "automated process control system" - a system consisting of personnel and a set of equipment with software used to automate the functions of this personnel in managing industrial facilities: power plants, boiler houses, pumping, water treatment plants, food, chemical, metallurgical plants, oil and gas facilities, etc. etc.
In fact, every person who does not live in the forest and enjoys the benefits of civilization uses the results of the labor of enterprises in which automated process control systems operate.
Sometimes articles on the subject slip on this subject too Usually they are not very popular, but nevertheless I want to write some review articles about ICS in the hope of telling habra residents something interesting (and perhaps even useful to someone) and attracting more of my colleagues to the hub.
First, a few words about yourself. I am just starting my life in automation, almost two years of work experience. During this time I visited several gas fields, now I work in the oil field.
Since the area is vast, despite everything developing, sometimes contradictory and controversial, I will try to summarize it without sacrificing reliability, but I can’t avoid a bias in my area — the hardware, software and sphere that I personally encountered.
So, the ASU TP software and hardware complex is divided into three levels: upper (computers), middle (controllers), lower (field equipment, sensors, actuators). I will not talk about the lower level - this is too far from the subject of the Habr, and the article will turn out to be too large.
The upper level is servers and user PCs (in our country they are called AWP - workstation). The status of the process is displayed here, and from here, if necessary, the operator sends commands to change its parameters. To simplify the development, a large number of SCADA systems have been created (from the English supervisory control and data acquisition - dispatch control and data collection). This is in some way an extended analogue of the IDE, in which the compiled “program” is executed.
In general, if we discard academism, then at the enterprise for everyone except asushniki, the scud looks like this:
And if you are not lucky at all, then like this:
Scuds can be implicitly divided into server and client parts. Field devices are polled and data is collected by the server (usually through a PLC), from the server, clients take this data to their monitor. The concepts of “server” and “client” parts are arbitrary in themselves. In fact, the separation is made under licenses for the components of the scada, and the licensing policy for each manufacturer has its own. Up to the division into: the number of processed signals from the field, the protocol driver, the number of workstations, the ability to create a web interface, a mobile interface, and indeed whole pieces of functionality can be for separate denzheks. It’s often easier to contact the supplier, providing the source data for the project to help with the selection of licenses.
Two operating modes are implied: development mode and runtime mode. Not necessarily these modes are mutually exclusive: you can edit the project on one workstation, engineering, upload it, it will be updated to user. It is very important to change the project without downtime and shutdowns, because the technological process cannot be interrupted, and operators should always be able to control it. Graphical interfaces are created in the scud, data sources from field devices are configured, it is responsible for the interaction of the user (operator, dispatcher, technologist) with what is happening in the production, as well as for archiving all the necessary data in the database.
Archiving is one of the obligatory functions, it is very important to be able to “go back in time” to parse flights in the event of something unforeseen or for global analysis during slow, lengthy processes. For example, recently, geologists asked me to unload a plate with data on oil pressure at wells over the past year.
Periodically, the scuda accumulates all the data collected in the database. They can then be viewed in the form of graphs (we call them trends), and if necessary, if agreed upon in the technical specifications for the process control system, they are uploaded in the form of reports to Excel or some other way. Archiving is done differently: in MS SQL; MS Access; in the same MS SQL, but in its cunning algorithm with additional archiving; and someone else in their own binary database.
A special point in the scads is informing the operator: current messages and alarms. They are also necessarily archived. In general, messages are divided into current and important (emergency). The current ones are hidden away, but the emergency log is always displayed on the operator’s screen. Sound alarms are attached to text alarms so that someone does not oversleep the emergency :-)
The most common, in my opinion, are the slopes manufactured by Invensys Wonderware, Iconics, Siemens, Indusoft, AdAstra, Emerson, Rockwell Automation.
I personally worked with Windows: Invensys Wonderware InTouch and a more powerful System Platform, with Iconics Genesis32 - and with the (still?) Little-known B&R APROL for SLES (formally, this is not entirely a bit, but more abruptly - the controllers themselves are programmed from under the aprol )
For search queries, for example, SCADA , HMI, you can see examples of interfaces and mimic diagrams.
Appearance and usability by priority, alas, are in last place. Moreover, this applies not only to runtime, but also to development. There are at least default symbol libraries, from buttons and other controls to graphic images of pumps, pipes, valves, tanks, for development in each scad. This is where smart SCADA-package developers (not to be confused with us, classmates - project developers in these packages) could achieve a fundamental advantage over competitors by making thoughtful libraries from which even the farthest engineer from design and usability would make would humane interfaces and mnemonic diagrams. Unfortunately, now this area is following the path of extensive development, along which IT has developed until recently - building functionality, adding buns, bigger, higher, stronger, harder,
Intermediate level - PLC, programmable logic controllers. Everything is quite simple here, most often physically PLCs consist of separate modules. Each PLC has its own development environment for programming, sometimes it is combined with the environment for creating SCADA.
Modules are as follows:
- Power Supply;
- discrete inputs;
- discrete outputs;
- analog inputs;
- analog outputs;
- temperature inputs;
- interface / communication.
B&R X20 Series controller
Why you need a power supply is understandable. The PSU is made a separate module, not a device, to guarantee compatibility with this PLC line. Most often, the input voltage of the PSU is 220 V AC, the output voltage is 24 V DC.
The processor module is the head of the PLC. Inside it, of course, the CPU, RAM and ROM, a service port for firmware and, possibly, a communication port (ethernet, RS232 / 422/485, Profibus, etc). Sometimes the communication port is also used as a service port. Sometimes there is a switch on the module (Allen Bradley is even cooler - there is a natural key with a keyhole) to transfer the PLC to various operating modes. There is no separate on / off button, in the best case, that switch, otherwise, if there is power, the PLC starts up and turns off and restarts “barbarously” by turning off the power.
Allen Bradley CompactLogix Series
Discrete and analog modules process the corresponding signals. Input modules receive these signals from the field, output modules form them.
A discrete signal is usually a 24 volt circuit voltage. There are 24 - this is "1", no - "0". There are modules for 220V, there are modules with a circuit integrity check. Discrete signals coming from the field can inform, for example, the status of the pump on / off. Discrete control signals can start or stop this pump. Optimization is not justified here, so there will be a separate chain to start, a separate one to stop.
I / O modules of the same type can be combined: for example, one module with 16 digital inputs and 16 digital outputs.
Analog input signals - this is the readings from the sensors. Here, a 4-20 mA current loop is most often used, in accordance with which the measurement limits of the sensor are set. It starts from 4 mA to diagnose an open circuit (if less than 4 mA, then somewhere something is wrong with the wiring).
Consider the example of a liquid level in a tank. There is a level gauge, it measures the level from 0 to 2 meters. Then: a level of 0 meters is 4 mA, a level of 2 meters is 20 mA. Intermediate values are calibrated according to the situation, not always 1 meter corresponds to 4+ (20-4) / 2 = 12 mA, there may be a small error, the level of 1 meter may be some 12.7553 mA.
An analog weekend is the same, only for control. I have not seen to be used, because there are always leads. In measurement, this is an allowable error; in control, it is not. Yes, and it is inconvenient. Instead, they use digital data transmission over various protocols through communication modules.
Temperature modules measure resistance in a circuit or thermo-emf. If resistance thermometers are connected to them - when the metal is heated, its resistance, according to the laws of physics, rises, and the temperature is determined accordingly. If a thermocouple is connected (two soldered conductors of different metals, when the joint is heated, a potential difference occurs between the other ends), the voltage is measured.
Interface (or communication) modules provide us with ports for RJ45, DB9, DB15, just terminal blocks or what else God will put to the soul of the manufacturer. In addition to directly implementing the interface (a physical connector for a connector, a physical layer of the OSI model), they also implement an exchange protocol through this connector.
Protocols and Interfaces
They invented and used a bunch of protocols: ModBus (RTU, TCP, ASCII), Profibus, Profinet, CAN, HART, DF1, DH485, etc. Some particularly cunning manufacturers implement their protocols on top of the generally accepted ones.
I am fairly familiar with the RS232 / 485 interfaces and Modbus protocols. RS232 is a familiar COM port, with three main lines: Tx (transmit, transmit), Rx (recieve, receive) and GND (ground). RS485 is an asynchronous half-duplex serial interface over 2 wires (combined Tx / Rx + and Tx / Rx-) or 4 wires (separately Tx +, Tx-, Rx +, Rx-) with a potential difference on each pair from 2 to 10 volts.
And modbass is basically a simple thing, with checking the integrity of the package by check sum, confirming delivery and the correctness of the request - or the answer why the request is incorrect. There are two types of devices on the modbas network: master - initiates the exchange; slave - Fulfills requests of the master. The packet from the master diverges to all the slaves that compare the destination address with their own, if it converges, then they look at the next two bytes - this is a command to work with memory registers - read / write (with the exception of a few rarely used service commands), then address bytes and data directly , at the end of the check. Enough detailed and clearly painted on Wikipedia .
The first thing to say is that the program in the PLC is executed cyclically with a certain frequency. The possibilities depend on the controller, usually it is somewhere around 20, 50, 250 ms, 1, 2, 3, 4, 5 s. Naturally, this does not guarantee the execution of the code for such a period of time, you cannot shove large programs into a 20 ms cycle, and the previous one should be completed by the beginning of the next cycle.
The second is programming languages. In theory, PLCs are programmed in the languages defined by the IEC61131 standard:
- IL (Instruction List) is a low-level assembler-like language.
- LD (Ladder Diagram) - a graphical language, is a software implementation of electrical circuits based on electromagnetic relays. Invented in shaggy years for those asushniki who are more electricians than programmers.
IL and LD are easily converted to each other, it seems, by all programming environments. They are not very readable, and therefore inconvenient for development, but in situations where the controller’s internal memory is small, you have to write to them.
- ST (Structured Text) is a Pascal-like text language. In my opinion, of all five, the most convenient.
- FBD (Function Block Diagram) is a kind of graphic language, “block-chem-like”. The program is composed of functional blocks, which are subprograms written in any of the languages of the IEC61131 standard. Each FB has inputs and outputs that connect to the inputs and outputs of other FBs. It might be more convenient for someone to do this than to write everything on the same ST.
- SFC (Sequential Function Chart) is a graphical high-level language. Created on the basis of the mathematical apparatus of Petri nets. Describes a sequence of states and transition conditions. I have never met or heard that it was used somewhere.
This is "in theory." But, for example, Siemens adheres to its name of languages, while B&R has the ability to write in ANSI C.
The most used controllers are unconditionally Siemens and Allen Bradley (the latter, by the way, belongs to Rockwell Automation with its own RSView SCADA-package line). Schneider Electric is on their heels; ARIES; General Electric; AutomationDirect ICP DAS; Advantech Mitsubishi Electric; B&R.
The post does not pretend to be a complete reference description of everything - very different equipment, software and approaches to them in general. The most formally error-free story about the process control system would be a listing of the relevant Federal Law, GOSTs, technical standards and regulations. Consider all possible discrepancies with these documents as typos ;-) Comments, corrections and, if interested, suggestions for the following articles are welcome.