Vuelo en equilibrio de un kite

In this stage of the DECIDE self-adaptation workflow, the system components decide their contributions to the realisation of the system-level QoS requirements. To this end, they use their capability summariesCS1,CS2, . . . ,CSn to solve the optimisation

problem:

minimise Pn

i=1ai,m+1

subject to expr_j(a1j, a2j, . . . , anj) ./j boundj, 1≤ j ≤ m

and (ai1, ai2, . . . , ai,m+1)∈ CSi, 1≤ i ≤ n

(5.9)

Assuming the problem has a solution, the CLA for thei-th component is given by clai= (ai1, ai2, . . . , ai,m+1) (5.10)

from this solution, and we say that thei-th system component satisfies its CLA iff the QoS attributes of the component satisfy for all1_{≤j ≤m}

attrij ./j aij, if ./j∈ {<, ≤, ≥, >}

attrij = aij, otherwise (i.e., if ./j∈ {=, 6=})

, (5.11)

Remember that the local capability analysis stage of DECIDE ensures that compo- nent configurations that satisfy (5.11) exist with probability at leastα.

Theorem 2. Let cla₁, cla₂, . . . , cla_n be the CLAs (5.10) of a DECIDE system with QoS requirements (5.2). If component i satisfies clai for all 1≤ i ≤ n, then the system

QoS requirements are satisfied.

Proof. Suppose that then components of a DECIDE system satisfy the CLAs (5.10), and consider thej-th system-level QoS requirement (5.2), 1_{≤j ≤m. Then attr}ij./jaij

for all componentsi, 1≤i≤n. We will prove that the j-th system-level QoS requirement is satisfied by examining each entry in Table 5.3 individually.

For the first entry,./j∈ {<, ≤, ≥, >}, so exprj satisfies

expr_j(attr1j, . . . , attrnj) =Pn_i=1wiattrij ./j Pn_i=1wiaij =

= expr_j(a1j, . . . , anj) ./j boundj,

and the j-th QoS requirement is satisfied.

For the second entry, attr_{ij ∈ [0, 1], so the same reasoning can be applied to show that} the requirement is satisfied:

expr_j(attr1j, . . . , attrnj) =Qni=1wiattrij ./j Qni=1wiaij =

= expr_j(a1j, . . . , anj) ./j boundj.

Finally, for the third entry in Table 1,./j∈ {=, 6=}, so attrij= aij for all 1≤i≤n, thus

expr_j(attr1j, . . . , attrnj) = exprj(a1j, . . . , anj) ./j boundj,

which completes the proof.

DECIDE does not prescribe how the optimisation problem (5.9) should be solved, as this is application specific. Depending on the nature of the DECIDE system and its requirements, the best way to obtain the component CLAs (5.10) may be by using an efficient dynamic programming or greedy algorithm, a metaheuristic or, when the solution spaceCS1× CS2× . . . × CSn is sufficiently small, using brute-force. The CLA

calculation is performed independently by each system component (using the same deterministic method). Although DECIDE is sufficiently generic to allow the execution of this calculation by a “leader” component that would then communicate it to all other components, the independent calculation is preferred because it avoids a single point of failure and additional communication between components. This is done, of course, at the expense of duplicating the CLA selection on all components.

Example 5.3. Suppose that the distributed UUV system from our running example comprises 3 UUVs, i.e.,n = 3, each equipped with 2 on-board sensors and the character- istics shown in Table 5.5. The capability summaries CS after completing the DECIDE stages described in Sections 5.1.2 and 5.1.3 are shown in Table 5.6. The instance of the optimisation problem (5.9) solved by the DECIDE module running on each UUV is

minimise Pn

i=1ai3

subject to Pn

i=1ai1≥ 1000

W

1≤i1<i2≤n(ai12∧ ai22) = true

and (ai1, ai2, ai3)∈ CSi, 1≤ i ≤ 3

(5.12)

The optimisation problem for this system corresponds to a multiple-choice knapsack problem (MCKP) [137]. In this particular problem, however, we deal with the minimi- sation form of the MCKP, where the optimal solution is given by the minimum value of the objective functionPn

i=1ai3, subject to a set of constraints being satisfied, of which

at least one is upper bounded.

Our implementation of DECIDE described in Section 5.3 solves this problem by first transforming the minimisation form of MCKP to its equivalent maximisation problem by calculating for each UUV, the following values:

¯ ai1= max1≤k≤Niaki1 ¯ ai3= max1≤k≤Nia k i3 (5.13)

and updating each capability summarycsk

i,1≤ i ≤ 3, 1 ≤ k ≤ 4, as follows: a0 i1= ¯ai1− aki1 a0_i3= ¯ai3− ak_i3 C =Pn i=1a¯i1− bound1 (5.14)

Table 5.5: Characteristics of the three-UUV system

UUVi ri1[Hz] ei1[J] eoni1[J] eoffi1[J] ri2[Hz] ei2[J] eoni2[J] eoffi2[J]

1 4 1.3 10 2 4.5 1 5 1

2 3.5 1.6 15 3 4 1.3 10 2

3 4.5 1.3 10 2 5 1 5 1

wherebound1 is the constraint specified for system-level QoS requirement R1 andC is

the knapsack capacity. Then using an efficientO(n2_{) dynamic programming algorithm,}

adapted from [157], we obtain the optimal solution to the problem solving the following equation recursively

DP [i][l] = max(l_{− a}k

i1≥ 0?DP [i − 1][l − aki1] + aki3:−∞) (5.15)

where DP is a suitable data structure of size4_{× C, 1 ≤ l ≤ C, and “?:" is the ternary} operator (shortcut for “if...then...else”). Note that DP [0][l], 1 _{≤ l ≤ C is an auxiliary} element of dynamic programming paradigm where all entries are 0.

After solving (5.15), the chosen CLAs (i.e., the optimal solution) for the 3-UUVs are:cla1=(384, true, 647); cla2=(190, true, 270); and cla3= (441, true, 707). These CLAs

have been established using configuration subsets Cfg4₁, Cfg3₂, and Cfg4₃, respectively.

Table 5.6: Capability summaries of the three-UUV system

k csk

1 csk2 csk3

1 (0, false, 3) (0, false, 5) (0, false, 3) 2 (185, true, 350) (163, true, 392) (213, true, 381) 3 (208, true, 292) (190, true, 270) (236, true, 321) 4 (384, true, 467) (343, true, 667) (441, true, 707)