m. tech. project thesis on anytime multi-objective

M. Tech. Project Thesis

on

Anytime Multi-Objective Optimization and

Co-design of Controller and Scheduler for

Optimal Control Performance

by

Sunandita Patra

09CS3037

5th year Dual Degree

COMPUTER SCIENCE AND ENGINEERING

IIT KHARAGPUR

April 2014

Certificate

This is to certify that the M. Tech project entitled, Anytime Multi-Objective Optimization and Co-design of Controllers and Scheduler for Op-timal Control Performance, submitted by Ms. Sunandita Patra to IndianInstitute of Technology, Kharagpur, India, is a record of bona-fide projectwork carried out by her under my supervision and guidance and is worthyof consideration for the award of the degree of Master of Technology in theDepartment of Computer Science and Engineering of the Institute.

—————————————(Prof. P. P. Chakrabarti)

Declaration

I certify that

the work contained in this report is original and has been done by meunder the guidance of my supervisor.

the work has not been submitted to any other Institute for any degreeor diploma.

I have followed the guidelines provided by the Institute in preparingthe report.

I have conformed to the norms and guidelines given in the Ethical Codeof Conduct of the Institute.

whenever I have used materials (data, theoretical analysis, figures, andtext) from other sources, I have given due credit to them by citing themin the text of the report and giving their details in the references. Fur-ther, I have taken permission from the copyright owners of the sources,whenever necessary.

———————————Signature of the Student

Acknowledgements

I would like to take this opportunity to thank my M. Tech project super-visor, Prof. P. P. Chakrabarti, who has invested his full effort in guiding metowards the goal. I would also like to thank, Prof. Samarjit Chakraborty,TU Munich, under whose guidance I did a summer internship at TU Munichin May-July 2013. A special gratitude, I give to my mentors, Mr. AritraHazra, Mr. Priyankar Ghosh, Mr. Satya Gautam Vadlamudi and Mr. DipGoswami, whose constant help, support, stimulating suggestions and encour-agement helped me throughout the project. I would also like to express mydeepest appreciation to all those who provided me the possibility to completethe project.

Abstract

We address the problem of developing anytime heuristic searchalgorithms where intermediate results are sought at intervals oftime which may be known apriori. We propose efficient any-time algorithms for multi-objective optimization problems calledMulti-Objective Anytime Contract Search (based on the AnytimeContract Search for single objective optimization) which incre-mentally explores the state-space with the given contracts (inter-vals of reporting). The algorithm works without restarting anddynamically adapts for the next iteration based on the currentcontract and the currently explored state-space. Experimentalresults on multi-dimensional grid show that Anytime ContractSearch for multi-objective optimization outperforms depth firstbranch and bound and beam stack. We also address the problemof co-design of controllers and schedulers parameters for embed-ded systems with multiple control loops and a hierarchical sched-uler. We propose an efficient method to calculate the optimaldelays in each control application which gives the user the desiredperformance and thus, develop a set of feasible configurations forthe system. Experiments on embedded systems with three con-trol loops show that our mechanism performs better compared tothe standard approach for co-design. The proposed methods arecomplete.

Contents

1 Introduction 11.1 Anytime Multi-Objective Optimization . . . . . . . . . . . . . 11.2 Co-Design of Controllers and Schedulers . . . . . . . . . . . . 3

2 Literature Survey 62.1 Anytime Multi-Objective Optimization . . . . . . . . . . . . . 62.2 Co-Design of Controllers of Schedulers . . . . . . . . . . . . . 8

3 Anytime Multi-Objective Search 103.1 Anytime Multi-Objective Contract Search (MOACTR) . . . . 10

3.1.1 Two Level distribution . . . . . . . . . . . . . . . . . . 113.1.2 N Level distribution . . . . . . . . . . . . . . . . . . . 14

3.2 Experimental Results . . . . . . . . . . . . . . . . . . . . . . . 173.2.1 Multi-Objective Grid . . . . . . . . . . . . . . . . . . . 17

3.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Co-design of Controllers and Scheduler for Optimal ControlPerformance with Hierarchical Schedules 294.1 System description . . . . . . . . . . . . . . . . . . . . . . . . 294.2 Formulation as an Optimization Problem . . . . . . . . . . . . 314.3 Approach for Optimal Co-design . . . . . . . . . . . . . . . . . 334.4 Algorithm for Optimal Co-design . . . . . . . . . . . . . . . . 34

4.4.1 Illustration with an example . . . . . . . . . . . . . . . 374.5 Experimental Results . . . . . . . . . . . . . . . . . . . . . . . 39

4.5.1 3 Control Loops with Hierarchical Scheduling . . . . . 394.5.2 Improvement in efficiency . . . . . . . . . . . . . . . . 44

4.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5 Conclusion 46

1

A Anytime Multi-Objective Search (AMOS) Results 51A.1 Multi-Objective Anytime Contract Search:

2 - level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51A.2 Multi-Objective Anytime Contract Search:



6 - level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A.5 Depth First Branch and Bound . . . . . . . . . . . . . . . . . 68A.6 Beam Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

B Performance and Scheduler Slot feasibility 80

Chapter 1

Introduction

1.1 Anytime Multi-Objective Optimization

In today’s world, there are a lot of optimization problems where we needto optimize multiple conflicting objectives by reaching a suitable trade-off.Multi-objective optimization problems involves more than one objective func-tion to be optimized simultaneously. One such application is product andprocess design. In order to make a good design, we need to look at multi-ple objectives like cost, profit, product quality, process safety, efficiency andmany more. Typically, while optimizing these objective functions, we willobserve that improving one objective leads to compromise in the quality ofothers.

For example, while designing the paper mill of paper industry, the aimis to decrease the amount of capital invested and increase the paper qualitysimultaneously. If the design of a paper mill is defined by the size of storagevolumes and paper quality is measured by quality metrics, then the problemof optimal design of a paper mill can include objectives such as minimizingexpected variation of the quality metrics from their nominal values, mini-mizing expected time of breaks and minimizing investment cost of storagevolumes. Applications of multi-objective optimization can be found in fi-nance for portfolio management where objectives are to minimize risks andmaximize returns[1], in economics for maximizing the amount of consump-tion of different goods[2] and also in co-design of controllers and schedulersas discussed in section 1.2.

We are trying to find anytime algorithms for multi-objective optimizationproblems. The objective of anytime search algorithms is to produce a solutionquickly and improve upon it as time passes. It gives us the ability to makeresults of better quality in return for turn-around time. They give us a

1

flexibility in time and resources and are useful because algorithms in artificialintelligence like, A*, MOA* and NAMOA* can take a long time to execute.The approach to develop anytime algorithms can be broadly categorized intotwo categories: namely interruptible algorithms and contract algorithms.The interruptible algorithms try to start by producing some solution andimprove it with time and get closer to the optimal solution. The contractalgorithms, on the other hand, know their limit (contract) apriori and thustry to optimize its steps so that it gives the best solution possible given thecontract.

Several anytime schemes are available in the domain of single-objectiveoptimization. In the domain of multi-objective optimization, methods havebeen developed for finding near optimal solution which gives a non-dominatingsolution set, but they are not anytime in nature. Ghosh et al.[3] gives usa search framework for anytime bi-objective optimization. We extend thisframework for the multi-objective domain. We develop an anytime algorithmfor multi-objective optimization (MOACTR) following the footsteps of Any-time Contract Search[4]. We approach the problem by distributing the con-tract in multiple stages depending on the number of objectives present. Thefirst stage involves assigning contracts to different ranges made by dividingon the basis one objective, in the second stage, the contract of each rangeis distributed among different sub-ranges depending on the second objectiveand so on. The number of ranges in each stage is a tunable parameter of thealgorithm.

The stages of the development of the search framework is shown in Fig-ure 1.1. The key contributions of this work are as follows:

• An efficient algorithm called Anytime Multi-Objective Contract Search(MOACTR) to solve this problem for multi-objective optimization(N ≥2 objectives) with anytime results.

• The 2-level search framework distributes the nodes into two hierarchicallevels depending on the values of first two objectives. All the nodes withObjective(1) ∈ Range(i) and Objective(2) ∈ Range(j) go to δ(i, j),where δ(i, j) is the data-structure containing the nodes in an array oflists.

• The N -level search framework distributes the nodes into N hierarchicallevels depending on the values of each of theN objectives. All the nodeswith Objective(1) ∈ Range(i1) and Objective(2) ∈ Range(i2), ...,Objective(N) ∈ Range(iN ) go to δ(i1, i2, ..., iN), where δ(i1, i2, ..., iN)is the data-structure containing the nodes in an array of lists.

2

Figure 1.1: Development stages of MOACTR

• Experimental results for multi-objective optimization on multi-dimensionalgrid comparing the proposed method with depth first branch and boundand beam stack for anytime multi-objective framework shows that themulti-objective anytime contract search gradually improves and out-performs the other algorithms with increasing grid dimensions

1.2 Co-Design of Controllers and Schedulers

Embedded systems are made up of several control loops. A feedback controlloop is demonstrated in Figure 1.2. In order to fully develop an embed-ded system, one must decide the parameters of the controllers in the controlloops and also how they are implemented on a hardware architecture as awhole. In the first stage, the control engineers analyze and simulate the con-trollers based on well-defined semantics of the plant and the controller beingdesigned. They decide the controller parameters which gives the best per-formance. Once a design is complete, that is, it has been analyzed and sim-ulated by the control engineer, the embedded systems engineer implementsthe different control blocks on a suitable hardware architecture/platform.

This platform consists of multiple processing units. These units need tocommunicate with each other via a shared communication bus. The buswill need some scheduling policy to determine the order of messages to betransmitted as the execution of one control application requires transmissionof multiple messages and there are multiple control applications runningsimultaneously. This will give rise to delays in the control loops. Thus,the assumptions with which the control engineer has done his design, like

3

Figure 1.2: Schematic Feedback Control System with delay(Voit et al.)

periodicity, zero delay/jitter are no longer valid once the design has beenimplemented.

With increase in the complexity of embedded systems, the semantic gapbetween the designing of the system and its implementation increases becausethey are done independent of each other. Thus, the performance of thesystem is affected. This is the motivation to build a framework where thedependencies are explored and made use of to give better performance.

The performance of the system can be measured by observing the per-formance of all the control applications individually, which in turn can mea-sured using multiple performance metrics. Now, these metrics need not showsimilar behaviour. One system configuration which increases the value of aparticular metric may reduce the value of another. Further, the increase inperformance metrics of control application may negatively affect the perfor-mance of other control applications. Thus, we can observe that identifyingthe optimal design is a non-trivial problem.

We are trying to solve this problem by considering a system of n con-trol loops and a communication bus with a TDMA(Time Division MultipleAccess)/FP(Fixed Priority) hierarchical scheduling policy.

Our approach to solve the co-design problem is illustrated in Figure 1.3and summarized as follows:

• An efficient methodology for finding the delay basis exploiting themonotonicity of performance with delay. This step uses the VC al-gorithm which minimizes the number of queries to the simulator.

• Delay basis is the maximal set of delays {δ = (δ1, δ2, ..., δn)}, such thatthere does not exist delay δ′, δ′ > δ and Performance(δ′) <= P ref .We note that lower value indicates better performance for our choiceof performance metrics.

• A query to the simulator is required to find the performance of a partic-

4

ular delay by exploring the search space of controller parameters. Thisis an expensive step and so we want to limit the number of queries asmuch as possible.

• After the maximal set of delays has been calculated, the scheduler slotspace is explored to find the set of feasible slot sizes which producesdelay δ, such that ∃δ′ : {δ′ ∈ DelayBasis and δ ≤ δ′}

Experiments are done with embedded control system consisting of threecontrol loops and desired performance P ≤ P ref .

Figure 1.3: Steps in solving the co-design problem

5

Chapter 2

Literature Survey

2.1 Anytime Multi-Objective Optimization

A* [5] is the central algorithm in heuristic search around which most otherstate-of-the-art methods are developed. Owing to the large amount of timerequired by A* algorithm to produce a solution (which is guaranteed to beoptimal) in case of complex problems, several themes are pursued that canreport solutions (possibly sub-optimal) quickly.

Most prominent amongst them is the class of anytime search algorithms [6].Several methods are proposed in the literature to address this class of prob-lems. As discussed in Chapter 1, anytime algorithms can be broadly cate-gorized into two parts, interruptible and contract. Most interruptible any-time heuristic algorithms can be divided into two categories: weighted A*approaches and structural restricted approaches like beam search, Anytimewindow A*, contract search, etc.

In weighted A*(Pohl 1970), the heuristic used to calculated f(n) is mul-tiplied by a weight w. Thus, f(n) is calculated as f(n) = g(n) + w × h(n),where w > 1. We have concentrated on structurally restricted approachesbecause weighing the heuristics introduces non-admissibility which distortsthe basic characteristic of A*.

Anytime Window A* [12] localizes the global competition performed byA* by forming a fixed- window size comprising of a continuous set of lev-els of the search space. Some anytime heuristic search algorithms such asAnytime Weighted A* and Anytime Repairing A* use a weighted heuristicapproach [13, 14] to bias the search to converge quickly to sub-optimal so-lutions and then continue the search with same or relaxed weights to findimproved solutions. Anytime Non-parametric A* [15] explores the theorybehind the working of such algorithms and comes up with a non-parametric

6

approach (without weight-tuning) capturing the greediness of the weightedheuristic approaches to the maximum extent.

A simple anytime version the beam search involves repeatedly invok-ing the beam search algorithm with increasing beam-widths called Itera-tive Beam Search [16]. Beam-stack search [17] makes the beam search com-plete via chronological backtracking. BULB [18] is a complete anytime beamsearch algorithm that uses limited discrepancy backtracking. Anytime Ex-plicit Estimation search [19] that works by taking advantage of the differencesbetween solution cost and length.

The contract search problem involves finding the best possible solutionin the given time. In [20], a time constrained search algorithm is proposedbased on Weighted A*. The beam search algorithm [21] follows the strategythat for every level, a limited number (beam- width) of nodes are expandedat every level. A more sophisticated approach is used in the contract searchalgorithm [22, 23] , where instead of fixing the beam width to be same forall levels of the search tree, a probabilistic rank profile(PRP) is developedfor the optimal path node at every level and the total contract is distributedamong the levels according to the rank distribution at the different levels toobtain the node expansion limits(k(l)) at every level. Thus, few more nodescan be expanded at an important level at the cost of expanding lesser nodesat a non-important level. The underlying idea is that, for every level, if weexpand all the nodes with their f(n) values less than the f(n) value of theoptimal path goal node at that level, it is guaranteed to give us the optimalsolution. [22, 23] also studies some of the characteristics of the PRP functionand presents an approximate model to develop the profile function.

Deadline aware search algorithm [24] proceeds in a best-first manner butensuring that those nodes are chosen for expansion which can lead to a goalstate within the given time.

Anytime algorithms have mostly been explored for single objective opti-mization problems. In the domain of multi-objective optimization, methodshave been developed for finding near optimal solution like [7, 8, 9, 10]. Thealgorithms try to find a solution frontier lying within a close range of themost optimal solution. Some approximation schemes (PTAS, FPTAS, etc.)for multi-objective optimization problems have been proposed [7, 9, 10]. In[11], a branch-and-bound based method is presented which uses the notionof separating hyper-surface for pruning. But, all of these methods work onexplicit graphs except the method in [8].

Perny et al. [8] presents an MOA* based ǫ-admissible algorithm for mul-tiobjective search. Although this method works on implicit representation,the proposed algorithm is not an anytime algorithm. There is a significantamount of literature [25, 26] on applying evolutionary computing based

7

methods for multi-objective optimization problems for finding near optimalsolutions. However, these methods are not suitable for study in anytimesetting.

Patra et al.[4] describes an anytime heuristic search algorithm where inter-mediate results are sought at intervals of time which may be known apriori. Itproposes efficient anytime algorithms for single objective optimization prob-lems called Anytime Contract Search (based on the contract search frame-work) which incrementally explores the state-space with the given contracts(intervals of reporting).

Ghosh et al.[3] presents one anytime bi-objective search framework forbi-objective optimization problems. It works by maintaining a set of non-dominated solutions and improves this non-dominated set with time to ob-tain the pareto-optimal solution frontier. One objective is used to divide thesearch space into a specific number of segments and each segment is exploredusing a search strategy in order to find a solution. If the newly found solu-tion forms a non-dominated set when added to the current solution frontier,the segments are pruned accordingly and the solution frontier is updated.Newly expanded nodes are inserted into the segments to which they belongaccordingly.

The underlying search strategies explored in [3] include depth first branchand bound, beam stack and beam search. The framework is adaptive to othersearch strategies. In our work, we use the anytime contract search strategyin this multi-objective search framework.

2.2 Co-Design of Controllers of Schedulers

In order to build a complex embedded system, we need to bridge the semanticgap between its design and implementation as discussed in Chapter 1. Thesystem architecture and the scheduling policies of the platform on whichthe system is implemented has considerable effect on the performance whichillustrates the need to develop methods for controller-scheduler co-design.

For implementation of linear controllers on time-triggered systems, the ex-act gap between design and implementation has been formulated by Nghiemet al.[27] and Yazarel et al.[28]. Voit et al. [29] and Samii et al. [30] addressesthe problem of optimal co-design of controller and scheduler parameters inan embedded system. The scheduling policies cause message delay in thecontrol loops. Voit et al. derives a closed-form expression of message delayfrom the scheduler parameters using Real Time Calculus and explores thesedelays and controller parameters to arrive at an optimal co-design, whereasSamii et al. simulates the systems to estimate the distribution of message

8

delay values caused by the schedulers and uses this distribution as an inputto the Jitterbug toolbox [31] to compute control performance. [29] avoidssimulations and instead use closed-form expressions because of the mannerin which it approximates the effects of message delay on control performance.

Samii et al. has used only one performance metric to measure the con-troller performances and Voit et al. has introduced two more metrics. Inthis work, we have considered all three performance metrics, i.e., the delaymargin (depending on controller parameters K and b), peak overshoot andarea under the error-time curve.

Cervin et al.[32], Bini et al.[33] and Palopoli et al.[34] tries to find suitablescheduler designs, i.e., scheduler periods and priorities of the control loops,with the goal of improving control performance. Bini et al. has derived ananalytical method for it. Naghshtabrizi et al. [35] describes a delay impulsivemodel for a distributed control implementation and the implementation isdone on FlexRay based architecture. But the jitters and sporadic behaviorof messages, which come with FlexRay, are not considered.

Voit et al. uses a general model of the implementation platform thatenables them to compute the delays encountered in heterogeneous architec-tures in a form that can be plugged into their control performance model.Also, their work shows how complex bus arbitration schemes like hierarchicalschedules may be optimized for improved control performance. In this work,we follow their architecture and performance metrics but we increase the effi-ciency of the co-design process by exploiting the monotonicity of performancewith delay. For any two delays, δ1 and δ2, δ1 < δ2 ⇒ Perf1 < Perf2.

So, we study the problem of searching monotone multi-dimensional ar-rays efficiently. A d-dimensional array of real numbers is called monotoneincreasing if its entries are non-decreasing along each dimension, like our Per-formance with respect to controller delays. Vadlamudi et al.[36] describes adivide and conquer algorithm to search monotone multi-dimensional arrays.It finds all minimal index vectors for which the corresponding array valuesare better than a given key. It calculates the basis, which is the minimal non-dominating set of index vectors with array values ≤ key and the inner basis,the maximal non-dominating set of index vectors with array values > key, inlinear time with respect to the number of dimensions. The multi-dimensionalsearch space is explored in a binary search manner, and the number of queriesto get the functional value of a point in the array is minimized by dividingthe search space intelligently while generating sub-problems.

9

Chapter 3

Anytime Multi-ObjectiveSearch

Anytime multi-objective search maintains a pareto-optimal solution frontierwhile trying to solve a NP-complete multi-objective search problem. Here,we present a method to solve such multi-objective search problems usingcontract search approach that keeps a check on the total number of nodeexpansions and tries to obtain the best possible solution frontier, given aparticular limit of node expansions, i.e., a specific contract.

3.1 AnytimeMulti-Objective Contract Search

(MOACTR)

In this section, we present our proposed anytime heuristic search algorithm,Anytime Multi-objective Contract Search (MOACTR) which takes the mini-mum and maximum number of node expansions allowed (MINC andMAXC)as parameters. We have experimented with two versions of the algorithm.The first one distributes the nodes among different ranges based on one ob-jective and within each range, all the objectives are grouped together andkept at different levels. This approach is described in Section 3.1.1.

The second approach works in a recursive manner, i.e., it first distributesthe nodes depending on one objective. Nodes go to their particular ranges.Then, within each range, nodes are distributed into several sub-ranges de-pending on the value of the second objective. This process continues until wehave examined the values of all the objectives. This approach is described inSection 3.1.2.

10

3.1.1 Two Level distribution

The algorithm works by increasing the number of node expansions fromMINC to MAXC, following a certain strategy as in the case of single-objective Anytime Contract Search[4]. At any stage, the total number ofnodes is distributed in the different ranges following the strategy in moduleAdjustMultiContract. It also shows how the limit of node expansions atdifferent levels is updated within a particular range. d(l) denotes the totalnumber of node expansions allowed in level l and lim(i)(j) denotes the num-ber of node expansions allowed at level j of range i. Whenever a node isbelonging to a different range is obtained, it is inserted to the data structureof the range to which it belongs.

We keep track of the node expansions at different levels at every iter-ation of the algorithm with the help of ExpCount and ExpandedCount.ExpCount(r) is the nodes expanded in range r and ExpandedCount(i)(j) isthe nodes expanded at level j of range i. This helps in moduleAdjustMultiContract

to revise the new limits and proceed.The algorithm is similar to the single-objective optimization when we

are considering a particular range. The difference from the single-objectiveoptimization lies in the stage where we need to distribute the contract acrossdifferent ranges. We observe that nodes belonging to a particular range cangenerate children in same or higher ranges but the reverse is not true, i.e.,children cannot lie in a lower range. So, while distributing the contract, wegive more nodes to the lower ranges and lesser nodes to the higher ranges.

While revising the contract for each range, we observe the number of thenode expansions in that range, ExpCount(r), and do the updation accord-ingly. Now, we present the pseudocode of the algorithm in Algorithm 1.

11

Algorithm 1 Anytime Multi-objective Contract Search(MOACTR)

1: INPUT :: A search graph G, a start node s, the number of ranges, k, and minimumand maximum number of node expansions, MINC and MAXC respectively.OUTPUT :: Pareto-optimal solution frontier

2: INITIATIZATION ::

Adjust d(l) values according to MINC3: for i← 1 to k do

4: d(i)←MINC/k +m ∗ (k − 1− 2i)/2, where m is a tunable parameter5: for j ← 0 to MAXD do

6: lim(i)(j)← d(i)/MAXD;7: end for

8: end for

9: for contract←MINC to MAXC do

10: while ∃i such that range i is not explored do

11: Use a given policy to determine i.Start/Resume the MultiObjContractSearch on δi;

12: end while

13: C ← AdjustMultiContract(C, contract);14: if SolutionFrontier is not improvable then

15: break;16: end if

17: end for

return SolutionFrontier

AdjustMultiContract

1: INPUT ::

Old Cutoff d(l) and ExpCount(l) for each range of the graph, depending upon the oldcontract specification oldC;

2: OUTPUT ::

newC(l) for all levels, l3: for i← 0 to k do

4: expR(i)← α ∗ d(i) + (1− α) ∗ExpCount(i);5: for j ← 0 to MAXD do

6: WRR(i)(j) = β ∗ lim(i)(j) + (1− β) ∗ ExpandedCount(i)(j)where α and β are tunable parameters

7: end for

8: end for

Normalize(expR);9: for i← 0 to k do

10: Normalize(WRR(i));11: end for

12: for i← 0 to k do

13: d(i)← expR(i) ∗ newLimit;14: for j ← 0 to MAXD do

15: lim(i)(j)←WRR(i)(j) ∗ d(i));16: end for

17: end for

return newC;

12

MultiObjContractSearch

1: INPUT ::

The search graph, G, data structure, δ, range, r and the maximum number of nodeexpansions allowed at each level, lim(r)(l)

2: OUTPUT :: Best solution pathSELECTION::

Select node n having the least f(n) value across all OpenLists with SuspendF lag = 0;3: if No such n exists or f(n) >= BestSol then4: return BestSol;5: end if

Insert n into ClosedList;GOAL EVALUATION::

6: if IsGoal(n) then7: NewSol← f(n);

ExpandedCount(r)(level(n))← ExpandedCount(r)(level(n)) + 1;ExpCount(r)← ExpCount(r) + 1;

8: if NewSol < BestSol then9: BestSol← NewSol; Goal ← n;

Goto SELECTION10: end if

11: end if

EXPANSION::

12: for Each successor node m of n do

13: Calculate f(m);idx← range(m);Insert m to δidx;

14: end for

15: ExpCount(r)← ExpCount(r) + 1;ExpCount(r)(Level(n))← ExpCount(r)(Level(n)) + 1;

16: if ExpCount(r)(Level(n)) >= lim(r)(Level(n)) then17:18: for all Level l such that l <= Level(n) and SuspendF lag(l) = 0 do

19: SuspendF lag(l)← 1; (Optional, done only if goal depth is known)20: end for

21: end if

Goto SELECTION

13

3.1.2 N Level distribution

In this approach, we proceed in a similar way as in Section 3.1.1 but insteadof distributing the nodes and contract in two levels, we do it for n levels ina hierarchical manner, where n is the number of objectives. For each range,we have several sub-ranges depending on the value of the next objective.

The total number of nodes is distributed in the different ranges followingthe strategy in module AdjustMultiContract. It also shows how the limit ofnode expansions at different sub-ranges is updated within a particular range.d denotes the total number of node expansions allowed in a particular range,and lim(i) denotes the number of node expansions allowed in its sub-rangei.

We keep track of the node expansions at different levels at every iter-ation of the algorithm with the help of ExpCount and ExpandedCount.ExpCount is the nodes expanded in a range and ExpandedCount(i) is thenodes expanded at sub-range i of the corresponding range. This helps inmodule AdjustMultiContract to revise the new limits and proceed.

The pseudocode of the algorithm is presented in Algorithm 2.

Algorithm 2 Anytime Multi-objective Contract Search(MOACTR)

1: INPUT :: A search graph G, a start node s, the number of ranges, k, and minimumand maximum number of node expansions, MINC and MAXC respectively.OUTPUT :: Pareto-optimal solution frontier

2: INITIATIZATION ::

Adjust lim(l) values according to MINC3: for i← 1 to k do

4: lim(i)←MINC/k +m ∗ (k − 1− 2i)/2, where m is a tunable parameter5: Initialize(range(i), lim(i))6: end for

7: for contract←MINC to MAXC do

8: while ∃i such that range i is not explored do

9: Use a given policy to determine i.Start/Resume the MultiObjContractSearch on δi;

10: end while

11: C ← AdjustMultiContract(C, contract);12: if SolutionFrontier is not improvable then

13: break;14: end if

15: end for

return SolutionFrontier

14

AdjustMultiContract

1: INPUT ::

Old Cutoff lim(i) and ExpCount(i) for each range of the graph, depending upon theold contract specification oldC;

2: OUTPUT :: newC(l) for all levels l;3: for i← 0 to k do

4: expR(i)← α ∗ lim(i) + (1− α) ∗ ExpCount(i);5: end for

Normalize(expR);6: for i← 0 to k do

7: lim(i)← expR(i) ∗ newLimit;8: AdjustMultiContract(range(i), lim(i))9: end for

return newC;

15

MultiObjContractSearch

1: INPUT ::

The search graph, G, data structure, δ, range, r and the maximum number of nodeexpansions allowed at each level, lim(r)(l)

2: OUTPUT ::

Best Solution PathSELECTION::

3: if level = 0 then

4: Select node n having the least f(n) value across all OpenLists with SuspendF lag =0;

5: if No such n exists or f(n) >= BestSol then6: return BestSol;7: end if

Insert n into ClosedList;GOAL EVALUATION::

8: if IsGoal(n) then9: Update Solution frontier with n10: ExpandedCount((level(n))← ExpandedCount(level(n)) + 1;11: ExpCount← ExpCount+ 1;

Goto SELECTION12: end if

EXPANSION::

13: for Each successor node m of n do

14: Calculate f(m);idx← range(m);Insert m to δidx;

15: end for

16: ExpCount← ExpCount+ 1;ExpCount(Level(n)← ExpCount(Level(n)) + 1;Goto SELECTION

17: end if

18: if level > 0 then

19: for i← 1 to k do

20: MultiObjContractSearch(range(i))21: if ExpCount(i) >= lim(i) then22:23: for all Ranges l such that l <= i and SuspendF lag(l) = 0 do

24: SuspendF lag(l)← 1; (Optional, done only if goal depth is known)25: end for

26: end if

27: end for

28: end if

16

3.2 Experimental Results

We compare the anytime performance of Depth First Branch and Bound(DFBB),Beam Stack and Anytime Contract (ACTR). All the experiments have beenperformed on a Dell Precision T7500 Tower Workstation with Intel Xeon5600 Series at 3.47-GHz × 12 and 192-GB RAM.

We used the hypervolume metric to determine the quality of the solu-tion frontier. The hypervolume is calculated using the efficient approach asdescribed in [37]. Given n mutually non-dominating points in objectives,the method proposed in [37] is based on the idea of processing the pointsone objective at a time. This idea has been suggested independently beforebut here the idea is applied in a different manner by creating slices based onthe value of one objective in a way that the total number of calculations isreduced.

The optimality of a solution frontier is defined as :

θ = hypervolume(SolutionFrontier)hypervolume(OptimalSolutionFrontier)

× 100

Each range is taken to be of width 0.5. The value of beam-width andbeam-stack-width are both taken as 20. We have taken the timeout periodto be 1200 seconds. The value of the parameter m is taken to be equal to 1and the values of α and β are both taken to be equal to 0.5.

3.2.1 Multi-Objective Grid

Two level distribution

NM bi-objective grid of different sizes were constructed randomly, with N

ranging from 12 to 24 in steps of 3 and M ranging from 4 to 8 in steps of1. The node at position (0, 0, ..., 0) is the source and the node at position(N,N, ..., N) is the destination. The Manhattan distance heuristic functionwas used in this problem. We compare the average solution quality producedby the three algorithms over 5 instances for all the grid dimensions. Theresults are shown in Figures 3.1 to 3.5.

17

70

75

80

85

90

95

100

105

0 5 10 15 20 25

% O

ptim

al C

lose

ness

Time (Sec)

ACTRDFBB

BeamStack

Figure 3.1: Comparison of the average anytime performances of ACTR, DFBBand Beam Stack on grid of dimension 24× 24× 24× 24.

50

60

70

80

90

100

0 10 20 30 40 50

% O

ptim

al C

lose

ness

Time (Sec)

ACTRDFBB

BeamStack

Figure 3.2: Comparison of the average anytime performances of ACTR, DFBBand Beam Stack on grid of dimension 21× 21× 21× 21× 21.

18

50

60

70

80

90

100

0 5 10 15 20 25 30

% O

ptim

al C

lose

ness

Time (Sec)

ACTRDFBB

BeamStack

Figure 3.3: Comparison of the average anytime performances of ACTR, DFBBand Beam Stack on grid of dimension 18× 18× 18× 18× 18× 18.

50

60

70

80

90

100

0 10 20 30 40 50 60 70 80

% O

ptim

al C

lose

ness

Time (Sec)

ACTRDFBB

BeamStack

Figure 3.4: Comparison of the average anytime performances of ACTR, DFBBand Beam Stack on grid of dimension 15× 15× 15× 15× 15× 15× 15.

19

50

60

70

80

90

100

0 50 100 150 200

% O

ptim

al C

lose

ness

Time (Sec)

ACTRDFBB

BeamStack

Figure 3.5: Comparison of the average anytime performances of ACTR, DFBBand Beam Stack on grid of dimension 12× 12× 12× 12× 12× 12× 12× 12.

Also, we measure the average time required to produce the correspondingsolution qualities. The results are present in Appendix A.

N level distribution

We have run experiments with N = 3 for grid sizes ranging from 8 × 8 × 8to 18 × 18 × 18, N = 5 for grid sizes ranging from 2 × 2 × 2 × 2 × 2 to8× 8× 8× 8× 8 and N = 6 for grid sizes ranging from 2× 2× 2× 2× 2× 2to 6× 6× 6× 6× 6× 6 . We compare the performance of MOACTR, DFBBand Beam Stack. Figures 3.6 to 3.15 shows the relative performance of thethree algorithms.

MOACTR takes the parameter step which determines the width of eachrange in the data structure. Different values of step was used to run thealgorithm as mentioned in the plots.

20

75

80

85

90

95

100

0 50 100 150 200 250 300 350 400

% O

ptim

al C

lose

ness

Time

BBBeamStack

ACTR1ACTR2ACTR3

Figure 3.6: Comparison of the average anytime performances of MOACTR (withsteps 1,2,3), DFBB and Beam Stack on grid of dimension 8× 8× 8.

60

65

70

75

80

85

90

95

100

105

0 100 200 300 400 500

% O

ptim

al C

lose

ness

Time

BBBeamStack

ACTR1ACTR2ACTR3

Figure 3.7: Comparison of the average anytime performances of MOACTR(withsteps 1,2,3), DFBB and Beam Stack on grid of dimension 9× 9× 9.

21

60

65

70

75

80

85

90

95

100

105

0 100 200 300 400 500 600 700 800

% O

ptim

al C

lose

ness

Time

BBBeamStack

ACTR1ACTR2ACTR3

Figure 3.8: Comparison of the average anytime performances of MOACTR,DFBB(with steps 1,2,3) and Beam Stack on grid of dimension 10 × 10 × 10.

60

65

70

75

80

85

90

95

100

105

0 100 200 300 400 500 600 700 800

% O

ptim

al C

lose

ness

Time

BBBeamStack

ACTR1ACTR2

Figure 3.9: Comparison of the average anytime performances of MOACTR(withsteps 1,2), DFBB and Beam Stack on grid of dimension 11× 11× 11.

22

60

65

70

75

80

85

90

95

100

105

0 200 400 600 800 1000

% O

ptim

al C

lose

ness

Time

BBBeamStack

ACTR1ACTR2ACTR3ACTR4

Figure 3.10: Comparison of the average anytime performances of MOACTR(withsteps 1 to 5), DFBB and Beam Stack on grid of dimension 12× 12× 12.

30

35

40

45

50

55

60

65

70

75

0 200 400 600 800 1000

% O

ptim

al C

lose

ness

Time

BBBeamStack

ACTR5ACTR6ACTR7ACTR8ACTR9

ACTR10

Figure 3.11: Comparison of the average anytime performances of MOACTR(withsteps 5 to 10), DFBB and Beam Stack on grid of dimension 18 × 18× 18.

23

70

75

80

85

90

95

100

105

0 50 100 150 200 250 300 350 400

% O

ptim

al C

lose

ness

Time

BBBeamStack

ACTR32ACTR36ACTR40ACTR44ACTR48ACTR52ACTR56

Figure 3.12: Comparison of the average anytime performances of MOACTR(withsteps 32 to 56), DFBB and Beam Stack on grid of dimension 7× 7× 7× 7× 7.

60

65

70

75

80

85

90

95

100

0 100 200 300 400 500 600 700 800

% O

ptim

al C

lose

ness

Time

BBBeamStack

ACTR36ACTR40ACTR44ACTR48ACTR56

Figure 3.13: Comparison of the average anytime performances of MOACTR(withsteps 32 to 56), DFBB and Beam Stack on grid of dimension 8× 8× 8× 8× 8.

24

60

65

70

75

80

85

90

95

100

105

0 20 40 60 80 100

% O

ptim

al C

lose

ness

Time

BBACTR100

ACTR50BeamStack

Figure 3.14: Comparison of the average anytime performances of MOACTR(withsteps 50 and 100), DFBB and Beam Stack on grid of dimension 5×5×5×5×5×5.

60

65

70

75

80

85

90

95

100

105

0 100 200 300 400 500 600

% O

ptim

al C

lose

ness

Time

BBBeamStack

MOACTR

Figure 3.15: Comparison of the average anytime performances of MOACTR(withstep 100), DFBB and Beam Stack on grid of dimension 6× 6× 6× 6× 6× 6.

25

Optimal Value of step

From the above plots, we observe that the performance is best at a par-ticular value of step. Increasing or decreasing it worsens the performanceof MOACTR. Thus, we conclude that we need to develop a mechanism todecide the optimal value of the parameter step. We try to do by observingthe pattern of node expansions. Figures 3.16 to 3.18 shows how the numberof node expansions vary with step and hence affect the quality of solution.Here, the quality of solution for a particular value of step is represented bythe area under its Solution Quality Vs Time curve.

80000

100000

120000

140000

160000

180000

0 1 2 3 4 5 6

Nod

e ex

pans

ions

and

are

a

Step

Area (Soln Quality Vs Time)Node expansions

Figure 3.16: Comparison of the average anytime performances (Area under theSolution Quality Vs Time curve) and number of node expansions for differentvalues of step for grid of size 12× 12× 12.

26

100000

150000

200000

250000

300000

0 1 2 3 4 5 6 7

Nod

e ex

pans

ions

and

are

a

Step

Area(Soln Quality Vs Time)Node expansions


70000

80000

90000

100000

110000

120000

130000

140000

4 5 6 7 8 9 10 11 12

Nod

e ex

pans

ions

and

are

a

Step

Area (Soln Quality Vs Time)Node expansions


27

3.3 Discussion

For the 2-level version, we observe that initially with small grid sizes anddimensions, MOACTR performs better. As the size gradually increases, theother algorithms starts performing better for the some initial duration andthen MOACTR catches up. But as the size further increases, the anytimecontract search dominates the solution quality. The beam stack algorithmproduces good results initially but is not able to improve upon it much astime progresses.

The depth first branch and bound takes time to produce the first solutionbecause initially it behaves like a breadth first search due to the presence of anumber of ranges which add a breadth wise component to the search pattern.

The N-level version of the algorithm gives better anytime performancethan the others. The trick lies in choosing the optimal value of the parameterstep which can be done by studying the node expansion and performanceprofiles for different values of step and grid sizes.

28

Chapter 4

Co-design of Controllers andScheduler for Optimal ControlPerformance with HierarchicalSchedules

Our objective is to find an optimal methodology to identify the optimal de-sign of controller and scheduler parameters so as to maximize the overallperformance of the embedded system. This chapter is organized as follows.A description of the system we have considered to explore the design space isprovided in Section 4.1. Section 4.2 shows a way to formulate an optimiza-tion problem corresponding to such type of systems. Section 4.3 describesour approach towards exploration of the design space and identifying theoptimal design. Section 4.4 presents the pseudo-code of the algorithm usedand illustrates a run through with an example. Section 4.5 shows the ex-perimental results obtained using our approach in order to find the optimalconfiguration.

4.1 System description

We are considering an embedded system with multiple(n) control applica-tions. One control application may use multiple processing units. We aremodelling four processing units, one each for user input, controllers, sensorsand actuators. Fixed priority schedule is used to execute tasks within eachof the processing units. These units communicate with each other with thehelp of a shared communication bus. We show the execution of one controlapplication in Figure 4.1.

29

PU1 PU2 PU3 PU4

m1 m2

m3

SCHEDULING BUS

User Input ActuatorsSensorsControllers

Figure 4.1: Execution of one control application

We see that message m1 is sent by processor 1 to processor 2, messagem2 from processor 3 to 2 and message m3 from processor 2 to 4. So, the buswill need to transmit these three messages. We assume the scheduler followsa fixed priority (FP), m1 > m2 > m3, for transmitting these messages, i.e.,if m1 is ready to be transmitted, it gets the bus and m2 and m3 has to waitand if m1 is not there, m2 gets preference over m3. Similarly, other controlapplications have their own fixed priority order for their own messages.

We have n such control applications. So, the message transmission viathe communication bus will be something similar to as modelled in Figure4.2(figure drawn assuming n = 3).

��

��

��

��

PU1 PU2 PU3 PU4

SCHEDULING BUS

User Input ActuatorsSensorsControllers

Control Application 1Control Application 2

Control Application 3

Figure 4.2: Execution of three control applications

Now, we need to decide how to share the bus among different control ap-plications. We follow a TDMA strategy where we give each of the applicationits own slot in a cycle to transmit its messages. So, every cycle is dividedinto n slots, corresponding to each control application. Control application i

can transmit any of its messages only in slot i of a cycle. It cannot transmitin any other slot even if that slot is free. Within slot i, control application i

will follow FP to transmit messages when multiple messages are ready to betransmitted as described earlier.

30

Thus, the bus follows a TDMA/FP hierarchical scheduling policy asshown in Figure 4.3.

Slot 1

m1 > m2 >m3

Slot 2 Slot 3 Slot n−1 Slot n

m4 > m5 m6 > m7 mp>mq>mr ms > mt

TDMA cycle length = c

Figure 4.3: Scheduling policy

In order to carry out the optimal co-design, we assume that the plant/actuatorhas the following transfer function,

P (s) = Kp

s2+s

with Kp = 1000, and the controller i modelled with the equation,

Ci(s) = Ki(s+ bi)e−τis, ∀i = 1 to n

Ki and bi are the parameters of controller i and τi is the delay of thecontrol application i due to communication and computation. So, when weexplore the design space, we need to explore the values of Ki and bi for eachcontroller i, ∀i = 1 to n.

The performance of each of the controllers is measured with the help ofthree control performance metrics defined as follows:

P0 =1

Lm, where Lm is the delay margin of the plant P with the controller

and depends on Kp, K and b.

P1 = Peak overshoot

P2 =∫∞

0 e(t)2dt, where e(t) is the tracking error

4.2 Formulation as an Optimization Problem

In order to design the scheduler, we need to decide the slot sizes for each ofthe control applications. A particular slot distribution will correspond to n

different end-to-end delays in the n control applications. In a single controlloop, increasing its end-to-end delay will decrease the performance whenother parameters are unchanged. But, if we tune the controller parameters(Kand b), the performance can change to reach the desired value. So, the

31

optimal controller parameter values are dependent on the end-to-end delayof the control loop in which it is being used. Summarizing,

Performance = f(K, b,Delay)

Delay = f(slotSize)

As we explore the design space of slot sizes in the scheduler, some designswill not be feasible because they may lead to an infinite end-to-end delay inone of the control loops. For the set of feasible slot sizes (finite end-to-enddelay for all control loops), there are optimal values of controller parameters,K and b which lead to best performance. So, we need to explore the spaceof K and b for each of the feasible slot sizes.

We note that increasing delay decreases the performance. So, one of ourobjectives should be minimizing the total end-to-end delay in each of thecontrol loops. The best performance should be achieved by the design whichwill lead to 0 delay in all the control loops. But, there does not exist anysuch slot distribution in the scheduler which will lead to no delay in all thecontrol loops. Giving one control application a greater part of the cycle willmean that other control applications will suffer and have more delays. Weneed to identify a slot distribution that improves the overall performance ofthe system.

Let the end-to-end delays in the n control loops be δ1, δ2, ...δn.So, our objective is to minimize

∑ni=1 δi, subject to the condition that

∑ni=1 δi ≤MAX DELAY

So, while exploring the design space for∑n

i=1 δi = D, then we need toexplore all the combinations of δ1, δ2, ...δn such that their sum is D.

Also, if Perf1, P erf2, P erf3, .., P erfn be the weighted performance ofeach of the n control applications, our one objective is to maximize the netperformance of the system, which is

∑ni=1 Perfi

Considering the two objectives of our optimization, we need to minimizethe value of

wp

∑ni=1 Pi + wδ

∑ni=1 δi

(We note that we have defined our performance metrics in a way thatlower values of the metrics means better performance).

A complete design of our system should determine the specifications ofthe controllers and the scheduler. A controller is described by its parameters,K and b and our TDMA/FP hierarchical scheduler is described by its slotsizes and the total cycle length. We have n controllers in our embeddedsystem. So, a design can be described as a set of the following parameters:

32

• A list of control parameter K for the n controllers, K[1...n]

• A list of control parameter b for the n controllers, b[1...n]

• A list of slot sizes, s[1...n]

• The total cycle length, C =∑n

i=1 s[i]

The performance of a design is a set of performance metrics, with threeperformance metrics for each control application. Thus, it can be describedusing the following parameters:

• A list of performance metrics P0 for the n controllers, P0[1...n]



4.3 Approach for Optimal Co-design

We observe that as delay increases the performance become worse. So, theperformance is a monotone function of delay. From this observation, we canconclude that VC algorithm can be used to calculate the maximum affordabledelay in the our system which achieves the desired performance. No delayvalues which dominate the resultant delay will lead to acceptable performanceof the system. Whenever query is made by the VC algorithm to find theperformance of a particular delay combination, simulations can be run withvarying K and b to find the best possible performance, the correspondingvalue of which is returned. Due to the high cost of running simulations, theVC algorithm is very helpful in this scenario because it minimizes the numberof function evaluations of the multi-dimensional delay array.

The set of non-dominating delays as returned by the VC algorithm formsan upper bound of the allowable message delays by the different slot con-figurations of the scheduler. Now, the search space of the scheduler slotsis explored to determine the corresponding message delays in the n controlloops. If a feasible solution is found, i.e.,

∀i : delayi ≤ δi,

where δ[1...n] is a member of the basis set returned by the VC algorithm,we have found an optimal design for the system.

33

The delay calculations from slot sizes is done using Real Time Calculuswith the help of the RTC Toolbox of MATLAB. Because of the fixed priorityhierarchical schedules, each message has its priority to use the communicationbus. Depending on the priority level of a message, it get the service of thecommunication channel. Correspondingly, the remaining service is availableto the other messages of lower priority. The Real Time calculus is wellequipped to deal with sporadic signals and signals with jitter.

After the allowable delays of the control loops are established, the optimalvalues of K and b can be determined independently for each control appli-cation because the dependence was only because the communication amongprocessors which is present in the form of delay.

4.4 Algorithm for Optimal Co-design

Now, we are ready to present the algorithm for optimal co-design. Ourobjective is to calculate the most optimal configuration set which gives thedesired performance, PREF . The pseudo-code is as presented in Algorithm 3.

Algorithm 3 Co-design

1: INITIALIZATION:2: for i← 1 to n do

3: lower(i)←MAX DELAY4: upper(i)←MIN DELAY5: end for

6: delay basis← FindBasisV C(lower, upper)7: FindSchedulerSlots(delay basis)

34

FindBasisVC1: INITIALIZATION:2: B ← φ, iB ← φ3: mid← midpoint(lower, upper)4: amid ← GetF (mid)5: if amid ≤ PREF then

6: Go to step 4 with (lower,mid)7: else

8: Go to step 4 with (mid, upper)9: Update iB with mid10: end if

11: Generate Child problems efficiently using VC approach12: if v is non-dominating with B then

13: Add v to B14: end if

15: return B;

GetF1: for i← 1 to n do

2: bestPerf(i)←∞3: for K ←MINK to MAXK do

4: for b←MINb to MAXb do

5: Perf ← Simulate(controller(i),K, b, delay(i))6: if bestPerf(i) > Perf then

7: bestPerf(i)← Perf8: end if

9: end for

10: end for

11: end for

12: return bestPerf

FindSchedulerSlots1: start← StartSlotsConfig()2: Create a queue q with start3: while q 6= φ do

4: c← dequeue(q)5: feasible← CalculateFeasibility(c)6: if feasible = true and delay basis allows Delay(c) then7: Add c to Solution8: end if

9: Enqueue c’s children to q10: end while

35

CalculateFeasibility

1: INPUT :: Slot[1...n]2: OUTPUT :: True if Delay(Slot) is finite, False, otherwise3: //Delay calculation using Real Time Calculus4: Initialization of service curves for the processors::5: for i← 1 to n do

6: S(i)← rtcpjd(p1, p2, p3)7: end for

8: P ← rtcfs(1)9: for i← 1 to n do

10: R(i, upper)← rtctdmau(Slot(i))11: R(i, lower)← rtctdmal(Slot(i))

12: R(i)← rtcaffine(R(i),∑i−1

j←1Slot(j))

13: end for

14: //Calculation of Delay15: for i← 1 to n do

16: msg out(0)← S(i)17: for j ← 1 to n do

18: [msg(j), T askDelay(j)]← rtcgpc(msg out(i − 1), P, exeDelayTask(j))19: [msg out(j),MsgDelay(j)]← rtcgpc(msg(j), P, exeDelayMsg(j))20: end for

21: delay(i)←∑n

j=1TaskDelay(j) +

∑n

j=1MsgDelay(j)

22: if delay(i) =∞ then

23: return false24: end if

25: end for

26: return true

36

4.4.1 Illustration with an example

We go through a run of our algorithm for a small example with n = 3and the delay space [(74, 74, 74)ms, (75, 75, 75)ms]. Lower will be initial-ized to (75, 75, 75) and upper = (74, 74, 74). With PREF = 44.40, theCalculateBasisV C module gives us a basis of size 1, (75, 74, 74). We ex-plore the whole delay space as well to check the correctness of the module.The weighted performance of the system as a function of delay is presented inTable 4.1. We see that the Performance is indeed a monotonic function of thedelay, i.e., consider any two delays, say δ1 = (74, 75, 75) and δ2 = (74, 75, 74).δ1 < δ2 implies Perf(δ1) < Perf(δ2) (lower values of performance metricsindicates better performance). We observe that this is true for all possiblechoices of δ1 and δ2. From the table, the basis is indeed (75, 74, 74). Atthis stage, we also calculate the optimal values of K and b for the threecontrollers.

Next, we explore the scheduler slot space, to find a slot configuration thatgives us a delay ≤ (75, 74, 74). Table 4.2 shows the results. We observe that(2, 1, 1) ms is a feasible slot configuration.

D1 D2 D3 Perf74 74 74 44.4074 74 75 44.5674 75 74 44.4174 75 75 44.5775 74 74 44.4075 74 75 44.5675 75 74 44.41

Table 4.1: Weighted performance as a function of delay (in ms)

37

Table 4.2: Delay as a function of Slot sizes (in ms)Slot1 Slot2 Slot3 Delay1 Delay2 Delay3 Feasible1 1 1 ∞ ∞ ∞ No1 4 4 ∞ ∞ ∞ No2 1 1 54 54 71 Yes2 1 2 85 73 70 No2 1 3 ∞ ∞ ∞ No2 1 4 ∞ ∞ ∞ No2 2 1 85 41 77 No2 2 2 ∞ ∞ ∞ No2 4 4 ∞ ∞ ∞ No3 1 1 43 83 74 No3 1 2 59 100 65 No3 1 3 ∞ ∞ ∞ No3 1 4 ∞ ∞ ∞ No3 2 1 59 47 92 No3 2 2 84 59 75 No3 2 3 ∞ ∞ ∞ No3 2 4 ∞ ∞ ∞ No3 3 1 84 40 106 No3 3 2 ∞ ∞ ∞ No3 4 4 ∞ ∞ ∞ No4 1 1 39 100 80 No4 1 2 ∞ ∞ ∞ No4 1 4 ∞ ∞ ∞ No4 2 1 50 57 106 No4 2 2 59 64 79 No4 2 3 68 77 85 No4 2 4 96 99 76 No4 3 1 59 47 120 No4 3 2 68 59 81 No4 3 3 96 62 85 No4 3 4 ∞ ∞ ∞ No4 4 1 68 49 149 No4 4 2 96 50 91 No4 4 3 ∞ ∞ ∞ No4 4 4 ∞ ∞ ∞ No

38

4.5 Experimental Results

4.5.1 3 Control Loops with Hierarchical Scheduling

We consider the system with 3 control loops and sensor inputs a combinationof periodic, periodic with jitter and sporadic signals. The value ofKp for eachplant is taken to be 1000. The scheduler decides the slot sizes for each controlapplication. The different slot sizes corresponds to unique delays in thedifferent control applications. We explore delay spaces of different sizes andcalculate the basis. Some results are summarized in Table 4.3. Additionalsimulation results which include values of performance metric and feasibilityof slots are included in Appendix B.

Delay Space Basis1 [(74, 74, 74),(75, 75, 75)] (75, 74, 74)2 [(73, 73, 73),(75, 75, 75)] (74, 74, 74)3 [(74, 74, 74),(77, 77, 77)] (76, 73, 74),(74,74,74)4 [(72, 72, 72),(76, 76, 76)] (75, 75, 75)5 [(85, 85, 85),(90, 90, 90)] (89,89,86),(84,89,87),(85,88,87),(87,87,87)6 [(85, 85, 85),(91, 91, 91)] (90,90,86),(84,90,87),(86,88,87),(85,89,87)

(90,86,87),(87,87,87)7 [(85, 85, 85),(92, 92, 92)] (91,91,86),(84,89,87),(86,87,91),(91,86,91)

(87,87,87)8 [(85, 85, 85),(93, 93, 93)] (92,92,86),(84,90,87),(86,88,92),(92,86,92)

(87,87,87)Table 4.3: Basis for delay spaces of different sizes

The performance metrics are functions of the delay and the controllerparameters K and b. We show the variation of performance with K and b asfollows. We do it for the following feasible slot configurations:

(2 ms,1 ms,2 ms), (3 ms,2 ms,1 ms), (3 ms,3 ms,1 ms)

The overall performance of each controller as a linear combination of itsperformance metrics, P0, P1 and P2 and observe that the optimal valuesare different for different slot sizes. Figures 4.4 to 4.12 shows the plots ofperformance for the controllers 1 to 3. The optimal values are mentioned inthe top of the figure.

39

00.5

11.5

22.5

0

1

2

3

4

x 10−3

0

0.02

0.04

0.06

0.08

0.1

b

controller1_0.016312_0.0013_0.71

K

Per

form

ance

Figure 4.4: Variation in Performance with respect to K and b in controller1 with s1 = 2ms, s2 = 1ms and s3 = 2ms

00.5

11.5

22.5

0

1

2

3

4

x 10−3

0.01

0.02

0.03

0.04

0.05

0.06

0.07

b

controller1_0.016664_0.0013_0.56

K

Per

form

ance


40

00.5

11.5

22.5

0

1

2

3

4

x 10−3

0

0.02

0.04

0.06

0.08

0.1

b

controller1_0.016346_0.0013_0.71

K

Per

form

ance


00.5

11.5

22.5

0

1

2

3

4

x 10−3

0.2

0.4

0.6

0.8

1

b

controller2_0.20782_0.0013_0.66

K

Per

form

ance


41

00.5

11.5

22.5

0

1

2

3

4

x 10−3

0.2

0.3

0.4

0.5

0.6

0.7

b

controller2_0.20152_0.0009_0.46

K

Per

form

ance


00.5

11.5

22.5

0

1

2

3

4

x 10−3

0.2

0.3

0.4

0.5

0.6

0.7

b

controller2_0.22186_0.0009_0.46

K

Per

form

ance


42

00.5

11.5

22.5

0

1

2

3

4

x 10−3

5

10

15

20

25

30

b

controller3_5.3262_0.0013_0.91

K

Per

form

ance



43

00.5

11.5

22.5

0

1

2

3

4

x 10−3

0

20

40

60

80

b

controller3_5.6403_0.0013_1.06

K

Per

form

ance


4.5.2 Improvement in efficiency

We compare the time required to calculate the feasible delays in order toachieve a required performance, PREF by using the VC algorithm with thetime required for doing so by exploring the whole search space. Size of delaymatrix is varied from 1× 1× 1 to 8× 8× 8 and simulation is run for 1 hourfor each size. The results are presented in Table 4.4 and a plot is shownin Figure 4.13. We observe that VC algorithm performs much better asexpected.

Size of delay Matrix Time(VC)(in sec) Time(full)(in sec)1× 1× 1 15 352× 2× 2 70 1183× 3× 3 83 2834× 4× 4 120 6135× 5× 5 301 10976× 6× 6 439 15437× 7× 7 446 25888× 8× 8 551 > 4000Table 4.4: Comparison of execution time of the two approaches

44

1 2 3 4 5 6 7 80

500

1000

1500

2000

2500

3000

3500

4000

Width along each dimension of the delay space (in ms)

Tim

e ta

ken

for

calc

ulat

ing

basi

s(in

sec

)

VCstandard

Figure 4.13: Comparison of VC and standard approach in terms to timerequired to find optimal delay

4.6 Discussion

The co-design of controller and scheduler is performed in a way which isuseful in real-life applications and does not make any assumptions about thenature of sensory inputs or message delays caused by the scheduler. Theexploration of design space is being done is an intelligent manner so as toreduce the number of controller simulations which is expensive. However,while deciding the slot sizes of each control loop, the whole search space isbeing explored. This is because there is no observable relation between theslot sizes and delay.

45

Chapter 5

Conclusion

We proposed the problem of optimizing anytime performance for multi-objective optimization problems. Anytime contract search, depth first branchand bound and beam stack algorithms are implemented on the newly devel-oped multi-objective framework for N -level node distribution, N being thenumber of objectives. An efficient scheme is developed to distribute thecontract among the ranges and the levels within each range.

The contract distribution scheme is a major aspect of the algorithm. Ourscheme builds on the previous distributions and the number of nodes ex-panded so far. However, there is ample scope here to study entirely differentand novel schemes and choose the best one. We have studied some other basicschemes such as, one which always distributes the contract equally amongstall levels, etc. which did not fare well compared to the one presented. Thegiven schemes use a pre-defined constant value for α, β, m and step whichmay also be learned/tuned during the run.

Coming up with a good dynamically learning framework for the contractdistribution is an interesting problem. Also, one may explore other optionsinspired by the existing contract search algorithms that are parameter-free.

In the co-design problem, an efficient scheme is developed to find the op-timal configuration of the controller and schedulers making use of the VCalgorithm for monotone multidimensional arrays. According to the require-ments of the user, we are able to calculate the optimal delay and schedulerslot configuration.

46

Bibliography

[1] Edwin J. Elton, Martin J. Gruber, and Christopher R. Blake. Modernportfolio theory, 1950 to date. SSRN eLibrary, 1997.

[2] Frederic S. Mishkin. The Economics of Money, Banking, and FinancialMarkets. Addison-Wesley, 7th edition, 2004.

[3] Priyankar Ghosh, P. P. Chakrabarti, and Pallab Dasgupta. Anytimealgorithms for biobjective heuristic search. In 25th Australasian jointconference on Advances in Artificial Intelligence, pages 230–241, 2012.

[4] Sunandita Patra, Satya Gautam Vadlamudi, and P. P. Chakrabarti.Anytime contract search. In 33rd International Conference for Arti-ficial Intelligence(BCS-SGAI), 2013.

[5] P. E. Hart, N. J. Nilsson, and B. Raphael. A formal basis for the heuristicdetermination of minimum cost paths. IEEE Transactions on SystemsScience and Cybernetics, 4(2):100–107, July 1968.

[6] T. Dean and M. Boddy. An analysis of time-dependent planning. InProceedings of 6th National Conference on Artificial Intelligence (AAAI88), pages 49–54, St. Paul, MN, 1988. AAAI Press.

[7] George Tsaggouris and Christos D. Zaroliagis. Multiobjective optimiza-tion: Improved FPTAS for shortest paths and non-linear objectives withapplications. Theory Comput. Syst., 45(1):162–186, 2009.

[8] Patrice Perny and Olivier Spanjaard. Near admissible algorithms formultiobjective search. In ECAI, pages 490–494, 2008.

[9] Eric Angel, Evripidis Bampis, and Alexander Kononov. On the approx-imate tradeoff for bicriteria batching and parallel machine schedulingproblems. Theor. Comput. Sci., 306(1-3):319–338, 2003.

47

[10] Christos H. Papadimitriou and Mihalis Yannakakis. On the approxima-bility of trade-offs and optimal access of web sources. In FOCS, pages86–92, 2000.

[11] Francis Sourd and Olivier Spanjaard. A multiobjective branch-and-bound framework: Application to the biobjective spanning tree problem.INFORMS Journal on Computing, 20(3):472–484, 2008.

[12] S. Aine, P. P. Chakrabarti, and Rajeev Kumar. AWA* - A windowconstrained anytime heuristic search algorithm. In Manuela M. Veloso,editor, IJCAI, pages 2250–2255, 2007.

[13] Eric A. Hansen and Rong Zhou. Anytime heuristic search. J. Artif. Int.Res., 28(1):267–297, March 2007.

[14] M. Likhachev, G. J. Gordon, and S. Thrun. ARA*: Anytime A* withprovable bounds on sub-optimality. In Advances in Neural InformationProcessing Systems 16. MIT Press, Cambridge, MA, 2004.

[15] Jur van den Berg, Rajat Shah, Arthur Huang, and Kenneth Y. Goldberg.Anytime nonparametric A*. In AAAI, 2011.

[16] Peter Norvig. Paradigms of Artificial Intelligence Programming: CaseStudies in Common Lisp. Morgan Kaufmann Publishers Inc., San Fran-cisco, CA, USA, 1st edition, 1992.

[17] R. Zhou and E. A. Hansen. Beam-stack search: Integrating backtrackingwith beam search. In Proceedings of the 15th International Conferenceon Automated Planning and Scheduling (ICAPS-05), pages 90–98, Mon-terey, CA, 2005.

[18] David Furcy and Sven Koenig. Limited discrepancy beam search. InProceedings of the 19th international joint conference on Artificial in-telligence, IJCAI’05, pages 125–131, San Francisco, CA, USA, 2005.Morgan Kaufmann Publishers Inc.

[19] Jordan Tyler Thayer, J. Benton, and Malte Helmert. Better parameter-free anytime search by minimizing time between solutions. In SOCS,2012.

[20] Hironori Hiraishi, Hayato Ohwada, and Fumio Mizoguchi. Time-constrained heuristic search for practical route finding. In Hing-YanLee and Hiroshi Motoda, editors, PRICAI98: Topics in Artificial In-telligence, volume 1531 of Lecture Notes in Computer Science, pages389–398. Springer Berlin Heidelberg, 1998.

48

[21] B. Lowerre. The Harpy Speech Recognition System. PhD thesis,Carnegie Mellon University, 1976.

[22] S. Aine, P. P. Chakrabarti, and Rajeev Kumar. Heuristic search undercontract. Computational Intelligence, 26(4):386–419, 2010.

[23] Sandip Aine, P. P. Chakrabarti, and Rajeev Kumar. Contract search:Heuristic search under node expansion constraints. In ECAI, pages 733–738, 2010.

[24] Austin J. Dionne, Jordan Tyler Thayer, and Wheeler Ruml. Deadline-aware search using on-line measures of behavior. In SOCS, 2011.

[25] Jurgen Branke, Kalyanmoy Deb, Kaisa Miettinen, and Roman Slowin-ski, editors. Multiobjective Optimization: Interactive and EvolutionaryApproaches. Springer-Verlag, Berlin, Heidelberg, 2008.

[26] Kalyanmoy Deb, Samir Agrawal, Amrit Pratap, and T. Meyarivan. Afast and elitist multiobjective genetic algorithm: NSGA-II. IEEE Trans.Evolutionary Computation, 6(2):182–197, 2002.

[27] T. Nghiem, G. J. Pappas, R. Alur, and A. Girard. Time-triggered imple-mentations of dynamic controllers. In 6th ACM and IEEE Internationalconference on Embedded software (EMSOFT), 2006.

[28] H. Yazarel, A. Girard, G. J. Pappas, and R. Alur. Quantifying the gapbetween embedded control models and time-triggered implementations.In 26th IEEE Real-Time Systems Symposium (RTSS), 2005.

[29] Harald Voit, Reinhard Schneider, Dip Goswami, Anuradha Annaswamy,and Samarjit Chakraborty. Optimizing hierarchical schedules for im-proved control performance. In 5th International Symposium on Indus-trial Embedded Systems (SIES), pages 230–241, 2010.

[30] S. Samii, A. Cervin, P. Eles, and Z. Peng. Integrated scheduling andsynthesis of control applications on distributed embedded systems. InDesign, Automation and Test in Europe (DATE), 2009.

[31] B. Lincoln and A. Cervin. Jitterbug: A tool for analysis of real-timecontrol performance. In 41st IEEE Conference on Decision and Control(CDC), 2002.

[32] A. Cervin and T. Henningsson. Scheduling of event-triggered controllerson a shared network. In 47th IEEE Conference on Decision and Control(CDC), 2008.

49

[33] E. Bini and A. Cervin. Delay-aware period assignment in control sys-tems. In IEEE Real-Time Systems Symposium (RTSS), 2008.

[34] L. Palopoli, C. Pinello, A. L. Sangiovanni-Vincentelli, L. Elghaoui, andA. Bicchi. Quantifying the gap between embedded control models andtime-triggered implementations. In Synthesis of robust control systemsunder resource constraints. In 5th International Workshop on HybridSystems: Computation and Control (HSCC), 2002.

[35] P. Naghshtabrizi and J. Hespanha. Analysis of distributed control sys-tems with shared communication and computation resource. In In Proc.of the 2009 Amer. Contr. Conf., 2009.

[36] Satya Gautam Vadlamudi and P. P. Chakrabarti. Efficient algorithmsfor searching monotone multi-dimensional arrays. In FCTTCS, 2012.

[37] Lyndon While, Philip Hingston, Luigi Barone, and Simon Huband. Afaster algorithm for calculating hypervolume. In Evolutionary Compu-tation, IEEE Transactions on, volume 10, pages 29–38. IEEE, 2006.

50

Appendix A

Anytime Multi-ObjectiveSearch (AMOS) Results

A.1 Multi-Objective Anytime Contract Search:

2 - level

Table A.1: Avg Time Required to achieve the corresponding quality of solutionfor multi-objective grid of dimension 4 using Anytime Contract Search

Solution Quality (in %) Vs Avg Time Required (in sec)57% 0.090 58% 0.092 59% 0.096 70% 0.48374% 0.484 80% 0.933 84% 0.959 85% 0.97488% 1.578 89% 1.679 91% 1.702 93% 2.34996% 2.447 97% 2.957 98% 4.041 99% 4.809


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.238 50% 1.526 51% 1.563 52% 1.58253% 1.598 54% 3.022 55% 3.059 60% 3.10163% 3.166 65% 3.259 66% 4.889 67% 5.20969% 5.287 70% 5.591 71% 5.629 73% 7.57874% 8.069 75% 8.421 79% 10.419 80% 10.96382% 12.399 86% 15.392 87% 15.773 88% 16.21189% 17.513 90% 20.468 94% 25.532 100% 28.263

51


Solution Quality (in %) Vs Avg Time Required (in sec)54% 0.163 55% 0.170 68% 1.015 70% 1.03774% 2.114 75% 4.014 76% 6.459 77% 6.47278% 6.482 79% 6.891 82% 8.686 84% 9.25985% 10.160 87% 11.392 92% 11.770 93% 12.26194% 12.733 95% 14.080 97% 14.251 99% 15.191100% 15.223


Solution Quality (in %) Vs Avg Time Required (in sec)51% 1.895 53% 1.920 54% 1.937 55% 1.94058% 4.055 60% 4.129 62% 4.151 73% 6.87875% 11.414 76% 13.959 77% 20.923 79% 21.99680% 22.166 82% 25.308 83% 31.187 84% 32.13285% 34.587 86% 36.825 88% 37.465 93% 41.91894% 44.596 99% 47.798 100% 49.927


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.657 50% 0.779 53% 3.824 54% 3.84955% 3.897 56% 4.191 57% 4.259 61% 7.72063% 7.987 64% 8.592 68% 9.032 70% 15.40872% 15.579 73% 15.900 74% 16.293 75% 17.43477% 27.474 78% 30.907 81% 37.571 82% 45.44585% 74.040 86% 74.831 88% 82.961 89% 96.47990% 103.607 92% 114.534 93% 116.147 94% 129.52795% 131.714 96% 132.015 97% 136.145 98% 140.41899% 141.800 100% 164.292

52


3 - level

Table A.6: Avg Time Required to achieve the corresponding quality of solutionfor multi-objective grid of size 8× 8× 8 using level 3 MOACTR with step 1

Solution Quality (in %) Vs Avg Time Required (in sec)53% 0.663 54% 0.640 55% 0.694 56% 0.68457% 0.737 58% 0.714 59% 0.690 60% 0.68961% 0.700 62% 0.692 63% 0.729 64% 0.74265% 0.747 66% 0.764 67% 0.728 68% 0.76869% 0.740 70% 0.776 71% 0.817 72% 0.82373% 0.762 74% 0.883 75% 0.947 76% 0.92977% 0.875 78% 0.877 79% 1.017 80% 1.84781% 1.499 82% 1.586 83% 3.146 84% 1.09585% 3.247 86% 3.159 87% 1.498 88% 4.01889% 5.898 90% 6.159 91% 10.873 92% 26.47993% 21.500 94% 25.044 95% 26.904 96% 35.67497% 39.026 98% 55.530 99% 65.950 100% 13.629


Solution Quality (in %) Vs Avg Time Required (in sec)50% 1.244 51% 1.070 52% 1.245 53% 1.07154% 1.367 55% 1.279 56% 1.323 57% 1.29358% 1.333 59% 1.292 60% 1.396 61% 1.45062% 1.357 63% 1.337 64% 1.400 65% 1.40766% 1.321 67% 1.477 68% 1.550 69% 1.46870% 1.559 71% 1.493 72% 1.501 73% 1.40374% 1.554 75% 1.582 76% 1.701 77% 1.65178% 1.721 79% 1.876 80% 1.962 81% 1.94382% 2.073 83% 2.267 84% 2.876 85% 2.77286% 3.175 87% 3.278 88% 3.898 89% 5.24790% 6.283 91% 8.149 92% 6.416 93% 10.38094% 13.917 95% 17.263 96% 21.408 97% 33.83698% 34.341 99% 42.816

53





54


Solution Quality (in %) Vs Avg Time Required (in sec)49% 7.754 50% 8.259 51% 8.262 54% 8.75055% 9.228 56% 9.236 57% 9.239 60% 9.68961% 9.716 62% 9.719 64% 10.133 67% 10.18068% 10.660 69% 11.032 71% 11.133 73% 11.48574% 11.574 75% 12.095 77% 12.632 78% 13.19679% 13.583 80% 14.283 81% 15.308 82% 15.93283% 17.170 84% 18.929 85% 20.326 87% 25.15888% 29.679 89% 37.492 90% 50.075 91% 65.57992% 67.890 93% 99.377 94% 144.867 95% 168.53296% 263.181 97% 410.735 98% 620.835 99% 837.187

55


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.224 51% 0.212 54% 0.243 55% 0.24856% 0.268 57% 0.274 58% 0.278 59% 0.25660% 0.256 61% 0.266 62% 0.283 63% 0.26664% 0.293 65% 0.297 67% 0.300 68% 0.30369% 0.296 70% 0.316 71% 0.330 72% 0.34173% 0.348 74% 0.394 75% 0.395 76% 0.43377% 0.697 78% 0.808 79% 0.366 81% 0.40282% 0.808 83% 0.948 84% 1.358 85% 0.48286% 0.609 87% 0.598 88% 1.625 89% 1.71090% 2.873 91% 3.251 92% 8.447 93% 5.99594% 8.307 95% 13.620 96% 18.496 97% 44.08798% 59.197 99% 80.330


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.536 50% 0.521 51% 0.458 52% 0.48053% 0.482 54% 0.588 55% 0.503 56% 0.53257% 0.603 58% 0.589 59% 0.653 60% 0.59361% 0.638 62% 0.660 63% 0.545 64% 0.47465% 0.632 66% 0.549 67% 0.627 68% 0.64769% 0.660 70% 0.521 71% 0.739 72% 0.65673% 0.767 74% 0.733 75% 0.887 76% 0.82277% 0.833 78% 0.915 79% 0.886 80% 1.03681% 0.965 82% 1.172 83% 1.408 84% 1.52885% 1.864 86% 2.350 87% 3.824 88% 3.60989% 3.588 90% 4.810 91% 7.535 92% 7.49993% 10.349 94% 10.056 95% 11.259 96% 14.21097% 39.834 98% 73.226 99% 149.095

56





57


Solution Quality (in %) Vs Avg Time Required (in sec)49% 2.672 52% 3.421 54% 3.430 56% 3.80458% 3.812 61% 4.183 65% 4.205 66% 4.58667% 4.633 68% 4.690 71% 5.027 72% 5.10573% 5.249 74% 5.364 75% 5.814 76% 6.46277% 6.963 78% 8.218 79% 8.337 82% 8.70683% 12.387 84% 15.725 85% 19.253 86% 27.72287% 30.352 88% 46.670 89% 58.978 90% 62.64991% 66.261 92% 123.832 93% 128.044 94% 180.31395% 216.480 96% 311.096

58




Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.162 50% 0.188 51% 0.188 54% 0.19355% 0.194 57% 0.211 58% 0.214 59% 0.21460% 0.216 61% 0.216 62% 0.234 63% 0.23464% 0.260 65% 0.262 68% 0.238 71% 0.27172% 0.264 73% 0.305 75% 0.310 76% 0.28677% 0.299 78% 0.333 80% 0.428 81% 0.37082% 0.423 83% 0.527 84% 0.590 85% 0.76286% 1.636 87% 1.519 88% 2.137 89% 8.17690% 16.690 91% 20.194 92% 37.620 93% 54.99894% 82.182 95% 111.571 96% 242.342 97% 373.87898% 843.519

59


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.324 52% 0.369 53% 0.319 54% 0.42655% 0.422 58% 0.427 59% 0.421 60% 0.43761% 0.388 64% 0.441 65% 0.390 66% 0.42567% 0.587 68% 0.434 69% 0.509 70% 0.54871% 0.638 72% 0.526 73% 0.742 74% 0.89575% 0.980 76% 1.041 77% 0.638 78% 0.76479% 0.987 80% 1.705 81% 2.050 82% 3.79883% 4.510 84% 2.462 85% 3.698 86% 7.64987% 12.338 88% 19.894 89% 45.641 90% 102.65191% 81.491 92% 118.404 93% 182.262 94% 293.78395% 374.606 96% 664.115 97% 340.040 98% 617.853


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.672 53% 1.024 56% 1.041 57% 1.04358% 1.241 59% 1.372 60% 1.413 61% 1.45663% 1.544 65% 1.668 66% 1.694 67% 2.13868% 3.039 69% 3.668 70% 3.774 72% 4.21773% 5.112 74% 5.735 75% 7.685 77% 8.97778% 10.645 79% 15.476 80% 17.337 81% 26.17684% 28.986 85% 29.659 86% 40.819 87% 56.53489% 74.537 90% 122.517 91% 333.587 92% 730.959

60


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.319 50% 0.461 51% 0.465 55% 0.51156% 0.534 60% 0.644 61% 0.727 66% 0.89767% 0.926 68% 1.047 71% 1.209 72% 1.73073% 2.069 77% 2.703 78% 4.537 79% 6.72980% 7.946 81% 9.392 82% 10.681 83% 12.84984% 37.928 85% 66.799 86% 95.880 87% 191.64288% 329.119 89% 813.431




Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.919 50% 2.382 52% 2.660 53% 2.72654% 4.749 55% 5.332 56% 7.008 57% 13.36558% 22.629 59% 114.093 60% 387.410 62% 410.04763% 695.671 64% 893.564


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.493 50% 0.859 53% 1.874 54% 2.02055% 2.985 56% 5.364 57% 18.666 61% 45.23862% 47.052 63% 53.454 64% 84.115 65% 110.42567% 164.835 68% 206.925 69% 251.094 70% 592.23271% 916.169

61






Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.153 50% 2.849 51% 3.003 52% 3.17853% 5.712 54% 18.489 55% 26.856 57% 66.86958% 116.336 59% 137.556 60% 155.410 61% 364.04762% 473.882 63% 550.337


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.111 52% 15.744 53% 37.209 54% 78.74655% 128.855 56% 193.166 57% 381.753 58% 418.26359% 548.780 60% 558.294 61% 953.413


5 - level

62

Table A.28: Avg Time Required to achieve the corresponding quality of solutionfor multi-objective grid of size 7× 7× 7× 7× 7 using level 5 MOACTR with step12

Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.149 54% 0.150 60% 0.162 62% 0.17464% 0.175 66% 0.177 70% 0.204 71% 0.22872% 0.244 74% 0.307 77% 0.328 80% 0.35486% 0.399 87% 0.438 89% 0.786 90% 0.90591% 1.165 93% 1.296 94% 2.701 95% 5.80696% 28.232 97% 46.886 98% 59.747 99% 63.509




Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.080 63% 0.086 69% 0.086 76% 0.08777% 0.087 78% 0.088 80% 0.102 81% 0.12082% 0.136 86% 0.148 87% 0.222 88% 0.25890% 0.304 91% 0.627 93% 0.761 95% 1.05297% 1.635 98% 22.368 100% 38.544


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.020 50% 0.025 54% 0.029 68% 0.03069% 0.032 70% 0.039 71% 0.045 74% 0.07176% 0.086 83% 0.130 85% 0.192 86% 0.51188% 0.723 89% 2.354 90% 2.693 91% 7.15892% 14.906 96% 24.733 98% 62.000 100% 66.134

63


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.031 51% 0.048 52% 0.059 55% 0.08059% 0.116 60% 0.145 62% 0.176 63% 0.21264% 0.259 65% 0.388 66% 0.911 67% 1.30269% 1.537 72% 5.202 74% 6.485 79% 8.93280% 9.817 81% 11.983 82% 22.861 83% 29.77685% 38.357 86% 68.719 87% 108.124 90% 158.02991% 326.180 92% 528.608 93% 639.418







64


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.037 51% 0.041 53% 0.049 55% 0.05458% 0.063 60% 0.070 61% 0.084 62% 0.16465% 0.276 67% 0.405 69% 0.719 70% 1.47471% 2.371 72% 2.758 73% 3.663 74% 5.98077% 6.772 79% 9.494 80% 10.573 81% 19.73685% 21.848 89% 45.889 90% 73.294 91% 105.93692% 172.215 93% 251.253 94% 349.440 95% 794.292


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.027 53% 0.038 55% 0.039 57% 0.04059% 0.044 61% 0.049 62% 0.052 75% 0.05679% 0.071 80% 0.081 81% 0.094 85% 0.15787% 0.183 89% 0.401 90% 0.552 91% 0.91692% 1.522 93% 2.920 94% 7.583 95% 17.35896% 45.312 98% 55.355





65


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.045 51% 0.052 52% 0.053 53% 0.05454% 0.060 56% 0.073 57% 0.080 60% 0.08762% 0.098 64% 0.130 65% 0.156 66% 0.18768% 0.545 71% 1.103 73% 1.523 74% 3.30075% 3.832 81% 4.452 83% 11.384 84% 13.83386% 18.305 87% 21.039 88% 24.226 89% 46.02190% 71.858 91% 77.362 92% 150.403 93% 379.30794% 416.694 95% 497.965



66






6 - level

Table A.44: Avg Time Required to achieve the corresponding quality of solutionfor multi-objective grid of size 5× 5× 5× 5× 5× 5 using level 6 MOACTR withstep 50


67




Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.022 55% 0.031 75% 0.036 77% 0.04379% 0.052 80% 0.068 84% 0.090 87% 0.16589% 0.221 90% 0.886 97% 6.354 99% 106.108100% 173.813

A.5 Depth First Branch and Bound

Table A.47: Avg Time Required to achieve the corresponding quality of solutionfor multi-objective grid of dimension 4 using DFBB



Solution Quality (in %) Vs Avg Time Required (in sec)56% 0.207 58% 1.479 62% 1.522 63% 1.64964% 1.669 65% 2.976 66% 3.074 69% 3.24070% 3.280 71% 3.495 72% 3.567 73% 5.38075% 5.631 76% 5.846 77% 6.163 79% 6.23582% 7.687 83% 10.006 85% 12.265 86% 12.56988% 14.081 90% 14.495 91% 15.112 92% 15.74394% 19.975 95% 20.437 96% 27.255 97% 28.090100% 35.649

68




Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.284 50% 0.298 51% 0.320 55% 1.83159% 1.865 61% 1.895 71% 3.554 73% 3.75074% 3.800 75% 3.933 76% 4.281 77% 6.14479% 7.062 80% 10.955 82% 13.931 83% 18.25084% 21.290 85% 26.282 87% 27.828 88% 28.28089% 32.214 90% 32.366 91% 33.976 92% 35.87593% 41.388 95% 55.495 96% 56.931 99% 57.289100% 57.497



69

Table A.52: Avg Time Required to achieve the corresponding quality of solutionfor multi-objective grid of size 8× 8× 8 using Depth-first Branch and Bound



Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.485 50% 0.368 52% 0.464 53% 0.59354% 0.469 55% 0.417 56% 0.561 58% 0.56959% 0.433 61% 0.422 62% 0.737 63% 0.55365% 0.507 66% 0.453 67% 0.613 68% 0.61069% 0.481 70% 0.463 71% 0.754 72% 0.48873% 0.453 74% 0.502 75% 0.764 76% 0.59777% 0.494 78% 0.600 79% 0.576 80% 0.58981% 0.609 82% 0.695 83% 0.700 84% 0.64985% 0.426 86% 0.824 87% 0.762 88% 1.00889% 1.313 90% 2.307 91% 6.312 92% 7.18493% 10.098 94% 11.374 95% 20.548 96% 32.33797% 48.825 98% 85.778 99% 164.630

70





71




Solution Quality (in %) Vs Avg Time Required (in sec)49% 91.052 51% 98.657 53% 100.474 54% 102.09555% 103.523 57% 104.765 59% 91.796 60% 105.85961% 106.799 62% 102.559 64% 102.319 66% 108.31067% 108.883 68% 107.064 70% 107.151 71% 109.99972% 110.628 73% 111.288 74% 113.192 75% 112.53176% 112.898 77% 113.197 78% 114.093 79% 111.64080% 114.391 83% 114.443 84% 156.279 85% 165.68586% 212.435 87% 213.424 88% 215.355 89% 247.79990% 271.664 91% 300.274 92% 353.572 93% 483.37394% 813.202

Table A.58: Avg Time Required to achieve the corresponding quality of solutionfor multi-objective grid of size 5× 5× 5× 5× 5× 5 using BB


72

Table A.59: Avg Time Required to achieve the corresponding quality of solutionfor multi-objective grid of size 6× 6× 6× 6× 6× 6 using BB


Table A.60: Avg Time Required to achieve the corresponding quality of solutionfor multi-objective grid of size 7× 7× 7× 7× 7 using BB


Table A.61: Avg Time Required to achieve the corresponding quality of solutionfor multi-objective grid of size 8× 8× 8× 8× 8 using BB


73

A.6 Beam Stack

Table A.62: Avg Time Required to achieve the corresponding quality of solutionfor multi-objective grid of dimension 4 using Beam Stack






74


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.353 51% 2.075 52% 2.098 53% 2.27157% 2.325 59% 2.355 60% 2.372 62% 2.40564% 4.489 65% 4.546 68% 4.942 70% 4.98272% 5.007 73% 8.122 76% 8.947 77% 9.16979% 13.852 80% 15.981 81% 16.319 85% 25.41186% 27.545 88% 31.432 89% 35.363 90% 38.78593% 47.317 95% 50.114 96% 55.135 97% 56.12798% 62.080 99% 62.443


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.595 63% 3.172 64% 3.295 65% 3.45866% 3.749 67% 6.893 68% 7.293 69% 7.37071% 7.517 73% 12.830 74% 13.218 75% 14.03276% 15.808 78% 15.963 82% 26.192 83% 30.08784% 44.727 85% 48.688 86% 54.729 87% 57.07790% 63.156 91% 87.573 94% 102.290 95% 108.79796% 135.556 97% 148.757

Table A.67: Avg Time Required to achieve the corresponding quality of solutionfor multi-objective grid of size 8× 8× 8 using Beam Stack


75


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.038 50% 0.048 51% 0.045 52% 0.02953% 0.060 54% 0.063 55% 0.051 56% 0.07757% 0.060 58% 0.072 59% 0.136 60% 0.37161% 0.250 62% 0.333 63% 0.515 64% 0.68765% 0.700 66% 1.260 67% 2.034 68% 3.94469% 6.843 70% 6.354 71% 11.438 72% 10.76473% 11.136 74% 17.438 75% 25.807 76% 30.25377% 35.697 78% 43.886 79% 54.606 80% 54.18281% 89.248 82% 108.336 83% 128.496 84% 170.72585% 214.271 86% 245.048 87% 280.017 88% 344.36289% 459.573 90% 360.519 91% 450.318 92% 518.12293% 397.072 94% 366.420 95% 676.841 96% 524.31297% 657.198 98% 415.733 99% 560.510


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.121 50% 0.212 51% 0.108 52% 0.21353% 0.107 54% 0.097 55% 0.109 56% 0.15757% 0.158 58% 0.239 59% 0.264 60% 0.33261% 0.359 62% 0.170 63% 0.525 64% 0.79565% 1.281 66% 1.964 67% 2.720 68% 5.13569% 7.037 70% 8.123 71% 11.126 72% 10.50773% 13.235 74% 34.213 75% 36.949 76% 78.60877% 111.009 78% 159.432 79% 391.133 80% 357.94181% 234.235 82% 304.131 83% 325.249 84% 338.94885% 477.332 86% 356.761 87% 449.755 88% 162.86189% 214.113 90% 341.734 91% 506.324 92% 620.90493% 259.080 94% 495.715 95% 539.959 96% 803.47897% 894.376

76





77


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.200 50% 0.339 51% 0.238 52% 0.24453% 0.335 54% 0.349 55% 0.248 56% 0.39057% 0.578 58% 1.279 59% 0.448 60% 1.41861% 1.944 62% 3.645 63% 4.205 64% 13.57865% 19.564 66% 27.593 67% 22.112 68% 42.75769% 55.062 70% 84.390 71% 137.927 72% 183.98473% 216.807 74% 296.882 75% 338.776 76% 365.49077% 190.547 78% 295.574 79% 398.279 80% 583.77881% 415.925 82% 486.096 83% 738.185 84% 754.97685% 973.503 86% 1183.151


Solution Quality (in %) Vs Avg Time Required (in sec)49% 0.353 50% 0.420 51% 0.393 52% 0.64053% 0.477 54% 1.133 55% 0.215 56% 0.91757% 2.752 58% 3.442 59% 3.726 60% 3.42161% 4.856 62% 7.782 63% 10.304 64% 12.63065% 18.112 66% 19.523 67% 32.426 68% 65.27869% 100.640 70% 186.803 71% 153.861 72% 171.94973% 248.448 74% 90.286 75% 144.103 76% 241.93477% 262.656 78% 332.636 79% 231.736 80% 276.95781% 355.069 82% 466.007 83% 301.841 84% 792.66985% 468.062 86% 115.548 87% 275.877 88% 308.15789% 323.888 90% 519.401 91% 586.212 92% 775.831


Solution Quality (in %) Vs Avg Time Required (in sec)49% 5.668 50% 5.681 51% 5.741 52% 5.81353% 5.947 54% 7.930 55% 8.209 56% 19.09857% 101.261 58% 126.365 59% 161.348 60% 214.80761% 498.279 62% 561.342 63% 622.245

78

Table A.75: Avg Time Required to achieve the corresponding quality of solutionfor multi-objective grid of size 5× 5× 5× 5× 5× 5 using BeamStack


Table A.76: Avg Time Required to achieve the corresponding quality of solutionfor multi-objective grid of size 6× 6× 6× 6× 6× 6 using BeamStack

Solution Quality (in %) Vs Avg Time Required (in sec)49% 3.150 52% 3.150 58% 3.150 59% 3.15171% 3.151 80% 3.153 81% 3.156 83% 3.36484% 3.631 85% 4.503 86% 6.939 87% 11.50588% 24.291 89% 30.367 90% 51.466 91% 163.78193% 322.802 94% 424.429

Table A.77: Avg Time Required to achieve the corresponding quality of solutionfor multi-objective grid of size 7× 7× 7× 7× 7 using BeamStack


Table A.78: Avg Time Required to achieve the corresponding quality of solutionfor multi-objective grid of size 8× 8× 8× 8× 8 using BeamStack


79

Appendix B

Performance and SchedulerSlot feasibility

We present some experimental results of the co-design problem. First, weshow that the performance is a monotonic function of delay(δ1, δ2, δ3) inTables B.1 to B.5. (δ1, δ2, δ3) ranges from (70, 70, 70) to (90, 90, 90). Also,we show the results of exploring the slot space of the scheduler, (s1, s2, s3)from (1, 1, 1) to (4, 4, 4) to calculate feasible delays for the basis of the delayspace [(85, 85, 85), (92, 92, 92)] in Table B.6.

Table B.1: Variation of performance with delay in the delay space [(70, 70, 70),(70,85, 75)]

Delay1(in ms) Delay2(in ms) Delay3(in ms) Performance70 70 70 44.4070 70 75 44.5670 70 80 45.6770 70 85 47.0870 70 90 47.5270 75 70 44.4070 75 75 44.5770 75 80 45.6870 75 85 47.0970 75 90 47.5270 80 70 44.4070 80 75 44.5770 80 80 45.6870 80 85 47.0970 80 90 47.52

80


Delay1(in ms) Delay2(in ms) Delay3(in ms) Performance70 85 70 44.3970 85 75 44.5670 85 80 45.6770 85 85 47.0870 85 90 47.5170 90 70 44.4170 90 75 44.5770 90 80 45.6870 90 85 47.0970 90 90 47.5375 70 70 44.4075 70 75 44.5675 70 80 45.6775 70 85 47.0875 70 90 47.5275 75 70 44.4075 75 75 44.5775 75 80 45.6875 75 85 47.0975 75 90 47.5275 80 70 44.4075 80 75 44.5775 80 80 45.6875 80 85 47.0975 80 90 47.5275 85 70 44.3975 85 75 44.5675 85 80 45.6775 85 85 47.0875 85 90 47.5175 90 70 44.4175 90 75 44.5775 90 80 45.6875 90 85 47.0975 90 90 47.53

81


Delay1(in ms) Delay2(in ms) Delay3(in ms) Performance80 70 70 44.4080 70 75 44.5680 70 80 45.6780 70 85 47.0880 70 90 47.5280 75 70 44.4080 75 75 44.5780 75 80 45.6880 75 85 47.0980 75 90 47.5280 80 70 44.4080 80 75 44.5780 80 80 45.6880 80 85 47.0980 80 90 47.5280 85 70 44.3980 85 75 44.5680 85 80 45.6780 85 85 47.0880 85 90 47.5180 90 70 44.4180 90 75 44.5780 90 80 45.6880 90 85 47.0980 90 90 47.53

82


Delay1(in ms) Delay2(in ms) Delay3(in ms) Performance85 70 70 44.4085 70 75 44.5685 70 80 45.6785 70 85 47.0885 70 90 47.5285 75 70 44.4085 75 75 44.5785 75 80 45.6885 75 85 47.0985 75 90 47.5285 80 70 44.4085 80 75 44.5785 80 80 45.6885 80 85 47.0985 80 90 47.5285 85 70 44.3985 85 75 44.5685 85 80 45.6785 85 85 47.0885 85 90 47.5185 90 70 44.4185 90 75 44.5785 90 80 45.6885 90 85 47.0985 90 90 47.53

83


Delay1(in ms) Delay2(in ms) Delay3(in ms) Performance90 70 70 44.4090 70 75 44.5690 70 80 45.6790 70 85 47.0890 70 90 47.5290 75 70 44.4090 75 75 44.5790 75 80 45.6890 75 85 47.0990 75 90 47.5290 80 70 44.4090 80 75 44.5790 80 80 45.6890 80 85 47.0990 80 90 47.5290 85 70 44.3990 85 75 44.5690 85 80 45.6790 85 85 47.0890 85 90 47.5190 90 70 44.4190 90 75 44.5790 90 80 45.6890 90 85 47.09

84

Table B.6: Feasibility of slots for the basis in the delay space [(85, 85, 85)ms,(92,92, 92)ms] with PREF = 45Slot1(in ms) Slot2(in ms) Slot3(in ms) Delay1 Delay2 Delay3 Feasibility1 1 1 ∞ ∞ ∞ No1 4 4 ∞ ∞ ∞ No2 1 1 54 54 71 Yes2 1 2 85 73 70 Yes2 1 3 ∞ ∞ ∞ No2 1 4 ∞ ∞ ∞ No2 2 1 85 41 77 Yes2 2 2 ∞ ∞ ∞ No2 4 4 ∞ ∞ ∞ No3 1 1 43 83 74 Yes3 1 2 59 100 65 No3 1 3 ∞ ∞ ∞ No3 1 4 ∞ ∞ ∞ No3 2 1 59 47 92 No3 2 2 84 59 75 Yes3 2 3 ∞ ∞ ∞ No3 2 4 ∞ ∞ ∞ No3 3 1 84 40 106 No3 3 2 ∞ ∞ ∞ No3 4 4 ∞ ∞ ∞ No4 1 1 39 100 80 No4 1 2 ∞ ∞ ∞ No4 1 4 ∞ ∞ ∞ No4 2 1 50 57 106 No4 2 2 59 64 79 Yes4 2 3 68 77 85 Yes4 2 4 96 99 76 No4 3 1 59 47 120 No4 3 2 68 59 81 Yes4 3 3 96 62 85 No4 3 4 ∞ ∞ ∞ No4 4 1 68 49 149 No4 4 2 96 50 91 No4 4 3 ∞ ∞ ∞ No4 4 4 ∞ ∞ ∞ No

85

m. tech. project thesis on anytime multi-objective

Documents