Because DCS is a local area network, there are communication protocol problems. DCS basically uses two types of communication protocols: polling and interrupt. Polling is conducted by the central control unit to query all subsystems in turn, and whether there is any data update will be asked at that time, so the communication flow of the system is high but constant at any time. Interrupt mode is just the opposite. The subsystem checks it first. If the data has not changed, it will not be updated online. Don't "say hello" on the Internet until the data changes. In this way, the usual communication traffic is low, so the requirements for network bandwidth are low. However, when the production process is abnormal, a large number of alarm data will flood in, and if the bandwidth is not enough, the communication will be blocked. Therefore, the bandwidth requirements of interruption and polling are the same, because no one can bear the consequences of communication congestion when the production process is abnormal.
Honeywell was the first company to eat DCS crabs 20 years ago. Today, Honeywell is still the leader in the industry. Although its equipment is expensive, it is nicknamed Moneywell. At that time, DCS were all tailor-made software and hardware. Today, with the tide of "open architecture", DCS manufacturers have turned their consoles, computing and network control units to general WINTEL or UNIX platforms, focusing on the software integration of industrial control special equipment (such as basic control equipment, including I/O) and the system. But this brings new problems. The reliability of general/commercial software and hardware often can't meet the requirements of continuous operation for 24 hours and 365 days. For most IT, the machine is broken and can be replaced quickly within two hours. But for the production process, this is intolerable. Open architecture enables DCS to connect with operation, management and office networks, which greatly improves the speed, depth and breadth of information exchange, but it also brings network security problems. Then, set up a firewall in front of DCS to minimize data sharing and remote control. In addition, WINTEL is constantly upgrading day and night, which makes the stability of software and hardware very poor. There is not much time, and it is a headache to upgrade. This is the second spiral rise of DCS, but now it still lingers more than rises.
The field of computer control is also expanding, and technologies such as USB are beginning to be used in digital instruments. In the past, all instruments had to pull the signal wire to the marshalling panel and then connect it to FTA. This 10 instrument is also hundreds of meters away, and it needs parallel pull wires, which is very wasteful. Using a field bus similar to USB, all instruments can be "hung" on the bus, and then a bus can be connected to DCS, which greatly saves the cost and time of cable drawing and is very convenient for system expansion (such as adding a measuring transmitter or control valve).
The biggest advantage of DCS is programmable. This is not a simple programming like ladder logic of PLC (programmable logic controller, mostly used for electromechanical control), but a "conventional" programming like C and FORTRAN. I haven't done IT before, and I can only compare with the computer language courses and big homework programs in the school. Compared with ordinary programming, DCS programming still has some characteristics. First of all, the program of DCS belongs to "reentry" type, that is, it runs repeatedly at regular intervals instead of all at once. Therefore, the DCS program can store the data in the memory at the end of the run, and then call it again at the next run, forming a so-called "recursive" operation. This has both advantages and disadvantages. If someone else changes the intermediate data between your two operations, you will be miserable and it is not easy to find a creditor.
The characteristic of DCS program is real-time, so its execution is very dependent on the time sequence of a series of events. If the timing is wrong, the old hen will become a duck. The problem is that the more decentralized the requirements of decentralized control, the better, not only the reliability is good, but also the distribution of system resources makes the calculation load of the system uniform. Such an application package often decomposes a huge program into many small programs, so the timing and connection of each program should be very careful.
Perhaps the biggest difference from the academic control calculation program lies in the handling of abnormal situations. A multivariable control problem often has some variables in manual control and some variables in automatic control. This is a trouble in theory, but it is a nightmare in practice. Not only all permutations and combinations should be considered, but also the smooth cut-in and cut-out of all situations and the switching between different modes should be considered. There is also a need to consider how to safely and automatically exit automatic control and return to manual control under abnormal circumstances. Sometimes a word in the operating rules, programming is a page. It would be even worse if the operating rules include a phrase "handle as appropriate" in all control procedures, and the control calculation usually does not exceed 30%, 20% is man-machine interface function, and 50% is abnormal situation handling.
Computer control didn't start because of a more advanced and effective man-machine interface. From the very beginning, the man-machine interface was faced with the problem of peeping at the leopard in the tube. The CRT screen of the computer is only so big that it is impossible to get a panoramic view of all the process information at a glance. Computers can constantly change screens and display information of other equipment and workshops in sections, but if all workshops and equipment are represented by their own frames, it will be difficult to find them without effective organization, just like putting hundreds of files in the same directory at will. Hierarchical menu is a traditional solution, but it takes time to go up step by step and down step by step. In a hurry, it is often too late to replace it. Shortcut keys on the keyboard can be called up with one key, but they need to be memorized. This is not a few or a dozen frames, but hundreds or even more. For a long time, how to navigate between frames effectively and find the required frame intuitively in the shortest time and with the least number of clicks without rote learning has always been a headache.
Another problem of man-machine interface design is color. Remember WordStar in the DOS 2.0 era? It's green on a black background. At that time, the brightness of CRT was insufficient and its service life was not good. Black background can prolong its service life, and green characters can increase contrast and help reading. Anyway, the computer room is dark, and the black background doesn't hurt your eyes. In WordPerfect 5.0, there will be white characters on a blue background, and the contrast between the text and the background will be greatly reduced. Blue background is also suitable for use in bright rooms. In the Word era, there was no dark computer room, and basically it was black on a white background like writing on paper, and then green on a black background, which hurt my eyes too much.
The computer monitor in the central control room has gone through a similar process. In the early days, the display of DCS was all green characters on a black background. In the era of WINTEL or UNIX, many people still use green characters on a black background out of habit. However, the research of modern ergonomics shows that the light background greatly reduces the fatigue of eyes, and the light in bright rooms is less reflected on the screen, so the display of control room begins to evolve to light gray background. At the same time, ergonomics research found that color can be used as a part of process information. When the world is at peace, it should be the most inconspicuous gray, and all graphics and data should be represented by different shades of gray. Only when the process parameters exceed the limit or give an alarm can the color display be used, so that the operator's attention can be immediately attracted to the place where it is needed. However, out of habitual thinking, many places still use many colors to represent different equipment states and parameters, even in normal state. In this way, it is beautiful to look at the colors on weekdays, but under abnormal circumstances, it is not easy to find the general's head among thousands of troops. It's actually a waste of time.
The layout of the display is also very particular. Of course, the less the better. An operator has a certain field of vision, and the color, structure and lighting of the console cannot be taken for granted. This is not to encourage revisionism, but to let operators control the production process most effectively.
Traditionally, the performance of the control loop is acceptable if the operator does not complain. Unless you want to keep improving, you won't go looking for trouble to reset the parameters. In today's haggle over economic benefits, the technological conditions of the production process are pushed to the extreme, which poses a great challenge to the control performance, and the control loop must be in an optimal state at any time and place. With the rapid growth of the number of control loops, it is difficult to grasp the performance of all control loops at any time only by manual observation. Performance evaluation technology of control loop came into being.
PLC can be understood as a collection of a large group of relays, but other auxiliary functions such as analog control and feedback control were added later.