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.

Figure 1: A simple system, Courtesy: Mario TorreToday, 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.

Real-time processing

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.

Real-time explanation

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.

Figure 2: Inserting input signal repeatedly to system. Courtesy: Mario Torre

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.

Table 1: Average Latencies. Courtesy: Mario Torre

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)

See the Control Engineering PLC and PAC page.

Please post any questions or comments using the interface below.

No comments
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
Each year, a panel of Control Engineering editors and industry expert judges select the System Integrator of the Year Award winners.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
Learn how to increase device reliability in harsh environments and decrease unplanned system downtime.
This eGuide contains a series of articles and videos that considers theoretical and practical; immediate needs and a look into the future.
Learn how to create value with re-use; gain productivity with lean automation and connectivity, and optimize panel design and construction.
Go deep: Automation tackles offshore oil challenges; Ethernet advice; Wireless robotics; Product exclusives; Digital edition exclusives
Lost in the gray scale? How to get effective HMIs; Best practices: Integrate old and new wireless systems; Smart software, networks; Service provider certifications
Fixing PID: Part 2: Tweaking controller strategy; Machine safety networks; Salary survey and career advice; Smart I/O architecture; Product exclusives
The Ask Control Engineering blog covers all aspects of automation, including motors, drives, sensors, motion control, machine control, and embedded systems.
Look at the basics of industrial wireless technologies, wireless concepts, wireless standards, and wireless best practices with Daniel E. Capano of Diversified Technical Services Inc.
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
This is a blog from the trenches – written by engineers who are implementing and upgrading control systems every day across every industry.
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.

Find and connect with the most suitable service provider for your unique application. Start searching the Global System Integrator Database Now!

Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.

These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.

Click here to visit the Case Study Database and upload your case study.