Model-Based Design of End-to-End Quality of Service in a Multi- UAV Surveillance and Target Tracking Application

Transcription

1 Model-Based Desgn of End-to-End Qualty of Servce n a Mult- UAV Survellance and Target Trackng Applcaton Joseph P. Loyall 1, Janmng Ye 1, Sandeep Neema 2, Nagabhushan Mahadevan 2 1 BBN Technologes, Cambrdge, Massachusetts 2 Vanderblt Unversty, Nashvlle, Tennessee 1 Introducton Desgnng and mplementng large dstrbuted, real-tme embedded (DRE) computng systems s challengng because these applcatons need to be able to react n real-tme to changes n mssons, condtons and operatng envronments wthn the scope of ther domans. There are especally challengng ssues surroundng the desgn and mplementaton of DRE systems wth managed end-to-end qualty of servce (QoS) propertes when those systems must adapt to the changes n both the computatonal and physcal unverses wthn whch they operate [12]. Whle advances n desgn methodology especally model-ntegrated computng (MIC) [10] and mddleware technologes [7,11,13] have made desgnng and developng the functonal logc of DRE systems much easer, the same cannot be sad about QoS features. MIC and most other tools are prmarly focused on the functonal logc wth at best lmted capabltes to capture QoS concerns. Even though QoS mddleware such as Qualty Objects (QuO) [4, 9, 15] has made QoS adaptve desgn and mplementaton smpler, usng abstractons and mechansms provded by the mddleware stll requres hghly sklled ndvduals wth strong ntutons about both the needs of the doman and the ways to manpulate the varous dmensons contrbutng to the managed QoS behavor. Wthout sgnfcant mprovement n our ablty to smplfy and at least partally automate the development of adaptve QoS strateges for collectons of dstrbuted components, many applcatons of these complex QoS concepts and contexts wll reman mpractcal to buld or be of lmted utlty. Therefore, there s a compellng need for applyng desgn-tme methodologes to develop and control these runtme adaptatons systematcally. In ths paper, we descrbe the applcaton of DQME, a modelng envronment that we have created for desgnng QoS adaptve applcatons, to the desgn of a representatve DRE applcaton nvolvng multple UAVs engaged n mult-mode mssons. 2 Dstrbuted QoS Modelng Envronment Under the auspces of the DARPA MoBIES program, we appled MIC to the problems of desgnng, customzng, and managng the adaptve runtme characterstcs of DRE applcatons. In partcular, we utlzed and augmented the Generc Modelng Envronment (GME) [1] to develop the doman-specfc Dstrbuted QoS Modelng Envronment (DQME) for desgnng runtme adaptve capabltes as provded by the QuO adaptve QoS mddleware framework. QuO s a mddleware framework that supports dynamc QoS adaptaton n dstrbuted applcatons [9]. QuO provdes a set of extensons to exstng off-the-shelf mddleware (ncludng CORBA and Java RMI), specfcaton languages, and a runtme system to support QoS awareness and manage dynamc adaptatons. It has been used n a number of demonstratons and applcatons [5], rangng from wde-area dstrbuted applcatons to embedded real-tme systems. Wth QuO, dstrbuted applcatons can specfy (1) ther QoS requrements, (2) the system elements that must be montored and controlled to measure and provde QoS, and (3) the behavor for controllng and provdng QoS and for adaptng to QoS varatons that occur at run-tme. QuO separates the role of functonal applcaton development from the role of developng the QoS behavor of the system. GME uses doman models and advanced user/desgner nterfaces to manpulate elements n the doman space that are ntellgently nterpreted by the models to produce effectve desgns and code elements representng that desgn [2]. As a reusable framework for creatng doman-specfc desgn envronments, GME supports a set of abstract modelng concepts that are generc enough to be applcable to a wde range of domans, not just lmted to software systems. These concepts nclude contanment (composton, aggregaton, and herarchy), module nterconnecton and nteracton, aspect modelng, nhertance, and attrbutes. It uses metamodelng to defne a doman-specfc language and to model constrants and relatonshps. Selected concepts are customzed for a target doman durng the metamodelng process. A metamodel defnes the famly of doman models that can be created usng the doman-specfc modelng envronment. System modelers use the resultng envronment to create applcaton models to analyze, smulate, and automatcally generate the target mplementaton. GME provdes support for tool ntegraton and extensblty [3]. Model nformaton and data can be communcated b-drectonally through varous programmng nterfaces, ncludng COM, BON (Bulder Object Network), and UDM (Unfed Data Model). Whle both QoS adaptve mddleware such as QuO and MIC envronments such as GME are effectve at what they set out to do, both also have mportant lmtatons. QoS adaptatons are currently mostly hand-coded n specal purpose languages and Ths work was sponsored by the Defense Advanced Research Projects Agency (DARPA) under contracts F C-4037 and F C

2 envronments, lmtng the complexty of the adaptaton strateges to those that a QoS desgner can understand n terms of localzed behavors and localzed measurements whle the QoS features themselves are nherently crosscuttng and dstrbuted. MIC tools such as GME can capture complex desgn concepts at varous levels of abstracton and ntellgently produce effectve desgns and code elements representng that desgn. However, they currently have lmted or no hgh-level capabltes for representng reusable QoS-related behavoral aspects n a way that would facltate the ntegrated desgn of QoS adaptve software. A mergng of these two tools would ncrease the power of both, ultmately leadng to tools that can be used to buld ntegrated models of applcaton domans and adaptaton strateges. We have developed a semantcally rch, Fgure 1. SystemDynamcs metamodel n DQME doman-specfc modelng language supportng the hgh-level desgn/representaton of QoS adaptaton strateges and concerns based on the techncal approach proposed n our earler papers [6, 14]. Our prototype envronment DQME supports herarchcal models of the essental components descrbed n [14], wth the hgher levels representng the components of end-to-end QoS adaptatons n support of system wde goals. The model developer can descend nto these models to create models of more local adaptatons, based upon local parameters, but coordnated wth the other subordnate models n support of the hgher level goals. The sx essental model objects captured n DQME metamodel (as dentfed n [14]) are dscussed below wth focus on two components, system dynamcs and adaptaton strateges. Msson requrements Ths s used to capture the hgh-level msson requrements of the system: functonal and QoS goals that must be met by the applcaton; relatve mportance of tasks; and mnmum requrements on performance or fdelty. These help determne the relatve mportance of adaptaton strateges and tradeoffs. Observable parameters Before any adaptaton acton can be taken, the system has to know ts current state wth regard to the QoS of nterest. These parameters determne the applcaton s current state and they are also mportant to help determne and/or predct the system s next state. Controllable parameters and adaptaton behavors These are the knobs avalable to the applcaton for QoS control and adaptaton. These can be n the form of nterfaces to mechansms, managers or resources, or n the form of packaged adaptatons, such as those provded by QuO s Qosket encapsulaton capablty [8]. By selectng a set of these knobs, we can move a system from one state to another. System dynamcs Based on the current state of the system (Observable parameters) and the set of knobs avalable (Controllable parameters and adaptaton behavors), there could be several optons for adaptaton. The nteractons between these are reflected n the system dynamcs and can help defne the set of possble trajectores that an applcaton can take. The SysteeDynamcs metamodel s shown n Fgure 1. The QPRef object s a reference to Controllable or Observable object. Fgure 2. Controller metamodel n DQME 2

3 The key of the SystemDynamcs s the functon object. Gven some nputs, a functon produces some outputs based on the logc expressed n the object. Analytcal models wth complcated logcs can be modeled usng chaned functons. The outputs can then be used by the adaptaton strateges to determne the next system state. Adaptaton strateges Here we actually choose an adaptaton strategy, whch specfes the adaptatons employed and the tradeoffs made n response to dynamc system condtons n order to mantan an acceptable msson posture. When makng a decson, the adaptaton strateges take nto account the msson requrements, current system state, as well as system dynamcs usng a utlty functon. The goal s to satsfy the msson requrements and maxmze the utlty. Multlevel adaptaton strateges are modeled wth a herarchcal representaton at dfferent levels of adaptaton. The Controller metamodel s shown n Fgure 2. Our metamodel currently supports the followng types: state machnes, supervsory control, feedback control, and search spaces. We are currently addng more types such as regon spaces and classcal compensators to capture a wder range of adaptaton strateges. The Utlty object provdes a functon to calculate the utlty of the system. The goal s to maxmze the utlty, thus maxmzng the QoS, through adaptaton. To support automated applcaton synthess, we developed varous tools to generate confguraton fles, QuO code, C++ code, and Matlab code. These synthess tools allow us to buld hghly complex DRE systems, wth adaptve QuO code and Qoskets nserted at approprate places, n mnutes rather than hours or days. A new set of artfacts can be regenerated to reflect the changes n the model, thus elmnatng human errors n manual code modfcaton throughout the applcaton. We have also developed mechansms through the UDM nterface to feed runtme measurements and evaluatons (e.g., statstcs, optmal parameter values) back nto the model, thus allowng us to do teratve model refnement. 3 Mult-UAV Survellance and Trackng Applcaton As an Open Expermental Platform (OEP) and demonstraton for the DARPA Program Composton for Embedded Systems (PCES) program, we have been developng a representatve DRE system focused on the use of multple reconnassance UAVs (RUAVs) to do survellance and target trackng n conjuncton wth Combat UAVs (UCAVs) and ground vehcles for tme crtcal targetng. The scenaro of the demonstraton s llustrated n Fgure 3 and nvolves a set of RUAVs performng theater-wde survellance, sendng survellance magery to a Combned Ar Operatons Center (CAOC). When a commander recognzes an tem of nterest (e.g., a target or threat), he commands a RUAV to concentrate ts survellance on the area of nterest (AOI). When a postve dentfcaton of a threat has been made, the commander dspatches a ground or ar combat unt to engage the target, wth the UCAV performng battle damage assessment (BDA) afterwards. As part of our PCES and MoBIES efforts, we are capturng the end-to-end QoS requrements necessary to support the Mult-UAV Survellance and Trackng Applcaton n DQME. A screen shot of the mult-uav applcaton modeled n DQME s shown n Fgure 4. Whle ths work s ongong, the followng sectons descrbe our ntal efforts to do ths. 3.1 Msson Requrements There are three prmary msson modes that have to be captured, wth msson requrements assocated wth each of them. Msson Mode A: Survellance. In ths mode, all RUAVs are performng survellance. The prmary msson s to maxmze the survelled area wth suffcent resoluton n magery for a commander to determne an tem of nterest. Ths means that magery from each RUAV must be sent at a suffcent rate to ensure there are no gaps n survellance coverage and at suffcent sze and resoluton for a commander to dscern command level detal. The maxmum possble rate, sze, and resoluton are determned by the capabltes of the RUAV s camera. A representatve UAV camera can provde 30 frames per second, 720x480 pxel, 24 bts per pxel magery. Ths means that one UAV could provde mllon bts per second (Mbps) of magery at the upper bounds. For the lower bound on our survellance magery, the resoluton and sze must be determned by commander nput, by human factors research, or by expermentaton, but a good frst cut CAOC Fgure 3. The OEP applcaton conssts of smulated RUAVs performng survellance, a UCAV and ground unts that can handle tme crtcal targets and perform battle damage assessment. Many UAVs dssemnate analog vdeo; ths s the dgtal equvalent provded by an analog to dgtal converter. 3

4 (determned by dscusson wth operatonal personnel) s sze no smaller than 360x240 (1/4 sze) and resoluton no lower than 8 bts per pxel. The lower bound on frame rate must be computed based on the speed of the RUAV and the scan sze of ts camera to avod any gaps n survellance. For example, assumng a cruse speed of 84 mph (0.037 km/sec) and a scan sze of 0.25 km by 0.25 km, the frame rate should be no lower than 0.15 frame per second, or one mage every sx seconds. Ths puts the absolute mnmum data sze at 85.3 Kbps per RUAV. Ths s a wde range wthn whch to adapt (248.8 Mbps to 85.3 Kbps) per RUAV. The adaptaton across RUAVs wll take nto account the number of UAVs and the amount of resources (see the adaptaton strateges n Secton 3.5 below), but the msson requrements must also ndcate the tradeoffs preferred. In ths case, agan specfed n conjuncton wth doman experts, we specfy the tradeoff order for the RUAV n Mode A as an ordered sequence Fgure 4. DQME Model of Mult-UAV Applcaton {rate, mage_sze, resoluton},.e., the preference s to tradeoff rate, then mage sze, then resoluton (untl the mnmum). Image compresson n general changes the overall data sze and mage processng tme. Lossy compresson can also affect (reduce) mage resoluton. Msson Mode B: Target Acquston and Engagement. In ths mode, at least one RUAV (the prvleged RUAV) has been dentfed to be observng an AOI. Ths RUAV (or set of RUAVs) s dentfed as beng more mportant than the others. The msson requrements of ths RUAV are to provde hgh resoluton magery so that postve target or threat dentfcaton can be made. Snce the RUAV can hover or crcle over the AOI, the mnmum rate s no longer determned by the speed of the RUAV, but by the speed of any moble targets, or more accurately, the dfference between ther speed and that of the RUAV snce the RUAV can pursue. Lkewse, wth statonary targets and the RUAV centered on the AOI, croppng the mage (.e., removng less mportant perpheral magery by selectng a dfferent scan sze) becomes an opton. Assumng a statonary AOI, the tradeoff order for the prvleged RUAV s {rate, scan_sze},.e., changng the mage sze and resoluton are not allowed. The mnmum frame rate can be even lower than one frame every sx seconds, but the mage sze and resoluton cannot be lower than the mnmums n Mode A. The other, non-prvleged RUAVs have the same msson requrements as n Mode A. Msson Mode C: Battle Damage Assessment. In Mode C, a target has been engaged and a UCAV enters the msson to perform BDA. The prvleged RUAV s stll performng survellance of the AOI and the other RUAVs are stll performng theater survellance, so ther msson requrements are the same as n Mode B. The UCAV needs to provde regular magery untl a human operator determnes that he has suffcent detal to dscern battle damage. Imagery from the UCAV does not need to start mmedately, snce dust and smoke wll obscure the scene mmedately after engagement, but once magery has started, hgh resoluton magery must be delvered regularly untl a commander decdes t s suffcent (trggerng a return to Mode B). In dscusson wth doman experts, we specfed a mnmum rate, sze, and resoluton of one mage every four seconds, 360x240, and 24 bts per pxel, respectvely. Tlng s also possble n ths mode for the UCAV,.e., breakng down a large magery nto smaller ones and sendng them n several steps. The tradeoff order for BDA magery s {rate, sze, tlng}. 3.2 Observable Parameters Ths s the part of the model n whch we specfy what can be measured at runtme to help calculate the current QoS, choose the proper behavor to nvoke, and then to subsequently measure the effectveness of the adaptaton. These nclude Msson attrbutes to measure nclude msson mode, allocated bandwdth, and allocated CPU. The physcal attrbutes of each UAV to measure nclude speed; scan sze (whch mght nclude alttude); and frame rate, mage sze, and resoluton of the UAV camera. Run tme data attrbutes nclude actual frame rate, mage sze (both n pxels and n bytes), and resoluton. Resource attrbutes to measure at runtme nclude bandwdth capacty, bandwdth used, CPU avalable, CPU used, Dffserv Code Pont values, CPU prortes, and CPU reservatons (requested and acheved). The cruse speed of the Predator RUAV. The actual scan sze s based upon the camera specfcatons and the alttude of the RUAV at mage capture. 4

5 Attrbutes of the adaptaton strateges that can be measured nclude compresson level, CPU usage of compresson routnes, data sze reducton due to compresson, and number of tles. 3.3 Controllable Parameters and Adaptaton Behavors We have wrapped a number of controllable QoS mechansms and other adaptve behavors as QuO qoskets that can be confgured and assembled nto the applcaton at varous places for end-to-end QoS. Each of these s represented n the model as a component and hooked to the applcaton components, system resources, and other qosket components that t affects or wth whch t nteracts. The followng s a partal lst of those we are usng n the PCES OEP: Network prortes usng Dffserv codeponts CPU prortes, RT CORBA prortes, and CPU Reservatons (usng Unversty of Utah s CPU Broker) Image compresson usng several compresson algorthms, ncludng lossy and lossless. Image scalng, croppng, and tlng. Pacng (changng rate) 3.4 System Dynamcs The system dynamcs part of the model s one of the most mportant, and can also be one of the most dffcult to capture. It requres an analytcal or expermental understandng of the ways n whch the adaptaton behavors can affect the observable parameters. Intutvely, we can capture some of the basc system dynamcs as follows: Invokng compresson wll reduce the amount of bandwdth used but wll ncrease the CPU usage (for compresson and for decompresson) Scalng and croppng wll reduce the amount of bandwdth used and should ncrease CPU usage very lttle. Scalng wll decrease mage resoluton and croppng wll decrease the effectve scan sze. Lossless compresson wll not decrease mage resoluton, but lossy compresson wll. Lossy compresson should get a hgher compresson rato or take less CPU, n order to have any beneft over lossless compresson. The exact factors by whch these behavors affect the observable parameters can vary by behavor, mage content and type, and due to other factors. There are two approaches that we can take to modelng the system dynamcs and usng them for the runtme adaptaton. The frst s to capture only the basc system dynamc relatonshp (e.g., whether an adaptaton ncreases or decreases bandwdth usage) and develop a reactve adaptaton strategy that chooses (or guesses) an adaptaton to nvoke and montors the change to the system, reactvely changng or adjustng the adaptaton to mprove the performance. Snce our applcaton requres real-tme behavor and our requrements are msson crtcal ones, we employ a second approach to developng our system dynamcs. We plan to conduct a seres of experments usng magery gathered from the RUAV and UCAV cameras to determne the affect of the varous compresson and mage manpulaton behavors we have. We wll use the results of these experments to choose the factors of the system dynamc formulas, add n a lttle wggle room, and supplement ths at runtme wth an adaptaton engne that wll make mnor adjustments to handle slght range volatons. Whle these system dynamcs are crtcal for our adaptaton strateges, there are other mportant ones for ths applcaton that we can more fully represent, such as the followng: total_bw_used (bps) = sze_of_ruav_magery (bps) + sze_of_ucav_magery (bps) + sze_of_control_traffc (bps) (1) end2end_latency processng(n ) + = transmt(e ) (2) where processng(n) s the tme spent processng for a stream on node n and transmt(e) s the tme to send an mage across lnk e for a gven stream. 3.5 Adaptaton Strateges In all modes, approxmately 10% of the network bandwdth and CPU processng wll be set asde for control traffc (.e., the pushng of polcy, msson mode changes, poston updates, and other command and control traffc). The resource manager at the CAOC wll allocate a specfc amount of bandwdth and CPU to each RUAV and UCAV based on the system dynamcs dscussed n secton 3.4. In Mode A, all RUAVs wll evenly dvde all the remanng avalable bandwdth and CPU. In mode B and C, the prvleged RUAV and the UCAV wll be allocated a hgher amount of bandwdth and CPU and all other non-prvleged RUAVs wll evenly dvde the remanng resources as n Mode A. Each non-prvleged RUAV wll use a local adaptaton strategy to select a frame rate, mage sze, and compresson functon such that the followng constrant s satsfed: 5

6 used_bw(u ) allocated_bw(u ) used_cpu(u ) allocated_cpu(u ) (3) We can model the RUAV adaptaton strategy n two ways. Frst, we could tradeoff the rate, sze, and compresson level equally n steps (n round robn fashon n the order specfed by the msson requrements) untl the constrant s met. Alternatvely, the strategy can reduce the rate untl the constrant s satsfed or the mnmum s reached, followed by the mage sze untl the constrant s met or the mnmum s reached, and then the compresson. The prvleged RUAV and UCAV adaptaton strateges wll set ther Dffserv codeponts to prvleged class and request suffcent CPU reservatons. The prvleged RUAV adaptaton strategy wll then reduce the magery rate, followed by nvokng lossless compresson, followed by mage croppng, each untl the mnmum or untl the constrant n (3) s met. The UCAV adaptaton strategy wll select a fxed rate for the BDA magery (probably one frame every four seconds) and nvoke lossless compresson, followed by tlng of the magery untl the constrant n (3) s satsfed. 4 Conclusons We have developed the DQME modelng envronment, based on GME and QuO, for desgnng the QoS adaptaton necessary for DRE applcatons. As part of a capstone demonstraton for the DARPA PCES program, we are evaluatng DQME s sutablty to model representatve DRE systems by modelng the end-to-end QoS adaptaton for a mult-uav survellance and target trackng applcaton. Ths work s ongong and s not wthout sgnfcant challenges, but shows promse for facltatng the desgn and top-down constructon of DRE applcatons, even whle applcaton to the PCES OEP shows promse for helpng us to mature and evaluate the usefulness of DQME. References [1] Ledecz A. GME 4 Users Manual (v4.0), Web Ste: [2] Ledecz, A., Marot, M., Bakay, A., Karsa, G., Garrett, J., Thomason, C., Nordstrom, G., Sprnkle, J., and Volgyes., P. The Generc Modelng Envronment. WISP'2001, Budapest, Hungary, May [3] Ledecz, A., Bakay, A., Marot, M., Volgyse, P., Nordstrom, G., Sprnkle, J., and Karsa, G. Composng Doman-Specfc Desgn Envronments. IEEE Computer, 34,11(Nov. 2001), [4] Loyall, J., Schantz, R., Znky, J., and Bakken, D. Specfyng and Measurng Qualty of Servce n Dstrbuted Object Systems. In Proceedngs of The 1st IEEE Internatonal Symposum on Object-orented Real-tme dstrbuted Computng (ISORC 98), Aprl 20-22, 1998, [5] Loyall, J., Schantz, R., Znky, J., Pal, P., Shapro, R., Rodrgues, C., Atghetch, M., Karr, D., Gossett, J.M., and Gll, C.D. Comparng and Contrastng Adaptve Mddleware Support n Wde-Area and Embedded Dstrbuted Object Applcatons. In Proceedngs of the 21st IEEE Internatonal Conference on Dstrbuted Computng Systems (ICDCS-21), Aprl 16-19, 2001, [6] Loyall, J., Shapro, R., Neema, S., Abdelwahed, S., Schantz, R., and Mahadevan, N. Model-Based Desgn of Runtme Adaptaton Strateges. RTAS 2003 Workshop on Model-Drven Embedded Systems (RTAS MoDES), Tuesday May 27, 2003 at RTAS 2003 Washngton, DC, May 27-30, [7] Object Management Group. Common Object Request Broker Archtecture (CORBA): Core Specfcaton.. OMG Document formal/ , March [8] Schantz, R., Loyall, J., Atghetch, M., and Pal, P. Packagng Qualty of Servce Control Behavors for Reuse. In Proceedngs of the 5th IEEE Internatonal Symposum on Object-Orented dstrbuted Computng (ISORC 02), Aprl 29-May [9] Schantz, R. E., Loyall, J., Rodrgues, C., Schmdt, D.C., Krshnamurthy, Y., and Pyaral, I. Flexble and Adaptve QoS Control for Dstrbuted Real-tme and Embedded Mddleware. The ACM/IFIP/USENIX Internatonal Mddleware Conference, June 2003, Ro de Janero, Brazl. [10] Sztpanovts, J. and Karsa, G., Model-ntegrated computng. Computer 30, 4(Aprl, 1998), [11] Tha, T. and Lam, H..Net Framework Essentals. O Relly, Cambrdge, MA [12] Wang, N., Schmdt, D.C., Gokhale, A., Gll, D., Natarajan, B., Rodrgues, C., Loyall, J.P., and Schantz, R.E. Total Qualty of Servce Provsonng n Mddleware and Applcatons. The Journal of Mcroprocessors and Mcrosystems, Elsever, 26, 9-10, (Jan 2003). [13] Wollrath, R.R. and Waldo, J. A Dstrbuted Object Model for the Java system. USENIX Computng Systems 9,4(Fall 1996). [14] Ye, J., Loyall, J., Shapro, R., Neema, S., Mahadevan, N., Abdelwahed, S., Koets, M., and Varner, D. A Model-Based Approach to Desgnng QoS Adaptve Applcatons Submtted for publcaton. [15] Znky, J., Bakken, D., and Schantz, R. Archtectural Support for Qualty of Servce for CORBA Objects. Theory and Practce of Object Systems 3(1)