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.

By Mario Torre July 31, 2014

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.

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:

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.

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.

Author Bio: Mario Torre is digital architect, IoT, at Sensia (a JV of Rockwell Automation and SLB).