Model Based Predictive
Networked Control Systems
What is a networked control system, why is it necessary?
Networked control systems where the sensors, controller and actuators of a digital controller reside on different computer nodes linked by a network aim to overcome the disadvantages of conventional digital control systems, such as difficulty of modification, vulnerability to electrical noise, difficulty in maintenance and upgrades, at the application level. However data delay and loss on the network may jeopardize stability.
In this project, we propose a novel networked control method where satisfactory control is possible even under random delay and data loss by keeping a model of the plant inside the control controller node and at every sampling period reset the states of this model to the actual or predicted states of the plant.
The purpose of this project is to derive the stability criteria of the method and evaluate the results. The effects of data loss and delay, the choice of network protocol, plant model inaccuracies and sensor noise will be investigated. The theoretical results will first be verified first on the simulation test bed which has already been completed, and later, on a dedicated experimental platform, which has been built by the project team. The results are directly applicable to the needs of the industry.
This project is supported by TUBITAK research grant 106E155
You can find a more detailed abstract here.
How do they work?
In conventional digital control systems, there are two major components, the controlled plant and the controller. Outputs of the plant are sampled at periodic intervals by the controller, a control algorithm applied to the samples, and the result of the control is produced at the output of the controller generally as a zero order hold signal.
From the theoretical point of view, there is no problem in this approach. From the implementation point, several aspects can be improved:
As a remedy, networked control systems can be used. The idea is to design sensor, control and actuator as separate computer nodes connected by a communication network. The same process as explained above is repeated, except data travels from sensor to control and control to actuator through a communication network instead of dedicated connections.
This way, the control system becomes more flexible. It can be implemented strictly in the conventional layout, or have different layouts as show in the figure above where several sensors, controllers and actuators can be present at the same time. Although this setup helps solve the above problems, it brings in problems of its own:
Network caused delay directly contributes to the delay in the control loop and contributes towards instability of the system. Data loss is similar in this respect. Therefore research must be done to enable common use of this type of control implementation.
What are the remedies? What are we doing?
The remedy to the network delay is to use a dedicated real-time network in the implementation. This network is specially designed to have a guaranteed upper bound on transmission delay, so that stability is not jeopardized. However this is not a simple solution. Such networks must have carefully tuned parameters for each application, and cannot be readily expanded. Similarly, they are not flexible in the amount of data they can transfer. Timed token protocol, master slave type protocols, TDMA type protocols are some examples.
We propose to use normal data communication networks which cause losses and delay, but we cover for these problems by using a model of the controlled plant for making predictions of future control outputs. These decisions are refreshed at each sample and send to the actuator node. In the actuator node, if the control commands do not arrive for delay or loss, the previously sent prediction is used instead. Please look here for a more detalied explanation of our method.
Where will they be used?
This type of control system can be used in many real-time applications such as automation, automotive and process control. Especially in noisy environments such as automobiles and most types of factories; where large plants must be dealt with such as steel mills, printing and production lines, building automation; and cost is a significant factor. The idea is to use common technologies in control and communication in a place they were not initially intended.
Most of communication theory and computer theory is based on open-loop systems in which we must send data through as fast as possible or crunch numbers as fast as possible. Therefore performance is evaluated using throughput figures such as MB/s or MIPS. In control, we are looking at closed-loop systems in which a given snippet of data should be sampled, processed, and output within a given time. This is latency. It is very possible that systems with high throughput can also have high latency and be useless for closed-loop applications.
There are many misconceptions. Here are a few:
It is possible to use a high speed communication network to reduce the amount of delay.
Modern communication networks really have very high throughputs. Gigabit ethernet, Firewire and USB are protocols where we can go up to 1Gb/s. For a control applications of 1-10kHz sampling frequency, they seem to be sufficient. The misconception here is that of confusing throughput with latency. Such networks are made to deliver large packets at once, with significant latency compared to their bandwidth.
Consider a gigabit network, delivering 10^9 bits/s. That is roughly 10^8bytes/s. If a message packet is made up of 300 bytes including overhead, we can transfer 10^6messages/s. If the sampling time is 10kHz, (10^4), then we can send approximately 30 messages/sample. This may sound fine until we consider that Gigabit ethernet is gigabit only as a theoretical maximum. Normally we can only use %40 of that capacity. That makes 12 messages/sample.
Similarly, the gigabit implies only the throughput value. It says nothing about the latency of the messaging, in which time is wasted in preparation of packets, queuing, actual transmission, and decoding the packet. When these add up, we see that if we want to send one message from the sensor node to the control node, run the control algorithm based on the received data, and send the result to the actuator node as one more packet, we barely have enough time even using a gigabit network. This does not take into consideration the possibility of packet collisions and re-transmissions.
Data loss over the network can be taken care of using common methods such as acknowledgement.
Error correction by retransmission is common since long time ago. However, in closed loop applications such as control, if the sensor to control data is lost, there is little meaning in devoting time to its retransmission, a new sample must be sent instead. Control to actuator is similar. Therefore such conventional methods are not useful in out applications. We must find ways to live with lost data.
We can use very high speed computers in control loops to get rid of computational bottleneck.
This misconception is similar to the first. Computer speed is a measure of its throughput, not latency. Throughput enhancing methods such as pipeline and cache do no good in closed-loop applications. If we think of the system as one byte passing through the control loop per sampling period, we can realize that pipeline is not very beneficial because it will be empty most of the time. Similarly, looking from a real-time system point of view, cacheand page misses are a source of procesing time uncertainty. Think of the times when the mouse just stops responding for a few seconds on your desktop computer which is enough to cause damage if it were controlling the tooltip of a CNC mill.
Again, this is an example of mixing up throughput with latency.
Networked Control Systems Repository: An active site dealing with networked control systems
RUNES: Reconfigurable Ubiquitous Networked Embedded SystemsEuropean Union Consortium supproted by FP6.
HYCON: European Union Network of Excellece on Hybrid Control
SIGBED: ACM Special Interest Group on Embedded Systems
TrueTime: Matlab toolbox allowing the modeling of networked control systems to a high degree of accuracy.