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

Transcription

1 Design of a wirelesshart simulator for studying delay compensation in networked control systems CARLO SNICKARS Masters Degree Project Stockholm, Sweden February 2008 XR-EE-RT 2008:009

2 Contents 1 Introduction Outline of the thesis Chapter 2: Network theory Chapter 3: WirelessHART Chapter 4: Introduction to TrueTime Chapter 5: New functions in the wireless network block Chapter 6: Delay compensation Chapter 7: Conclusions Network theory The Open System Interconnection model (OSI) The OSI basic structure The Medium Access Control (MAC) protocol ALOHA Carrier Sense Multiple Access Protocols (CSMA) Time Division Multiple Access (TDMA) Token Bus Token Ring The IEEE 802 standards Bluetooth/IEEE IEEE IEEE ZigBee WirelessHART i

3 CONTENTS 3 WirelessHART Introduction A brief view of WirelessHART MAC Protocol Description Data-Link packets(dlpdus) Time Division Multiple Access (TDMA) Shared Slot Communication Tables Implementation MAC Protocol Devices Tables Synchronization of the devices tasks Introduction to TrueTime Description of the tool The TrueTime Kernel The TrueTime Network The TrueTime Wireless Network The TrueTime Standalone Network Blocks The TrueTime Battery Wireless Network Block behaviour b/g (WLAN) (ZigBee) Calculation of Error Probabilities New functions in the wireless network block Introduction Nodes in the 3D space External noise port Noise and time correlation Packets lost signal Fixed packet loss functionality Wireless Network Mask modification Moving the MAC into each device ii

4 CONTENTS The WirelessHART MAC sub-layer in each device Delay compensation Delay, possible sources Delay effect in different systems First-order Stable System Integrating System Possible solutions PI controller Detuned PI controller The PPI controller Modified Smith predictor Results First-order system Integrating system A brief description of the AC800M Effects of the clock drift in AC800M Simulations of systems with delay due to clock drift using wirelesshart protocol Simulation setup The stable model with PI and Predictive PI control The hybrid PPI controller The Integrating process The hybrid improved Smith predictor Conclusions Results Open problems A How to install the tool 92 A.1 Software Requirements A.2 Installation A.3 Compilation iii

5 CONTENTS B How to use the Simulator 94 B.1 Introduction B.2 Writing Code Functions B.2.1 Writing a Matlab Code Function B.2.2 Writing a C++ Code Function B.2.3 Calling Simulink Block Diagrams B.3 Initialization B.3.1 Writing a Matlab Initialization Script B.3.2 Writing a C++ Initialization Script B.4 Compilation C Examples 102 C.1 Introduction C.2 Control of a loop with three nodes C.3 5 nodes with multi-hop C.4 5 nodes with a shared slot C.5 Packets loss and prediction D TrueTime Command Reference 114 Bibliography 117 iv

6 List of Figures 1.1 The SOCRADES consortium in Europe The Open System Interconnection (OSI) model The amount of data in the Open System Interconnection (OSI) model The TDMA structure The Token Bus operating principle The Token Ring operating principle Characteristics of the 802 family HART OSI 7-Layer Model [1] The structure of a WirelessHART network The DLPDU structure [1] The SuperFrame structure [1] The channel hopping [1] The communication tables [1] MAC Algorithm The TrueTime 1.5 block library The dialog of the TrueTime kernel block The dialog of the TrueTime network block The dialog of the TrueTime wireless network block The dialog of the ttgetmsg block to the left, and the dialog of the ttsendmsg block to the right Probability density function for a received symbol when using binary phase shift keying and additive white Gaussian noise v

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 The wireless network block with the external noise input port The average and the variance fields in the wireless network block mask The plot of the lost packets and the consequences in the control performance The wireless network block with the output port for the packet lost signal Settings for the fixed packets lost option The plot of the packets lost and the consequence in the control performance The parameters setting in the WirelessHart mask MAC protocol location in TrueTime MAC protocol location in a real environment Dead-time Jitter effect in event driven control Jitter effect in time driven control Delay caused by clock drift Internal model control structure Standard control loop The IAE error changing the delay and the system time constant The IAE error changing the delay and the closed-loop time constant The PI controller The PPI controller The Modified Smith Predictor The Modified Smith Predictor when d is equal to zero The integral absolute error for the various methods considering a first order system The integral absolute error for the various methods considering an integrating system AC800 typical scenario Cascade loops A possible scenario Representation of the simulated control system Communication schedule WirelessHART parameters vi

8 LIST OF FIGURES 6.21 The drift field in the controller kernel block Reference tracking using the PI controller both with drift and without The PPI scheme Comparison of reference tracking between PI and PPI IAE : PI and PPI controllers Finite state machine: D=0 no delay, D=1 delay of 1 cycle Schedule of the tasks and detection of the delay Scheme of the detection of the delay due to the drift Detection of the delay due to the drift is one cycle late Detection of the delay due to the drift improvement Performance comparison between the hybrid controller, the PPI and the PI IAE comparison between the hybrid controller, the PPI and the PI Simulink model of the system with input disturbance System output with disturbance and drift IAE with disturbance and drift System output with disturbance, drift and a square wave reference IAE with disturbance, drift and a square wave reference System output using PI control with drift and without Integral Absolute Error using a PI control both with drift and without The modified Smith predictor for integrating process Behaviour of the modified Smith predictor in presence of drift compared with the performance of the PI controller Integral Absolute Error of the modified Smith predictor in presence of drift compared with the performance of the PI controller Behavior of the modified Smith predictor in presence of drift with F=λ The system output using the hybrid controller compared with a normal PI and the MSP IAE of the hybrid controller compared with a normal PI and the MSP Behaviour of the hybrid controller in presence of input disturbance for different choice of F. 89 A.1 The TrueTime 1.5 block library B.1 The execution of user code is modeled by a sequence of segments executed in order by the kernel vii

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 C.1 Example: A control loop with 3 nodes C.2 Example: Two control loops C.3 Example: Two control loops and shared slots C.4 Example: Packets lost and prediction viii

10 List of Tables 3.1 Example BOCntr Selection Sets Device Table B.1 Example of a P-controller code function written in Matlab code B.2 The C++ version of the code function in Listing B B.3 Simulink block diagrams are called from within code function using the TrueTime function ttcallblocksystem 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 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 B.6 Example of a TrueTime initialization script in the C++ version. Corresponds to the Matlab version from Listing B C.1 Example of a TrueTime initialization script in the Matlab version C.2 Example of a sensor code C.3 Example of transmissions schedule using different channels and multi-hop. 107 C.4 Example of transmissions schedule using shared slot D.1 Real-time primitives D.2 Commands used to create, initialize TrueTime objects, to control the simulation and used to set and get task attributes D.3 Real-time primitives ix

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 WirelessHART 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 1

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

13 1.1. Outline of the thesis 1.1 Outline of the thesis The contents of the thesis are as follows: 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 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 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 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. 3

14 1.1. Outline of the thesis 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 Chapter 7: Conclusions The last chapter presents the conclusions of this thesis work. Future work is also discussed. 4

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 The OSI basic structure The OSI model is structured in seven functionals layers (see figure 2.1). Each layer communicates 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. 5

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 connection. It enhances the transport layer by adding services to support full session between different nodes. An example is the network login in a remote computer. Layer 4 : Transport - End to end communication control. This layer is the interface between the application software that request data communication and the physical network represented by the first three layers. The transport layer has the responsibility of verifing that the data is transmitted and received correctly from a node of the network to another and that the data is available for application programs. Layer 3 : Network - This layer sets up a complete communication path and oversees that messages travel all the way from the sources to the destination node. When a packet has to travel from one network to another to get to its destination, many problems can arise. The addressing used by the second network may be different from the first one. The second one may not accept the packet at all because it is too large. The protocols may differ, and so on. It is up to the network layer to overcome all these problems to allow heterogeneous networks to be interconnected. Layer 2 : Data Link - This level provides for the verification that bit sequences 6

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

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

19 2.2. The Medium Access Control (MAC) protocol 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 9

20 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 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 Token Bus In token bus all units are connected to the network using a bus. The access to the medium follows a strict deterministic pattern, so that only a node at time can initiate a transmission of a message. The right to send is given by a token, a special bit pattern that is passed from one unit to the other in a circular fashion. The unit that receives the token gets the 10

21 2.2. The Medium Access Control (MAC) protocol right to transmit for a specific interval, and must, then, pass the token to the following unit. If a unit does not have to transmit, it just passes the token to the next one. The circular pattern in which the token is passed makes the token bus a logical ring, although its physical topology is a bus. Figure 2.4: The Token Bus operating principle 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 11

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] Bluetooth/IEEE 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åtand, 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 timeslots in accordance with permission given by the master. Each channel is divided into 12

23 2.3. The IEEE 802 standards time slots of 625 µs. The master switches from slave to slave in a round-robin fashion. The 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 IEEE Since IEEE 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 systems will be discussed here. The main parameters of IEEE a/b/g are the following [20]: IEEE a IEEE a is placed in 5 GHz bands that are license exempt in Europe ( GHz and GHz) and unlicensed in the US (UNII bands, GHz and GHz). Over the whole spectrum, this allows for 21 systems to be running in parallel in Europe and eight in the US. The IEEE a 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 b is a high rate extension to the original IEEE 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 system, the payload of the IEEE b 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. 13

24 2.3. The IEEE 802 standards IEEE g is an extension to the IEEE b 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 b and an OFDM PHY that uses the same modulation and coding combinations as IEEE a. 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 b and g standards use the 2.4 GHz band. Because of this choice of frequency band, b and g equipment can incur interference from microwave ovens, cordless telephones, Bluetooth devices, and other appliances using this same band. The a 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 b, also known by the brand Wi-Fi. It is, hence, important to spend some more words on it. IEEE b 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] IEEE The IEEE standard was finalized in October The goal of this standard was to create a very low cost, very low power, two-way wireless communication solution that meets the unique requirements of sensors and control devices. In contrast to Bluetooth and IEEE , IEEE has been specifically developed for use with applications 14

25 2.3. The IEEE 802 standards in which a static network exists that has many infrequently used devices that transmit only small data packets. Such applications are exactly what many industrial environments would require. In order to encourage widespread deployment, IEEE 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, especially 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 can scan the frequency band for a channel that promises better performance values and switch to that channel. The devices operation with the IEEE 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 standard, there are two different modes of operation. In unbeaconed mode all stations use an unslotted CSMA variant. Here, a station initiating 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 ms and 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- 15

26 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 uses low transmit power levels. In addition to this, IEEE 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 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 ZigBee The ZigBee [27] set of high level communication protocols, developed by the Zigbee Alliance, uses the 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 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 ( feet), although it is heavily dependent on the particular environment. The maximum output power is generally 0 dbm (1 mw) WirelessHART The goal of the development of WirelessHART is to establish a wireless communication standard for process automation applications [4]. WirelessHART is an extension of the wired HART protocol, enhancing it by allowing new applications while still preserving backwards compatibility. WirelessHART supports applications that have cycle times in 16

27 2.3. The IEEE 802 standards the order of seconds, as well as applications with cycle times as long as days or even weeks. WirelessHART aims to be a secure, time-synchronised, ultra low-power, mesh network for process automation. The WirelessHART specification follows the OSI layers, and contain a Physical, Medium access, Transport, and Network layer. The Application layer is the same for both wired and WirelessHART. Details of the WirelessHART layers are shown below: The physical layer is the same as the IEEE GHz PHY layer The MAC layer is a modified version of the IEEE 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. 17

28 2.3. The IEEE 802 standards Figure 2.6: Characteristics of the 802 family 18

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 g) 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 Multiple Access (TDMA) (see Subsection 3.3.2). Both support the common HART Application 19

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

31 3.3. MAC Protocol Description All communications of the WirelessHART Network pass through the gateway. Consequently, 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 communication between the device and its neighbors (see Subsection 3.4.2). These tables are normally populated by the Network Manager. populated as neighbors are discovered. In addition the neighbors table is 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. 21

32 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] 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 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 22

33 3.3. MAC Protocol Description 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. Superframes 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. 23

34 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 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) 24

35 3.3. MAC Protocol Description BOExp Set of Possible Values for BOCntr 1 { 0, 1 } 2 { 0, 1, 2, 3 } 3 { 0, 1, 2, 3, 4, 5, 6, 7 } 4 { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 } Table 3.1: Example BOCntr Selection Sets A sample random back-off sets for BOExp values of one to four is shown in table 3.1. From this set calculated based on the BOExp, a random value for the BOCntr is selected. For each subsequent shared link to that neighbor, the BOCntr must be decremented. Only when the corresponding BOCntr is zero can the source device attempt a transmission in a shared slot. The value of BOExp shall not exceed that of MaxBackoffExponent. Broadcast messages must not be transmitted on shared slots 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. destination. Graphs are used to route messages from their source to their The communication tables and the relationships between them are shown in figure 3.6. For more details on wirelesshart see [1]. 25

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 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 To understand better how the MAC protocol is implemented the pseudo-code of 26

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 * 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 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 27

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) 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 : 28

39 3.4. Implementation ActualSlotNumer = ( Actual Sim time + exectime %Superf ramesize) + 1 (3.2) SlotSize 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). 29

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 to interface the kernel and the tasks with the continuous-time processes. 30

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

42 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 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 32

43 4.1. Description of the tool signals), the length of the message, and optional real-time attributes such as a priority or a deadline. Figure 4.3: The dialog of the TrueTime network block. The network block is configured through the block mask dialog, see Figure 4.3. Some 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 33

44 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 transmission. Lost messages will consume network bandwidth, but will never arrive at the destination 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. into account also the path-loss of the radio signals. It takes 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 b/g (WLAN) and IEEE (ZigBee). WirelessHART has been added (see Sec 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 1 d a a parameter chosen to model the environment. Interference from other terminals. where d is the distance in meters and a is 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 pernode basis. 34

45 4.1. Description of the tool Figure 4.4: The dialog of the TrueTime wireless network block. The following parameters are common to all models: Network type Determines the MAC protocol to be used. (WLAN) or (ZigBee). Can be either b/g 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 number of header and tail bits, so the frame must be at least sizeof(header)+sizeof(tail) long. 35

46 4.1. Description of the tool Transmit power Determines how strong the radio signal will be, and thereby how long it will reach. Receiver signal threshold If the received energy is above this threshold, then the medium is accounted as busy. Path-loss exponent The path loss of the radio signal is modeled as 1 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 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 ). 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. 36

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 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, b/g (WLAN) and (ZigBee). The possibility to use also WirelessHART has been added. The block permits 37

48 4.2. Wireless Network Block behaviour to simulate packets lost using a packet error probability or specifying when a packet has to be discharged. It permits to compare more simulations together taking into account how the same sequence of packets lost affects them. In the following subsection the original options of the network will be carefully described. The new possibilities added in this project, instead, are described in chapter b/g (WLAN) IEEE b/g are two of the more popular protocols used today. IEEE is used in many laptops and mobile devices. The protocol is based on CSMA/CA with some modifications. In TrueTime a package transmission is modelled like this: The node that wants to transmit a packet checks if the medium is idle. The transmission may proceed, if the medium is found to be idle, and has stayed so for 50 µs. If, on the other hand, the medium is found to be busy, a random back-off time is chosen and decremented in the same way as when colliding (described later in this section). When a node starts to transmit, its relative position to all other nodes in the same network is calculated, and the signal level in all those nodes are calculated according to the path-loss formula 1/d a. If the signal level in the receiving node is larger than the receiver signal threshold, then the signal-to-noise ratio (SNR) is calculated and used to find the block error rate (BLER). All other transmissions add to the background noise when calculating the SNR. The BLER and the size of the message are used together to calculate the number of bit errors in the message. If the percentage of bit errors is lower than the error coding threshold, then it is assumed that the channel coding scheme is able to fully reconstruct the message. If any other nodes are already transmitting to the receiving node and their respective SNRs are lower than the new one or if there are other ongoing transmissions which the currently sending node reaches with its transmission, then all those messages are marked as collided and discharged. From the perspective of the sending node, lost messages and message collisions are the same. ACK messages are sent on the MAC protocol layer. If the ACK is not received by the transmitting node during ACK timeout, the message is retransmitted after waiting a random back-off time within a contention window. The contention window size is doubled for every retransmission of a certain message. The back-off timer is decremented only if the medium is idle, or if it has been idle for at least 50 µs. The Retry limit number of retransmissions specifies the maximum number of 38

49 4.2. Wireless Network Block behaviour times that a message could be retransmitted before it is discharged (ZigBee) ZigBee is a protocol optimized for the use of sensors and simple control networks. It is characterized by a rather low bandwidth and by a really low power consumption that increases the life of the devices from a battery consumption point of view. It is based on CSMA/CA. The packet transmission model in ZigBee is similar to WLAN, but the MAC procedure differs and is modeled as: 1. Initialize: NB=0 BE=macMinBE 2. Delay for a random number of backoff periods (order of 100 µs) in the interval [0, 2 BE 1] 3. Is the medium idle? if yes: send else: goto 4 4. Update the backoff counters: NB=NB+1 BE=min(BE+1, amaxbe) 5. Is NB>macMaxCSMABackoffs? if yes: drop the packet else: goto 2 where: NB Number of backoffs. BE Backoff exponent. macminbe The minimum value of the backoff exponent in the CSMA/CA algorithm. The default value is 3. 39

50 4.2. Wireless Network Block behaviour amaxbe The maximum value of the backoff exponent in the CSMA/CA algorithm. The default value is 5. macmaxcsmabackoffs The maximum number of backoffs the CSMA/CA algorithm will attempt before declaring a channel access failure. The default value is 4. The variable names are taken from the standard to make comparisons easier Calculation of Error Probabilities When a symbol is sent, in this case it is a bit, an additive white Gaussian noise gives a probability density function for the received symbol, that for some signal-to-noise ratio may look like Figure 4.6. A threshold is then used to decide if the received symbol is a 0 or a 1. The darker area to the left of the threshold gives the probability of a symbol error. A higher signal to noise ratio translates the curve to the right, making the probability of error smaller. During the calculation of error probabilities, the following approximation is done: BPSK 1 is always used in the transmissions. The above standard procedure takes into account the single bits that form a message. The total number of calculated bit errors should then be compared to the error coding threshold. Being it very computationally expensive, it has been chosen to save the maximum noise level during the transmission and to use it to calculate the worst case SNR. By assuming that bit errors in a message are uncorrelated, it is deduced that the number of bit errors, X, belongs to a binomial distribution X Bin(n, p), where n is the number of bits in the message, and p is the probability that a certain bit is erroneous. If the value of n is large, the binomial distribution can be approximated with a normal distribution, using the central limit theorem. This gives that X N(np, npq) where q = 1 p. What we are really interested in is the probability that bn, where b is the error coding threshold, is larger than the total number of bit errors in a message. This probability is calculated using P (X bn) = bn np Φ( ) if bn np > 0 npq bn np 1 Φ( ) if bn np 0 npq (4.1) where Φ is the standard normal cumulative distribution function. 1 Binary Phase Shift Keying (BPSK) is a means of transmitting symbols by altering the phase of a reference signal. It uses two phases separated by 180 and is hence binary. 40

51 4.2. Wireless Network Block behaviour Figure 4.6: Probability density function for a received symbol when using binary phase shift keying and additive white Gaussian noise. Example Assume that a message consists of 100 bits (i.e., n = 100). The probability that a certain bit is erroneous has been calculated to 0.1 using the above method, i.e., p = 0.1 and q = 1 p = 0.9. The error coding threshold has been set to 5%, i.e., b = Then the probability that we can decode the complete message is bn np P (X bn) = 1 Φ( ) = 1 Φ( 5 ) (4.2) npq 9 User-Defined Path-Loss Function TrueTime permits to use a different path-loss function, instead of the defined one. The default path-loss function (or propagation model) used in the TrueTime wireless simulations is [23]: P receiver = 1 d a P sender (4.3) 41

52 4.2. Wireless Network Block behaviour where P is the power, d is the distance in meters, and a is a parameter that can be chosen to model different environments. This model is often used in simulations, but if the user prefers to implement his own function, he may do it by writing a Matlab m-file where all the built-in functions available in Matlab or Simulink could be called. The Matlab function has to take the following arguments Transmission power Name of the sending node x and y coordinates of the sending node Name of the receiving node x and y coordinates of the receiving node Current simulation time and return the signal power in the receiving node. 42

53 Chapter 5 New functions in the wireless network block 5.1 Introduction In this chapter will be described some new utilities implemented to improve the behavior and the useability of the wireless network block of TrueTime. In Section 5.2 the 3D location of the nodes is described. It permits a more realistic placement of the devices in the environment. Another useful functionality is introduced in Section 5.3 and it consists in the possibility to introduce an external source of noise. Section 5.4 explains a new way for the computation of the noise considering a time correlation between the time samples. To improve the usability of the tool the possibility to notice when a packet is lost has been added (Section 5.5). Section 5.6 explains a new option that permits to simulate, in a deterministic way, a time interval in which the network loses packets. Section 5.7 describes the modification in the TrueTime graphic interface, of the wireless network block, done to use the WirelessHART protocol. For a more realistic behavior of the devices the MAC layer has been moved from the wireless network block and implemented in a separate function that can be called from each device (Section 5.8). 5.2 Nodes in the 3D space TrueTime allows to collocate the devices on a 2D plane. It does not permit to build up a real scenario in which the nodes could be placed at different heights, for example attached to the same column. For that reason, the possibility to specify the (X,Y,Z) coordinates (meters) in the space for each node is given (see Fig. 5.1). 43

54 5.3. External noise port Figure 5.1: The TrueTime wireless network block with the x,y,z coordinates inputs port that specifies the true location of the nodes This new information has to be considered in the computation of the signal power received during a transmission. In fact, as is described in Section 4.2.3: P receiver = 1 d a P sender (5.1) where P is the power, a is a parameter that can be chosen to model different environments and d is the distance in meters. Considering the new coordinates, the distance between the node i and the node j is: d = (X i X j ) 2 + (Y i Y j ) 2 + (Z i Z j ) 2 (5.2) This new computation of the distance involves also the probability of packets lost (see Sec ). 5.3 External noise port The TrueTime default error probability function takes into account a signal to noise ratio SNR, for the transmitted packet i, computed in the following way: SNR i = P reveiveri N j=1 P reveiver j P reveiveri (5.3) 44

55 5.4. Noise and time correlation where P reveiveri is the power of the packets i, N j=1 P reveiver j is the total power at the receiver node. This formula considers the interferences due to other nodes than the transmitting one. In fact, it is possible that more than one node tries to transmit at the same time to the same node. Anyway this approach does not take into account other sources of interferences like thermal noise, fading or other radio traffic not belonging to this network. For that reason an input port is added. It permits to specify for each device an external source of noise that can be, for example, a white noise block or a sequence of measurements taken from a real case (see Fig. 5.2). Figure 5.2: The wireless network block with the external noise input port. This external contribution is introduced in (5.3) in this way: SNR i = P reveiveri N j=1 P reveiver j P reveiveri + N i (5.4) where N i is the contribution of this new component to the SNR of the transmitted packet i. 5.4 Noise and time correlation In a real environment, where the nodes are fixed in a place and not in movement, if an event causes interferences, the effects produced by this will not vanish immediately, but 45

56 5.4. Noise and time correlation will have an impact also in subsequent moments. Considering this fact, a time correlation is introduced in the computation of the interferences: N i = a N i 1 + V i V i N (µ Vi, σ 2 V i ) (5.5) where a (currently fixed at the value of 0.9) is a coefficient that indicates the correlation between two samples, V i is a gaussian noise and N i N (µ Ni, σn 2 i ) is the final interference. The initial value of the sequence, N 0, is picked from the external noise port. To chose with which order of magnitude of interference to work, it is possible to set the average µ Vi and the variance σv 2 i of the gaussian noise from the mask interface of the wireless network block (see Fig. 5.3). Figure 5.3: The average and the variance fields in the wireless network block mask The final variance σ 2 N i is affected by σ 2 V i in the following way σ 2 N i = σ2 V i 1 a 2 (5.6) 46

57 5.5. Packets lost signal The average value of N i will be µ Ni = a µ Ni 1 + µ Vi (5.7) 5.5 Packets lost signal To have a complete mastery of simulation, it is useful to monitor the packets lost situation. For this reason, a new graphics function has been added. It allows to highlight in a chart when a packet is lost, due to a collision, external interference or excessive attenuation of signal. This permits to study in a simpler way how it affects the control performance (see Fig. 5.4). Figure 5.4: The plot of the lost packets and the consequences in the control performance To plot the lost packets, an output port has been added in the wireless network block (see Fig. 5.5). Figure 5.5: The wireless network block with the output port for the packet lost signal 47

58 5.6. Fixed packet loss functionality 5.6 Fixed packet loss functionality To study the problem of packet loss in the wireless control networks and to compare the results of different solutions, the possibility to fix the time intervals in which the packets are lost has been also added. Figure 5.6: Settings for the fixed packets lost option When the check box indicated in figure 5.6 is selected a new field appears in the mask. In this field it is possible to write an array of time intervals following this structure: [ t 1start t 1stop t 2start t 2stop... t nstart t nstop ] t istart is the instant, in seconds, when the network starts to lose packets and t istop is 48

59 5.7. Wireless Network Mask modification the final instant of that interval. Considering, for example, the values fixed in figure 5.6: [ ] the packets lost intervals and the possible consequences in a control loop are shown in figure 5.6. Figure 5.7: The plot of the packets lost and the consequence in the control performance 5.7 Wireless Network Mask modification The possibility to chose the wirelesshart MAC protocol in the wireless network block mask has been added. Figure 5.8 shows the mask with all the parameters and the default values for the Hart case. As is shown in figure 5.8 WirelessHart uses the same parameters as for Wlan and ZigBee with the addition of three fields to set the number of channels, the size of the slot and the superframe length. 49

60 5.8. Moving the MAC into each device Figure 5.8: The parameters setting in the WirelessHart mask 5.8 Moving the MAC into each device In the original version of TrueTime the wireless network block is responsible for the implementation of the MAC protocols of all the devices, as well as the simulation of packets loss and graphic plot (Figure 5.9). Figure 5.9: MAC protocol location in TrueTime 50

61 5.8. Moving the MAC into each device This does not correspond perfectly to reality. In fact, in a real environment, each device has its own MAC sub-layer. When a device wants to access the network it has to interrogate the MAC in a local way (see Fig. 5.10). Figure 5.10: MAC protocol location in a real environment When the MAC sub-layer of a device permits the access to the network, the message will be propagated through the medium The WirelessHART MAC sub-layer in each device The ttmac function described in section 3.4 permits to work using the scenario described above. WirelessHART (see Sec. 3.3) communication is arbitrated using TDMA to schedule link activity. All communication is performed within a designated slot with a period of 10 ms. If a packet is lost, it will have to be retransmitted in a specially reserved future time slot. In case shared slots are used and a collision occurs, a back-off counter has to be decreased until 0 before to try a new transmission. The Back-off is decremented at most one time for each time slot. For all these reasons the the MAC sub-layer will not operate more frequently than 10 ms. So every time a transmission is required, it is possible to call the ttmac function. If the channel is free and the back-off counter is already equal to zero, the function will give a positive response. Permitting to each device to memorize its own status (BOcounter, BOexponent) the MAC layer can be implemented and called inside each device (see Fig. 5.10). The network block in this case will be responsible only for the propagation of the message, for the computation of the packet loss error and for the graphics function. 51

62 Chapter 6 Delay compensation In this chapter will be described how the most common industrial model can be affected by delay and some possible solutions to overcome this problem. In section 6.1 is introduced the problem of the delay in a control loop and the possible sources. In 6.2 is investigated how the performance of a control loop could be influenced by a delay considering some typical industrial systems. Section 6.3 investigates some possible solutions that the controller can adopt to improve its performance. A brief description of the controller AC800M is given in 6.5. In Section 6.6 the problem of delay due to the clock drift in controllers like the AC800M will be treated. 6.1 Delay, possible sources The effects of delays in control loops can be really annoying and, in extreme case, bring the system to instability. For these reasons it is of great importance to study the type of delays presents in the plant that has to be controlled. The possible causes of delay in a control system can be many. 52

63 6.1. Delay, possible sources Below some possible sources that can affect a system are listed: Intrinsic delay; Dead-time due to the scheduling; Delay during the communication; Jitter; Drift of the clocks; The first cause is an intrinsic factor of the system taken in consideration. In fact, not all the plants met in control applications are characterized by an instantaneous response to the control signal (this is often a transport delay, for example, between a chemical reaction and the sensor). Also the scheduling scheme used to execute the various tasks responsible of the control loop computation has to be taken into account (see Fig. 6.27). If a sensor makes the measurement at time t 1 and the controller executes at time t 2, a dead-time equal to t 2 t 1 is introduced. Figure 6.1: Dead-time Considering the case in which the actuation is not immediate, then a longer dead-time has to be considered (in Fig 6.27 t 3 t 1 ). Another possible source of the delay is the communication protocol used for data exchange [28]. Each protocol specifies a data rate and a particular medium access protocol (MAC). Hence the size of the data plays a significant role, but more important is the MAC chosen. Many of them could be considered (i.e. Token Bus, Token Ring, TDMA, CSMA). What firmly distinguish them is the possibility to have a bounded delay or not. In fact, while Token Bus/Ring and TDMA assure a deterministic delay, the use of a CSMA does not. Using this method, when a collision occurs, there is no guarantee of having neither a bounded time before the transmission will be completed nor an absolute certainty of a successful transmission. The number of 53

64 6.1. Delay, possible sources maximum retransmissions and the number of the devices, that can access to the network at the same moment, strongly affect the behavior of a CSMA based protocol. Also the presence of jitter in the task execution time can affect the behavior of a control loop. In an event driven controller case a jitter causes a delay equal to the jitter itself (see Fig. 6.2): Figure 6.2: Jitter effect in event driven control. The delay introduced by the jitter is: D = (t 4 t 3 ) (t 2 t 1 ) (6.1) In the time driven case, instead, the problem could be more critical. In fact, if the actuator task is executed very close to the begin of the controller task, then, a small jitter could cause an extra delay in the actuation of a whole period H (see Fig. 6.3). Figure 6.3: Jitter effect in time driven control. The control signal can not be actuated during the execution of the task of the first actuator, because it is not ready, but has to wait until the next one. Last but not least, the drift of the clocks has to be analyzed. Typically in a control loop there are at least one sensor, one controller and one actuator. Consider the following scenario: the sensor sends the measurement through a network to a gateway or to an I/O board. The controller receives the data from this using a different protocol (typically 54

65 6.2. Delay effect in different systems Profibus or Fieldbus). After the computation, the control signal will be sent to the actuator using the same network used by the sensor. It is easy to imagine that, using two different network protocols, no synchronization between the controller and the rest of the system is guaranteed. Hence, if periodic tasks are used to execute the sensing, the actuation and the control calculation, and a drift of the clocks occurs, then an extra dead-time is introduced in the loop. Figure 6.4: Delay caused by clock drift. As it is possible to notice from the figure 6.4, if the clocks are not synchronized, the controller can execute when a new measure is not ready or with an extra delay. The control signal computed at time t 4 uses the measurement made at time t 1 and it will be not actuated before the time t 6. The total delay in this case will not be equal to standard dead-time L = t 3 t 1, but to D. D = t 6 t 1 = H + L (6.2) 6.2 Delay effect in different systems To get an understanding of the problems caused by delays, it is interesting, first of all, to study how, different control loops react in presence of extra delay. industrial applications are characterized by one of the following models: Many plants in G(s) = K T s + 1 G(s) = K s (6.3) For this reason, they will be the basis for our case study. 55

66 6.2. Delay effect in different systems Both these systems can easily be controlled using a PI controller of this type C(s) = K c (1 + 1 T I s ) (6.4) First-order Stable System The first case represents a first order stable system affected by a delay D sys : G(s) = K T s + 1 e D syss (6.5) The controller chosen is a PI because of its simplicity. The tuning of the PI parameters can be done following the lambda tuning technique [9]. Figure 6.5: Internal model control structure. This considers a closed-loop of the following form (see Fig. 6.5): Y (s) = G(s)Q(s)R(s) (6.6) 56

67 6.2. Delay effect in different systems Q(s) can be chosen as a plant inverse multiplied by the desired closed loop system: Q(s) = F (s)ĝ(s) 1 (6.7) where Ĝ(s) is an approximation of G(s). From this follows: Y (s) = F (s)r(s). If the model Ĝ(s) is not invertible, then factorize according to Ĝ(s) = Ĝ (s) 1 Ĝ(s) where Ĝ(s) contains all invertible parts with Ĝ+(0) = 1, and use Q(s) = F (s)ĝ(s) 1. Comparing Y (s) with the standard control loop shown in Fig. 6.6: Figure 6.6: Standard control loop. C(s) = Q(s) 1 QĜ(s) = 1 Ĝ (s) F (s) 1 F (s)ĝ+(s) (6.8) Hence considering Ĝ (s) = K T s + 1, Ĝ + (s) = e Dsyss, F (s) = 1 λs + 1 (6.9) leads to C(s) = T s + 1 K 1 λs + 1 e Dsyss (6.10) Approximating the deadtime by a first order Taylor series expansion e D syss (1 D sys s) yields which is clearly a PI controller. C(s) = T s + 1 K(λ + D sys )s (6.11) 57

68 6.2. Delay effect in different systems Comparing it with C(s) = K c T I s + 1 T I s (6.12) it is easy to obtain T I = T, K c = T I K(λ + D sys ) = T K(λ + D sys ) (6.13) where λ is the desired closed loop time constant. Following these rules it is possible to tune the controller parameters taking into account the delay of a system. In many cases, as it is explained in section 6.1, the total delay in a closed loop system can change according to many possible reasons. Considering to have tuned the controller action on a known delay, D sys, it is interesting to understand how the performance of the system could be influenced by an extra delay. In this particular case, the extra delay is equal to the length of one superframe H. Without loos of generality, in the rest of this chapter it is used H = 1 s. Figure 6.7: The IAE error changing the delay and the system time constant. Define the integral absolute error as IAE = 0 58 e(t) dt (6.14)

69 6.2. Delay effect in different systems The figure 6.7 shows the ratio between the IAE using a controller tuned for D sys, but applied to a system affected by a delay equal to D sys + 1 and the IAE obtained applying the same controller to a system affected by a delay D sys. In the graph it is also taken into account the effects due to the shift of the time constant T. The extra delay gives performance degradation only in the corner case, when T < 2 and D < 2. It means that only in these lasts cases, it will be useful to adopt some delay compensation techniques Integrating System The second case considered is an integrating system affected by a delay D sys : G(s) = K s e Dsyss (6.15) This system is not stable. The controller chosen can be, also in this case, a PI. Approximating the dead-time by a first order Taylor series expansion Y (s) = C(s)G(s) 1 + C(s)G(s) = (T I s + 1)(1 D sys s) ( T I KKc T R(s) (6.16) ID sys )s 2 + (T I D sys )s + 1 Assume desired characteristic equation (λs + 1) 2 following parameters = λ 2 s 2 + 2λs + 1 which implies the T I = 2λ, K c = T I K(λ + D sys ) 2 (6.17) where λ is the desired time constant of the closed-loop system. The study done for the first order case can be done considering this new system. In this case, not having the time constant T, the analysis is done taking into account the shift of the parameter λ. 59

70 6.3. Possible solutions The figure 6.8 shows that the integrating system is more sensitive to the change of the parameters and suffers a degradation of its performance when λ < 3, for any value of the delay. Figure 6.8: The IAE error changing the delay and the closed-loop time constant. 6.3 Possible solutions The previous sections (see Sec. 6.1 and Sec. 6.2) have introduced the problems that a delay can cause in a system and which are the more sensitive cases. In order to improve the performance of the control loop, some techniques are here described and compared. The solutions proposed are the following: Digital PI controller Digital PI controller detuned PPI controller Modified Smith predictor (integrating case only) Both the previous systems, first order and integrating, are studied. 60

71 6.3. Possible solutions PI controller The digital PI controller is implemented following the rules explained in sections and 6.2.2, depending on the cases studied. This controller is tuned assuming knowledge of the system delay D sys, but not the extra delay that can affect the loop. The use of this controller, as is shown in the figure 6.7 and 6.8, has clear limitations when the total delay is different from the one used for the tuning. Anyway, the simulations done using this method will be useful to understand how much the other solutions improve the performance of the closed loop. The controller signal is calculated according to u k = u k 1 + K c ((1 + T s /T I )(r k y k ) (r k 1 y k 1 )) (6.18) As described above G(s) = K T s + 1 e Dsyss (6.19) the following controller setting is used T I = T, K c = T K(λ + D sys ) (6.20) and for G(s) = K s e Dsyss (6.21) the controller parameters are T I = 2λ, K c = T I K(λ + D sys ) 2 (6.22) The parameter λ has been chosen equal to T in the first case and equal to 1/K in the second one. 61

72 6.3. Possible solutions Figure 6.9: The PI controller Detuned PI controller This solution takes into account the possibility of detuning the PI controller considering the total delay. Using this solution, when there is an extra delay, the performance will of course be improved, but this operation needs model based tuning which is not always the case. The controller signal has the same form like in 6.3.1, but the K c and T I are chosen considering the total delay D = D sys + L, where L is the extra delay. G(s) = K T s + 1 e (D sys+l)s, T I = T, K c = T I K(λ + D sys + L) (6.23) G(s) = K s e (Dsys+L)s, T I = 2λ, K c = T I K(λ + D sys + L) 2 (6.24) The parameter λ has again been chosen equal to T in the first case and equal to 1/K in the second one The PPI controller The Predicting PI controller (PPI) is a particular Smith predictor characterized by a simpler form [9]. Considering: G(s) = K T s + 1 e Ds (6.25) As in lambda tuning, the design criterion is to chose a controller that cancels the process pole and makes the other closed-loop pole equal to s = 1/λ, where λ is the desired response time of the closed-loop system. 62

73 6.3. Possible solutions Figure 6.10: The PPI controller. The controller parameters obtained are the following: K c = T λk, T I = T (6.26) The loop transfer function of the nominal system without delay is P 0 C 0 = 1/(sλ), where P 0 = K/(T s + 1). The controller is: The loop transfer function is: C(s) = 1 + st Ksλ sλ (1 e Ds ) (6.27) G(s)C(s) = 1 sλ sλ (1 e Ds ) (6.28) The process pole has to be faster than the dominant closed-loop dynamics because it is cancelled. The tuning parameter is only one: λ. The output signal can be written as: U(s) = 1 + st Ksλ E(s) 1 sλ (1 e sd )U(s) = 1 + st Ksλ (E(s) K 1 + sλ (1 e sd )U(s)) (6.29) = 1 + st Ksλ E p(s) (6.30) where E p (s) is the Laplace transform of the predicted error: e p (t) = y sp (t) y(t) ỹ(t) (6.31) and Ỹ (s) = K 1 + st (1 e Ds )U(s) (6.32) 63

74 6.3. Possible solutions The term ỹ(t) represents the effect on the output of control actions taken in the interval (t T, t). The controller can be seen as a PI controller that acts on a predicted error, which is the actual error compensated for past control actions that have not yet appeared at the output. From that it takes its name, Predicting PI controller. Choosing λ = T U(s) = K c E(s) e Ds 1 + st I U(s) (6.33) Modified Smith predictor The PPI applied to integrating systems, as it will be shown in section 6.4.2, leads to an unstable closed-loop system. Therefore some kind of modified Smith predictor has to be used. For example like the one depicted in Fig The price to pay is a more deep knowledge of the plant to be controlled. Figure 6.11: The Modified Smith Predictor. G(s) = G 0 (s)e Ds = K s e (Dsys+L)s (6.34) C(s) is needed to stabilize G 0 (s) and can be the same PI as introduced in tuned for D sys. F (s) can be chosen as F (s) = λ 2 (6.35) where λ is the desired closed-loop time constant. 64

75 6.4. Results Considering the case in which the disturbance d is equal to zero, the system can be simplified as in Fig Figure 6.12: The Modified Smith Predictor when d is equal to zero. Hence, F(s) has the property to help rejecting the disturbance on the control signal. 6.4 Results In this section will be described the results obtained using the methods proposed in Section 6.3. The simulations are done considering both the plants, the stable one and the integrating one First-order system Considering the systems G(s) = the following techniques have been applied and compared: K T s + 1 ; G 1(s) = K T s + 1 e Ds (6.36) Digital PI controller Digital PI controller detuned PPI controller The figure 6.13 shows the ratio between the IAE of the various methods applied to G 1 (s) and the IAE of the basic case in which a PI controller is used to control the plant G(s) (first in the legend). The top half explains how the integral absolute error changes in the various cases for a step in teh setpoint. The bottom half illustrates the IAE when the reference signal is set 65

76 6.4. Results to zero, but when instead there is a step disturbance on the control signal. In all the cases it is assumed λ = T, a sample time T s equal to 1 s and a delay D = 1 s. Figure 6.13: The integral absolute error for the various methods considering a first order system. The red line (the second in the legend) shows the behavior of the PI controller tuned on G(s) if applied on G 1 (s). As was shown in Section 6.2.1, when T < 2 the performance deteriorates. The cyan line (third in the legend) represents the PI controller performance when it is tuned considering the delay D according to the rules in Section The behavior is much better, but this detuning operation has a price. The green line (fourth in the legend) shows how this last controller works if the delay is, indeed, equal to zero (D = 0). The analysis of this case is useful to understand what could happen if the delay is not always constant In fact, as shown in Section 6.1, a clock drift, for example, can cause a varying dead-time. The magenta line (last in the legend) is related to the PPI case, which gives the best result for both the cases. Remembering also the simplicity of implementation of the PPI, this controller is the best solution studied for a first order system with delay. 66

77 6.4. Results Integrating system Considering the systems G(s) = K s ; G 1(s) = K s e Ds (6.37) the following techniques have been applied and compared: Digital PI controller Digital PI controller detuned PPI controller Modified Smith predictor The figure 6.14 shows, like in the previous case, the ratio between the IAE for the various methods considered and the IAE for the basic case in which a PI controller is used to control the plant G(s) (first in the legend). The top half explains how the integral absolute error changes for a setpoint step. The bottom half illustrates the IAE for a step disturbance on the control signal. Figure 6.14: The integral absolute error for the various methods considering an integrating system. 67

78 6.5. A brief description of the AC800M In all the cases is assumed λ = 1/K, a sample time T s equal to 1 s and a delay D = 1 s. G 1 (s) = K s e Ds (6.38) Considering the figure 6.14, the red line (the second in the legend) shows the behavior of the PI controller tuned on G(s) and applied on G 1 (s). As was shown in Section 6.2.2, when T < 3 the performance deteriorates. The cyan line (third in the legend) represents the PI controller performance when it is tuned considering the delay D according to the rules in Sec Comparing with the result given by the other system, in this case the performance is not really better. The green line (fourth in the legend) shows how this last controller works if the delay is equal to zero (D = 0). The analysis of this case is useful to understand what could happen if the delay is not always constant. The magenta line (fifth in the legend) is related to the PPI case. However in this case, becouse the system is unstable, the standard Smith predictor can not be applied. For that reason, for an integrating system an other solution is suggested. The black line (last in the legend) represents the behavior the the modified Smith predictor (MSP) described in Section 6.3.4, which gives the best result for this system. Also considering a disturbance on the control signal, the MSP gives a great performance improvement. Of course the price to pay is an increased complexity of the controller that must be implemented. 6.5 A brief description of the AC800M The AC800M is an ABB controller of the 800xA family [24] [25]. It is very popular device and is used in many industrial plants all around the world. For the studies done here, it will not be useful to describe the whole system, but the scheduling of the threads that this controller adopts is important. The AC800M works according to a scenario like the one shown in figure Figure 6.15: AC800 typical scenario 68

79 6.5. A brief description of the AC800M Each execution cycle is began by AC800M reading the values of all sensors from their respective registers. In the context of WirelessHART, if an AC800M would be used for the computation of the control signals, then all sensor slots would have to be before any control tasks. AC800M then writes the control signals to the output registers as soon as the corresponding computation has been completed. Hence, one does not need to wait until all control signals have been computed before actuator communication can start. The reason for reading all sensor at once, is that when there are control loops with a direct connection to each other, they need to be executed together. An example of such a situation is cascaded loops, see Fig Here the outer so called master controller provides the setpoint to the inner slave controller, which in turn calculates the actuator signal. This means that two sensor signals are needed to calculate one actuator signal. Obviously both sensor readings need to be available before calculation can start. It is however, highly unlikely that with a large number of loops in one network they are all directly connected in this manner, why the requirement to have all sensor signals available up front is an unnecessary (but obviously convenient) restriction. Figure 6.16: Cascade loops Effects of the clock drift in AC800M Consider a system like the one shown in the figure 6.17: Figure 6.17: A possible scenario. 69

80 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol The sensor sends the data to the gateway over a wireless network. The gateway writes the data in the I/O board of the controller through a wired connection. When the control signal is computed, the information is sent back to the gateway by wire and to the actuator using the wireless network. Using a wireless protocol like WirelessHART it is reasonable to suppose that all the devices that are part of that network, are synchronized. In fact, the protocol plans on using some nodes like time sources to execute the operation of synchronization. The controller, instead, is not part of the same network. Typically it communicates with the gateway using protocols like Fieldbus or Profibus, so no synchronization with the other nodes can be guaranteed. Remembering the study made in Section 6.1, it is easy to foresee that, if the controller is affected by clock drift, a delay can appear in the closed loop system. 6.6 Simulations of systems with delay due to clock drift using wirelesshart protocol In this section the problem of delay due to the clock drift in the controllers like the AC800M will be treated. All the tests have been made using simplified plants with one loop in which the devices communicates using the WirelessHART protocol (see Section 3.2). In section 6.3 the problem of the delayed systems was studied using different control algorithms. In this section the same algorithms will be analyzed considering the delay due to the clock drift. Moreover a new hybrid algorithm will be introduced in order to increase the performance of the control loop Simulation setup In this subsection the main setup of the simulations is explained. All the tests are made using two different plants, the stable model (6.39) and the integrating process (6.40) G(s) = s + 1 (6.39) G(s) = 0.25 s (6.40) The global scheme of the control system is illustrated in figure It has been constructed in a Simulink environment, using the modified wireless library described in chapter 5. 70

81 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol Figure 6.18: Representation of the simulated control system In this control system there is only one loop. The sensor sends the measurement to the gateway that is responsible to communicate with the controller using a wired protocol (like Profibus or Fieldbus) and to send the control signal to the actuator using the wireless network. The communication between sensor, gateway and actuator is provided by the WirelessHART protocol (see Section 3.2) with a superframe size of 1 s and a time slot of 10 ms. All the settings of the wireless network are illustrated in figure The meanings of the parameter fields are explained in chapter 3. In order to simulate the correct behaviour of an AC800M controller the communication schedule follows the scheme explained in chapter 5. Considering this specific case with only one control loop the schedule will be: Figure 6.19: Communication schedule Looking at this schedule, it is possible to notice that after the transmission between the sensor and the gateway (S > GW ) there are some empties slots. These slots are left empty to simulate the same dead time of the case in which there are several loops. In 71

82 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol this specific scenario the time elapsed between sensing and actuating (dead-time) is 0.5 s. If the controller is affected by the clock drift the dead-time increases, conditioning the system performances. The clock drift in digital devices is usually around 10 5 but this value would require several hours of simulation before the delay appears in the system. Using a bigger value of the clock drift, the simulation needs less time and the results are not changed. Figure 6.20: WirelessHART parameters 72

83 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol For this reason the clock drift value has been fixed equal to in the controller kernel block (see Fig. 6.21). Figure 6.21: The drift field in the controller kernel block This setting means that the controller clock is faster than the simulation clock and it gains 5 s every 1000 s The stable model with PI and Predictive PI control In this section the performances of a PI controller and a Predictive PI will be compared in order to understand which is the best solution for the problem of the clock drift. Consider the stable model (6.39) and a square wave reference with a 50% duty cycle and period of 60 s. The controller parameters are computed following the lambda tuning rules explained in section With λ = T = 2 for this plant the resulting setting is K c = 4, T I = 2. where λ is the time constant of the closed loop. K = 0.25, λ = T = T I = 2 and T s =1. In this specific case has been chosen In case the controller suffers from clock drift, the performance decreases as it is shown in figure 6.22, where it is compared to the case without drift. In fact, as it is explained in section 6.1 the drift of the clock causes a delay of one cycle (in this scenario 1 s) when the control signal is computed after the actuation so the dead-time becomes equal to 1.5 s instead of 0.5 s. Looking at figure 6.22, it is possible to notice an overshoot in the reference tracking when the system is affected by the extra delay. This 73

84 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol Figure 6.22: Reference tracking using the PI controller both with drift and without overshoot disappears when the drift is equal to one cycle and the actuator task executes again after the controller. In section a Predictive PI controller (a simplified version of a Smith predictor) is introduced as a solution for the delay problem. Consider the PPI scheme in figure Figure 6.23: The PPI scheme The control signal is : Defining: U(s) = K c E(s) T I s e sd U(s) (6.41) the equation 6.41 becomes Z(s) = 1 U(s) (6.42) 1 + T I s U(s) = K c E(S) + Z(s)e sd (6.43) 74

85 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol To implement a digital PPI, it is necessary to convert to the discrete domain: z k = where a = e T s T I. The equation to update z k is : (1 a)q 1 1 aq 1 u k (6.44) z k = az k 1 + (1 a)u k 1 (6.45) Considering 6.43 and 6.45 it is possible to obtain the digital control command: u k = K c e k + z k 1 (6.46) In figure 6.24 the reference tracking for this implementation of the PPI is compared with the PI performance. Figure 6.24: Comparison of reference tracking between PI and PPI Looking at figure 6.24, it is possible to notice that when the system is affected by the delay, the step response of the PPI is better than the one of the PI. However, it is of course worse when the system has not extra delay, since the PPI is implemented considering a fixed delay of 1 s. For this reason the IAE (Integral Absolute Error) that is shown in figure 6.25 is bigger in case of PPI. 75

86 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol Figure 6.25: IAE : PI and PPI controllers The hybrid PPI controller To increase the performance of the controller, it is possible to notice that the control signal of the PPI (equation 6.41) in case of no delay (D=0) is equal to the PI control signal. Looking at (6.43) and considering the PPI implementation (equation 6.46) the hybrid controller can be described with the following equations: K c e k + z k, u k = K c e k + z k 1, if D=0; if D=1. (6.47) When the system is not affected by the delay, the controller is a normal PI. Then, when the drift of the clock causes a delay, the control switches to the Predictive PI. Like it is shown in figure 6.26, the controller can be described as a finite state machine with two states: one state is D=0 (no delay) and the controller is a normal PI, the other state is D=1 (delay of one cycle) and the controller is the Predictive PI. 76

87 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol The status changes depending on a variable that depends on the drift. Figure 6.26: Finite state machine: D=0 no delay, D=1 delay of 1 cycle Detection of the delay due to the drift The detection of the exact instant in which the drift introduces the delay is fundamental for the correct operation of the finite state machine. Assume that the controller has the possibility to synchronize its clock with the network clock. Considering this, the detection of the delay is easier : suppose that t d is the dead time of the system without the delay due to the drift (see figure 6.27), t s is the instant in which the sensor makes the measurement, t c the time when the controller computes the control signal and t exec the execution time of the control task, then the machine switches from one state to another under the following rule: 0, if t c t s < t d + t exec ; D = 1, else. Figure 6.27: Schedule of the tasks and detection of the delay 77

88 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol In the case of a synchronization mechanism not being available in the controller, an alternative solution is to consider a time stamp in the sensor data, t s, and to compare it with the instant in which the gateway transmits the control signal to the actuator (t GW ) (see Fig. 6.28). Figure 6.28: Scheme of the detection of the delay due to the drift Notice that all the times are referred to the internal clock of each device. Considering these notations the detection of the delay can be explained with the following equations: 0, if t GW t s < t d ; D = 1, else. This solution permits to detect the presence of the delay in the system but the switching between the two states will arrive one cycle later (see Fig. 6.29). Figure 6.29: Detection of the delay due to the drift is one cycle late 78

89 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol This is due to the fact that when the gateway executes, the controller has already done the computation for that cycle. An improvement to this law is obtained considering the trend of the difference t c t s. Figure 6.30: Detection of the delay due to the drift improvement In fact, as it is shown in figure 6.30, the difference between t c and t s is constant and changes only in the instant when the drift introduces the delay. Defining: the rule to switch between the two states becomes: t cs = t c t s (6.48) 0, if t GW t sc < t d ; D = 1, if t cs t 1 cs. Considering (6.47) the hybrid controller can be described by the following equations: K c e k + z k, if t GW t s < t d ; u k = K c e k + z k 1, if t cs t 1 cs. (6.49) In this way the transition between D=0 and D=1 happens immediately without loosing any cycle. 79

90 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol Comparison between the performance of the hybrid controller and the normal PPI In figure 6.31 the performance of the hybrid controller is compared with the behaviour of the previous implementation of the PPI and with the performance of a normal PI. Figure 6.31: Performance comparison between the hybrid controller, the PPI and the PI. Figure 6.32: IAE comparison between the hybrid controller, the PPI and the PI. From figures 6.31 and 6.32, it is possible to notice that the hybrid controller permits to have an integral absolute error of the same order of the PI but it is characterized by a 80

91 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol better step response. The hybrid controller is, hence, the best solution for this kind of process. Performance of the PPI and the PI with input disturbances In figure 6.33 the Simulink model of the control system with an input disturbance is shown. Figure 6.33: Simulink model of the system with input disturbance The disturbance is a square wave with an amplitude equal to 1, a period of 60 s and a duty cycle of 50%. The plot of the output signal and the IAE for both PPI and PI controllers is shown in figure 6.34 and Figure 6.34: System output with disturbance and drift 81

92 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol Figure 6.35: IAE with disturbance and drift From figure 6.34 and 6.35, it is evident that for a constant reference equal to zero, the integral absolute error is smaller in case of PI, but the output signal of the system has both an undershoot and an overshoot, instead the PPI has only the overshoot. If the reference is a square wave, the performances of the PI with disturbance decreases and its IAE error becomes greater than the one of the PPI (see Fig and Fig. 6.37). Figure 6.36: System output with disturbance, drift and a square wave reference 82

93 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol Figure 6.37: IAE with disturbance, drift and a square wave reference The Integrating process In this section the same analysis made for the stable model has been executed for an integrating process with the following transfer function: G(s) = 0.25 s (6.50) In this case the simulations are focused on the comparison between the performances of a normal PI controller and a modified Smith predictor. A delay due to the clock drift is considered. Assume the same PI controller implementation as in the previous case with a proper choice of the parameters. According to the PI tuning for integrating processes explained in section : λ = 1 K = 4 (6.51) T I = 2λ + D sys = 8.5 (6.52) Kc = T I 1.6 (6.53) K(λ + D sys ) 2 83

94 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol where D sys is the delay in the system without any drift. In figure 6.38 the tracking of a square wave reference with a period of 60 s and a duty cycle of 50% is plotted both for the PI with and without drift. Figure 6.38: System output using PI control with drift and without. As is expected, when the drift introduces the delay, the performance of the controller decreases. This is also visible in the plot of the IAE in figure 6.39 Figure 6.39: Integral Absolute Error using a PI control both with drift and without. In section a modified Smith predictor (MSP) was introduced to increase the performance of the control system in case of delay. In this section, the MSP is tested with the delay introduced by clock drift. The structure of the controller is described in figure

95 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol Figure 6.40: The modified Smith predictor for integrating process. C c (s) is a PI controller tuned for the system G(s) that is affected only by the normal dead-time, in this case 0.5 s (see subsection 6.6.1). e Ds is the delay introduced by the drift (in this case D = 1s) and P(s) is the real plant. The block F(s) permits to improve the performance in presence of delay and rejects possible input disturbances in the system. In the next simulations it is possible also to notice the fundamental role of this block in the stability of the close loop. Looking at the structure of the MSP (see figure 6.40) it is possible to derive the equations the digital controller task executes at each iteration: where a = e T s T i controller (see figure 6.40). w k = w k 1 + T s Kuc k 1 (6.54) x k = y k w k 1 (6.55) e k = r k (w k + x k ) (6.56) z k = az k 1 + (1 a)uc k 1 (6.57) uc k = k c e k + z k (6.58) u k = uc k F x k (6.59) and all the variables computed are indicated in the structure of the In figure 6.41, the behavior of this digital version of the modified Smith predictor, in case of drift, is shown in comparison with the PI controller. 85

96 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol Figure 6.41: Behaviour of the modified Smith predictor in presence of drift compared with the performance of the PI controller. Figure 6.42: Integral Absolute Error of the modified Smith predictor in presence of drift compared with the performance of the PI controller. From figure 6.42, it is evident that the modified Smith predictor increases the performance in presence of the delay. This simulation has been made choosing a constant F(s)= λ 30. This particular choice is due to the necessity to guarantee the stability of the closed loop and 86

97 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol in the same moment to have a good rejection of the input disturbances. In fact, a wrong choice of F(s) cause instability in the system if the drift introduces a delay of one second (see figure 6.43). Figure 6.43: Behavior of the modified Smith predictor in presence of drift with F=λ The hybrid improved Smith predictor In this section a hybrid solution is presented to combine the better behaviour of the modified Smith predictor in presence of delay, with the one of the PI when the system is not affected by the delay. In section a hybrid controller for the stable plants has been explained. Considering the same assumptions regarding the finite state machine described in section and using the same approach to detect the delay due to the clock drift, the hybrid control algorithm could be described by the following equations : if (t GW t sc < t d + t exec ) e k = r k y k z k = az k 1 + (1 a)uc k 1 u k = K c e k + z k if ( k cs k 1 cs ) w k = w k 1 + T s Kuc k 1 x k = y k w k 1 e k = r k (w k + x k ) z k = az k 1 + (1 a)uc k 1 uc k = K c e k + z k u k = uc k F x k 87

98 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol Figure 6.44: The system output using the hybrid controller compared with a normal PI and the MSP. The result of this controller is compared with the modified Smith predictor introduced in the previous section and with a normal PI (see Fig. 6.44). Figure 6.45: IAE of the hybrid controller compared with a normal PI and the MSP. The IAEs, of the hybrid controller and of the MSP, are of the same order. In fact, despite the hybrid Smith has a faster step response, the MSP has less overshoot (when the drift does not introduce the delay). This is due to the particular structure of the modified Smith predictor (see Sec ) in which the outer feedback makes the controller less aggressive than a normal PI. 88

99 6.6. Simulations of systems with delay due to clock drift using wirelesshart protocol Figure 6.46: Behaviour of the hybrid controller in presence of input disturbance for different choice of F. The rejection of the input disturbance, as it is described at the beginning of this section, depends on the block F(s). A comparison of the disturbance rejection using different F(s) is given in figure This plot shows that choosing F (s) = λ 30 the disturbance rejection and the delay compensation. is a good trade-off between 89

100 Chapter 7 Conclusions 7.1 Results The WirelessHART simulator made in this thesis work is a useful tool. It has permitted to do all the simulations studied in this project and will give a great help in the future analysis. The other modifications introduced in the TrueTime simulator give the possibility to have more detailed and realistic simulations. Considering the delay compensation study, it has been shown that the delay introduced by the clock drift of the controller is a problem. However, also having to work with these particular processes, there are many techniques to compensate this delay. These methods have been introduced and studied. For the first order case, a PPI controller with a hybrid solution has shown to give the best results. It is a very simple solution because it does not need the knowledge of all the plant model, but only the controller parameters. In the integrating case, the situation is a bit more complex. The PPI is not applicable and a modified Smith predictor is needed. It requires a model of the plant that has to be controlled. It is something not always easy or cheap to have. The results obtained for both the cases are, anyway, very positives and show that, when a synchronization between all the devices, which is of course the preferred solution, is not possible, the problem considered can be solved. 90

101 7.2. Open problems 7.2 Open problems Future work of this project will be the study of different processes and of different delay compensation methods. Considering the modified Smith predictor, the study of how the stability of the closed-loop system could be affected by different values of the parameter F is interesting. Considering, instead, the WirelessHART simulator, the implementation of the higher levels of the WirelessHART protocol and of the various commands that characterize it will be the aim of future studies. Also the implementation of a Network Manager, able to modified at run-time the devices table of WirelessHART, could open new possibility of study. It permits to modify dynamically the scheduling of the devices, making possible a more reliable structure of the network. 91

102 Appendix A How to install the tool A.1 Software Requirements TrueTime currently supports Matlab 7.x (R14 and later) with Simulink 6.x and Matlab (R13.1) with Simulink 5.1. Support for Matlab 6.1 (R12.1) with Simulink 4.1 was dropped in TrueTime 1.3. A C++ compiler is required to run TrueTime in the C++ version. For the Matlab version, pre-compiled files are provided in the archive that is downloaded from the TrueTime web site. The following compilers are currently supported (it may, of course, also work using other compilers): Visual Studio C (for all supported Matlab versions) for Windows gcc, g++ - GNU project C and C++ Compiler for LINUX and UNIX A.2 Installation Download and extract the compressed archive (truetime-1.5.zip), available at Extracting the file creates a truetime-1.5 directory, which will be referred to as $DIR in the sequel. Before starting Matlab, you must set the environment variable TTKERNEL to point to the directory with the TrueTime kernel files, $DIR/kernel. This is typically done in the following manner: Unix/Linux: export TTKERNEL=$DIR/kernel 92

103 A.3. Compilation Figure A.1: The TrueTime 1.5 block library. Windows: use Control Panel / System / Advanced / Environment Variables Then add the following lines to your Matlab startup script. This will set up all necessary paths to the TrueTime kernel files. addpath([getenv( TTKERNEL )]) init_truetime; Starting Matlab and issuing the command >> truetime from the Matlab prompt will now open the TrueTime block library, see Figure A.1. A.3 Compilation Since the TrueTime archive contains pre-compiled files, no compilation is required to run TrueTime with the M-file API. However, TrueTime also supports simulations written in C++ code, which then must be compiled. In this case, you first need to configure your C++ compiler in Matlab. This can be done by issuing the command >> mex -setup In the setup, make sure that you change from the Matlab default compiler to a proper C++ compiler. For more detailed instructions on how to compile individual simulations, see Section B.4 in this manual. 93

104 Appendix B How to use the Simulator B.1 Introduction This appendix describes the fundamental steps in the creation of a TrueTime simulation. This include how to write the code that is executed during simulation, how to configure the kernel and network blocks, and what compilation that must be performed to get an executable simulation. The code functions for the tasks and the initialization commands may be written either as C++ functions or as Matlab M-files. The TrueTime blocks are connected with ordinary Simulink blocks to form a real-time control system. Before a simulation can be run, however, it is necessary to initialize kernel blocks and network blocks, and to create tasks, interrupt handlers, timers, events, monitors, etc for the simulation. As mentioned above, the initialization code and the code that is executed during simulation may be written either as Matlab M-files or as C++ code (for increased simulation speed). How the code functions are defined and what must be provided during initialization will be described below. It will also be described how the code is compiled to executable Matlab code. B.2 Writing Code Functions The execution of tasks and interrupt handlers is defined by code functions. A code function is further divided into code segments according to the execution model shown in Figure B.1. All execution of user code is done in the beginning of each code segment. The execution time of each segment should be returned by the code function. 94

105 B.2. Writing Code Functions Figure B.1: The execution of user code is modeled by a sequence of segments executed in order by the kernel. B.2.1 Writing a Matlab Code Function The syntax of a Matlab code function implementing a simple P-controller is given by Listing B.1. The variable segment determines which segment that should be executed, and data is a user-defined data structure that has been associated with the task when it was created (see ttcreatetask and ttcreateperiodictask in the command reference). The data is updated and returned by the code function. The code function also returns the execution time of the executed segment. Table B.1: Example of a P-controller code function written in Matlab code. function [exectime, data] = Pcontroller(segment, data) switch segment, case 1, r = ttanalogin(1); y = ttanalogin(2); data.u = data.k * (r-y); exectime = 0.002; case 2, ttanalogout(1, data.u); exectime = -1; % finished end In this example, the execution time of the first segment is 2 ms. This means that the delay from input to output for this task will be at least 2 ms. However, preemption from higher priority tasks may cause the delay to be longer. The second segment returns a 95

106 B.2. Writing Code Functions negative execution time. This is used to indicate end of execution, i.e. that there are no more segments to execute. ttanalogin and ttanalogout are real-time primitives used to read and write signals to the environment. Detailed descriptions of these functions can be found in the command reference at the end of this manual. Table B.2: The C++ version of the code function in Listing B.1. double Pcontroller(int segment, void* data) { Task_Data* d = (Task_Data*) data; switch (segment) { case 1: double r = ttanalogin(1); double y = ttanalogin(2); d->u = d->k*(r-y); return 0.002; case 2: ttanalogout(1, d->u); return FINISHED; // end of execution } return FINISHED; // to supress compiler warnings } B.2.2 Writing a C++ Code Function Writing a code function in C++ follows a similar pattern as the code function described in Listing B.1. The corresponding C++ syntax for the P-controller code function is given in Listing B.2. We here assume the existence of a data structure Task Data that contains the control signal u and the controller gain, K. B.2.3 Calling Simulink Block Diagrams In both the C++ and m-file cases, it is possible to call Simulink block diagrams from within the code functions. This is a convenient way to implement controllers. Listing B.3 shows an example where the discrete PI-controller in Figure B.2 is used in a code function. See the command reference at the end of this manual for further explanation of the command ttcallblocksystem. 96

107 B.2. Writing Code Functions Figure B.2: Controllers represented using ordinary discrete Simulink blocks may be called from within the code functions. The only requirement is that the blocks are discrete with the sample time set to one. Table B.3: Simulink block diagrams are called from within code function using the TrueTime function ttcallblocksystem. function [exectime, data] = PIcode(segment, data) switch segment, case 1, inp(1) = ttanalogin(1); inp(2) = ttanalogin(2); outp = ttcallblocksystem(2, inp, PI_Controller ); data.u = outp(1); exectime = outp(2); case 2, ttanalogout(1, data.u); exectime = -1; % finished end 97