[ieee 2002 ieee aerospace conference - big sky, mt, usa (9-16 march 2002)] proceedings, ieee...

9
QoS Tradeoffs for Guidance, Navigation, and Control Ella M. Atkins Robert M. Sanner Department of Aerospace Engineering University of Maryland, College Park College Park. MD 20742, USA atkins, [email protected] Abstract-Future space missions will require onboard au- tonomy to reduce data, plan activities, and react appropri- ately to complex dynamic events. Software to support such behaviors is computationally-intensive but must execute with sufficient speed to accomplish mission goals. The lim- ited processing resources onboard spacecraft must be split between the new software and required guidance, naviga- tion, control, and communication tasks. To-date, control- related processes have been scheduled with fixed execu- tion period, then autonomy processes are fit into remaining slack time slots. We propose the use of Quality-of-Service (QoS) negotiation to explicitly trade off the performance of all processing tasks, including those related to spacecraft control. We characterize controller performance based on exhaustive search and a Lyapunov optimization technique and present results that analytically predict worst-case per- formance degradation characteristics. The results are illus- trated by application to a second-order linear system with a linear state feedback control law. TABLE OF CONTENTS INTRODUCTION RESOURCE ALLOCATION AND SCHEDULING QoS NEGOTIATION 00s LEVEL SPECIFICATION CONTROLLER TASK SPECIFICATION ANALYSIS AND COMPUTATION OF p(T) EXAMPLE APPLICATION SUMMARY I. INTRODUCTION Aerospace software is becoming increasingly complex while processing and communications hardware are strug- gling to accommodate the demands. Onboard data pro- cessing is expected to improve the quality of scientific data transmitted to Earth. Autonomy techniques for planning, scheduling. and fault management will increase robustness and ultimately enable ambitious deep space and forma- tion flight missions previously considered infeasible due to communications and ground support requirements. These advanced capabilities are expected to be computationally- intensive thus will require efficient utilization of onboard processing resources. Spacecraft typically support a single onboard processor foc all software. For critical hard real-time tasks, resources are reserved in advance to guarantee execution properties based on required execution period and worst-case exe- cution time. During execution, soft real-time tasks are then fit into remaining time slots, usually based on a dy- namic priority queue. As emerging non-critical-path tech- nology, software for high-level autonomy has been cast as soft real-time, while stability-related operations such as guidance, navigation, and control take their fixed "bite" on available computational resources. Automation engineers have reduced software complexity to the extent possible by manually designing algorithms that reduce flexibility and increase reactivity, often blurring the distinction be- tween "planning" and "execution" architecture layers. Un- der nominal mission profiles, this tradeoff is acceptable, but lack of flexibility ultimately reduces system robustness to faults and unanticipated environmental events. The real-time computing community has embraced the "Quality of Service" (QoS) paradigm for scheduling tasks on over-utilized processors and networks. Tasks have mnl- tiple levels of quality to be traded off, including worst- case execution time, execution period, deadline, and perfor- mance degradation relative to the highest QoS level. Ide- ally, a simple search through QoS space will reveal an ac- ceptable set of tasks that fit on available resources while still meeting minimum performance criteria. However, to perform this search, the tradeoff between processing re- quirements and performance must be well-characterized for each task. In this paper, we review real-time scheduling and recent progress in dynamic QoS management. We cast the space- craft software execution management problem under the QoS framework and discuss how a QoS manager would control the execution of U// spacecraft software tasks, rang- ing from high-level planning to low-level control.' The QoS negotiation protocol uses task execution reward ver- sus resource requirements (cost) to optimize computational resoume utilization and guarantee minimum system perfor- ' Forthis work. we consider only processing iesources. Acomplete QoS manager would handle comnlunicadon. data channel. and awilable power res0"urCes as well. 7-3333

Upload: arm

Post on 08-Feb-2017

213 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: [IEEE 2002 IEEE Aerospace Conference - Big Sky, MT, USA (9-16 March 2002)] Proceedings, IEEE Aerospace Conference - QoS tradeoffs for guidance, navigation, and control

QoS Tradeoffs for Guidance, Navigation, and Control Ella M. Atkins Robert M. Sanner

Department of Aerospace Engineering University of Maryland, College Park

College Park. MD 20742, USA atkins, [email protected]

Abstract-Future space missions will require onboard au- tonomy to reduce data, plan activities, and react appropri- ately to complex dynamic events. Software to support such behaviors is computationally-intensive but must execute with sufficient speed to accomplish mission goals. The lim- ited processing resources onboard spacecraft must be split between the new software and required guidance, naviga- tion, control, and communication tasks. To-date, control- related processes have been scheduled with fixed execu- tion period, then autonomy processes are fit into remaining slack time slots. We propose the use of Quality-of-Service (QoS) negotiation to explicitly trade off the performance of all processing tasks, including those related to spacecraft control. We characterize controller performance based on exhaustive search and a Lyapunov optimization technique and present results that analytically predict worst-case per- formance degradation characteristics. The results are illus- trated by application to a second-order linear system with a linear state feedback control law.

TABLE OF CONTENTS

INTRODUCTION RESOURCE ALLOCATION AND SCHEDULING

QoS NEGOTIATION 00s LEVEL SPECIFICATION

CONTROLLER TASK SPECIFICATION ANALYSIS AND COMPUTATION OF p(T)

EXAMPLE APPLICATION SUMMARY

I . INTRODUCTION

Aerospace software is becoming increasingly complex while processing and communications hardware are strug- gling to accommodate the demands. Onboard data pro- cessing is expected to improve the quality of scientific data transmitted to Earth. Autonomy techniques for planning, scheduling. and fault management will increase robustness and ultimately enable ambitious deep space and forma- tion flight missions previously considered infeasible due to communications and ground support requirements. These advanced capabilities are expected to be computationally-

intensive thus will require efficient utilization of onboard processing resources.

Spacecraft typically support a single onboard processor foc all software. For critical hard real-time tasks, resources are reserved in advance to guarantee execution properties based on required execution period and worst-case exe- cution time. During execution, soft real-time tasks are then fit into remaining time slots, usually based on a dy- namic priority queue. As emerging non-critical-path tech- nology, software for high-level autonomy has been cast as soft real-time, while stability-related operations such as guidance, navigation, and control take their fixed "bite" on available computational resources. Automation engineers have reduced software complexity to the extent possible by manually designing algorithms that reduce flexibility and increase reactivity, often blurring the distinction be- tween "planning" and "execution" architecture layers. Un- der nominal mission profiles, this tradeoff is acceptable, but lack of flexibility ultimately reduces system robustness to faults and unanticipated environmental events.

The real-time computing community has embraced the "Quality of Service" (QoS) paradigm for scheduling tasks on over-utilized processors and networks. Tasks have mnl- tiple levels of quality to be traded off, including worst- case execution time, execution period, deadline, and perfor- mance degradation relative to the highest QoS level. Ide- ally, a simple search through QoS space will reveal an ac- ceptable set of tasks that fit on available resources while still meeting minimum performance criteria. However, to perform this search, the tradeoff between processing re- quirements and performance must be well-characterized for each task.

In this paper, we review real-time scheduling and recent progress in dynamic QoS management. We cast the space- craft software execution management problem under the QoS framework and discuss how a QoS manager would control the execution of U / / spacecraft software tasks, rang- ing from high-level planning to low-level control.' The QoS negotiation protocol uses task execution reward ver- sus resource requirements (cost) to optimize computational resoume utilization and guarantee minimum system perfor-

' Forthis work. we consider only processing iesources. Acomplete QoS manager would handle comnlunicadon. data channel. and awilable power res0"urCes as well.

7 - 3 3 3 3

Page 2: [IEEE 2002 IEEE Aerospace Conference - Big Sky, MT, USA (9-16 March 2002)] Proceedings, IEEE Aerospace Conference - QoS tradeoffs for guidance, navigation, and control

mance. However, desirable results rely on accurate perfor- mance characterization for each task.

For guidance. navigation, and control, task performance is cast in terms of actual versus desired vehicle motion. Guid- ance algorithms calculate the trajectory to follow and can uade off complexity for accuracy as required. Navigation and control rely on hardware interface and software execu- tion. For navigation, sensor selection (e.g., GPS vs. laser) and the state estimation algorithm control task execution time. Feedback control algorithms compute from the avail- able state estimate the actuator inputs (forces,torques) re- quired for the vehicle to follow the guidance solution.

Because of the mathematical tools utilized to design each of these important subsystems, particularly the latter, they have traditionally been assigned an invariant slice of the onhoard execution time, rigidly executing at fixed, guaran- teed intervals for fixed, guaranteed durations. To properly include each of these systems in QoS tradeoffs requires an analysis of the extent to which this paradigm can be re- laxed, allowing more flexihlity in the scheduling of GN&C subsystem execution.

This paper attempts to take a first step in this direction, by quantifing the performance tradeoffs incurred by ninning the control subsystem at variable rates. We present both exhaustive search and Lyapunov-based techniques for op- timization of a performance index p ( T ) that relates con- tmller execution period to controller performance, mea- sured by the worst case excursions of the system from its desired equilibrium. We demonstrate how this analysis can he integrated into the QoS resource management model, and illustrate the techniques with a second-order dynamic system.

2. RESOURCE ALLOCATION AND SCHEDULING

For a real-time computing system, a "plan" is a set of tasks T = {TI, . . . , T,} with resource requirements and timing constraints. The problem of resource allocation is to map the set of planned tasks onto a set of available resources such that all constraints are met. Tasks are typically clas- sified as either hard real-time or soft real-time. Hard real- time tasks must be guaranteed to meet execution deadlines; spacecraft guidance, navigation, and control tasks are typ- ically characterized in this vein. For periodic tasks such as navigation or control, each task Ti has worst-case com- putation time Ci and period Pi. The worst-case computa-' tion time includes scheduler context-switching overhead. The j th invocation of task Ti becomes ready for execu- tion at time ( j - l)P;, called task arrival time, ai[j]. The deadline, d i [ j ] , of a task invocation is usually such that d ib ] 5 ai[j] + Pi since each invocation must complete its execution before the next one arrives. It is sufficient for resource allocation algorithms to find a task schedule within a finite interval, L, equal to the least common mul- tiple of all task periods, called the planning cycle. The re-

sulting task schedule repeats itself in subsequent planning cycles. Each task may be composed of one or more sep- arately schedulable modules (Le,, threads) with arbitrary precedence constraints. The resource requirements of each module are known a priori since we know the resource pro- file for the application code.

The selection of a proper resource allocation algorithm de- pends on the execution platform considered. An optimal resource allocation algorithm is described in 151 for unipro- cessors, in [6] for multiprocessors, and in [3] for distributed systems. Once the task assignment is fixed, an optimal of- fline scheduling algorithm such as that found in 121 can be used to preschedule the tasks. Hard real-time tasks are guaranteed computing resources first. Best-effort (i.e., soft real-time) tasks are then fit, when possible, into gaps of this schedule. The resulting overall schedule for each processor is stored in a table.

The resource allocation analyzer receives input Ti E (Tmondotory, Pi) then retums a success/failure status and utilization matrix U in which each element U(z, q ) is the utilization consumed by task Ti of resource class q. The scheduler database defines the worst-case resource require- ments of all task modules (or threads) &$ E Ti. Elements U ( i , q) are computed by the resource allocation analyzer as follows. Within each planning cycle L the total capacity of a resource p is pQL, where p is the number of instances of the resource and Q is the capacity of each. If module A l k of period Pk and execution time Ck requires ai amount ~ k , ~ of the resource throughout its execution, then its to- tal demand on that resouxe within the planning cycle is ~fi,,CkL/Pk. The ratio of that demand to the total avail- able resource capacity is the utilization u(k, q) consumed by module (or thread) M k of resource q. The utilization U ( i , q ) consumed hy task Ti of resource q is the sum of the utilizations u(k , y) of all modules Mfi E T,.

3. QoS NEGOTIATION

Predictability in realtime applications is generally ;achieved by reserving resources control under a priori assumed load and failure conditions. Graceful Quality of Service (QoS) degadation, on the other hand, requires dynamic resource reallocation in order to cope with changing load and fail- ure conditions while maximizing system utility. Both pre- dictability and graceful QoS degradation are necessaty for realtime applications but pose conflicting requirements.

Our Quality of Service (QoS) negotiation model is centered around three simple abstractions: QoS levels, rewards, and rejection penalty. A client requesting service specifies in its request a set of negotiation options and the penalty of rejecting the request derived from the expected utility of the requested service (i.e., task execution). Each negoti- ation option consists of an acceptable QoS level for the client to receive from the provider and a reward value com- mensurate with this QoS level. The reward represents the

7-3334

Page 3: [IEEE 2002 IEEE Aerospace Conference - Big Sky, MT, USA (9-16 March 2002)] Proceedings, IEEE Aerospace Conference - QoS tradeoffs for guidance, navigation, and control

"degree of satisfaction" to be achieved from the QoS level (i.e.. application-perceived utility of supplying the client with that level of service). Thus, the client's negotiation options represent a set of altematives for "acceptable" QoS and their "utility". The rejection penalty of a client's re- quest is the penalty incumed to the application if the request is rejected.

To control system load in a way that ensures predictable service, a scheduler must determine whether the request can be guaranteed or must be rejected. For QoS negotia- tion, a guaranteeing a client's request is the certification of the request to receive service at one of the QoS levels listed in its negotiation options. The selection of the QoS level it will actually receive, however, is up to the scheduler. Furthermore, during plan execution, the service provider will be free to switch this QoS level to another level in the client's negotiation options if it increases perceived utility (e.g., if tasks take much less than their worst-case require- ments, the dynamic scheduler can insen one or modules with a higher QoS level to take advantage of the extra slack resources).

Middleware services such as RTPOOL [l] have been used to illustrate the utility of the QoS negotiation protocol. Each incoming client request for scheduling a task includes its rejection penalty along with the different QoS levels and their rewards. A client tasks QoS level is specified by the parameters of its execution model. For an independent pe- riodic task, the parameters consist of task period, deadline. orid c.\-ecutiori time. A reward associated with each QoS level tells RTPOOL the utility of executing the specified modules of the task with the given period and deadline.

When one or more new requests arrives at a machine, RT- POOL executes a local QoS optimization heuristic, which computes the set of QoS levels for all local clients to maximize the sum of their rewards. A task may be re- jected if both (i) the new sum of rewards (including that of the newly-anived task) is less than the existing sum prior to its anival, and (ii) the difference between the current and previous sums is larger than the new task's rejection penalty. Otherwise, the requested task is guaranteed. As a result, task execution requests will be guaranteed unless the penalty from resulting QoS degradation of other local clients is larger than thai from rejecting the request. By offering QoS degradation as an altemative to rejection and by using admission control rules, we can show that the re- ward sum (or perceived utility) achieved with our scheme is lower bounded by that achieved using conventional admis- sion control schemes given the same schedulability anal- ysis and load sharing algorithms. Details on the specific optimization algorithms used by middleware services such as RTPOOL may be found in [I].

2Numerical values are for illustrative purposes ady.

~

7 - 3 3 3 5

Table 1. Example Spacecraft QoS Levels.

4. QoS LEVEL SPECIFICATION

A QoS task manager presupposes the existence of a table containing QoS levels for all tasks. Each task Ti has a set of QoS levels L;, each of which has an associated worst- case execution time C;, execution period P;, version 15, and associated reward R;. The worst-case execution time is a function of algorithm, so altemate task versions li, may be defined that reduce C; but also deprade result quality (e.g., through approximation). Task period is defined to meet system performance requirements, and the overall re- ward for a QoS level reflects both task execution criticality for the overall system and relative quality of degraded QoS levels relative to the maximum (level I) value.

A sample decomposition of tasks available for a space- craft controller is shown in Table 1.' As shown by their relatively high reward values, guidance, navigation, and control tasks are critical to the overall performance of the spacecraft. Communication, data processing, and plan- nerlschedoler operation are of somewhat lesser stature, with Communication taking precedence over the latter modules when dictated by resource constraints.

When expanded with more levels, such a table provides a good first-step toward enabling tradeoffs required before advanced autonomy algorithms can coexist with guidance, navigation, and control software. Multiple task versions corresponding with different algorithms or instrumentation configurations naturally admit this tabular form for pro- cessing. On the other hand, perfomance degradation as- sociated with changes in execution period P; will be con- tinuous, and we wish as a minimum to capture the pattems of that degradation within the QoS table. In the following section, we focus on QoS level definition for the Control task, enabling us to better define the Control task QoS lev- els. Although beyond the scope of this paper, the remaining tasks will also require analogously in-depth analyses to ac- curately characterize numerical performancelreward trade- offs.

Page 4: [IEEE 2002 IEEE Aerospace Conference - Big Sky, MT, USA (9-16 March 2002)] Proceedings, IEEE Aerospace Conference - QoS tradeoffs for guidance, navigation, and control

5 . CONTROLLER TASK SPECIFICATION

The controlled vehicle is assumed to he modeled by a fi- nite dimensional system of linear, time invariant differen- tial equations, with a state-space description of the fomi

x( t ) = F x ( t ) + Gu(t) + H d ( t ) (1)

where x is the state of the system, U are the control in- puts to the system, and d are disturbances which act on the system. The values of each of the states are assumed IO he measured by appropriate sensors at discrete intervals ?a. The control inputs to the system during the interval [tr., t k + l ] are computed based upon these measurements, and are held constant at their computed values until the next sensor measurement is taken.

The sample intervals are assumed to be nominally constant, so that tk - = T for every k . The resulting dynamics of the samples xy = x(?k) can then he specified as

xk+l = A T X ~ + B T u ~ + Hdr. (2)

where uk is the constant control input level in the interval [tn., tr-+i], and

The matrices AT and BT can be computed directly from the continuous time description as [4]

AT = eFT T

BT = 1 eF’drG

For a fixed sample rate T , these matrices are constant.

For clarity in the following discussion, a simple second or- der system will be used as illustration:

which is prototypical of the problem of controlling the po- sition of an vehicle by varying the applied force, or equiva- lently, controlling the pointing angle by varying the applied torque. This model is easily placed into the form ( I ) , by choosing X I = y, the position (or angle) or the vehicle, and x2 = j, the Linear or angular velocity of the vehicle. In this case, it is easily computed that:

1 T T 2 / 2 . . = A [ ] The feedback control law, specifying what the inputs uk should be in response to state measurements xk. is typi- cally designed to ensure that the state remains close to its equilibrium x = 0 regardless of initial conditions x g or disturbance inputs dk. (Note that problems where the de- sired equilibrium is nonzero, for example a nonzero desired

pointing angle in the above second order system, can easily he transformed into an equivalent system model with a zero equilibrium [7].) Since the system is linear. with all states measured, a common method for achieving this objective is to compute the control input as a linear comhination of the measured states:

uk = -Kxk (4)

The resulting closed-loop dynamics are then of the form

X k + i = r T X k + Hdk (5)

where F T = AT - B T K ,

A necessary condition forthe success of this strategy is that the closed-loop dynamics be stable, indicated by the con- dition I&(rT)l < 1, where &(rT) are the eigenvalues of the matrix rT. A variety of algorithms are avaikihle to se- lect amatrix K to achievethis condition (assuming the pair [AT, BT] is controllable), as well as to achieve additional performance objectives for the behavior of the state x under a variety of assumptions about the nature of the disturbance d P I .

For the purposes of this paper, the additional performance objectives will be described in terms of the bound t = supk 1)xp/l where 11x/I is the euclidean norm of the state vector. This bound measures the worst case excursion of the state from its equilibrium in response to the distur- bance, as measured by the euclidean norm. For the example second-order system above, a requirement for small values o f t specifies that the position of the system must not move too far from its equilibrium, nor must the vehicle move too quickly. These are natural constraints to ensure that scien- tific imaging or measurement equipment aboard the vehicle can collect accurate data.

Note that use of the euclidean norm in this setting implic- itly assigns equal importance to deviations of any of the state variables, giving equal importance for example to po- sition deviations of c units as to velocity deviations of the same magnitude. In practice, there may he more severe constraints on the behavior of a subset of the state variables than on the others. In this event, by rescaling the states in the original state equation ( I ) to reflect the relative m a g i - tudes of the consrtaints, an equivalent sampled-dala model can he obtained for which satisfaction of the “hall-like” eu- clidean norm constaint in the new coordinates guarantees that the original states satisfy the desired (unequal) con- straints.

For this initial analysis, the specific class of disturbances to be considered will he inipukive, that is dk = 0 for all k # ko - 1 and dk,_l # 0, for some sample lime k g . This kind of disturbance is similar to a sudden wind gust striking an aircraft. The effect of this disturbance will be to pelrurb the state away from its equilibrium to a nr!w state

7 - 3 3 3 6

Page 5: [IEEE 2002 IEEE Aerospace Conference - Big Sky, MT, USA (9-16 March 2002)] Proceedings, IEEE Aerospace Conference - QoS tradeoffs for guidance, navigation, and control

X k o r which is assumed to satisfy IIxkoII 5 6, where 6 > 0 is a measure of the maximum "strength of the disturbance.

Rather than the more traditional control analysis of at- tempting to determine a general algorithm for selecting a feedback matrix K which meets a pmicular set of ( e , b ) performance targets, this paper instead seeks to quantify the behavior of the ratio p(T) = €16 as a function of the sample rate T for a given,fired matrix K . Especially, we wish to study the sensitivity of this ratio to variations in T , and quantify the perfotmancelsample-rate tradeoffs. In this manner we hope to take a first step towards develop- ing an analytical tool by which automation engineers can dynamically trade CPU cycles between the feedback con- trol algorithm and high level planning modules, while still meeting all performance objectives.

6 . ANALYSIS A N D COMPUTATION OF p ( T )

To begin the controller analysis, note that, with the assump- tions above, for any k 2 ko

Xk = * T ( k - k u ) X k 0

where -ST is the state transition matrix associated with the closed-loop matrix rT. Then

by linearity, and thus the ratio to be examined is given by

The following two sections explore two different tech- niques to compute the hound p from these expressions. The first utilizes exhaustive search, essentially analyzing explicitly all possible solutions of the closed-loop dynam- ics. The second utilizes a more geometric argument based on Lyapunov stability theory, and develops a constrained nonlinear optimization algorithm to estimate p.

It should be emphasized that the analysis helow is not a m e variable rate sampled-data analysis. It is rather assumed that changes to the controller execution rate are made only infrequently. If the sample rate were allowed to change every cycle of the controller, the system matrix A would in fact be time-varying, changing with each index k, This would require a more delicate analysis, although in princi- ple the techniques outlined could still be employed, with appropriate modifications.

Exhuustive Search

An exhaustive search type algorithm can be developed by exploting the following expansion: if xra = [cl , . . . , c,],

then n

* T ( k - k0)xko = c i4T, i (k - k0) i=1

where &,i is the ith column of the state transition matrix Qr. Substituting this expansion into the above equation for p and use of the triangle inequality gives

Each of the columns $T,i(k - ko) represents the state re- sponse of the system to an initial condition vector xo,; which has zeros everywhere except in the ith component, which has value I . Thus, an algorithm for computing a bound on p(T) can procede as follows: for each T on a suitably defined grid, compute numerically the n response vectors $T,;(IC) for IC = 0, . . . , N , where N is a suitably large to capture the majority of the state transients. These responses can he obtained by iterating equation ( 5 ) (with d k = 0) for each of then initial conditions ~0,;. (Note: to ensure that decreasing sample rates do not miss significant features of the tnie plant response, equation (2) can be iter- ated instead with a very small sample rate To, but updating the control input (4) only at the larger rate T.)

Once each of the responses dJT, i have been computed, and their values for each )i = 0,. . . , N stored, the euclidean norm of each vector response at each time IC can be com- puted, and the square mot of the sum of the squares of these norms evaluated. Taking the maximum of the resulting vec- tor of N + 1 values then produces an estimate of the ratio p. Iterating this process over the desired gid of sample times allows analysis of the sensitivity of p to variations in T.

Lyapunov Optimtation

Assuming that the sample time T is not so large as to drive the system unstable (indicated by the condition maxi i X i ( r T ) / > I), then it is known that, for any sym- metric positive definite Q there exists a symmetric positive definite PT which satisfies the Lyupunov equation:

r T T P T r T - PT = -Q

As a result, the positive function V(x) = X ~ P T X satisifies

V(xk+i) - V ( X ~ ) = -$QxL < 0.

From this inequality and the definition of V , it is straight- fonvard to show that

2 XPllXkl12 5 ~ P l I X k , l l

1 - 3 3 3 7

Page 6: [IEEE 2002 IEEE Aerospace Conference - Big Sky, MT, USA (9-16 March 2002)] Proceedings, IEEE Aerospace Conference - QoS tradeoffs for guidance, navigation, and control

leading to the hound I . EXAMPLE APPLICATION

To illustrate application of the above ideas, consider the example system (3) with a nominal sample rate of 100 Hz (T = .O1 sec). The feedback gain matrix K is chosen so that the closed-loop system has eigenvalues at 0.95+0.06j, resulting in a (nominal) natural frequency of 7.25 Hz. and damping ratio of 0.7: specifically K = m 150, 9.751 here.

Figure I shows the results for p ( T ) obtained using the ex- haustive search algorithm. The nominal bound p(.Ol) for this K is approximately 3.4, and the closed-loop system becomes unstable at T % ,206 secs, where the bound ~ ( 2 0 5 ) becomes infinite. For values of T between .Ol and ,205, notice the ‘‘knee” of the curve that occurs near T = .08 secs. At this point p(.08) c 4.25, or an increase of about 25% over the nominal value, and beyond this point the bound increases linearly with the sample rate: T, until instability sets in at T = 205 secs.

For an automation designer wishing to evaluate the impact of reallocating CPU time from the controller to ilu onboard planning algorithm, this tradeoff shows that the controller sample rate can be decreased by a factor of 8, while suffer- ing only a 25% decrease in pointing (or positioning) accu- racy for the class of disturbances considered. Beyond this point however, accuracy degrades linearly with increasing sample rate, with an upper limit of T < 205 secs required to still ensure stable closed-loop operation.

Notice that this result would not be obvious from exam- ination of the behavior of the closed-loop damping ratio as a function of T (the damping ratio is commonly used to predict the magnitude of the transient response of a second- order system). Indeed, as shown in Figure 2 the damping ratio remains quite close to its nominal value, not exhibit- ing a significant ‘‘bee” until T c 0.15 secs, or nearly twice the value of the inflection point in Figure 1 .

Figure 3 shows the Lyapunov conntours for the nominal system when Q = diag(.95’ - 1, .952 - 1). (The solution P of the Lyapunov equation for this Q is P = I when the closed-loop dynamics are written in modal (diagonal) co- ordinates. In these coordinates, the Lyapunov contours are thus indeed spherical, however they are still ellipsoidal in the original (non-modal) coordinates. as the Figure shows. The spherical nature of the contours in modal ccwdinates with this choice of Q makes it a logical starting point for the optimization of (6)). Figure 4 shows the contours ob- tained after a constrained nonlinear optimization of (6); no- tice that these contours are clearly more circular than those in Figure 3.

The hound p(.O1) found via this optimization is approx- imately 4.3, which is larger than that found by exhaus- tive search. The reason for the conservative nature of this bound can be understood by overlaying an example trajec- tory of the system over the Lyapunov contours. The ini-

where xp is the maximum eigenvalue of PT, and X p is the minimum eigenvalue of this matrix. Note that if the posi- tive definite matrix P is Cholesky factored P = RTR, then the above bound on llx// is 6 times the condition num- ber of the mauix R.

Note that there are infinitely many different pairs (PT , Q) which solve the Lyapunov equation for a given stable I?. A strategy for estimating p(T) can thus be found by optimiz- ing the ratio on the right hand side of the above inqeuality over all positive definite matrices Q:

where the function lyap solves the Lyapunov equation for PT given rT and Q , chol computes the Cholesky factor- ization, and cond computes the condition number.

To understand this analysis more intuitively, it is helpful to visualize the contour lines of the Lyapunov function V(x) as ellipsoids centered at the origin (for the second- order system above, the contours are oriented ellipses in the plane, as shown below). The inequality If(xn+l) - V(x,) 5 0, implied by the solutions of the Lyapunov equa- tion, mean that the evolution of the state trajectory is con- fined for all time to the ellipsoid in which it starts.

The quantity in the minimization above essentially mea- sures the maximum “elongation” of this ellipsoid, and hence the maximum possible excursion of the state trajec- tory away from the origin. The optimization procedure at- tempts to find the smallest possible value of this ratio given the constraints of the Lyapunov equation. Smaller ratios correspond to ellipsoids which are more spherical in shape than elongated, with the minimum possible ratio being 1, indicating perfectly spherical contour lines. Thus, the pro- cess of finding the tightest hound for p(T) can he visual- ized as finding the Lyapunov function V(x) = X ~ P T X which has the most spherical contour lines possible given the closed-loop matrix rT.

For reasons which will be illustrated below, this opti- mization procedure will necessarily give more conserva- tive bounds for p(T) than the exhaustive search procedure outlined in the previous section. However, this procedure potentially requires less total computation than exhaus- tive search, especially for larger state dimensions, and the bound (6) may be more amenable to funher analytical sim- plification by exploiting the structure of the matrix decom- positions used in computing the solutions lyap,chol, cond.

7-3338

Page 7: [IEEE 2002 IEEE Aerospace Conference - Big Sky, MT, USA (9-16 March 2002)] Proceedings, IEEE Aerospace Conference - QoS tradeoffs for guidance, navigation, and control

tial condition wed is that which causes the closed-loop dy- namics to achieve the bound p( .01) = 3.4 found by ex- haustive search. The hound 4.3 found by Lyapnnov opti- mization would actually be achieved if the closed-loop re- sponse were to follow the contour line on which it starts around to its maximum deviation away from the origin be- fore settling back to equilibrium. However, the condition I’(xn+l) < V(x*) implies that the state trajectory is in fact crossing progressively smaller valued countour lines as it moves, so that this worst-case bound will never actu- ally be achieved. Notice that the contours in Figure 4 are also less conservative than those of Figure 3 in this regard, as the contours of the former more closely conform to the shape of the trajectoly during its initial motion away from the initial condition.

Figure 5 shows the result of performing the Lyapunov opti- mization over the same range of T used for the exahustive search analysis. The hounds from Figure 1 are shown as a dashed line for comparison. The Lyapunov optimization gives a smoother, although more conservative, bound for p(T) with a more gentle inflection point in the curve near T = .10 secs. Although more conservative, it predicts a similar tradeoff of 23% decrease in performance for an 8 fold decrease in sample rate, and a 30% performance de- crease if the sample rate is decreased by a factor of 10.

8. SUMMARY

Spacecraft software is rapidly expanding to include on- board autonomy and data processing capabilities. Exist- ing guidance, navigation, and control processes are also becoming more complex as ambitious missions in forma- tion flying with near-zero error tolerance are defined. To- gether, this daunting set of tasks will inevitably over-utilize onboard computational resources if all tasks mn at peak performance levels.

In this paper, we have presented a QoS negotiation strat- egy for task scheduling. With this paradigm, each task to he scheduled is assigned multiple QoS levels, each of which defines a specific set of resource requirements and associated reward (performance) when a task is executed at that level. As computational resources become over- utilized, the QoS manager degrades task QoS levels un- til tasks can be fit onto the set of available computational resources. Offline, QoS negotiation yields task schedules that optimize overall task performance (reward). Online, QoS negotiation is invaluable for responding to adaptation of task properties and unanticipated faults (e.g., computa- tional resource failures).

QoS level specification requires detailed analysis of perfor- mance versus task execution parameters. Guidance, navi- gation, and control tasks require significant bandwidth but t d a t e have been rigidly scheduled to meet worst-case per- formance requirements. To build control task QoS levels, we have defined a performance index p(T) that relates con-

troller execution period to controller performance. mea- sured by worst-case excursion from desired equilibrium. We demonstrated how this analysis can produce QoS re- ward values with a simple second-order dynamic system and compared performance predictions from an exhaustive search versus a Lyapunov optimization.

Navigation and control tasks are inexorably coupled since the navigation task supplies the state estimate used by the controller to compute actuator outputs. Our controller ex- ecution rate analysis is thus applicable to QoS level spec- ification for both control and navigation tasks. In future work, remaining computational tasks (guidance, commu- nication, data processing, planningkheduling) must also be analyzed to enable accurate assessment of overall sys- tem performance. We have defined a specific performance measure p(T) for the control task that applies generically to guidance and navigation as well. However, different performance measures may be required for other tasks (e.g., quantity of relevant scientific data transmitted per unit time). We must define a principled way to compare such different performance measures, scaling relative task QoS rewards to capture mission priorities. Once captured, we will achieve a unified measure of performance to truly op- timize software execution.

REFERENCES

T. Abdelzaher, E. Atkins, and K. Shin, “QoS Negotia- tion in Real-Time Systems and Its Application to Au- tomated Flight Control”, IEEE Transactions 011 Com- puters, vol. 49,110. 11, pp. 1170-1183,2000.

C. L. Liu and James W. Layland, “Scheduling Al- gorithms for Multiprogramming in a Hard-Real-Time Environment”, Journal of the ACM, vol. 20, no. I, pp, 4641,1973.

D:T. Peng and Kang G. Shin and Tarek F. Abdelza- her, “Assignment and Scheduling of Communicating Periodic Tasks in Distributed Real-Time Systems”, IEEE Transactions 011 Purallel and Distributed Sys- tems, vol. 8, no. 12, December 1997.

G . Franklin, J. Powell, and M. Workman, Digi- tal Control of Dynamic SJ’stems, 3rd ed, Addison- Wesley, Reading MA, 1998.

J. Xu and D. L. Pamas,”Scheduling Processes with Release Times, Deadlines, Precedence. and Exclusion Relations”, IEEE Transactions on Sofmare Engineer- ing,voI. SE-16, no. 3, pp. 360-369, March 1990.

J. Xu.”Multiprocessor Scheduling of Processes with Release Times, Deadlines, Precedence, and Exclusion Relations”, IEEE Transactions on Software Engineer- ing, vol. 19, no. 2, pp. 139-154. February 1993.

K. Ogata, Modem Control Engineering. 3rd ed., Prentice Hall, Upper Saddle River, NI, 1997.

W. Rugh, Linear System Theory, 2nd ed., Prentice

7-3339

Page 8: [IEEE 2002 IEEE Aerospace Conference - Big Sky, MT, USA (9-16 March 2002)] Proceedings, IEEE Aerospace Conference - QoS tradeoffs for guidance, navigation, and control

Hall, Upper Saddle River, NJ. 1996.

of Aerospace Eitgineerirtg at the Uni- versiQ of Maryland. Her research iuterests robolic and include uninhabited autoniation aerial of space vehi- ' 0 - 1 .. ' " ' ' -

conipurarioii. DK Atkins eanied S.B. and S.M. degrees in Aeronautics and

a structural dynamics test engineer for SDRC, after which she retunied to school, eaniing M.S. and Ph.D. degrees in Computer Science and Engineering from the University of Michigan.

cles, fomiafioii J ly iw a d real-time *. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

P Astror,auticsfroni Mm She worked as 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..: . . . . . .

<.. . . . . . .:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . '1'' I ' 'I I d

0 05 0 1 0 1 5 0 2 0 25 7 1 Rob Sanner is an Associate Professor sa"@* P * W ,se4

of Aerospace Eiigineeriiig at the Uni- versity of Maryland. His researcl? in- terests include uonlinear and adaptive control of UAVs arid space robotic sys- tems, formation j y i n g algorithms, and distributed contputdon. Di: Sanner eanied S.B.S.M., and Ph.D. degrees in Aeronautics and Astronautics from MIr and is currently the Associate Di-

rector for Research of the UMD Space Systems Loborntory.

Figure 1. Bounds p(T) found by exhaustive search u

0.1 0.5 0 25 Sample P e n d ,lP)

Figure 2. Closed-loop damping ratios as a function of T.

7-3340

Page 9: [IEEE 2002 IEEE Aerospace Conference - Big Sky, MT, USA (9-16 March 2002)] Proceedings, IEEE Aerospace Conference - QoS tradeoffs for guidance, navigation, and control

I

..... . . . . . . . . . . . . . . . . . . . . .~ ,. _ - 4.. _ _ - -

PoS3tlO"

Figure 4. Final Lyapnnov contours found after optimiza- tion.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2t. ~

Figure 5. Bounds for p(T) found by Lyapunov optimiza- tion (diamonds), compared with bounds found by exhaus- tive search (dashed line).

7-3341