networked control system: theory and simulations

NETWORKED CONTROL SYSTEM: THEORY AND SIMULATIONS

A Project by Sandeep Bimali Bachelor’s Degree in Electronics Engineering, Tribhuvani University, Nepal December 2001

Submitted to the Department of Electrical and Computer Engineering and the faculty of the Graduate School of Wichita State University in partial fulfillment of the requirements for the degree of Master of Science

December 2005

NETWORKED CONTROL SYSTEM: THEORY AND SIMULATIONS

I have examined the final copy of this Project for form and content and recommend that it be accepted in partial fulfillment of the requirement for the degree of Master of Science, with a major in Electrical Engineering.

____________________________ Dr. John M. Watkins, Committee Chair

We have read this project And recommend its acceptance:

____________________________ Dr. Steven R. Skinner, Committee Member

____________________________ Dr. Coskun Cetinkaya, Committee Member

ii

ACKNOWLEDGEMENTS

I would like to express my thanks to my project advisor, Dr. John M. Watkins, for his guidance and continuous support throughout the project work. He has been a continual source of information and fresh ideas in the process of completing this project. I would also like to thank Dr. Steven R. Skinner and Dr. Coskun Cetinkaya for reviewing my project and serving on my project committee. A big thanks to my friend, Deependra Malla, who took his personal time to review and helped me edit the project report. My family and my beloved wife Meghna deserve my deepest gratitude for their constant source of love and encouragement throughout my studies.

iii

TABLE OF CONTENTS

CHAPTERS

1. Introduction ………………………………………………………………… 1

2. Background ………………………………………………………………… 2 2.1. Networks and Control ………………………………………………….

2

2.2. State Space Models for Systems with Delay ………………………….. 3 2.3. Fundamental Issues in Networked Control Systems ………………….. 6 2.4. Compensation for Network Induced Delays ………………….……….. 7

3. Simulation Framework ……………………………………………………… 10 3.1. TrueTime – A Simulation Environment ……………………………….. 10

4. Simulation Results …………………………………………………………. 17 4.1. Simulation Model ……………………………………………………… 17

5. Conclusion …………………………………………………………………. 21

List of References

……………………………………………………………. 22

iv

Chapter 1

Introduction The study of Networked Control Systems (NCSs) brings together the historically separate disciplines of computer networks and control theory. Feedback control systems, wherein the loops used to control the behavior of a plant are closed through a real-time communication network, are called networked control systems. The defining feature of an NCS is that information is exchanged using a network among control system components (sensors, controller, and actuator). The insertion of the communication network in the feedback control loops makes the analysis and design of an NCS complex. Conventional control theories with many ideal assumptions, such as synchronized control and non-delayed sensing and actuation, must be reevaluated before they can be applied to NCSs. The issues that needs to be addressed while designing an NCS include, network-induced delays that occurs while exchanging data among devices connected to the shared medium, and packet losses, because of the unreliable network transmission path, where packets not only suffer transmission delays but, even worse, can be lost during transmission. In this project, an attempt has been made to analyze the stability of an NCS resulting from the network-induced delay (sensor-to-controller delay and controller-toactuator delay). A simple compensation scheme has been proposed to minimize its effect. For this purpose, I have used TrueTime, a Matlab toolbox for simulation of distributed real-time control systems.

1

Chapter 2

Background

2.1

Networks and Control Network control systems (NCSs) combine two engineering fields, control and

computer networks. Computer networks can be wired or wireless. Because NCSs are implemented over a network, a good understanding of underlying communication network protocols, such as Ethernet, Token Bus or Token Ring is required to analyze and model the system’s behavior. The International Organization for Standardization (ISO) has created a reference model for computers in a network to communicate with each other, called Open System Interconnection (OSI). The OSI model is the primary architectural model for networks. It describes how data and network information are transmitted from an application on one computer, through the network media, to an application on another computer. The OSI reference model breaks this approach into sever layers: the application layer, the presentation layer, the session layer, the transport layer, the network layer, the data link layer and the physical layer from the top to the bottom respectively. Media Access control (MAC), which is a sub layer of the data link layer, is responsible for the physical transmission of data to the proper device on a local area networks (LAN) using a hardware address and also handles error notification. The IEEE 802 committee has issued standards for LANs [2]: IEEE 802.3 (Ethernet), IEEE 802.4 (token bus) and IEEE 802.5 (token bus).

2

Ethernet (IEEE 802.3) uses carries sense multiple access with collision detection (CSMA/CD) protocol to control its communication. The transmitting nodes terminate their transmission after detected collisions. They wait for a random period of time defined by an exponential back off algorithm and try to send the frames again. The token bus (IEEE 802.4) is a token ring over a virtual ring on a coaxial cable. A token is passed around the network nodes and only the node processing the token may transmit. If a node doesn’t have anything to send, the token is passed on to the next node on the virtual ring. Each node must know the address of its neighbors in the ring, so a special protocol is needed to notify the other nodes of connections to, and disconnections from the ring. The token ring (IEEE 802.5) has stations logically organized in a ring topology with data being transmitted sequentially from one ring station to the next with a control token circulating around the ring controlling access. When no station is transmitting a data frame, a special token frame circles the loop. The special token frame is repeated from station to station until arriving at a station that needs to transmit the data. When a station needs to transmit a data frame, it converts the token frame into a data frame for transmission.

2.2

State-Space Model for Systems with Delay The time delay phenomenon in control paths or state variables is unavoidable in

many physical systems. Time delays are common in networked control systems and the design of controllers for such systems depends critically on knowledge of the delays. Ignorance of the delay during analysis and design of digital controllers may lead to

3

unpredictable system performance. For the ease of implementation, the realization of a discrete-time state space model of a system with delay shorter and longer than one sampling period is presented in the following section.

Delay Less Than One Sampling Period Consider the linear state equation with input delayed by λ [1]:

x& (t ) = Ax(t ) + Bu (t − λ ) ,

(1)

y(t) = Cx(t).

(2)

where x(⋅) is called the “state vector”, y(⋅) is called the “output vector”, u(⋅) is called the “input (or control) vector”, A is the “state matrix”, B is the “input matrix”, and C is the “output matrix”. The general solution to the equation is t

x(t ) = e A (t −t0 ) x(t 0 ) + ∫ e A ( t −τ ) Bu (τ − λ )dτ t0

By sampling the system with sampling period h and assuming a zero-order hold on the input, the solution for the state is kh + h

x(kh + h) = e A ( h ) x(kh) +

∫e

A ( kh + h −τ )

Bu (τ − λ )dτ

k=0, 1, 2, 3…

kh

Since the delayed input signal u(t-λ) is not piecewise constant over the sampling period interval, the delayed signal will change during one sampling period. The modified solution to the equation is kh + λ

x(kh + h) = e A ( h ) x(kh) +

A ( kh + h −τ ) Bdτu (kh − h) + ∫e

kh

A discrete-time state space model of the system is given by 4

kh + h

∫ λe

kh +

A ( kh + h −τ )

Bdτu (kh)

⎡x(kh + h)⎤ ⎡Φ Γ1 ⎤ ⎡ x(kh) ⎤ ⎡Γ0 ⎤ ⎢ u (kh) ⎥ = ⎢ 0 0 ⎥ ⎢u (kh − h)⎥ + ⎢ I ⎥u (kh) ⎣ ⎦ ⎣ ⎦⎣ ⎦ ⎣ ⎦

where Φ = e Ah , kh + h

Γ0 =

∫ λe

A ( kh + h −τ )

Bdτu (kh) , and

kh +

kh + λ

Γ1 =

∫e

A ( kh + h −τ )

Bdτu (kh − h) .

kh

Longer time Delay

If the time delay,λ, is longer than the sampling period, h, one may receive zero, one, or more than one control samples in a single sampling period. The analysis needs a little adaptation. Decomposeλ, such that

0 < λ' ≤ h

λ = (d − 1)h + λ' where d is an integer. The analysis is modified to

x(kh + h) = Φx(kh) + Γ0 u (kh − (d − 1)h) + Γ1u (kh − dh). The corresponding state-space description is ⎡ x(kh + h) ⎤ ⎡Φ Γ1 ⎢u (kh − (d − 1)h)⎥ ⎢ 0 0 ⎢ ⎥ ⎢ ⎢ ⎥ ⎢. . . ⎢ ⎥ ⎢ . . ⎢ ⎥=⎢. ⎢ ⎥ ⎢. . . ⎢ ⎥ ⎢ ⎢ u (kh − h) ⎥ ⎢ 0 0 ⎢ ⎥ ⎢0 0 u (kh) ⎣ ⎦ ⎣

Γ0

I . . . 0 0

5

0 . . . . . .

0 ⎤ ⎡ x(kh) ⎤ ⎡0⎤ 0 ⎥⎥ ⎢⎢u (kh − dh) ⎥⎥ ⎢⎢0⎥⎥ ⎥ ⎢.⎥ . . ⎥⎢ ⎥⎢ ⎥ ⎢ ⎥ . . .⎥ ⎢ ⎥ + ⎢ . ⎥u (kh) ⎥ ⎢.⎥ . . ⎥⎢ ⎥⎢ ⎥ ⎢ ⎥ I ⎥ ⎢u (kh − 2h)⎥ ⎢0⎥ I ⎥⎦ ⎢⎣ u (kh − h) ⎥⎦ ⎢⎣ I ⎥⎦

2.3

Fundamental Issues in NCSs The basic problem in NCSs includes network-induced delays, single-packet or

multiple-packet transmission of plant input and outputs, and dropping of network packets [1] and [3]. The network-induced delays in NCSs occur when sensors, actuators, and controllers exchange data packet across the communication network. This delay can degrade the performance of control systems designed without considering it and can even destabilize the system. Categorized by the MAC algorithms, the media access protocols fall into two categories, ones that produces constant transmission periods and those that create time varying transmission periods. The algorithm used in the IEEE 802.3 standard produce time-varying transmission period, whereas the IEEE 802.4 standard and IEEE 802.5 standard yield constant transmission period. Bounds for the transmission period will be needed to guarantee stability of NCSs. Also, depending on the MAC protocol, the delay between transmissions (networked induced delay) is divided into two groups, deterministic and nondeterministic. If the MAC sub layer of a protocol access channel is using random backoff CSMA/CD, in the Ethernet, for example, the delay from the protocol will be random. On the other hand, the scheduling protocols (the IEEE 802.4 standard and IEEE 802.5 standard) will give deterministic delay. These issues were studied in [1], [3], and [4]. Other concerns for stability of NCSs are length of transmitted packets and packet dropping. The underlying protocol of the MAC sub layer in the network is the key to controlling the length of packets to be transmitted. For example, in Ethernet, the data field of the protocol is 1500 bytes, so the size of transmitted packets is unlikely to affect

6

real-time feedback signals, which are only few bytes each. The information can even be lumped and transmitted in one packet. Packet dropping is often an inevitable event in network data transmission despite the provision network protocols. Network packet drops occasionally happen on an NCS when there are node failures or message collisions. In real-time feedback control, data such as sensor measurements and calculated control signals, it might be advantageous to discard the old untransmitted message and transmit a new packet if it becomes available. In this way, the controller always receives fresh data for control calculation.

2.4 Compensation for Network-Induced Delays The compensation for NCSs in considered for sensor-to-controller delay, τsc only. Sensor-to-controller delay can be known when the controller uses the sensor’s data to generate the control signal, provided the sensor and controller clocks are synchronized and the message is time stamped. Thus an estimator can be used to reconstruct an approximation to the undelayed plant state and make it available for the control calculation.

On the other hand, controller-to-actuator delay is different, in that the

controller does not have the information on how long will it take the control signal to reach the actuator, therefore, no exact correction can be made at the time of control calculation. Feedback systems [1] are categorized as full-state feedback or output feedback systems. With full-state feedback, the estimator compensates τsc. In the output feedback system, the estimator has to do both compensation for τsc and estimate the states of the system. These methods are possible if the delays are measurable.

7

Full-state Feedback

With full-state feedback, the only task of the estimator is to compensate for the delay, τsc, to achieve a more accurate plant state at the time the control signal is calculated. Let a system be described as in (1) and (2). For every plant output, the data is time-stamped by the sensor in order to acquire the information about current time delay, τ sc,k . Sensor information reaches the estimator at time (kh + τ sc ,k ) . By assuming there is no measurement noise and all states are measured, the plant information [3] at that time is x(kh + τ sc ,k ) = x(kh + τ sc ,k ) = e

A (τ sc , k )

x(kh) + ∫

kh +τ sc , k

kh

e

A ( kh −τ sc , k − s )

where, x(kh + τ sc ,k ) is the estimated state at time (kh + τ sc ,k ) . Applying the state feedback control law to the system u (kh + τ sc ,k ) = −K ⋅ x(kh + τ sc ,k ), ~ x((k + 1)h + τ sc ,k +1 ) = Φ ⋅ (δ k ) ⋅ x(kh + τ sc ,k ). where

δ k = h − τ sc ,k +1 − τ sc ,k , ~ Φ (δ k ) = Φ (δ k ) + Γ(δ k ) ⋅ K ,

Φ (δ k ) = e Aδ k , and δk

Γ(δ k ) = ∫ e As ⋅ Bds 0

8

Bu ( s )ds

Output Feedback

In practice, all states of some systems are not measured. Here we assume that the outputs from the plant are the only information we know. An estimator is needed to estimate the state. A conventional current-state estimator is used in this study. Without the delay, a current estimator [4] is given by x((k + 1)h) = xˆ ((k + 1)h) + L c ⋅ (( y (k + 1)h) − C ⋅ xˆ ((k + 1)h)),

where, xˆ ((k + 1)h) = Φ ⋅ x (kh) + Γu (kh), u ((k + 1)h) = −K ∗ x((k + 1)h) and L c is the estimator gain. The estimator is calculated in two steps. The estimator state x(kh) is projected forward to the next sample, xˆ ((k + 1)h) . Then the calculation is corrected with the received plant output to give ( x(k + 1)h). When τ sc is taken account, the current estimator scheme is described by 1. Correction based on y (kh) : x(kh) = xˆ (kh) + L c ⋅ ( y (kh) − C ⋅ xˆ (kh)),

2. Forward to x (kh + τ sc ) : x(kh + τ sc ) = e Aτ sc +

kh +τ sc

∫e

A ( kh +τ sc − s )

⋅ B ⋅ u ( s )ds,

kh

3.

Calculate the control law: u (kh + τ sc ) = −K ⋅ x(kh + τ sc ),

4. Forward to (k+1) h: xˆ ((k + 1)h) = e Aτ sc x(kh + τ sc ) +

kh + h

∫τe

kh +

F ( kh + h − s )

sc

9

⋅ B ⋅ u ( s)ds.

Chapter 3

Simulation Frameworks

There are many different ways to simulate the dynamics of a network control system. Likewise, many packages exist to simulate the discrete events of a network system. Traditional control design using Matlab/Simulink, often disregards the temporal effects arising from the actual implementation of the controllers. Presently, controllers are often implemented as tasks in a real-time kernel and communicate with other nodes over a network. Consequently, the constraints of the target system, e.g., limited central processing unit speed and network bandwidth must be taken into account at a design time. For this purpose, I have used TrueTime, a toolbox for simulation of distributed realtime control systems. TrueTime makes it possible to simulate the timely behavior of realtime kernels executing controller tasks. TrueTime also makes it possible to simulate simple models of network protocols and their influence on networked control loops.

3.1 TrueTime- A simulation environment

TrueTime is a Matlab/Simulink-based package written by Henriksson et al., [5] which was designed to simulate the temporal behavior of multi-tasking real-time kernels containing controller tasks. The TrueTime simulation environment offers two simulation blocks – a computer block and a network block as shown in the Figure 1.

10

Figure 1: The TrueTime block library

The blocks are variable-step, discrete, Matlab S-functions written in C++. The TrueTime kernel block (also called Computer block) executes user-defined tasks and interrupts handlers. The TrueTime network block distributes messages between computer nodes according to a chosen network model. Both blocks are event driven with the execution determined both by external and internal events. The blocks inputs are assumed to be discrete-time signals, except the signals connected to the A/D converters of the computer block, which can be continuous time. The schedule and monitors signals indicate the allocation of common resources during the simulation.

The TrueTime Kernel Block

The TrueTime kernel block S-function simulates a computer with a simple but flexible real-time kernel, A/D and D/A converters, a network interface, and external 11

interrupt channels. The execution of the tasks and interrupt handlers is defined by the user-written code functions. The task is the main construct in the TrueTime simulation environment. Tasks are used to simulate both periodic activities, such as controller and I/O tasks, and aperiodic activities such as communication tasks and event-driven controllers. An arbitrary number of tasks can be created to run in the TrueTime kernel. Each task is defined by a set of attributes and a code function. The attributes include a name, a release time, a worst-case execution time, an execution time, a priority, and a period. Interrupts may be generated in two ways: externally or internally. An external interrupt is associated with one of the external interrupt channels of the computer block. The interrupt is triggered when the signal of the corresponding channel changes values. Internal interrupts are associated with timers. The corresponding interrupt is triggered when the timer expires. When an external or internal interrupt occurs, a user-defined interrupt handler is scheduled to serve the interrupt. An interrupt handler is defined by a name, a priority and a code function. The code associated with tasks and interrupt handlers is scheduled and executed by the kernel as simulation progresses. The simulated execution time of each segment is returned by the code function.

The TrueTime Network Block

The network block is event driven and executes when messages enter or leave the network. A message contains information about the sending and the receiving computer

12

node, arbitrary user data (typically control signals), the length of the message and optional real-time attributes such as priority or a deadline. In the network block it is possible to specify the transmission rate and the medium access control protocols. A long message can be split into frames that are transmitted in sequence, each with an additional overhead. When the simulated transmission of a message is completed, it is put in a buffer at the receiving computer node, which is notified by a hardware interrupt.

Simulation Scenario

The scenario used for the simulation is shown in Figure 2.

Continuous Plant

Sensor Node

Actuator Node

Network

Disturbance Node

Controller Node

Figure 2: Continuous plant to be controlled over a network

13

The sensor, actuator, controller and disturbance nodes are modeled using the TrueTime kernel block and the network block is modeled using the TrueTime network block. The TrueTime blocks are connected with ordinary Simulink blocks to form a realtime control system. The time-driven sensor node contains a periodic task, which at each invocation samples the process and transmits the sample package to the controller node. The controller node contains an event-driven task that is triggered each time a sample arrives over the network from the sensor node. Upon receiving the sample, the controller computes a control signal, which is then sent to the event-driven actuator node, where it is actuated. The model also contains a disturbance node with a periodic task generating random interfering traffic over the network. Figures 3 and 4 show the implementation of the TrueTime network and the TrueTime kernel block.

Figure 3: TrueTime network block

14

Figure 4: TrueTime kernel block

A Proportional-Integral-Derivative controller or PID controller is implemented for the controller. A PID controller compares a measured value from a process with a reference set point value. The difference or “error” signal is then processed to calculate a new value for a manipulated process input. The manipulated process input brings the process-measured value back to its desired set point. The PID-controller is implemented according to the following equations. If u(t) is the control signal sent to the system, y(t) it’s measured output, a PID controller has the generical form t

u (t ) = K [e(t ) +

where,

de(t ) 1 e(t )dt + Td ] ∫ Ti 0 dt

K= Gain of the controller e(t) = difference between set point r(t) (set point) and measured output y(t), i.e. e(t) =r (t)-y(t) Ti= integration time, and Td=derivative time The PID controller is tuned by adjusting the derivative control parameters to

improve the overshoot and settling time. 15

The derivative part is given by D(t ) = KTd

de(t ) d (t )

Using the backward difference rule, a discrete version of the derivative part is given as D(kh) =

KTd N Td ( y (kh) − y (kh − h)) , k=0, 1, 2, 3… D(kh − h) − Td + Nh Td + Nh

where, N = gain at higher frequencies h = sampling period The controller parameters are given by Ad =

Td Td + Nh

Bd =

KTd N Td + Nh

16

Chapter 4

Simulation Results

4.1

Simulation Model

The simulation setup is shown in Figure 5. The TrueTime blocks are connected with ordinary continuous Simulink blocks to form a real-time control system.

Figure 5: Simulation model Results

In the following simulations, an Ethernet-type network is assumed. A 10-ms sampling interval is used in the sensor node. The execution time of the controller is 0.5

17

ms and the ideal transmission time from one node to another (sensor-to-controller and controller-to-actuator) is 1.5ms, giving an ideal round-trip delay of 3.5ms. We further assume that an interfering, high-priority task is executing in the controller node with a 7ms period and a 3-ms execution time. In the first simulation, the network bandwidth occupied by the messages generated by the interfering node is set equal to zero. The control performance resulting from this situation is shown in Figure 6.

Figure 6: Control Performance without interfering network messages. Next we consider a more realistic simulation where messages generated by the interfering node occupy 50% of the network bandwidth. Colliding transmissions in the network will cause the round-trip delay to be even longer with the resulting degraded control performance shown in the simulated response in Figure 7.

18

Figure 7: Control Performance with interfering network messages and interfering task in the controller node. The transmission of messages over the network can be seen in detail in Figure 8. Controller Node

Network Schedule

Sensor Node

Interf. Node

Time [ms] Figure 8: Network Schedules showing the allocation of common resources. A high means sending or executing, a medium signal means waiting, and a low means idle. Finally, for an attempt to cope with the delays a simple compensation is introduced. By time-stamping the messages sent from the sensor node, it is possible for the controller to determine the actual delay from sensor to controller. The total delay is estimated by adding the expected value of the delay from controller to actuator (assumed to be same as from the sensor to controller). The new control signal is then calculated

19

taking a mean of the set of the controller parameters calculated for different delays. Figure 9 and 10 shows the control performance and network schedule using this compensation.

Figure 9: Control Performance with delay-compensation and interfering node occupying 50% of the network bandwidth.

Controller Node

Network Schedule

Sensor Node

Interf. Node

Time [ms] Figure 10: Network Schedules showing the allocation of common resources. A high means sending or executing, a medium signal means waiting, and a low means idle. To compare the results between the two schemes, it would be necessary to run many simulations under different network conditions. This has not been done for this study. 20

Chapter 5

Conclusion This project analyzed some of the theoretical aspects and fundamental issues in networked control system. Design of controllers in networked control system critically depends on the knowledge of delays. The discrete-time state space model of a system with delay shorter and longer than one sampling was presented. The fundamental issue in networked control system includes network-induced delay, i.e. the delay that occurs between sensor, controller and actuator when exchanging data packet across the communication network. Sensor-to-controller delay and controller-to-actuator delay have different measures. Sensor-to-controller delay can be known when the controller uses the sensor’s data to generate the control signal, provided the message is time stamped. Controller-to-actuator delay is different; however, in that the controller does not know how long it will take the control signal to reach the actuator, therefore, no exact correction can be made at the time of control calculation. A simulation scenario was developed using TrueTime software, which is a Matlab/Simulink toolbox to simulate distributed real-time control systems. In the simulation, the data sent from sensor to controller were time stamped there by giving an estimate of the sensor-to-controller delay. Since time stamping does not compensate controller-to-actuator delay, using different delay estimation technique and algorithm to compensate this delay will obviously produce even better results.

21

LIST OF REFERENCES

22

[1]

W. Zhang, M.S. Branicky, S.M. Philips, “Stability of Networked Control Systems,” IEEE Control System Magazine, February 2001.

[2]

A.S. Tanenbaum, Computer Networks, 3rd ed. Upper Englewood Cliffs, NJ: Prentice-Hall, 1996.

[3]

G.C. Walsh, H. Ye, L.G. Bushnell, “Stability Analysis of Networked Control Systems,” IEEE Transactions on Control Systems technology, Vol. 10, No. 3, May 2002.

[4]

G.C. Walsh, H. Ye, “Scheduling of Networked Control Systems,” IEEE Transactions on Control Systems technology, Vol. 21, No. 1, February 2001.

[5]

M. Anderson, D. Henriksson, A. Cervin, “TrueTime 1.3-Reference Manual,” Department of Automatic Control, Lund Institute of Technology, June 2005.

23