online admission control for multi-switch … · systems, the messages in the network may need to...

Marlardalen UniversitySchool of Innovation Design and Engineering

Vasteras, Sweden

Thesis for the Degree of Master of Science in Computer Science withSpecialization in Embedded Systems 30.0 credits

ONLINE ADMISSION CONTROL FORMULTI-SWITCH ETHERNET

NETWORKS

Yong [email protected]

Examiner: Thomas NolteMalardalen University, Vasteras, Sweden

Supervisor: Mohammad AshjaeiMalardalen University, Vasteras, Sweden

May 20, 2015

Malardalen University Master Thesis

Abstract

The trend of using switched Ethernet protocols in real-time domains, where timing requirementsexist, is increasing. This is mainly because of the features of switched Ethernet, such as its highthroughput and availability. Compared to other network technologies, switched Ethernet can supporthigher data rate. Besides the timing requirements, that must be fulfilled in real-time applications,another requirement is normally demanded in real-time systems. This requirement is the ability ofchanging, adding or removing the messages crossing the network during run-time. This ability isknown as on-line reconfiguration, and it should be done in a way that the real-time behavior of thenetwork is not violated. This means that, the guarantee of meeting the timing requirements for themessages should not be affected by the changes in the network. In this thesis, we focus on on-linereconfiguration for multi-hop HaRTES architecture, which is a real-time switched Ethernet network.The HaRTES switch is a modified Ethernet switch that provides real-time guarantees as well asan admission control to be used for on-line reconfiguration. We study the existing reconfigurationmethods including centralized and distributed approaches. Then, we propose a solution to provideon-line reconfiguration for the multi-hop HaRTES architecture, based on the studied methods. Forthis purpose, we use a hybrid method to achieve the advantages of both traditional centralized anddistributed approaches. Moreover, we perform two different experiments. In the first experimentwe focus on the decision making part of the method. The decision making part decides whether therequested reconfiguration is feasible. We calculate the time required to make the decision in dif-ferent network settings. In the second experiment, we focus on the entire reconfiguration process,where the decision making is part of it. Again, we show the time needed to do the reconfigurationin several network settings. Finally, we conclude the thesis by presenting possible future works.

Keywords: Online reconfiguration; Switched Ethernet; Real-time switched Ethernet; The HaRTESarchitecture; Response time analysis

1


Table of Contents

1 Introduction 51.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 Thesis Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Outline of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Background 82.1 Ethernet Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Real-Time Ethernet Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Ethernet Powerlink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2 PROFINET IRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.3 TTEthernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.4 Ethernet AVB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.5 The FTT-SE protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 The HaRTES Architecture 153.1 The HaRTES Switch Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 The Single-Switch HaRTES Architecture . . . . . . . . . . . . . . . . . . . . . . . . 153.3 The Multi-hop HaRTES Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.1 Multi-hop HaRTES Topology . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.2 Scheduling Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4 Response Time Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4.1 System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4.2 Response Time Analysis for Synchronous Message . . . . . . . . . . . . . . 193.4.3 Response Time Analysis for Asynchronous Message . . . . . . . . . . . . . 22

4 Problem Formulation 23

5 Solution Method 24

6 On-line Reconfiguration Design 256.1 Cluster-Tree Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.2 Dynamic Reconfiguration Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.2.1 Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.2.2 Feasibility Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.2.3 QoS Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.2.4 Mode-change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

7 Evaluation 317.1 Implementation of the Response Time Analysis . . . . . . . . . . . . . . . . . . . . 317.2 Decision Making of On-line Reconfiguration . . . . . . . . . . . . . . . . . . . . . . 347.3 The Reconfiguration Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

8 Related work 39

9 Conclusion 429.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

References 46

Appendix A Appendix A - Time Plan 46

2


Appendix B Appendix B - Response Time Functions 47B.1 Idle Time Calculation Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47B.2 Inflation Time Calculation Function . . . . . . . . . . . . . . . . . . . . . . . . . . 47B.3 Blocking Time Calculation Function . . . . . . . . . . . . . . . . . . . . . . . . . . 48B.4 Interference Time Calculation Function . . . . . . . . . . . . . . . . . . . . . . . . 48B.5 Switch Delay Calculation Function . . . . . . . . . . . . . . . . . . . . . . . . . . . 50B.6 Response Time Calculation Function . . . . . . . . . . . . . . . . . . . . . . . . . . 51B.7 Total Response Time Calculation Function . . . . . . . . . . . . . . . . . . . . . . 52

Appendix C Appendix C - Experimental Data 53C.1 The raw data for decision making time, EC=1ms LSW=70%EC . . . . . . . . . . 53C.2 The raw data for decision making time, EC=2ms LSW=70%EC . . . . . . . . . . 53C.3 The raw data for decision making time, EC=1ms Message Number=20 . . . . . . 53C.4 The raw data for reconfiguration process time, Period=50EC, EC=1ms, LSW=70%EC

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53C.5 The raw data for reconfiguration process time, Period=100EC, EC=1ms, LSW=70%EC

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54C.6 The raw data for reconfiguration process time, Period=50EC, EC=1ms, Message

Number=20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3


List of Figures

1 The Ethernet switch internal structure [1] . . . . . . . . . . . . . . . . . . . . . . . 82 Ethernet Powerlink Transmission Cycle [1] . . . . . . . . . . . . . . . . . . . . . . 93 PROFINET IRT communication cycle [2] . . . . . . . . . . . . . . . . . . . . . . . 104 TTEthernet communication cycles [3] . . . . . . . . . . . . . . . . . . . . . . . . . 115 Ethernet AVB Protocol Stack [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 The FTT-SE Overview [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Eelementary Cycle in the FTT-SE [1] . . . . . . . . . . . . . . . . . . . . . . . . . 148 Internal HaRTES Switch Structure [6] . . . . . . . . . . . . . . . . . . . . . . . . . 159 Elementary Cycle in the HaRTES architecture . . . . . . . . . . . . . . . . . . . . 1510 The HaRTES Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 1611 An example of single-switch HaRTES architecture . . . . . . . . . . . . . . . . . . 1712 Muti-Hop HaRTES Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1713 Operation of the RBS method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1814 The path links between source and destination nodes in the multi-hop HaRTES

architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1915 Switch delay of message m2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2116 Solution Method used in this thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 2417 Clusters in Multi-hop HaRTES architecture . . . . . . . . . . . . . . . . . . . . . . 2618 Reconfiguration process in Multi-hop HaRTES archeteture . . . . . . . . . . . . . . 2819 Reconfiguration process example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2920 The Network architecture under evaluation . . . . . . . . . . . . . . . . . . . . . . 3121 Message structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3122 Decision making for EC=1ms LSW=70%EC . . . . . . . . . . . . . . . . . . . . . 3523 Decision making for EC=2ms LSW=70%EC . . . . . . . . . . . . . . . . . . . . . 3524 Decision making time for changed LSW . . . . . . . . . . . . . . . . . . . . . . . . 3625 Reconfiguration process time, when Period= 50EC EC=1ms LSW=70%EC . . . . 3726 Reconfiguration process time, when Period= 100EC EC=1ms LSW=70%EC . . . 3727 Reconfiguration process time for changed LSW, when Period= 100EC EC=1ms . 3828 Time Plan of thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

List of Tables

1 EC=1ms LSW=70%EC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532 EC=2ms LSW=70%EC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533 EC=1ms Message Number=20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534 Period= 50EC EC=1ms LSW=70%EC . . . . . . . . . . . . . . . . . . . . . . . . . 535 Period= 100EC EC=1ms LSW=70%EC . . . . . . . . . . . . . . . . . . . . . . . . 546 Period=50EC, EC=1ms, Message Number=20 . . . . . . . . . . . . . . . . . . . . 54

4


1 Introduction

Over the last decades, Ethernet has been used widely in numerous industrial applications. Asa member of computer network technologies, Ethernet is based on the IEEE 802.3 standard.Currently, Ethernet still plays an essential part in construction of enterprise information system,intelligent building and the information superhighway. Ethernet has the following advantages:

1) High data transmission rateEthernet can provide four data rates, 10Mbps, 100Mbps, 1Gbps and 10Gbps;

2) Supporting various physical medium and topological structureEthernet supports a variety of transmission medium, including coaxial cable, twisted paircable, antenna, etc., therefore users could have a number of choices according to the band-width, range, price and other factors. Moreover, Ethernet supports Bus type and Star typetopology structure, which makes it scalable. It also uses a variety of redundant connectionmodes, which could improve the performance of the network;

3) Good open specificationEthernet, based on TCP/IP protocol , is an open network standard, and it is easy to be usedfor different manufacturers to interconnect their equipments. This feature is very suitable tosolve the problem of compatibility between different equipment manufacturers in the controlsystem and the interoperability problem. Ethernet is the most widely used LAN technology,and follows the international standard IEC/ISO802.3, with a wide range of technical support.Almost all programming languages support the development of Ethernet applications, suchas Java, VC++ and Visual Basic;

4) Low costIn the engineering and application field, due to the fact that Ethernet has been used for manyyears, it has a large number of experts that are familiar with Ethernet applications. Thereare a lot of technical experience that can be reused. A large number of existing resourcescan greatly reduce the development and training of Ethernet system maintenance, which caneffectively reduce the overall system cost. Besides, it can also accelerate the speed of systemdevelopment;

These above advantages make Ethernet a very suitable technology for industrial control systems.However, there still exists many problems with Ethernet when it is used in industrial applications.For example, Ethernet does not provide power, there must be an additional power supply cable.Ethernet in control systems requires more security controls, which can result in security vulnerabil-ities. Besides, the main problem in Ethernet is the use of Carrier Sense Multiple Access / CollisionDetection (CSMA/CD) arbitration mechanism. CSMA/CD leads to non-deterministic behavior ofdata transmission. Each node in the network sends the information by means of messages to thechannel. When nodes start transmission, they should also check whether there is a collision withother messages in the channel. If there is a collision, the node immediately stops sending. It waitsfor some unpredictable time, then starts retransmission. Thereforethe node may re-transmit manytimes. This behavior makes Ethernet non-deterministic, which is not desirable for safety criticalcontrol system and industrial applications.

In safety critical control system and industrial communications, the messages are transmittedwith specific requirements. Basically, the messages should be delivered within a specific time.These messages with timing constrains are called real-time messages. Standard Ethernet cannotsupport timing constraints due to the CSMA/CD arbitration. However, switched Ethernet is seenas a promising method to overcome that limitation, as it could eliminate the collision and supporttiming constraints.

The increasing use of switched Ethernet technologies in real-time domains such as in trains,air-crafts and industrial applications, becomes very common. The main reasons are its good fea-tures i.e. cost-effective, scalability, higher data rates and expandability. Switched Ethernet couldsupport throughput up to 100 Mbps in embedded systems, which is higher than other network

5


technologies. Moreover, switched Ethernet is flexible to connect with various elements in differenttopologies like Mesh, Star and Tree, which is convenient for switches to form a multi-hop architec-ture.

1.1 Motivation

However, many new requirements present new challenges to real-time network field. Those re-quirements include growing network complexity due to highly interactive functions [7], incorporat-ing with diverse traffic patterns (event-triggered, time-triggered) and on-line reconfiguration [8].Therefore, many Real-Time Ethernet (RTE) protocols, such as TTEthernet [9], Profinet [10], havedeveloped to meet some of these requirements. Despite a timeliness guarantee that is provided bythe RTE protocols, they still have limitations when applied in dynamic systems. In the dynamicsystems, the messages in the network may need to be added or removed during run-time. In orderto handle dynamic reconfiguration in real-time networked embedded system, the Hard Real-TimeEthernet Switching architecture (HaRTES) [11] has been developed. The HaRTES architecture isan enhanced Flexible Time Trigger (FTT) enabled switch, which is based on master-slave tech-nique. It supports both synchronous traffic i.e. real time periodic traffic, and asynchronous traffic,which composes real time sporadic traffic and other traffics. Moreover, a middle-ware[12] includedon-line admission control and Quality of Service(QoS) management, was proposed to support dy-namic reconfiguration. However, the proposed QoS management and on-line reconfiguration wereproposed for a small network with one switch in the network. As most of the network architec-tures have several switches, a multi-hop architecture is required. Therefore, admission control formulti-hop HaRTES architecture is required, which is the focus of this thesis.

1.2 Thesis Contributions

In this thesis, we work on on-line reconfiguration for multi-hop HaRTES architecture. The adap-tivity and on-line reconfiguration for a single-switch case was already investigated [12]. Currently,there is no protocol provided for dynamic reconfiguration in the multi-hop HaRTES architecture.Thus, in the beginning we investigate different reconfiguration methods, which are already pro-posed in the literature. Then, we present a protocol to reconfigure dynamic request change incontext of the multi-hop HaRTES architecture, without disrupting the real-time behavior of thesystem. This means that the proposed reconfiguration protocol does not cause a deadline miss forthe messages. Based on the discussed introduction and motivation, we formulate the goal of thethesis as below:

The goal of the thesis is to provide an on-line reconfiguration protocol for the multi-hop HaRTESarchitecture, such that it does not affect the timeliness guarantee of the network.

We achieve the main goal by presenting the following contributions:

• We study the state of the art regarding the reconfiguration methods as well as resourcereservation mechanisms in the network;

• We define a method to carry out the dynamic reconfiguration in the context of the multi-hopHaRTES architecture. For this purpose, we use a hybrid method to achieve the advantagesof both traditional centralized and distributed approaches;

• We evaluate the proposed protocol in two different experiments. In the first experiment,we evaluate the decision making part of the protocol, which decides whether the requestedreconfiguration is feasible. In the second experiment, we evaluate the reconfiguration time forthe whole reconfiguration process, including request sending, feasibility checking and systemupdating.

6


1.3 Outline of the Thesis

Our thesis consists of 9 chapters and the rest parts of the thesis are organized as follow.

• Chapter 2 illustrates background and some basic concepts related to the thesis. This includesthe basic concepts of the standard switched Ethernet protocol and the switch structure. Inaddition, the chapter mentions some limitations of using the standard Ethernet switch in real-time applications. Therefore, some solutions to overcome the limitations in the literature aredescribed in this chapter as well;

• Chapter 3 presents the HaRTES architecture, including the HaRTES switch internal struc-ture, the single switch forwarding method, and the multi-hop HaRTES forwarding method;

• Chapter 4 formulates the problem of performing reconfiguration in the multi-hop HaRTESarchitecture;

• Chapter 5 describes the research method during the thesis;

• Chapter 6 presents how to build cluster in the architecture, and proposes dynamic reconfig-uration protocol for the multi-hop HaRTES;

• Chapter 7 depicts two experiments to evaluate the proposed protocol in terms of decisionmaking time and reconfiguration time;

• Chapter 8 presents the state of the art regarding the reconfiguration mechanisms. Thischapter also provides the advantages of our mechanism compared with the state of the artsolutions;

• Chapter 9 contains conclusion and presents some directions for the future work of theHaRTES architecture.

7


2 Background

In this chapter, we firstly introduces some basic concepts about standard switched Ethernet technol-ogy. Then, we describe some of the solutions to tune switched Ethernet for real-time applications.

2.1 Ethernet Switch

Figure 1 shows a typical Ethernet switch structure. This switch contains receive ports, inputbuffers, a packet handling module, queue transmitting and output ports. The process for a mes-sage crossing a switch is depicted as follow steps. Firstly, switch receives a message and buffer itin input buffers. Then, the packet handling module is responsible to analyze the message and findits destination address. At last, the message is inserted into the destination queue. The outputqueue is First-In-First-Out (FIFO) model, i.e. the first coming message could be transmitted first,the messages are buffered based on their arrival time. Most switches are based on IEEE802.1DStandard that proposed up to 8 FIFO queues for each output port.

Figure 1: The Ethernet switch internal structure [1]

Switching techniques are used to transmit the packets among the switches through its channels.In general, Ethernet switches employ two common switch techniques: Store-and-Forward switching,Cut-Through switching.

Store-and-Forward switching

Store-and-Forward switching is the simplest switching technique among other switching tech-niques. In Store-and-Forward switching, switch stores the entire packet in the internal buffermemory before forwarding the packet to the next switch. Moreover, switch computes CyclicRedundancy Check (CRC) of each packet to check whether the packet is trustful or not. If aerror is found by CRC, the corresponding packet would be discarded. The packet cannot betransferred between the switches until the entire packet is received and stored in the switchsbuffer. The switch latency is big in this technique because switch checks the CRC of eachpacket.

Cut-Through switching

Cut-Through switching is an enhance version of Store-and-Forward method. This methodminimize the time to store packet in each switch since switch just buffer MAC address ofeach packet. When the packet enters a switch, the packets header can start to transfer assoon as the next channel is free. Therefore, its switch latency is less than Store-and-Forward

8


switching. However, Cut-Through switching may propagate the errors since it does not fullycheck the error of each packet.

2.2 Real-Time Ethernet Protocols

The standard switched Ethernet still shows some limitations when using in the real-time systems,such as the number of priority levels in the output queues is limited , and messages would bedropped when the buffer is full. When the output buffer is full, the arriving messages are dropped,which is a very undesirable situation in real-time systems. These limitations affect the Ethernetswitch to achieve real-time communication. In order to guarantee timeliness behavior in real-timeswitched Ethernet, several solutions were proposed. In the following sections, we present some ofthe solutions.

2.2.1 Ethernet Powerlink

Ethernet Powerlink(EPL) [13] is a master/slave protocol supported by Ethernet Powerlink Stan-dardization Group. It provides deterministic real-time communication and supports periodic(Isochronous) traffic and asynchronous traffic. In EPL, a fix time-slot that is used to organizecommunication, is called cycle. In Figure 2, each EPL cycle composes four periods:

1) Start period, where the master sends a SoC message(start of cycle ) in order to notify slavenodes at the beginning of EPL cycle;

2) Isochronous period, the master sends a Poll Request to each slave node in a polling way ac-cording to the predefined one-way sequence. Once slave node receives a Poll Request, slavenode responds by transmitting the corresponding data message (Poll Response). At the sametime, all the other slave nodes (including those who should receive the frame of the nodes)can receive, supervise the Poll Response frames. After all slave nodes sending their PollResponse, the master sends an End of Cycle message, which is transmitted until the end ofthe isochronous period;

3) Asynchronous period, in which only one asynchronous message could be transferred. Themaster grants a node and sends a start of asynchronous (SoA) message to that the selectednode, the node gives a reply to SoA message;

4) Idle period, which is aimed to enforce a precise cycle start with low jitter.

Figure 2: Ethernet Powerlink Transmission Cycle [1]

2.2.2 PROFINET IRT

PROFINET IRT is a modified standard Ethernet protocol developed by PROFIBUS and PROFINETInternational for industrial automation. PROFINET IRT defines fast real-time data exchangein distributed architecture, whose cycle time is down to less than 1 millisecond. Therefore,

9


PROFINET-IRT [14] is ideal for applications where motion control is critical to production cycles;high performance industry automation applications, which requires a cycle time in a few hundredmicroseconds. Figure 3 illustrates PROFINET IRT communication cycle. Each cycle is composedof two channels:

1) Isochronous Communication Channel, which is conveying static time to schedule real-timecommunications;

2) TCP/IP Communication Channel, which is used to transmit address for synchronous andasynchronous messages.

Figure 3: PROFINET IRT communication cycle [2]

Compared with PROFINET RT, PROFINET IRT takes advantages of its bandwidth reserva-tion and its advanced scheduler. When using PROFINET IRT, the industrial economy requiresextra bandwidth, fast delivery of data stored in the super-critical part. When a priority messageis transmitted, dedicated reservation bandwidth for seamless transfer offers as soon as possible sothat the message can be delivered.

Another feature of PROFINET IRT is its scheduler. Depending on the intended message whereit is at a place of production data transfer cycle. The scheduler guarantees that the data message,which is based on the time required for the device, is sent. It also ensure that the manufacturingprocess of receiving message in device is as expected.

2.2.3 TTEthernet

TTEthernet [9] is a scalable switched Ethernet and is optimized for time-triggered transmissionwhich is based on IEEE 802.3 standard. TTEthernet protocol defines how to implement highprecision time synchronization in a standard Ethernet. Moreover, TTEthernet provides severaltraffic classes, Figure 4 shows three types of traffics:

1) Time-Triggered(TT) traffic, transmission is according a predefined communication schedule;

2) Rate-Constrained(RC) traffic, enforces minimum duration between two frames of the samestream;

3) Best-Effort(BE) traffic, standard Ethernet communication paradigm and no temporal guaran-tees are given.

10


Figure 4: TTEthernet communication cycles [3]

In TTEthernet protocol, TT traffic has the highest priority. Therefore, TT messages are asso-ciated with hard real-time communication, with low latency. The transmission of these messagesare followed a TDMA policy. RC traffic, based on event-triggered, is used by applications with lessstringent real-time requirements than time-triggered systems. RC frame delivery is guaranteed,but potentially has high latency and jitter. BE traffic is transmitted in the free bandwidth left byother two traffic classes. Best-effort frame delivery (standard Ethernet traffic) is not guaranteed.However, the high priority TT traffic may be blocked from the low priority traffic RC and BEtraffics. Thus, TTEthernet proposed three methods to solve the problem, which are preemption,timely block and shuffling.

2.2.4 Ethernet AVB

Ethernet Audio Video Bridging (Ethernet AVB) technology is potential and promising technologyin the real-time audio and video transmission network. Ethernet AVB is mostly used in automotiveindustry. It is compatible with the standard Ethernet data transmission. In addition, EthernetAVB ensures the transmission of real-time stream. It could provide high reliability, low latency,and low cost of implementation for real-time audio and video streaming data transmission. As itis shown in Figure 5, Ethernet AVB protocol stack includes five protocols, PTP (Precision TimeProtocol), SRP (Stream Reservation Protocol), QFP (Queuing and Forwarding Protocol), AVBTP(Audio/Video Bridging Transport Protocol) and RTP (Real-time Transport Protocol) respectively[15, 16].

Figure 5: Ethernet AVB Protocol Stack [4]

11


PTP: Its prototype is IEEEP1588 V2, the original IP routing protocol is applied to a localarea Ethernet network which only has two-layer structure. PTP mainly includes two aspects, oneaspect is the choice of the master clock, another is a synchronization mechanism that contains timecompensation and clock frequency match. PTP selects a master clock in PTP domain through thebest master clock algorithm, as the root. The root is to establish the spanning tree which is usedto synchronize. Each time-sensitive device node must be synchronized with the master clock. Inthe local network, in the meantime, PTP defines a number of potential master clock in case of nodefailure. When the node fails to access the main clock, PTP can automatically switch to one of thepotential main clock and establish the appropriate spanning tree, to ensure network clock synchro-nization. After the master clock is determined, PTP sends a synchronization message through thetime-stamp mechanism, and transfers the times-tamp through a conventional Ethernet packets.When the message transmit to the port which needs clock synchronization, it will be comparedwith the local clock synchronization, using corresponding path delay compensation algorithm tomatch the local clock. After the clock matched, the slave node sends a message containing a timestamp, and match the clock synchronization in the next slave nodes.

SRP: In order to ensure QoS of data transmission and forwarding, reducing latency and jitter,SRP, based on the bandwidth of the network topology, locks the transmission path in advance,and sets aside a portion of the bandwidth to ensure inter-end bandwidth availability of streamingaudio and video equipment. SRP utilizes SP (Signaling Protocol) and multi-function expansion ofIEEE802.1 MRP (Multiple Registration Protocol) to exchange the description message of band-width audio and video streams, and reserves bandwidth resources. In general, the 75 percent ofthe whole bandwidth is reserved for audio and video time-sensitive data streams, the remaining 25percent is used to transmit conventional Ethernet data.

QFP: It is an accompanied protocol in AVB protocol stack, and most of the implementation arein the switch. The main responsibilities of QFP are processing and forwarding data transmission,ensuring that traditional Ethernet data traffic cannot interfere with the real-time audio and videostreaming. QFP mainly includes three parts, traffic shaping, prioritization and queue management.In order to avoid the completion for bandwidth between time-sensitive audio-video streaming dataand general data, Ethernet AVB switch has several input and output queues, audio-video stream-ing data and general data could be transmitted into different queues. All switches and bridges areusing priority transmission selection algorithm, and give the highest priority of audio and videostreaming data.

In addition, AVB TP is mainly responsible for packeting real-time streaming data in EthernetAVB. Meanwhile, it is also responsible to establish stream, control stream, and end up stream.The RTP, based on three-layer application of IP, takes advantage of performance of EthernetAVB, which provides time synchronization in the LAN, latency and bandwidth reservation servicethrough bridging and routing.

2.2.5 The FTT-SE protocol

The Flexible Time Trigger Switched Ethernet (FTT-SE) protocol is based on the Flexible TimeTrigger (FTT) scheme which provides real-time communication service. The FTT-SE architectureexploits master/slave technique in which the master node is responsible to control transmissionsof the salve nodes. Master node in the FTT-SE architecture is connected with one port of otherswitch ports, as it is depicted in Figure 6.

12


Figure 6: The FTT-SE Overview [5]

In the FTT-SE architecture, Elementary Cycles(EC) are fixed duration time-slots for datatransmission. The master node schedules the messages for transmission within the ECs and putsthe scheduling decision through a special message, which is called Trigger Message (TM). Then,master node broadcasts TM to all nodes. Each EC is composed of two different windows, syn-chronous window and asynchronous window, to handle synchronous traffic and asynchronous trafficrespectively. Figure 7 depicts EC in the FTT-SE protocol.

13


Figure 7: Eelementary Cycle in the FTT-SE [1]

The master node not only employs any kinds of scheduling policies, but also performs reconfig-uration to meet communication requirements. The last feature involves on-line admission control,removing message under guarantee timeliness and dynamic band-width reservation. The FTT-SEprotocol has a distinctive feature in handling asynchronous traffic. The slaves node are of event-driven model, which trigger asynchronous traffic. The FTT-SE protocol uses a specific messageto notify asynchronous messages to master node, which follows a signaling mechanism. Once themaster node receives all asynchronous messages, it schedules them and sends new traffic schedulingfor upcoming EC. The FTT-SE protocol makes use of full-duplex links so that master node couldreceive slave nodes’ asynchronous traffic queues, while it could also send the TM to slave nodes atthe same time [17].

14


3 The HaRTES Architecture

Although the previous presented protocols have advantages in supporting real-time communica-tion, there still exits some limitations. For example, some of the presented real-time protocols arefit in a static reconfiguration for real-time communication, the on-line reconfiguration for real-timetraffic is only available in SRP protocol. Therefore, we focus on the FTT-enabled switch, namelyHaRTES architecture, which can provide on-line admission control, dynamic QOS managementand arbitrary traffic scheduling policies.

3.1 The HaRTES Switch Structure

The internal HaRTES structure is depicted in Figure 8. The packet classification is used to clas-sify the arriving packets at input ports, it distinguishes the traffic types and sends the packetsto memory pool. The master module consists of admission control, scheduler, Quality of Service(QoS) management and one repository that stores traffic attributes such as message length, dead-line, period, etc. When one message stream is added, removed, or their properties are changed,the traffic needs on-line reconfiguration. Admission control unit handles requests for adding newmessages, executes an adequate analysis and decided whether the message can be accepted or not.If the message can be accepted, then the necessary changes in the system must be made to accom-modate the new message. The packet forwarding module checks the packet type and puts it intothe corresponding output queue. Three FIFO queues are used to handle three different packets(Synchronous, Asynchronous, None-Real-Time) in each output port. The function of dispatcher isto handle the packet transmission in reserved bandwidths and to enforce temporal isolation.

Figure 8: Internal HaRTES Switch Structure [6]

3.2 The Single-Switch HaRTES Architecture

In single-switch HaRTES architecture, message communication is scheduled by master module ina time duration slots, namely Elementary Cycle (EC). As shown in Figure 9, each EC containstwo windows, synchronous window and asynchronous window. Synchronous window is used totransmit synchronous traffic, while asynchronous window transmits asynchronous traffic and thenon-real-time traffic. A particular message, which is sent by master to all slave nodes, is calledtrigger message(TM). TM contains the ID of the scheduled messages for the following EC [8].

Figure 9: Elementary Cycle in the HaRTES architecture

15


HaRTES architecture supports all traffic types i.e. periodic traffic, sporadic traffic and non-real-time traffic. Based on traffic patterns, traffic can be divided into synchronous traffic that istime-triggered event, asynchronous traffic that is caused by event-triggered event, and non-real-time traffic. The HaRTES integrates FTT master in the switch as shown in Figure 10. Besides,it obtains some important features compared with the FTT-SE protocol. For example, improv-ing performance in handling asynchronous traffic, which is autonomously transmitting withouttriggering by the master. Moreover, it maintains temporal isolation [18].

Figure 10: The HaRTES Architecture Overview

A single-switch HaRTES architecture example is depicted in Figure 11 . Only one HaRTESswitch connects several nodes in the architecture. The switch acts as master node to scheduletransmission to all slave nodes.

16


Figure 11: An example of single-switch HaRTES architecture

3.3 The Multi-hop HaRTES Architecture

With the development of industry, the networks in industrial applications require more than hun-dreds nodes, this means a single switch cannot meet that requirement. The multi-hop architectureis developed to overcome the mentioned limitation. In this part, we describe a multi-hop HaRTEStopology and a scheduling method to handle the traffic forwarding in this architecture.

3.3.1 Multi-hop HaRTES Topology

Multiple HaRTES switches are connected with each other to form a tree topology. An example ofmulti-hop HaRTES architecture is depicted in Figure 12.

Figure 12: Muti-Hop HaRTES Topology

17


3.3.2 Scheduling Methods

Two scheduling methods are proposed in [8, 11], namely Distributed Global Scheduling(DGS)and Reduced Buffering Scheme(RBS), to handle traffic forwarding through the multiple switches.In this section, we only describe the RBS method in details, as it provides better performancecompared with the DGS method. Furthermore, we explain the on-line reconfiguration process inthe context of the RBS method.

In the RBS method, message that needs to be sent from source slave node to destination slavenode, would not be buffered in each involved switch. Firstly, switch that is connected to sourcenode, schedules the message and buffers it. The switch forwards the message until there is notenough time in the associate window of the current EC, then, next switch buffers the message andcontinues the same procedure.

Figure 13 illustrates the operation of message forwarding in the RBS method. We assumethat source node S1 sends a message M1 to destination node S2 in network as shown in Figure12. The message M1 is activated in ECk, then switch H2 schedules it and buffers it in its ownmemory. Then, switch H1 inserts the message into its output link. Since there is still enoughtime in the synchronous window in current EC, switch H2 forwards the message to switch H1.Switch H1 do the same operation as switch H2 did, if there is still enough time in the synchronouswindow. Since there is not enough time to forward message M1 from switch H1 to switch H3 incurrent synchronous window, the transmission of message is suspended in switch H3. In ECk+1,the message is buffered in switch H3. Switch H3 receives the message from switch H1, schedules itand forwards the message to destination node S2, in ECk+1.

Figure 13: Operation of the RBS method

The asynchronous messages are forwarded in the same manner as synchronous messages.Thedifferences exist as below:

• In the HaRTES architecture, asynchronous messages that are triggered by slave nodes, aresent autonomously to a switch without being triggered by the switch, while the synchronousmessages are transmitted to the switch upon receiving the TM.

18


• In the HaRTES architecture, asynchronous messages are transmitted in asynchronous win-dow, while synchronous messages are in synchronous window.

3.4 Response Time Analysis

In this section, we depict the response time analysis in details which presented in [8]. First, wedefine a system model that represents the messages in the HaRTES architecture network. Then,we explain the response time analysis for two types of message, i.e., synchronous and asynchronous,in details.

3.4.1 System Model

The message model for both synchronous and asynchronous messages is presented in Expression1:

Γ = mi(Ci, Di, Ti, Pi, RTi, Li, ni, Pki), i = 1 · · ·N (1)

In the system model, each message consists of several parameters. Ci is the transmission timeof message mi. Di indicates the deadline of mi, while Ti is the period of message mi. Pi is thepriority of message mi. Note that the value of priority must be an integer number. RTi is used tostore the response time of message mi. Pki indicates the packet size that composes message mi.Li represent the transmission path of mi, which consists of path links between the source nodeto destination node. Besides, ni shows the number of links in Li. For example, node A sends amessage m1 to node B as show in Figure 14. The transmission path of m1 includes link 2, link 1,link 3. The number of links in L1 is 3. The transmission path of message m1 and its links numberare shown as below.

L1 = [2, 1, 3], n1 = 3

Figure 14: The path links between source and destination nodes in the multi-hop HaRTES archi-tecture

In this model, the total response time of mi is the time duration from source node initiates thetransmission of a message to destination node receives the message. Moreover, a response timebetween two links (la and lb) is defined, which is the time duration a message crosses between thementioned links. This response time is denoted by RTi,a,b.

3.4.2 Response Time Analysis for Synchronous Message

We calculate total response time of mi by Algorithm 1. In the first three line of the algorithm,we initialize the total response time of message mi (RTi), and the links that are included in themessage mi. In line 4, if the last link of message mi is not included in response time calculation,

19


the loops carry on. Line 5 illustrates the response time calculation between link la and link lb. Theresponse time of message mi is expressed in an integer number of ECs by using ceiling function inline 6. As the RBS method described before, the message will be buffered in switch if the responsetime of the current link is not equal to the response time of previous link. In this situation, theresponse time of previous link is added into the total response time. Meanwhile, the start linkis set to current link. Otherwise, the algorithm continues to calculate the response time of nextlink. This process can be shown in line 7 to line 12. In the last three lines of the algorithm, thealgorithm calculates the response time until the last link of message mi and response time of thelast link is also added into total response time.

Algorithm 1 Total Response Time Calculation for mi

Initialization:1: The total response time, RTi = 0;2: The start link, a = 13: The next link, b = 1;

Iteration:4: while b ≤ ni do5: rti,a,b = responseT imeCalc(i, a, b)

6: RTi,a,b = d rti,a,b

EC e7: if (a! = b)&(RTi,a,b! = RTi,a,(b−1)) then8: RTi = RTi +RTi,a,(b−1)9: a = b

10: else11: b = b+ 112: end if13: end while14: RTi = RTi +RTi,a,(b−1)15: Return RTi

Take an example to explain mentioned algorithm, we assume that node A sends a message m1

to node B in Figure 14. To calculate the total response time of message m1, the following steps areneeded. At first, we need to calculate the response time of start link, i.e. link 2, and the responsetime of first two links, i.e., link2 and link 1. Then, we compared the values of two response time.If they are equal, then, we calculate the response time of the first three links. However, if the twovalues of response time are not equal to each other. The response time of first link is added intothe total response time, meanwhile, the start link is set to the second link, i.e., link 1. We followthe same steps as before and calculate the response time until the last link. At last, we add theresponse time of the last link into total response time.

In Algorithm 1, the function of response time calculation between link la and link lb is shownin line 5. This response time is calculated in Equation 2. As the message is transmitted in thespecified synchronous window, not other times in the EC, the inflation factor should be defined.

rtxi,a,b =Ciαi,a,b

+ Ii,a,b +Bi,a,b + SDi,a,b (2)

The response time of messagemi, rti,a,b includes four parts: (i) the inflated transmission time Ci

αi,a,b,

(ii) the interference from higher priority messages that share links with mi, Ii,a,b , (iii) the blockingtime, Bi,a,b is caused by the messages with lower priority that share the link between la and linklb, (iv) the switch delaying, SDi,a,b consists of the hardware fabric latency, store and forward delay.

The initial response time of rt0i,a,b is the message’s inflated transmission time Ci

αi,a,b, we iterate

calculation rtxi,a,b until rtxi,a,b is equal to rtx−1i,a,b. Then, the response time of message mi is equal tortxi,a,b.

rti,a,b = rtxi,a,b When rtxi,a,b = rtx−1i,a,b (3)

20


The idle time in the EC for mi is denoted by Idi,l and αi,a,b represents inflation factor betweenla and link lb for mi. Idi,l and αi,a,b are computed in Equation 4 and Equation 5, respectively. InEquation 4, Pk represents packet size of message. LWl means length of transmission window inlink linkl. hep(mi) means the message that have higher or the same priority than mi.

Idi,l = max∀r∈[1,N ]

∧mr∈hep(mi)∧l∈Lr

(PKr, PKi) (4)

αi,a,b =

minl=a···b

(LWl − Idi,l)

EC(5)

The interference time is caused by messages that have higher or the same priority than mi.This interference is calculated in Equation 6.

Ii,a,b =∑

∀r∈[1,N ],i6=j∧mj∈hep(mi)∧Lj∩Li,a,b 6=0

⌈rt

(x−1)i,a,b

Tj

⌉Cjαi,a,b

(6)

The blocking time Bi,a,b, is caused by the messages with lower priority that shares the linkbetween la and link lb in transmission path of message mi. For example, a message mi is insertedto output queue, while a low priority message mj is transmitted with the same queue. Therefore,mi is blocked by mj . The blocking time of message mi is calculated in Equation 7. lp(mi) meansmessages that have lower priority than message mi.

Bi,a,b =∑

t=a+1...b,a6=b

max∀p∈[1,N ],

∧mp∈lp(mi)

∧lt∈Lp

∨∀y,a+1≤y≺t,ly /∈Lp

PKp

αi,a,b(7)

The switching delay SDi,a,b, consists of hardware fabric latency which is a constant value, andstore-and-forward delay which is the time to buffer message mi in the switch before transmitted.When message mi crosses through a switch, no matter the message is preempted or blocked byother message, the switch delay of mi exists. However, when calculating the switch delay of mi,we also need to consider the effect from other messages. In the worst-case, according to [8], themaximum transmission time of all messages crossing from the same input and output ports shouldbe considered for the switching delay. As shown in Figure 15, when m1 is transmitted into itsoutput link, m2 is waiting to be transmitted until m1 done. In this scenario, when calculating theswitch delay time for m2, we need also take the switch delay time of m1 into account.

Figure 15: Switch delay of message m2

21


In general, the switching delay time of message mi is calculated in 8. All messages that haveeither higher or lower priority than the priority of message mi, are taken into account.

SDi,a,b =∑

t=a+1...b,a6=b

max∀q∈[1,N ],

∧lt∈Lq

∨l(t−1)∈Lq

(SWDi, SWDq

αi,a,b

)(8)

3.4.3 Response Time Analysis for Asynchronous Message

The response time analysis of asynchronous message is similar to the process that is done forsynchronous message. The main difference is that asynchronous messages are transmitted in asyn-chronous window. Therefore, the asynchronous message cannot interfere to the transmission ofsynchronous message. Besides, the inflation factor is also considered in the asynchronous window.

22


4 Problem Formulation

The on-line reconfiguration for dynamic systems follows four steps in general. The first step isthat a negotiation is communicated between slave node and master node. The slave node requiresa request change and sends the request to master switch. The request is usually caused by a slavenode removing, adding message stream, or changing some parameters in message stream. The sec-ond step is implementing Admission Control in master node. Admission control is used to handlethe request and verify the request changes. Therefore, response time analysis or utilization boundcan be used to measure the feasibility in the second step. The third step is resource reservation forthe message streams. QoS management is used to distribute the reserved resource. At last, mode-change is needed, where all nodes are updating their databases. In order to guarantee timelinessof the system, this transition should be done in a bounded time, and consistently.

The on-line reconfiguration for single-switch HaRTES architecture is similar to the one pro-posed in the FTT-SE protocol, as they use the same concepts for message transmission. The on-linereconfiguration for the FTT-SE is presented in [12]. The proposed protocol, however, cannot beused in the multi-hop HaRTES architecture, as there are several master nodes in the network.Therefore, all the master nodes should agree on the requested changes, and they should applythe new changes at the same time to achieve the consistency. Moreover, the data transmissionfollows different methods, as it uses the RBS method. This affects the negotiation phase of thereconfiguration, where the nodes should send their requests using the RBS method. Consideringthe mentioned differences, we need a new protocol for multi-hop HaRTES architecture to achieveon-line reconfiguration.

In this thesis, we define an on-line reconfiguration protocol for the multi-hop HaRTES archi-tecture. The main problems are the admission control process, negotiation between the masternode and slave node, and updating the network based on the changes. Based on the introductionthroughout this thesis, we address the following research questions:

1. What are the steps toward achieving the on-line reconfiguration in multi-hop HaRTES archi-tecture?

2. How many admission control units are required in the network to perform the reconfiguration?

3. Where the admission control units should be located in the architecture to achieve a fast andefficient request and update handling?

4. What are the criteria to measure the performance of the proposed on-line reconfigurationmethod?

23


5 Solution Method

In order to perform the thesis in a structure way, we follow several steps. In the first step, wereviewed the state of the art, in two different directions: (i) reviewing the switched Ethernetprotocols in real-time systems, (ii) the reconfiguration mechanisms in the same contexts. Then,we performed a detail study on the HaRTES architecture, as the main part of thesis is focusedon this protocol. In third step, we proposed a reconfiguration protocol according to the identifiedrequirement. In the next step, we compared the solution with other existing solutions, and wetuned that to achieve better performance. Then, we evaluate the proposed solution in terms ofoverall performance of the protocol. The flow of solution method is shown in Figure 16.

Figure 16: Solution Method used in this thesis

24


6 On-line Reconfiguration Design

In this chapter, we propose a protocol to achieve on-line reconfiguration for the multi-hop HaRTESarchitecture. In order to define our reconfiguration protocol, we divide the network into severalclusters. In this section, we first explain how to split the network to clusters, then we present theprotocol itself.

6.1 Cluster-Tree Topology

Cluster-based technique is a well-known method and is widely used in Wireless Sensors Network(WSN) field [19]. The basic principle of the cluster-based technique is that the nodes in archi-tecture are classified into several groups called clusters. There is a node that would be selectedas cluster head (CH) in each cluster. The functions of CH are to collect data from other clus-ter members, aggregate, and forward the compact information to a base station. By using thisprinciple, it is able to reduce the amount of data transferred within the network and have highlyenergy-efficient operation of WSNs. Moreover, the cluster-based technique has some advantagesrelated to scalability as well as efficient communication. It decreases the overheads occurred dueto communication, thereby reducing interferences and energy consumptions among network nodes.

We adopt the cluster-based technique in the context of the multi-hop HaRTES architecture,to take the advantages of such technique. Before we propose an algorithm to set up clusters inmulti-hop HaRTES network, some parameters of tree topology need to be explained.

• Root switch – the switch on top of the network hierarchy

• Parent switch – a switch in which several nodes and switches are connected to it, and it isresponsible for collecting requests in the cluster-tree topology

• Cluster – a group of nodes and switches with one single parent switch

In order to divide the multi-hop HaRTES network into the clusters, we follow a bottom-up algo-rithm. This means that we start from the switches in the lower hierarchy level. We select theswitches with one parent switch, together with their nodes, and we grouped them as one cluster.Then, we move to the upper level, and we select the parent switch with the switches and nodes,which do not belong to any cluster, as another cluster.

25


Figure 17: Clusters in Multi-hop HaRTES architecture

For example, as shown in Figure 17, this is a hybrid HaRTES tree topology with 9 switches.We start to assign clusters from the bottom, therefore, switch 1, switch 2 and their parent switch(switch 3) can be grouped as cluster 1. Switch 3 is the cluster head in cluster 1 , as it is theparent for the others. Then, for the left switches that are located next to the bottom, we followthe method as before, cluster 2 consists of switch 4 and switch 5, while its cluster head is switch4. Cluster 3 includes switch 8, switch 9 and their parent switch (switch 7), while switch 7 is itscluster head. When we assign new cluster for left switches, only switch 6 left. Therefore, the rootswitch (switch 6) forms a cluster 4, while it is also the cluster head in cluster 4.

6.2 Dynamic Reconfiguration Method

As it is described before, the process of on-line reconfiguration consists of four steps. Here, weexplain each steps in details.

6.2.1 Request

In this step, a node that has a request to change, i.e. adding or removing a message, will send thisrequest to its cluster head. This request is sent by a sporadic message through the asynchronouswindow of the EC. Moreover, the request message has the highest priority message among otherdata messages, so that it can be delivered as short time as possible. As the request message is areal-time message, the response time of that is bounded.

6.2.2 Feasibility Check

The cluster head receives the request from one of the nodes inside the cluster. At this step, thecluster head should check the feasibility of the requested change. This checking is done using theresponse time analysis presented in this thesis. Basically, the cluster head computes the responsetime for all the messages in the network considering the requested change. If all the messages meet

26


their deadline in the new settings, then the reconfiguration is accepted. Otherwise, if at least oneof the messages does not meet their deadlines, the reconfiguration request must be rejected. In caseof reject, the cluster head sends an update message to the node who requested the reconfigurationinforming that about the rejection. However, in case of acceptance, the cluster header not onlymust inform the nodes inside its cluster about the change, but also it should inform other nodesin the other clusters. An important issue is that, in case of mode-change all nodes and switchesmust change their mode at the same time to keep the consistency of the system. Therefore, theinformation about the time that the system must do the mode-change should be sent to othernodes as well. In order to do that, the cluster head, computes the time it takes for the updatemessage to reach to all the nodes in the network, and set that time for the mode-change. Thistime is encoded in the update message. More details on update message is described in Section6.2.4.

6.2.3 QoS Management

The QoS management is done inside the cluster head. After feasibility check, the cluster headchecks how much bandwidth is available, and how much is used by the new change. This infor-mation is saved in the cluster head for future bandwidth distribution. However, the focus of thethesis is not bandwidth redistribution, thus this part remains for the future work.

6.2.4 Mode-change

In the last step, the new mode should be sent to other nodes in the network. This information issent by a sporadic message through the asynchronous window in the EC. This message is sent firstto the other cluster heads, then those cluster heads are responsible to inform their cluster nodes.As the update message is a real-time asynchronous message, its response time is bounded.

27


Figure 18: Reconfiguration process in Multi-hop HaRTES archeteture

The entire process of the on-line reconfiguration is shown in Figure 19. In order to show theprocess in details, we explain an example. We assume the hybrid architecture is shown in Figure17. One slave node S1 in cluster 1 issues a request. Slave node S1 sends the request to its clusterhead SW3 through a slv−request message. Cluster head SW3 calculates the feasibility of requestchange. We assume that this request change is accepted. At time t1, cluster head SW3 informsthe result of request change to other cluster heads through a ch−update message. Then all clusterheads update their master switches and nodes through a slv−update message. The process of thereconfiguration for the depicted example is shown in Figure 19.

It may occur that several nodes initiate several reconfiguration requests to their cluster heads.Assume that in the worst-case several cluster heads accept the requested change. In this case therewill be several conflicting update messages propagated in the network. This causes an inconsis-tency in the network. In order to solve this problem, if a node or switch receives two consecutiveupdate messages, it applies the one that has the latest mode-change time encoded in the message.As all the nodes and switches follow this rule, they all apply the same update message.

28


Figure 19: Reconfiguration process example

29


6.3 Discussion

The proposed on-line reconfiguration protocol is a combination of centralized and distributed ap-proaches. In the centralized approach, there is one specific node, as a management node, in thenetwork responsible to decide on the acceptance or rejection of the request. This means all thenodes must send their reconfiguration requests to the management node for the decision. Therefore,in a large network, the request and update messages are sent through several links. Moreover, asthere is one node performing the process, the node should be strong enough to handle all requestsin the network. On the other hand, in the distributed reconfiguration, all nodes cooperate on thedecision. This was there is no need for a high performance node. However, there are many requestand update messages could be transmitted through the network.

In our protocol, we used a hybrid approach in which several nodes are responsible for recon-figuration, similar to the distributed approach. However, the number of nodes for the process areless. We divided the network into a number of clusters. Each cluster has a specific head to do thereconfiguration, similar to the centralized approach.

30


7 Evaluation

In this chapter, we evaluate the proposed protocol with two different experiments. In the firstexperiment we evaluate the decision making part of the protocol, i.e., the response time analysisby the cluster head. In the second experiment, we evaluate the entire reconfiguration process fromsending the request and updating the system. In order to evaluate the protocol, we build a smallnetwork that includes three switches along with nine nodes, as it is shown in Figure 20. In order tomeasure the times of the response time and the reconfiguration, we implement the response timeanalysis in a computer with the following configuration. The processor is 4th Generation IntelCore i5-4210U Processor (@1.70GHz @2.40GHz 1600MHz 3MB) with 8GB RAM. The operatingsystem is Windows8.1, 64-bit.

Figure 20: The Network architecture under evaluation

7.1 Implementation of the Response Time Analysis

In the implementation of message model, we define a structure for each message in Figure 21. Eachelement in structure represents the parameter in the system model in Expression 1.

Figure 21: Message structure

In the implementation of calculating idle time, we define a function idleT imeCalc(mi, linki)that follows algorithm 2. Firstly, we initial idle time as the packet size of message mi. Then, wetraverse all other messages that have higher or equal priority than message mi and share same link

31


linki of message mi. Last, we choose the maximum packet size of those messages as the idle time.

Algorithm 2 Idle Time Calculation for mi

Initialization:1: The idle time, I = m[i].Pk;

Iteration:2: for j= 0 to N do3: if mj has higher or same priority than mi then4: for k = 0 to linkmax do5: if linklist[k] == l then6: if m[j].Pk > I then7: I = m[j].Pk8: end if9: end if

10: end for11: end if12: end for13: Return I

We define a function inflationCalc(mi, linka, linkb) to calculate inflation factor of message mi

between link la and link lb in algorithm 3. When calculating inflation factor, we take the worstcase into consideration. Therefore, we choose the minimum inflation factor between link la andlink lb.

Algorithm 3 Inflation Factor Calculation for mi

Initialization:1: The Idle time, I = 0;2: The current inflation factor, X = 03: The minimum inflation factor, prevX = LW/EC;

Iteration:4: for i= linki to linkj do5: I =IdleTimeCacl(m,i)6: X =(LW - I)/EC7: if X is less than prevX then8: prevX = X9: end if

10: end for11: Return prevX

We define a function interT imeCalc(mi, a, b) to implement the calculation of interference timein algorithm 4. First, we calculate inference time of each message that have higher priority thanmessage mi. Then, we add all the interference time together and store the value in total inferencetime TTerm.

32


Algorithm 4 Interference Calculation for mi

Initialization:1: The inflation factor, αi,a,b;2: The interference time, TTerm = 0;3: The previous response time, rt0;

Iteration:4: for l= linki to linkj do5: for j= 0 to message-number do6: if m[i].prio is higher than m[j].prio then7: for k = 0 to numlink do8: if mess[m].linklist[k] == l then

9: Term = d rt0mess[m].periode

mess[m].transαi,a,b

10: end if11: end for12: end if13: end for14: TTerm = TTerm+ Term15: end for16: Return TTerm

In our thesis, we define a function blockT imeCalc(mi, linka, linkb) to calculate the block timeof message mi in algorithm 5. First, we calculate block time for each link in the transmission pathof message mi. Then, we add all the block time together and store the value in total block timeTblock.

Algorithm 5 Block Term Calculation for mi

Initialization:1: The totally block time, Tblock = 0;

Iteration:2: for l= linki to linkj do3: Prevmax = 0;4: for j= 0 to message-number do5: if m[i].prio is higher than m[j].prio then6: for k = 0 to numlink do7: if mess[m].liklist[k] == l then8: Block = mess[m].pk/αi,a,b9: if Block > Prevmax then

10: Prevmax = Block11: end if12: end if13: end for14: end if15: end for16: Tblock = Tblock + Prevmax17: end for18: Return Tblock

We implement a function delayT imeCalc(mi, linka, linkb) to calculate the switch delay timeof message mi by following algorithm 6. Firstly, we compare switch delay time of each message inmessage set mess[] with the switch delay time of message mi. We choose the higher switch delaytime. Then, we add all those higher switch delay time together and store the summation to Tdelay.

33


Algorithm 6 Switching delay Calculation for mi

Initialization:1: The totally delay time, Tdelay = 0;

Iteration:2: for l= linki to linkj do3: Prevmax = 0;4: Swdi = (SLD +msgi.pk)/alpha;5: Prevmax = Swdi;6: for j= 0 to message-number do7: for m[j] is belong to mess[] do8: for k = 0 to numlink do9: if mess[m].liklist[k] == l then

10: Swdj = (SLD +mess[j].pk)/alpha;11: if Swdj > Swdi then12: Prevmax = Swdj13: end if14: end if15: end for16: end for17: end for18: Tdelay = Tdelay + Prevmax19: end for20: Return Tdelay

7.2 Decision Making of On-line Reconfiguration

In order to evaluate the decision making time, we generate randomly 10000 sets of messages. Theparameters of each message is selected within a given range. We set the value of message’s periodwithin [2, 22]EC, while the deadline of message is equal to its period. The priority of the mes-sages is assigned based on the Rate Monotonic algorithm, i.e., larger period has higher priority. Inour thesis, the network capacity is 100Mbps. The maximum packet size in Ethernet is 1524KB,therefore, the maximum time that use to transmit maximum packet is around 123µs. Thus, thetransmission time and packet size of each message are selected within [80, 123]µs. In addition, thehardware fabric latency is set to 5µs. We performed the experiment for two settings. In the firstsetting the EC size is set to 1ms, while in the second setting it is set to 2ms. The synchronouswindow is set to 70% of the EC, for both settings. The source and destination nodes of the messageis chosen randomly.

In our evaluation, we change the value of EC and compare the decision making time. In thefirst case, EC is set to 1ms, length of synchronous window is set to 70%EC. We generate 10000message sets which includes 10 messages, then we measure the time it takes to calculate the re-sponse time of the messages in the set. for each set. Figure 22 shows minimum, average andmaximum time that it took to compute the response time of the messages in the set, where 10,20 and 30 messages are generated in each set. As it can be seen from the figure, by increasingthe number of messages, the time of performing the response time for the messages increases. Forexample, for 10 messages in the set, the maximum time it took to calculate the response time isless than 0.5ms.

34


Figure 22: Decision making for EC=1ms LSW=70%EC

In the second case, EC is set to 2ms. We follow the same process as we did in first case tocalculate the decision making time for each message set. The result is shown in Figure 23. Similarto the previous case, the time for the response time increases by increasing the number of messagesin the set. Comparing both cases, the average time for performing response time did not changeby increasing the EC size.

Figure 23: Decision making for EC=2ms LSW=70%EC

In the third case, we fix the value of EC, then we compute decision time, when changing thesynchronous window duration LSW for a given set of messages. We assume EC = 1ms, the numberof message set is 20. Then, the size of LSW is selected 60%, 70%, 80% and 90% of the EC. Figure24 illustrates the minimum, average and maximum decision making time. As it can be seen, thetime is slightly decreasing by increasing the window size in the EC. This is due to the fact that,the number of messages that can be fit in the windows is decreasing when the size of the windowis decreasing. Thus, the response time of the messages becomes larger. For LSW = 60%EC, theaverage decision making time is 0.36 ms. While LSW= 90%EC, the average decision making timedecrease to 0.25 ms.

35


Figure 24: Decision making time for changed LSW

To sum up, the decision making time is affected by both EC and transmission window sizes.However, this experiment is done in a fixed network architecture. Checking the effect of differentarchitecture and the size of network are remained for the future work.

7.3 The Reconfiguration Process

In order to measure the reconfiguration time, we measure each step of the process and sum themup. The first step is to send a request. We assumed that the request is sent from a node in acluster that has to pass at least two switches, i.e. node D sends a request to node G, we assume thebiggest possible cluster and longest possible route for the request message. The response time ofthe request message is the time it takes to send the request. In the second step, the response timeis performed by the cluster head. This measurement is already done in the previous evaluationin Section 7.2. In the last step, the cluster head sends the update message to the other clusterheads, and the cluster heads send the update to their switches and nodes inside the cluster. Again,the time it takes for sending the update message is the worst-case response time of the message.However, there are several update messages with different routes and interference. The maximumresponse time among those update messages is the time to inform all the switches and the nodes.In this evaluation, we assume that the update message passes the longest route in the network.Moreover, in the evaluation we assume that all the requests are accepted by the cluster head, as itgenerates the update message. Otherwise, in case of the rejection, there is a short update just forthe requested node. The request time, the response time analysis time and the update time areshown by RTrequest, RTdecision, RTupdate, respectively. Thus, the whole reconfiguration processtime is calculated in Equation 9.

RTreconfiguration = RTrequest +RTupdate +RTdecision (9)

In this evaluation part, we generate randomly 10000 sets of messages that are schedulable. Thenwe generate request message and update message.The parameters of both message is selected ingiven range. We perform the evaluation for two different settings. In the first setting the reconfig-uration period is set to 50EC. This means that every 50EC there will be a request message. In thesecond setting, we increase the reconfiguration period to 100EC. The priority of messages are setbased on the Rate Monotonic algorithm. The transmission time and packet size of of each messageare set to 123µs. In addition, the hardware fabric latency is set to 5µs.

We generate 10000 schedulable sets which includes 10 messages, then we calculate reconfigura-tion time for each set. The measurement is done for the sets with 10, 20 and 30 messages in theset. Figure 25 shows the experiment when the reconfiguration period is 50EC. As it can be seen,the reconfiguration process time is increasing by increasing the number of messages in the set. In

36


average, for 30 messages in the set, it takes around 8.5 ms to completely reconfigure the system.This time is increased slightly to 8.1 ms when the number of messages is 20.

Figure 25: Reconfiguration process time, when Period= 50EC EC=1ms LSW=70%EC

In the second setting where the reconfiguration period is 100EC, the reconfiguration time isshown in Figure 26 for different number of messages in the set. As it can be seen, compared to theprevious case, shown in Figure 25, the time did not change.

Figure 26: Reconfiguration process time, when Period= 100EC EC=1ms LSW=70%EC

In addition, we also evaluate the reconfiguration process time when the transmission time ischanging for a message set. For this case, we assume that the reconfiguration period is 50EC,message set includes 20 messages and EC is equal to 1ms. We change the size of synchronouswindow to 60%, 70%, 80% and 90% of the EC. The simulation result is shown in Figure 27. As itcan be seen from the figure, the average reconfiguration time for larger LSW is less than the casewhere we set the LSW small. This means the reconfiguration takes 9 EC. When LSW is set to60%EC, the average reconfiguration time for message set is 8.35ms. While, when we set the LSWto 90%EC, the average reconfiguration time is decreased to 6.33ms. This means the reconfigurationcan be done in 7 ECs.

37


Figure 27: Reconfiguration process time for changed LSW, when Period= 100EC EC=1ms

The experiments show that the reconfiguration time is affected by the number of messages, sizeof EC and size of transmission window. The larger numbers of messages is in set, the longer timeis needed to perform reconfiguration. For a given message set, the higher size synchronous windowcan lead a less reconfiguration process time.

38


8 Related work

In this chapter, we review state of art regarding the on-line reconfiguration mechanisms. Thischapter also provides the advantages of our mechanism compared with the state of the art solutions

Marau et. al. [12] proposed a middleware, which contains QoS management and admissioncontrol, for the Flexible Time Triggered Switched Ethernet (FTT-SE) protocol, which is to performdynamic reconfiguration and adaptability of real-time communication. The FTT-SE protocol isusing master-slave technique. This paper gives a brief overview of the FTT-SE protocol, whichcontains its basic structure and application interfaces. It also identifies requirements of middlewareand proposes middlesware structure. The on-line reconfiguration and adaption in the FTT-SE pro-tocol composes four steps. Firstly, there is a negotiation from slave node to master node that slavenode requires a request change. The request change includes adding message, removing messageand changing parameters of the message. Then, Admission Control is used to handle the requestchange from slave nodes. The third step is Qos Management, which allocates resource for eachmessage stream. Last step is Mode Change, which synchronizes the change for all slave nodes. TheFTT-SE master node implements Admission Control, QoS Management and Mode Changes in theFTT-SE architecture. Through a case-study of camera surveillance system, the proposed middle-ware shows its merits in alleviating the application in slave side, verifying easier interface providedto the application and processing overall reconfiguration in bounded time. However, the proposedprotocol is worked in context of single-switch. As there are many master nodes in the multi-hopHaRTES architecture, the proposed FTT-SE protocol is not enough. In multi-hop HaRTES archi-tecture, all the master nodes should agree on the requested changes, and they should apply thenew changes at the same time to achieve the consistency. Considering the mentioned difference,we propose a new protocol for multi-hop HaRTES architecture to achieve on-line reconfigurationin this thesis.

Ashjaei et.al [20] proposed two protocols (based on centralized and on distributed) to performon-line reconfiguration for the multi-hop FTT-SE networks, and made a qualitative comparisonbetween them. The centralized approach chooses one root master node to implement AdmissionControl and QoS Management. All slave nodes send their request change to the root node. Theroot node verifies all the request change and informs its decision to other master nodes and slavenodes. Therefore, the root master node requires higher processing power than other master nodes.In the distributed approach, all master nodes can be acted the role as root master node in central-ized approach. Each master node is capable to verify feasibility of request change and computethe allocated resource in parallel. Thus, master node in the distributed approach require higherprocessor power. Ashjaei et.al [21] used the computational time and reconfiguration signal timeto evaluate the reconfiguration time of two protocols. Computational time is the time that usedto calculate response time of a set messages. The reconfiguration time is the time that used tonegotiate and update in reconfiguration process. The centralized approach, which is easy to beimplemented, is more efficient for large scale networks, while the distributed approach has advan-tages in terms of bandwidth and fault tolerance. In our thesis, we proposed a hybrid method touse the advantages of both centralized and distributed approach.

Garner et.al [16] described Stream Reservation Protocol(SRP) of IEEE 802.1 AVB in detailsand case study of its application in Home networks. SRP is conducted into two parts, registrationand reservation. In the stream reservation service, the provider of stream is defined as Talker,the recipient of the stream is defined as Listener. Talker reserves bandwidth resource that audioand video streams require, Listener is registered and receiving audio and video streams from theTalker. Talker provided initially broadcast a offering declarations, which announces streams thatcould be transmitted and depicts their features, so that the listeners could notice the existenceof talker and offer steam to talker. During the transmission of offering declaration, it will collectquality of service information along the channel, and the collected information is classified intotwo types, positive and negative offering declarations. When the channel is ready, the feedbackprovided a positive offering declaration that indicates the communication path is ready and thestream can be sent. While the bandwidth of along path is lacked, a negative offering declaration

39


is provided. It represents applicant port cannot send the stream. Listeners broadcasts an askingdeclarations to enquire the type of streams that they need to receive. The asking declaration istransmitted to upstream toward talker. Moreover, it is responsible to deliver allocation result ofbandwidth resource along its path. The asking declarations is divided into two types, positiveasking declarations, which represents listener can receive stream, and negative asking declarationswhich represents transmission path is not found. Talker and Listener utilize MRP signaling mech-anism, in accordance with their own circumstances. The state machine in the SRP, maintainsregistration information of Talker and Listener. It is possible to dynamically monitor the statusof network nodes and updates its internal database registration information. In our thesis, wetake advantage of the idea of SRP protocol, and design dynamic reconfiguration in context of themulti-hop HaRTES architecture.

Klobedanz et.al [22] proposed a reconfiguration method to improve fault tolerance of FlexRayNetwork and evaluated valid reconfiguration of the method. Because of safety and redundancychannel communication, FlexRay Network is used widely in safety critical automotive field. FlexRayNetwork consists of numbers of Electronic Control Units (ECUs). If one ECU fails, the whole sys-tem is malfunction. In this paper, authors classified the ECUs into two types: Nodes that is toconnect sensors with actuators and read/write data with bus, dedicated nodes which is responsibleto handle and distribute data. To avoid the malfunction of system that evoked by a failure nodeand guarantee reliable and correct communication, authors considered reconfiguration and redun-dancy for dedicated nodes. As FlexRay cannot support to change schedule at its running time,the author adopt redundancy slots or integrate messages in idle slots of existing frames to performreconfiguration. First, authors calculate the initial configuration according to a genetic algorithms(GA) [23]. Then, a valid reconfiguration is calculated based on the result of initial reconfiguration.The valid reconfiguration is for the nodes in FlexRay Network when one node is failed to work.The evaluation of the reconfiguration approach illustrates that it is valid for most individual nodefailure and can reduce its overhead.

Jahnich et.al [24] proposed a middleware that supports self-reconfiguration for InfotainmentNetwork in automotive system . The Infotainment Network includes media-based tasks i.e. navi-gation system and entertainment system in vehicles. Self-reconfiguration supports fault-tolerancesuch that it makes automotive system more stable. In Infotainment Network, if there is a ECUthat fails to work, it causes an error. Then the load balancing of tasks is executed. It migrates alltasks in the failure ECU to other ECUs in the system, which ensures the reliability of system. Themiddleware could execute error detection and load balancing in parallel. Authors also proposed acost-based load balancing strategy to migrate tasks from ECU to another ECU. Load balancer inmiddleware computes the cost of migrated tasks in their original ECU, then, it assesses the cost ofother ECUs that can accept the migrated tasks. If there exists one ECU that has lower cost thanoriginal cost , and the migrated tasks are schedulable in that ECU, then, the tasks in original ECUcan be migrated to that ECU. Therefore, the middleware can decrease the compute time of tasksand improve the resource utilization. However, the cost-based load balacing stategy of proposedmiddleware did not get the optimal performance of Infotainment Network.

Lepuschitz et.al [25] focused on the on-line reconfiguration for Low Level Control in automationagent . In this paper, an automation agent is consist of physical component and software compo-nent. The physical component is physical hardware, while software component is responsible tocontrol the physical component to meet external requirements. The software component is dividedinto two parts, High Level Control (HLC) and Low Level Control (LLC). The function of HLC isto coordinate communication with other automation agents and control current automation agent.The LLC is to control physical component in automation agent. Authors describe an infrastruc-ture of LLC that can perform on-line reconfiguration. However, due to the reconfiguration of LLCapplication cannot disturb the control process in agent, therefore, reconfiguration is time con-straint. Besides, the authors proposed a new programmable reconfiguration management, whichis responsible to generate dedicated reconfiguration application (RCA) by HLC. In the processof reconfiguration, RCA is used to collect the status of LLC, perform mode change and activateevents. A Number of reconfiguration services i.e. execution control services, structure services .etc

40


are employed to perform reconfiguration.

Kooti et.al [26] presented a novel on-line reconfiguration-aware real-time scheduler under QoSconstraints . QoS constraints, which is caused by reconfiguration overhead, means that a givenrate of deadline missing in real-time system is acceptable. Therefore, tasks in real-time system canbe separated into two types, critical tasks and non-critical tasks. Critical tasks are the task thatcannot miss its deadline. If the critical task misses the deadline, it can cause QoS violation. Non-critical tasks are the tasks which can be dropout without affecting QoS violation. Authors proposeda real-time scheduler, based on weak-hard real time system that tolerates the deadline missing.The real-time scheduler is composed of QoS Model, Criticality Function and Reconfiguration-awareOnline Scheduler. Qos Model is responsible for gather the QoS of task, while Criticality Functionis use to verify whether the task is critical or not. Reconfiguration-aware Online Scheduler is thecore of real-time scheduler, it is used to schedule tasks according to their task types and theirreconfiguration overheads. The critical tasks are scheduled first, if there are enough idle time, thennon-critical tasks are scheduled. The change of task ordering affects the reconfiguration overhead.Then, authors model a task ordering to get a proper reconfiguration overhead.

41


9 Conclusion

9.1 Summary

In this thesis, We focus on the on-line reconfiguration for the multi-hop HaRETS networks. In or-der to guarantee on-line reconfiguration for real-time network, four steps are required, negotiationbetween slave node and master node, admission control carried out in cluster head, QoS manage-ment by cluster head and mode changes for all nodes. We proposed a protocol to synchronizethose steps that is aimed to guarantee the real-time behavior. Moreover, we evaluate the protocolin terms of reconfiguration time and decision making time. According to result of evaluation, thereconfiguration time increases slightly by increasing the number of messages.

In Chapter 4, four research questions were defined to address reconfiguration problems. Theanswers of each question has been formulated in previous chapters. Here, we summarize the an-swers.

What are the steps towards achieving the on-line reconfiguration in multi-hopHaRTES architecture?In our thesis, we organize the multi-hop HaRTES architecture into several clusters. The parentswitch in each cluster is selected as cluster head, which is responsible for performing the AdmissionControl and QoS Management. The cluster head receives the request change from one of slavenodes inside the cluster. After verifying feasibility of request change, if the request is rejected,then cluster just notify its slave node. Otherwise, the cluster header not only must inform thenodes inside its cluster about the change, but also notify other nodes in the other clusters. Tosynchronize the mode-change for all nodes and switch at the same time and keep the consistencyof the system, the information about the time that the system must do the mode-change shouldbe sent to other nodes as well. In order to do that, the cluster head, computes the time whichtakes for the update message to reach to all nodes in the architecture, and sets that time for themode-change. This time is encoded in the update message. Then, the dynamic reconfiguration ofmulti-hop HaRTES architecture is done.

How many admission controls are required in the network to perform the recon-figuration?Admission control unit is used to check the feasibility of request change. In the hybrid HaRTESarchitecture, only cluster head carries out admission control. Therefore, the amount of admissionunits depends on the number of cluster head in the HaRTES network.

Where the admission control units should be located in the architecture to achievea fast and efficient request and update handling?The admission control units should be located in the cluster head switch where it could achieve afast and efficient request and update handling. In this thesis, we define a cluster-tree topology forhybrid HaRTES architecture to take advantage of its scalability and efficient communication.

What are the criteria to measure the performance of the proposed on-line recon-figuration method?To measure the performance of the proposed protocol, we evaluate it in terms of decision makingtime by the cluster head and reconfiguration time. The decision making time is the time that usedto calculate response time of a set messages. The reconfiguration time is the time for the wholereconfiguration process, including the request time, response time calculation and update time.

42


9.2 Future Work

In this thesis, the future works can be done as below.

• We proposed a reconfiguration protocol, and we evaluated that. However, the remaining partis to compare experimentally with other reconfiguration methods in the literature, includingthe centralized and distributed approaches.

• Implement the proposed reconfiguration method on the multi-hop HaRTES architecture isremained as a future work. Moreover, another part is to perform some case studies on thehardware.

• In this thesis, we used a fixed network architecture for the experiments. Therefore, the effectof different network size on the reconfiguration time is not studied. Investigating this effectis another part of the future work.

• A middleware is proposed to meet adaptability and flexible reconfiguration for a single switchin the FTT-SE [12]. Thus, some work can be done to design or extend the middleware forthe multi-hop HaRTES architecture.

• Comparing performance of the multi-hop HaRTES architecture with other multi-hop Eth-ernet Switches Network, i.e. Ethernet AVB networks, TTEthernet Networks. could be onedirection of the future work.

• Another thing that needs to be done, is to develop a simulation tool that can evaluatedifferent architectures. Therefore, we can evaluate using the simulation for different networkarchitectures.

43


References

[1] Pedreiras Paulo and Almeida Luis. Approaches to enforce real-time behavior in Ethernet. TheIndustrial Communication Systems Handbook, 36, 2005.

[2] PROFINET. Holistic thinking now defines industrial automation. http://www.iebmedia.com/Accessed: 2015-03-02.

[3] Hermann Kopetz, Astrit Ademaj, Petr Grillinger, and Klaus Steinhammer. The time-triggeredethernet (TTE) design. In 8th International Symposium on Object-Oriented Real-Time Dis-tributed Computing, pages 22–33. IEEE, 2005.

[4] Jahanzaib Imtiaz, Jurgen Jasperneite, and Lixue Han. A performance study of Ethernet AudioVideo Bridging (AVB) for Industrial real-time communication, 2009.

[5] L. Almeida, P. Pedreiras, J. Ferreira, J. Calha, J. A. Fonseca, R. Marau, R. Silva, and E. Mar-tins. Enhancing real-time communication over COTS Ethernet switches. 2006.

[6] Rui Santos, Moris Behnam, Thomas Nolte, Paulo Pedreiras, and Luıs Almeida. Multi-levelhierarchical scheduling in Ethernet switches. 2011.

[7] Philip Axer, Daniel Thiele, Rolf Ernst, Jonas Diemer, Simon Schliecker, and Kai R Richter.Requirements on real-time-capable automotive ethernet architectures. Technical report, SAETechnical Paper, 2014.

[8] Mohammad Ashjaei, Moris Behnam, Paulo Pedreiras, Reinder J Bril, Luis Almeida, andThomas Nolte. Reduced buffering solution for multi-hop HaRTES switched Ethernet networks.In 20th of the International Conference on Embedded and Real-Time Computing Systems andApplications, pages 1–10. IEEE, 2014.

[9] Wilfried Steiner, Gunther Bauer, Brendan Hall, Michael Paulitsch, and Srivatsan Varadarajan.TTEthernet dataflow concept. In IEEE International Symposium on Network Computing andApplications, pages 319–322. IEEE, 2009.

[10] Zdenek Hanzalek, Pavel Burget, and Premysl Sucha. Profinet IO IRT message scheduling. In21st Euromicro Conference on Real-Time Systems, pages 57–65. IEEE, 2009.

[11] Mohammad Ashjaei, Paulo Pedreiras, Moris Behnam, Reinder J Bril, Luis Almeida, andThomas Nolte. Response time analysis of multi-hop HaRTES Ethernet switch networks. In10th IEEE Workshop on Factory Communication Systems, pages 1–10. IEEE, 2014.

[12] Ricardo Marau, Luis Almeida, Mario Sousa, and Paulo Pedreiras. A middleware to supportdynamic reconfiguration of real-time networks. In IEEE Conference on Emerging Technologiesand Factory Automation, pages 1–10. IEEE, 2010.

[13] Ethernet Powerlink Protocol. http://www.ethernet-powerlink.org/ Accessed: 2015-03-02.

[14] PROFINET IRT. Real-time PROFINET IRT. http://www.profibus.com/pn Accessed: 2015-03-02.

[15] Hyung-Taek Lim, Daniel Herrscher, L Volker, and Martin Johannes Waltl. IEEE 802.1 AStime synchronization in a switched Ethernet based in-car network. In Vehicular NetworkingConference, pages 147–154. IEEE, 2011.

[16] Geoffrey M Garner, Feifei Feng, Kees den Hollander, Hongkyu Jeong, Byungsuk Kim, B-JBLee, Tae-Chul Jung, and Jinoo Joung. IEEE 802.1 AVB and its application in carrier-gradeEthernet. Communications Magazine, pages 126–134, 2007.

[17] R Marau, P Pedreiras, and Luis Almeida. Asynchronous traffic signaling over master-slaveswitched Ethernet protocols. In 6th International Workshop on Real Time Networks (RTN07),2007.

44


[18] R. Santos, R. Marau, A. Vieira, P. Pedreiras, A. Oliveira, and L. Almeida. A synthesiz-able Ethernet switch with enhanced real-time features. In 35th Annual Conference of IEEEIndustrial Electronics Proceedings, pages 2817–2824. IEEE, 2009.

[19] Aboobeker Sidhik Koyamparambil Mammu, Ashwani Sharma, Unai Hernandez-Jayo, andNekane Sainz. A novel cluster-based energy efficient routing in wireless sensor networks. In27th International Conference on Advanced Information Networking and Applications, pages41–47. IEEE, 2013.

[20] Mohammad Ashjaei, Paulo Pedreiras, Moris Behnam, Luis Almeida, and Thomas Nolte. Dy-namic reconfiguration in multi-hop switched Ethernet networks. ACM SIGBED Review, pages62–65, 2014.

[21] Mohammad Ashjaei, Paulo Pedreiras, Moris Behnam, Luis Almeida, and Thomas Nolte. Eval-uation of dynamic reconfiguration architecture in multi-hop switched Ethernet networks. InIEEE Conference on Emerging Technology and Factory Automation, pages 1–4. IEEE, 2014.

[22] Kay Klobedanz, Andreas Koenig, and Wolfgang Mueller. A reconfiguration approach for fault-tolerant FlexRay networks. In Design, Automation & Test in Europe Conference & Exhibition,pages 1–6. IEEE, 2011.

[23] DING Shan, Hiroyuki Tomiyama, and Hiroaki Takada. An effective GA-based schedulingalgorithm for FlexRay systems. IEICE transactions on information and systems, 91(8):2115–2123, 2008.

[24] Isabell Jahnich, Ina Podolski, and Achim Rettberg. Towards a middleware approach for aself-configurable automotive embedded system. In Software Technologies for Embedded andUbiquitous Systems, pages 55–65. Springer, 2008.

[25] Wilfried Lepuschitz, Mathieu Vallee, Alois Zoitl, and Munir Merdan. Online reconfigurationof the low level control for automation agents. In 36th Annual Conference on IEEE IndustrialElectronics Society, pages 1365–1370. IEEE, 2010.

[26] Hessam Kooti, Deepak Mishra, and Eli Bozorgzadeh. Reconfiguration-aware real-time schedul-ing under qos constraint. In Proceedings of the 16th Asia and South Pacific Design AutomationConference, pages 141–146. IEEE Press, 2011.

45


A Appendix A - Time Plan

Figure 28 presents the time plan for the thesis work. The whole thesis has been done within 20weeks. In the first four weeks, We focused on studying background and state of art related thethesis. The design and evaluation are the main parts in this thesis. Therefore, we spent 12 weekson that. Meanwhile, we started to write the thesis in parallel along with the following activitiesstarting with background till the final presentation.

Figure 28: Time Plan of thesis

46


B Appendix B - Response Time Functions

B.1 Idle Time Calculation Function

f l o a t idleTimeCalc (msg msgi , i n t l i n k i , msg mess [ ] , i n t index ){

f l o a t I = 0 ;f o r ( i n t j = 0 ; j < MSG num; j++){

f l o a t Imax = msgi . pk ;f l o a t I = msgi . pk ;i f ( j == index ){

j++;i f ( j >= MSG num)

break ;}msg m=mess [ j ] ;i f (m. p r i o < msgi . p r i o ){

f o r ( i n t k = 0 ; k < m. numlink ; k++){

i f (m. l i n k l i s t [ k ] == l i n k i ){

i f (m. pk>I&&m. pk>Imax ){

I = m. pk ;Imax = I ;

}}

}}

Imax = msgi . pk ;

r e turn Imax ;}

}

B.2 Inflation Time Calculation Function

f l o a t i n f l a t i o nCa l c (msg msgi , i n t l i n k i , i n t l i n k j , msg mess [ ] , i n t index ){

f l o a t prevX = ( f l o a t )maxalp ;f l o a t I = 0 ;f l o a t X = 0 ;f o r ( i n t i = 0 ; i < msgi . numlink ; i++){

i f ( msgi . l i n k l i s t [ i ] != l i n k i ){

i++;break ;

}I = idleTimeCalc (msgi , msgi . l i n k l i s t [ i ] , mess , index ) ;X = (LW − I ) / EC;i f (X < prevX )

prevX = X;i f ( msgi . l i n k l i s t [ i ] == l i n k j ){

break ;}

}r e turn prevX ;

}

47


B.3 Blocking Time Calculation Function

f l o a t blockTimeCalc (msg msgi , i n t l i n k i , i n t l i n k j , f l o a t alpha ,msg mess [ ] , i n t index ){

f l o a t Tblock=0;f o r ( i n t l = 0 ; l < msgi . numlink ; l++){

i f ( msgi . l i n k l i s t [ l ] != l i n k i ){

l++;break ;

}

f l o a t Prevmax=0;i f ( msgi . numlink >=2){

// f o r ( i n t j = 0 ; j < MSG num; j++)f o r ( i n t j = 0 ; j < MSG num; j++){

i f ( j == index ){


break ;}

msg temp = mess [ j ] ;i f ( msgi . pr io<temp . p r i o )// f i nd the lower p r i o r i t y messages{

f o r ( i n t i = 0 ; i < temp . numlink ; i++){

i f ( temp . l i n k l i s t [ i ] == msgi . l i n k l i s t [ l ] ){f l o a t Block = temp . pk / alpha ;i f ( Block > Prevmax ){Prevmax= Block ;}}

}}

}}e l s e{ r e turn 0 ;}Tblock+=Prevmax ;i f ( msgi . l i n k l i s t [ l ] == l i n k j ){

break ;}

}r e turn Tblock ;

}

B.4 Interference Time Calculation Function

48


f l o a t interTimeCalc (msg msgi , i n t l i n k i , i n t l i n k j , f l o a t alpha , msg mess [ ] , i n t index , f l o a t prevRT){

f l o a t TTterm=0;f l o a t Term = 0 ;f l o a t prevr t=prevRT ;f o r ( i n t l = 0 ; l < msgi . numlink ; l++)

{i f ( msgi . l i n k l i s t [ l ] != l i n k i ){

l++;break ;

}f l o a t Prevmax=0;


i f ( j == index ){


break ;}msg temp = mess [ j ] ;i f ( msgi . p r i o > temp . p r i o ) // f i nd the h igher p r i o r i t y{


i f ( temp . l i n k l i s t [ i ] == msgi . l i n k l i s t [ l ] ){

f l o a t Term = c e i l ( p revr t / temp . per iod )∗ ( temp . t ranst ime / alpha ) ;TTterm += Term ;

}}

}}i f ( msgi . l i n k l i s t [ l ] == l i n k j ){

break ;}

}r e turn TTterm ;

}

49


B.5 Switch Delay Calculation Function

f l o a t delayTimeCalc (msg msgi , i n t l i n k i , i n t l i n k j , f l o a t alpha ,msg mess [ ] , i n t index ){

f l o a t Tdelay = 0 ;f o r ( i n t l = 1 ; l < msgi . numlink ; l++){

f l o a t SWDi = (SLD + msgi . pk )/ alpha ;f l o a t Prevmax = 0 ;i f ( msgi . numlink >= 2){


i f ( j == index ){


break ;}msg temp = mess [ j ] ;i f ( msgi . pr io<temp . p r i o | | msgi . pr io>=temp . p r i o ){


i f ( temp . l i n k l i s t [ i ] == msgi . l i n k l i s t [ l ] ){

// f l o a t Block = temp . pk / alpha ;f l o a t SWDq = (SLD + temp . pk ) / alpha ;i f (SWDq > Prevmax ){

Prevmax = SWDq;}

}}

}}

}e l s e{

r e turn 0 ;}

Tdelay += Prevmax ;i f ( msgi . l i n k l i s t [ l ] == l i n k j ){

break ;}

}r e turn Tdelay ;

}

50


B.6 Response Time Calculation Function

f l o a t responseTimeCalc (msg msgi , i n t l i n k i , i n t l i n k j , msg mess [ ] , i n t index ){

f l o a t prevr t = 0 ;

f l o a t a lp = i n f l a t i o nCa l c (msgi , l i n k i , l i n k j , mess , index ) ;f l o a t term = msgi . t ranst ime / alp ;f l o a t r t = term ;

f l o a t Blocking = blockTineCalc (msgi , l i n k i , l i n k j , alp , mess , index ) ;f l o a t Switching = delayTimeCalc (msgi , l i n k i , l i n k j , alp , mess , index ) ;whi l e ( r t != prevr t ){

prevr t = r t ;f l o a t Highinte = interTimeCalc (msgi , l i n k i , l i n k j , alp , mess , index , prevr t ) ;r t = term + Blocking + Highinte + Switching ;

}

r e turn r t ;

}

51


B.7 Total Response Time Calculation Function

f l o a t responseTimeAnalys i s (msg msgi , i n t l i n k i , i n t l i n k j , msg mess [ ] , i n t index ){

f l o a t RTA = 0 ;i n t l i nk index = 1 ;i n t l i n k s t a r t = msgi . l i n k l i s t [ 0 ] ;whi l e ( l i nk i ndex < msgi . numlink ){

i n t l i nknex t = msgi . l i n k l i s t [ l i nk index ] ;i n t l i nkp r ev = msgi . l i n k l i s t [ l i nk index − 1 ] ;f l o a t r t i = responseTimeCalc (msgi , l i n k s t a r t , l inknext , mess , index ) ;f l o a t r t p r e = responseTimeCalc (msgi , l i n k s t a r t , l inkprev , mess , index ) ;f l o a t RT i = c e i l ( r t i /EC) ;f l o a t RT pre = c e i l ( r t p r e / EC) ;i f ( l i n k s t a r t != l i nknex t && r t i != r t p r e ){

RTA += RT pre ;l i n k s t a r t = l i nknex t ;

}e l s e{

l i nk i ndex++;l i nknex t = msgi . l i n k l i s t [ l i nk index ] ;

}

}

msgi . r t = RTA∗EC;mess [ index ] . r t = RTA∗EC;i n t dead = ( i n t )msgi . dead l ine ;i n t l a s t = ( i n t )msgi . r t ;i n t f l a g = dead−l a s t ;

i f ( f l a g <0){

r e turn FALSE;}i f ( f l a g >=0){

r e turn TRUE;}

}

52


C Appendix C - Experimental Data

C.1 The raw data for decision making time, EC=1ms LSW=70%EC

Message set Min(ms) Mean(ms) Max(ms)10 mess 0.0612 0.0984 0.480320 mess 0.2108 0.3456 1.121730 mess 0.4927 0.6445 1.2278

Table 1: EC=1ms LSW=70%EC

C.2 The raw data for decision making time, EC=2ms LSW=70%EC


Table 2: EC=2ms LSW=70%EC

C.3 The raw data for decision making time, EC=1ms Message Num-ber=20

Size of LSW Min(ms) Mean(ms) Max(ms)60%EC 0.2703 0.3579 1.213570%EC 0.2023 0.3301 1.121480%EC 0.1501 0.2873 1.083690%EC 0.1001 0.2519 1.0584

Table 3: EC=1ms Message Number=20

C.4 The raw data for reconfiguration process time, Period=50EC, EC=1ms,LSW=70%EC


Table 4: Period= 50EC EC=1ms LSW=70%EC

53


C.5 The raw data for reconfiguration process time, Period=100EC, EC=1ms,LSW=70%EC


Table 5: Period= 100EC EC=1ms LSW=70%EC

C.6 The raw data for reconfiguration process time, Period=50EC, EC=1ms,Message Number=20

Size of LSW Min(ms) Mean(ms) Max(ms)60%EC 8.2579 8.3482 9.111970%EC 8.2237 8.3241 8.678180%EC 6.2733 6.3615 6.947790%EC 6.2669 6.3308 6.6038

Table 6: Period=50EC, EC=1ms, Message Number=20

54

online admission control for multi-switch … · systems, the messages in the network may need to...

Documents