Minimizing the Worst Case Execution Time ofDiagnostic Fault Queries in Real Time Systems Using

Genetic Algorithm

Nadra Tabassam 1, Sarah Amin 2 and Roman Obermaisser 3

University of Siegen, Germanynadra.tabassam@uni-siegen.de

Abstract. The number of embedded systems in safety-critical applications arecontinuously increasing. These systems requires high level of reliability and havestrict timing constraints specially in case of fault occurrence. One method to en-hance the reliability and availability of these systems is to introduce the conceptof optimization of diagnostic fault queries and real time database managementsystems. Both of them can be used to trace back failures to faults and trigger suit-able recovery actions. Our major concern is the completion of diagnostic queryin bounded time in order to satisfy timing constraints for fault recovery (e.g. ac-tuator freezing). For this purpose it is important to provide a solution which canoptimize the diagnostic fault queries in a manner that they can complete theirexecution within the pre-defined deadline of the real time system. Our proposedalgorithm optimize the diagnostic fault queries using genetic algorithm, so thatthe overall Worst Case Execution Time (WCET) of these queries can be mini-mized. A diagnostic query is represented in the form of (i) Left Deep Tree (LDT)and (ii) Bushy Tree (BT). Each query tree is converted into multiple task graphsby considering different combinations of nodes (in query tree). Our genetic al-gorithm selects the task graph with minimum make span (scheduling length), sothat the goal of fault diagnosis within the defined deadline of the real time systemcan be achieved. The evaluation based on our results shows that the WCET of thediagnostic queries is better in case of bushy trees and ring topology.

Keywords: Active diagnosis · Real time systems · RTDBMS · Diagnostic queries· Pervasive SQL · WCET. · Genetic Algorithm

1 INTRODUCTION

Safety critical systems are different from traditional IT systems. In safety-critical sys-tems, it is important that a fault is determined and the problem is solved within pre-dictable time before the system reaches an unsafe state. Therefor any failure mightresult in loss of life, damage of environment or damage of property so it is essentialthat these systems should equipped with a fault-tolerance mechanism. For example incase of autonomous vehicles the performance of all system components should be mon-itored actively along with fault detection mechanism, in order to guarantee the safety ofpassenger [3].

Another example is a Flight Tolerant Control System (FTCS). An active FTCS sys-tem reacts to the malfunctioning of system components by re-configuring the controller

based on the information received from a Fault Detection and Diagnosis (FDD) unit.The major objectives of an active FTCS is to develop an effective FDD scheme to pro-vide information about the fault with minimal uncertainties in a timely manner [4].Therefore the fault detection based on-line diagnosis improves the overall reliability ofthese safety critical systems. The active diagnosis in these systems is imperative be-cause these applications have timing constraints for fault recovery (e.g., actuator freez-ing, limited time until correct service is required again or to prepare for the next faultwhen combining diagnosis with conventional replication) [12].

There are two solutions in state of art in order to ensure the reliability of these sys-tems. First solution is based on adding the redundant components in the final product.But it is not feasible as this increases the overall cost of the final product [7]. Anothersolution is the continuous monitoring of the system for temporary or permanent compo-nent failures. There are two types of diagnostic techniques in the literature, i). passivediagnosis that stores the diagnostic information and analyzes it later for fault detectionand recovery and ii). active diagnosis that analyzes the diagnostic information at runtime so that an immediate recovery action can be taken [16].

Another fundamental concern of these systems is the effective data processing withintime bound of the system. Due to the huge amount of data processing among the dif-ferent components of the system, it is important to process and store data by consid-ering the timing constraints of the system. In order to meet these timing requirementsspecifically for data processing in real time systems, numerous real time database man-agement systems like Genesis, Polyhedra, Berkeley DB and TimesTen have designed[6]. These real time database management systems have properties like temporal con-sistency, timeliness, meeting deadlines etc.

Therefore the execution of diagnostic fault queries over the database is an effectivetechnique for root cause analysis i.e. to find the fault responsible for a failure and de-termine an appropriate recovery action. But the processing of fault queries should becompleted within the timing constraints of the real time system.

Contributions: Our proposed algorithm optimize the diagnostic fault queries sothat their WCET can be minimized and they can complete their execution within thepre-defined deadline of the system. Our major contributions are as follows:

WCET of the diagnostic query is minimized so that it can complete its executionwithin the defined deadline of the system. This is the major concern of our work. Pro-posed GA goes through the search space and selects the task graph with minimummake span. Fitness function for GA is based on the calculation of make span of eachtask graph. For calculating the fitness score of each TG we are invoking scheduler. Ourscheduler will map the TGs on end systems considering different topologies.

The rest of the paper is structured as follows. Section 2 describes the related workand gap existing in the state of art. Section 3 describes the steps in proposed algorithm.Section 4 describes the calculation of WCET. Section 5 describes the importance ofscheduler in our work. Section 6 describes the illustrative example and Section 7 de-scribes the experimental results.

2 Related Work

In case of query optimization, database management system sometimes chooses theworst query execution plan for some queries. This is the case where query optimizerdoes not considers the amount of time and resources that needs to be efficiently se-lected [8]. An improved particle swarm optimization technique is used to perform theembedded database query optimization [11]. An experimental embedded system plat-form using embedded database SQLite3.3.4 has been designed to test the effectivenessof proposed algorithm. Most of the genetic algorithm in case of query optimization onlydeals with the join ordering problem [14][9]. Selection of best index for query execu-tion has also been implemented by using genetic algorithm [5]. In order to select thebest join order for the creation of optimal optimization strategy, the author in [14] hasemployed the genetic query optimizer (GQO). Author completes the experimentationby associating GQO with DB2, PostgreSQL and MySQL.

In [10] author has presented a framework to optimize the query execution plan whileusing a flexible communication model. A polynomial time algorithm for finding the op-timal plan is proposed. This algorithm minimizes the total communication cost when thecommunication graph is restricted to be a tree. In [15] authors consider the problem ofimproving the performance of parallel query tasks based on a tool known as QSchedulerwhich is designed and implemented for controlling the process of the query executionsequence. Proposed QScheduler treats the database system as a black box and decideswhich query to schedule preferentially according to the different algorithm.

For the query optimization of distributed database, the speed of query depends onthe amount of data transfer and order of join. The cost model which can minimize thecommunication cost is the basic concern of this research. Parallel Genetic Algorithm-Max-Min Ant System is proposed to seek a best query execution plan. This algorithm in[2] combines faster convergence of Genetic Algorithm with the globally search abilityof Max-Min Ant System and parallel properties of both.

Although the above describe work is presenting the algorithms for query optimiza-tion but in our case our underlying problem is slightly different from them. None ofthe aforementioned techniques considered the query optimization in stringent timingconstraints that are essential for analysis in real-time distributed systems. The fault di-agnosis queries are represented in SQL format. These SQL queries are then convertedto task graphs. The initial population of TG are then mapped to end systems for process-ing by our scheduler. Scheduler is invoke in for calculating the fitness function (makespan) of these TGs. Therefore this technique has not implemented in state of art and isnovel way of optimizing the diagnostic queries so that they can complete their executionwithin the pre defined deadline of the system.

3 Steps in Proposed Algorithm

Fig.1 shows the steps involved in our proposed algorithm. Next subsections will de-scribe the details about these steps.

Fig. 1. Steps in Proposed Algorithm

Algorithm 1 Task Graph Optimization Algorithm (TGO)Input:Diagnostic Query (DQ)Output:Optimized Task Graph (TG), Makespan of TG

1: Convert DQ into Relational Algebra (RA) representation.2: Convert RA of DQ into Query Tree (QT) representation.3: QT can be left depth tree or bushy tree4: Generate different Task Graphs (TG) with different combinations of nodes from QT.5: Add all these TG into Search Space (SP) of Genetic Algorithm (GA)6: Create initial population based on these TG for GA.7: while the TG with minimum Make Span (MS) is not found do8: for all TG in initial population do9: Calculate fitness function (MS)

10: end for11: Select TG with minimum MS12: Apply mutation on selected solutions (TG)13: Send them to next generation.14: Exit when TG with minimum MS is found15: end while

3.1 Diagnostic Query

Diagnostic fault queries are based on the features and symptoms extracted directly fromthe sensors data. Our diagnostic queries are represented in SQL format. In order tomake our scenario simple we are only considering one type of diagnostic query. Butconsidered query is quite complex and have multiple join operations.

3.2 Query Tree

Second step in algorithm is to convert SQL query into query tree. Query tree representsthe query in the form of a relational algebra expression. The nodes of the query treerepresents the relational algebra operations as well as the tables that are involved in thequery. In order to make effective comparison for our results, we have considered twotypes of trees. These are (i) Left Deep Tree (LDT) (ii) Bushy Tree (BT). (c.f. 2-3)

3.3 Task Graph (TG)

For each query tree different TGs are generated (c.f. 4). Each node of a query trees isconsidered as the one task in TG. The WCET (N) represents the WCET of task node. And W (E) represents the weight of the edge. W (E) represents the amount of datathat is being transferred from parent node to the child node. We assume that each edgehas unit weight that is W (E) = 1. Whenever the data item of size S is sent across thenode, overall cost of the edge becomes S.W (E). Each task graph is considered as asolution for the search space in GA. Each TG contains different number of nodes fromone query tree. However it means that each TG has different number of nodes. TheseTGs are created depending on the type of query tree. They can be LDT based TG orBT based TG. The most simpler TG is the one in which each operation of query tree(within a query node) is consider as a one task.

3.4 Genetic Algorithm (GA)

Last step is to apply the GA in order to find the TG which has the minimum make span.Next section will describe all the necessary steps in this context.

Initial Population Each TG (individual solution) that is created by considering thedifferent combinations of query tree operations is considered as the part of our solutionspace (c.f.5-6). We have used the binary string for encoding the chromosome. EachSQL operation within the query tree is assigned 1 when it is considered as a separateoperation in the task graph. And each SQL operation in query tree is assigned 0 if itis considered in combination with the other SQL operation. For example if the parentSQL operation is combined with the child SQL operation (two joins combine togetherin the form of one SQL query). Then the parent SQL operation is assigned 1 and childSQL operation is assigned 0.

Fitness Function Calculation of fitness function is the most important part of our work(c.f.7-10). The fitness score for each solution is calculated by invoking the scheduler.The WCET of each node along with the weights of edges (for each task graph) is givenas an input to the scheduler for calculating the make span. The scheduler maps theseTGs for processing to the end systems. Scheduler is considering different topologiesincluding Star-Bus, Star-Ring and Star-Star. The calculated make span of a each taskgraph is considered as our fitness score. The scheduler is invoke whenever the fitnessfunction of the solution (task graph) in search space has to calculate. More informationabout the type of scheduler is out of context of this paper. For more details please referto [1].

Selection Our selection phase selects the fittest individual and passes them to the nextgeneration (c.f.11-12). For each solution (TG) make span is calculated and then all makespans are compared to each other. The TG with minimum make span are considered asthe best one to select.

Mutation In our case we will not perform the cross over of two solutions becauseour new individual becomes wrong. We will only perform mutation (c.f.13). In case ofmutation it is important to maintain the order of a task graph. So that when the new TGis generated the considered diagnostic query should not changed. All type of mutationis not allowed because it is possible that the new TG will have different query.

Termination Our algorithm terminates when our GA keeps on finding the similar makespans or in other words the make span does not decrease more after a certain value.

4 Calculation of Worst Case Execution Time

The WCET is the estimation of the maximum time that a diagnostic query can take tocomplete its execution [13]. In our case we are concerned about the WCET of wholequery which actually means that we have to calculate the WCET of each node withina task graph. Therefore these nodes actually contains the SQL operations with in thediagnostic query. And all of these operations are executed on the cars database, whichis created in PSQL. For finding the WCET for each node of a task graph, the SQL op-eration in this graph node is split from the main query and converted into sub queries.The number of sub queries depends upon the number of operations present in the origi-nal query. These sub queries are measured against all the combinations of data. Almost3,000 test queries are run to find the estimated WCET.

5 illustrative Example

This sections describes the illustrative implementation of our proposed algorithm withthe help of working example.

D:LDT with Two Task Nodes for TGC:LDT with Three Task Nodes for TG

A:LDT with Five Task Nodes for TG B:LDT with Four Task Nodes for TG

E:LDT with one Task Nodes for TG

Fig. 2. Different Left Deep Trees

Left Deep Tree Bushy Tree

Fig. 3. Query Tree for A: Left Deep Tree, B:Bushy Tree

5.1 Diagnostic Query

As described earlier the diagnostic query is represented in SQL format. The examplediagnostic query is executed on the database, that we have designed in PSQL. Thisdatabase comprises of data that is extracted from the cars sensors. The example diag-nostic query we are considering is denoted by QD. The query QD is a join query whichis joining five different tables. Defined query is complex because data manipulation isperformed on different set of data from different database tables.

QD: select Oxygen.OxygenRatio, Water.WaterTemp,Oil.Oillimit, Engine.EngineIDfrom Oxygen, Oil, Water,Engine,Fuel where Fuel.WaterID=Water.WaterID andWater.WaterID =Engine.EngineID and Oil.OilID=Engine.OilID and Oxygen.OxygenID=Oil.OxygenID

5.2 Query Tree

As described in Section 3 that we have considered two types of query trees. These are(i) Left Deep Tree (LDT) and (ii) Bushy Tree (BT). Fig.3 shows the informal represen-tation of query QD in the form of LDT and BT. While Fig.2 shows the different LDT.Fig.2A generates the LDT based TG which will have five nodes. Fig.2B generates theLDT based TG which will have four nodes. Fig.2C generates the LDT based TG whichwill have three nodes. Fig.2D generates the LDT based TG which will have two nodes.Fig.2E generates the LDT based TG which will have only one node.

5.3 Task Graph

We start creating the most simpler TG which consider all the operations (join, pro-jection) of a query tree as a one separate task (Fig.4B). For generating other TG we

A: Left Tree 1 B: Task Graph 1

C: Left Tree 2 D: Task Graph 2

Fig. 4. A:Left Deep Tree 1, B:Task Graph 1, C:Left Deep Tree 2, D: Task Graph 2

consider more than one operation of a query tree as a one task (Fig.4D). As mentionedin Section 3 that TGs are generated depending on the type of query tree. They can beLDT based TG or BT based TG. Section 5.4 and 5.5 describes LDT based TG or BTbased TG and BT based TG.

5.4 Left Deep Tree Based TG

For example if we consider the Fig.4A which is actually the LDT for query QD. It showsthat we have five operations in this LDT including four joins and one projection.

Task Graph 1 If we define the first and most simpler TG for this query tree accordingto our assumptions, then this TG contains the five nodes.

C:Bushy Tree 2

A:Bushy Tree 1 B:Task Graph 1

D:Task Graph 2

Fig. 5. A:Bushy Tree 1, B:Task Graph 1, C:Bushy Tree 2, D: Task Graph 2

So if we consider the relational algebra equation for query QD then it looks likeEquation 1.

{Π(oxygen.OxygenRatio,Water.WaterTemp

Oil.Oillimit,Engine.EngineID)

((((F ./W ) ./ E) ./ O) ./ X))}(1)

Now considering Equation 1 for creating TG, the first TG can be generated byconsidering each operation of the query tree as a one task. T1 = (F ./ W ) T2 =./E, T3 =./ O, T4 =./ X , T5 = Π(oxygen.OxygenRatio,Water.WaterTemp,Oil.Oillimit,Engine.EngineID).Fig.4B shows the structure of this TG. This task graph comprise of five processingnodes.

A:Left Deep Tree before Mutation B:Left Deep Tree after Mutation

C:Task Graph for Query Tree A D:Task Graph for Query Tree B

Fig. 6. Left Query Tree before and after Mutation

Task Graph 2 Now we will generate another TG from the query tree shown in Fig.4C.We consider the same Equation 1 for creating this TG but this time we have combinedthe operations (F ./W ) and ./ E into one task T1. So the task nodes defined in Fig.4Dbecomes T1 = (F ./W ) ./ E, T2 =./ O, T3 =./ X , T4 =Π(oxygen.OxygenRatio,Water.WaterTemp,Oil.Oillimit,Engine.EngineID).

If we compare LDT in Fig.4A with LDT in Fig.4C. We can see that LDT in Fig.4Ccontains the two join operations in task node T1. While LDT in Fig.4A only contains theone join operation in task node T1. Therefore the TG in Fig.4B has five nodes and TGin Fig.4D has four nodes. And number of these task graphs keeps on increasing whenwe have more join operations and more relations in diagnostic query. Similarly manyother task graphs can be generated in this manner.

A:Bushy Tree B:Task Graph

Fig. 7. A: Busy Tree B: TG for A

5.5 Bushy Tree Based TG

Task Graph 1 Now if we consider the Fig.5A. which is BT then the Equation 2 showsthe relational algebra representation of this query QD.

{Π(oxygen.OxygenRatio,Water.WaterTemp

Oil.Oillimit,Engine.EngineID)

[((F ./W ) ./ E) ./ (O ./ X)]}(2)

On the basis of Equation 2, we will generate some TGs. The BT for query QD isshown in Fig.5A. Suppose we generate the first TG in which we consider each operationas a one task. Now we consider T1 = (F ./W ), T2 =./ E, T3 =./ (O ./ X), T4 = (((F ./W ) ./ E) ./ (O ./ X)), T5 = Π(oxygen.OxygenRatio,Water.WaterTempOil.Oillimit,Engine.EngineID).This TG is shown in Fig.4B.

Task Graph 2 Now we will create another TG from the query tree shown in Fig.5C,using the Equation (2). This TG as shown in Fig.5D, comprise of less number of tasks ascompare to the TG shown in Fig.5B. These tasks are T1 = ((F ./W ) ./ E), T2 =./ (O ./X), T3 =(((F ./W ) ./E) ./ (O ./X)), T4 =Π(oxygen.OxygenRatio,Water.WaterTempOil.Oillimit,Engine.EngineID).

Task Graph 3 Similarly another TG can also be created using the same technique.This task graph contains tasks including T1 = (F ./W ) ./ E) ./ (O ./ X),T2 = Π(oxygen.OxygenRatio,Water.WaterTempOil.Oillimit,Engine.EngineID). So this task graph only

contains two tasks as shown in Fig.7B. While the Bushy tree for this TG is shown inFig.7A.

So different types of task graphs are generated during the implementation of GA.All these task graphs are added in solution space of GA in different generations. Thesolution space can be bigger depending upon the number of joins and complexity of adiagnostic query.

5.6 Genetic Algorithm

This section will describe the implementation details of our GA using illustrative ex-ample. For our proposed genetic algorithm the size of initial population=100, No ofgenerations=100, mutation probability=0.1 and convergence probability=0.2.

Initial Population Each TG (individual solution) is created by considering the differentcombinations of query tree operations. As described in Section 5, two types of taskgraphs are generated depending on the type of query tree. These TG are LDT based TGand BT based TG. The chromosome representation of these TG are shown in Fig.2. Thechromosome representation of TG based on LDT are shown in Fig.4A and Fig.4C. Thechromosome representation of TG based on the BT are shown in Fig.5A, Fig.5C andFig.7B.

Fitness Function The fitness score for each TG in the selected solution space is cal-culated by invoking the scheduler. The WCET of each task node within the TG alongwith the weight of edges is given as an input to the scheduler for calculation of fitnessscore (make-span) for TG in solution space. Suppose the initial population in our GAcomprised of hundred solutions (task graphs). For each TG its make span is calculated.For elaboration of example we take three graphs (Fig.4B, Fig.4D, Fig.5B). The inputgiven to the scheduler for calculating the fitness score (make span) of each TG is shownin Table 1.

Selection Our selection step selects the fittest individual and passes them to the nextgeneration. For each solution fitness score (make span) is calculated and then all makespans are compared to each other. The solutions with minimum fitness score (makespan) are considered as the best one to select. According to Table 1 the Fig.5B has thesmallest make span calculated. And it is considered as the fittest solution as it has themost smallest make span. So this solution (TG) is passed to the next generation.

Mutation In case of our proposed solution, the order of mutation is really important.After the mutation the query should remain the same and TG should remain in the sameorder. Fig.6A shows the LDT before mutation and Fig.6B shows the LDT after themutation. Therefore Fig.6C shows the TG for LDT in Fig.6A and Fig.6D shows the TGfor LDT in Fig.6B. It is clear that both TG shown in Fig.6C and Fig6D are similar instructure but it is also shown that the T1 in Fig.6C is different from the T1 in Fig.6D.It means that the overall WCET of T1 in Fig.6C is different from the WCET of T1 inFig.6D, which changes the make span of both the task graphs.

Table 1. Make span of task graphs in Secs.

Task graph WCET (ms) Weight of Edge W(e)MBFig.4B T1 = 1.08 T1 → T2 = 58.80

T2 = 3.12 T2 → T3 = 33.78T3 = 4.56 T3 → T4 = 67.24T4 = 5.08 T4 → T5 = 45.98T5 = 4.23

Make Span 7.29msFig.4D T1 = 4.35 T1 → T2 = 74.90

T2 = 4.56 T2 → T3 = 67.24T3 = 5.08 T3 → T4 = 45.98T4 = 4.23

Make Span 6.09msFig.5B T1 = 1.08 T1 → T2 = 58.80

T2 = 4.87 T2 → T4 = 56.03T3 = 5.48 T3 → T4 = 66.19T4 = 4.23 T4 → T5 = 78.90T5 = 4.74

Make Span 4.18ms

5.7 Calculation of Worst Case Execution Time using Example Query

This section shows the calculation of WCET of TG shown in Fig.4B. For example thequery QD has four sub-queries and we name them QD1, QD2, QD3, QD4. QD1 representsthe task node T1. QD2 represents the task node T2. QD3 represents the task node T3. QD4represents the task node T4. We are considering only join queries.

QD1: select Oxygen.OxygenRatio, Water.WaterTemp,Oil.Oillimit, Engine.EngineIDfrom Oxygen, Oil, Water,Engine,Fuel where Fuel.WaterID=Water.WaterID and Wa-ter.WaterID =Engine.EngineID and Oil.OilID=Engine.OilID andOxygen.OxygenID=Oil.OxygenID

QD2: select Oxygen.OxygenRatio, Water.WaterTemp,Oil.Oillimit, Engine.EngineIDfrom Oxygen, Oil, Water,Engine, Fuel where Fuel.WaterID=Water.WaterID and Wa-ter.WaterID =Engine.EngineID and Oil.OilID=Engine.OilID

QD3: Select Oxygen.OxygenRatio, Water.WaterTemp,Oil.Oillimit, Engine.EngineIDfrom Oxygen, Oil, Water,Engine,Fuel where Fuel.WaterID=Water.WaterID and Wa-ter.WaterID =Engine.EngineID

QD4: Select Oxygen.OxygenRatio, Water.WaterTemp, Oil.Oillimit, Engine.EngineIDfrom Oxygen, Oil, Water,Engine,Fuel where Fuel.WaterID=Water.WaterID

According to Fig.4B and Equation 1 QD1 = T5, QD2 = T4 , QD3 = T3, QD4 = T2. Foreach of these queries (task nodes) the estimated WCET is calculated by running thesequeries with different amount of data. The WCET calculated for the TG in Fig.4B isshown in Table 1.

A:Left Deep Tree B:Bushy Tree

C:Bushy Tree 4 End Systems D:Bushy Tree 6 End Systems

Fig. 8. A:LDT based TG, B:BT based TG, C:BT based TG 4 End Systems, D: BT based TG 6End Systems

A:Left Deep Tree 4 End Systems B:Left Deep Tree 6 End Systems

Fig. 9. A:LDT Based TG 4 end systems, B:LDT Based TG 6 End systems

6 Experimental Results

In our experimental results we have taken into account the three types of network topol-ogy including (i) Star-bus (ii) Star-Ring and (iii) Star-Star. All the task graphs presentin the solution space are given as an input to the scheduler for calculating the fitnessscore (make span). Our genetic algorithm selects the task graph with minimum makespan in all the generations. The scheduler is invoked when the fitness score (make span)of the TG is calculated. Our scheduler is running over the 8 networked (based on threenetwork topology) distributed system.

Result 1 Fig.8A and Fig 8B shows the results of make span calculation in case wherewe have considered two end systems in our topology. If we compare both results,it isclear that the task graphs generated on the basis of bushy trees has better make span ascompare to the left deep trees. In case of left deep trees we have a sequential task graphsdue to which scheduler can process only one task at one time because each child taskhas to start its execution after its parent task ended up its execution, so scheduler cannotschedule multiple tasks. On the other hand in case of bushy tree we have more tasks atone level of task graph which are ready so at one time multiple tasks can be assigned toprocessing nodes due to which overall make span is reduced.

Result 2 If we compare results presented in Fig.8C and Fig.8D it is clear that BT givesthe better results when we have considered our scheduler with six end systems. Themake span of task graphs with more than 30 nodes shows remarkable decrease in case

A:Left Deep Tree Convergence B:Bushy Tree Convergence

Fig. 10. A:LDT Convergence, B:BT Convergence

when we have more end processing systems. The task graphs withe lesser number ofnodes does not show any decrease in make span when more end processing systems areadded.

Result 3 If we compare the results in Fig.9A and Fig.9B it is clearly shown that evenin case of left deep trees the make span is also decreased when the more processingend systems are added in the topology. So the task graphs based on deep left trees havebetter make spans in case of scheduler based on 6 end systems.

Result 4 If we compare the Fig8C and Fig.9A ,it is clearly seen that our BT based taskgraphs have better results in case of 4 end systems as compare to the LDT based TG.

Result 5 Similarly if we compare the Fig8D and Fig.9B, it is also clear that BT basedTG has lesser make span as compare to the LDT based task graphs in case of schedulerbased on 6 end systems.

Result 6 If we compare the Fig10A and Fig.10B, it is clearly seen that our BT con-verges earlier as compare to the LDT. In case of LDT, genetic algorithm converges after80th generations while in case of bushy tree it converges after 100th generation butgives us better and minimized make spans.

Result 7 If we consider the results based on different topologies then it is seen that ringtopology is giving us better make span as compare to the star and bus topology. As incase of ring topology we have more connections among the processing nodes so overallnetwork load is minimized. Minimized network load increases the chances of scheduleability.

Conclusion

This paper presents the genetic algorithm based technique for minimizing the WCETof diagnostic queries, so that the objective of timing constraint and meeting deadlinesin real time systems can be achieved. Different task graphs on the basis of diagnosticquery trees are generated. These task graphs are considered as a solution for our searchspace in case of genetic algorithm. The task graph with minimum make span is selectedby our proposed GA, so that the deadline constraint of the system can be fulfilled.Different task graphs are tested with different topology. The results shows in context ofbushy trees over the ring topology are better as compare to left deep trees. The overallmake span of the diagnostic query is reduced in case of bushy trees much more ascompare to the left deep trees after the optimization is applied. In our future work wewill considered solving the problem of memory hot spots that can cause memory bottlenecks, in case of bigger tasks graphs and more complex diagnostic queries.

ACKNOWLEDGMENT

This work has been supported in part by the European project FP7 DREAMS underproject No. 610640 and by the German Research Foundation (DFG) under projectADISTES (OB384/6-1, 629300).

References

1. Amin, S., Obermaisser, R.: Time-triggered scheduling of query executions for active diag-nosis in distributed real-time systems. In: Emerging Technologies and Factory Automation(ETFA), 2017 22nd IEEE International Conference on. pp. 1–9. IEEE (2017)

2. Ban, W., Lin, J., Tong, J., Li, S.: Query optimization of distributed database based on par-allel genetic algorithm and max-min ant system. In: Computational Intelligence and Design(ISCID), 2015 8th International Symposium on. vol. 2, pp. 581–585. IEEE (2015)

3. Bateman, F., Noura, H., Ouladsine, M.: Fault tolerant control strategy based on the doa:Application to uav. In: 7th IFAC Symposium on Fault Detection Supervision and Safety ofTechnical Processes (2009)

4. Ducard, G.J.: Fault-tolerant flight control and guidance systems: Practical methods for smallunmanned aerial vehicles. Springer Science & Business Media (2009)

5. Fang, L., Wang, P., Yan, J.: A multi-copy join optimization of information integration sys-tems based on a genetic algorithm. In: Computing in the Global Information Technology,2008. ICCGI’08. The Third International Multi-Conference on. pp. 223–228. IEEE (2008)

6. Idoudi, N., Duvallet, C., Sadeg, B., Bouaziz, R., Gargouri, F.: Structural model of real-timedatabases: An illustration. In: Object Oriented Real-Time Distributed Computing (ISORC),2008 11th IEEE International Symposium on. pp. 58–65. IEEE (2008)

7. Kandasamy, N., Hayes, J.P., Murray, B.T.: Time-constrained failure diagnosis in distributedembedded systems: application to actuator diagnosis. IEEE Transactions on parallel and dis-tributed systems 16(3), 258–270 (2005)

8. Kiefer, M., Heimel, M., Breß, S., Markl, V.: Estimating join selectivities using bandwidth-optimized kernel density models. Proceedings of the VLDB Endowment 10(13), 2085–2096(2017)

9. Kratica, J., Ljubic, I., Tosic, D.: A genetic algorithm for the index selection problem. In:Workshops on Applications of Evolutionary Computation. pp. 280–290. Springer (2003)

10. Li, J., Deshpande, A., Khuller, S.: Minimizing communication cost in distributed multi-queryprocessing. In: Data Engineering, 2009. ICDE’09. IEEE 25th International Conference on.pp. 772–783. IEEE (2009)

11. Mingyao, X., Xiongfei, L.: Embedded database query optimization algorithm based onparticle swarm optimization. In: Measuring Technology and Mechatronics Automation(ICMTMA), 2015 Seventh International Conference on. pp. 429–432. IEEE (2015)

12. Muenchhof, M., Beck, M., Isermann, R.: Fault-tolerant actuators and drivesstructures, faultdetection principles and applications. Annual Reviews in Control 33(2), 136–148 (2009)

13. Munnich, A., Farber, G.: Calculating worst-case execution times of transactions in databasesfor event-driven, hard real-time embedded systems. In: Database Engineering and Applica-tions Symposium, 2000 International. pp. 149–157. IEEE (2000)

14. Vellev, S.: An adaptive genetic algorithm with dynamic population size for optimizing joinqueries (2008)

15. Zhang, Q., Li, S., Xu, J.: Qscheduler: A tool for parallel query processing in database sys-tems. In: Engineering of Complex Computer Systems (ICECCS), 2014 19th InternationalConference on. pp. 73–76. IEEE (2014)

16. Zhang, Y., Jiang, J.: Bibliographical review on reconfigurable fault-tolerant control systems.IFAC Proceedings Volumes 36(5), 257–268 (2003)