Implementation of a wirelessHARTsimulator and its use in studying packetloss compensation in networked control
MAURO DE BIASI
Masters’ Degree ProjectStockholm, Sweden February 2008
XR-EE-RT 2008:010
Acknowledgement
First of all, I would like to thank my parents and my girlfriend that have been always
beside me in all this years of studies and have been a great source of strength in these
months away from home. I am deeply grateful to Alf Isaksson, my supervisor at ABB,
that always followed me with patience and new motivations. He offered me his everyday
support and permitted me to grow up and develop this project. I can not go on without
express my gratefulness to my university supervisors Alberto Bemporad (University of
Siena) and Mikael Johansson (KTH). I would like to say thank you to them who gave me
the opportunity to join this project and shared with me their knowledge with technical
suggestions and interesting ideas. They gave me their full support when I applyied for
my thesis and provided helpful information. This work would not be as it is without the
kind assistance and support of Tiberiu Seceleanu and Krister Landernas, who shared their
valuable knowledge and inspired me in defining my research topic. A special thanks is
needed to all the persons involved in the SOCRADES project, who collaborated with me
in this period. A huge thank you to the whole ABB Corporate Research that permitted
me to live this amazing experience. I’m honored to have been part of this incredible group
of people. I feel to mention also all the guys who did their thesis with me at ABB, who
made me feel less far from home and were such good friends. Thanks to Eva Stenqvist,
who gave me the possibility to concentrate only on my work, solving every kind of external
problem.
I am deeply indebted to Giuseppe and Marisa, who treated me like a son, helping me in
all these years of studies. Last but not least I would like to thank Carlo that has been
more than a colleague, but a real friend.
Thank you All
i
No matter how long the winter,
spring is sure to follow.
ii
Abstract
This thesis is part of the SOCRADES project, a European research and advanced develop-
ment project with the primary objective to develop a design, execution and management
platform for next-generation industrial automation systems. In the specific case of work
it concerns the networked control systems. These are becoming more important in the
industrial automation field thanks to the many advantages introduced by the networks. In
fact, the use of a network to connect the devices permits to eliminate unnecessary wirings,
reducing the complexity and the overall cost in designing and implementing the control
systems. In the last years the fast spread of the wireless technologies has opened new
scenarios for the communication in the automation field. The benefits introduced by the
use of wireless communication in the networked control system are many. First of all the
simplicity and the convenience of the sensors placement. The price to be paid is a lower
reliability due to the interference that can easily affect the medium (radio frequencies)
with the consequent possible loss of communication. This work is focused on the study of
the problem of losing packets (the information in a wireless network is formed by packets of
bits) in a WirelessHART networked control system and on the possible solutions to avoid
the problem. WirelessHART is a wireless protocol that provides a low cost, relatively low
speed (e.g., compared to IEEE 802.11g) wireless connection. The aims of the thesis are
multiple, first of all the implementation of a tool that permits to simulate a wirelessHART
network. In fact, since it is a quite new protocol, the most used network simulators do
not give the possibility to simulate WirelessHART networks. This simulator has been im-
plemented modifying the original version of the TrueTime network simulator, adding this
new protocol and some other functions to make the simulator as close as possible to the
reality. Another objective of the thesis is to study the effects, and the possible solutions,
of the loss of communication in a wirelessHART network.
The last part of the thesis deals with a level control problem in a mineral flotation plant
and with the possibility to use a wirelessHART network for that plant.
iii
Contents
1 Introduction 1
1.1 Outline of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Chapter 2 : The WirelessHART protocol . . . . . . . . . . . . . . . 2
1.1.2 Chapter 3 : Introduction to TrueTime . . . . . . . . . . . . . . . . . 2
1.1.3 Chapter 4 : New functions in the wireless network block . . . . . . . 2
1.1.4 Chapter 5 : Study of Packet Loss . . . . . . . . . . . . . . . . . . . . 3
1.1.5 Conclusions and future work . . . . . . . . . . . . . . . . . . . . . . 3
2 Network theory 4
2.1 The Open System Interconnection model (OSI) . . . . . . . . . . . . . . . . 4
2.1.1 The OSI basic structure . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 The Medium Access Control (MAC) protocol . . . . . . . . . . . . . . . . . 7
2.2.1 ALOHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Carrier Sense Multiple Access Protocols (CSMA) . . . . . . . . . . . 8
2.2.3 Time Division Multiple Access (TDMA) . . . . . . . . . . . . . . . . 9
2.2.4 Token Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.5 Token Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 The IEEE 802 standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Bluetooth/IEEE 802.15.1 . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.3 IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.4 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.5 WirelessHART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 WirelessHART 18
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
i
CONTENTS
3.2 A brief view of WirelessHART . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 MAC Protocol Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.1 Data-Link packets(DLPDUs) . . . . . . . . . . . . . . . . . . . . . . 21
3.3.2 Time Division Multiple Access (TDMA) . . . . . . . . . . . . . . . . 21
3.3.3 Shared Slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.4 Communication Tables . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.1 MAC Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.2 Devices Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.3 Synchronization of the devices tasks . . . . . . . . . . . . . . . . . . 27
4 Introduction to TrueTime 29
4.1 Description of the tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.1 The TrueTime Kernel . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.2 The TrueTime Network . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.3 The TrueTime Wireless Network . . . . . . . . . . . . . . . . . . . 33
4.1.4 The TrueTime Standalone Network Blocks . . . . . . . . . . . . . . 35
4.1.5 The TrueTime Battery . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Wireless Network Block behaviour . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.1 802.11b/g ( WLAN) . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.2 802.15.4 (ZigBee) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.3 Calculation of Error Probabilities . . . . . . . . . . . . . . . . . . . . 39
5 New functions in the wireless network block 42
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Nodes in the 3D space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3 External noise port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.4 Noise and time correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.5 Packets lost signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.6 Fixed packet loss functionality . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.7 Wireless Network Mask modification . . . . . . . . . . . . . . . . . . . . . . 48
5.8 Moving the MAC into each device . . . . . . . . . . . . . . . . . . . . . . . 49
5.8.1 The WirelessHART MAC sub-layer in each device . . . . . . . . . . 50
ii
CONTENTS
6 Study of Packet Loss 51
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.1.1 Main causes of packet loss . . . . . . . . . . . . . . . . . . . . . . . . 52
6.1.2 The problem of packet loss in the networked controlled systems . . . 54
6.2 Comparison of different protocols with respect to packet loss . . . . . . . . 55
6.2.1 The compared protocols . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.2 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.3 Network parameter settings . . . . . . . . . . . . . . . . . . . . . . . 59
6.2.4 Simulation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.3 A brief description of the AC800M . . . . . . . . . . . . . . . . . . . . . . . 63
6.4 Different approaches to the problem of packet loss . . . . . . . . . . . . . . 64
6.4.1 Possible methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.4.2 An improved PID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.4.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.4.4 Multi-Hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.5 Boliden Plant: a case study . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.5.1 Description of the flotation process . . . . . . . . . . . . . . . . . . . 77
6.5.2 The pulp level control problem . . . . . . . . . . . . . . . . . . . . . 78
6.5.3 Boliden Plant: simulation . . . . . . . . . . . . . . . . . . . . . . . . 81
7 Conclusions and Future Work 85
7.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A How to install the tool 88
A.1 Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.3 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
B How to use the Simulator 90
B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
B.2 Writing Code Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
B.2.1 Writing a Matlab Code Function . . . . . . . . . . . . . . . . . . . . 91
B.2.2 Writing a C++ Code Function . . . . . . . . . . . . . . . . . . . . . 92
iii
CONTENTS
B.2.3 Calling Simulink Block Diagrams . . . . . . . . . . . . . . . . . . . . 92
B.3 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
B.3.1 Writing a Matlab Initialization Script . . . . . . . . . . . . . . . . . 94
B.3.2 Writing a C++ Initialization Script . . . . . . . . . . . . . . . . . . 95
B.4 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
C Examples 98
C.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
C.2 Control of a loop with three nodes . . . . . . . . . . . . . . . . . . . . . . . 99
C.3 5 nodes with multi-hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
C.4 5 nodes with a shared slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
D TrueTime Command Reference 107
E Lambda Tuning rule 110
E.1 Stable first order system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
E.2 Integrative process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
F Linearization 114
Bibliography 115
iv
List of Figures
2.1 The Open System Interconnection (OSI) model . . . . . . . . . . . . . . . 5
2.2 The amount of data in the Open System Interconnection (OSI) model . . . 6
2.3 The TDMA structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 The Token Bus operating principle . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 The Token Ring operating principle . . . . . . . . . . . . . . . . . . . . . . 10
2.6 Characteristics of the 802 family . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 HART OSI 7-Layer Model [1]. . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 The structure of a WirelessHART network. . . . . . . . . . . . . . . . . . . 19
3.3 The DLPDU structure [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 The SuperFrame structure [1] . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 The channel hopping [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6 The communication tables [1] . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.7 MAC Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1 The TrueTime 1.5 block library. . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 The dialog of the TrueTime kernel block. . . . . . . . . . . . . . . . . . . . 31
4.3 The dialog of the TrueTime network block. . . . . . . . . . . . . . . . . . . 32
4.4 The dialog of the TrueTime wireless network block. . . . . . . . . . . . . . 34
4.5 The dialog of the ttGetMsg block to the left, and the dialog of the ttSendMsg
block to the right. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.6 Probability density function for a received symbol when using binary phase
shift keying and additive white Gaussian noise. . . . . . . . . . . . . . . . . 40
5.1 The TrueTime wireless network block with the x,y,z coordinates inputs port that specifies
the true location of the nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
v
LIST OF FIGURES
5.2 The wireless network block with the external noise input port. . . . . . . . 44
5.3 The average and the variance fields in the wireless network block mask . . . 45
5.4 The plot of the lost packets and the consequences in the control performance 46
5.5 The wireless network block with the output port for the packet lost signal . . . . . . . 46
5.6 Settings for the fixed packets lost option . . . . . . . . . . . . . . . . . . . . 47
5.7 The plot of the packets lost and the consequence in the control performance 48
5.8 The parameters setting in the WirelessHart mask . . . . . . . . . . . . . . . 49
5.9 MAC protocol location in TrueTime . . . . . . . . . . . . . . . . . . . . . . 49
5.10 MAC protocol location in a real environment . . . . . . . . . . . . . . . . . 50
6.1 Main characteristics of major radio standards and technologies. . . . . . . . 52
6.2 The fading problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.3 The scheme of a control loop with wireless communication . . . . . . . . . . 55
6.4 The Simulink scheme of the networked control system . . . . . . . . . . . . 57
6.5 Schematic of the communication between the devices . . . . . . . . . . . . . 57
6.6 Illustration of the communication delay in WirelessHART. In the first slot the sensor (S)
sends the measurement to the gateway (GW) and in the second slot the gateway sends
the control signal to the actuator. The controller (C) executes between the sensor and
the actuator tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.7 Settings of the network parameters for WLAN, Zigbee and WirelessHART . 59
6.8 WirelessHART superframe . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.9 Tracking of the reference of the networked control system using WLAN
network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.10 Tracking of the reference of the networked control system using ZigBee
network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.11 Tracking of the reference of the networked control system using Wire-
lessHART network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.12 AC800 typical scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.13 Cascade loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.14 The studied scenario: the sensor, the gateway and the actuator communi-
cate through a wireless network. The controller reads and sends the data
from/to the gateway through a wire. . . . . . . . . . . . . . . . . . . . . . . 64
vi
LIST OF FIGURES
6.15 The control loop with an observer, if the feedback on the output is lost, it is possible to
use a predicted value. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.16 The studied scenario with disturbance on the control signal . . . . . . . . . 67
6.17 The performances of the two predictors. . . . . . . . . . . . . . . . . . . . . 69
6.18 Communication schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.19 Results using various methods: reference response. . . . . . . . . . . . . . . . . . . . 73
6.20 Results using various methods: disturbance rejection. . . . . . . . . . . . . . . . . . 73
6.21 Results using various methods: disturbance rejection and noise on the out-
put value. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.22 Multi-hop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.23 Multi-hop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.24 The performace using or not the multi-hop . . . . . . . . . . . . . . . . . . 77
6.25 Model of the tanks process . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.26 Simplified model of the tanks process . . . . . . . . . . . . . . . . . . . . . . 79
6.27 The Simulink−TrueTime model of the Boliden plant . . . . . . . . . . . . . 81
6.28 Communication schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.29 The simulation of the Boliden plant . . . . . . . . . . . . . . . . . . . . . . 83
6.30 The simulation of the Boliden plant with packets lost . . . . . . . . . . . . . 83
6.31 The Boliden plant with packets lost, critical situation . . . . . . . . . . . . 84
A.1 The TrueTime 1.5 block library. . . . . . . . . . . . . . . . . . . . . . . . . 89
B.1 The execution of user code is modeled by a sequence of segments executed
in order by the kernel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
B.2 Controllers represented using ordinary discrete Simulink blocks may be called from
within the code functions. The only requirement is that the blocks are discrete
with the sample time set to one. . . . . . . . . . . . . . . . . . . . . . . . . . . 93
C.1 Example: A control loop with 3 nodes. . . . . . . . . . . . . . . . . . . . . . 99
C.2 Example: Two control loops. . . . . . . . . . . . . . . . . . . . . . . . . . . 103
C.3 Example: Two control loops and shared slots. . . . . . . . . . . . . . . . . . 106
E.1 Internal model control structure. . . . . . . . . . . . . . . . . . . . . . . . . 111
E.2 Standard control loop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
vii
List of Tables
3.1 Example BOCntr Selection Sets . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Device Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1 Principal characteristics of WLAN, ZigBee and WirelessHArt . . . . . . . . 56
6.2 Example of transmissions schedule using different channels and multi-hop. . . . . . . . 76
B.1 Example of a P-controller code function written in Matlab code. . . . . . . 91
B.2 The C++ version of the code function in Listing B.1. . . . . . . . . . . . . 92
B.3 Simulink block diagrams are called from within code function using the TrueTime
function ttCallBlockSystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
B.4 Example of a TrueTime initialization script in the Matlab version. The kernel
is initialized using the function ttInitKernel, and a periodic task is created that
uses the P-controller code function from Listing B.1. The period of the controller
is passed to the initialization script as a parameter. . . . . . . . . . . . . . . . . 94
B.5 Template for writing initialization scripts in C++. The final script is actually a
complete Matlab S-function, since the included file, ttkernel.cpp, contains the
Simulink callback functions that implement the kernel. . . . . . . . . . . . . . . 95
B.6 Example of a TrueTime initialization script in the C++ version. Corresponds to
the Matlab version from Listing B.4. . . . . . . . . . . . . . . . . . . . . . . . . 97
C.1 Example of a TrueTime initialization script in the Matlab version. . . . . . . . . 100
C.2 Example of a sensor code. . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
C.3 Example of transmissions schedule using different channels and multi-hop. 103
C.4 Example of transmissions schedule using shared slot. . . . . . . . . . . . . 104
D.1 Real-time primitives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
viii
LIST OF TABLES
D.2 Commands used to create, initialize TrueTime objects, to control the simulation
and used to set and get task attributes. . . . . . . . . . . . . . . . . . . . . . . 108
D.3 Real-time primitives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
ix
Chapter 1
Introduction
This thesis is part of the SOCRADES project, a European research and advanced develop-
ment project with the primary objective to develop a design, execution and management
platform for next-generation industrial automation systems. The partners of the project
are many in all Europe and it is a cooperation between companies (Schneider Electric,
ABB, ARM, Boliden, FlexLink, APS, SAP, Siemens, Ifak, Jaguar Cars Ltd.) and univer-
sities (Politecnico di Milano, Loughborough University, TUT, KTH, LTU). In the specific
case of work it concerns the networked control systems. These are becoming more im-
portant in the industrial automation field thanks to the many advantages introduced by
the networks. In fact, the use of a network to connect the devices permits to eliminate
unnecessary wirings, reducing the complexity and the overall cost in designing and imple-
menting the control systems. In the last years the fast spread of the wireless technologies
has opened new scenarios for the communication in the automation field. The benefits in-
troduced by the use of wireless communication in the networked control system are many.
First of all the simplicity and the convenience of the sensors placement. The price to be
paid is a lower reliability due to the interference that can easily affect the medium (radio
frequencies) with the consequent possible loss of communication. This work is focused
on the study of the problem of losing packets (the information in a wireless network is
formed by packets of bits) in a WirelessHART networked control system and on the pos-
sible solutions to avoid the problem. WirelessHART is a wireless protocol that provides
a low cost, relatively low speed (e.g., compared to IEEE 802.11g) wireless connection. It
operates in the 2.4GHz ISM radio band using Time Division Multiple Access (TDMA)
to schedule the communications of the various devices that has to communicate. The
1
1.1. Outline of the thesis
aims of the thesis are multiple, first of all the implementation of a tool that permits to
simulate a wirelessHART network. In fact, since it is a quite new protocol, the most used
network simulators do not give the possibility to simulate WirelessHART networks. This
simulator has been implemented modifying the original version of the TrueTime network
simulator, adding this new protocol and some other functions to make the simulator as
close as possible to the reality. Another objective of the thesis is to study the effects,
and the possible solutions, of the loss of communication in a wirelessHART network. Two
common processes have been simulated, a stable process and an integrating process.
The last part of the thesis deals with a level control problem in a mineral flotation plant
and with the possibility to use a wirelessHART network for that plant.
1.1 Outline of the thesis
The thesis is divided in seven chapters. Skipping the introduction the other six chapters
are described in the following paragraphs.
1.1.1 Chapter 2 : The WirelessHART protocol
The chapter describes all the technical characteristics of the WirelessHART protocol.
Moreover the structure of the MAC protocol (Medium Access Control) and the implemen-
tation of the protocol in the simulator is deeply explained.
1.1.2 Chapter 3 : Introduction to TrueTime
This chapter describes the use of the original Matlab/Simulink-based TrueTime simulator.
All the main functions and the useful information about the TrueTime library and the
main parameters of the simulated networks are explained in the chapter. Moreover a brief
description of the implementation of the wireless protocols that can be simulated using
TrueTime is given.
1.1.3 Chapter 4 : New functions in the wireless network block
All the new functionalities that have been added to improve the behavior and the use
of the original TrueTime are illustrated in this chapter. Moreover the chapter explains
a new way for the computation of the noise considering a time correlation between the
2
1.1. Outline of the thesis
time samples. A section is also dedicated to describing the modification in the TrueTime
graphic interface done to use the WirelessHART protocol.
1.1.4 Chapter 5 : Study of Packet Loss
In this chapter the problem of packet loss in wireless networks is treated. The main causes
of the problem and some possible techniques to reduce the effects of packets lost in a
wirelessHART networked control system is analyzed. In the last section of the chapter the
possibility to use a wireless network in a real mining plant is studied.
1.1.5 Conclusions and future work
In this chapter the main aims of the thesis are analyzed and some conclusions about the
usability of the simulator, the problem of packet loss and the possible use of a wireless
network in a real mining plant have been done.
3
Chapter 2
Network theory
Industrial communications constitute, today, a fundamental topic for all kind of automa-
tion. The aim of this chapter is to introduce the basis of the network theory in order
to create a background for the understanding of the whole thesis. The first section is
an introduction to the main structure of the Open System Interconnection model (OSI).
In section 2.2 a description of the Medium Access Protocol (MAC) has been given. The
IEEE 802 standard is described in section 2.3. In the last section a brief overview of the
major part of the actual wireless protocols is presented.
2.1 The Open System Interconnection model (OSI)
The OSI model [21] is a conceptual framework of standards for communication in the
network. It has been developed by the International Standards Organization (ISO) in
1984 and it is now considered the primary architectural model for network communication.
Most of the network protocols used today have a structure based on the OSI model.
2.1.1 The OSI basic structure
The OSI model is structured in seven functionals layers (see figure 2.1). Each layer com-
municates directly only with the layer above (requesting services) and the layer below it
(providing services). Like is shown in figure 2.1 the layers defined in OSI are:
• Layer 7 - Application - The highest layer deals with application management
tasks such as file transfer, distributed database operation and remote control. It
provides network services to the end-user and defines an interface to user processes
for communication and data transfer in the network.
4
2.1. The Open System Interconnection model (OSI)
Figure 2.1: The Open System Interconnection (OSI) model
• Layer 6 : Presentation - This layer provides data encoding and conversion. It
converts user local representation of data to its canonical form and vice versa.
• Layer 5 : Session - The layer defines the format of the data sent over the con-
nection. It enhances the transport layer by adding services to support full session
between different nodes. An example is the network login in a remote computer.
• Layer 4 : Transport - End to end communication control. This layer is the
interface between the application software that request data communication and the
physical network represented by the first three layers. The transport layer has the
responsibility of verifing that the data is transmitted and received correctly from
a node of the network to another and that the data is available for application
programs.
• Layer 3 : Network - This layer sets up a complete communication path and
oversees that messages travel all the way from the sources to the destination node.
When a packet has to travel from one network to another to get to its destination,
many problems can arise. The addressing used by the second network may be
different from the first one. The second one may not accept the packet at all because
it is too large. The protocols may differ, and so on. It is up to the network layer to
overcome all these problems to allow heterogeneous networks to be interconnected.
• Layer 2 : Data Link - This level provides for the verification that bit sequences
5
2.1. The Open System Interconnection model (OSI)
are passed correctly between two nodes. If errors occur, for example because of
disturbances, the retransmission of a corrupted bit sequence may be request at the
data link layer. As a result the data link layer present to highest layers an error-free
data link between the nodes.
• Layer 1 : Physical - This is the electrical, optical or radio communication medium
with the related interfaces to the communicating network nodes. All details about
transmission medium, signal levels, frequencies are handled at this level. The phys-
ical layer is the only real connection between two nodes.
The requesting layer passes parameters and data to the layer below it and waits for an
answer. Modules that are located at the same layer and at different points in the communi-
cation network (i.e. running on different nodes) are called peers. The peers communicate
via protocols that define message formats and the rules for data exchange. Following the
OSI rules only peers are allowed to communicate with each other. Two peer entities are
connected by a virtual link that appears, to the peers, like a real communication channel.
Only at the first layer the virtual and the physical connection are the same. The peers
exchange data according to a protocol specified for their level. There is not direct link,
real or virtual, between modules of the same node, at a distance of more than one layer
from each other. Each layer has its own communication protocol and adds therefore the
related data to the original message (see figure 2.2).
Figure 2.2: The amount of data in the Open System Interconnection (OSI) model
The result is an incremental amount of data in the message that has to be sent.
6
2.2. The Medium Access Control (MAC) protocol
2.2 The Medium Access Control (MAC) protocol
The Medium Access Control (MAC) data communication protocol belongs to a sub-layer
of the Data Link layer specified in the OSI model. The protocol provides addressing and
channel access control mechanism. In fact, in any broadcast channel, the key issue is how
to determine who gets to use the medium when there is competition for it. Many MAC
protocols for solving the problem are known. The principals are:
• ALOHA
• Carrier Sense Multiple Access Protocols (CSMA)
– CSMA/CD - for wired networks ( i.e. Ethernet)
– CSMA/CA - for wireless networks ( i.e. Wireless LAN)
• Time Division Multiple Access (TDMA)
• Token Bus
• Token Ring
2.2.1 ALOHA
This is an old protocol, one of the first that proposed the use of random access radio
communications. The ALOHA protocol [18] was born in the 70s to provide Wireless links
between the universities and some research-institutes spread around the Hawaiian islands.
The protocol used is really simple. It consists in just sending when the data is ready. If
a collision occurs, then it detects errored frames and retransmits the data with a random
time delay. The result of this simple protocol is the possibility to have a decentralized
network that works well for low loads. In 1972, Roberts published a method for doubling
the capacity of an ALOHA system [19]. His proposal was to divide time into discrete
intervals, each interval corresponding to one frame. This approach requires the users to
agree on slot boundaries. One way to achieve synchronization would be to have one special
station that emits a beep at the start of each interval, like a clock. The Roberts’ method
has come to be known as slotted ALOHA.
7
2.2. The Medium Access Control (MAC) protocol
2.2.2 Carrier Sense Multiple Access Protocols (CSMA)
Carrier Sense Multiple Access Protocols (CSMA) [19] are probabilistic MAC protocols in
which a node verifies the absence of other traffic before transmitting on a shared physical
medium. The nodes listen if the channel is idle (carrier sense ) before transmitting. If
the channel is in use, the devices wait a random amount of time before retrying. Multiple
access (MA) indicates that many devices can connect and share the same network. All
devices have equal access to use the network when it is idle. Even though devices attempt
to sense whether the network is in use, there is a good chance that two nodes will attempt
to access it at the same time. In this case a collision occurs. There are two main protocols
that differs in the way the collisions are treated :
• CSMA/CD - ( i.e. Ethernet)
• CSMA/CA - ( i.e. Wireless LAN)
Carrier Sense Multiple Access Protocols / Collision Detection (CSMA/CD)
Carrier Sense Multiple Access Protocols with collision detection defines what happens
when two devices sense the channel to be idle and begin transmitting simultaneously. A
collision occurs, and both devices stop transmission, wait for a random amount of time
(back-off time), then retransmit. Collisions can be detected by looking at the power or
pulse width of the received signal and comparing it to the transmitted signal.
Carrier Sense Multiple Access Protocols / Collision Avoidance (CSMA/CA)
In the collision avoidance (CA) [17] technique when a node has to transmit, it first checks
the medium to ensure no other node is transmitting. If the channel is idle, it then transmits
the packet. Otherwise, it chooses a random ”back-off factor” which determines the amount
of time the node must wait until it is allowed to transmit its packet. During periods in
which the channel is idle, the transmitting node decrements its back-off counter (when the
channel is busy it does not decrement its back-off counter). When the back-off counter
reaches zero, the node transmits the packet. There is no possibility to detect a collision but
if a message is not acknowledged, the transmitting node assumes a collision has occurred
and retransmits. The collision avoidance permits to reduce the probability that a collision
occurs but it is not possible to detect when it happens. In fact, collision detection cannot
be used for the radio frequency transmissions. The reason for this is that, when a node
8
2.2. The Medium Access Control (MAC) protocol
is transmitting, it cannot hear any other node in the system which may be transmitting,
since its own signal will drown out any others arriving at the node.
2.2.3 Time Division Multiple Access (TDMA)
Time division multiple access (TDMA) [1] is digital transmission technology that allows a
number of users to access a single shared medium (usually radio channel) by dividing the
signals into different time slots. The nodes transmit in rapid succession, one after the other,
each using its own time slot. This allows multiple nodes to share the same transmission
medium (e.g. radio frequency channel) while using only the part of its bandwidth they
require.
Figure 2.3: The TDMA structure
As is shown figure 2.3, the time slots are usually regrouped into frames. Typically, two
devices are assigned to a given slot. One is designated as the source and the other the
destination. For successful and efficient TDMA communications, synchronization of clocks
between devices in the network is critical. Consequently, tolerances on time keeping and
time synchronization mechanisms are specified to ensure network-wide device clock syn-
chronization. It is imperative that devices know when the start of a slot occurs.
2.2.4 Token Bus
In token bus all units are connected to the network using a bus. The access to the medium
follows a strict deterministic pattern, so that only a node at time can initiate a transmission
of a message. The right to send is given by a token, a special bit pattern that is passed
from one unit to the other in a circular fashion. The unit that receives the token gets the
9
2.2. The Medium Access Control (MAC) protocol
right to transmit for a specific interval, and must, then, pass the token to the following
unit. If a unit does not have to transmit, it just passes the token to the next one. The
circular pattern in which the token is passed makes the token bus a logical ring, although
its physical topology is a bus.
Figure 2.4: The Token Bus operating principle
2.2.5 Token Ring
The operating principle of Token Ring is similar to Token Bus but in this case the ring is
not only logical but also physical with the nodes connected in a circular path. The token
is continuously circulated on the ring and each node receives it, regenerates it and puts it
again on line. When a station receives the token, if it needs to transmit, it removes the
token from the ring and for the maximum specified amount of time sends its own data
packets. After the time allowed for transmission has elapsed, the nodes recirculate the
token.
Figure 2.5: The Token Ring operating principle
10
2.3. The IEEE 802 standards
2.3 The IEEE 802 standards
In this section the family IEEE 802 and some related protocols, used in wireless communi-
cation, are briefly described. The standards here considered are chosen for their diffusion
in both industrial and public environments for implementing wireless networks. The very
extensive 802 group of IEEE standards is concerned with Local Area Networks (LANs)
and the development of many of these standards have had a major impact [20].
2.3.1 Bluetooth/IEEE 802.15.1
Bluetooth Wireless TechnologyTM is a lowcost/short-range (up to 10m) wireless network-
ing method for personal, office and industrial environments [17]. The name originates
from a Danish King, Harald Blatand, who is considered to have succeeded in uniting the
Scandinavian people in the 10th century AD. The aim of this Standard was, instead, to
unite personal computing devices. A frequency-hopping spread-spectrum technique is used
with 1600 hops/s at 79 frequencies. The frequency-sequence is selected in a pseudo-random
manner. All Bluetooth devices share the same frequency space, and the band may be used
concurrently by other ISM devices. There are two main classes of frequency-hopper; those
that have many bits per hop and those that have many hops per bit. Bluetooth uses the
first class. The Bluetooth standard allows three transmit-power classes: 1mW, 2.5mW
and 100mW. Most applications are in the first two classes, which provide ranges of 100mm
to 10m respectively. It is easy to notice that, Bluetooth has a low consumption but is
able to work only in short range. The maximum data rate for Bluetooth is 1 Mbit/s (
3 Mbit/s v2.1), using Gaussian binary frequency shift keying (FSK). It makes Bluetooth
inadequate for some consumer applications such as MPEG2 video data stream for a high-
definition TV display and for Real-time computer graphics. It supports maximum 7 slave
devices controlled by a master. In order to establish a net of devices ( piconet), the master
transmits ’enquiry messages’ at 1.28 second intervals in order to locate Bluetooth devices
within range. This is followed by ’invitations to join the piconet’ addressed to the specific
devices within range that the master wishes to have in the net. The master allocates a
member-address to each of the active slaves, and controls their transmissions. The clock
of the master provides the time synchronization of the whole piconet. The master always
transmits in ’even-numbered’ time-slots and the slaves transmit in ’odd-numbered’ time-
slots in accordance with permission given by the master. Each channel is divided into
11
2.3. The IEEE 802 standards
time slots of 625 µsecs. The master switches from slave to slave in a round-robin fashion.
The 802.15 working group is developing a family of ’Wireless Personal Area Networks’
(WPANs) for up to 55Mb/s data-rate, and Bluetooth has been accepted as one of these.
In March 2002, Bluetooth was ratified by IEEE for 802.15.1.
2.3.2 IEEE 802.11
Since IEEE 802.11 is a WLAN standard, its key intentions are to provide high throughput
and a continuous network connection. The most common variations and extensions of
IEEE 802.11 systems will be discussed here. The main parameters of IEEE 802.11 a/b/g
are the following [20]:
IEEE 802.11a IEEE 802.11a is placed in 5 GHz bands that are license exempt in Europe
(5.15-5.35 GHz and 5.47-5.725 GHz) and unlicensed in the US (UNII bands, 5.15-
5.35 GHz and 5.725-5.825 GHz). Over the whole spectrum, this allows for 21 systems
to be running in parallel in Europe and eight in the US . The IEEE 802.11a physical
layer (PHY) is based on the multicarrier system Orthogonal Frequency Division
Multiplexing (OFDM). Seven modi are defined ranging from BPSK modulation with
rate-1/2 FEC and a 6 Mbit/s data rate, to 64-QAM modulation with rate- 3/4 FEC
and a 54 Mbit/s data rate. The maximum user-visible rates depend on the packet
sizes transmitted. In the 54 Mbit/s mode, the transmission of Ethernet packets that
are 1500 bytes long results in a maximum user rate of about 30 Mbit/s, while sending
packets with user payloads of just 60 bytes results in a throughput of 2.6 Mbit/s.
The latter throughput value is the one of interest for industrial applications, as small
packet sizes are dominant in fieldbus networks.
IEEE 802.11b is a high rate extension to the original IEEE 802.11 DSSS mode and thus
uses the 2.4 GHz ISM band. Although in principle either 11 or 13 different center
frequencies can be used for the DSSS (depending on whether you are in the US
or in Europe), only three systems can actually operate in parallel. In addition to
supporting the 1 and 2 Mbit/s modulation rates of the basic IEEE 802.11 system,
the payload of the IEEE 802.11b PHY allows for modulation with 5.5 and 11 Mbit/s
Complementary Code Keying (CCK). The maximum user data rates are 7.11 Mbit/s
20 in the case of Ethernet packets and 0.75 Mbit/s in the case of packets with user
payloads of 60 bytes in length.
12
2.3. The IEEE 802 standards
IEEE 802.11g is an extension to the IEEE 802.11b specification and is consequently also
placed in the 2.4 GHz band. It supports four different physical layers of which two
are mandatory: the PHY that is identical to IEEE 802.11b and an OFDM PHY that
uses the same modulation and coding combinations as IEEE 802.11a. Because of
the different frequency band, the maximum user transmit rates are about 26 Mbit/s
for Ethernet packets and about 2 Mbit/s for packets with user payloads of 60 bytes
when using the 54 Mbit/s modulation scheme.
802.11b and 802.11g standards use the 2.4 GHz band. Because of this choice of frequency
band, 802.11b and 802.11g equipment can incur interference from microwave ovens, cord-
less telephones, Bluetooth devices, and other appliances using this same band. The 802.11a
standard uses the 5 GHz band, and is therefore not affected by products operating on the
2.4 GHz band.
In this work more attention has been given to the IEEE 802.11b , also known by the
brand Wi-Fi. It is, hence, important to spend some more words on it. IEEE 802.11b is a
contention-based protocol. To avoid collision, it uses a CSMA/CA protocol. The device
that wants to transmit, checks if the channel remains idle for a time DIFS (Distributed
Inter Frame Space), then it transmits the frame. If the channel, instead, is occupied,
the device choses a random backoff time. This value will be decremented every time the
channel is idle. When it is equal to zero the transmission can start. At the end of the
transmission, if no acknowledge is recived, a new backoff counter is computed. On the
other side, the receiver, if the frame is received correctly, sends an acknowledge signal
back to the sender after a time SIFS (Short Inter Frame Space). The basic CSMA/CA
method can be enhanced with an optional RTS/CTS handshake to avoid hidden terminal
situations. The user can control whether or not this handshake is used by configuring a
threshold for frame sizes. If a frame size exceeds this threshold, then RTS/CTS will be
used, otherwise it will not [19].
2.3.3 IEEE 802.15.4
The IEEE 802.15.4 standard was finalized in October 2003. The goal of this standard was
to create a very low cost, very low power, two-way wireless communication solution that
meets the unique requirements of sensors and control devices. In contrast to Bluetooth
and IEEE 802.11, IEEE 802.15.4 has been specifically developed for use with applications
13
2.3. The IEEE 802 standards
in which a static network exists that has many infrequently used devices that transmit
only small data packets. Such applications are exactly what many industrial environ-
ments would require. In order to encourage widespread deployment, IEEE 802.15.4 has
been placed in unlicensed frequency bands. Within these bands, direct sequence spread
spectrum (DSSS) is used in order to comply with the respective sharing rules of each band
as well as to allow for simple analog circuitry to be used. The maximum data rate of
the DSSS is 250 Kbit/s in a single channel within the 2.4 GHz band. In total, the 2.4
GHz band accommodates 16 such channels. Because of various system parameters, espe-
cially the MAC protocol that is in use, the maximum user data rate will most likely be
about half of its nominal value, or less. If upper layers detect a throughput degradation
while using a specific channel within the used frequency band, IEEE 802.15.4 can scan
the frequency band for a channel that promises better performance values and switch to
that channel. The devices operation with the IEEE 802.15.4 standard are distinguished in
two kinds: full-function devices (FFD) and reduced-function devices (RFD). A FFD can
become a network coordinator and can work with other FFDs in a peer-to-peer fashion.
The RFDs, on the other hand, are always associated with one of these FFDs and are
limited to exchanging data with this device alone. Among RFDs there is no peer-to-peer
communication possible. All devices have a 64 bit address, but it is possible for RFDs to
obtain a 16 bit shorthand address from their coordinator FFD. With respect to the MAC
protocol used by the IEEE 802.15.4 standard, there are two different modes of operation.
In unbeaconed mode all stations use an unslotted CSMA variant. Here, a station initiat-
ing transmission of a packet does not perform carrier sensing immediately, but introduces
a random waiting time, called backoff time. Having such a backoff time facilitates the
avoidance of collisions. In beaconed mode, the network coordinator imposes a superframe
structure. The coordinator transmits beacons periodically, choosing one of a number of
configurable periods between 15.36 ms and 251.65 s. The remaining superframe starts
with the contention-access period, in which the RFDs access the medium according to a
slotted CSMA-CA variant, which incurs more overhead than the unslotted variant. In
addition to these two modes of operation, an inactive period of operation exists. During
this period, all nodes including the coordinator in the network are put to sleep in order
to conserve energy. Data packets are acknowledged and the protocol supports retransmis-
sions. In the beaconed mode the throughput is smaller than in the unbeaconed mode, in
which no beacon frames exist and the unslotted CSMA variant has less overhead. Un-
14
2.3. The IEEE 802 standards
der the conditions investigated in, the maximum user data rate when running in the 2.4
GHz ISM band is 38 Kbit/s with one source, and up to 70kbs when multiple sources are
present. Similar to Bluetooth, IEEE 802.15.4 uses low transmit power levels. In addition
to this, IEEE 802.15.4 also uses very short symbol rates (up to 62.5 ksymbols/s), allowing
the increased delay spread found in industrial plants not to cause a problem. For security
purposes, IEEE 802.15.4 provides authentication, encryption, and integrity service. The
developer can choose between: No security, an access control list, and a 32 to 128 bit
Advanced Encryption Standard (AES) encryption with authentication.
2.3.4 ZigBee
The ZigBee [30] set of high level communication protocols, developed by the Zigbee Al-
liance, uses the 802.15.4 standard as a baseline and adds additional routing and networking
functionality. ZigBee is an established set of specifications for wireless personal area net-
working (WPAN) that can be used in a variety of commercial and industrial low data
rate applications. ZigBee is designed to add mesh networking to the underlying 802.15.4
radio. Mesh networking is used in applications where the range between two points may
be beyond the range of the two radios located at those points, but intermediate radios are
in place that could forward on any messages to and from the desired radios. The MAC
protocol used is CSMA/CA with an initial random backoff time following the unbeaconed
mode explained above. Because ZigBee was designed for low power applications, it fits
well into embedded systems and those markets where reliability and versatility are impor-
tant but a high bandwidth is not. The transmission range is between 10 and 75 meters
(33 ∼ 246 feet), although it is heavily dependent on the particular environment. The
maximum output power is generally 0 dBm (1 mW).
2.3.5 WirelessHART
The goal of the development of WirelessHART is to establish a wireless communication
standard for process automation applications [4]. WirelessHART is an extension of the
wired HART protocol, enhancing it by allowing new applications while still preserving
backwards compatibility. WirelessHART supports applications that have cycle times in
15
2.3. The IEEE 802 standards
the order of seconds, as well as applications with cycle times as long as days or even weeks.
WirelessHART aims to be a secure, time-synchronised, ultra low-power, mesh network for
process automation. The WirelessHART specification follows the OSI layers, and contain
a Physical, Medium access, Transport, and Network layer. The Application layer is the
same for both wired and WirelessHART. Details of the WirelessHART layers are shown
below:
• The physical layer is the same as the IEEE 802.15.4 2.4GHz PHY layer
• The MAC layer is a modified version of the IEEE 802.15.4 MAC layer with support
for channel hopping.
• The Transport and Network layers are based on TSMP (Time Synchronised Mesh
Protocol), which has been developed by DUST Networks.
WirelessHART communication is time slotted, where each slot is 10ms. Slots can be either
dedicated to one node or shared by several nodes. Dedicated slots use TDMA for medium
access, while shared slots use CSMA/CA for access. Latency requirements are addressed
by scheduling the communication in such a way that packets will reach their destination
in time, considering multiple hops, possible retransmissions, and alternate routes through
the network. For more details see Chapters 3 and 5 .
In figure 2.6 the characteristics of the various protocols have been summarized.
16
2.3. The IEEE 802 standards
Figure 2.6: Characteristics of the 802 family
17
Chapter 3
WirelessHART
3.1 Introduction
In this chapter the WirelessHART protocol [1] will be described. The first section 3.2 is
a general introduction to the protocol with the main information and the technical char-
acteristics of WirelessHART. In section 3.3 the structure of the MAC is deeply explained,
and a more exhaustive description of the communication protocol is given. The last section
describes the code implementation of the ttMAC function.
3.2 A brief view of WirelessHART
WirelessHART is an optional HART Physical Layer that provides a low cost, relatively
low speed (e.g., compared to IEEE 802.11g) wireless connection to HART-enabled devices.
It operates in the 2.4GHz ISM radio band using Time Division Multiple Access (TDMA)
(see Subsection 3.3.2) to schedule the communication of the various devices. All commu-
nication is performed within a designated time slot of 10 ms. A series of time slots form a
superframe. WirelessHART also enables channel hopping to avoid interferers and reduce
multi-path fading effects. One or more sources and one or more destination devices may
be scheduled to communicate in a given slot. The slot may be dedicated to communication
from a single source device or a slot may support shared communication (see Subsection
3.3.3). HART is loosely organized around the ISO/OSI 7-layer (see Sec. 2.1) model for
communication protocols (see Fig. 3.1). With the introduction of wireless technology to
HART, two Data-Link Layers are supported: the token-passing and Time Division Multi-
ple Access (TDMA) (see Subsection 3.3.2). Both support the common HART Application
18
3.2. A brief view of WirelessHART
Layer.
Figure 3.1: HART OSI 7-Layer Model [1].
The Structure of a WirelessHART network is shown in the diagram below.
Figure 3.2: The structure of a WirelessHART network.
19
3.3. MAC Protocol Description
All communications of the WirelessHART Network pass through the gateway. Conse-
quently, the gateway must route packets to the specified destination (network Device,
host application, or network manager). The gateway uses standard HART commands to
communicate with network devices and host applications. The plant automation network
could be a TCP-based network, a remote IO system, or a bus such as PROFIBUS DP. The
Network Manager creates an initial superframe and configures the Gateway. A detailed
description of the components of a wirelessHART network is given in [2] and [3].
The MAC rules ensuring that transmissions by devices occur in an orderly fashion. In
other words, the protocol specifies when a device is allowed to transmit a message.
3.3 MAC Protocol Description
The main tasks of the MAC (Medium Access Control) protocol are:
• slot synchronization;
• identification of devices that need to access the medium;
• propagation of messages received from the Network Layer;
• to listen for packets being propagated from neighbors
The Medium Access Control (MAC) sub-layer is, hence, responsible for propagating Data-
Link packets (DLPDUs, see Subsection 3.3.1) across a link. To permit this, the device
includes:
• Tables of neighbors, superframes, links, and graphs that configure the communica-
tion between the device and its neighbors (see Subsection 3.4.2). These tables are
normally populated by the Network Manager. In addition the neighbors table is
populated as neighbors are discovered.
• A link scheduler that evaluates the device tables and chooses the next slot to be
serviced by listening for a packet or by sending a packet.
• State machines that control the propagation of packets through the MAC sub-layer.
MAC Operation consists of schedule maintenance and service slots. MAC operation
is fundamentally event driven and responds to service primitive invocations and the
start of slots needing servicing.
20
3.3. MAC Protocol Description
In the next subsections a brief view of the WirelessHART MAC protocol is introduced. A
deeper explanation of the protocol is given in [1].
3.3.1 Data-Link packets(DLPDUs)
This subsection specifies the format of the Data-Link packet (DLPDU, see Figure 3.3).
Each DLPDU consists of the following fields:
• A single byte set to 0x41
• A 1-byte address specifier;
• The 1-byte Sequence Number;
• The 2 byte Network ID;
• Destination and Source Addresses either of which can be 2 or 8-bytes long;
• A 1-byte DLPDU Specifier;
• The DLL payload;
• A 4-byte keyed Message Integrity Code (MIC);
• A 2-byte ITU-T CRC16;
Figure 3.3: The DLPDU structure [1]
The total packet length is 127 bytes.
3.3.2 Time Division Multiple Access (TDMA)
WirelessHART uses Time Division Multiple Access (TDMA) and channel hopping to con-
trol access to the network. TDMA is a widely used Medium Access Control technique
21
3.3. MAC Protocol Description
that provides collision free, deterministic communications. It uses time slots where com-
munications between devices occur. A series of time slots form a TDMA superframe (see
Figure 3.4).
Figure 3.4: The SuperFrame structure [1]
All devices must support multiple superframes. Slot sizes and the superframe length (in
number of slots) are fixed and form a network cycle with a fixed repetition rate. Super-
frames are repeated continuously. For successful and efficient TDMA communications,
synchronization of clocks between devices in the network is critical [29]. Consequently,
tolerances on time keeping and time synchronization mechanisms are specified to ensure
network-wide device clock synchronization. It is imperative that devices know when the
start of a slot occurs. Within the slot, transmission of the source message starts at a
specified time after the beginning of a slot. This short time delay allows the source and
destination to set their frequency channel and allows the receiver to begin listening on the
specified channel. Since there is a tolerance on clocks, the receiver must start to listen
before the ideal transmission start time and continue listening after that ideal time. Once
the transmission is complete, the communication direction is reversed and the destination
device indicates, by transmitting an ACK, whether it received the source device DLPDU
successfully or with a specific class of detected errors. To enhance reliability, channel
hopping (see Figure 3.5) is combined with TDMA. Channel hopping provides frequency
diversity, which can avoid interferers and reduce multi-path fading effects.
22
3.3. MAC Protocol Description
Figure 3.5: The channel hopping [1]
Communicating devices are assigned to a superframe, slot, and channel offset. This forms
a communications link between communicating devices.
3.3.3 Shared Slot
WirelessHART allows to define shared slots in which more than one device may try to
transmit a message. Consequently, collisions may occur within a slot. If a collision occurs,
the destination device will not be able to successfully receive any source transmission and
will not produce an acknowledgement to any of them. To reduce the probability of repeated
collisions, source devices shall use random back-off delay when their transmission in a
shared slot is not acknowledged. A device shall maintain two variables for each neighbor:
Back-Off Exponent (BOExp) and Back-Off Counter (BOCntr). Both of these variables
are initialized to 0. When a transaction in a shared slot fails the random back-off period
is calculated based on the BOExp. For each unsuccessful attempt by the source device in
a shared slot the BOExp is incremented and a sequential set of numbers calculated. The
set of numbers consists of the whole numbers {0, 1, ...L} where
L = (2BOExp − 1) (3.1)
23
3.3. MAC Protocol Description
BOExp Set of Possible Values for BOCntr
1 { 0, 1 }2 { 0, 1, 2, 3 }3 { 0, 1, 2, 3, 4, 5, 6, 7 }4 { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 }
Table 3.1: Example BOCntr Selection Sets
A sample random back-off sets for BOExp values of one to four is shown in table 3.1. From
this set calculated based on the BOExp, a random value for the BOCntr is selected. For
each subsequent shared link to that neighbor, the BOCntr must be decremented. Only
when the corresponding BOCntr is zero can the source device attempt a transmission in a
shared slot. The value of BOExp shall not exceed that of MaxBackoffExponent. Broadcast
messages must not be transmitted on shared slots.
3.3.4 Communication Tables
All devices maintain a series of tables that control the communications performed by the
device. The tables controlling communication activities include:
• Superframe and Link tables. Multiple superframes may be configured by the network
manager. Multiple links within a superframe are configured to specify communica-
tion with a specific neighbor or broadcast communications to all listening to the
link.
• The Neighbor table. The neighbor table is a list of all devices that the device may
be able to communicate with.
• The Graph table. Graphs are used to route messages from their source to their
destination.
The communication tables and the relationships between them are shown in figure 3.6.
For more details on wirelessHART see [1].
24
3.4. Implementation
Figure 3.6: The communication tables [1]
3.4 Implementation
This section explains the way WirelessHART has been implemented to work with the mod-
ified TrueTime (see Section 5). The WirelessHART MAC protocol has been implemented
with some C++ functions with corresponding MATLAB MEX-interfaces. The main func-
tion (ttMAC.cpp) implements the algorithm that permits the access to the medium. In
the following subsections all the technical details will be described.
3.4.1 MAC Protocol
As described in Section 3.2 WirelessHART uses TDMA and channel hopping to control
the access to the medium. Each device has a table in which all the information for the
communication is specified (see Subsection 3.4.2). When a device wants to transmit a
message it must call the MAC function, that reads the device table and checks if the
device is allowed to transmit. In other words the MAC protocol checks if the actual slot
is reserved to the device that has called the MAC function. If yes, the transmission is
permitted otherwise it is blocked. The channel hopping technique permits that different
devices transmit in the same time slot using different channels. WirelessHART also allows
the use of shared slots, for that reason a collision detection system has been implemented.
When a device tries to transmit in a shared slot the MAC function verifies the status of the
channel. If the channel is occupied a back-off is computed in the way explained in Section
3.3.3. To understand better how the MAC protocol is implemented the pseudo-code of
25
3.4. Implementation
the algorithm is shown in Figure 3.7.
* Read the actual simulation time to know the actual time slot
* Read the device table to collect the information about the communication
* if the device has to communicate in this slot
* In the case of the device has to receive
* set the state to reception
* if(slot=shared && BOcntr>0)
* BOcntr=BOcntr-1;
* in the case of the device has to transmit
* if (slot=shared & BOcntr=0 & channel=occupied)
* set the state to COLLISION;
* Collision detection and handling:
* BOexp=BOexp+1;
* BOcntr=random(0,(pow(2,BOexp)-1));
* else if(slot=shared & BOcntr>0)
* set the state to COLLISION
* BOcntr=BOcntr-1
* else if(slot=shared & channel!=occupied & BOcntr=0)
* set the state to transmission
* set the channel to occupied
* reset the BOexp (BOexp=0)
* else if(slot!=shared)
* set the state to transmission
* set the channel to occupied
* reset the BOexp (BOexp=0)
* if the actual slot is not reserved for this device and is not a shared slot
* reset the BOexp (BOexp=0)
* reset the BOcntr (BOcntr=0)
* set the state to BLOCKED,
this device can’t access to the medium in this time slot
Figure 3.7: MAC Algorithm
3.4.2 Devices Tables
In the WirelessHART protocol it is specified that each device must have a particular table
in which all the communication details are specified. The main information, that the table
26
3.4. Implementation
must contain, are the time slots in which the device has to communicate, the information
for the channel hopping technique, the device with which the communication has to be
done and the information about each link (for example if the link is shared). In Table 3.2
the structure of the table is shown with the possible values of each field.
FrameID TimeSlot ChOffset DevAddress LinkOpt LinkType
{1..Nbrframes} {1..NbrSlots} {1..Nbrch} {1..NbrNodes} 0=RX 0=normal
1=TX 1=advertisement
-1=shared
Table 3.2: Device Table
The first column has to contain the frameID, a value that indicates the unique identification
number of a superframe. This value is needed because in wirelessHART each device must
support multiple superframes. The second column is the list of the slots in which the
device wants to communicate. The channel offset value (ChOffset) indicates, for each
slot, which channel the device uses to transfer the data. The DevAddress field indicates
with which device the communication has to be realized. In case of transmission, this
field represents the destination device. In case of reception it represents the source of the
message. The link option field (linkopt) indicates the type of communication. If the value
is 0, it means that the device must receive, otherwise 1 means that it must transmit. The
last column indicates if a slot is reserved to a device, if it is a shared slot or if the slot is
dedicated to the advertisement (for example from the network manager).
3.4.3 Synchronization of the devices tasks
For successful and efficient TDMA communications, synchronization of clocks between
devices in the network is critical. Consequently, tolerances on time keeping and time
synchronization mechanisms are specified to ensure network-wide device clock synchro-
nization. It is imperative that devices know when the start of a slot occurs. For that
reason the first operation in the MAC function is to read the actual simulation time from
the MATLAB environment. With this value the device is able to compute the actual slot
time :
27
3.4. Implementation
ActualSlotNumer = (Actual Sim time + exectime
SlotSize%SuperframeSize) + 1 (3.2)
where the exectime is the execution time of the device task that has called the MAC
function. The SlotSize is fixed to 10 ms in WirelessHART and the SuperframeSize is the
number of slots contained in a superframe (typically 100 slots, i.e. a superframe length of
1 s).
28
Chapter 4
Introduction to TrueTime
4.1 Description of the tool
This chapter describes the use of the original Matlab/Simulink-based simulator TrueTime
[5], which facilitates co-simulation of controller task execution in real-time kernels, network
transmissions (using wired or wireless networks), and continuous plant dynamics. In the
next chapter will be described the changes that have been made in this project. TrueTime
is not constituted by only the blocks library, but also by a collection of C++ functions
with corresponding MATLAB MEX-interfaces. Some functions permit to configure the
simulation by creating tasks, interrupt handlers, monitors, timers, etc. The other functions
are real-time primitives that are called from the task code during execution and provides
for AD-DA conversion, changing task attributes, entering and leaving monitors, sending
and receiving network messages, etc. TrueTime is developed in Simulink, which allows for
traditional control system assessment in terms of performance, stability and robustness.
TrueTime is primarily intended to be used together with MATLAB/Simulink. However,
the TrueTime kernel implements a complete event-based kernel and Simulink is only used
to interface the kernel and the tasks with the continuous-time processes.
29
4.1. Description of the tool
Being written in C++, it is easy to adapt the block code to other simulation environments.
All TrueTime objects, such as tasks, interrupt handlers, monitors, timers and events, are
defined by C++ classes that are easily extendable by the user to add more functionality.
Figure 4.1: The TrueTime 1.5 block library.
4.1.1 The TrueTime Kernel
One of the blocks contained in the library is the Kernel block. It is a MATLAB S-
function that simulates a CPU with a real-time kernel, A/D and D/A converters, a network
interface, and external interrupt channels. Internally, the kernel maintains several data
structures that are commonly found in a real-time kernel: a ready queue, a time queue,
and records for tasks, interrupt handlers, monitors and timers that have been created
for the simulation. The kernel executes an arbitrary number of user-defined tasks and
interrupt handlers. Some of them may also be created dynamically at run-time. Tasks
may be periodic to simulate activities such as controller and I/O tasks, or aperiodic to
represent activities like communication tasks and event-driven controllers. Aperiodic tasks
are executed by the creation of task instances (jobs). The kernel block is configured
through the block mask dialog, see figure 4.2 (some parameters can be set during the
simulation using the function ttSetKernelParameter):
Init function The name of the initialization script, see Section B.3.
Init function argument an optional argument to the initialization script.
30
4.1. Description of the tool
Battery Enable this check box if the kernel should depend on a power source.
Clock drift The time drift, α if the local time should run α% faster than the nominal
time (the actual simulation time).
Clock offset A constant time offset from the nominal time.
Figure 4.2: The dialog of the TrueTime kernel block.
4.1.2 The TrueTime Network
The TrueTime network block permits to simulate medium access and packet transmission
in a local area network choosing different communication protocols: CSMA/CD (e.g.
Ethernet), CSMA/ AMP (e.g. CAN), Round Robin (e.g. Token Bus), FDMA, TDMA
(e.g. TTP), and Switched Ethernet. Only packet-level simulation is supported. It is,
in fact, assumed that the messages have been divided into packets at higher protocol
levels. When a node tries to transmit a message (using the primitive ttSendMsg), a
triggering signal is sent to the network block on the corresponding input channel. At the
end of the transmission, the network block sends a new triggering signal on the output
channel corresponding to the receiving node. Each receiving node has a buffer in which
the transmitted message is put. A message is characterized by several information: the
sending and the receiving node, arbitrary user data (typically pieces of signals or control
31
4.1. Description of the tool
signals), the length of the message, and optional real-time attributes such as a priority or
a deadline.
Figure 4.3: The dialog of the TrueTime network block.
The network block is configured through the block mask dialog, see Figure 4.3. Some pa-
rameters may be changed on a per-node basis using the command ttSetNetworkParameter,
see Section D. The following network parameters are common to all models:
Network number The number of the network block. The networks must be numbered
from 1 and upwards. Wired and wireless networks are not allowed to use the same
number.
Number of nodes The number of nodes that are connected to the network. This number
will determine the size of the Snd, Rcv and Schedule input and outputs of the block.
Data rate (bits/s) The speed of the network.
Minimum frame size (bits) A message or frame shorter than this will be padded to
give the minimum length. Denotes the minimum frame size, including any overhead
32
4.1. Description of the tool
introduced by the protocol. E.g., the minimum Ethernet frame size, including a
14-byte header and a 4-byte CRC, is 512 bits.
Pre-processing delay (s) The time a message is delayed by the network interface on
the sending end. This can be used to model, e.g., a slow serial connection between
the computer and the network interface.
Post-processing delay (s) The time a message is delayed by the network interface on
the receiving end.
Loss probability (0–1) The probability that a network message is lost during transmis-
sion. Lost messages will consume network bandwidth, but will never arrive at the
destination.
4.1.3 The TrueTime Wireless Network
The Wireless Network block (see Section 4.2 for more details) permits to simulate, like
the one described in the last section, the communication between two nodes. It takes
into account also the path-loss of the radio signals. The possibility to lose packets is
modelled considering the spacial location of the nodes, the power transmission used and
some other statistical parameters. Only two network protocols were supported originally:
IEEE 802.11b/g (WLAN) and IEEE 802.15.4 (ZigBee). WirelessHART has been added
(see Sec. 3.4.1 and 5.7). The radio model used includes support for:
• Ad-hoc wireless networks.
• Isotropic antenna.
• Inability to send and receive messages at the same time.
• Path loss of radio signals modeled as 1da where d is the distance in meters and a is
a parameter chosen to model the environment.
• Interference from other terminals.
The wireless network block is configured through the block mask dialog, see Figure 4.4.
Using the command ttSetNetworkParameter some parameters can also be set on a per-
node basis.
33
4.1. Description of the tool
Figure 4.4: The dialog of the TrueTime wireless network block.
The following parameters are common to all models:
Network type Determines the MAC protocol to be used. Can be either 802.11b/g (
WLAN) or 802.15.4 ( ZigBee).
Network number The number of the network block. The networks must be numbered
from 1 and upwards. Wired and wireless networks are not allowed to use the same
number.
Number of nodes The number of nodes that are connected to the network. This number
will determine the size of the Snd, Rcv and Schedule input and outputs of the block.
Data rate ( bits/s) The speed of the network.
Minimum frame size (bits) A message or frame shorter than this will be padded to
give the minimum length. Denotes the minimum frame size, including any overhead
introduced by the protocol. For example, most network protocols have a fixed num-
ber of header and tail bits, so the frame must be at least sizeof(header)+sizeof(tail)
long.
34
4.1. Description of the tool
Transmit power Determines how strong the radio signal will be, and thereby how long
it will reach.
Receiver signal threshold If the received energy is above this threshold, then the
medium is accounted as busy.
Path-loss exponent The path loss of the radio signal is modeled as 1da where d is the
distance in meters and a is a suitably chosen parameter to model the environment.
Typically chosen in the interval 2-4.
ACK timeout The time a sending node will wait for an ACK message before concluding
that the message was lost and retransmit it.
Retry limit The maximum number of times a node will try to retransmit a message
before giving up.
Error coding threshold A number in the interval [0, 1] which defines the percentage of
block errors in a message that the coding can handle. For example, certain coding
schemes can fully reconstruct a message if it has less than 3% block errors. The
number of block errors are calculated using the signal-to-noise ratio, where the noise
is all other ongoing transmissions.
4.1.4 The TrueTime Standalone Network Blocks
The standalone network blocks are two, the ttSendMsg and the ttGetMsg. They can
be used to send messages using the network blocks without using kernel blocks (see Sec.
4.1.1). This permits (not having to initialize kernels, create and install interrupt handlers,
etc.) to build quickly a simulation, without create any M-files.
The standalone network blocks are configured through the block mask dialogs, seen in
Figure 4.5. The parameters are the same that are used in the ttSendMsg and ttGetMsg
primitives. The ttSendMsg block has a Simulink trigger input port, which can be config-
ured to trigger on raising, falling or either flanks. The ttGetMsg block has an optional
trigger output port whose value switches back and forth between 0 and 1 as messages
are received. It is useful to trigger any other block that has to be executed after a new
message has been received.
35
4.2. Wireless Network Block behaviour
Figure 4.5: The dialog of the ttGetMsg block to the left, and the dialog of the ttSendMsg
block to the right.
4.1.5 The TrueTime Battery
The battery block permits to set the initial power of a node using the configuration mask.
To use the battery, enable the check box in the kernel configuration mask and connect the
output of the battery to the E input of the kernel block. Connect every power drain such
as the P output of the kernel block, ordinary Simulink models, and the wireless network
block to the P input of the battery. The battery uses a simple integrator model, so it can
be both charged and recharged. If the kernel is configured to use batteries and the input
P to the kernel block is zero, it will not execute any code.
4.2 Wireless Network Block behaviour
The wireless network block simulates medium access and packet transmission. Originally
it implemented two kinds of communication protocols, 802.11b/g (WLAN) and 802.15.4
(ZigBee). The possibility to use also WirelessHART has been added. The block permits
36
4.2. Wireless Network Block behaviour
to simulate packets lost using a packet error probability or specifying when a packet has to
be discharged. It permits to compare more simulations together taking into account how
the same sequence of packets lost affects them. In the following subsection the original
options of the network will be carefully described. The new possibilities added in this
project, instead, are described in chapter 5
4.2.1 802.11b/g ( WLAN)
IEEE 802.11b/g are two of the more popular protocols used today. IEEE 802.11 is used
in many laptops and mobile devices. The protocol is based on CSMA/CA with some
modifications. In TrueTime a package transmission is modelled like this: The node that
wants to transmit a packet checks if the medium is idle. The transmission may proceed,
if the medium is found to be idle, and has stayed so for 50 µs. If, on the other hand,
the medium is found to be busy, a random back-off time is chosen and decremented in
the same way as when colliding (described later in this section). When a node starts to
transmit, its relative position to all other nodes in the same network is calculated, and the
signal level in all those nodes are calculated according to the path-loss formula 1/da. If the
signal level in the receiving node is larger than the receiver signal threshold, then the
signal-to-noise ratio (SNR) is calculated and used to find the block error rate (BLER). All
other transmissions add to the background noise when calculating the SNR. The BLER
and the size of the message are used together to calculate the number of bit errors in the
message. If the percentage of bit errors is lower than the error coding threshold, then
it is assumed that the channel coding scheme is able to fully reconstruct the message.
If any other nodes are already transmitting to the receiving node and their respective
SNRs are lower than the new one or if there are other ongoing transmissions which the
currently sending node reaches with its transmission, then all those messages are marked
as collided and discharged. From the perspective of the sending node, lost messages and
message collisions are the same. ACK messages are sent on the MAC protocol layer. If
the ACK is not received by the transmitting node during ACK timeout, the message
is retransmitted after waiting a random back-off time within a contention window. The
contention window size is doubled for every retransmission of a certain message. The
back-off timer is decremented only if the medium is idle, or if it has been idle for at least
50 µs. The Retry limit number of retransmissions specifies the maximum number of
37
4.2. Wireless Network Block behaviour
times that a message could be retransmitted before it is discharged.
4.2.2 802.15.4 (ZigBee)
ZigBee is a protocol optimized for the use of sensors and simple control networks. It is
characterized by a rather low bandwidth and by a really low power consumption that
increases the life of the devices from a battery consumption point of view. It is based on
CSMA/CA.
The packet transmission model in ZigBee is similar to WLAN, but the MAC procedure
differs and is modeled as:
1. Initialize:
NB=0
BE=macMinBE
2. Delay for a random number of backoff periods (order of 100 µs) in the interval
[0, 2BE − 1]
3. Is the medium idle?
if yes: send
else: goto 4
4. Update the backoff counters:
NB=NB+1
BE=min(BE+1, aMaxBE)
5. Is NB>macMaxCSMABackoffs?
if yes: drop the packet
else: goto 2
where:
NB Number of backoffs.
BE Backoff exponent.
macMinBE The minimum value of the backoff exponent in the CSMA/CA algorithm.
The default value is 3.
38
4.2. Wireless Network Block behaviour
aMaxBE The maximum value of the backoff exponent in the CSMA/CA algorithm. The
default value is 5.
macMaxCSMABackoffs The maximum number of backoffs the CSMA/CA algorithm
will attempt before declaring a channel access failure. The default value is 4.
The variable names are taken from the standard to make comparisons easier.
4.2.3 Calculation of Error Probabilities
When a symbol is sent, in this case it is a bit, an additive white Gaussian noise gives a
probability density function for the received symbol, that for some signal-to-noise ratio
may look like Figure 4.6. A threshold is then used to decide if the received symbol is a 0
or a 1. The darker area to the left of the threshold gives the probability of a symbol error.
A higher signal to noise ratio translates the curve to the right, making the probability of
error smaller. During the calculation of error probabilities, the following approximation is
done: BPSK1 is always used in the transmissions.
The above standard procedure takes into account the single bits that form a message.
The total number of calculated bit errors should then be compared to the error coding
threshold. Being it very computationally expensive, it has been chosen to save the max-
imum noise level during the transmission and to use it to calculate the worst case SNR.
By assuming that bit errors in a message are uncorrelated, it is deduced that the number
of bit errors, X, belongs to a binomial distribution X ∈ Bin(n, p), where n is the number
of bits in the message, and p is the probability that a certain bit is erroneous. If the value
of n is large, the binomial distribution can be approximated with a normal distribution,
using the central limit theorem. This gives that X ∈ N(np,√
npq) where q = 1−p. What
we are really interested in is the probability that bn, where b is the error coding threshold,
is larger than the total number of bit errors in a message.
This probability is calculated using
P (X ≤ bn) =
Φ(bn− np√
npq) if bn− np > 0
1− Φ(|bn− np|√
npq) if bn− np ≤ 0
(4.1)
where Φ is the standard normal cumulative distribution function.1Binary Phase Shift Keying (BPSK) is a means of transmitting symbols by altering the phase of a
reference signal. It uses two phases separated by 180◦ and is hence binary.
39
4.2. Wireless Network Block behaviour
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
Figure 4.6: Probability density function for a received symbol when using binary phase
shift keying and additive white Gaussian noise.
Example
Assume that a message consists of 100 bits (i.e., n = 100). The probability that a certain
bit is erroneous has been calculated to 0.1 using the above method, i.e., p = 0.1 and
q = 1− p = 0.9. The error coding threshold has been set to 5%, i.e., b = 0.05. Then the
probability that we can decode the complete message is
P (X ≤ bn) = 1− Φ(|bn− np|√
npq) = 1− Φ(
5√9) ≈ 0.0478 (4.2)
User-Defined Path-Loss Function
TrueTime permits to use a different path-loss function, instead of the defined one. The de-
fault path-loss function (or propagation model) used in the TrueTime wireless simulations
is [26]:
Preceiver =1da
Psender (4.3)
40
4.2. Wireless Network Block behaviour
where P is the power, d is the distance in meters, and a is a parameter that can be chosen
to model different environments. This model is often used in simulations, but if the user
prefers to implement his own function, he may do it by writing a Matlab m-file where all
the built-in functions available in Matlab or Simulink could be called.
The Matlab function has to take the following arguments
• Transmission power
• Name of the sending node
• x and y coordinates of the sending node
• Name of the receiving node
• x and y coordinates of the receiving node
• Current simulation time
and return the signal power in the receiving node.
41
Chapter 5
New functions in the wireless
network block
5.1 Introduction
In this chapter will be described some new utilities implemented to improve the behavior
and the useability of the wireless network block of TrueTime. In Section 5.2 the 3D
location of the nodes is described. It permits a more realistic placement of the devices in
the environment. Another useful functionality is introduced in Section 5.3 and it consists
in the possibility to introduce an external source of noise. Section 5.4 explains a new way
for the computation of the noise considering a time correlation between the time samples.
To improve the usability of the tool the possibility to notice when a packet is lost has
been added (Section 5.5). Section 5.6 explains a new option that permits to simulate, in a
deterministic way, a time interval in which the network loses packets. Section 5.7 describes
the modification in the TrueTime graphic interface, of the wireless network block, done
to use the WirelessHART protocol. For a more realistic behavior of the devices the MAC
layer has been moved from the wireless network block and implemented in a separate
function that can be called from each device (Section 5.8).
5.2 Nodes in the 3D space
TrueTime allows to collocate the devices on a 2D plane. It does not permit to build up a
real scenario in which the nodes could be placed at different heights, for example attached
to the same column. For that reason, the possibility to specify the (X,Y,Z) coordinates
(meters) in the space for each node is given (see Fig. 5.1).
42
5.3. External noise port
Figure 5.1: The TrueTime wireless network block with the x,y,z coordinates inputs port that specifies
the true location of the nodes
This new information has to be considered in the computation of the signal power received
during a transmission. In fact, as is described in Section 4.2.3:
Preceiver =1da
Psender (5.1)
where P is the power, a is a parameter that can be chosen to model different environments
and d is the distance in meters. Considering the new coordinates, the distance between
the node i and the node j is:
d =√
(Xi −Xj)2 + (Yi − Yj)2 + (Zi − Zj)2 (5.2)
This new computation of the distance involves also the probability of packets lost (see
Section 4.2.3).
5.3 External noise port
The TrueTime default error probability function takes into account a signal to noise ratio
SNR, for the transmitted packet i , computed in the following way:
SNRi =Preveiveri∑N
j=1 Preveiverj − Preveiveri
(5.3)
43
5.4. Noise and time correlation
where Preveiveri is the power of the packets i,∑N
j=1 Preveiverj is the total power at the
receiver node. This formula considers the interferences due to other nodes than the trans-
mitting one. In fact, it is possible that more than one node tries to transmit at the same
time to the same node. Anyway this approach does not take into account other sources of
interferences like thermal noise, fading or other radio traffic not belonging to this network.
For that reason an input port is added. It permits to specify for each device an external
source of noise that can be, for example, a white noise block or a sequence of measurements
taken from a real case (see Fig. 5.2).
Figure 5.2: The wireless network block with the external noise input port.
This external contribution is introduced in (5.3) in this way:
SNRi =Preveiveri∑N
j=1 Preveiverj − Preveiveri + Ni
(5.4)
where Ni is the contribution of this new component to the SNR of the transmitted packet i .
5.4 Noise and time correlation
In a real environment, where the nodes are fixed in a place and not in movement, if an
event causes interferences, the effects produced by this will not vanish immediately, but
44
5.4. Noise and time correlation
will have an impact also in subsequent moments. Considering this fact, a time correlation
is introduced in the computation of the interferences:
Ni = a ·Ni−1 + Vi Vi ∼ N (µVi , σ2Vi
) (5.5)
where a (currently fixed at the value of 0.9) is a coefficient that indicates the correlation
between two samples, Vi is a gaussian noise and Ni ∼ N (µNi , σ2Ni
) is the final interference.
The initial value of the sequence, N0, is picked from the external noise port.
To chose with which order of magnitude of interference to work, it is possible to set the
average µVi and the variance σ2Vi
of the gaussian noise from the mask interface of the
wireless network block (see Fig. 5.3).
Figure 5.3: The average and the variance fields in the wireless network block mask
The final variance σ2Ni
is affected by σ2Vi
in the following way
σ2Ni
=σ2
Vi
1− a2(5.6)
45
5.5. Packets lost signal
The average value of Ni will be
µNi = a · µNi−1 + µVi (5.7)
5.5 Packets lost signal
To have a complete mastery of simulation, it is useful to monitor the packets lost situation.
For this reason, a new graphics function has been added. It allows to highlight in a chart
when a packet is lost, due to a collision, external interference or excessive attenuation of
signal. This permits to study in a simpler way how it affects the control performance (see
Fig. 5.4).
Figure 5.4: The plot of the lost packets and the consequences in the control performance
To plot the lost packets, an output port has been added in the wireless network block (see
Fig. 5.5).
Figure 5.5: The wireless network block with the output port for the packet lost signal
46
5.6. Fixed packet loss functionality
5.6 Fixed packet loss functionality
To study the problem of packet loss in the wireless control networks and to compare the
results of different solutions, the possibility to fix the time intervals in which the packets
are lost has been also added.
Figure 5.6: Settings for the fixed packets lost option
When the check box indicated in figure 5.6 is selected a new field appears in the mask. In
this field it is possible to write an array of time intervals following this structure:
[∆t1start ∆t1stop ∆t2start ∆t2stop . . . ∆tnstart ∆tnstop]
∆tistart is the instant, in seconds, when the network starts to lose packets and ∆tistop is
47
5.7. Wireless Network Mask modification
the final instant of that interval. Considering, for example, the values fixed in figure 5.6:
[1.1 1.3 4.9 5.1 10.2 10.4 15 15.2]
the packets lost intervals and the possible consequences in a control loop are shown in
figure 5.7
Figure 5.7: The plot of the packets lost and the consequence in the control performance
5.7 Wireless Network Mask modification
The possibility to chose the wirelessHart MAC protocol in the wireless network block mask
has been added. Figure 5.8 shows the mask with all the parameters and the default values
for the Hart case.
As is shown in figure 5.8 WirelessHart uses the same parameters as for Wlan and ZigBee
with the addition of three fields to set the number of channels, the size of the slot and the
superframe length.
48
5.8. Moving the MAC into each device
Figure 5.8: The parameters setting in the WirelessHart mask
5.8 Moving the MAC into each device
In the original version of TrueTime the wireless network block is responsible for the im-
plementation of the MAC protocols of all the devices, as well as the simulation of packets
loss and graphic plot (Figure 5.9).
Figure 5.9: MAC protocol location in TrueTime
49
5.8. Moving the MAC into each device
This does not correspond perfectly to reality. In fact, in a real environment, each device has
its own MAC sub-layer. When a device wants to access the network it has to interrogate
the MAC in a local way (see Fig. 5.10).
Figure 5.10: MAC protocol location in a real environment
When the MAC sub-layer of a device permits the access to the network, the message will
be propagated through the medium.
5.8.1 The WirelessHART MAC sub-layer in each device
The ttMAC function described in section 3.4 permits to work using the scenario described
above. WirelessHART (see Section 3.3) communication is arbitrated using TDMA to
schedule link activity. All communication is performed within a designated slot with a
period of 10 ms. If a packet is lost, it will have to be retransmitted in a specially reserved
future time slot. In case shared slots are used and a collision occurs, a back-off counter
has to be decreased until 0 before to try a new transmission. The Back-off is decremented
at most one time for each time slot. For all these reasons the the MAC sub-layer will not
operate more frequently than 10 ms. So every time a transmission is required, it is possible
to call the ttMAC function. If the channel is free and the back-off counter is already equal
to zero, the function will give a positive response. Permitting to each device to memorize
its own status (BOcounter, BOexponent) the MAC layer can be implemented and called
inside each device (see Fig. 5.10). The network block in this case will be responsible only
for the propagation of the message, for the computation of the packet loss error and for
the graphics function.
50
Chapter 6
Study of Packet Loss
In this chapter the problem of packet loss in wireless networks is treated. The first section
is an introduction to the main causes of the problem. In section 6.2 the behaviour of
different wireless protocols (Wlan, ZigBee, WirelessHART) is explained. Some possible
techniques to reduce the effects of packets lost in a wirelessHART networked control system
are analyzed in section 6.4. In the last section 6.5 the possibility to use a wireless network
in a real mining plant is studied.
6.1 Introduction
The use of wireless networks in the automation field is expanding always faster. The
benefits introduces by the use of wireless communication in the networked control system
are many. First of all, the wireless sensors are easy and cheap to place. This is due
the absence of cables between sensors and the data acquisition system and also to the
continuous decrease of the prices of wireless devices. Moreover the absence of cables gives
more degrees of freedom (e.g. a sensor installed in a robotic arm). The price to be paid in
the use of wireless networks is lower reliability. In fact, the communication channel (radio
frequency band) could be affected by interferences due, for example, to others networks
operating in the same radio frequencies. This interference and other sources of noise
leads to bit errors and packet loss. The aim of the control application, using wireless
communication, is to be able to handle occasional loss of connection. For this reason the
problem of packets lost assumes particular relevance in the design of the controller.
51
6.1. Introduction
6.1.1 Main causes of packet loss
Packet loss can be caused by a number of different factors. These factors can be summa-
rized in three points:
• channel interference
• channel fading
• collisions of packets transmitted by more nodes at the same time (only for networks
using contention based MAC protocols, like CSMA or similar)
Channel interference
Concerning the first point, it has to be noticed that the interferences in the medium are
principally due to other networks operating in the same frequency band. In fact, the
principal wireless network protocols (e.g Bluetooth, Wlan, ZigBee) all operate in the same
ISM bands (2.4-2.5 GHz). The main characteristics of some available radio standards and
commercially available technologies operating in the ”free” ISM bands are shown in figure
6.1.
Figure 6.1: Main characteristics of major radio standards and technologies.
52
6.1. Introduction
From figure 6.1 it is possible to notice that the ISM bands are very crowded. Hence, it
is possible to have interferences due to the co-existence of different networks. Studies on
interference between different networks may be found in [13],[14] and [15]. Comparison
between Bluetooth and ZigBee interference susceptibility is introduced in [16]. To limit
the packets lost due to the network interferences, a good placement of the nodes, as a
function of the measured value of noise, is required.
The fading problem
Fading is a phenomenon that happens when, in a wireless communication, the presence
of obstacles between the transmitter and the receiver creates multiple paths for the trans-
mitted signal (see figure 6.2).
Figure 6.2: The fading problem
The received signal is, therefor, a superposition of multiple copies of the transmitted one
that arrive in different time instants. Each copy of the signal has difference attenuation,
delay and phase shift due to different travel from the source to the receiver. The principal
effect of this phenomenon is the modification of the signal power at the receiver. The are
two kinds of fading: Slow fading and Fast fading. The first one generally means variations
in signal power that change slowly with time (i.e. slowly compared to the transmission
frame length), while fast fading means variations in the signal amplitude that change
rapidly with time (i.e. in the order of a packet length).
53
6.1. Introduction
A valid method to avoid the problem of fading is the frequency hopping technique, that is
the repeated switching of frequencies during radio transmission. In this way, it is possible
to reconstruct the received signals without errors.
Packets lost due to collisions
The last cause of packet loss is depending on the particular MAC protocol used by the
wireless network. In fact if the network uses a contention based MAC protocol, collisions
can occur between messages that have been sent at the same time. Consider the carrier
sense multiple access with collision avoidance (CSMA/CA, see section 2.2.2) protocol that
is used in the 802.11 standard. In this protocol, when a node has to transmit, it first
checks the medium to ensure that no other nodes are transmitting. If the channel is idle,
it then transmits the packet. Otherwise, the node chooses a random ”back-off factor”
which determines the amount of time it has to wait until to be allowed to transmit its
packet. During periods in which the channel is clear, the transmitting node decrements
its back-off counter (when the channel is busy it does not decrement its back-off counter).
When the back-off counter reaches zero, the node transmits the packet. The collision
avoidance permits to reduce the probability that a collision occurs but it is not possible
to detect the collision if it occurs. In fact collision detection, as is employed in Ethernet,
cannot be used for the radio frequency transmissions of IEEE 802.11. The reason for this
is that, when a node is transmitting, it cannot hear any other node in the system which
may be transmitting. If the source node does not receive an ACK, due to collision, it
reactivates the back-off algorithm to have a retransmission of the message. When the
number of collisions exceeds the maximum number of retransmissions, the packet is lost.
This can happen, especially, when the network load is high, and some devices have to
transmit in the same period. To avoid this problem, a more deterministic MAC protocol
has to be used, for example the WirelessHart, that uses the TDMA technique (see section
3.3.2).
6.1.2 The problem of packet loss in the networked controlled systems
Networked controlled systems constitute a set of research topics in full rise. This rise is di-
rectly related to the spectacular development of the communication networks in numerous
industrial applications. Particularly quoted is the field of the manufacturing production
54
6.2. Comparison of different protocols with respect to packet loss
and the complex processes or systems (distributed control of transport or energy networks
for example). All these applications strongly rely on the characteristics of the commu-
nication channel. The problem of packet loss in wireless communication is of particular
relevance when the network is inserted in the context of a control system.
Figure 6.3: The scheme of a control loop with wireless communication
Consider the scheme in figure 6.3. The sensor sends the measurement to the controller
that computes the control signal and sends it to the actuator. Both the communications
are provided by the wireless network. It is possible to lose packets in both the paths: from
the sensor to the controller and from the controller to the actuator. If the packets are
lost in the first path, the controller does not have the feedback from the process and the
control signal has to be computed taking into account this lack of information and trying
to estimate the lost data. Some solutions to these problems are analyzed in section 6.4. If
the loss happens in the second path, a smart actuator is needed to memorize and use the
past values of the control signal.
6.2 Comparison of different protocols with respect to packet
loss
In this section a comparison between wireless networks that uses different MAC protocols
is presented. The aim of the section is to show the behaviour of different wireless protocols
used in a control system.
55
6.2. Comparison of different protocols with respect to packet loss
6.2.1 The compared protocols
Three different protocols, operating in the same band (ISM band 2.4 GHz), have been
compared:
• WLAN;
• ZigBee;
• WirelessHART.
WLAN ZigBee WirelessHART
MACtype CSMA/CA CSMA/CA TDMA
CSMA/CA ( shared slots)
Data Rate 2-54Mb/s 20-250kb/s 250kb/s
Packet length 34-2346 bytes 128 bytes 128 bytes
Freq. hop. YES Not specified YES
PowerConsump. high low low
Band(s) 2.4-2.5 GHz 868, 902-928 MHz 2.4-2.5 GHz
5.15-5.825 GHz 2.4-2.5 GHz
number of nodes limitation due 255 nodes 250 nodes
to collisions
Table 6.1: Principal characteristics of WLAN, ZigBee and WirelessHArt
The Wireless LAN protocol is defined by the IEEE 802.11 family of specifications (see
section 2.3.2). The MAC protocol is based on CSMA/CA technique (carrier sense mul-
tiple access with collision avoidance, see section 2.2.2). ZigBee (see section 2.3.4) is a
low-power wireless communications technology and international standard protocol. It
uses the physical and MAC layers defined by IEEE 802.15.4, (see section 2.3.3) which is
the short-distance wireless communication standard for 2.4 GHz band. WirelessHART
(see chapter 3) provides a low cost, relatively low speed (e.g., compared to 802.11g) wire-
less connection to HART-enabled devices. The physical layer follows the standard IEEE
802.15.4. WirelessHART communication is time slotted, where each slot is 10ms. Slots
can be either dedicated to one node or shared by several nodes. Dedicated slots use TDMA
for medium access, while shared slots use CSMA/CA. The main characteristics of these
three protocols are described in the table 6.1.
56
6.2. Comparison of different protocols with respect to packet loss
6.2.2 Simulation Setup
To analyze the different behaviour of the three protocols in an industrial plant, a simulation
of a networked control system has been made. All the simulations have been done in the
Simulink environment using the modified TrueTime simulator (see chapter 5). The scheme
of the networked control system is shown in figure 6.4
Figure 6.4: The Simulink scheme of the networked control system
In this control system there is only one loop. The sensor sends the measurement to
the gateway that is responsible to communicate with the controller using a wired protocol
(like Profibus or Fieldbus) and to send the control signal to the actuator using the wireless
network (see figure 6.5).
Figure 6.5: Schematic of the communication between the devices
In each device a periodic task is executed to handle the communication.
57
6.2. Comparison of different protocols with respect to packet loss
The transfer function of the system that has to be controlled is :
G(s) =50
s(25s + 1)(6.1)
The choice of this particular system is not due to any specific reasons. The only constraint
in the choice of this transfer function is the time constant of the system. In fact Wire-
lessHART can control only the processes that have closed-loop time constants at least at
the order of tens of milliseconds. This is imposed by the WirelessHART MAC protocol
that uses TDMA with slots of 10 ms. In each slot only one transmission (in the same
channel) is possible so, thinking of a control system, the minimum delay between sensing
and actuating is 20 ms. It is possible if the actuator task can be executed in the slot
immediately after the one of the sensor, see figure 6.6:
Figure 6.6: Illustration of the communication delay in WirelessHART. In the first slot the sensor (S)
sends the measurement to the gateway (GW) and in the second slot the gateway sends the control signal
to the actuator. The controller (C) executes between the sensor and the actuator tasks.
Notice from figure 6.6 that the controller does not need a slot in the communication
schedule. This is due to the fact that the controller communicates with the gateway by
wire. If the execution time of the controller task is of the same order of the time slot
(10 ms), it is better to leave at least one slot empty between sensing and actuating to
give the possibility for the controller to finish its calculations. The reference is a square
wave with an amplitude of 1, a period of 5 seconds and a duty cycle of 50%. The control
algorithm used is Proportional Derivative. The PD-controller is implemented according
to the following equations:Pk = K · (rk − yk)
Dk = adDk−1 + bd(yk−1 − yk)
uk = Pk + Dk
(6.2)
where ad = TdNTs+Td
, bd = NKTdNTs+Td
, Ts is the sample time, Td is the derivative constant, K
is the gain of the controller and N is a factor for the filtering of the derivative part:
58
6.2. Comparison of different protocols with respect to packet loss
D(s) = − sKTd
1 + sTdN
Y (s) (6.3)
Hence the ideal derivative sTd is filtered by a first order system with the time constant
Td/N. This means that high frequency measurement noise is amplified at most by a factor
KN (more details could be found in [8]).
6.2.3 Network parameter settings
The main parameters of each network protocol has been set using the wireless network
block mask described in section 4.1.3 and in chapter 5.
Figure 6.7: Settings of the network parameters for WLAN, Zigbee and WirelessHART
An important thing to notice, in the configurations (see Fig. 6.7), is the setting of the
noise. In fact, to simulate the loss of packets some noise has been added to the network like
59
6.2. Comparison of different protocols with respect to packet loss
a source of interference. It influences the signal to noise ratio (see section 5.3) and causes
the loss of the packets. The noise is characterized by a time correlation effect (section
5.4):
Ni = a ·Ni−1 + Vi Vi ∼ N (µVi , σ2Vi
) (6.4)
where a (currently fixed at the value of 0.9) is a coefficient that indicates the correlation
between two samples, Vi is a gaussian noise and Ni ∼ N (µNi , σ2Ni
) is the final interference.
The initial value of the sequence, N0, is picked from the external noise port.
Another thing to notice is the setting of the WirelessHART protocol. For these simulations
the shortest superframe possible has been chosen. In fact the WirelessHART superframe
has a minimum length of 0.5 s that means 50 slots of 10 ms each. Obviously to control
this system is necessary to sense more often than 0.5 s.
For that reason the superframe has been designed in the according to figure 6.8.
Figure 6.8: WirelessHART superframe
In this scenario a slot has been left empty between the sensor task and the actuator
task. This has been done to permit the controller to complete its calculations. With this
particular scenario the sensor sends the measured values every 0.03 s.
6.2.4 Simulation results
The simulations have been done in the Simulink environment using the modified Truetime
and considering the settings explained in section 6.2.2 and 6.2.3. The reference tracking
of the networked control system, using the three different protocols, is shown in figures
6.9, 6.10 and 6.11.
In these pictures the periods in which the packets are lost are indicated by the red line.
This line rises to 0.5 when the packet is lost and is zero if the packet is correctly received.
60
6.2. Comparison of different protocols with respect to packet loss
Figure 6.9: Tracking of the reference of the networked control system using WLAN network
Figure 6.10: Tracking of the reference of the networked control system using ZigBee net-
work
61
6.2. Comparison of different protocols with respect to packet loss
Figure 6.11: Tracking of the reference of the networked control system using Wire-
lessHART network
A first result that is evident is the amount of packets lost for each protocol. Looking
at figures 6.9, 6.10 and 6.11 it appears that ZigBee is the protocol with more packets
lost. This is due to the necessity to use less power in the transmitted signal in order
to optimize the duration of the battery life of the devices. In fact, the lower the power
of the transmitted signal, the smaller is the signal to noise ratio and, consequently, the
probability to lose packets is greater. WLAN has the best behaviour in terms of number
of packets lost, but the power consumption of this protocol is very high and the battery
life of the devices could be too short. Moreover, these protocols are not deterministics
due to the use of CSMA/CA MAC protocol. In fact each device does not know when its
transmission will be effectuated because its message can collide with other messages and
the transmission could be retarded. If the number of the devices in the network increases,
the probability of collisions rises, increasing the probability of packets lost. A good trade-
off is represented by the use of WirelessHART. The use of the TDMA technique makes
the protocol deterministic. Each device knows the time slot in which it will transmit the
message and, if the slot is not shared, collisions may not occur and the probability to lose
packets due to collision is zero. The TDMA technique permits also to have a low power
62
6.3. A brief description of the AC800M
consumption because the devices are actives only in the time slots in which they have to
operate. On the other hand, as is described in 6.2.2, to use WirelessHART in a networked
control system it is necessary to be sure that the system to control has a time constant of
the order of tens of milliseconds. If the system is faster WirelessHART cannot be used.
6.3 A brief description of the AC800M
Before to introduce some different approaches to the problem of packet loss, an introduc-
tion to the AC800M controller is necessary. In fact in all the tests that have been done it
has been supposed to work with a model of this controller.
The AC800M is an ABB controller of the 800xA family [27] [28]. It is very popular device
and is used in many industrial plants all around the world. For the studies done here, it
will not be necessary to describe the whole system, but the scheduling of the threads that
this controller adopts is important. The AC800M works according to a scenario like the
one shown in figure 6.12.
Figure 6.12: AC800 typical scenario
Each execution cycle is began by AC800M reading the values of all sensors from their
respective registers. In the context of Wireless Hart, if an AC800M would be used for
the computation of the control signals, then all sensor slots would have to be before any
control tasks.
AC800M then writes the control signals to the output registers as soon as the corresponding
computation has been completed. Hence, one does not need to wait until all control signals
have been computed before actuator communication can start.
The reason for reading all sensor at once, is that when there are control loops with a
direct connection to each other, they need to be executed together. An example of such a
situation is cascaded loops, see Fig. 6.13.
Here the outer so called master controller provides the setpoint to the inner slave controller,
which in turn calculates the actuator signal. This means that two sensor signals are needed
63
6.4. Different approaches to the problem of packet loss
Figure 6.13: Cascade loops
to calculate one actuator signal. Obviously both sensor readings need to be available before
calculation can start.
It is however, highly unlikely that with a large number of loops in one network they are all
directly connected in this manner, why the requirement to have all sensor signals available
up front is an uneccessary (but obviously convenient) restriction.
6.4 Different approaches to the problem of packet loss
The wireless technology is potentially a useful tool for many control applications. The
benefits introduced by it are several, but, as it is explained in Sec. 6.1, the cost is a less
reliable communication. During the communication, some packets could be lost and it
corresponds to a lack feedback. For these reasons it is important to implement the control
loops taking this problem into account. Many techniques are adoptable in order to reduce
the damages introduced by an unstable communication.
Figure 6.14: The studied scenario: the sensor, the gateway and the actuator communicate
through a wireless network. The controller reads and sends the data from/to the gateway
through a wire.
64
6.4. Different approaches to the problem of packet loss
In this section some different approaches have been considered (see Sec. 6.4.1, 6.4.2 and
6.4.4). Studying these results, it is possible to have an idea of what could happen choosing
a method instead of another. The following solutions are applied assuming a scenario like
the one shown in figure 6.14. The sensor sends its measurement, to the gateway, using
a wireless network. Then the gateway communicates with the controller by wire, so no
packets can be lost. When the control signal is ready, it is passed from the controller to
the gateway and then, by the wireless network, to the actuator. In each device a periodic
task is executed.
6.4.1 Possible methods
This section presents some possible methods that can be used when packets are lost
between the sensor and the gateway.
1 uk = 0
When a packet is lost, the controller sends a signal equal to zero. This is of course
a choice that gives different results depending on the system considered and the
reference signal that has to be followed. If the system considered is stable, giving a
null input, the output of the system will tend to the equilibrium point. With other
kinds of system it can bring the closed loop to instability.
2 uk = uk−1
When a packet is lost the controller sends the previous control signal. A buffer,
where to memorize it, is needed in the controller.
These two cases can be applied, also, directly in the actuator if a smart one is
usable. If the actuator acts periodically, when it is time to execute, if no new data
are received, the actuator can read a buffer where the old control signals have been
stored and it can use the old control value. It does not matter where the packet is
lost. The result will be the same also if it happens in the gateway-actuator path.
3 yk = yk−1
If no new information on the system output values are available, the controller
continues working using the last data received. The controller needs a buffer in
which to memorize, at each execution, the last feedback signal received.
65
6.4. Different approaches to the problem of packet loss
4 Output estimation
The previous solutions are very simple and do not need any model information on
the plant that is controlled. Having access to a model, an estimation of the feedback
value could be done considering the previous data (see Fig. 6.15).
Figure 6.15: The control loop with an observer, if the feedback on the output is lost, it is possible to
use a predicted value.
When a packet sent from the sensor is lost, the new output could be estimated in
the controller. A first estimator has been implemented in this way:
Y (s) = G(s)U(s) ≈ G(s)U(s) (6.5)
where Y (s) is the estimated output, G(s) is a known model of the plant and G(s)
is the transfer function of the real plant. It is possible to write the observer in a
discrete form considering that the control signal is piece-wise constant.
For example, a first order system
G(s) =K
Ts + 1(6.6)
is described as
Yk = aYk−1 + bUk−1 (6.7)
witha = e
−TsT
b = K(1− a)(6.8)
where Ts is the sample time.
66
6.4. Different approaches to the problem of packet loss
When the controller task has to be executed, if no new data are available, the control
signal is computed considering the estimated output. This solution can improve the
behavior of the loop, but, if the control signal is affected by a disturbance (see Fig.
6.16), the predictor built in this way is not able to take it into account.
Figure 6.16: The studied scenario with disturbance on the control signal
To solve this problem a Luenberger observer with an extended state has been im-
plemented. Consider the following extended state space:
yk
dk
=
a b
0 1
yk−1
dk−1
+
b
0
uk (6.9)
where yk is the output at time k, uk is the control signal at time k and dk is the
disturbance at time k which is supposed to be constant.
In matrix form the system may be formulated as
Xk = AXk−1 + Buk
Yk = CXk = [1 0]Xk
(6.10)
The form of the Luenberger observer for a system like this is:
Xk = AXk−1 + Buk + L(Yk−1 − Yk−1)
Yk = CXk
(6.11)
The observer error is:
Xk = (A− LC)Xk−1 (6.12)
67
6.4. Different approaches to the problem of packet loss
Consider the system described by (6.9). Being (A,C) observable, it is possible to
place the eigenvalues of (A−LC) arbitrarily inside the unit circle (the observer being
discrete).
(A− LC) =
a− l1 b
−l2 1
L =
l1
l2
(6.13)
The eigenvalues satisfy:
[sI − (A− LC)] = s2 + (l1 − a− 1)s + a− l1 + bl2 = 0 (6.14)
Taking into account the poles of the observed system, it is possible to fix the eigen-
values, obtaining in this way l1 and l2. The Luenberger observer has been chosen
because of its easy implementation. Moreover, considering the simplicity of the
systems studied (see Sec. 6.4.3), it was improper to implement a more complex
estimator like, for example, a Kalman filter. This solution permits to improve the
behavior of the system, but it costs a more complex implementation of the controller
task. Figure 6.17 shows the performance of the controller using alternatively the two
predictors.
The system taken into account has been a first-order system:
G(s) =0.25
2s + 1(6.15)
The controller used is for both the cases a simple PI tuned following the lambda
tuning rules (see Sec. E). The simulation has been done using the TrueTime simula-
tor modified as explained in chapter 5. The same sequence of packets lost has been
considered for both the simulations to have the possibility to compare the results.
The reference and disturbance are considered to be square waves with amplitude
equal to 1, period of 60s and duty cycle equal to 50%. Considering a square wave
reference, but no disturbance, when a packet is lost, the performances are the same
for both the observers (see Fig. 6.17, top picture).
68
6.4. Different approaches to the problem of packet loss
Figure 6.17: The performances of the two predictors.
More interesting is to study the disturbance response. The reference signal is set
to zero. Notice that in this case ( 6.17, bottom picture), when some packets are
lost, the simple observer has a wore behavior than the Luenberger one. Immediately
before 80 seconds 3 packets are lost. While using the Luenberger observer the loop
is not affected by it, working with the other observer, the reference is not followed.
6.4.2 An improved PID
Another aspect to take into to account is that replacing a wired network with a wireless
network, it is expected to have intermittent communication losses (see Sec. 6.1.1). In
[6] an enhanced PID algorithm is proposed to improve the dynamic response under these
conditions. Here is given a brief introduction of this solution, without reporting all the
results there presented.
69
6.4. Different approaches to the problem of packet loss
When there are no packets lost the behavior of the enhanced PID is the same of a standard
PID. During the loss of some packets, instead, the integral component is modified in such
a way to compensate the loss of data. When finally the communication is re-established,
the derivative component of the improved PID helps to eliminate possible spikes in the
output. Starts considering a simple PID:
u(t) = Kc[e(t) + KI
∫e(t)d(t) + KD
de(t)dt
] (6.16)
where Kc, KI and KD are the parameters to tune. The error signal, e(t), is equal to
the difference between the reference signal and the feedback signal. The underlying as-
sumption, in the digital implementation of a PID algorithm, is that it is executed on a
periodic basis. When the measurement is lost, the PID continues to use the last output
data. The output will go on to move based on the error of the last data received and
the actual reference. When later a new measurement gets through, the derivative action
may produce a spike in the output. If, instead, the control is only executed when a new
data is communicated (event-driven case), then this could delay the control response to
the setpoint changes and feedforward action on measured disturbances. In this solution is
considered a reset contribution, Treset, in the integrate part and a rate contribution, ∆T ,
in the derivative part. The digital implementation of the integral part of the improved
PID is:
Ik = Ik−1 + (uk−1 − Ik−1)(1− e−∆T
Treset ) (6.17)
where:
Ik is the new output of the integrate part.
Ik−1 is the output of the integrate part at the last execution.
uk−1 is the controller output for the last execution.
∆T is the elapsed time since a new value was communicated.
Treset is the reset contribution.
70
6.4. Different approaches to the problem of packet loss
The derivative part is:
Dk = KDek − ek−1
∆T(6.18)
where:
Dk is the new output of the derivative part
ek is the current error.
ek−1 is the error for the last execution.
∆T is the elapsed time since a new value was communicated.
When no packets are lost, ∆T is equal to the period and the behavior of this PID is the
same of the standard one. During the loss instead, the derivative contribution is smaller.
The results obtained using this technique or a standard PID are shown in [6].
6.4.3 Results
Here are presented the results obtained using the previous solutions ( uk = 0, uk =
uk−1, yk = yk−1 and the Luenberger observer) and the improved PI controller described
in the section 6.4.2 (the derivative part has not been used).
The simulation has been done using the modified TrueTime (see Section 5). A fixed pack-
ets lost sequence has been used to be able to compare in a easy way the results. The
moments in which the packets are lost, have been chosen considering the reference signal
that in this simulation is a square wave. It is possible to see how the various solutions and
the plants considered react loosing 3, 4 and 5 packets in different conditions. 3 packets are
lost when the reference is high (t = 75s), 4 when the reference passes from the low level
to the higher one (t = 120s) and 5 when it goes down again (t = 150s). This represents
a kind of worst case scenario. In fact, the loss of more than 3 packets, consecutively and
just when the reference is changing rapidly, is a very unlucky situation.
71
6.4. Different approaches to the problem of packet loss
The plants considered are:
Stable first-order system
G(s) =0.25
2s + 1(6.19)
Integrating system
G(s) =0.25s
(6.20)
These type of models have been chosen because many industrial plants can be approxi-
mated as one of these. The wireless protocol used for the simulation is WirelessHART.
The scheduling of the tasks (see Fig. 6.18) follows the specification of a controller like the
AC800M (see Sec. 6.3).
Figure 6.18: Communication schedule
The simulations have been made using only one loop, but in the wirelessHART superframe
is left the space to add more loops. In this way, the behavior of a big plant with several
independent loops can be considered, but implementing and studying only one of these.
The tuning of the parameters of the PI has been done following the lambda tuning rules
(see Sec. E). In the first order case Treset = 2, instead in the integrating case Treset = 6.5.
In the simulation in which the Luenberger observer is used, the eigenvalues of (A − LC)
have been placed considering the pole of the systems. In the first order case it is obtained
l1 = 0.56 and l2 = 2.4, in the integrating case l1 = 0.9 and l2 = 0.8. These values have
been found using the MATLAB function place.
Consider the figure 6.19. The basic case is the one that shows the standard behavior of
the loop without any packets lost.
72
6.4. Different approaches to the problem of packet loss
Figure 6.19: Results using various methods: reference response.
Figure 6.20: Results using various methods: disturbance rejection.
73
6.4. Different approaches to the problem of packet loss
As it is possible to notice the best results are given by using the observer or assuming
uk = uk−1. Using instead yk = yk−1, some peaks are introduced. Re-doing the simulation,
but considering a reference equal to zero and a disturbance on the control signal modelled
like the same square wave used before as reference, it is possible to notice (see Fig. 6.20)
that all the methods have, more or less, the same rejection ability. An exception is the
uk = 0 case whose performance is really bad.
Considering, moreover, a white noise on the measurements ( ≈ 10% of the output signal),
see Fig. 6.21, and the same disturbance on the control signal, it is possible to come to
the same conclusions. All the methods have, more or less, the same behavior, but not the
uk = 0 case.
Figure 6.21: Results using various methods: disturbance rejection and noise on the output
value.
74
6.4. Different approaches to the problem of packet loss
6.4.4 Multi-Hop
The last solution presented is the possibility to have multi-hop. Consider the case in
which, for example, a message sent by the device A to the device B is lost. A can decide
to try to send the data via a third device C (see Fig. 6.22).
Figure 6.22: Multi-hop.
The node A is able to understand if a message is lost because it will not receive an
acknowledge signal by B. Attaching a special flag to each packet in which it is specified
the final destination device, the node C may try to send it to the final device, in this case
B.
An example, where this method is used , is presented here. The simulation has been done
using the modified TrueTime simulator (see Sec. 5). The communication protocol chosen
is wirelessHART. The scenario is the same as the one described in figure 6.14, but with 5
nodes ( 2 sensors, 2 actuators, 1 gateway). There are two identical plants to control.
The two loops have in common the gateway and the controller (see Fig. 6.23).
Figure 6.23: Multi-hop.
75
6.4. Different approaches to the problem of packet loss
The scheduling used to initialize wirelessHART is:
S1 -> GW S1 ->A1 A1 -> GW GW->A1 GW -> A2
- S2 -> GW - - -
Table 6.2: Example of transmissions schedule using different channels and multi-hop.
From this scenario it is possible to notice that sensor1 uses the actuator1 node to reach
the gateway. Using the multi-channel option (see chapter 3), in the second slot, the first
and the second sensor are able to transmit at the same time, making it possible to have
a smaller superframe. The controller runs two tasks, one for each loop. The one relative
to the first loop executes between the third and the fourth slot assuming that the new
data is ready. The second task computes during the fourth slot. Both the controller tasks
implements the same PD controller tuned on the plant using a trying and error method.
The model of the plants is the following:
G(s) =50
s(25s + 1)(6.21)
It is a motor model used in one of the examples presented by the creators of the original
TrueTime. Here it has been modified a bit in such a way to have a slower time constant.
This is because, having decided to implement the simulation using wirelessHART, it was
not possible to have a shorter sample time. The figure 6.24 shows the behavior of the two
output signals.
The simulation is made using the fixed packets lost utility in such a way to have the same
number of packets lost in both the loops. The first loop, in which the sensor tries another
hop if the communication is lost, works better than the second one in which, if a packet
is lost, the old control signal is used.
76
6.5. Boliden Plant: a case study
Figure 6.24: The performace using or not the multi-hop
6.5 Boliden Plant: a case study
This section deals with level control of flotation tanks at the Boliden plant in Garpenberg.
The aim of the section is to simulate and test the possibility to control the level of the
flotation tanks using a wireless network, instead of the wired network that is used today.
6.5.1 Description of the flotation process
There are four main steps in the procedure of extracting the value mineral from the ore
[23]:
• crossing;
• grinding;
• flotation;
• dewatering;
All the four steps are important but the flotation one plays a fundamental role for the
overall result of the procedure. Flotation is a separation technique used widely in the min-
erals industry, for paper, de-inking, and water treatment amongst others. The technique
relies upon differences in the surface properties of different particles to separate them. The
77
6.5. Boliden Plant: a case study
particles that are to be floated are rendered hydrophobic by the addition of the appropri-
ate chemicals. Air is then bubbled through the mixture and the desired particles become
attached to the small air bubbles and move to the surface where they accumulate as a
froth. The flotation process is widely used for processing of sulphide minerals (copper,
lead, zinc, nickel, cobalt etc...). At the Boliden ore concentration plant the pulp (crude
ore in water) is ground to a fine grained slurry and mixed with frothing reagents and
collecting reagents. When air is blown through the mixture activated mineral particles
cling to the bubbles, which rise to form a froth on the surface.
6.5.2 The pulp level control problem
As described in the previous section, in the flotation process, the pulp flows into tanks
where air is blown to separate the desired minerals from the ore. By means of adjusting
the pulp level, froth, which contains the value minerals, is made to flow over the edge of
the flotation cell for further concentration. It is then important to maintain correct and
stable pulp levels in the tanks to assure that a sufficient part of valuable froth will flow
out from the cells without causing pulp to follow the stream.
Model of the pulp tanks process
The model for the tanks process is illustrated in figure 6.25. In this figure only the parts
important from a control point of view have been included.
Figure 6.25: Model of the tanks process
As is shown in figure 6.25 there are five tanks with a volume of 40m3 and an area of 11m2.
The nominal input flow of the first tank is q = 5m3/min = 560m3/s . The first two tanks
78
6.5. Boliden Plant: a case study
are at the same height and are directly connected by a pipe. The second tank is connected
via a valve to the third tank which is 1 meter lower. In the same way the third tank is
connected using a valve to the last couple of tanks that are 1 m below. Considering the
principle of communicating vessels, hence assuming the same pulp level in the tanks at
the same height, it is possible to obtain the simplified model shown in figure 6.26.
Figure 6.26: Simplified model of the tanks process
In this simplified model the tanks at the same height have been unified into a tank with a
double volume of 80m3 and a double area of 22m2. The principle of communicating vessels
could be applied only if the liquid in the tanks has the same density. In this case the tanks
may have different density because the flotation process has different effects in the two
tanks. The difference between the densities is, anyway, not too relevant, so it is possible
to assume them equal. Another thing that has not been taken into account in this model
is relative to the dynamic of the two tanks. In fact in the original model the input flow
has not an immediate effect in the level of the second tank but the variation happens with
a certain delay. Anyway the simplification could be considered reasonable for the aim of
this work. In the model in figure 6.26 the levels in the tanks are denoted with y1, y2 and y3
and are the process outputs. The control signals u1, u2 and u3 are the commands to the
valves. These values are the opening percentage of the valves (0 < ui < 100, i = 1, 2, 3).
The controls values along with the input flow into the first tank, denoted q, are the system
inputs. The dynamic equations of the system have been obtained considering the input
and the output flow in each tank.
79
6.5. Boliden Plant: a case study
In fact, considering the Torricelli’s principle is possible to obtain the following nonlinear
differential equation [22]:
y1 =1
A1(q −K1u1
√y1 − y2 + h1)
y2 =1
A2(K1u1
√y1 − y2 + h1 −K2u2
√y2 − y3 + h2)
y3 =1
A3(K2u2
√y2 − y3 + h2 −K3u3
√y3 + h3)
(6.22)
here Ai i = 1, 2, 3 are the areas of the tanks (in this case A1 = A3 = 22m2 and A2 = 11m2)
hi i = 1, 2, 3 are the difference of height between succeeding tanks (h1 = h2 = 1 and
h3 = 0). Ki i = 1, 2, 3 are the valves coefficients, that have been obtained considering
the situation in which the system works after the transient period. Hence, assume that
the tanks have been filled and the levels have reached the reference value (in this case
y1 = y2 = y3 = 3m). This means y1 = y2 = y3 = 0 and y1 − y2 = y2 − y3 = 0. Taking
into account these values and considering the valves opened at 50%, when the tanks have
reached the levels, the equations 6.24 becomes:
0 =1
A1(
560−K150
√1)
0 =1
A2(K150
√1−K250
√1)
0 =1
A3(K250
√1−K350
√3)
(6.23)
and the valves constants follow as :
K1 =5
300= 0.0167
K2 =5
300= 0.0167
K3 =5
300√
3= 0.0096
(6.24)
80
6.5. Boliden Plant: a case study
6.5.3 Boliden Plant: simulation
Using MATLAB Simulink and the modified TrueTime, it is possible to implement a sim-
ulation of the system described previously in this section and study how the possibility of
an intermittent communication loss, can affect its behavior. Figure 6.27 shows how the
plant has been implemented.
Figure 6.27: The Simulink−TrueTime model of the Boliden plant
Considering the slow dynamic of the plant it is possible to use wirelessHART. The schedul-
ing of the tasks (see Fig. 6.28) follows the specification of a controller like the AC800M
(see Secion 6.3).
Figure 6.28: Communication schedule
81
6.5. Boliden Plant: a case study
Three loops have been considered. The empty slots in the superframe are left because
it is assumed that the same controller has to compute other control actions relative to
other loops presents in the Boliden plant, but not considered in this study. All the loops
are controlled by a specific task, that implements a PI, and are executed in the controller
CPU. The working point chosen is characterized by a pulp level in each tank equal to
3m. The tuning of the controllers has been made following the lambda tuning method (see
Section E), applied on the linearized plant. Considering the three loops decoupled and
following the linearization method explained in section F, the linear model of the plant is:
y1 = −0.0019y1 − 0.0758e−3u1 + 0.045q
y2 = −0.0076y2 − 0.1515e−3u2
y3 = −0.0023y3 − 0.0758e−3u3
(6.25)
The detailed calculations are omitted, but are straight forward following section F.
These equations lead to:
y1(s) = −0.0758s+0.0019e
−3u1 + 0.045s+0.0019q
y2(s) = −0.1515s+0.0076e
−3u2
y3(s) = −0.0758s+0.0023e
−3u3
(6.26)
Considering these equations, the parameters of the PI controllers can be fixed using the
lambda tuning technique.
The values obtained are:
Kc1 = −25 TI1 = 526
Kc2 = −58 TI2 = 131
Kc3 = −30 TI3 = 434
(6.27)
The second tank, being smaller than the other two, needs a quicker controller. Figure 6.29
shows the behavior of the three loops when a step disturbance is added to the in-flow of
the first tank. The step considered passes form 5m3/min to 5.5m3/min at t = 50s. This
value represents a good approximation of the reality, where in fact varying in-flow of the
first tank is the main disturbance.
Considering the possibility to have packets lost ( see Fig. 6.30) and applying the uk = uk−1
solution, it is possible to notice that the performances are not badly affected.
82
6.5. Boliden Plant: a case study
Figure 6.29: The simulation of the Boliden plant
Figure 6.30: The simulation of the Boliden plant with packets lost
In this figure the loss of communication is represented by a signal that passes to the
high level when the network starts to lose packets and returns to the low level when the
communication is re-established. This simulation has been done considering to lose only
few packets consecutively, no more than 10. When few packets are lost, it is not a problem
to use the previous control signal because of the slow dynamic of the system. The figure
83
6.5. Boliden Plant: a case study
6.31 shows that the performances start to be affected by the unreliable communication
only when the loss of communication is in the order of some minutes (in this case the
maximum period of loss of communication is 5 minutes). If this happens, the effects on
the dynamic of the system are still not too severe and the times to reach the references
are almost the same as for the case in which the communication is never lost.
Figure 6.31: The Boliden plant with packets lost, critical situation
It is possible to conclude that the problem of the packets lost does not affect deeply an
application like this and the wireless technology can be applied with all its advantages.
84
Chapter 7
Conclusions and Future Work
7.1 Conclusions
The main aims of this thesis were the implementation of a WirelessHART simulator, the
analysis of the packet loss problem and the study of the possible use of a wireless network
in a mining flotation plant. Regarding the first point, a simulator has been implemented
using some C++ functions with corresponding MATLAB MEX-interfaces. In this way the
network simulation could be done in an easy way in the Simulink environment and in the
same time the use of C++ instead of the Matlab code makes the simulation faster. The
WirelessHART network is easy to configure using the modified TrueTime library and the
new wireless block mask that is very useful permitting to set all the parameters necessary
for the WirelessHART protocol. Moreover the functionalities that have been added, like
the time correlation in the interferences and the fixed packet loss function make this
network simulator a very complete tool for the analysis of the networked control systems.
About the study of packets lost, the results shows that, with the prediction of the lost data,
it is possible to increase, a little bit, the performance but what is gained in performance
is lost in complexity. In fact to implement this kind of solution a good knowledge of the
system is required. In the real plants it is not always possible to have a good model of
the system and also, assuming that the model is correct, the disturbances could affect the
system in a unpredictable way, making the prediction useless. Considering this, for the
kind of systems analyzed in this thesis, a good trade-off between the complexity of the
85
7.2. Future work
method and the performance of the control is to use the previous value of the control signal
when a packet is lost. In any case the nodes of the network have to be placed considering
the noise in the environment and trying to build the optimized deployment of the node
in relation to the interferences. A reasonable idea for the future could be to dedicate
its own frequency band to the networked control systems. In fact the 2.4GHz ISM radio
band is too crowded and in the future more and more protocols and transmission could be
joined to this band. Another important thing to notice is that one critical period to lose
communication is during a set point change. A reasonable idea, thinking of a real plant,
is to not permit the operator to change the set point if the communication between the
devices is lost. Regarding the tests of the wirelessHART network in the flotation plant
it is clear from the tests, that the loss of communication for few minutes is not a critical
problem, thanks to the slow dynamic of that process. A thing to notice is that actually the
system is over-sampled, this is not a real problem for a wired solution but for a wireless
network the power consumption has to be taken into account. To decrease the power
consumption it should be possible to use a longer sample period; maybe a WirelessHART
superframe of 2 or 3 seconds instead of 1 s. Anyway the very slow dynamic of the system
makes the problem of lost packets a small problem in controlling this particular process.
7.2 Future work
One of the main tasks for the future is to investigate more deeply other kinds of systems,
maybe systems that have an oscillatory step response. In that case some smart predictors
could have better performances compared with using the last control signal.
Regarding the implementation of the simulator more utilities could be added. One in-
teresting task is the implementation of a network manager that can interact with the
controller and the gateway. Now the schedule of the WirelessHART superframe is fixed at
the beginning and it cannot be changed during the simulation. A benefit of changing the
superframe is, for example, the possibility to change the schedule of the communication if
the network manager realizes that a communication path does not work anymore due, for
example, to interferences in the channel.
86
7.2. Future work
Last but not least, another task to consider is to deeply investigate the potential of us-
ing multi-hop communication and shared slot in the the Wireless HART communication
schedule. In fact, if one path is affected by the interference the packets will be lost but the
possibility to use another path to reach the receiver could be a good solution. The only
problem is the constraint introduced by the WirelessHART superframe and by the way
in which the multi-hop has been defined in WirelessHART. In fact to do multi-hop more
slots have to be used (one slot for each hop). If in the process there are several loops the
slots dedicated to the multi-hop cannot be so many.
87
Appendix A
How to install the tool
A.1 Software Requirements
TrueTime currently supports Matlab 7.x (R14 and later) with Simulink 6.x and Matlab
6.5.1 (R13.1) with Simulink 5.1. Support for Matlab 6.1 (R12.1) with Simulink 4.1 was
dropped in TrueTime 1.3.
A C++ compiler is required to run TrueTime in the C++ version. For the Matlab ver-
sion, pre-compiled files are provided in the archive that is downloaded from the TrueTime
web site. The following compilers are currently supported (it may, of course, also work
using other compilers):
• Visual Studio C++ 7.0 (for all supported Matlab versions) for Windows
• gcc, g++ - GNU project C and C++ Compiler for LINUX and UNIX
A.2 Installation
Download and extract the compressed archive (truetime-1.5.zip), available at
http://www.control.lth.se/truetime
Extracting the file creates a truetime-1.5 directory, which will be referred to as $DIR in
the sequel.
Before starting Matlab, you must set the environment variable TTKERNEL to point to
the directory with the TrueTime kernel files, $DIR/kernel. This is typically done in the
following manner:
• Unix/Linux: export TTKERNEL=$DIR/kernel
88
A.3. Compilation
Figure A.1: The TrueTime 1.5 block library.
• Windows: use Control Panel / System / Advanced / Environment Variables
Then add the following lines to your Matlab startup script. This will set up all necessary
paths to the TrueTime kernel files.
addpath([getenv(’TTKERNEL’)])
init_truetime;
Starting Matlab and issuing the command
>> truetime
from the Matlab prompt will now open the TrueTime block library, see Figure A.1.
A.3 Compilation
Since the TrueTime archive contains pre-compiled files, no compilation is required to run
TrueTime with the M-file API.
However, TrueTime also supports simulations written in C++ code, which then must be
compiled. In this case, you first need to configure your C++ compiler in Matlab. This
can be done by issuing the command
>> mex -setup
In the setup, make sure that you change from the Matlab default compiler to a proper
C++ compiler. For more detailed instructions on how to compile individual simulations,
see Section B.4 in this manual.
89
Appendix B
How to use the Simulator
B.1 Introduction
This appendix describes the fundamental steps in the creation of a TrueTime simulation.
This include how to write the code that is executed during simulation, how to configure
the kernel and network blocks, and what compilation that must be performed to get an
executable simulation. The code functions for the tasks and the initialization commands
may be written either as C++ functions or as Matlab M-files. The TrueTime blocks
are connected with ordinary Simulink blocks to form a real-time control system. Before
a simulation can be run, however, it is necessary to initialize kernel blocks and network
blocks, and to create tasks, interrupt handlers, timers, events, monitors, etc for the simu-
lation. As mentioned above, the initialization code and the code that is executed during
simulation may be written either as Matlab M-files or as C++ code (for increased sim-
ulation speed). How the code functions are defined and what must be provided during
initialization will be described below. It will also be described how the code is compiled
to executable Matlab code.
B.2 Writing Code Functions
The execution of tasks and interrupt handlers is defined by code functions. A code function
is further divided into code segments according to the execution model shown in Figure B.1.
All execution of user code is done in the beginning of each code segment. The execution
time of each segment should be returned by the code function.
90
B.2. Writing Code Functions
Figure B.1: The execution of user code is modeled by a sequence of segments executed in
order by the kernel.
B.2.1 Writing a Matlab Code Function
The syntax of a Matlab code function implementing a simple P-controller is given by
Listing B.1. The variable segment determines which segment that should be executed,
and data is a user-defined data structure that has been associated with the task when it
was created (see ttCreateTask and ttCreatePeriodicTask in the command reference).
The data is updated and returned by the code function. The code function also returns
the execution time of the executed segment.
Table B.1: Example of a P-controller code function written in Matlab code.
function [exectime, data] = Pcontroller(segment, data)
switch segment,
case 1,
r = ttAnalogIn(1);
y = ttAnalogIn(2);
data.u = data.K * (r-y);
exectime = 0.002;
case 2,
ttAnalogOut(1, data.u);
exectime = -1; % finished
end
In this example, the execution time of the first segment is 2 ms. This means that the
delay from input to output for this task will be at least 2 ms. However, preemption from
higher priority tasks may cause the delay to be longer. The second segment returns a
91
B.2. Writing Code Functions
negative execution time. This is used to indicate end of execution, i.e. that there are no
more segments to execute. ttAnalogIn and ttAnalogOut are real-time primitives used to
read and write signals to the environment. Detailed descriptions of these functions can be
found in the command reference at the end of this manual.
Table B.2: The C++ version of the code function in Listing B.1.
double Pcontroller(int segment, void* data) {
Task_Data* d = (Task_Data*) data;
switch (segment) {
case 1:
double r = ttAnalogIn(1);
double y = ttAnalogIn(2);
d->u = d->K*(r-y);
return 0.002;
case 2:
ttAnalogOut(1, d->u);
return FINISHED; // end of execution
}
return FINISHED; // to supress compiler warnings
}
B.2.2 Writing a C++ Code Function
Writing a code function in C++ follows a similar pattern as the code function described
in Listing B.1. The corresponding C++ syntax for the P-controller code function is given
in Listing B.2. We here assume the existence of a data structure Task Data that contains
the control signal u and the controller gain, K.
B.2.3 Calling Simulink Block Diagrams
In both the C++ and m-file cases, it is possible to call Simulink block diagrams from within
the code functions. This is a convenient way to implement controllers. Listing B.3 shows
an example where the discrete PI-controller in Figure B.2 is used in a code function. See
the command reference at the end of this manual for further explanation of the command
ttCallBlockSystem.
92
B.2. Writing Code Functions
Figure B.2: Controllers represented using ordinary discrete Simulink blocks may be called from
within the code functions. The only requirement is that the blocks are discrete with the sample
time set to one.
Table B.3: Simulink block diagrams are called from within code function using the TrueTime
function ttCallBlockSystem.
function [exectime, data] = PIcode(segment, data)
switch segment,
case 1,
inp(1) = ttAnalogIn(1);
inp(2) = ttAnalogIn(2);
outp = ttCallBlockSystem(2, inp, ’PI_Controller’);
data.u = outp(1);
exectime = outp(2);
case 2,
ttAnalogOut(1, data.u);
exectime = -1; % finished
end
93
B.3. Initialization
B.3 Initialization
Initialization of a TrueTime kernel block involves specifying the number of inputs and
outputs of the block, defining the scheduling policy, and creating tasks, interrupt handlers,
events, monitors, etc for the simulation. This is done in an initialization script for each
kernel block. The initialization script can (in the Matlab case) also take an optional
parameter to limit the number of similar code functions. The other TrueTime kernel
block parameters are described in Section 4.1.1.
In the examples given below, the initialization script is called example init, both in the
Matlab and C++ cases. The optional parameter is called argument when it is used.
B.3.1 Writing a Matlab Initialization Script
The initialization code in Listing B.4 shows the minimum of initialization needed for a
TrueTime simulation. The kernel is initialized by providing the number of inputs and
outputs and the scheduling policy using the function ttInitKernel.
Table B.4: Example of a TrueTime initialization script in the Matlab version. The kernel
is initialized using the function ttInitKernel, and a periodic task is created that uses the P-
controller code function from Listing B.1. The period of the controller is passed to the initialization
script as a parameter.
function example_init(initarg)
ttInitKernel(2, 1, ’prioFP’);
data.u = 0;
data.K = 2;
offset = 0;
period = initarg;
prio = 5;
ttCreatePeriodicTask(’ctrl’, offset, period, prio, ’Pcontroller’, data);
A periodic task is created by the function ttCreatePeriodicTask. The period of the
task is given by the init argument of the TrueTime Kernel block dialogue. (Note that
the init argument may be an arbitrary Matlab struct.) This task uses the code function
94
B.3. Initialization
Pcontroller that was defined in Listing B.1. See the command reference for further ex-
planation of the functions. In the Matlab case, you may experience that nothing changes
in the simulations, although changes are being made to the code functions or the initial-
ization script. If that is the case, type the following at the Matlab prompt
>> clear functions
To force Matlab to reload all functions at the start of each simulation, issue the command
(assuming that the model is named mymodel)
>> set_param(’mymodel’, ’InitFcn’, ’clear functions’)
B.3.2 Writing a C++ Initialization Script
An initialization script in C++ must follow a certain format given by the template in
Listing B.5.
Table B.5: Template for writing initialization scripts in C++. The final script is actually a
complete Matlab S-function, since the included file, ttkernel.cpp, contains the Simulink callback
functions that implement the kernel.
#define S_FUNCTION_NAME filename
#include "ttkernel.cpp"
// insert your code functions here
void init() {
// perform the initialization
}
void cleanup() {
// free dynamic memory allocated in this script
}
The included file ttkernel.cpp contains the Simulink callback functions that implement
the TrueTime kernel, meaning that the initialization script is actually a complete Matlab
95
B.4. Compilation
S-function. filename should be the name of the source file, e.g. if the source file is called
example init.cpp, S FUNCTION NAME should be defined to example init.
The init()-function is called at the start of simulation (from the Simulink callback func-
tion mdlInitializeSizes), and it is here all initialization should be performed. Any dy-
namic memory allocated from the init()-function can be deallocated from the cleanup()-
function, which is called at the end of simulation. The initial argument supplied in the
TrueTime Kernel block dialogue can be retrieved using the function ttGetInitArg. The
C++ version of the Matlab initialization script of Listing B.4 is given in Listing B.6.
B.4 Compilation
Compilation requires that a proper C++ compiler has been configured in Matlab as de-
scribed in Section A.3. If needed, the TrueTime kernel may be re-compiled by issuing
the command
>> make_truetime
from the Matlab prompt. This script compiles the kernel and network S-functions and the
MEX-files for the TrueTime primitives.
In the C++ case, the initialization script (example init.cpp in the example from the
previous section) must be compiled to produce a Matlab MEX-file for the simulation.
This is done by the command
>> ttmex example_init.cpp
The initialization file needs to be recompiled each time changes are made to the code
functions or to the initialization functions.
Note: The ttmex command is the same as the ordinary mex command but includes
the path to the kernel files (ttkernel.cpp) automatically.
96
B.4. Compilation
Table B.6: Example of a TrueTime initialization script in the C++ version. Corresponds to the
Matlab version from Listing B.4.
#define S_FUNCTION_NAME example_init
#include "ttkernel.cpp"
#include "Pcontroller.cpp" // P-controller code funtion
class Task_Data {
public:
double u;
double K;
};
Task_Data* data; // pointer to local memory for the task
void init() {
mxArray *initarg = ttGetInitArg();
ttInitKernel(2, 1, prioFP);
data = new Task_Data;
data->u = 0.0;
data->K = 2.0;
double offset = 0.0;
double period = mxGetPr(initarg)[0];
double prio = 5.0;
ttCreatePeriodicTask("ctrl", offset, period, prio, Pcontroller, data);
}
void cleanup() {
delete data;
}
97
Appendix C
Examples
C.1 Introduction
This appendix presents some examples of different control loops that can be tested with
TrueTime and its new functions. In the first example will be described a simple loop in
which a system is controlled using a sensor, an actuator and controller that communicate
through a wireless network. The second shows how to control two different loops using
sensors, actuators and a controller with wirelessHART, using once shared slots and once
multi-hop strategy. The last example introduces a simple strategy to compensate the
packets loss problem. More examples are described in [5].
98
C.2. Control of a loop with three nodes
C.2 Control of a loop with three nodes
The following example explains how to build up a control loop with a sensor, an actuator
and a controller that communicate through a wireless network (Fig. C.1). The sensor
will send the measurement of the system output to gateway. This will send the data to
the controller, through a wire, that will send the control message to the actuator passing
again by the gateway.
Figure C.1: Example: A control loop with 3 nodes.
The first step is to write the init file of each task. If wirelessHART is to be used for the
simulation, in each init file must be defined a matrix that represents the communication
table of the corresponding device ( see Section 3.4.2). The others init file will be similar
to that one and so is not useful to show also them.
99
C.2. Control of a loop with three nodes
Table C.1: Example of a TrueTime initialization script in the Matlab version.
function gateway_init
//
// Distributed control system: controller node
// Receives messages from the sensor node, computes control signal
// and sends it back to the actuator node.
// Initialize TrueTime kernel
ttInitKernel(1, 1, ’prioFP’); % nbrOfInputs, nbrOfOutputs, fixed priority
ttCreateMailbox(’sensor1_signal’, 10) // Create mailboxes
// Controller parameters
data.yold = 0.0; deadline = 0.01;
prio =1; data.y = 0;
offset =0.002; period = 0.01;
// Stucture for MAC
data.table=[1 1]’; % frameID
for i=1:length(data.table) timeslot(i)=i; end choffset=[1 1]’;
devaddress=[1 3]’; //node i sensor, node 2 gateway,node 3 actuator
linkopt=[ 0 1 ]’; // 0 if RX 1 if TX
linktype=[0 0]’;
data.table=[data.table timeslot’ choffset devaddress linkopt
linktype];
offset = 0.0025;
ttCreatePeriodicTask(’gatewayRX_task’,
offset, period, prio, ’gatewayRX’, data);
period =0.01;
offset=0.006;
ttCreatePeriodicTask(’gatewayTX_task’, offset,
period, prio, ’gatewayTX’, data);
// Initialize network
ttCreateInterruptHandler(’nw_handler’, prio, ’msgRcv2’);
ttInitNetwork(2, ’nw_handler’); // node #1 in the network
100
C.2. Control of a loop with three nodes
To understand how to use the ttMAC function is useful to give a look to the sensor code
task (Listing C.2):
Table C.2: Example of a sensor code.
function [exectime, data] = sens1code(seg, data)
switch seg,
case 1,
data.msg.msg = ttAnalogIn(1);
if data.msg.msg==0
data.msg.msg=data.y;
end
exectime = 0.0005;
case 2,
eps = 0.0004;
MAC=ttMAC(0,data.table,2,eps,1);
if(MAC==1)
data.msg.type = ’sensor1_signal’;
ttSendMsg(2, data.msg, 80); % Send message (80 bits) to node 2 (controller)
end
exectime =eps;
case 3,
exectime = -1; % finished
end
As is possible to see, after having called the ttMAC function, an if statement decides the
transmission of the packet. In the same way the actuator will understand if the packet
is received or not. If the user wants to change the MAC protocol into Wlan or ZigBee,
it will be useless to define the tables and call ttMAC where a packet is received. The
transmitting device must, instead, call the ttMAC function with 1 or 2 as first argument.
101
C.3. 5 nodes with multi-hop
function [exectime, data] = act1code(seg, data)
switch seg,
case 1,
eps=0.0005;
MAC=ttMAC(0,data.table,2,eps,3);
if(MAC==0)
% Read all buffered packets
temp = ttTryFetch(’control1_signal’);
if temp~=0
while ~isempty(temp),
data.u = temp;
temp = ttTryFetch(’control1_signal’);
end
else
data.u = data.uold;
end
else
data.u=data.uold; % if no new data, use the last.
end
data.uold=data.u;
exectime =eps;
case 2,
ttAnalogOut(1, data.u)
exectime = -1; % finished
end
C.3 5 nodes with multi-hop
In these example two identical loops are considered. They have in common only the
controller that will generate a control task for each loop.
This example introduces a new possibility for the propagation of the messages. In that
102
C.3. 5 nodes with multi-hop
Figure C.2: Example: Two control loops.
case, in fact, if the message is lost during the hop from the sensor 1 to the gateway, it will
be transmitted in the next slot to the actuator 1 and later, in another slot, again from
here to the gateway. This need a longer frame size than the previous example. At the
same time, according to wirelessMAC rules, is possible to use a different channel to let
the sensor 2 communicates with the gateway.
The schedule scheme is:
S1 -> GW S1 ->A1 A1 -> GW GW->A1 GW -> A2
- S2 -> GW - - -
Table C.3: Example of transmissions schedule using different channels and multi-hop.
To do it, the tables should have the following values:
%gateway table:
frameID=[1 1 1 1 1]’;
timeslot=[1 2 3 4 5];
choffset=[1 2 1 1 1]’;
devaddress=[1 4 3 3 5]’;
linkopt=[ 0 0 0 1 1]’; %% 0 if RX 1 if TX
linktype=[0 0 0 0 0]’; %% 0 if normal, 1 if advertise, -1 shared
103
C.4. 5 nodes with a shared slot
%sensor 1 table:
frameID=[1 1]’;
timeslot=[1 2]’;
choffset=[1 1]’;
devaddress=[2,3]’;
linkopt=[1 1]’;
linktype=[0 0]’; %% 0 if normal, 1 if advertise, -1 shared
%sensor 2 table:
frameID=[1]’;
timeslot=[2]’;
choffset=[2]’;
devaddress=[2]’;
linkopt=[1]’; %% 0 if RX 1 if TX, -1 RX shared
linktype=[0]’; %% 0 if normal, 1 if advertise, -1 shared
C.4 5 nodes with a shared slot
In these example is presented a case with two identical loops that have in common only
the controller. It will generate a control task for each loop. The schedule scheme is:
S1 -> GW GW ->A1 S1 -> GW GW -> A2
- - S2 -> GW -
Table C.4: Example of transmissions schedule using shared slot.
The third slot is a shared slot. Both the sensor 1 and the sensor 2 try to transmit to the
gateway but only one will win the contention.
104
C.4. 5 nodes with a shared slot
The other will wait a back-off number of slots before to transmit again on a shared slot
(see Section 3.3.3). In that case the tables of the devices must be written in this way:
%gateway table:
frameID=[1 1 1 1]’;
timeslot=[1 2 3 4]’;
choffset=[1 1 1 1]’;
devaddress=[1 3 -1 5]’;
linkopt=[ 0 1 0 1]’; %% 0 if RX 1 if TX
linktype=[0 0 -1 0]’; %% 0 if normal, 1 if advertise, -1 shared
%sensor 1 table:
frameID=[1 1]’;
timeslot=[1 3]’;
choffset=[1 1]’;
devaddress=[2,2]’;
linkopt=[1 1]’; %% 0 if RX 1 if TX
linktype=[0 -1]’; %% 0 if normal, 1 if advertise, -1 shared
%sensor 2 table:
frameID=[1]’;
timeslot=[3]’;
choffset=[1]’;
devaddress=[2]’;
linkopt=[1]’; %% 0 if RX 1 if TX, -1 RX shared
linktype=[-1]’; %% 0 if normal, 1 if advertise, -1 shared
105
C.4. 5 nodes with a shared slot
Figure C.3: Example: Two control loops and shared slots.
The worse performance of the first loop (Fig. C.3) is due to a less frequent updating of
the measurements. It could be improved by changing the PID parameters, but here were
deliberately left unchanged because the differences were obvious.
106
Appendix D
TrueTime Command Reference
The available TrueTime commands are summarized in Tables D.1–D.3, and the rest
of the manual contains detailed descriptions of their functionality. The commands are
categorized according to their intended use (I; initialization script, T; task code function,
and H; interrupt handler code function). Note that the set and get primitives are collected
under the headings ttSetX and ttGetX, respectively. By typing help command, where
command is the name of a TrueTime function, in the Matlab command window, the
syntax of the various TrueTime functions will be displayed.
Command Description
ttInvokingTask Get the name of the task that invoked a task overrun han-
dler.
ttCallBlockSystem Call a Simulink block diagram from within a code function.
ttSendMsg Send a message over a TrueTime network.
ttGetMsg Get a message that has been received over a TrueTime
network.
ttDiscardUnsentMessages Delete any unsent messages.
ttSetNetworkParameter Set a specific network parameter on a per node basis.
ttSetKernelParameter Set a specific kernel parameter on a per node basis.
Table D.1: Real-time primitives.
107
command Description
ttInitKernel Initialize the kernel.
ttInitNetwork Initialize the network interface.
ttGetInitArg (C++ only) Retrieve the initialization argument.
ttCreateTask Create a task.
ttCreatePeriodicTask Create a periodic task.
ttCreateInterruptHandler Create an interrupt handler.
ttCreateExternalTrigger Associate a interrupt handler with an external interrupt channel.
ttCreateMonitor Create a monitor.
ttCreateEvent Create an event.
ttCreateLog Create a log structure and specify data to log.
ttCreateMailbox Create a mailbox for inter-task communication.
ttCreateSempahore Create a counting semaphore.
ttNoSchedule Switch off the schedule generation for a specific task or interrupt
handler.
ttNonPreemptable Make a task non-preemptable.
ttAttachDLHandler Attach a deadline overrun handler to a task.
ttAttachWCETHandler Attach a worst-case execution time overrun handler to a task.
ttAttachHook (C++ only) Attach a run-time hook to a task.
ttAbortSimulation Abort the simulation.
ttSetDeadline Set the relative deadline of a task.
ttSetAbsDeadline Set the absolute deadline of a task job.
ttSetPriority Set the priority of a task.
ttSetPeriod Set the period of a periodic task.
ttSetBudget Set the execution time budget of a task job.
ttSetWCET Set the worst-case execution time of a task.
ttSetData Update the local memory data structure of a task.
ttGetRelease Get the release time of a task job.
ttGetDeadline Get the relative deadline of a task.
ttGetAbsDeadline Get the absolute deadline of a task job.
ttGetPriority Get the priority of a task.
ttGetPeriod Get the period of a periodic task.
ttGetBudget Get the execution time budget of a task job.
ttGetWCET Get the worst-case execution time of a task.
ttGetData Retrieve the local memory data structure of a task.
Table D.2: Commands used to create, initialize TrueTime objects, to control the simulation and
used to set and get task attributes.
108
Command Description
ttCreateJob Create a job of a task.
ttKillJob Kill the running job of a task.
ttEnterMonitor Attempt to enter a monitor.
ttExitMonitor Exit a monitor.
ttWait Wait for an event.
ttNotify Notify the highest-priority task waiting for an event.
ttNotifyAll Notify all tasks waiting for an event.
ttLogNow Log the current time.
ttLogStart Start a timing measurement for a log.
ttLogStop Stop a timing measurement and save in the log.
ttTryPost Post a message to a mailbox (non-blocking).
ttTryFetch Fetch a message from a mailbox (non-blocking).
ttPost Post a message to a mailbox (blocking).
ttFetch Fetch a message from a mailbox (blocking).
ttRetrieve Read the actual message fetched from a mailbox.
ttTake Take a semaphore.
ttGive Give a semaphore.
ttCreateTimer Create a one-shot timer and associate an interrupt handler
with the timer.
ttCreatePeriodicTimer Create a periodic timer and associate an interrupt handler
with the timer.
ttRemoveTimer Remove a specific timer.
ttCurrentTime Get and/or set the current time in the simulation on a per
node basis.
ttSleepUntil Sleep until a certain point in time.
ttSleep Sleep for a certain amount of time.
ttAnalogIn Read a value from an analog input channel.
ttAnalogOut Write a value to an analog output channel.
ttSetNextSegment Set the next segment to be executed in the code function
(to implement loops and branches).
Table D.3: Real-time primitives.
To have more details about the syntax and the behavior of these functions see [5].
109
Appendix E
Lambda Tuning rule
In most of the controllers used in this thesis the lambda tuning technique has been used to
tune the parameters of the PI. For that reason a brief overview of the method is introduced
in the following section. The explanation is divided into two parts, one regards the lambda
tuning for a stable first order system and the other regards an integrating process.
E.1 Stable first order system
Consider a stable first order system affected by a general delay Dsys
G(s) =K
Ts + 1e−Dsyss (E.1)
The controller chosen is a PI because of its simplicity. The tuning of the parameters of
the PI can be done following the lambda tuning technique.
This considers a closed-loop of the following form (see Fig. E.1):
Y (s) = G(s)Q(s)R(s) (E.2)
110
E.1. Stable first order system
Figure E.1: Internal model control structure.
Q(s) can be chosen as a plant inverse multiplied by the desired closed loop system
Q(s) = F (s)G(s)−1 (E.3)
where G(s) is an approximation of G(s). From this follows: Y (s) = F (s)R(s).
If the model G(s) is not invertible, then factorize according to G(s) = G−(s)−1G+(s)
where G−(s) contains all invertible parts with G+(0) = 1, and use Q(s) = F (s)G−(s)−1.
Comparing Y (s) with the standard control loop shown in Fig. E.2:
Figure E.2: Standard control loop.
C(s) =Q(s)
1−QG(s)=
1G−(s)
F (s)1− F (s)G+(s)
(E.4)
Hence considering
G−(s) =K
Ts + 1, G+(s) = e−Dsyss, F (s) =
1λs + 1
(E.5)
111
E.2. Integrative process
leads to
C(s) =Ts + 1
K
1λs + 1− e−Dsyss
(E.6)
Approximating the deadtime by a first order Taylor series expansion e−Dsyss ≈ (1−Dsyss)
yields:
C(s) =Ts + 1
K(λ + Dsys)s(E.7)
which is clearly a PI controller.
Comparing it with
C(s) = KcTIs + 1
TIs(E.8)
it is easy to obtain
TI = T, Kc =TI
K(λ + Dsys)=
T
K(λ + Dsys)(E.9)
where λ is the desired close loop time constant. Following these rules is possible to tune
the controller parameters taking into account the delay of a system.
E.2 Integrative process
Consider an integrating system affected by a general delay Dsys:
G(s) =K
se−Dsyss (E.10)
This system is not stable. The controller chosen can be, also in this case, a PI. Approxi-
mating the dead-time by a first order Taylor series expansion:
Y (s) =C(s)G(s)
1 + C(s)G(s)=
(TIs + 1)(1−Dsyss)( TI
kvKc − TIDsys)s2 + (TI −Dsys)s + 1R(s) (E.11)
112
E.2. Integrative process
Assume desired characteristic equation (λs + 1)2 = λ2s2 + 2λs + 1 which implies the
following parameters
TI = 2λ, Kc =TI
K(λ + Dsys)2(E.12)
where λ is the desired time constant of the closed-loop system.
113
Appendix F
Linearization
Considering the major analysis power of a linear system compared with a non-linear one,
it is often desirable to approximate a non-linear system, f(x, u), with a linear one, f(x, u).
Typically the linearization is done around an equilibrium point or the working point
(x, u, y). It is possible to do the approximation using a Taylor series of the first order:
f(x, u) ≈ f(x, u) + dfdx
∣∣∣(x,u)
(x− x) + dfdu
∣∣∣(x,u)
(u− u)
f(x, u) = y(F.1)
Define:
A =df
dx
∣∣∣∣(x,u)
B =df
du
∣∣∣∣(x,u)
(F.2)
Considering x = x− x and u = u− u the new state variable:
f(x, u) = Ax + Bu (F.3)
If there is a non-linearity also in the outputs, it is possible to apply the same approximation
on it [25].
114
Bibliography
[1] HART communication foundation , TDMA Data Link Layer , HCF SPEC − 075
Revision 1.0, 30 August 2007.
[2] HART communication foundation , Wireless Devices Specification , HCF SPEC −290 Revision 1.0, 5 September, 2007.
[3] HART communication foundation , Network Management Specification ,
HCF SPEC − 085, Revision 1.0, 27 August, 2007.
[4] J. Song, S. Han, A, K, Mok, D. Chen, M. Lucas, M. Nixon and W. Pratt , Wire-
lessHART: Applying Wireless Technology in Real-Time Industrial Process Control
- 14th IEEE Real-Time and Embedded Technology and Applications Symposium
(RTAS), 2007
[5] M. Ohlin, D. Henriksson and A. Cervin, TRUETIME 1.5-Reference Manual, Depart-
ment of Automatic Control Lund University, January 2007.
[6] J. Song, A. K. Mork, D. Chen, M. Nixon, T. Blevins and W. Wojsznis, Improving
PID Control with Unreliable Communications, ISA EXPO 2006, 17-19 October 2006
[7] D. Chen, M. Nixon, T. Aneweer, A. K. Mok, R. Shepard, T. Blevins and Greg
McMillan, Similarity-Based Traffic Reduction to Increase Battery Life in a Wireless
Process Control Network, ISA EXPO 2005, 26 October 2005
[8] K.J. Astrom and T. Hagglund , PID control - Theory, Design, and Tuning , ISA,
1995
[9] K. J. Astrom and T. Hagglund, Advanced PID control, ISA, 2006
115
BIBLIOGRAPHY
[10] J.P. Hespanha, P. Naghshtabrizi and X. Yonggang, A Survey of Recent Results in
Networked Control Systems, Proceedings of the IEEE Volume: 95, pages 138-162, 1
January 2007
[11] J. Nilsson, Bo Bernhardsson, Bjorn Wittenmark, Department of Automatic Control,
Lund Institute of Technology, Stochastic Analysis and Control of Real-Time Systems
with Random Time Delays , Automatica (Journal of IFAC) archive, Volume 34, pages
57-64, 1 January 1998
[12] A. Ingimundarson and T. HAgglund, Performance comparison between PID and
dead-time compensating controllers, Journal of Process Control, Volume 12, No 8,
pages 887-895, December 2002
[13] T. Keller and J. Modelski, Experimental results of testing interferences in 2.4 ghz ism
band, Proc. 33rd European Microwave Conference, Munich, pages 1043-1046, 2003
[14] J.A. Park, S.K. Park, D.H. Kim, P.D.Cho and K.R. Cho, Experiments on radio
interference between wireless lan and other radio devices on a 2.4 GHz ism band,
57th IEEE Semiannual Vehicular Technology Conference VTC 2003, Volume 3, pages
1798-1801, 2003
[15] M.V.S. Chandrashekhar, P. Choi, K. Maver, R. Sieber and K.Pahlavan, Evaluation
of interference between IEEE 802.11b and bluetooth in a typical office environment,
Proceedings 12th IEEE International Symposium on Personal, Indoor and Mobile
Radio Communications PIMRC 2001, Volume 1, pages D71-D75, 2001
[16] V. E.Makensen and W. Kuntz, Bluetooth ZigBee and nanoNE Comparison of short-
range wireless personal area networks, Elektronik/Automotive Volume 54 part 24
pages 70-77
[17] A.C. Davies, An overview of Bluetooth Wireless TechnologyTMand some competing
LAN Standards, ICCSC 02, pages 206-211, 2002
[18] Norman Abeamson, The ALOHA system - Another alternative for computer commu-
nications, AFIPS Conference Proceedings, Volume 36, pages 295-298, 1970.
[19] A.S. Tanenbaum, Computer Networks, Prentice Hall, Fourth Edition, 2003
116
BIBLIOGRAPHY
[20] A. Willig, K. Matheus, A. Wolisz, Wireless Technology in Industrial Networks, Pro-
ceedings of the IEEE, Volume 93, pages 1130-1151, june 2005
[21] G. Olsson and Christian Rosen, Industrial Automation, Lund Universtity, 2004
[22] B. Stenlund and A. Medvedev, Level control of cascade coupled flotation tanks, Con-
trol Engineering Practice, Volume 10, Issue 4, Pages 443-448, April 2002
[23] B. A. Wills, Mineral Processing technology, Butterworth-Heinemann, 1986
[24] SOCRADES documents, Service-Oriented Cross-layer infRAstructure for Distributed
smart Embedded devices, www.socrades.eu
[25] A. Bicchi, Appunti di Teoria dei Sistemi
[26] S. Mangold, S. Choi and N. Esseling, An Error for Radio Transmitting Of Wireless
LANs at 5GHz, Proc. 10th Aachen Symposium on Signal Theory, pages 209-214,
September 2001
[27] IndustrialIT 800xA - System ( version 5.0), System guide: Technical data and config-
uration information, ABB Automation Technology Products, 2006
[28] IndustrialIT 800xA - Control and I/O (System version 5.0) , Application programming
introduction and design, ABB Automation Technology Products, 2006
[29] R. Tjoa, K.L Chee, P. K. Sivaprasad, S.V. Rao and J.G. Lim, Clock Drift Reduction
for Relative Time Slot TDMA-based Sensor Networks, PIMRC 2004, 15-th IEEE
symposium on Personal, Indoor and Mobile Radio Communications, Volume 2, pages
1042-1047, 5-8 September 2004.
[30] http://www.ZigBee.org
117
