Design of a wirelessHART simulator for studying delay compensation in networked control systems

(1)

Design of a wirelessHART simulator for studying delay compensation in networked control systems

CARLO SNICKARS

Masters’ Degree Project

Stockholm, Sweden February 2008

(2)

List of Figures

1.1 The SOCRADES consortium in Europe. . . 2

2.1 The Open System Interconnection (OSI) model . . . 6

2.2 The amount of data in the Open System Interconnection (OSI) model . . . 7

2.3 The TDMA structure . . . 10

2.4 The Token Bus operating principle . . . 11

2.5 The Token Ring operating principle . . . 11

2.6 Characteristics of the 802 family . . . 18

3.1 HART OSI 7-Layer Model [1]. . . 20

3.2 The structure of a WirelessHART network. . . 20

3.3 The DLPDU structure [1] . . . 22

3.4 The SuperFrame structure [1] . . . 23

3.5 The channel hopping [1] . . . 24

3.6 The communication tables [1] . . . 26

3.7 MAC Algorithm . . . 27

4.1 The TrueTime 1.5 block library. . . 31

4.2 The dialog of the TrueTime kernel block. . . 32

4.3 The dialog of the TrueTime network block. . . 33

4.4 The dialog of the TrueTime wireless network block. . . 35

4.5 The dialog of the ttGetMsg block to the left, and the dialog of the ttSendMsg block to the right. . . 37

4.6 Probability density function for a received symbol when using binary phase shift keying and additive white Gaussian noise. . . 41

(7)

LIST OF FIGURES

5.1 The TrueTime wireless network block with the x,y,z coordinates inputs port that specifies

the true location of the nodes. . . 44

5.2 The wireless network block with the external noise input port. . . 45

5.3 The average and the variance fields in the wireless network block mask . . . 46

5.4 The plot of the lost packets and the consequences in the control performance 47 5.5 The wireless network block with the output port for the packet lost signal . . . 47

5.6 Settings for the fixed packets lost option . . . 48

5.7 The plot of the packets lost and the consequence in the control performance 49 5.8 The parameters setting in the WirelessHart mask . . . 50

5.9 MAC protocol location in TrueTime . . . 50

5.10 MAC protocol location in a real environment . . . 51

6.1 Dead-time . . . 53

6.2 Jitter effect in event driven control. . . 54

6.3 Jitter effect in time driven control. . . 54

6.4 Delay caused by clock drift. . . 55

6.5 Internal model control structure. . . 56

6.6 Standard control loop. . . 57

6.7 The IAE error changing the delay and the system time constant. . . 58

6.8 The IAE error changing the delay and the closed-loop time constant. . . 60

6.9 The PI controller. . . 62

6.10 The PPI controller. . . 63

6.11 The Modified Smith Predictor. . . 64

6.12 The Modified Smith Predictor when d is equal to zero. . . 65

6.13 The integral absolute error for the various methods considering a first order system. . . 66

6.14 The integral absolute error for the various methods considering an integrating system.. . 67

6.15 AC800 typical scenario . . . 68

6.16 Cascade loops . . . 69

6.17 A possible scenario. . . . 69

6.18 Representation of the simulated control system . . . 71

6.19 Communication schedule . . . 71

6.20 WirelessHART parameters . . . 72

(8)

LIST OF FIGURES

6.21 The drift field in the controller kernel block . . . 73

6.22 Reference tracking using the PI controller both with drift and without . . . 74

6.23 The PPI scheme . . . 74

6.24 Comparison of reference tracking between PI and PPI . . . 75

6.25 IAE : PI and PPI controllers . . . 76

6.26 Finite state machine: D=0 no delay, D=1 delay of 1 cycle . . . 77

6.27 Schedule of the tasks and detection of the delay . . . 77

6.28 Scheme of the detection of the delay due to the drift . . . 78

6.29 Detection of the delay due to the drift is one cycle late. . . 78

6.30 Detection of the delay due to the drift improvement . . . 79

6.31 Performance comparison between the hybrid controller, the PPI and the PI. . . . 80

6.32 IAE comparison between the hybrid controller, the PPI and the PI. . . . 80

6.33 Simulink model of the system with input disturbance . . . 81

6.34 System output with disturbance and drift . . . 81

6.35 IAE with disturbance and drift . . . 82

6.36 System output with disturbance, drift and a square wave reference . . . 82

6.37 IAE with disturbance, drift and a square wave reference . . . 83

6.38 System output using PI control with drift and without. . . 84

6.39 Integral Absolute Error using a PI control both with drift and without. . . 84

6.40 The modified Smith predictor for integrating process. . . 85

6.41 Behaviour of the modified Smith predictor in presence of drift compared with the performance of the PI controller. . . . 86

6.42 Integral Absolute Error of the modified Smith predictor in presence of drift compared with the performance of the PI controller. . . . 86

6.43 Behavior of the modified Smith predictor in presence of drift with F=λ. . . 87

6.44 The system output using the hybrid controller compared with a normal PI and the MSP. 88 6.45 IAE of the hybrid controller compared with a normal PI and the MSP. . . . 88

6.46 Behaviour of the hybrid controller in presence of input disturbance for different choice of F. 89 A.1 The TrueTime 1.5 block library. . . 93

B.1 The execution of user code is modeled by a sequence of segments executed in order by the kernel. . . 95

(9)

LIST OF FIGURES

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

C.1 Example: A control loop with 3 nodes. . . 103

C.2 Example: Two control loops. . . 107

C.3 Example: Two control loops and shared slots. . . 110

C.4 Example: Packets lost and prediction. . . 112

(10)

List of Tables

3.1 Example BOCntr Selection Sets . . . 25

3.2 Device Table . . . 28

B.1 Example of a P-controller code function written in Matlab code. . . 95

B.2 The C++ version of the code function in Listing B.1. . . 96

B.3 Simulink block diagrams are called from within code function using the TrueTime function ttCallBlockSystem. . . . 97

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

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

B.6 Example of a TrueTime initialization script in the C++ version. Corresponds to the Matlab version from Listing B.4. . . . 101

C.1 Example of a TrueTime initialization script in the Matlab version. . . . 104

C.2 Example of a sensor code. . . 105

C.3 Example of transmissions schedule using different channels and multi-hop. 107 C.4 Example of transmissions schedule using shared slot. . . 108

D.1 Real-time primitives. . . 114

D.2 Commands used to create, initialize TrueTime objects, to control the simulation and used to set and get task attributes. . . . 115

D.3 Real-time primitives. . . 116

(11)

Chapter 1

Introduction

Wireless technologies are becoming more and more important both in public and in industrial environments. The aim of technique is to remove the constrictions if being attached to expensive and messy cables. The advantages given by wireless technology are several.

First of all, it permits to carry the capability of wired networks to areas that cables cannot reach. Considering industrial plants, wireless technologies can significantly facilitate deployment and reconfiguration by eliminating the need for installing and maintaining cabling, reducing both cost and time. However, the lack of maturity, the failure to provide real-time performance and the lack of reliability metrics comparable to those of wired networks do not help the use of this technology in industrial environments. This thesis work has been made at ABB Corporate Research in Sweden and is part of the SOCRADES European project [22]. One of the main objectives of this project is to specify a new wireless communication architecture that provides the required reliability, safety, security and real-time parameters for wireless sensor networks. The SOCRADES consortium is made up of 15 partners from 6 European countries. It is led by the major European players in the industrial automation sector (Schneider Electric, ABB, ARM, Boliden, FlexLink, APS, SAP, Siemens, Ifak, Jaguar Cars Ltd.) and many European universities (Politecnico di Milano, Loughborough University, TUT, KTH, LTU).

The aims of this thesis work are two. The first one is the implementation of a Wire- lessHART network simulator. WirelessHART is a new wireless protocol that aims to establish a new communication standard for process automation applications [4]. The simulator has been written in C++ and interfaced with MATLAB through a S-function, to have a friendly use of it. The possibility to work with this simulator has been added in

(12)

Figure 1.1: The SOCRADES consortium in Europe.

the TrueTime library giving to the user a very powerful tool to simulate different wireless scenarios. TrueTime has also been improved by other utilities. First of all the possibility to specify the 3D position of the nodes. A port has been added in the wireless network block to permit the use of an external source of noise. An other improvement is give by the possibility of use a deterministic sequence of packets lost, in such a way, to be able to compare different simulations and chose where to fix a loss of information. The second aim of this work is the study of delay compensation in a WirelessHART network. This protocol provides for the synchronization between all the devices of the network. If the controller is not part of the wireless network, no synchronization with the other devices is guaranteed. In this condition, if the controller clock is affected by drift, a varying delay is introduced in the control-loop. This effect degrades the performance desired and, in some critical cases, causes instability to the whole system. To solve this problem many techniques have been considered and compared. A Predictive PI controller and a Modified Smith predictor are the more interesting solutions. The processes considered in this study are a stable first order system and an integrating system. These two models are, in fact, the most commons in industrial environments. The WirelessHART simulator has been used to study this problem. The last part of this document is dedicated to the conclusions and the future work.

(13)

1.1. Outline of the thesis

1.1 Outline of the thesis

The contents of the thesis are as follows:

1.1.1 Chapter 2: Network theory

Industrial communications constitute, today, a fundamental topic for all kind of automation. 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. In this chapter are introduced the OSI model, some different MAC protocol and the IEEE 802 standards.

1.1.2 Chapter 3: WirelessHART

In this chapter the WirelessHART protocol will be described. First, a general introduction to the protocol is given. Later the structure of the MAC is deeply explained, and a more exhaustive description of the communication protocol is given. The chapter is concluded with the description of the implementation of the WirelessHART MAC protocol in a C++

code.

1.1.3 Chapter 4: Introduction to TrueTime

This chapter describes the use of the original Matlab/Simulink-based simulator True- Time, which facilitates co-simulation of controller task execution in real-time kernels, network transmissions (using wired or wireless networks), and continuous plant dynamics. A detailed description of the six blocks that compose the library (the kernel block, the network block, the wireless network block, the battery block the ttSendMsg and the ttGetMsg blocks) is given. The same tool has been modified to permit the use of the WirelessHART protocol and some more utilities have been added.

1.1.4 Chapter 5: New functions in the wireless network block

This chapter contains some new utilities implemented to improve the behavior and the useability of the wireless network block of TrueTime. The 3D position of a node is the first improvement. After that are described the use and the implementation of the external source of noise, the time correlation function and the fixed sequence of packets lost. The last section of this chapter is dedicated to the configuration of WirelessHART in the mask of the wireless network block.

(14)

1.1. Outline of the thesis

1.1.5 Chapter 6: Delay compensation

This chapter introduces how the most common systems in industry can be affected by delay and some possible solutions to overcome this problem. First of all, the problem of delay in a control loop is introduced and its possible sources. After that, it investigates how the performance of a control loop could be influenced by a delay considering some typical industrial systems. Possible solutions that the controller can adopt to improve its performance are investigated. A brief description of the controller AC800M is also given.

The last section deals with the problem of delay due to the clock drift using a controllers like the AC800M in a WirelessHART scenario and proposes some solutions considering different processes.

1.1.6 Chapter 7: Conclusions

The last chapter presents the conclusions of this thesis work. Future work is also discussed.

(15)

Chapter 2

Network theory

Industrial communications constitute, today, a fundamental topic for all kind of automation. 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.

(16)

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.

(17)

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 physical 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 communication 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.

(18)

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.

(19)

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

(20)

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

(21)

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

(22)

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 communication, 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 networking 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 Mbps (3 Mbps 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

(23)

time slots of 625 µs. 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.

(24)

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

(25)

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 environments 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 retransmissions. 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-

(26)

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 [27] 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 networking (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 important 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

(27)

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.

(28)

Figure 2.6: Characteristics of the 802 family

(29)

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 characteristics 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 communication 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

(30)

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.

(31)

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.

(32)

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 control access to the network. TDMA is a widely used Medium Access Control technique

(33)

that provides collision free, deterministic communications. It uses time slots where communications 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 [26]. 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.

(34)

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)

(35)

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

(36)

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 modified TrueTime (see Sec. 5). The WirelessHART MAC protocol has been implemented with some C++ functions with corresponding MATLAB MEX-interfaces. The main function (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

(37)

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

* if the actual slot is not reserved for this device and is not a shared slot

* 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

(38)

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 synchronization. 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 :

(39)

3.4. Implementation

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

(40)

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

(41)

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.

(42)

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

(43)

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 parameters 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

(44)

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 transmission. 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¹a 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.

(45)

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)

(46)

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 _d¹a 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 configured 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.

(47)

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

Design of a wirelessHART simulator for studying delay compensation in networked control systems