Process Control

Many systems are intended to provide real time dynamic control of a physical environment using a feedback loop, where the system uses a set of inputs to determine a set of outputs which will help produce a new state of the environment. How do we implement such a system efficiently?

Real time dynamic control systems are used to allow digital systems to interact with the physical world, for example: control systems for machines and engines. Such systems use sensors to receive information, perform computations, and control the machine or engine via actuators. Unlike applications based on iterative refinement, real time control systems are designed with the intention for the control process to continue indefinitely.

For example, an engine control unit receives the accelerator’s position and current RPM as inputs, and changes the amount of fuel injected into the cylinders so that the amount of torque produced by such engine corresponds to the accelerator’s position.

Frequently these systems take the form of a dynamic, stateful system which provides sensor feedback to a controller. The controller then has access to a set of parameters that modify the dynamics of the system. The system under control is usually stochastic and unpredictable, and has real-time constraints; correct functionality depends upon deadline-driven response to sensor feedback. Engines and machines generate analog information. Digital Control Theory was developed so that micro-controllers and computers could be used to perform such control tasks.

Universal Forces:

Sample Rate Samples are taken at regular intervals, as determined by Digital Control Theory. A higher sample rate provides higher accuracy, but requires more computation. Since the controller needs to guarantee that the computations are finished before the deadline demanded by the physical requirements of the system, the designer needs to balance the trade-off between high sample rate and computation limits

Model Complexity The controller performance can improve significantly from using an internal model of the system under control. The complexity of this model influences the latency of its response. However, a more complex model provides more precise control over the system. Similar to the sample rate, simpler models are usually faster to compute, but may not capture some nuances of the physical system.

Implementation Force:

Determinism vs. Performance Real-time constraints demand that the controller respond within its allocated time to sensor feedback. Control systems designers measure execution times in order to guarantee that deadlines are always met. It is much harder to guarantee deadlines in systems that vary their performance depending on conditions that cannot be easily modeled. For instance, caches are widely used by the IT industry, since they increase the global throughput of computer system. But in the case of control systems, their use reduces determinism in the system. When designing a dynamic control system, system designers need to decide if multiple cache levels should be used.

The Process Control pattern provides isolation between the various pieces of the problem:

1. The software required to interface to the physical sensors
2. The software required to interface the system’s actuators
3. The model of the system under control, and the functionality and policy of the controller.

Regarding implementing this pattern on parallel hardware, there exist explicit dependencies between the components, making the feedback loop sequential by definition. However, concurrency can often be extracted from within each of the components, e.g.: collecting and processing data from multiple sensors, controlling multiple actuators, performing computation in the controller.

By isolating the code for the three system components, evaluating the central trade-off of the system design becomes possible. The designer is free to experiment with the parallelization of each of the components to balance precision in control versus response latency.

The characteristics of the software components that interface both with the sensors and the actuators are determined by the physical properties of the system to be controlled. For instance, if the physical system has a temperature sensor that takes 200 milliseconds to provide a new reading, this is how fast the sensor interface software needs to read the input data from this sensor. The complexity of the model, on the other hand, is dictated by both the computational capabilities of the device used and the deadlines required by the system. Most of the time, the amount of computational power available is dictated by cost, heat, etc.

Control software is usually designed as an iterative process. The process can be described as follows:

1. Determine the system requirements in terms of response characteristics of the closed loop system,
2. Choose a suitable controller architecture and design a coarse mathematical model for the controlled system and the closed loop system,
3. Use an initial estimate for the parameters of the controller that is appropriate for this type of controller and system,
4. Simulate your closed-loop model (from step 2) with the parameters (from step 3) and compare to the system requirements (from step 1)
   1. If the system is unable to satisfy the requirement, go back to step 2 and incorporate a different, likely more complex, controller architecture,
   2. otherwise, implement your controller from step 2 with the parameters from step 3 on the chosen processor.

Sample Rate

In choosing the sampling rate, the central aim is to find a rate that is as low as possible while still meeting all design criteria, especially closed loop stability and required error margins. To help in the selection, several rules of thumb exist. One of those relates the sampling rate Fs to the closed-loop bandwidth Fc of the controlled system by Fc *5 < Fs < Fc *30 [The control handbook, W. S. Levine], while others take into account the rise time of the feedback system or the phase margin of the discrete control system. In general, it is advisable to check via computation of the discrete system transfer function (for linear systems) or via simulation (for non-linear and stochastic systems), whether the chosen sampling rate will satisfy all requirements placed on the control system.

Model Complexity

As mentioned before, the amount of computational power available is often dictated by cost. Such requirements impose a hard limit on the processing power available. Usually, system designers are required to figure out what is the simplest model that captures the behavior of the system, since simpler models usually require the least amount of computation power. However, more complex models may provide benefits that justify a higher cost for the controller. For instance, low emission engines require a more complex model in order to improve the efficiency of the combustion.

Determinism vs. Performance

A very important characteristic of dynamic control systems is the need for determinism, since in many of these systems missing a deadline may have serious consequences. An example would be an Anti-lock Braking System (ABS) that could cause a collision if deadlines were missed. One way to guarantee that deadlines will never be missed is to compute the worst time execution of each individual computation, and choose a processor that would allow the system to meet all the deadlines. However, for most systems, empirical evidence shows that the sequence of execution does not follow the path that takes the longest time. Thus, using worst time execution to determine which processor to choose would lead to an overestimation. Also, caches can be used to speed-up performance, but their use reduces determinism. Control systems designers have to balance these requirements. In order to find a suitable solution, multiple simulations are performed, and systems are tested in real conditions multiple times.

The only paths of information between the process and the controller are the sensors and the actuators. Information travels from the sensors to the controller (read only), and from the controller to the actuators (write only). It is presumed that the controller understands the inherent unreliability of the sensors and actuators: the Process Control pattern itself makes no provision for hardware failures. Furthermore, the controller must understand possible anomalies and prevent the closed loop system from becoming unstable.

Many Real-time control systems fit the Process Control pattern. In this section we will use an engine management system to provide a concrete example about a real time control system.

The goal of the engine management system is to control all the actuators to deliver the required torque and obtain optimum engine operation in terms of fuel consumption, performance, exhaust gas emissions and driving smoothness. In such a system, a sensor measures the torque produced by the engine. If there is a need to increase the torque, computations are processed to determine the increase in the amount of air-fuel (A/F) mixture that needs to be provided to the engine. As the A/F mixture increases, torque starts to increase. The torque sensor sends new measurements to the engine control unit that in turn uses an actuator to control the new A/F mixture. When the desired torque is reached, the controller stops the increase in the A/F mixture.

Computations are performed either at a fixed time interval (regular time sample) or associated with the camshaft’s rotation angle (irregular time sample), thus depending on the engine’s RPM:

1. computing the necessary A/F mixture is an example of computation executed at a fixed time interval. Such computations are highly deterministic.
2. determining the time at which the the spark plugs will ignite the A/F mixture depends on the engine’s RPM. The higher the RPM, the more times this function is called and the more computations are performed in a fixed time interval. Because of this, such tasks reduce the determinism in the system.

Forces

Model complexity – engine management systems usually employ a simplified version of the physical models in order to simplify the hardware and software used. For instance, instead of solving a system of equations to compute the amount of fuel required at a given torque, altitude, air temperature, etc. in real-time, most of this computation is done off-line and a look-up table is created. Then, at execution time, the system uses the value at the look-up table and performs a simple interpolation between the nearest neighbors. However, more complex models may provide benefits that justify a higher cost for the controller. For instance, low emission engines require a more complex model in order to improve the efficiency of the combustion.

Determinism – it is common for engine management system to make limited uses of caches. Despite the increase in overall system throughput associated with the use of caches, the lack of mathematical tools that allow the deterministic modeling of cache behavior makes the system’s behavior less predictable. Software designers for engine management systems usually choose determinism over system throughput.

Concurrency and Parallelism

Computations in an engine management system are traditionally executed serially and great care is taken to guarantee determinism in the system. The introduction of parallel hardware, and consequently software and algorithms, threaten to reduce determinism. A challenge is how to design parallel algorithms that take advantage of possible concurrency in the domain while still maintaining a large degree of determinism.

1. Heating, Ventilation and Air Conditioning (HVAC) systems read the current temperature from thermostats and adjust the flow of hot or cold air so that the room temperature is kept at the value specified.
2. Autonomous navigation systems such as the ones used in the DARPA Grand-Challenge. Various sensors, such as GPS, cameras, and laser scanners, are used to acquire information about the surrounding environment and the car’s location. This information is used to control the car’s accelerator, breaks, and steering wheel so that the car follows a predetermined path.
3. Anti-lock breaks (ABS) in automobiles and airplanes use sensors at the wheels to sense the angular speed of each wheel and modulate the brake pressure to prevent the wheels from locking.
4. An airplane’s auto-pilot system reads data from sensors and provides hydraulic pressure to the actuators on the control surfaces to maintain heading and attitude.
5. A Dynamic-Range Compression system in audio applications (e.g. a hearing-aid) adjusts the gain applied to the input audio signal based on a short-time average of perceived loudness.

The Process Control pattern is neither inherently sequential nor inherently parallel. Therefore the PLPP patterns do not directly apply.

Related Algorithm Strategies:

1. The Pipe-and-Filter Pattern deals with a similar type of parallelism, however, the feedback loop presents a necessary extra consideration in implementation.

Parallel Algorithm Strategy Patterns that are of interest in parallel implementations of Process Control:

1. Parallelism for tasks along a linear branch in the control system can be exploited using the Pipeline Pattern.
2. Parallel control paths can use the Task Parallelism Pattern.

Structural and Computational Patterns that can aid in the implementation of specific types of controllers:

1. The Event-based Implicit Invocation Structural Pattern can be useful for event-driven control systems.
2. The Finite State Machine Computational Pattern can be applicable for very large finite state machine controllers.

1. The Control Handbook, W. S. Levine

Mark Murphy, Eric Battenberg

Enylton Coelho, Jike Chong, Dorothea Kolossa