Implementation of a wirelessHART simulator and its use in studying packet loss compensation in networked control

simulator and its use in studying packet loss compensation in networked control

MAURO DE BIASI

Masters’ Degree Project Stockholm, 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

spring is sure to follow.

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.

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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.

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.

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.

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

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

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

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 Technology ^{T M} 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 Bl˚ atand, 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

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.

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

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-

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

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.

2.3. The IEEE 802 standards

Figure 2.6: Characteristics of the 802 family

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

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.

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.

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

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.

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 = (2 ^BOExp − 1) (3.1)

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].

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

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

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 :

ActualSlotN umer = ( Actual Sim time + exectime

SlotSize %Superf rameSize) + 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).

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

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.

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

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

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 _d ¹

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.