Fundamentals of real-time processing in automation and control, part 2

The most important constraint in a real-time system is that the time it takes to process an input and produce an output must be well known. Part 2 of a series of articles on real-time control systems.


This is the second part of a series of articles referred to real-time systems, real-time processing and fundamentals in real-time automation and control systems design and development.

The previous article explained what characterizes a real-time system. The most important constraint in a real-time system is that the time required for processing an input and producing an output must be well known. In other words, the processing time of a real time system to get a solution is part of the solution. Of course, for a particular system, such time is not always exactly the same; it may vary. This deviation, that we have called "latency jitter" or Δt, essentially defines the "determinism" that a real-time system is providing. The closer Δt approaches zero, the more deterministic a real time system is.

To be governed, any physical plant requires a real time controller, which is, per se, a real time system. The controller Δt must be at least 5 times smaller than the latency of the plant. This is a very general rule-of-thumb, but may be diff depending on the application and other considerations and trade-offs. In any case, the controller designer is, at some point of time, compelled to design a real-time controller with a specific Δt.

So, now the question is: how can we reliably design a controller that guarantees some specific ? For simplicity, the discussion here will:

  • Consider the design of an electronic controller for a plant.
  • Assume that all sensors, transducers and actuators are readily available, and that all inputs and outputs are electric signals.
  • Consider that this controller will be a digital controller, that is, analog to digital conversions are made, and the control functions are being made by logical and mathematical operations.

So, in brief, this controller will be developed using (mostly) digital electronic components, PC boards, and related parts.

The most basic approach for any electronic designer to come up with a controller is to go with discrete components. Any digital controller may be implemented using logical gates, flip-flops, and buffers. Those components have a great performance in regards to latency jitter. The Δt of most of those components is very low (depending on gate technology, it is about 40-50 nanoseconds), so the overall controller latency jitter typically won't exceed 1 microsecond, which is good enough for most real time applications, even hard real time.

The main issue with this "hardware" approach is its lack of flexibility and expandability. If there's a need for an extra input or a change to controller functionality, then a new controller must be designed. However, it is important to say that this hardware approach was widely used in the past, and it is still being used in very specific applications, most of them in the hard real time domain.

To date, almost all digital controllers are microprocessor-based controllers. The designer is no longer entitled to build the hardware for a controller. Controller hardware has been standardized, and all signal treatment, filtering and processing are being managed by microprocessors. Most of them have several processing cores, depending on the type and purpose of the controller. It may sound simple, but to date the work of a controller designer has been reduced to: 1) Selecting the right controller hardware according to the application; 2) Choosing the operating system to be used; 3) Selecting the programming environment or framework that will further help with the development, and 4) Developing a software application to implement the actual controller function that is needed for the plant that the control designer envisions to control.

Selecting the right hardware controller for the application may be, by itself, a complicated task. The characteristics of hardware controllers will depend on the elapsed time t required for the controller to provide the solution, and the latency jitter Δt that is expected from such controller. It is also determined by many other factors and conditions that go beyond considerations here. For this discussion, let's say that the correct hardware selection criteria will need to meet the following requirements: 1) Must be fast enough to handle the required elapsed time and latency jitter; 2) Must be able to handle processor interrupts in real-time, and 3) Must provide an "adequate" development and runtime software environment in which the designer can design and deploy the required software application.

Once the hardware is selected, the designer creates the software application using a computer language according to the chosen software development environment. Nowadays, hardware controllers include a rich, intuitive software development environment, where applications may run over some specific operating system and a programming framework. Although it is not mandatory, the use of the hardware manufacturer's suggested programming framework is advised. Please note that designing software applications without using any software environment is similar to building the hardware out of discrete components and chips, as explained earlier.

Suppose that the designer already selected the hardware and is about to design a new software application on top of the selected operating system, using a programming language. Depending on the programming language preferred, there may be more "software layers" between the hardware and the actual controller application: frameworks (as Microsoft .NET), virtual machines (as Oracle Java) or even hardware manufacturer proprietary frameworks or programming interfaces.

All these layers further separate the controller application from the input and output signals. Also, it must be noted that each of those layers add latencies and processing times. Figure 1 shows the processing layers for a typical controller implementation.

Figure 1 shows controller design processing layers. Courtesy: Mario Torre

As displayed in Figure 1, an input event must be handled from its occurrence, through all the layers, up to the actual application which will process it. Once processed, the application must send the results to the actual output port, which also must go through the same layers. The total response time for this simple control application, using the above stack of hardware and software layers, can be calculated as:

Figure 2 shows the calculation for total response time for this simple control application, using the stack of hardware and software layers in Figure 1. Courtesy: Mario Torre

However, under this scenario, how can the designer guarantee that the total response time t will be the required one for the plant? How can the control designer ensure that such response time will be within a specific latency jitter Δt? The table shows a detailed explanation of each one of the time components and how each one affects and also gives some initial recommendations on how to achieve the desired results.

Table: Controller application time components. Courtesy: Mario Torre

Each one of the time components above mentioned provides a portion on the total resulting controller latency jitter Δt. One of the main duties of the controller designer is to assess every one of those components, and adequately weight them to make sure that: 1) resulting controller latency t is the required one; 2) the sum of Δts from all time components will not go beyond the desired latency jitter.

This is not an easy task. Please note that what is exposed in Table 1 is a very simplistic first view of a real time controller design. There are many more considerations that must be made by the controller designer and assigned team that also affect selections of hardware, operating systems and frameworks far beyond the strict real time performance of the controller.

At this point, just a few of very basic recommendations have been presented, for each one of the controller processing layers. The next article will review controller processing layers and discuss additional guidelines and best practices to design and develop an effective controller that can govern real time plants in a robust and reliable way.

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. He 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, 

See the Control Engineering PLC and PAC page.

Please post any questions or comments using the interface below. 

- See part 1 of Fundamentals of real-time processing in automation and control below.

LARRY , WA, United States, 10/20/14 06:12 PM:

Two comments about aspects of this survey. First the claim: "The most important constraint in a real-time system is that the time required for processing an input and producing an output must be well known..." Well, knowing is certainly important for analysis, but probably more important that the system CAN PERFORM all processing within its time constraints. In a real-time system, violating a time constraint is a kind of system failure. What is the consequent cost? Is it an annoying but obvious glitch in a summary report? Or is it driving a workpiece through the floor with a hydraulic press that fails to get a timely "close valve" message?

A second point is that "jitter" is usually taken to be synonymous with "random disturbance." It is often helpful to split the analysis into two parts: real-time delays T that are non-random and knowable (like delay to move heated water through a pipe), and delays dT that truly are unpredictable and best described by a probability distribution (like message transport time through a communication stack). Ironically, real-time feedback systems are sometimes quite robust to unbiased random variations, as late arrival of information is soon balanced by early arrival of information, and the net impact greatly lessened. But persistent time delays can cause persistent phase delays that produce havoc with loop stability.

While appropriate issues are indicated, beware that some of the recommendations are not as simple as they first seem, for example "avoid polling." Does that mean "PLC devices are forbidden"? Maybe it does sometimes, but well-defined fixed delays at the lowest practical level of the system can sometimes avoid seriously longer unpredictable delays for transporting information up and down the system hierarchy.
Jonas , Singapore, 10/21/14 07:50 AM:

There are solutions out there which are time-synchronized which helps ensuring real-time behavior. This includes for instance PROFIBUS-DPv2 and other motion control buses. For process control you can use FOUNDATION fieldbus which synchronizes input, control, and output:
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
The System Integrator Giants program lists the top 100 system integrators among companies listed in CFE Media's Global System Integrator Database.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
This eGuide illustrates solutions, applications and benefits of machine vision systems.
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.
Make Big Data and Industrial Internet of Things work for you, 2017 Engineers' Choice Finalists, Avoid control design pitfalls, Managing IIoT processes
Engineering Leaders Under 40; System integration improving packaging operation; Process sensing; PID velocity; Cybersecurity and functional safety
Mobile HMI; PID tuning tips; Mechatronics; Intelligent project management; Cybersecurity in Russia; Engineering education; Road to IANA
This article collection contains several articles on the Industrial Internet of Things (IIoT) and how it is transforming manufacturing.

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

SCADA at the junction, Managing risk through maintenance, Moving at the speed of data
Flexible offshore fire protection; Big Data's impact on operations; Bridging the skills gap; Identifying security risks
The digital oilfield: Utilizing Big Data can yield big savings; Virtualization a real solution; Tracking SIS performance
click me