Fundamentals of real-time processing in automation and control
Almost all automation and control systems are designed, developed and built using data processors, microprocessors, digital signal processors (DSPs) or any other processing device. Part 1 of a series of articles on real-time control systems.
This is the first part of a series of articles on real-time systems, real-time processing and fundamentals of real-time software design, applied to automation and control systems.
Today, almost all automation and control systems are designed, developed and built using data processors, microprocessors, DSPs or any other processing device, which execute instructions derived or compiled from a software program. Just very few and specialized control devices still use plain hardware (or "programmable" hardware, as FPGA) to accomplish the job for which they were designed.
Nevertheless, to design and develop software applications for a controller or automation device, special skills and a good understanding of the automation and control problem are required. Many designers and programmers are around, building web servers, information systems, business processes management systems, and many other important and valuable infrastructures based on computing platforms. But when it comes to industrial process controllers, the designer recognizes that a new design and programming paradigm is required. This is well accepted throughout the automation and control industry.
This special paradigm is closely related with many concepts involving signals acquisition, transducers, control set points and other aspects mostly related to process state variables, measurements and control. But mostly, such paradigm is closely connected with real-time processing. The concept of real-time processing is the main paramount that any engineer must take into account when a new automation and control system is designed, developed and deployed. This is, in other words, what differentiates automation software designers from designers of any other application software. It's not better or worse, easier or harder; it's just different.
Automation controllers are required to be real-time systems because they must control physical processes or plants that demand real-time control. At this point, the automation controller designer must have a very good idea on what a real-time system is. Hermann Kopetz, in his book, "Real Time Systems: Design Principles for Distributed Embedded Applications" (2011), stated that "A real-time computer system is a computer system where the correctness of the system behavior depends not only on the logical results of the computations, but also on the physical time when these results are produced. By system behavior we mean the sequence of outputs in time of a system." For any physical plant to be governed, it requires a controller capable of acquiring some input signals and producing some specific output signals within a very specific time frame. If the controller outputs occur outside such time frame, those outputs will no longer be valid, and will produce malfunctions or even a catastrophic failure in the physical plant.
How can we determine that a computer system is actually a real-time system? Figure 1 (above) can help answer this question. Suppose there is a very simple system, with just one input and one output. Such system generates an output signal every time it receives an input signal. Please note in Figure 1 that the output signal is produced t seconds after the input signal is introduced.
Now suppose that we repeatedly (but not periodically) apply the same input signal to this system. We may expect that this system will generate the same output signal every time, at exactly t seconds after the input signal is applied. Unfortunately, this is not what happens in actual controllers. The same output signal will be generated by the controller every time, but the time t that it takes the controller to produce each output may increase slightly (see Figure 2). If we repeat this experiment, we will find that the controller response times fall into a variation interval, say Δt. Some literature refers to Δt as "latency jitter."
The question is: Who determines this magnitude Δt? It strongly depends on how the controller hardware was designed, which components were used, and how the application software running inside it was designed and developed.
At this stage, something needs to be mentioned: the time magnitude t is not related to the time variation value, Δt. The former depends on the function that the controller is supposed to perform, while the latter depends on how the designer implemented such function inside the controller.
It is important to point out that no controller system can reach Δt = 0. Therefore, the controller designer must know the maximum that the physical plant would allow without causing any failures or damages, and consequently he/she must build the right real-time controller which takes into account such constraint.
Hard real time, soft real time
Depending of the physical plant and the type of control to be performed, the controller may be classified as "hard real time" or "soft real time." If the specific characteristics of the plant or process to be controlled are such that a non-compliance of its Δt constraint will produce a malfunction or a failure, then the controller must be a "hard real-time" controller. If, on the other hand, the specific characteristics to be controlled are such that a non-compliance of its Δt constraint will generate a degradation of the plant functionality, but will not produce any malfunctions or failures, then a "soft real-time" controller may be used.
The value of Δt to be used as the main constraint for a process controller design depends heavily on the nature of the process that is to be controlled. Each physical process has its own "latency," that is, the mean time the process reacts from a change in one or several of the inputs. This latency is tied to the physical, chemical and electrical laws governing such process. For instance, the latency of an oil production process is very different from the latency of an electric power transmission system.
The table below shows latency times for some process types.
Based on experience, a basic "rule of thumb" for automation controller design is that the controller's Δt must be at least 5 times smaller than the latency of the process such controller is intended to govern. Of course, this also depends of many other considerations, like power consumption, heat dissipation, available space and many other constraints, not discussed here.
Designing a hard real-time controller is a lot harder than building a soft real-time controller. Depending on the physical process and the specific application, the designer must chose to build one or the other.
Most controllers for industrial applications available in the market are soft real-time controllers. The good news about this is that almost all industrial automation and control applications may be governed by soft real-time controllers. Just in a few, very specific situations, a hard real-time controller is justified and installed. But, as long as a good controller is designed or chosen, in which its latency jitter Δt is small enough compared to the process latency, a reliable automation solution may be provided.
Next up: Reliability criteria
What are the criteria to adequately design a reliable controller? This interesting subject will be the content of the next articles of this series.
Mario Torre is a real-time systems design and architect specialist, focused on digital oil field automation, control and real time information systems. He is an Electronic Engineer with a master degree in Systems Engineering. Mario is currently a Consulting Advisor on Intelligent Operations Solutions (IOS) Global Group, in Halliburton, Landmark Software and Services in Houston, TX. Edited by Brittany Merchut, Project Manager, CFE Media, bmerchut(at)cfemedia.com
See the Control Engineering PLC and PAC page.
Please post any questions or comments using the interface below.