Research and Contributions in Energy- Efficiency and Context-Awareness of Mobile Systems and Applications

Transcription

1 Research and Contrbutons n Energy- Effcency and Context-Awareness of Tmsoara, 016

2

3 Research and Contrbutons n Energy-Effcency and Context-Awareness of CONTENTS 1 Scentfc and academc results Introducton and felds of expertse Overvew on the man scentfc achevements Power aware moble applcatons Energy proflng of vrtualzaton soluton Devce and executon characterzaton usng power sgnatures Wreless postonng of moble devces Component level power characterzaton of embedded systems usng FPGA desgns Runtme Thread Level Energy Accountng Overvew on academc and educatonal results Overvew on nnovaton and economc mpact Executon framework for power aware applcatons on battery powered devces Overall descrpton and research objectves Theoretcal concepts Framework desgn and mplementaton prototype Component proflng Physcal measurements Power benchmarks Power effcency metrcs Expermental results Moble voce communcaton Wreless data communcaton CPU ntensve processng Energy aware vdeo player Related work Supportng grants, research team and scentfc outcomes Conclusons and future work Energy proflng of vrtualzaton solutons Overall descrpton and research objectves Theoretcal concepts

4 3.3 Measurement test bench Expermental results Idle state physcal system and vrtual machnes power consumpton CPU and memory workload vrtual machnes power consumpton I/O workload vrtual machnes power consumpton Related work Supportng grants, research team and scentfc outcomes Conclusons and future work Usng power sgnatures n electrc devces characterzaton Overall descrpton and research objectves Theoretcal consderatons Measurement nfrastructure test bench Expermental results Devce under analyss Power sgnature analyss Ideal power sgnature Power Factor Sgnature Analyss Sgnal segmentaton Regresson functon for sgnal components Calculaton of correlaton ndces between two components Correlaton analyss. Determnng smlarty and anomaly detecton Synthetc analyze on components Related work Supportng grants, research team and scentfc outcomes Conclusons and future work Indoor postonng systems and context aware moble applcatons Overall descrpton and research objectves Theoretcal consderatons Method Method Expermental results Wreless transmtter devce types Wreless recever devce types

5 Research and Contrbutons n Energy-Effcency and Context-Awareness of Envronmental factors Dstance estmaton Related work Supportng grants, research team and scentfc outcomes Conclusons and future work Drect FPGA based energy proflng of embedded components Overall descrpton and research objectves FPGA based energy proflng methodology Measurement setup Measurement achevement Hardware Energy Proflng Test Benches Software Energy Proflng Test Benches System Level Energy Proflng Benchmarks Expermental results Related work Supportng grants, research team and scentfc outcomes Conclusons and future work Low Cost Hardware Infrastructure for Runtme Thread Level Energy Accountng Overall descrpton and research objectves Per thread energy accountng Hardware nfrastructure Implementaton use-case Expermental results Related work Supportng grants, research team and scentfc outcomes Conclusons and future work Scentfc and Academc Development Plan References Relevant publshed papers Related work papers

6 1 SCIENTIFIC AND ACADEMIC RESULTS 1.1 INTRODUCTION AND FIELDS OF EXPERTISE Ths habltaton thess summarzes the achevements I have obtaned snce when I receved the PhD scentfc ttle of Poltehnca Unversty of Tmsoara back n 005, n the feld of Computer and Informaton Technology, wth the thess Cercetăr prvnd fenomenele termce la plăcle cu crcute ntegrate folosnd magnle termografce ş senzor de temperatură. I am currently an Assocate Professor PhD Engneer at Department of Computer and Software Engneerng, Faculty of Automaton and Computers, Poltehnca Unversty of Tmsoara ( For almost 0 years of ddactc, scentfc and research actvtes, I have addressed and worked n several felds of nterests, ganng both theoretcal and practcal strong experence, as follows: Power and Energy Measurement, Modelng, Optmzaton and Low Power Desgn of Embedded Systems Dynamc Thermal, Power and Energy Management of Computng Systems Mcroprocessor Systems Desgn and Mcroprocessor Archtectures Computer Networks and Wreless Communcaton Moble Computng, Systems and Applcatons Low Level Software and Drvers Development In these felds of expertse, I have publshed over 70 scentfc and academc works as sngle author (9), frst author (34) or co author: 1 PhD thess and PhD reports; 3 books and 3 books chapters; 6 onlne course and laboratory support materals and 1 prnted laboratory workbook; 14 scentfc papers n journals ndexed by recognzed databases; 53 scentfc papers n proceedngs of nternatonal and natonal conferences ndexed by recognzed databases; publshed natonal patent requests and 1 nternatonal patent request. Snce 005 I have been actvely nvolved n 13 nternatonal and natonal projects granted by competton, as drector or prncpal nvestgator (), local partner responsble () and team member. I have been also nvolved n 8 research and development projects wth the local ndustry as drector (4) and team member. 7 nternatonal grants ( as local partner manager); 6 natonal grants ( as prncpal nvestgator); 8 contracts wth ndustry (Alcatel Lucent). 6

7 Research and Contrbutons n Energy-Effcency and Context-Awareness of Snce 1995, I worked together wth Prof. Mrcea POPA to develop the mcroprocessors laboratory that evolved n tme nto Research Laboratory on Mobl Computng, Sensor Networks and Embedded Systems (CMRSSI Our research objectves are: Research n the areas of moble computng, smart sensors, sensor networks and embedded systems; development of scentfc and ndustral applcatons. Developng partnershps wth academa and ndustry at a local, natonal and European level. Contnue to ncrease the laboratory's vsblty through scentfc publcatons, patents and creaton of new products. The strategy we use to acheve the proposed objectves are: Attractng research fundng based on natonal and nternatonal compettons. Focus the scentfc research on domans and subdomans wth a maxmum potental by takng nto account the actual areas of nterest of the laboratory members. Orentaton on appled research and development talored to ndustry needs n the area, ncreasng collaboraton wth research groups and development companes. Integratng laboratory research n the European Research Area. Identfyng and establshng new relatonshps wth specalzed research groups wthn unverstes from the European Unon and beyond. Provde teachng support, courses and specfc teachng materal. Creaton of specalsts n these areas by contrbutng to teachng and student nvolvement at all levels, bachelor, master and doctoral programs n research Snce 1995 I ntroduced and developed several courses and laboratores: Mcroprocessor systems (developed course and laboratory) Devce drvers development (new course and laboratory) Moble systems and applcatons (new course and laboratory) Computer networks admnstraton (new course and laboratory) Snce 006 I supervsed and traned UPT teams for Imagne Cup Internatonal student competton. In 009 and 010 UPT teams won the natonal Embedded Development secton, beng selected for fnal worldwde competton where we reached the Top 15, respectvely Top 6 teams worldwde, out of 300 other teams. In 01 we won the natonal Software Desgn secton, reachng the Top 0 teams worldwde. 7

8 1. OVERVIEW ON THE MAIN SCIENTIFIC ACHIEVEMENTS 1..1 Power-aware moble applcatons Power aware and energy aware moble applcatons analyss, modelng and development research work s part of the Dynamc Power and Energy Management of Computng Systems feld of expertse. I started ths research work rght after I fnalzed the PhD wth the nnovatve dea at that tme of nvolvng hgh level applcatons n dynamc power management technques. Ths research drecton has been supported by two natonal grants I have managed between 006 and 011. The most recent one has been a Natonal R&D Fundng Grant (PNCDII IDEAS), called Open Executon Framework for Low Consumpton Battery Powered Moble Devces and t had been developed durng three years: The projects have been ntally granted wth more than 00k EURO, but due to the crss n 008 the budged cuts reached almost 50% of the budget ntally approved. The man outcome of ths research s an Executon Framework for Power Aware Applcatons on Battery Powered Moble Devces. Ths research topc converged n recent years nto cross layer power and energy management technques. Power aware applcatons are software applcatons that mplement applcaton specfc power management algorthms n order to reduce and optmze the energy consumpton of the system whle runnng them. The man goal of ths research effort was to promote power consumpton management and optmzaton of moble and embedded systems at hgher abstracton layers of such systems. The man outcome of these projects was to establsh a general theoretcal background and applcatve rules and patterns n order to obtan effcent moble systems and applcatons from the pont of vew of the consumpton. Durng the last years there had been a lot of research effort n power and thermal management at dfferent abstracton levels of the system such as hardware, drvers and operatng system (OS). However, my dea has been to focus on a dfferent drecton: the hgher abstracton levels of the system the user applcatons, due to lmted energy effcency gan acheved by the lower layers of a computng system. Power management, when mplemented at the hghest levels, leads to a much more effcent power savng than when used n the lower system layers. Stll, the large majorty of lterature deal at that moment wth the physcal (hardware) and operatng system levels. Therefore, the research goal has been modelng, montorng and controllng of software applcatons power consumpton for dfferent types of hardware platforms. The results acheved so far n ths research drecton are both theoretcal and applcatve: 1. Defnton, mplementaton and valdaton of two new types of benchmarks: power benchmark and thermal benchmark. Frst of all, there was a lack of a runtme method whch can be used to evaluate energy effcency of software applcatons or varous algorthms mplementatons executed on dfferent hardware systems. Therefore, I ntroduced and defned the new concept of power thermal benchmarks software as a software applcaton used for run tme system level energy characterzaton. Ths concept has been frst ntroduced n 006 and has been further refned n Proposal of a hgh level model for software applcatons power consumpton based on montorng, proflng and estmaton. For the second step, the modelng, nstrumentaton and 8

9 Research and Contrbutons n Energy-Effcency and Context-Awareness of energy consumpton estmaton for the user applcatons and ther mpact on the overall system energy consumpton have been addressed. A method to estmate energy consumpton of software applcaton has been proposed. The power consumpton modelng problem of computng systems s n general a very complex one because each physcal component from the system has ts own energy consumpton whch vares wth the workload executed by the component. Therefore together wth the physcal components, the software applcatons have a bg nfluence on the system s energy consumpton. To overcome these lmtatons, I proposed the decomposton of the whole system n components. The energy consumpton of the applcaton has been computed based on estmated for these components. Thus, I proposed a general model based on the system decomposton nto hardware and software components that can be montored, nstrumented and evaluated separately. 3. Power characterzaton experments on several hardware components or algorthms: CPU mult core and mult threadng, WLAN communcaton, multmeda algorthms, and I/O dsk operatons. The next step has been to run multple experments for energy proflng of varous hardware components n a moble devce and of dfferent algorthms mplementatons. These experments provde a large database of energy consumpton profles of varous nterfaces, components, algorthms and devces. 4. Development of an executon framework for power aware software applcatons. In order to mplement power aware applcaton, I proposed and successfully mplemented a power effcency framework whch addresses some of the shortcomngs of exstng approaches towards power aware software. The framework archtecture and ts theoretcal model n the next secton. 1.. Energy proflng of vrtualzaton soluton Vrtualzaton s one of the man research drectons for both large scale data centers and servers. Eenergy effcency has become an mportant aspect n data centers and large server systems. Our research effort explores how vrtualzaton nfluences the power consumpton of both physcal systems and vrtual systems and whch s the most effcent way to mplement such applcatons. The man goal of ths work has been the study on the power consumpton mpact of vrtualzaton solutons for common desktop and laptop computers. Ths work explored how vrtualzaton nfluences the power consumpton of both physcal systems and vrtual systems and whch s the most effcent way to mplement such applcatons. The man contrbuton to the project s the study on energy and thermal effcency of vrtualzaton solutons mplemented on the two OS used today: Wndows and Lnux. In order to acheve ths result the evaluaton methodology and measurement setup have been proposed and mplemented Devce and executon characterzaton usng power sgnatures Usng smart grd for developng ntellgent applcatons s a current trend of great mportance. One advantage les n the possblty of drect montorng of all devces connected to the electrcal network n order to prevent possble malfunctons and manage (optmze) the overall power consumpton n offce or resdental buldngs. In our work we am to montor domestc devces n order to automatcally extract ther workload power profles n order to dentfy bad usage habts, 9

10 external condtons or agng and fnally falures of these devces. The man goal s to detect and model the nfluence of the dentfed elements on the energy effcency of the devces. In our approach we montor the target devces n order to extract power consumpton profles of dfferent applcatons, workload, external condtons or usage patterns. Next we apply pattern recognton algorthms to extract relevant behavor or patterns n the power consumpton seres of measurements. We call the dentfed patterns n the power profles, power sgnatures. Based on these sgnatures we further try to count devce specfc usage parameters and to dentfy abnormal behavor of the devce due to agng or malfunctonng. The fnal goal of our work s to propose an ntellgent house level centralzed soluton to montor, analyze, predct and control household devces n order to mprove ther lfe tme usage energy effcency. There are several contrbutons clamed by our work: An ntellgent power meterng nfrastructure deployed as a wreless sensors network for energy montorng, analyzng, controllng and predctng of electrc, electronc and computng devces; Defnton, mplementaton and valdaton of the concept of power sgnature appled to runtme operaton of home applances and computer devces; A database storng power sgnatures of many knds of devces, such as refrgerator, freezer, washng machne, bread cookng machne, TV set, DVD player, and desktop computers; A method usng dgtal processng and pattern matchng technques for characterzng the functonal parameters of the components, user operaton modes and patterns, system agng or falures Wreless postonng of moble devces Locaton aware moble applcatons s part of Moble Computng, Systems and Applcatons feld of expertse. The man research objectve of ths research topc represents the possblty to use the wreless network nfrastructure (.e. networks adapter, access ponts, and wreless routers) to determnate ndoor poston of a moble system, whle usng the same nfrastructure for the wreless communcaton. Ths research work has been performed between 007 and 009, but a revval of the topc happened after 010, along wth the spread of smart devces and context aware applcatons. We dd not receved any foundng to perform ths actvty. Ths research topc converged to context aware servces development for moble users. Indoor postonng s an mportant aspect of moble applcatons n order to develop context aware applcatons. The man goal for localzaton process s estmatng the poston of a moble devce n ts ndoor and outdoor envronment based on a set of sensors wth known postons. Modern smart moble devces have one or more wreless communcaton nterfaces, lke Bluetooth or WF, n order to communcate wth nfrastructure computng systems or other moble devces. WLAN nfrastructure s a wdely accepted and mplemented communcaton standard n many ndoor envronment, therefore many buldngs are already equpped wth latest IEEE WLAN nfrastructure access ponts. Wreless adapters the modern moble devces are equpped wth can montor rado power strength of the emttng sources nearby. Based on the receved rado sgnal strength an estmaton of dstance between the devce and power source can be computed. If a 10

11 Research and Contrbutons n Energy-Effcency and Context-Awareness of moble devce can montor at least three WLAN power sgnal sources wth a pror known postons, an estmaton of the moble devce poston can be acheved. Ths approach has the advantage that no costly hardware nstallatons are necessary nsde the buldng, nor addtonal sensors to be attached wth the moble devces. The results acheved untl now are both theoretcal and applcatve: Proposal of a theoretcal mathematc model for poston estmaton of a wreless recever based on the receved rado sgnal strength (RSSI) from several access ponts wth known postons and usng trlateraton. Proposal and valdaton of an extended range of test cases used to evaluate local postonng system deployments. A complete set of test cases that can be used to evaluate a wreless postonng system (WPS) has been proposed. A lot of experments have been performed n order to buld a rado sgnal strength database. Analyzng the RSSI data, a set of problems that can make such a WPS system neffectve for hgh accuracy localzaton has been dscussed. Development of software module for estmatng the postons based on the rado parameters. Based on the proposed model and the test executon results a WPS has been mplemented and t can be used to provde locaton specfc servces for moble applcatons. An accuracy of 3 meters has been obtaned wth current mplementaton Component level power characterzaton of embedded systems usng FPGA desgns Power and energy proflng of mult core embedded SoC desgns s a dauntng task due to the lack of fne gran accurate and hgh samplng rate montorng nfrastructures. Furthermore, shared components used n common by multple processng cores, make SoC desgns dffcult to analyze the thread level energy consumpton. The man goal of our work s to perform both hardware and software accurate proflng of any mult core archtecture usng low level profles of ts components, such as CPU cores, memores, and buses. Therefore, n ths secton, we nvestgate the capacty of FPGA desgns to profle the power consumpton and energy usage of mult core embedded archtectures and applcaton benchmarks runnng on them. The man outcomes of ths research drecton are: Implementaton and valdaton of a mult core target desgn used to montor per component and per thread energy consumpton. The system s heterogeneous and ncludes two ARM cores and 8 Mcroblaze cores Introducton of a montorng methodology for fne gran and hgh samplng rate energy measurement, valdate by measurements and smulatons Energy proflng of FPGA core, BRAM memory, DRAM memory, CPU cores, and AXI bus 1..6 Runtme Thread Level Energy Accountng The ever growng need for energy effcent computaton requres adequate support for energyaware thread schedulng that offers nsght nto a systems behavor for mproved applcaton 11

12 energy/performance optmzatons. Runtme accurate montorng of energy consumed by every component of a mult core embedded system s an mportant feature to be consdered for future desgns. Although, mportant steps have been made n ths drecton, the problem of dstrbutng energy consumpton among threads executed on dfferent cores for shared components remans an ongong struggle. We am at desgnng a generc low cost and energy effcent hardware nfrastructure whch supports thread level energy consumpton montorng of hardware components n a mult core system. The proposed nfrastructure provdes upper layers (operatng system and applcaton threads) wth per thread and per component energy accountng API (Applcaton Programmng Interface), smlar wth performance proflng functons. Implementaton results ndcate that the proposed LEM (Load and Energy Montor) adds around 10% resource overhead to the montored system. Regardng the power estmates, the one derved by LEM acheve a correlaton degree of more than 95% wth the ones obtaned from physcal power measurements. The contrbutons of ths work are as follows: hardware nfrastructure for dynamc energy consumpton montorng n a heterogeneous mult core system wth per thread energy accountng; energy nterrupt specfcaton and desgn; a use case on the software sde (OS and drvers) for run tme per thread energy accountng mplementaton on FPGA; and valdaton of proposed nfrastructure on a hgh end FPGA board wth physcal energy measurements. 1.3 OVERVIEW ON ACADEMIC AND EDUCATIONAL RESULTS Snce 1995 I ntroduced and developed several courses and laboratores: Mcroprocessor systems (developed course and laboratory) Devce drvers development (new course and laboratory) Moble systems and applcatons (new course and laboratory) Computer networks admnstraton (new course and laboratory) Snce 006 I supervsed and traned UPT teams for Imagne Cup Internatonal student competton. In 009 and 010 UPT teams won the natonal Embedded Development secton, beng selected for fnal worldwde competton where we reached the Top 15, respectvely Top 6 teams worldwde, out of 300 other teams. In 01 we won the natonal Software Desgn secton, reachng the Top 0 teams worldwde. Each year I supervsed students for ther dploma or master projects. In these collaboratons I focus on both techncal qualty and applcablty of the results. 1

13 Research and Contrbutons n Energy-Effcency and Context-Awareness of 1.4 OVERVIEW ON INNOVATION AND ECONOMIC IMPACT In my projects I constantly try to focus on the appled results and nnovaton. I am lookng also at the economc mpact or the research outcomes. As a result of these nterests, n 01, together wth a company n Tmsoara (Lastng System) and one of my former students we founded a startup (Intutve Software SRL) based on the results acheved durng the collaboraton on dploma and master projects. Our startup was granted wth EURO from POS CCE Structural Founds. The man goal of the product we targeted s an nnovatve context aware communcaton manager. In the last years there s a mergng trend towards unfed communcaton systems over IP protocols from desktop to moble devces. Nowadays users have the possblty to choose from a wde range of methods of communcatons (voce, text, vdeo, socal networks) and equpment (mobles, SIP phones, computers). Ths varety leads to a seres of problems lke the management, synchronzaton, updatng and sharng of contacts between varous platforms or choosng the most effcent mean of communcaton from a cost and qualty perspectve. In ths context the current project has as man goal to propose an ntellgent software platform for assstng users of multple communcaton technologes (moble, IP phone, emal, socal, and messenger) and fndng the most effcent method of communcaton takng nto account the avalable communcaton channels and the caller and recever s context. The term of context, nowadays largely dscussed n moble applcatons developers communty, s any nformaton that can be used to characterze the stuaton of an entty. The aspects of context that shall be taken nto account when proposng a communcaton channel are: locaton, people and devces nearby and changes n the prevous aspects. Therefore, the proposed applcaton wll allow the management of avalable communcaton channels along wth the contacts n order to optmze the proposal of the most effcent communcaton method from the qualty and cost perspectve usng both caller and callee contexts. The expected results of the project are: (1) a model for characterzng qualty level of communcaton usng context nformaton, () an algorthm for selectng the optmum communcaton channel usng machne learnng and data mnng and (3) a prototype of the proposed platform. 13

14 EXECUTION FRAMEWORK FOR POWER-AWARE APPLICATIONS ON BATTERY POWERED DEVICES.1 OVERALL DESCRIPTION AND RESEARCH OBJECTIVES Moble wreless devces contnue ther fast sezure of our daly lves as they become smarter, powerful and faster. However, the new features bult n these devces come wth an ncrease of resources usage and energy consumpton. Therefore, prolongng the battery lfetme of moble devces was one of the man research topcs n moble computng durng the last decade. Dfferent power management strateges have been proposed and mplemented durng the last years n order to reduce the power consumpton of the battery powered devces. These strateges can be mplemented at dfferent levels of the computng system: physcal or hardware level, operatng system level, applcaton level and user level. Applcaton level energy effcency mechansms are consdered the next mportant step n the evoluton of hghly power and energy effcent moble systems. The fnal user s also an mportant element to be ntroduced wthn the energy effcency and management cycle. However the normal user lacks the basc understandng of the low level power management mechansms, even though he s the most able to choose how to consume the remanng energy wthn the battery. Therefore power management technques should propagate to hgher levels of the system, more specfcally to the user applcatons level. The man goal of ths research work was to defne, mplement and valdate a software executon framework for moble systems (smartphones, tablets and notebooks) n order to reduce and optmze dynamcally the energy consumpton at the applcaton level. The role of the framework s to provde a generc nterface for user applcatons such that they can obtan an estmaton of ther own energy consumpton and next they should be able to adapt ther executon n order to acheve an optmum energy consumpton level. Applcatons that are gong to use the executon framework n order to optmze ther energy demands are called power aware applcatons. The roles of the power aware applcaton models are frst to make the applcatons aware of ther own power consumpton and to adapt themselves to reduce consumed power and second to promote and translate system s power management states and actons to the user n a user frendly way. Ths way the hgher level applcatons make the users aware of applcaton specfc energy consumpton aspects and allow users to actvely nteract wth power management mechansms n a much more effectve and nformed way.. THEORETICAL CONCEPTS In ths secton we ntroduce the core concepts, whch are used by the framework. We start by ntroducng theoretcal concepts of power sources or power stmul and responses for dfferent real components as well as measurement and framework specfc notons. Next, the dfferent ways we tred to obtan the best soluton proposal are dscussed together wth the advantages and dsadvantages of the evaluated solutons. 14

15 Research and Contrbutons n Energy-Effcency and Context-Awareness of We defne a computng system S as a number of hardware components (C1 Cn) together wth the runnng software applcatons (A1 Am) usng these components (Eq. 1). Every applcaton nvolves several hardware components n fnalzng ts tasks n order to provde the servces the applcaton s executed for. S A C (Eq. 1) 1.. m j1.. n j The operator specfes the usage relaton between applcatons and system components. In fact the relaton descrbes how each component s used by a runnng applcaton (Fg. 1). Fg. 1 General system abstracton In the context of the power effcency framework, we address dfferent power consumpton sources, correspondng to the dfferent components of the system (C1 Cn). Every component Cj mplements a number of power states (Sj,k), that are actvated accordng to the performance requrements of the applcatons usng t (Eq. ). Every power state of a component has assocated a certan power consumpton level (PSj,k). Ths level s consdered to be known based on component s datasheets or t can be computed or estmated based on specfc formula or by physcal measurements (Mj,l). S j Sj, 1, Sj,,..., Sj, Ns j (Eq. ) Power consumpton model of component Cj resdng n state Sk s characterzed by the workload performed by Cj. It can be estmated by the set of measurable parameters Mj,l (Eq. 3). P S f, M, M,..., M, j, k j k j,1 j, j Nm (Eq. 3) j Durng ts executon every applcaton (A) uses some components n certan power states or n a certan sequence of power states (Eq. 4). We consder Sj,k the component Cj workng n power state Sk. A component could be placed only n one power state at a tme, no matter how many applcatons are usng t. We defne power consumpton of a software applcaton to be the sum of power consumpton levels of components used by the applcaton (Eq. 5). Consderng that only one applcaton s runnng on the system and each component s runnng n only one power state, 15

16 power consumpton of one applcaton A s the sum of power levels assocated wth the used components power states (Eq. 5). A C S S (Eq. 4) j j, k j, k j1.. n, k1.. Ns j j1.. n, k{1.. Ns j } j1.. n P P P (Eq. 5) A C j S j, k j1.. n, k{1.. Ns j } Power consumpton of system components and software applcatons s not constant n tme and depends on workload varatons that occur durng the executon (Eq. 6) A ( t) S ( t) (Eq. 6) j1.. n j where Sj(t) means the power state of the component Cj s at the tme t and Sj,k represents dscrete power levels. As tme passes the component swtches between these states: S j ( t) S j, k k{1.. Ns j } (Eq. 7) For each power consumpton source we can establsh dfferent power profles (or power fngerprnts) that represent the varaton of power consumpton of the component for a gven utlzaton profle (e.g. appled stmul). Every power profle s dentfed by a sequence of power consumpton values correspondng to component s executon power states assocated to the current workload. A component usage model assumes a certan workload usage level and operaton for that component. Power consumpton of an applcaton A vares n tme and could be computed summng the power levels of the components used by the applcaton n every moment n tme (Eq. 8) j1.. n P ( t) P ( t) P ( t) (Eq. 8) A C j S j j1.. n, S j ( t) S j, k k{1.. Ns j } where (t) s the power consumpton of the system due to the runnng applcaton A at the PA moment t. Consderng that a component could be used by more than one applcaton at a tme or a component s not used by an applcaton, we ntroduce n equaton (Eq. 8) a weght factor (W,j) that specfes the level a component (Cj) s used by an applcaton (A) at the moment t (Eq. 9): P ( t) ( W ( t) P ( t)) (Eq. 9) A, j j1.. n, S j ( t) S j, k k{1.. Ns j } S j In terms of energy, the energy needed by an applcaton A to complete ts tasks can be computed usng (Eq. 10): 16

17 Research and Contrbutons n Energy-Effcency and Context-Awareness of E A t0 P A ( t) t, stop P A tt, start ( t) (Eq. 10) where t,start and t,stop are the tme when the applcaton s started and respectvely the tme when applcaton s fnshed. The power consumpton of the whole system at the tme t can be easly computed by summng the power consumpton of every runnng applcaton n the system ncludng the operatng system servces and applcatons (Eq. 11). Summng the power consumpton of each component we should obtan also the power consumpton of the whole system at the tme t. 1.. m P ( t) P ( t) P ( t) (Eq. 11) S A S j j1.. n, S j ( t ) S j, k k{1.. Ns j } Based on (Eq. 11) we am to assgn the overall system power consumpton frst to the systems components and second to the runnng applcatons. Power consumpton dstrbuton to components and applcatons s further based on the measurements avalable for components (MCj) and applcatons (MA). Consderng that for the most battery powered devces, PS can be measured at system runtme through well defned OS API or battery devce drvers, we am to splt the overall measured power consumpton between the runnng applcatons and estmate the power consumpton of each applcaton (PA). If we can compute and estmate PA from PS then we can estmate the effect of every runnng applcaton on the overall system power consumpton. Based on ths estmaton we can buld software applcatons that are aware of ther own power consumpton and further these applcatons can adapt themselves n order to optmze the overall power consumpton. A poweraware applcaton s an applcaton that mplements applcaton specfc power management algorthms. To dspatch the overall power consumpton values we use the power levels of the components power states assocated wth user applcatons (Eq. 8) and the system and components measurements (Eq. 3) whch wll be further descrbed n ths chapter. P C ( t) PS ( t) fc ( M j j j j, k k P ( t) A ( t), P ( t)) (Eq. 1) j j1.. n, S j ( t) S j, k k{1.. Ns j } k k ( W, ( t) PS ( t)) ( f A, C ( M, j, k ( t), Pk ( t) )) j j1.. n j k k (Eq. 13) Based on (Eq. 1) and (Eq. 13) we nvestgate the possblty to estmate power consumpton of system s components and runnng applcatons based on a number of measurements we can acheve for every component (Mj,k) and applcaton (M,k). Functons fcj and fa,cj are determned n the process of system proflng where the relaton between measurements and power values are establshed. Due to the complexty of these relatons, we focused our research experments n three drectons and try to profle and analyze the CPU and WLAN components and one knd of moble applcaton multmeda applcatons. 17

18 .3 FRAMEWORK DESIGN AND IMPLEMENTATION PROTOTYPE We propose to mplement the power dspatchng functons n a software applcaton, we call power framework, whch provdes a programmng nterface for user applcatons n order to permt them to have knowledge of ther own power consumpton. Therefore we descrbe next the concepts used to defne the power framework module. The power framework (Fg. ) s placed on top of the operatng system servces and drvers. It uses the components devce drvers n order to provde a generc and portable nterface for the applcatons runnng on top of ths framework. User applcatons ether regster themselves n the framework or the framework montors them contnuously so that t can estmate ther power consumpton and provde feedback wth these power values. Fg. Block dagram of the power dspatcher The proposed power framework mplements the theoretcal concepts presented before and some software specfc concepts whch are presented further n ths secton. The general archtecture of the framework applcaton s based on a modular structure grouped n several abstractng layers (Fg. 3). At the lower level the framework applcaton wll use the operatng system s drvers or API functons to access the hardware components consdered n the optmzng process of energy consumpton: the processor, the battery, wreless chpset, man board chpset, the memory etc. The framework should be platform agnostc, so that t can be easly ported on dfferent operatng systems and hardware devces, therefore the framework core access to operatng system and components drvers s realzed through a portng layer. Generc components montors are placed on top of the portng layer so that they provde platform ndependent measurement functons for the framework core to montor all avalable system s components. The components montors mplement a generc nterface n order to permt upper layers to access dfferent types and number of system measurements. The kernel of the executon framework collects all the avalable measures through the montorng drvers and generc components montors, calculates the energy consumpton of the runnng 18

19 Research and Contrbutons n Energy-Effcency and Context-Awareness of applcatons and through the applcaton nterface, t communcates wth regstered user applcatons usng specfc messages for consumpton control. Fg. 3 Power framework abstracton Further n ths secton we dscuss the system parameters that can be used n developng poweraware applcatons or power management framework for such applcatons. We defne as power framework metrcs the set of parameters that may be used by power management strateges and algorthms mplemented to support power aware applcatons. There are two layers of poweraware metrcs (Fg. 4): Component measurements are the prmary values the power framework wll use n order to characterze the current power consumpton of the system. These measures can be obtaned from dfferent sources: battery drver, operatng system, and other devce drvers; Power effcency metrcs are the fnal metrcs computed out of the physcal measurements, whch the power framework wll provde to the applcaton level. These metrcs are descrbng hgh level profles of dfferent system components that may provde an applcaton level or component level mage of the power consumpton. The man goal of the power effcency montorng framework (Fg. 4) s to provde applcatons wth power effcency self montorng servces. It provdes applcatons wth a feedback loop on ther power and energy consumpton n order to allow applcatons to adapt ther algorthms and tasks to ncrease ther energy effcency. The data montorng nterfaces of the framework provde energy effcency measurements based on the framework metrcs. Power effcency measurements can be used to assess the energy effcency of the platform n terms of dfferent workloads that are appled. The feedback loop s desgned n order to mprove the power effcency dynamcally, by enablng applcatons or the operatng systems to take dynamc decsons at runtme based on 19

20 avalable energy. For example, n case of a wreless applcaton, the applcaton mght adjust the download rate or the wreless drver mght adjust the power of the emtted sgnal, or at least announce the user that the download cannot be fnshed n the avalable energy. Fg. 4 Power framework modules and metrcs The man goal of the power effcency montorng framework at system level s to allow applcatons and operatng system or drvers to mprove the both applcatons and system s power and energy effcency. One of the man desgn requrements of the framework has been ts portablty. The framework should be ported on dfferent hardware and OS systems easly and potentally at dfferent layers of the system. For example, t can be placed drectly n the context of the vrtualzaton layer or can be ported on the guest operatng system. Portng the framework at dfferent layers of the overall system s realzed by mplementng a set of abstract nterfaces n terms of functonaltes provded by the layers where portng takes place. In our system, we consder a seres of power consumng components that are accounted as the man hardware power consumers of the system. We nvestgated the followng sx components: CPU, audo, dsplay, WLAN, Bluetooth and the hard drve keepng the fle system. Accordng to ther specfcs, every component s performng dfferent measurements over an abstract montorng nterface. The montorng nterface decouples the power effcency framework to any platform specfcs and thus ncreases ts portablty. The data montorng (or data loggng) nterfaces of the framework provde effcency measurements based on the component measurements ntroduced n prevous chapters, where the 0

21 Research and Contrbutons n Energy-Effcency and Context-Awareness of raw data s collected by a set of platform drvers. Power effcency measurements can be used to assess the energy effcency of the platform n terms of dfferent workloads that are appled. A feedback loop s desgned n order to mprove the power effcency dynamcally, by enablng applcatons or the operatng systems to take dynamc decsons at runtme. For example, n case of a wreless applcaton, the applcaton mght adjust the download rate or the wreless drver mght adjust the power of the emtted sgnal. In case of the CPU adjustments, applcatons mght nsert wat states nto ther algorthm logc or adjust the prorty of the worker threads n order to ncrease power effcency. The mechansm works on the prncple of hgh level metrcs. The basc dea s that the montorng framework defnes a set of hgh level and doman specfc applcaton metrcs where applcatons are regsterng ther executon threads. The framework s nformed by the applcaton whenever a change occurs n the profle confguraton data (e.g. download rate s changng). Based on the regstered metrcs and the avalable system measurements, the montorng framework performs actve montorng and provdes a feedback loop to applcatons or the operatng system. The general system overvew wth the ntegraton of the power effcency framework s depcted n Fg. 5. cmp System Overvew Profle App Power Effcency Framework + Kernel + Montor «thread» Power Effcency Framework::Kernel «thread» Pow er Effcency Framework::Montor OS Montor OS Portng System Portng Layer Component Montor OS CPU WLAN Dsplay Audo Bluetooth Fle System Operatng System and Drvers Hardware 1

22 Fg. 5 Power effcency framework archtecture On the bottom level there s the hardware platform of the system. On top of the hardware platform, there s usually the operatng system together wth platform drvers whch provde the low level functonaltes for all the hardware features. On top of the operatng system and drver layer there s a system portng layer whch glues together the power framework to the runtme executve and drvers. The presence of the portng layer s an effect of requrement that the power effcency framework should be platform ndependent. The portng layer must mplement the requred Montor and OS nterfaces of the framework n order to provde basc operatng system functonaltes such as threads, tmers and memory management. The Montor nterface s the gateway for collectng measurement data. Montorng data comes n terms of the specfcs of each of the supported power components. On top of the system portng layer there s the core of ths work: the power effcency framework component. It has two man components: a kernel and a montor. The kernel provdes all the necessary logc and exposes a generc nterface towards the hgher layers. At the same tme, the montorng nterface abstracts the collecton of measurement data and ther representaton and provdes t to the kernel as necessary. On top of the framework we normally have applcatons whch are standard applcatons whch are runnng on the system. For evaluaton and proflng purposes, we supply a set of proflng applcatons whch am to apply dfferent knds of stmul to the system n order to determne the system characterstcs n terms of power effcency. Proflng determnes a set of relevant system states, whch are determned n solaton (each component s profled n one step). Each state s assocated a power consumpton profle whch s confgured n the system. Ths nformaton s later used by the framework n order to determne dfferent consumpton and effcency predctons. composte structure Montor PowerComponent «thread» Power Effcency Framework:: Kernel - m_benabled: boolean + DsableMeasurement(nt) : vod + EnableMeasurement(nt) : vod + GetMeasurement(nt) : double {query} + onmeasurementchange(nt) : double «use» PowerData + SetData() + GetData() CPU Audo FleSystem WLAN Dsplay Bluetooth CPU Montor Audo Montor Fle System Montor WLAN Montor Dsplay Montor Bluetooth Montor Fg. 6 Power effcency framework montor

23 Research and Contrbutons n Energy-Effcency and Context-Awareness of The detals of the Montor component are shown n Fg. 6. The Montor component runs n ts own executon thread and collects data from dfferent concrete components. Every power component has a set of measurement parameters defned. Power components defne a requred nterface through whch dfferent measurements are collected. These nterfaces are mplemented by the portng layer. The mplementaton of the portng layer defnes f the component s enabled or not n the system, as well as whch measurement parameters are provded by the physcal platform. Both pollng and notfcaton mechansms are supported for data collecton. Upon data recepton, the montorng component stores the data n ts own data store represented by the PowerData component. PowerData storage s not perssted. One mportant aspect s that the translaton between the power effcency framework s data representaton and the one provded by the platform s realzed n the portng layer. The kernel of the power effcency framework runs n the context of an executon thread and s depcted n Fg. 7. The kernel s responsble to provde to the hgher layers power effcency metrcs such as nformaton on power consumpton (average, nstantaneous), power effcency and to provde predctons on remanng power under the trend of the observed workload. The kernel s also responsble for the metrc splt among executon threads and applcatons so that a global pcture of the contrbuton of each applcaton to the global power consumpton s gven. The contrbuton can be also provded per ndvdual component or applcaton per component. The general dea s to construct flexble and meanngful reportng facltes n the kernel. composte structure Kernel Component Model:: Profle App ApplcatonData + RegsterApplcaton(nt, nt) : vod + UnregsterApplcaton(nt, nt) : vod «use» PowerAnalyss + onstartoperaton(nt, nt, nt) : vod + onstopoperaton(nt, nt, nt) : vod «thread» Pow er Effcency Framew ork::montor «use» PowerPredcton ProfleData + GetData() : double {query} «use» Fg. 7 Power effcency framework kernel 3

24 The clent applcatons regster to the kernel va the ApplcatonData nterface. Bascally they specfy ther set of threads and whch components they are nteractng wth. For example, an applcaton mght have a thread whch s recevng audo data from a wreless LAN nterface and decodng the audo stream (n software) and renderng the stream to the audo drver. The ProflngData class s a data store whch s constructed by the proflng applcaton. The kernel provdes a specal mode where t collects montorng data and bulds the repostory. The proflng data are permanently stored on the framework and can be re ntalzed by runnng the system proflng applcaton agan. Profle data s used by the PowerPredcton component to perform predcton on remanng battery capacty or remanng operatonal tme. The kernel supples hgh level metrcs on power effcency through the PowerAnalyss nterface. Ths nterface s also used to sgnal the framework that a gven operaton has been trggered by an executon thread. Ths s especally mportant n cases where the framework cannot make any nferences on the power consumpton splt among executon threads and components. For example, for power consumpton due to audo accesses, all audo accesses to the audo drver need to be nstrumented so that the kernel can buld ther real dstrbuton. If such usage nformaton s not suppled, the power analyss component of the kernel provdes a far splt between executon threads and components. Based on the proposed framework archtecture we mplemented the framework prototype. Durng detaled desgn several tradeoffs and challenges have to be addressed. Here are some of them: we ntended the power framework to be portable over a number of dfferent hardware and OS archtectures, therefore we provded the portng layer n the overall desgn. Intally ths layer was consdered as a thn wrapper for the operatng system and devce drvers servces. But f we consder the sgnfcant dfferences between varous OS APIs and the large number of components, ths layer become qute complex and resource consumng. Here are the solutons to ths problem we consdered: renounce the portng layer and replcate the framework for every target OS; develop the portng layer no matter ts complexty and ts tme response; desgn only the nterfaces for the needed components (battery, CPU, and WLAN); ntroduce the concept of abstract components that wraps the hardware component API and decde for every component f t s mplemented n the portng layer or not. an ncreasng amount of data has been sampled by montorng component durng executon lfetme of the benchmarks. Consderng the lmted memory, storage and processng resources avalable on moble devces specal attenton had to be pad when managng these data: keep all measurement data persstent or only the hgh level metrcs, make use of a lght database for moble systems and select the proper way to analyze montored data. There are dfferent possble solutons to address these problems: use an external database for measurements and extract relevant metrcs usng data mnng technques; use memory structures for selected measurements and extract metrcs usng the proposed model. threadng and synchronzaton at the framework kernel level mples some overhead due to the context swtchng and lockng operatons. There are some possble solutons expose the functons through the portng layer; use drectly the OS API n the framework kernel or do not used dfferent threads n the kernel. We decded to use a small number of threads (two 4

25 Research and Contrbutons n Energy-Effcency and Context-Awareness of threads) wth mnmum lockng sectons and the mplementaton s based on the OS API, not the portng layer. communcaton between framework and user applcatons s another desgn aspect whch needed a desgn decson. There were dfferent solutons nvestgated. Frst, the framework contnuously montors the target processes and threads and take decsons based on that; n ths case there s no communcaton between process and framework. The second soluton s to regster the user power aware applcatons nto the framework usng the avalable nterface and further the applcatons communcate wth the framework usng nter process communcaton. The last soluton makes use agan of regstraton nterface but the communcaton between applcatons and framework s through functon calls. Therefore n the last case the applcatons are to be compled and buld wth the framework. The proposed soluton n Fg. 8 s based on a layered archtecture contanng the user nterface layer (GUI layer), energy effcency logc specfc layer (Proflng layer), component parameters montorng (Montorng layer) and the data acquston layer (Data layer). The bottom layer s runnng on top of the host operatng system (OS) and t provdes a platform ndependent method to access and collect specfc parameters from the underlyng hardware and software components. Data acquston layer uses the specfc APIs provded by OS to read component related measurements whch are further transferred to the upper layer n a unform platform ndependent way. But the mplementaton of data access layer s platform dependent; therefore specfc mplementaton should be developed for every new targeted platform or devce. Ths layer provdes access to read battery, telephony, rado, CPU and memory parameters. Fg. 8 Energy effcency framework layers and modules The mddle layer s platform ndependent and t mplements the energy estmaton logc. These layers contan ntellgent component montors and the energy effcency proflers matchng the power consumpton measurements and workload related phases to estmate the energy consumed by every specfc workload. The montor components store hstorcal data whch are used to calculate energy costs of each workload. On top of the logc layer s placed the user nterface layer whch provdes moble users wth smple access to energy costs of the last workloads and an estmaton of the avalable tme consderng 5

26 the current energy status of the battery and the current runnng workloads. The GUI layer s platform dependent and s desgned to allow development of applcaton specfc GUI components: today screen or normal dalogs. Component montorng soluton shown n Fg. 9 s based on four desgn elements: factores, meters, samples and montors. «nterface» IFactory «nterface» IMeter «nterface» IMontor ComponentFactory ComponentMeter «nterface» Sample * ComponentMontor 1..* SystemFactory ComposteMeter 1..* ComposteSample ComposteMontor 1 «mplementaton class» WnMobleFactory BatteryMeter «mplementaton class» PowerSample «mplementaton class» EnergyMontor «mplementaton class» WnMobleBattery Fg. 9 Energy montor desgn Factory objects are used to dentfy the host system, to detect the target components n the system and fnally to create meter objects for the detected components. Factory objects mplementaton s platform dependent and they generate platform dependent meterng objects. Meter objects are used to provde read access to components n the system or OS to collect components specfc parameters. Meter objects mplementatons are also platform specfc. The meter objects can be used by pollng the components or by lstenng from certan events from the component. Sample objects are platform ndependent and they are used to store the parameters read from a component for a sampled moment of tme. The Sample objects are stamped wth tme nformaton. Battery parameters are stored n the data type PowerSample whch contans: current, voltage, remanng tme, capacty, remanng percentage and temperature. The man problem of measurng and usng parameters of dfferent batteres s that they are not all avalable on every battery drver. The devces we used do not provde current or power consumpton parameters. In ths case we can estmate the consumpton based on remanng lfetme, voltages and remanng percentage. 6

27 Research and Contrbutons n Energy-Effcency and Context-Awareness of The last element type n the montorng desgn s the montor tself. The montors are platform ndependent and they have specfc mplementaton for every type of observed component. The sampled data from the meters are temporary stored n these montors. The montors extract relevant nformaton from hstorcal parameters n order to try to fnd models, to extract patterns or to predct trends. The upper layer contanng aggregaton components collects component specfc metrcs from dfferent montors and computes the applcaton specfc energy effcency values. For example at the aggregaton level, one module can compute the energy consumpton or energy effcency of a specfc workload. Based on these computatons, onlne energy measurement of moble applcatons can be acheved..4 COMPONENT PROFILING Hardware component s power consumpton depends on runtme workload ths component executes whch n turn s specfed by the applcatons runnng by the devce. The overall power consumpton of the whole system s composed of power consumpton of every component. Sometmes reducng power consumpton of one component mply and ncrease n consumpton of other components, therefore the system as a whole should be also consdered n the proposed framework. The power framework s the central part for the runnng applcatons whch have to balance and optmze the applcatons power management decsons n order to obtan overall reducton n power consumpton or energy. Both workload and power profles of a physcal devce are based on two elements: the frst one s the set of power states the devce may have and the second one s the set of dfferent actve usage patterns or workloads avalable for every power state. Every runtme usage pattern for a certan power state has ts own power consumpton level, n other words f a component executes the same operaton n the same condtons t wll consume the same power level. The power profles we defned establsh a relatonshp between power states, workloads and power consumed by the devce or component beng n these states. In our framework we characterze power states havng certan power consumpton levels, n terms of the effects observed on the battery characterstcs. These profles have to be acheved emprcally by the mean of the power proflng tests. Conceptually, these profles can be grouped n power consumpton classes based on two knds of parameters: system (usage) parameters and battery (consumpton) parameters. Fg. 10 descrbes three types of power consumpton profles for the followng measurements: consumed energy, remanng energy and dsspated energy. Every profle s dependent on the workload executed by the system. The workload profle determnes the power states the devce can swtch whle runnng (Fg. 10.a) and thus t determnes the power consumpton profle of the devce. Power consumpton shown n Fg. 10.b has dfferent power consumpton values for a component at dfferent workload type. Every workload type has assocated a certan power consumpton level. Power consumpton profles are usually descrbed as a sequence of power consumpton levels assocated wth a sequence of workload type. 7

28 Remanng energy, whch s shown n Fg. 10.c, s the energy avalable n the devce energy supply (usually the battery) that can be further used by the devce. The remanng energy s decreasng wth tme dependng of workload profle. The avalable energy s decreasng faster when hgher workload levels are appled to the component. Dsspated energy s the fracton of the consumed energy loosed by the system as heat (Fg. 10.d). Fg. 10 Theoretcal power consumpton profles To conclude, the power effcency framework s based on followng concepts: Workload components are consdered the system s physcal modules that consume power and contrbute to the overall power consumpton of the system. For a moble devce we dentfed the followng components: CPU and memory, WLAN, Flash fle system, Audo chpset, Dsplay, Vdeo chpset, Bluetooth, GPS recever, GSM chpset, etc. Component measurements defne the measured parameters avalable for every addressed component. For every component n system there are a set of measurable parameters whch descrbe how the component s used and ts power consumpton state. Every component parameter s ncluded n one of the four classes presented n Fg. 10. For the same component, dfferent systems used t may provde dfferent parameters, dependng on the component drver mplementaton. Measurements could be enabled/ dsabled through confguraton fles dependng on the system. 8

29 Research and Contrbutons n Energy-Effcency and Context-Awareness of Power effcency metrcs are defned as hgh level metrcs computed by the power framework core, whch makes them avalable to user applcatons through a well defned nterface layer. Hgh level metrcs are doman specfc values computed for every component and regstered user or system applcaton. These values are doman specfc n terms of power consumpton for component or applcaton workload operatons. Some basc component measurements, lke power consumpton metrcs, could be propagated from lower level of the framework to user applcatons. Power consumpton and power effcency metrcs could be computed as average value or nstantaneous values. Besde power effcency metrcs computaton the framework core has to splt these values and dspatch them n order to obtan: o contrbuton of ndvdual components to the global power consumpton o contrbuton of each applcaton to the power consumpton per component o contrbuton of each applcaton to the global power consumpton Power profles specfy how power effcency metrcs vares n tme. We defne one set of profles per component n order to see how component power consumpton changes wth component s parameters. Power profles establsh a relatonshp between power states, workloads and power consumed by the devce or component beng n these states. Proflng determnes a set of relevant states of the system whch are determned n solaton (no other components are enabled). Each state has assocated a power consumpton profle (e.g. amount of used energy per actvty). Based on component power profles we ntend to obtan power consumpton forecasts for certan workloads before they are executed..4.1 Physcal measurements Typcally, power related measurements correspond to the man system power sources: CPU and memory, WLAN/LAN card, storage system, dsplay, vdeo and audo. Every system component has a number of parameters provded by ts drver or by the operatng system nterfaces. In ths secton we address the frst two components: the CPU and memory as a sngle component because for the hgher levels they are tght related. These parameters are presented n Tab. 1. Item Physcal Operatng System Applcaton Battery I [ma] - current C [mwh] - battery capacty V [V] - battery voltage P [mw] - dscharge rate T - temperature Power states Workload type CPU T - temperature F - fan speed Ps - p-state CPU load CPU counters Memory usage Thread nfo Thread count 9

30 WLAN Dsplay RSSI - power strength Securty model Brghtness level Bandwdth Error rate Brghtness level Audo Volume level Volume level Tab. 1 System and component measurements We grouped the measurements n four classes (Fg. 10): Workload sources measurements specfes the descrpton of the components whch may consume energy n the system. Battery energy measurements specfes the current status of the remanng energy avalable n the system. Power consumpton measurements specfes the current system power consumpton Heat dsspaton measurements specfes the energy lost n the system through heat dsspaton. The man goal of our tests s to fnd an emprcal relaton between the extracted measurements for the CPU component and ts power consumpton. In order to acheve ths relaton we used power benchmarks to profle the system and the applcatons, whch are defned n the next secton. CPU measurements CPU s the most mportant component n the system and t has a substantal contrbuton to the overall systems power consumpton. CPU parameters could be measured globally for all applcatons runnng n the system or specfcally for every applcaton regstered n the framework. There are two types of CPU parameters: statc and dynamc. Statc CPU parameters are known a pror for a certan system and could be confgured through confguraton fles or can be obtaned usng OS API. Dynamc CPU parameters could be measured n real tme (onlne) for the runnng applcatons and they are varable wth the CPU utlzaton by these applcatons. Dynamc parameters could be acheved for the whole system or per applcaton, but statc CPU parameters are only global parameters. Dynamc parameters are computed as an average on a fxed amount of tme whch s a settable parameter for the framework, and we call t framework sample tme perod. We consder n our model that one applcaton s composed, n terms of CPU, from one or more threads. The applcaton threads could be started when the applcaton s launched (as a pool of threads) and they are alve durng the whole applcaton lfetme or the applcaton could start dynamcally a number of threads, when they are needed. Every applcaton thread has a unque ID, the processor core t s allocated to, the prorty and CPU and memory usage by the thread durng the current tme perod. The CPU power consumpton due to a certan applcaton s to be computed from CPU parameters computed for every thread n the observed applcaton. 30

31 Research and Contrbutons n Energy-Effcency and Context-Awareness of CPU core parameters are used to characterze statcally and dynamcally the CPU confguraton of the system: CPU cores number (cpuno) specfy the number of cores avalable n the system. Ths parameter s statc and s well defned globally for a certan system. We consder for the current mplementaton only sngle processor systems wth sngle or multple cores. [cpu_core_number] CPU core avalable power states (cpups) every CPU core has a well defned number of power states: actve, low power, sleep, nactve. For every power state the power consumpton level has to be known and statcally confgured. A CPU power state s defned by ts name, power consumpton and the actvaton tme needed by the CPU core to enter ths power state. [cpu_power_states_number, cpu_power_state_name, cpu_power_state_value, cpu_power_state_uptme] CPU core runtme power states specfy n every sample n tme the current power states the CPU cores are used n. For every core, the runtme power state s one of the avalable power states for the CPU presented before. [cpu_runtme_power_state] CPU usage parameters specfy how the CPU s used by all runnng applcatons: Global CPU tme (cpugt) specfy the tme the CPU or ts cores are used by the runnng programs threads n the current evaluaton tme perod. CPU tme s expressed n clock tck counts and defned as the amount of tme the CPU s actually executng nstructons of the runnng applcatons. Global CPU tme s the dfference between the total amount of tme the CPU executes nstructons counted from the system begn tme to the samplng nterval end tme and the amount of CPU tme from the system begn tme and the start tme of the samplng nterval [global_cpu_tme]. Thread usage parameters specfy how the CPU cores are shared by the runnng threads: Thread CPU tme (cputt) specfy the amount of tme a thread has actvely used the CPU core durng the framework sample tme perod. Ths parameter s computed for every combnaton of thread and CPU core n order to show how a thread was executed and mgrated on dfferent cores. The same wth global CPU tme, t s expressed n clock tck counts and can be computed by dfference between the total amount of tme the thread used the CPU from ts begn to the stop tme of the current samplng nterval and the amount of CPU tme from the thread begn and the start tme of the next samplng nterval [thread_cpu_tme]. Wreless measurements WLAN nterface has an mportant contrbuton to the total system s power consumpton, especally for smart moble devces and tablets. Typcally, the man contrbutors to power consumpton of wreless nterface are the chpset and the rado nterfaces. They are under the control of the applcatons that are performng wreless communcaton and OS drvers mplementng the protocol stacks. The power consumpton measurements used to profle wreless communcaton: 31

32 WF chpset power consumpton (Pwf on) specfes the amount of power consumed by the wreless nterface hardware when the nterface s swtched on but t s not connected to an access pont. WF connected power consumpton (Pwf con) specfes the power consumpton of the WF crcuts when connected to an access pont and lstenng to the rado nterface. WF transmsson power consumpton (Pwf tr) specfes the power consumpton of the WF rado nterface whle sendng data packets. Several parameters are taken nto account whle measurng transmsson power consumpton: transport protocol, data block sze, payload data patterns, receved rado sgnal strength, and transmsson rates. WF recepton power consumpton (Pwf rc) specfes the power consumpton of the rado nterface whle recevng data. The same parameters are taken nto account whle measurng recevng power consumpton: transport protocol, data block sze, payload data patterns, receved rado sgnal strength, and recepton rates. Energy effcency measurements of wreless communcaton: WF transmsson energy effcency (Ewf tr) represents energy consumed by the wreless nterface to transmt 1 bt of nformaton under certan condtons: transport protocol, data block sze, payload data patterns, receved rado sgnal strength, and transmsson rates. WF recepton energy effcency (Ewf rc) represents energy consumed by the wreless nterface to receve 1 bt of nformaton under certan condtons: transport protocol, data block sze, payload data patterns, receved rado sgnal strength, and recepton rates. Battery measurements Battery parameters are valuable metrcs for mprovng moble systems and applcatons power management. Power management strateges appled for lower levels n the system usually do consder nether battery parameters nor other system parameter; they only mplement certan polces, n most of the cases based on tmeout or usage predctons. Moble systems are subject to dfferent and complex user and usage models, each wth ts own battery lfe profles. Hgher system level and fnally the user applcatons should be aware of ther mpact on overall power consumpton usng the set of low level metrcs provded by devces, drvers or operatng system components. Besdes battery parameters there are other operatng system or devce level parameters whch can be used n the power aware framework. Our proposed power executon framework s based manly on the nformaton measured or estmated by the battery drver or the operatng system. Battery status s based on several parameters: battery capacty [mwh], maxmum battery capacty [mwh], charge/dscharge rate [mw], current drawng [ma], battery remanng lfe tme [s], battery temperature [oc], etc. These parameters depend on the way the battery dscharges and the power profle of the workload sources. As a battery dscharges, ts termnal voltage decreases from an ntal voltage Vmax, gven by the open crcut voltage of the fully charged battery, to a cut off voltage Vcut, the voltage at whch the battery s consdered dscharged. Because of the chemcal reactons wthn the cells, the capacty of a battery depends on the dscharge condtons such as the magntude of the current, the duraton 3

33 Research and Contrbutons n Energy-Effcency and Context-Awareness of of the current, the allowable termnal voltage of the battery, temperature, and other factors. The effcency of a battery s dfferent at dfferent dscharge rates. When dschargng at low rate, the battery's energy s delvered more effcently than at hgher dscharge rates. Battery lfetme under a certan load s gven by the tme taken for the battery termnal voltage to reach the cut off voltage. The standard capacty of a battery s the charge that can be extracted from a battery when dscharged under standard load condtons. The avalable capacty of a battery s the amount of charge that the battery delvers under an arbtrary load, and s usually used (along wth battery lfe) as a metrc for measurng battery effcency. Many chp vendors offer ther own energy consumpton specfcatons on product data sheets that are dffcult to compare wth one another. When usng these crcuts n the desgn phase the attempts to compare processors ntegrated nto system on chp mplementatons, nterpretng these values becomes even more dffcult. Vendors also use typcal power metrcs to characterze ther processors, but only rarely they ndcate the workload that was appled whle makng these measurements and ths wll have a sgnfcant mpact on energy and power numbers. Modern operatng systems provde a comprehensve and system wde set of power management features n order to extend battery lfe and save energy, reduce heat and nose, and help ensure data relablty. The power management functons and messages allow applcatons to retreve the system power status, notfy applcatons of power management events, and notfy the system of each applcaton's power requrements. Intellgent batteres whch provde power for recent portable computers and moble devces are avalable to applcatons through the operatng system, whch provdes nformaton on the state of the battery so applcatons can provde useful functons for the user. To obtan nformaton about the battery status, the applcatons may use the OS functons, whch return general nformaton about all power sources n the system and some estmatons of the battery current status computed by operatng system: battery lfe percent, battery lfe tme and battery full lfe tme. In our tests these data are not suffcent for a good estmaton of power consumpton; therefore detaled nformaton about each ndvdual battery s necessary. In order to obtan detaled status parameters on batteres, the battery drvers should be used. Temperature measurements Temperature n computng systems s a valuable parameter whch can provde dfferent nformaton about the usage and healthness of the system and ts components. When temperature of a component ncreases over a certan level, the component s overloaded or could have some hardware defects. On the other hand, the temperature of a component gves an ndcaton of the energy dsspated by the component through heat. Another aspect s related wth the ncreasng of power consumpton of a component where temperature of the component ncreases. Some components n a computng system have already ntegrated bult n temperature sensors whch can be read from applcatons: CPU temperature and core temperature Battery temperature 33

34 .4. Power benchmarks The power framework contnuously montors the components and systems parameters and computes power effcency metrcs whch are provded to the regstered applcatons. Every power source n the system has a power profler n order to estmate and predct ts power consumpton varaton durng ts usage. We understand by power profles the varaton n tme of power effcency metrcs related to the workload appled to the component. In order to use power profles we need to ntroduce a standard way to generate the profles and n order to dentfy correctly power varaton of the components. Ths standard method to generate power effcency profles we called power effcency benchmarks that we descrbe n the followng secton. Besdes the two enttes we ntroduced before (power consumpton metrcs are the hgh level values we compute based on measurements and power consumpton profles are the way power metrcs vares n tme for certan workloads) we ntroduce the power benchmarks whch are standard method proposed to extract power profles. We propose to extend the concept of benchmarkng wth another metrc: the power consumpton and name t power benchmark. Defnton Power benchmark s defned as a software program that characterzes the power consumpton of a system, component or applcaton wth respect to certan stmulus (workload). The metrcs used by power benchmark software are based on the measured or estmated power consumpton by the battery drver or the operatng system. Many chp vendors offer ther own energy consumpton specfcatons on product data sheets that are dffcult to compare wth one another. When usng these crcuts n the desgn phase the attempts to compare processors ntegrated nto system on chp mplementatons, nterpretng these values becomes even more dffcult. Vendors also use typcal power metrcs to characterze ther processors, but only rarely do they ndcate the workload that was appled whle makng these measurements and ths wll have a sgnfcant mpact on energy and power numbers. Therefore an onlne power benchmarkng tool s needed n order to compare all these metrcs wth respect to real lfe scenaros and applcatons. A power benchmark must be able to dstngush the way power consumpton s ncreasng wth the workload compared to the dle state power consumpton. The power benchmark s able to dentfy the type of workload out of the power consumpton varaton. Therefore, we defne a power benchmark as havng three ntervals (Fg. 11): The frst tme range [0 t1), s ntended for dle mode power consumpton. In ths step, the component does not execute anythng, but the power savng mechansms s prevented to occur. The second tme range [t1 t) represents the workload phase, when a certan stmulus s executed. SPEC CPU000 or any type of other applcatons can be executed as workload. The last tme range [t t3) represents the releasng phase ntended for the component to reach agan the dle state power consumpton. In ths step, the component does not execute anythng, but the power savng mechansms s also prevented to occur. 34

35 Research and Contrbutons n Energy-Effcency and Context-Awareness of Fg. 11 Power benchmark defntons There are two ways the power benchmark can be mplemented: Fxed tmes power benchmark the benchmark moments t1, t and t3 are predefned and constant. Ths knd of power benchmark shows the maxmum component power consumpton when a certan workload s appled for a constant perod of tme (t t1); Fxed power consumpton values power benchmark the benchmark tmes are varable and benchmark power measured values are predefned and constant. Ths benchmark shows how many workload operatons are executed per consumed energy. The power consumpton measurements presented before can be used n benchmark, and these can be grouped n two classes: power consumpton measurements (a) (dscharge rate, current) and remanng battery capacty measurements (b) (remanng tme, remanng capacty, etc.)..4.3 Power effcency metrcs The kernel s responsble to provde to the hgher layers power effcency metrcs such as nformaton on power consumpton (average, nstantaneous), applcaton or component power effcency and to provde predctons on remanng power under the trend of the observed workload. The kernel s also responsble for the power metrcs splt among executon threads and applcatons so that a global pcture of the contrbuton of each applcaton to the global power consumpton s gven. Power effcency metrcs specfy how much energy s needed to complete an applcaton specfc job. The applcatons runnng on top of the framework should be able to estmate the tme and the energy needed to fnsh ther tasks n order to adapt and optmze them or at least to establsh whether they can be fnshed n the avalable energy. Usually applcatons have the hghest chance to estmate the duraton of ther own tasks, therefore they should know or could estmate how long 35

36 a job wll last n order to complete. For example an applcaton whch downloads a fle knows how long wll take to complete and could then estmate how much energy s needed. Of course there are also a lot of jobs that cannot be estmated exactly n tme but other heurstcs or statstcal data can be used, but these are applcaton specfcs and are not the purpose of our work. Based on the theoretcally concepts ntroduced before, we defne a computng system as a set of hardware components and the software applcatons usng them. The power aware applcatons whch use the framework need an nterface to regster them n the framework and an nterface for power effcency data retreve and analyss. Power analyss nterface mplemented by the framework provdes a way to acheve global power consumpton of the system, power consumpton of every component n the system or ts value from the global power consumpton and power consumpton of every software applcaton or ts relatve value from the global power consumpton. Global metrcs are the parameters that characterze the power consumpton and power effcency of the whole system: Global power consumpton (Ps) s the average power consumpton of the system durng the framework samplng tme nterval. Ths metrc s the absolute power consumpton expressed n Watts and s obtaned from the battery measurements presented before. In case the battery drver does not provde any nformaton that could be used to estmate absolute system power consumpton, relatve values for ths metrc are accepted. [global_power_consumpton] Global energy effcency (Es) specfes what are the costs n terms of energy n order the system wll fnsh ts work. The effcency s measured n operatons per consumed energy and s computed as the useful work executed by the system per quantty of energy consumed to fnsh the work. The system s operatons could be defned n terms of users operatons, component operatons or applcatons operatons. [global_energy_effcency] Total avalable energy (Et) s the energy that the system s power sources can supply wthn specfc parameters n order the system works properly (works wth the expected level of performance or QoS). The energy s expressed n joules or n terms of battery capacty (Wh). Ths metrc s avalable from battery measurements. [total_avalable_energy] Component metrcs are the framework computed values that characterze the power consumpton and ts effcency of a hardware component: Component power consumpton (Pcpu, Pwlan, etc.) s the average power consumpton of the component durng every samplng nterval. Ths metrc specfes the part n the global power consumpton due to the addressed component. Component power consumpton s a component specfc metrc whch s computed based on the low level measurements for the component. The metrc s expressed ether n absolute values (recommended) or n relatve values (when poor measurements are avalable). [component_power_consumpton (component)]. Component energy effcency (Ecpu, Ewlan) specfes whch the costs n terms of energy are n order the component execute a specfc amount of work. The effcency s measured n operatons per consumed energy and s computed as the useful work executed by the 36

37 Research and Contrbutons n Energy-Effcency and Context-Awareness of component per quantty of energy consumed to fnsh the work. CPU energy effcency s the report between CPU tmes and energy consumed by the component for the tme perod the CPU tme s computed. [component_energy_effcency] Applcaton metrcs are the framework provded parameters that characterze the power consumpton and power effcency of a software applcaton: Applcaton global power consumpton (Papp) specfes how much of the system power consumpton s due to the specfc applcaton. Ths metrc provded by the framework core s computed based on the applcaton s threads measurements and the used components parameters. The metrc s expressed ether n absolute values (recommended) or n relatve values (when poor measurements are avalable). [applcaton_power_consumpton (applcaton)] Applcaton energy effcency (Eapp) specfes whch the costs n terms of energy are n order the specfc applcaton executes ts work. The effcency s measured n operatons per consumed energy and s computed as the useful work executed by the applcaton per quantty of energy consumed to fnsh the work. The effcency s the report between energy consumed by an applcaton and the applcaton specfc parameters, for example energy used per frame dsplayed by a move player. [applcaton_energy_effcency] Applcaton component power consumpton (Papp cpu) s the power consumpton of a hardware component nduced by a specfc applcaton. Ths metrc s computed by the framework functon of the applcaton s threads measurements and specfc component parameters. The metrc s expressed ether n absolute values (recommended) or n relatve values (when poor measurements are avalable). [applcaton_power_consumpton (applcaton, component)] Applcaton component energy effcency (Eapp cpu) specfes whch the costs n terms of energy are n order the component execute a specfc amount of work for a certan applcaton. The effcency s measured n operatons per consumed energy and s computed as the useful work executed by the component for an applcaton per quantty of energy consumed to fnsh the work. CPU energy effcency s the report between CPU tmes and energy consumed by the component for an applcaton for the tme perod the CPU tme s computed. [applcaton_energy_effcency].5 EXPERIMENTAL RESULTS.5.1 Moble voce communcaton Voce communcaton remans one of the man functons of moble devces even though new features and applcatons are avalable. Currently there are a lot of voce communcatons technologes runnng on dfferent types of moble devces, such as VoIP technologes provded by applcatons lke Skype, Vber). The multtude and complexty of devces that mplement a large spectrum of multmeda and wreless communcaton protocols requre closer evaluaton and understandng n respect to ther energy effcency. In ths actvty we tred to dentfy, model and estmate the energy consumpton of voce communcatons on moble devces based on the energy 37

38 effcency framework and energy profles. We used TAPI (Telephony API) to dentfy ongong and ncomng calls and next to estmate ther energy consumpton. The man goal of our work s to measure or at least to estmate the energy consumed by a moble devce whle communcatng n GSM 3G and IEEE networks. The moble devce can ntate a call (herenafter referred to as outgong call) or t can receve a call (herenafter referred to as ncomng call). Durng voce GSM calls the moble devce consumes more power than f the devce s dle or t does not communcate. In order to estmate the energy of GSM voce calls the frst step s to montor the devce components usng the operatng system s API. There are three elements we proposed to montor n our tests: the battery status, the call status and the cell tower nformaton. Further n ths secton we descrbe the archtecture and the detaled desgn of the montorng applcaton based on the concepts and framework archtecture descrbed before. Consderng the wde range of exstng moble devces, the man requrement for the voce communcaton energy montorng applcaton was to desgn and develop a soluton whch s portable and extensble. The montorng soluton desgn should be easly portable on dfferent type of battery powered devces (smartphones, pocket pc, tablet pc, laptop), operatng systems (Wndows Moble/Phone, Wn3/64, Androd) or development envronment and language (C++, C#, Java). Furthermore, the proposed soluton should be able to collect and to abstract the varous types of parameters avalable on dfferent devces (e.g. dfferent battery drvers may provde dfferent types of battery measures: voltage, current, power consumpton, remanng lfetme, etc.) The montorng applcaton was tested on two moble devces: HTC HD Wndows Moble 6.5 (WM 6.5) smartphone and Fujtsu Semens Pocket Loox T830 Wndows Moble 5.5 (WM 5.5) smartphone due to ther API access to the smart battery drvers and ther measurements accuracy. The montorng applcaton can be compled for WM 5, WM 6, WM 6.5 and Wn3 for ARM and x86 mcroprocessor archtectures. The proposed general soluton presented n Fg. 5 Power effcency framework archtecturefg. 5 s customzed for ths specfc applcaton whch s shown n Fg. 1. It s based on a layered archtecture contanng the user nterface layer (GUI layer), call energy logc specfc layer (Logc layer) and the data acquston layer (Data layer). The bottom layer s runnng on top of the host operatng system (OS) and t provdes a platform ndependent method to access and collect specfc parameters from the underlyng hardware and software components. Data acquston layer uses the specfc APIs provded by OS to read component related measurements whch are further transferred to the upper layer n a unform platform ndependent way. But the mplementaton of data access layer s platform dependent; therefore specfc mplementaton should be developed for every new targeted platform or devce. Ths layer provdes access to read battery, telephony and rado related parameters. The mddle layer s platform ndependent and t mplements the energy estmaton logc. Ths layer contans ntellgent battery and call montors and the call energy profler that matches the power consumpton measurements and call related phases to estmate the energy consumed by every voce call. The montor components store hstorcal data whch are used to calculate energy costs of each call. 38

39 Research and Contrbutons n Energy-Effcency and Context-Awareness of Fg. 1 Overall energy-aware voce soluton archtecture On top of the logc layer s placed the user nterface layer whch provdes moble users wth smple access to energy costs of the last calls and an estmaton of the avalable conversaton tme consderng the current energy status of the battery. The GUI layer s platform dependent and s desgned to allow development of applcaton specfc GUI components: today screen or normal dalogs. Factory objects are used to dentfy the host system, to detect the target components n the system and fnally to create meter objects for the detected components. Factory objects mplementaton s platform dependent and they generate platform dependent meterng objects. Meter objects are used to provde read access to components n the system or OS to collect components specfc parameters. Meter objects mplementatons are also platform specfc. In Wndows Moble OS we based the mplementaton of WnMobleBattery meter on functon GetSystemPowerStatusEx. The meter objects can be used by pollng the components or by lstenng from certan events from the component. WnMobleBattery s used n pollng mode to sample wth certan tme rate (usually 1 second) the battery parameters. Every sampled set of parameters are stored n Sample objects. Sample objects are platform ndependent and they are used to store the parameters read from a component for a sampled moment of tme. The Sample objects are stamped wth tme nformaton. Battery parameters are stored n the data type PowerSample whch contans: current, voltage, remanng tme, capacty, remanng percentage and temperature. The last element type n the montorng desgn s the montor tself. The montors are platform ndependent and they have specfc mplementaton for every type of observed component. The sampled data from the meters are temporary stored n these montors. The montors extract relevant nformaton from hstorcal parameters n order to try to fnd models, to extract patterns or to predct trends. Some of the montorng and meterng objects are composte because more than one component of the same type may exst n the system. One complex sample system detected and constructed by a Factory object s shown n Fg. 13. It s a system wth two batteres and two SIM cards whch needs 39

40 two montor objects, one for batteres and one for rado nterfaces, and four meter objects, one for every battery and rado nterface n the system. Fg. 13 Meterng objects herarchy To montor call related parameters we need two types of nformaton: (1) call status to detect the begnnng and the end of an ncomng or outgong call and () call nformaton to obtan the rado sgnal strength as estmaton for the dstance between moble staton and the Base Transcever Staton (BTS). Call status on Wndows Moble devces can be captured usng Telephony API (TAPI). TAPI s used n a Wndows envronment to montor and control telephony resources. Cell tower nformaton s accessed usng Rado Interface Layer API. Fg. 14 Outgong and ncomng calls dentfcaton TAPI s an event based programmng nterface for applcatons to access, montor and control telephony servces. An event based TAPICallStatusMeter s mplemented n the applcaton to detect call related events. The event sequences for outgong and ncomng calls are presented n Fg. 14. However for our purpose only few of the messages are needed n order to dentfy the begnnng and the end of an ncomng or outgong call. Every voce call on a moble devce mples several states: dalng, rngng, busy, connected, dsconnected, and dle. In our tests we consdered two call states for energy evaluaton, rngng 40

41 Research and Contrbutons n Energy-Effcency and Context-Awareness of and connected (Fg. 14), and we compared them wth the dle state power consumpton of the devce. The outgong call s dentfed by several relevant TAPI messages: LINEDEVSTATE_OPEN generated when the voce lne has been opened by the callng applcaton LINECALLSTATE_DIALING the moble devce s dalng the phone number dgts LINECALLSTATE_CONNECTED the call has been establshed and the connecton s establshed between moble devce and the called devce LINECALLSTATE_DISCONNECTED the remote party has dsconnected from the call LINEDEVSTATE_CLOSE the lne has been closed by the callng applcaton The rngng state of an outgong call s consdered the tme perod between LINECALLSTATE_DIALING and LINECALLSTATE_CONNECTED. The voce communcaton of an outgong call s consdered the tme nterval between LINECALLSTATE_CONNECTED and LINECALLSTATE_DISCONNECTED. The ncomng call s dentfed by several relevant TAPI messages: LINECALLSTATE_OFFERING the sgnalng for a new call was receved by the devce LINEDEVSTATE_RINGING the moble devce s rngng to announce the user the new arrved call LINEDEVSTATE_OPEN the voce lne has been opened by the callng applcaton LINECALLSTATE_CONNECTED the call has been establshed and the connecton s establshed between moble devce and the callng devce LINECALLSTATE_DISCONNECTED the remote party has dsconnected from the call LINEDEVSTATE_CLOSE the lne has been closed by the callng applcaton The rngng state of an ncomng call s consdered the tme perod between LINEDEVSTATE_RINGING (or LINECALLINFOSTATE_CALLERID) and LINECALLSTATE_CONNECTED. The voce communcaton of an ncomng call s consdered the tme nterval between LINECALLSTATE_CONNECTED and LINECALLSTATE_DISCONNECTED. We executed the call montorng applcaton on two Wndows moble devces (HTC HD and FSC Loox T830). We ran several call tests between devces whle montorng system parameters and power consumpton of devces. Fg. 15 shows power consumpton varaton of the HTC devce durng outgong and ncomng calls. An ncrease of approxmatvely 1 W can be observed durng calls comparng wth the dle state power consumpton. There s no sgnfcant and consstent dfference between power consumpton of ncomng and outgong calls. Fg. 16 shows power consumpton of the FSC devce durng voce calls. The ncrease of power consumpton durng calls s hgher than the one of the other devce, wth W hgher than the dle state power consumpton. However, ths dfference s due to the older verson of the hardware of FSC devce. 41

42 P [mw] 0 HTC voce calls power consumpton Tme [s] Outg ong call Inco mng call P [mw] Fg. 15 HTC voce calls power consumpton FSC voce calls power consumpton Tme [s] Fg. 16 FSC voce calls power consumpton Outgo ng call Incom ng call P [mw] HTC FSC 5 0 Idle Call Incomng Outgong Fg. 17 Idle vs. voce calls power consumpton 4

43 Research and Contrbutons n Energy-Effcency and Context-Awareness of Average power consumpton values for both devces are presented n Fg. 17. In our tests we dd not observe sgnfcant and repeatable dfferences between ncomng and outgong calls. However a 100% 00% ncrease n power consumpton s accounted when communcatng compared wth the dle state power consumpton of the devces. The user nterface for Wndows Moble s shown n Fg. 18. The applcaton measure and dsplay n the Today plugn the power consumpton of the system when dle and when the user ntates or accepts a call. Fg. 18 Idle vs. voce calls power consumpton (GUI).5. Wreless data communcaton In order to obtan always connected moble applcatons, energy effcent wreless communcaton chpsets, protocols, clents and servers have to be developed. Wth the proposed tests we amed to hghlght the relaton between dfferent wreless communcaton parameters and ther effect on system power consumpton n order to capture these relatons n the fnal model mplementaton. The proposed test set contans the followng test cases: WLAN power states to measure power consumpton of the devce when wreless nterface s swtched between ts avalable power states: OFF, ON (wthout communcaton and wthout power management), ON (wthout communcaton and wth PM), ON (wth communcaton n progress) WLAN securty to measure power consumpton of the devce when ts WLAN nterface s usng dfferent securty settngs and encrypton algorthms: OFF, ON (WEP), ON (WPA TKIP), ON (WPA AES) WLAN TCP/IP transport protocols UDP and TCP transport protocols have been used 43

44 WLAN communcaton data patterns to measure power consumpton of the devce when transferrng dfferent types of data: text, zp, multmeda WLAN communcaton drecton to measure power consumpton of uplnk and downlnk data transfers WLAN transfer rates to measure power consumpton and energy effcency when dfferent transfer rates are obtaned WLAN rado sgnal strength and dstance between communcatng nodes and how they nfluence the devce power consumpton Based on the results of these tests we further tred to ntroduce them nto the proposed energy estmaton model. Hgh level proflng of wreless communcaton conducts to several conclusons. Power consumpton of WLAN power and communcaton states can be measured and show constant values for every specfc devce. When transferrng data on wreless nterface, the power consumpton depends on the securty model used but t do not depends on dstance between emtter and recever and also t do not depends on data patterns or types (Fg. 19). WLAN power states 3.5 P [W] FSC N560 FSC T830 0 WLAN On (ds) WLAN Comm (Open) WLAN Comm (WPA) WLAN Off WLAN On (en) WLAN Comm (WEP) Fg. 19 Wreless LAN nterface hgh-level power states Power consumpton of wreless nterface whle transferrng data s consdered constant wthn one hgh level power state (Fg. 0). However, the energy effcency of communcaton n one power state s not constant and depends on the acheved transfer rate (Fg. 1). Therefore, WLAN communcaton s modeled usng the two parameters: current power state and transfer rate. Based on these parameters an energy aware moble download manager applcaton aware of ts energy consumpton can be developed. 44

45 Research and Contrbutons n Energy-Effcency and Context-Awareness of f(x) = ln(x) f(x) = x Rate [kbps] Logarthmc Regresson for Rate [kbps] P [W] Lnear Regresson for P [W] k k 4k 8k 3k 16k 18k 51k 64k 56k 1M M 4M 8M Block sze Fg. 0 Wreless nterface power consumpton and rate Energy effcency Efcency Logarthmc Regresson for Efcency f(x) = ln(x) k k 4k 8k 3k 16k 18k 51k 64k 56k 1M Block sze M 4M 8M Fg. 1 Wreless LAN nterface hgh-level energy effcency.5.3 CPU ntensve processng Moble applcatons follow an ascendng trend of processng performance requrements, trend that leads to ncreasng power consumpton values of the processor and to hgher temperatures of the CPU cores. CPU ntensve workloads are therefore worth to be studed and optmzed based on ther energy effcency. An energy aware applcaton was developed on top of the energyeffcency framework whch mplements several CPU benchmark algorthms. An mportant aspect of CPU ntensve workloads s ther thermal effect; therefore we have been nterested also n temperature profles of these workloads. Thermal profle of a processor when executng hgh ntensve computatons s shown n Fg. 3. The CPU load s 100% and CPU temperature ncreases n tme untl heat dsspaton steady state s acheved. When the workload s executed on a multcore archtecture the sngle threaded benchmark applcaton s contnuously swtched from one core to another on the bass of OS task scheduler mplementaton. The overall CPU usage for the sngle threaded nteger test applcaton s 50% and the applcaton receves dfferent processor tmes from every core (Fg. ). Thermal profles of CPU and CPU cores, when the same nteger workload s executed, are presented n Fg. 3. The CPU cores are not at the same temperature because ther uses are not balanced equally. 45

46 Fg. CPU cores usage level for sngle threaded test Fg. 3 CPU cores temperatures for sngle threaded test In order to mplement energy aware CPU workloads we executed the same workload at dfferent CPU usage levels. The same CPU ntensve workload when executed at dfferent CPU loads produces dfferent thermal profles and power consumpton levels. For example the same workload was mplemented n three ways: full performance (CPU usage=100%) Fg. 4, the workload s mplemented for best performance. short delays (CPU usage=50%) Fg. 4, nsde the workload algorthm, after a number of teratons, short ntervals sleep functon calls have been ntroduced. Dependng on the frequency of sleep calls we could acheve dfferent CPU usage levels. long delays (CPU usage=50 75%) Fg. 5, nsde the workload algorthm, wth a selectable frequency, long delays are ntroduced. Dependng on the delay perods and frequences dfferent CPU loads could be acheved, but we also obtaned dfferent thermal profles. Therefore, n some cases we can control and adapt a software applcaton n order to reduce the heat dsspaton due to ths applcaton (Fg. 5). 46

47 Research and Contrbutons n Energy-Effcency and Context-Awareness of Fg. 4 Full performance and short sleeps workload mplementatons Fg. 5 Long sleeps workload mplementatons 47

48 By runnng the same test wth dfferent delay parameters, so that a workload s executed wth dfferent CPU usage levels, the plots n Fg. 5 have been obtaned. In Fg. 6(a) the same nteger workload was run on core 0 at 100%, 90% and 70% CPU core usage levels. Four groups of dots are clearly observed: one cluster for the dle state temperatures and three clusters for the workload temperatures. The same pattern can be observed for the relaton between CPU usage levels and average CPU temperatures. There s a drect relaton between CPU core temperatures and CPU tme (n terms of usage level) for the same type of workload; therefore we can estmate the contrbuton of the applcaton to the CPU heat generaton. Fg. 6 (a) CPU core temperature versus CPU core usage and (b) CPU average temperature versus CPU usage Another aspect we nvestgated was the nfluence of dfferent workload types on CPU cores temperatures. Fg. 7 depcts the thermal profles of four workload types: nteger, float, memory and SSE executed successvely for the same amount of tme on the same CPU core. Based on ths test, n order to estmate the effect of a CPU ntensve applcaton over temperature, we need to know the type of operatons the applcaton mplements. 48

49 Research and Contrbutons n Energy-Effcency and Context-Awareness of Fg. 7 CPU cores workload temperatures Part of the battery energy of a moble devce s transformed nto heat. The ncrease n temperature enforces more energy to be consumed. Durng the second phase of the benchmark applcaton, when the workload s executed, the temperature of the processor and also the temperature of the entre moble devce ncrease (n our example the temperature ncreases from 60 to 100 o C). Ths ncrease n temperature has an effect on power consumpton, and a smooth ncrease (from 30 to 34 W) durng phase of the benchmark can be observed n the current profle. Ths ncrease of approxmately 4W durng the workload executon s due to heatng of the devce and avalable coolng elements. Fg. 8 (a) CPU cores thermal effcency and (b) CPU workload thermal effcency 49

50 We ntroduce and draw the thermal effcency profle Fg. 8 as the number of workload (applcaton specfc) operatons per ncrease n temperature. Thermal effcency specfes how effcent s the use for every ncrease n temperature due to the executon of the workload n the selected parameters. Based on the thermal profle and power consumpton values of the moble system acheved durng tests we developed a power and thermal aware applcaton whch adapts ts executon n order to decrease CPU cores temperatures and ncrease the system s energy effcency. In addton we nvestgated the possblty to dentfy the effect of every runnng applcaton n the system over the CPU, cores and system temperatures..5.4 Energy-aware vdeo player Nowadays the moble phone s becomng the devce people rely on not only for basc communcaton, but also for entertanment and even for work. Moble devces have to run multmeda and communcaton applcatons together wth user personal data and busness applcatons that need optmum of energy effcency n order to prolog the battery lfetme. Therefore the last test applcaton we mplemented based on the energy framework s a vdeo renderng system for a moble devce, whch was tested on Pocket PC LOOX T380 Fujtsu Semens. The proposed applcaton adapts tself dynamcally to the energy consumpton of the moble devce modfyng some parameters, whch change some characterstcs of the vdeo renderng, to ensure a power usage reducton. The power adaptaton algorthm has been calbrated based on the followng proflng results. Four benchmark moves have been profled under several statc and dynamc condtons, such as vdeo encodng, fle formats, localty or type of devce. The frst test targeted power consumpton of vdeo decodng algorthms. We played locally the same vdeo and audo content encoded wth dfferent algorthms and fle formats. The Cave vdeo benchmark was played locally and the obtaned power consumpton values are shown n Fg. 9. Cave P [dw] Cave gpp dv3 h64 mp4 mpeg4v ms-mpeg wmp dle Fg. 9 Power consumpton of the vdeo decoder 50

51 Research and Contrbutons n Energy-Effcency and Context-Awareness of 1 10 CPU usage [%] Cave 0 3gpp dv3 h64 mp4 mpeg4v ms-mpeg wmp dle Fg. 30 CPU usage of the vdeo decoder It can be observed that Wndows Meda Vdeo format and MPEG4 encodng consume more energy than the other codecs. We can also see that there s a drect relaton between CPU usage level and ts power consumpton for every vdeo format decoded (Fg. 30). The second test evaluated the power consumpton versus scene complexty or type of the vdeo content. In ths test we played locally every vdeo benchmark encoded wth the same codec and fle formats. The Cave, Ste, Tropcs and Lvng vdeo benchmark power consumpton values are shown n Fg. 31. We used the four selected benchmarks encoded wth MPEG 4 (AVI) and WMV 8 (WMV). P [dw] ste cave tropcs engne dle wmv av Fg. 31 Power consumpton vs. vdeo scene complexty The mpact of vdeo localty (local or streamng playng) s presented next. In Fg. 3 local and streamng playng results s shown. It can be observed that when transferrng the vdeo benchmarks usng WLAN, the overall power consumpton ncreases but also the dfferences between power values are reduced because n that case s the wreless card. 51

52 P [dw] Local Streamng gpp dv3 h64 mp4 mpeg4v ms-mpeg wmp dle Fg. 3 Power consumpton (local vs. remote) Test cases executed on the moble devce gave the results presented n Fg. 33 for power consumpton. It can be observed that multmeda vdeo playng ncrease the overall power consumpton four tmes the dle state power consumpton. P [W] ste cave tropcs lvng dle wmv av Fg. 33 Power consumpton of moble devce The power aware player applcaton was created n three stages: n the frst stage the vdeo renderng system was created, n the second stage the nfluence of some parameters of the system on the devce s battery power level was studed and fnally n the last stage the obtaned results n the energy aware vdeo player applcaton were appled. The creaton of the system can be dvded n two parts: the mplementaton of the vdeo renderng part of the system and mplementng the readng of the energy consumpton of the applcaton from the framework. The energy adaptaton algorthm obtaned durng the evaluaton and calbraton tests s further presented. The parameters of the system that were taken nto account were: the frame rate, the dmensons of the renderng wndow and the renderng frequency. 5

53 Research and Contrbutons n Energy-Effcency and Context-Awareness of WHILE not ext condton READ battery status from framework IF (battery status <= 60%) AND (battery status > 50%) SET wndows sze to 0.66 of ts orgnal sze ELSE IF (battery status <= 50%) AND (battery status > 40%) SET frame drop rate to 1/3 ELSE IF (battery status <= 40%) SET frame dsplay rate to 3 END IF END WHILE When the devce s battery level reaches the level of 60% from the total energy avalable when the battery s fully charged the parameter renderng wndow wll be appled and the renderng wndow wll be reduced by 1.5 from ts ntal dmensons. When the devce s battery level reaches 50% the renderng wndow wll be changed back to the ntal dmensons and the frame rate wll be multpled by 3. After the devce s battery level reaches 40% the parameter that ensures the best energy reducton wll be appled, that s the renderng frequency. The frame rate wll be establshed at the ntal frame rate of the move and the renderng frequency wll be 3, ndcatng that only the frames from 3 to 3 seconds wll be rendered. The parameter that ensures the best energy reducton s used last because when the battery s energy reaches a low level a better energy reducton s needed to ensure that the devce wll functon a longer tme. Two vdeo fles were used to test the applcaton and the proposed algorthm: one vdeo fle wth the renderng tme of 1 hour and the second vdeo fle wth the renderng tme of hours. For the frame rate parameter there were made 1 tests: 6 tests for the frame rate multpled by and 6 for the frame rate multpled by 3 (Fg. 34). For the renderng wndow s dmensons parameter there were made 1 tests: 6 tests when the wndow s dmensons are reduced by 1. n regard to the ntal dmensons of the wndow and 6 tests when the wndow s dmensons are reduced by 1.5 (Fg. 35). For the renderng frequency parameter there were made 1 tests: 6 tests for renderng the frames and droppng frames from two to two and 6 tests for renderng one frame and drop frames (Fg. 36). In addton to these tests there were made 6 tests consderng the ntal values for the three parameters: the frame rate 1, the specfc frame rate of the move, the renderng wndow s dmensons were the ntal dmensons establshed usng a panel as a parent for the wndow and the renderng frequency 1, ndcatng that all frames of the move are rendered. 53

54 Energy consumpton [%] Fg. 34 Energy consumpton vs. frame rate 1h h Frame rate Energy consumpton [%] h h Wndow sze Fg. 35 Energy consumpton vs. wndow sze Energy consumpton [%] Fg. 36 Energy consumpton vs. drop rate 1h h Drop rate 54

55 Research and Contrbutons n Energy-Effcency and Context-Awareness of.6 RELATED WORK The authors of [Chen008] proposed and mplemented a desgn framework called GreenRT, for developng power aware soft real tme applcatons. They consdered that the task n soft real tme applcatons must run quckly enough to meet the deadlnes, but there s no extra beneft from runnng them faster than that so that the task fnshes earler. The energy could be saved f tasks are executed on a lower frequency n order to meet exactly ther deadlne, but not earler than then ther deadlne. The GreenRT framework allows an applcaton to montor ts progress and adjusts the processor frequency dynamcally to fnsh ts jobs n tme. The framework s usng the concept of DVFS mplemented on modern processors whch provdes an energy effcent mplementaton for soft real tme tasks wthout any performance loss n respect to the user s percepton [Chen008]. How ever the framework proposed by Chen et al. s not generc, t s hghly dependent on the managed applcaton. Durng the last years, several smlar solutons were proposed [Fe008], [Cheung009], [Bellas010] and [Vallna011]. In [Fe008] an energy aware framework for dynamc software management of moble systems has been proposed. The authors have desgned a user space module, separated of the operatng system, whch permts the QoS (Qualty of Servces) based adaptaton mplemented at the applcaton level. The energy consumpton of the moble applcatons s computed usng predefned software macro models whch are hard to be mplemented n practce for dfferent types of applcatons. Unlke the soluton adopted n [Fe008] we estmate onlne the power consumpton of the applcatons by measurng the battery and system s components parameters. The framework proposed n [Fe008] was valdated usng three applcatons: vdeo player, speech recognzer, and voce over IP. We obtaned smlar results for the vdeo player energy aware mplementaton usng our framework. In [Cheung009] an energy optmzaton framework for software tasks s proposed. The work s focused on the optmzaton algorthm based on Markov decson process. The authors propose effcent technques to solve the optmzaton problem based on dynamc programmng and llustrate how t can be used n the context of realstc applcatons such as WF rado power optmzaton and emal synchronzaton. Unlke the framework presented n [Cheung009] our framework s orented on montorng and provdng power consumpton feedback to moble applcatons. We have not compared our results wth the ones acheved n [Cheung009]. In [Bellas010] a cross layer framework for power management of moble devces s presented. The proposed framework nvolves dfferent layers of a moble system, from devce drvers to user applcatons. The man goal of the framework s to aggregate the QoS levels of applcatons and select the optmum component specfc power management polces accordng wth the power requrements of the runnng applcatons. No smlar applcaton level expermental results were presented n [Bellas010] n order to compare the results. In [Vallna011] a user centered energy aware moble operatng system s presented. The proposed OS manages the hardware resources proactvely allowng opportunstc access to external resources nearby. The work presented n [Vallna011] follow another approach, usng 55

56 an opportunstc access to computng resources avalable n nearby devces usng local wreless nterfaces and nformaton about users socal networks. In [Iyenggar007] a new unfed power management framework s proposed whch descrbes a software archtecture for a unfed hardware and software controlled power management. Ther framework provdes a set of rules for classfyng moble devce components n classes, each class havng a set of well defned states based on the runnng applcatons states. Usng these classes, the framework s an actve software module that manages the power requrements of each applcaton and approprately handles the target components [Iyenggar007]. Our work s smlar wth the soluton proposed by Ivengarr et al. and have the same goals but s dfferent because we try to use on lne power and system montorng n order to provde a feedback for the control mechansm mplemented n the framework. In [Mttal01] the authors present an energy emulaton tool that can be used to estmate the energy usage of a moble applcaton. WattsOn extends exstng emulators to estmate applcaton battery consumpton. A more generc approach towards applcaton level predcton of power consumpton and battery dsspaton has been taken n [Krntz004], where an estmaton methodology s ntroduced. Based on a set of dran rate curves from a set of benchmarks, estmaton for an arbtrary program s composed. The estmaton s lmted to CPU and memory dmensons and t does not take nto account the dsplay, wreless communcaton or I/O components, but could be extended to nclude wreless basc benchmarks to assess wreless based communcaton applcatons. VoIP usage s evolvng for moble devces such as smartphones wth multple wreless nterfaces. However, the hgh energy consumpton, presents a sgnfcant barrer to the wdespread adopton of VoIP over W F. To address ths ssue n [Agarwal007] s presented a practcal and deployable energy management archtecture that leverages the cellular rado on a smartphone to mplement wakeup for the hgh energy consumpton W F rado. In [Feeney001], the authors nvestgate per packet energy consumpton of an IEEE 80.11b card n varous modes: transmt, receve, broadcast, and dle modes. Ther data reveals how complextes ntroduced by the IEEE protocol can mpact the overall energy consumed by the card durng ts operaton. The IEEE WLAN specfcaton descrbes a power savng mode (PSM) that perodcally turns the network nterface off to save energy, and on to communcate [Krashnsky005]. In the nfrastructure mode a moble devce usng PSM communcates wth a wred access pont (AP), the AP buffers data destned for the devce. Once every beacon perod, the AP sends a beacon contanng a traffc ndcaton map that ndcates whether or not the moble devce has any data watng for t. The moble devce wakes up to lsten to beacons at a fxed frequency and polls the AP to receve any buffered data. Sgnfcant reducton n consumpton s obtaned usng ths statc PSM method [Krashnsky005]. 56

57 Research and Contrbutons n Energy-Effcency and Context-Awareness of.7 SUPPORTING GRANTS, RESEARCH TEAM AND SCIENTIFIC OUTCOMES Project ttle: Open Executon Framework for Low Consumpton Battery Powered Moble Devces Prncpal nvestgator: PhD Natonal competton: IDEI 008 Implementaton perod: Project acronym: MobPower Project code: 680/ Budget: ~ EUR Project summary: The evoluton of portable and moble computaton systems towards an ncrease feature set and ncreasng hardware and software requrements demand, together wth the sgnfcant ncrease of market penetraton n our modern socety, s rasng complex problems from a reasonable energy consumpton level pont of vew under dfferent usage scenaros. Besdes the need to assure a reduced energy consumpton level from the user satsfacton pont of vew, the ncreasng number of moble systems are contrbutng drectly to the ncrease carbon doxde emssons, whch motvate the purpose of ths project. In ths project we amed to defne, mplement and valdate a software executon framework for moble systems n order to reduce and optmze energy consumpton. The role of the framework s to provde a generc nterface for user applcatons such that applcatons can express and estmate ther own energy consumpton and to be able to adapt ther executon n tme n order to acheve an optmum energy consumpton level. Applcatons that are gong to use the executon framework n order to optmze ther energy demands are called power aware applcatons. The approach that we am to pursue s both theoretcal, from the energy or power consumpton we am to devse, and practcal whch reflects nto the practcal experments we am to conduct as well as the nter dscplnary aspects t trggers. Some nnovaton elements of our project come from the theoretcal model defnton for the power consumpton analyss, the model valdaton n mult core, multmeda and wreless systems, as well through the process of applyng our fndngs and theoretcal concepts nto the purpose to defne a framework for power aware applcaton constructon and promoton. At the end, our project ams to dssemnate the results n order to promote and ntegrate ts concepts n varous productons products. The research team nvolved n the project ncluded experenced researchers, young researchers, external advsors and students: Prof. Mrcea POPA (scentfc responsble) PhD. Sebastan FUICU PhD. Dacan TUDOR Bogdan STRATULAT 57

58 Jula STRATULAT Florn MATICU Slva COPIL Caml MILOS The man techncal outcomes of the project are: Open executon framework for power aware applcatons 3 power aware applcatons: o Voce communcaton o CPU benchmarks o Vdeo player Power thermal proflng methodology o Power thermal benchmarkng Power thermal proflng measurement database o CPU o WF IEEE (a,g) o Multmeda The man scentfc outcomes of the project are ( ): 1 patent request 45 papers: 3 ISI journal papers Ths secton s based on the followng papers publshed by the author: [ISI], [ISI4], [ISI9], [ISI11], [ISI18], [ISI19], [ISI3], [BDI13], [BDI1], [BDI4], [BDI8], [BDI3], BDI[38]..8 CONCLUSIONS AND FUTURE WORK In ths work we proposed a theoretcal model for power consumpton estmaton of multple components and multple applcatons runnng on a sngle system. Based on ths model we developed a portable software framework prototype for energy effcency montorng and dspatchng between runnng user applcatons. We further run power proflng experments for wreless nterface, processor, and dfferent types of applcatons and workloads. On top of the proposed framework and based on the obtaned power profles we developed four power aware applcatons: voce communcaton energy detecton, processor ntensve workloads energy detecton, WLAN fle transfer energy detecton and vdeo renderng applcaton energy detecton. Based on the energy dspatcher theoretcal model we developed the framework whch s the man result of the project. The proposed framework s mplemented on top of the host operatng system and t provdes energy montorng and estmaton servces for those user applcatons that are adaptable and aware of the remanng battery lfetme. The man beneft of the power aware framework s to provde a platform for development of new knd of software applcatons whch are adaptable to user requrements and avalable energy resources. The framework alone does not optmze the overall energy consumpton of the moble devce but t provdes the power aware 58

59 Research and Contrbutons n Energy-Effcency and Context-Awareness of applcatons wth the means by whch they can get an estmaton of ther own power consumpton. Power aware applcatons bult on top of the framework are the fnal components responsble for system optmzaton decsons. In fact they dynamcally fnd a tradeoff between qualty of servces provded to the users and energy requred to execute these servces. In order to valdate the framework we developed several power aware applcatons that shown an energy consumpton optmzaton range between 5 to 60 %. These applcatons are further presented n the results secton of the document. The second mportant result of ths research work s the power characterzaton of the man hardware components of a moble devce: processor, memory, wreless chpset, GSM chpset and dsplay. Usng the power characterzaton process of system s components the power profles or sgnatures of software workloads or algorthms mplementatons were further extracted. The power framework mplements the onlne profler for power consumpton of system s components and runnng applcatons. 59

60 3 ENERGY PROFILING OF VIRTUALIZATION SOLUTIONS 3.1 OVERALL DESCRIPTION AND RESEARCH OBJECTIVES The envronment sustanablty s one of the man drectons of nterventon for all developed countres. Solutons for alternatve energes generaton and energy reducton are already dscussed. Furthermore, energy effcency has become an mportant aspect n data centers and large server systems. Vrtualzaton s one of the man research drectons for both large scale data centers and servers. Ths secton explores how vrtualzaton nfluences the power consumpton of both physcal systems and vrtual systems and whch s the most effcent way to mplement such applcatons. Power consumpton s a crtcal desgn parameter n modern data center and enterprse envronments, snce t drectly mpacts both the deployment (peak power delvery capacty) and operatonal costs (power supply, coolng). The energy consumpton of the compute equpment s a major component of these costs. [Carpenter007, Dhman009] Modern data centers use vrtualzaton (e.g. VMware), to get better fault and performance solaton, mproved system manage ablty and reduced nfrastructure cost through resource consoldaton and lve mgraton [Clark005]. Consoldatng multple servers runnng n dfferent vrtual machnes (VMs) on a sngle physcal machne (PM) ncreases the overall utlzaton and effcency of the equpment across the whole deployment. However, as we show later on, based on the utlzaton levels and characterstcs of these dfferent co located VMs, the overall power consumpton and performance of the VMs can vary a lot. Ths can create hot spots of actvty, and degrade overall performance and energy effcency. [Dhman009, Tan007] A new trend n vrtualzaton s to use t for moble and embedded mult core archtectures [Behmann009]. The man goal of ths work has been the study on the power consumpton mpact of vrtualzaton solutons for common desktop and laptop computers. Ths work explored how vrtualzaton nfluences the power consumpton of both physcal systems and vrtual systems and whch s the most effcent way to mplement such applcatons. 3. THEORETICAL CONCEPTS We am to measure power consumpton and heat dsspaton of several VMs hosted by one PM. Power consumpton of the PM and the temperature of specfc nternal components of the PM (e.g. HDD, CPU cores), can be measured usng exstng bult n sensors and external meters. However, power consumpton and temperature of a VM cannot be measured n hardware, but they can be estmated usng vrtual nstrumentaton and measurable VM parameters. Power consumpton of a PM (noted PPHY) s a hardware measurable parameter whch quantfes the power consumpton of the whole PM system whle runnng. PM power consumpton contans two components: statc 60

61 Research and Contrbutons n Energy-Effcency and Context-Awareness of power consumpton of the PM system when dle and dynamc power consumpton of the PM due to the software workloads executed on the PM, as n (PPHY = PIDLE + PDYN (Eq. 14). The dynamc component of PPHY s the supplementary amount of power needed by the system s components to execute the specfc workloads of the runnng = (Eq. 15). PPHY = PIDLE + PDYN (Eq. 14) = (Eq. 15) The dynamc power consumpton of a PM hostng several VMs, descrbed n ( = (Eq. 16), contans the addtonal amount of power requred to execute the workload tasks of the runnng VMs. = (Eq. 16) Power consumpton of a VM (noted PVM) s a vrtual parameter that quantfes the addtonal power consumpton of the PM due to the tasks executed by the VM. PVM can be estmated based on power models for VMs, or from a measurement scheme lke the one we propose n ths work. Temperature s another mportant parameter for both physcal servers and vrtualzaton solutons. The temperature can be measured for varous PM nternal components such as bult n sensors. We addressed the temperature of CPU cores (noted TCORE) and the average CPU temperature (noted TCPU) for PM. Vrtual CPU temperature (TVCPU) s the temperature ncrease of the physcal CPU due to the tasks executed by the VM. Each test n a test sequence conssts of three phases (Fg. 37). The test starts wth an dle state watng perod whch brngs the system s parameters to dle statc values. Durng the second phase the test workload s executed. After workload executon the second dle watng phase s provded for system s parameters to reach back the ntal statc values. Every test n a test case last for the same amount of tme. The tme of phase 1 s constant for the tests along a test case and the duraton of phases and 3 together s also constant. Fg. 37 Test phases 61

62 Several parameters were measured, computed and evaluated durng tests executon. These parameters are descrbed and defned next and they are shown n Fg. 38 and Fg. 39. Power consumpton and energy parameters are descrbed n the test representaton shown n Fg. 38. Pmn s the average power consumpton of the PM when dle (PIDLE), t s measured n Watts and t s measured n the frst phase of every test. Pavg s the average power consumpton of the PM when runnng the workload applcaton. Pavg s measured and computed durng phase of a test executon. Pdf s the dfference between maxmum workload power consumpton and the dle power consumpton. It s computed at the end of phase of each test. Pthm s the dfference between Pmax and the average of frst power consumpton samples of the workload phase of the test. Pthm s an ndcator of the ncrease of power consumpton of workload phase due to the temperature ncrease of the CPU. We have computed the energy consumed by the whole test executon usng two components: Edle and Eworkload. Edle s the energy consumed by the PM consderng the whole test s dle. Eworkload s the addtonal energy consumed by the PM to execute the workload. The energy values are represented n Joules. Fg. 38 Power and energy parameters The same parameters descrbed for temperature and heat energy dsspaton are presented n Fg. 39. Tmn represents the temperature of the system components (manly the CPU) when the system s n the dle state, before any workload s executed. Tmax s the maxmum temperature measurements when executng the workload usually dependng on thermal benchmark calbraton t should be the steady state temperature of the workload. 6

63 Research and Contrbutons n Energy-Effcency and Context-Awareness of Fg. 39 Temperature and heat parameters 3.3 MEASUREMENT TEST BENCH We want to estmate the consumpton and temperature of a vrtual machne usng a measurable test workbench. The overall archtecture of the proposed workbench s shown n Fg. 40. It contans the PM under test and VMware vrtualzaton soluton was used to nstall and deploy four VMs on both PM operatng systems. All VMs under tests have Deban Lnux 5.0 operatng system nstalled and every VM owns one physcal CPU core and 1 GB of memory (Fg. 41). An external computer was used to montor power consumpton of PM under test and to collect and store measurement values from PM and VMs. Power consumpton of the PM was measured usng an AC power meter, that contnuously send avalable measurements to the montorng staton usng wreless nterface wth a sample rate of one per second. An external temperature sensor s connected to the montorng computer seral port and s used to montor envronment temperature. Systems under tests we selected were one laptop and one desktop. 4 vrtual machnes PM and VMs system measurements Power consumpton measurements Montorng and analyss computer AC power lne Physcal server under test USB lne External AC power meter 63

64 Fg. 40 Overall measurement archtecture Vrtualzaton energy effcency expermental test bench Physcal machne Vrtual machne VM1 Vrtual machne VM Vrtual machne VMn Test controller Test controller Test controller A/C Power Power meter A/C Power Power data Test coordnator Workload data Energy effcency analyzer Fg. 41 Overall evaluaton setup archtecture In order to emphasze the power consumpton due to vrtual machne executon and to estmate energy effcency of the vrtualzed tasks, several test cases were defned. Every test case contans a sequence of benchmark applcatons wth dfferent combnatons of parameters called test workloads (Fg. 4). Runnng a test case nvolves the executon of each test workload from that test case three tmes on each of the followng machne combnatons: Wndows PM, VMs hosted by Wndows PM, Lnux PM and VMs hosted by Lnux PM. In the Fg. 4 two parameters, power consumpton and CPU load, measured durng test executon, are presented. It can be easly observed the parameters varaton durng workload executon of every test. Fg. 4 Test sequence n a test case 3.4 EXPERIMENTAL RESULTS Idle state physcal system and vrtual machnes power consumpton The frst test case we run on every system under test was ntroduced to estmate power consumpton of the physcal system when runnng n dle state on the host operatng system. We 64

65 Research and Contrbutons n Energy-Effcency and Context-Awareness of consder that the system dle power consumpton s mportant n because the workloads power consumpton ntroduced n the next test cases wll be estmated compared wth ths ntal value. Furthermore, the test s needed to nvestgate the accuracy and repeatablty of the measurements. The second test case s specfed to estmate power consumpton of the physcal system when runnng one or more VMs n dle state under dfferent confguraton parameters. Durng frst two tests no workload applcaton was executed. The condtons specfed for ths test are: number of VMs started and ther parameter settngs, the number of CPU cores and the sze of RAM allowed for one VM. In the begnnng, the dle state power consumpton and temperature measurements for VM and PM were performed and analyzed accordng wth frst two test cases (Fg. 43). It can be observed that when PM s dle, the Wndows OS consumes less power than the Lnux OS. In fact ths depends on the number of servces runnng of both measured systems. In the proposed tests two clean nstalled OS were used wth default servces. The dfference s approxmately 10% n power consumpton levels between Wndows and Lnux OS. An ncrease of power consumpton of the system s noted when startng the VMs (4 VMs) and all of them are dle. Under Lnux OS the observed ncrease of power consumpton when runnng the VMs s rather small. The dfference s approxmately 1% (~1W). But when the system s runnng Wndows OS the ncrease of power consumpton when VMs are on s sgnfcant hgher. The dfference s approxmately 9% (~7W). We run the tests on two dfferent machnes a desktop and a laptop computer (Fg. 44). Power consumpton [W] Temperature [ o C] Lnux Wndows Lnux Wndows PM VM Increase [%] Tab. Idle power consumpton and temperature values An ncrease of average CPU temperature s observed when runnng VMs compared wth the PM temperature. The hgher ncrease n temperature s observed on Wndows, approxmately 8% (3.5 o C) as shown n Tab.. Based on these tests we consdered that s mportant to propose and select an approprate test executon strategy n order to overcome the dfferences n power consumpton between both operatng systems and hardware systems. Absolute power consumpton values cannot be consdered n our test, therefore every test follows the same pattern n order to emphass the relatve power values between dle states and workload states. Energy values should be compared consderng the system performance and number of workload operatons, thus we computed the energy effcency of a test workload executon. 65

66 Fg. 43 Idle PM and dle VM power consumpton and temperature P [W] HP desktop FSC laptop Wndows Lnux Fg. 44 Power consumpton of physcal systems under tests 3.4. CPU and memory workload vrtual machnes power consumpton The thrd set of test cases s performed n order to estmate power consumpton of the physcal system when runnng one or more VMs and each VM executes certan workload. Ths test case tres to estmate how physcal system s power consumpton vares wth dfferent types of CPU workloads or benchmarks when runnng on one or more VMs compared to runnng drectly on the physcal system. For the workload phase of the test sequence we used dfferent CPU and memory benchmarks: nteger, memory and floatng pont. Every test executon was parameterzed wth the followng settngs: the number of VM nstances, the runnng VM settngs (CPU cores and memory sze), and the number of smultaneous workload nstances (processes or threads). Every test case was executed once on the physcal system and then on the selected VMs. For every workload benchmark we logged also ts performance data n order to estmate the energy effcency for every test condton. 66

67 Research and Contrbutons n Energy-Effcency and Context-Awareness of Fg. 45 Lnux memory PM and VM workload power consumpton We have consdered two more memory test cases. The frst one compares the energy effcency of the same task executed on dfferent machnes and operatng systems: Wndows PM, Wndows VM, Lnux PM and Lnux VM. Power consumpton profles of the test workload executed on Lnux are shown n Fg. 45. It can be easly observed that the VM executon s more energy effcent than the PM executon and t s also best performng. Ths s a strange observaton that we cannot explan and t s repeated for all the tests wth sngle task workloads. Power profles obtaned after test executon under Wndows OS are shown n Fg. 46. Task executon on the VM n ths case s slower than t executon drectly on the PM. Fg. 46 Wndows memory PM and VM workload power consumpton Thermal profles for ths test case executon are shown n Fg. 47 for Lnux OS and n Fg. 48 for Wndows. 67

68 Fg. 47 Lnux memory PM and VM workload average CPU temperature In order to compare the four test executon n dfferent envronments, ther energy effcences were computed. The energy effcency of the RAM transfers workload s calculated dvdng the workload energy (Eworkload) to the sde to data. Energy effcency s measured as number of bytes per unt of energy consumed (Fg. 49). Thermal effcency of the VM/PM test executon s shown n Fg. 50. Fg. 48 Wndows memory PM and VM workload average CPU temperature 68

69 Research and Contrbutons n Energy-Effcency and Context-Awareness of Fg. 49 Energy effcency of memory transfers Fg. 50 Thermal effcency of memory transfers The second test emphaszes the varaton of PM/VM parameters wth varous number of test nstances runnng smultaneously. The average power consumpton values of test workloads when executed multple test nstances are shown n Fg. 51. The same workload s executed as one nstance whch means one sngle task runnng on PM or VM. Havng two test nstances means that the whole workload s splt n two equvalent applcatons that are executed smultaneously as two processes on PM or two dstnct VMs. Fg. 51 Average power consumpton of memory workload 69

70 Fg. 5 Energy effcency of memory workload multple nstances The energy effcency of the multple nstances test executons s shown n Fg. 5. Constant or small decreasng of energy effcency s observed when runnng tests on the ncreasng number of VMs I/O workload vrtual machnes power consumpton The fourth set of test cases s specfed to estmate power consumpton of the physcal system when t executes one or more I/O workloads wthn VMs. Wth ths test case we try to show how vrtualzaton nfluences the I/O operatons. One mportant aspect we want to cover wth ths test case s hard dsk I/O workload usng exstng dsk benchmarks. Other I/O test cases could also be mplemented lke USB, vdeo, sound, etc. In our test we ran only DISKIO test cases usng a dsk benchmark, parameterzed wth the followng settngs: the number of VM nstances, the runnng VM settngs (CPU cores and memory sze), and the number of smultaneous workload nstances (processes or threads). The two test cases wthn ths test set were selected to characterze power consumpton and temperature of I/O ntensve workload. Usng these tests the PM and VM dsk I/O workload can be compared. Power consumpton of I/O operatons have been performed usng hard dsk benchmarkng, usng a fle system benchmark tool runnng on dfferent platforms that generates and measures a varety of fle operatons: read, wrte, re read, re wrte, read backwards, read strded, fread, fwrte, random read. We executed the I/O workload wth dfferent parameters on both operatng systems under tests and both types of machnes (PM and VM). Power measurements for one test executon are shown n Fg. 53 and temperature profles are presented n Fg

71 Research and Contrbutons n Energy-Effcency and Context-Awareness of Fg. 53 Power profles of I/O workload tests Fg. 54 Temperature profles of I/O workload tests 10 % ncrease n energy consumpton for the vrtualzed task executon compared wth the PM one, s observed durng the tests. However, the temperature ncrease durng the I/O tests s moderate ( 3 o C), whch s smlar for PM and for VM. In Fg. 55 the concludng results of energy effcency of CPU, memory and dsk I/O tests are shown. Due to the mplementaton partculartes of L4Lnux memory operatons are less preformat than non vrtualzaton mplementaton therefore the energy effcency s lower wth ~5%. The dsk I/O operatons however are smlar on both platforms Ubuntu and L4Lnux. Another observaton s that L4Lnux mplementaton consumes less power than Ubuntu, when dle, on the same machne. 71

72 Energy effcency Ubuntu (1) L4Lnux (1) Ubuntu () L4Lnux() ramspeed [MB/J] dsko [0.1MB/J] Fg. 55 Memory and I/O operatons energy effcency 3.5 RELATED WORK A cornerstone n the energetcally evaluaton for vrtualzed systems s the measurement procedure and context for both physcal systems and vrtual machnes. Power consumpton of physcal servers s an mportant metrc used when evaluatng dfferent vrtualzed solutons mplemented on top of these servers. The power consumpton ssue of computng systems s n general a very complex one because every physcal component n the physcal system has ts own power consumpton profle dependng especally on ts executon workload. In vrtualzed envronments the power consumpton modelng problem s much more complex because software applcatons are runnng on VMs and they do not access drectly the physcal components. The host operatng system has to provde access to physcal components and share these components for dfferent VMs and ther applcatons. The nature of workload executed n each VM determnes the power profle and performance of the VM, and hence ts energy consumpton [Dhman009]. The complexty of measurng energy effcency for vrtualzed systems s ncreasng wth the number of elements that should be addressed (e.g. number of VMs, OS, PM, power management mechansms actvated, software applcatons runnng on VMs). The author of [Carpenter007] proposed and performed a set of vrtualzaton performance tests for three types of Intel mult core based servers n order to estmate whether ther vrtualzaton can delver sgnfcant benefts n data centers over non vrtualzed servers. Durng the performance tests overall power consumpton was measured and power consumpton per workload was computed n order to determne the costs of provdng the requested level of performance. Vrtualzaton enables one to consoldate multple workloads onto each server, ncreasng utlzaton and reducng power consumpton per workload [Carpenter007]. A CPU ntensve complex database applcaton was used as testng workload, and they progressvely ncreased the number of vrtualzed workloads. In our approach we use three types of smple operatons as workload n order to address the man components of the system: CPU, memory and I/O. Another mportant element n energy effcency evaluaton for vrtualzed systems s related to the power management mechansms and ther mplementatons. The authors of [Dhman009] presented a mult ter software soluton for energy effcency computng n vrtualzed 7

73 Research and Contrbutons n Energy-Effcency and Context-Awareness of envronments based on the characterstcs of the workloads co located on the same PM. The paper shows that co locaton of VMs wth heterogeneous characterstcs on same PM s benefcal for overall performance and energy effcency. In [Verma008] the authors nvestgate the desgn, mplementaton, and evaluaton of a power aware applcaton placement controller n the context of an envronment wth heterogeneous vrtualzed server clusters. Ther soluton dspatches applcatons to dfferent VM or PM takng n account performance requrements, mgraton costs and power consumpton. The tests and experments were executed based on the traces obtaned from server farm of a large data center. In [Tan007] specfc work related to power management of vrtualzed OS s presented. The authors tred to map vrtual ACPI power states of VM components (e.g. CPU P states, OS S states and devces D states) to real power states of the PM n order to ncrease the effcency of overall power management mechansm. Nathuj and Schwan explored n ther work how to ntegrate power management mechansms between VMs and host PM whle keepng solaton between them [Nathuj007]. They proposed and mplemented a software soluton called VrtualPower whch extends the VM power states and assgn specfc power polces to these states. Ther man challenge s agan to map VM power states to real power states of the PM. The authors of [Ye010] focused ther research work to power management of I/O dsk operatons n vrtualzed envronments. Ths paper presents three proposed mprovements to address the dsk s devce drvers power states mappng between VM and PM, based on the statstcs of I/O actvtes between PM and VM. Ther solutons are based on dfferent combnatons between bufferng mechansm n the PM that buffers wrtes from the VMs and early flush mechansm that flushes the drty pages from the guest OS buffer caches pror to puttng the dsk to sleep. A major challenge n computer systems s the coexstence of real tme and non real tme applcatons on the same machne. The authors of [9] descrbe the mcrokernel archtecture of L4 and whch provdes both vrtualzaton and real tme support. On a real tme capable mcrokernel, all applcatons are temporally solated and can execute wth real tme guarantees even they are vrtualzed. L4 Lnux s a para vrtualzaton soluton whch requres changes n the guest operatng systems n order to run n user space of the CPU. The changes are requred n platform specfc code of Lnux but all other code and devce drvers are unchanged. L4 Lnux was ported on IA 3 and ARM processors archtectures; therefore t may be used n the near future on next mult core moble devces. 3.6 SUPPORTING GRANTS, RESEARCH TEAM AND SCIENTIFIC OUTCOMES Project ttle: Embedded Mult Core Processng for Moble Communcatons Natonal competton: FP7 ICT Implementaton perod: Project acronym: emuco 73

74 Project code: 16378/ Budget: EUR Project summary: The am of the ICT emuco project s to develop a platform for future moble devces based on mult core archtecture. Ths comprses the relevant controller element as well as the operatng system and applcaton layers. A mult core archtecture has been used to obtan the best rato of performance and power consumpton whle mantanng the flexblty and scalablty of the system through varatons n number of cores, cache szes, or clock speed. Vrtualzaton technologes have been used to abstract the applcatons from the hardware layer archtecture. The project has generated a seres of results whch can be seen from three dfferent perspectves: software platform perspectve, hardware platform perspectve, and applcaton layer perspectve. The research team nvolved n the project ncluded experenced researchers, young researchers, and external advsors: Prof. Vladmr CRETU (local partner drector) PhD. Dacan TUDOR PhD. Georgana MACARIU PhD. Caln JEBELEAN PhD. Prof. Mha MICEA The man contrbuton to the project s the study on energy and thermal effcency of vrtualzaton solutons mplemented on the two OS used today: Wndows and Lnux. In order to acheve ths result the evaluaton methodology and measurement setup have been proposed and mplemented. Ths secton s based on the followng papers publshed by the author: [BDI14], [BDI16], [BDI17]. 3.7 CONCLUSIONS AND FUTURE WORK Ths secton explores how vrtualzaton nfluences the power consumpton of both physcal systems and vrtual systems and whch s the most effcent way to mplement such applcatons. We proposed a number of test cases that can be used to evaluate power consumpton and energy effcency of vrtualzaton systems. We run the tests on dfferent common desktop and laptop mult core systems. We performed the tests on several system components: CPU, memory, and I/O. In our tests we observed no sgnfcant ncrease n power consumpton when startng and usng several VMs on one PM. However an ncrease of approx. 1% per VM nstance was measured for PM. Furthermore when runnng CPU and I/O ntensve workloads on VM and PM we dd not observe sgnfcant dfferences n power consumpton absolute levels. But n term of energy effcency we estmated a decrease of 5 10% when the workload was executed on VM compared to ts executon on PM. Ths decrease n energy effcency s manly due to the decrease n performance. We am to contnue the present work on nvestgatng energy effcency of vrtualzaton solutons to develop an energy model for a vrtual machne and use ths model to buld an onlne software 74

75 Research and Contrbutons n Energy-Effcency and Context-Awareness of montorng tool used by a vrtual machne to estmate ts energy consumpton and thermal dsspaton. 75

76 4 USING POWER SIGNATURES IN ELECTRIC DEVICES CHARACTERIZATION 4.1 OVERALL DESCRIPTION AND RESEARCH OBJECTIVES Usng smart grd for developng ntellgent applcatons s a current trend of great mportance. One advantage les n the possblty of drect montorng of all devces connected to the electrcal network n order to prevent possble malfunctons and manage (optmze) the overall power consumpton n offce or resdental buldngs. Therefore, ths secton descrbes a method for an automatc detecton of the malfunctonng of consumer electrcal devces. Malfunctonng means any devaton of a household devce from ts normal operatng schedule. The method s based on a comparson technque, consstng n the correlaton, between the current power sgnature of a devce and an deal sgnature (the standard sgnature provded by the manufacturer). The frst step of ths method s to acheve a smplfed form of power sgnature whch keeps all the orgnal features. Further, the sgnal s segmented based on the data provded by an event detecton algorthm (values of the frst dervatves) and each resultng component s approxmated usng a regresson functon. The fnal step conssts of an analyss based on the correlaton between the computed regresson coeffcents and the coeffcents of the standard sgnal. Followng ths analyss all the dfferences are classfed as a malfunctonng of the analyzed devce. In our work we propose to montor domestc devces n order to automatcally extract ther workload power profles n order to dentfy bad usage habts, external condtons or agng and fnally falures of these devces. The man goal s to detect and model the nfluence of the dentfed elements on the energy effcency of the devces. In our approach we montor the target devces n order to extract power consumpton profles of dfferent applcatons, workload, external condtons or usage patterns. Next we apply pattern recognton algorthms to extract relevant behavor or patterns n the power consumpton seres of measurements. We call the dentfed patterns n the power profles, power sgnatures. Based on these sgnatures we further try to count devce specfc usage parameters and to dentfy abnormal behavor of the devce due to agng or malfunctonng. The fnal goal of our work s to propose an ntellgent house level centralzed soluton to montor, analyze, predct and control household devces n order to mprove ther lfe tme usage energy effcency. 4. THEORETICAL CONSIDERATIONS When montorng power consumpton of a devce or component a drect relaton between power varaton and component actvty can be observed. A consumer devce conssts of several nternal components connected to the same external power lnes (Fg. 56). Power lne s electrcal parameters can be measured by the mean of a power meter. Actvaton of each nternal component durng executon of one specfc task or program has an mpact on the electrcal parameters of the system, manly ts power consumpton. If two or more components are overlappng ther executon the overall mpact at the system level power consumpton s an addton of ndvdual contrbutons. 76

77 Research and Contrbutons n Energy-Effcency and Context-Awareness of Fg. 56 System powered components Power sgnature of a devce s defned as the power consumpton response to certan workload executed by the devce. In other words a power sgnature s the varaton n tme of power consumpton of the devce under measurement when t executes a program or task. Power sgnature s specfc to a devce and to a workload executed by the devce. Our goal s to use system level power sgnatures to dentfy component level actvty whle accountng for ther energy. Furthermore, our ntal assumpton was that based on a reference sgnature of a workng system, faulty or aged components of a consumer devce can be dentfed and then replaced. Power factor s a postve electrcal parameter and subunt sze that reflects the effcency of electrcal equpment fed wth alternatng current. Therefore the energy whch flow across the devce whch s vsble as apparent power symbolzed S [VA], and the flow of energy actually used for productve purpose equpment s symbolzed actve power P [W]. The value of the power factor s gven n the equaton (Eq. 17): cos( ) P cos( ) (Eq. 17) S Addtonal to these, there here s also so called reactve power due to the reactve component (manly nductve) consumer, symbolzed by Q [VAR] and also dstortng power (D) of the consumer due to nonlneartes (manly due to the rectfer crcut). P S Mentoned above parameters satsfy the relaton ( S (Eq. 18). P Q D S P Q D (Eq. 18) For mproved analyss n ths paper, the power factor was selected along wth actve power, both of them beng ndcated by the measurng equpment. When analyzng more consumers electrcal nterconnected, dynamc consumer program wll be characterzed by the followng parameters: power, power factor and speed varaton thereof. 77

78 Actve power and power factor of the system are gven n relatons ( P P cos( ) (Eq. 19) and ( n 1 cos ( ) P P 1 cos( ) 0). n P 1 (Eq. P n P 1 (Eq. 19) cos( ) n 1 cos ( ) P P 1 cos( ) P (Eq. 0) where P and cos( ) are specfc parameters of each nterconnected equpment n the system. For every type of devce that s an ndependent power consumer, we can establsh dfferent power profles (or power fngerprnts), that denote the power consumpton of the devce for a gven utlzaton profle (e.g. usage pattern, appled stmul or workload). In our tests we observed that every electronc devce has a specfc power consumpton profle. We grouped the consumer electrcal devces n three classes accordng wth ther bult n electronc ntellgence or ther workload complexty: Low ntellgence devces are consdered the consumer electrcal systems wth no or low bult n ntellgence. In ths class we nclude refrgerators, washng machnes, heatng devces, ar condtonng devces, etc. Medum ntellgence devces are consdered the electronc devces contanng some level of electronc control features: TV sets, rado devces, CD players, DVD players, set topboxes, fxed phones, etc. Hgh ntellgence systems are the computng class of systems contanng at least one certan type of central processng unt lke mcroprocessors or mcrocontrollers. In ths class of devces we consder: desktop PC, notebooks, PDAs, SmartPhones, prnters, network devces, etc. We understand by power profles the varaton n tme of power consumpton measurements related to usage pattern appled to the component. We defne one profle per component and workload type n order to see how component power consumpton changes wth component s parameters when the workload s appled. Test methodology we used to extract power consumpton profles addresses the power states of target devces. Every devce has at least two power states (on and off) whle most devces mplement more power states: off the devce s turned off, but t remans plugged n; 78

79 Research and Contrbutons n Energy-Effcency and Context-Awareness of sleep or stand by the devce s n one of ts power savng states, where t wats for certan commands to swtch n actve state agan. In sleep states a devce s not completely swtched off n order to retan at certan level the last actve devce state or context, so that the actve state can be easly actvated; actve the devce s turned on and executes ts actvtes. Power sgnature of an electronc devce s defned as the power consumpton response to certan workload executed by the devce. In other words a power sgnature s the varaton n tme of power consumpton of the devce under test when certan usage pattern or executon workload s executed by the devce. Power sgnature s specfc to a devce and to a workload executed by the devce. The power sgnature of the workload s the composton of power consumpton measures of each acton needed to sustan the workload. A power event s defned as a change n power values of a devce that dentfes a specfc functonal event of the product (Fg. 57). A power workload s a complete set of actons a product executes n order to provde ts servce. Every actvty or acton has ts own power consumpton whose profle depends of the type of electrcal or electronc devces that mplement them. Power sgnature P [W] t [s] Fg. 57 Power events and power workloads The composton of power measures of several actvtes are depcted n Fg. 58. Every subsystem of a devce has ts own power consumpton. The subsystems work together to complete the executon workload. The workload power sgnature s the composton of power varatons of the devce subsystems or components actvated durng workload executon. 79

80 Actvty type 1 power varaton Actvty type power varaton Fg. 58 Power actvtes composton Obtanng the power sgnature of an electronc devce s a smple task to acheve. We need to place a power electrcty meter connected to AC lnes of the electronc devce under test. The ntellgent power montorng soluton, presented n the next sub secton, was used for the executon of the power characterzaton tests. Such a test s needed to emphasze the energy consumpton of one specfc program or workload of the devce under test. 4.3 MEASUREMENT INFRASTRUCTURE TEST BENCH The proposed power measurement nfrastructure ams to address a wde range of needs n ths doman, and that was the startng prncple n the desgn process. We have to take nto account dfferent usage scenaros n order to satsfy as many requests as possble. Also, gven the use of the wreless sensors, the topology of the locaton has to be accounted for. That s why an ncremental desgn process was selected, whch allows for developng a base soluton whch serves only a small segment of clents, and then extend t wth more functonalty at each step. The types of devces we targeted to montor do not vary consderably. Ths means that the hardware needed n the mplementaton of ths soluton s the same for all devces, whch lowers the development costs. From an archtectural pont of vew, our system s farly smple. There are three man components that nteract n order to fulfll the purpose of the soluton. These parts are: a wreless sensor network, a central unt and a web server (Fg. 60). 80

81 Research and Contrbutons n Energy-Effcency and Context-Awareness of Fg. 59 Overall montorng archtecture The sensor network s responsble for acqurng power measurements from the targeted devces and transmttng them safely to the central unt. There are two types of nodes n ths network: the coordnator, whch s connected to the central unt and end ponts, whch are connected to the montored devces. An end pont sensor node s equpped wth a wreless communcaton devce, a power measurement devce and a mcro controller whch controls the actvty locally. The central unt can be mplemented wth an embedded devce (e.g. Raspberry PI or Arduno) or a desktop PC system. The only requrements for the central node are to have seral communcaton port and Ethernet nterface. The wreless network coordnator s attached through the seral COM port to the central unt, n order to lnk t to the sensor network. It s here that all measured data s gathered, analyzed and structured n order to make t easer to access. It offers a vsual nterface for the setup process of the system, when all the devces that need montorng are regstered wth the applcaton and the functonng parameters are set. These parameters consst of an ndvdual dentfcaton number and name for each devce, the connecton parameters for the lnk wth the data server and the clent account detals. The thrd unt of the soluton s a web server. Its man responsbltes are to store the measured data from all the clents of the servce, and to make them avalable for analyss. In order to complete these tasks, the server has two man parts: a set of Wndows Communcaton Foundaton servces for the communcaton wth the central unts and an ASP.NET applcaton that provdes the user nterface. Addtonally, a user account control system s mplemented n order to ncrease securty, such that not to allow one clent access to another clent s data. The desgn of the hardware n the parts that were bult by us also mpled makng use of the knowledge gathered from dfferent felds. The desgn of the AC power measurement unt was nspred from the notons presented n electrcal engneerng textbooks. The DC power measurement uses electronc notons, but was smplfed by usng an already avalable shunt 81

82 montor. The ntegraton of the components of a sensor node nto a untary board needed hardware layout and dgtal logc sklls. The desgn of the code that runs on the mcro controller s n a close bond wth ts hardware archtecture, and the usage of dfferent components, lke the analog dgtal converter, seral nterfaces or operatonal amplfers, requres a thorough understandng of the functonng of such devces. Fg. 60 Overall hardware archtecture In Fg. 60, we present the hardware archtecture for the proposed soluton. Ths desgn s bult around the central unt (called ebox) whch s consdered the central embedded element of the system. Together wth the sensor network coordnator, the ebox forms the central unt. The nterface between the two s mplemented through a seral COM port. Also, the components of a sensor node are specfed n the fgure. These are the XBee module, an ATmega16 mcro controller and the measurng devce adapted to the type of element whch needs measurng. The AC power montor sensor node wth XBee connecton, presented n Fg. 61, provdes a power socket wth the attached montorng and communcaton modules. Fg. 61 AC sensor node 8

83 Research and Contrbutons n Energy-Effcency and Context-Awareness of The software s structured n three separate stand alone applcatons: (1) the embedded (ebox) component whch can collect data from the sensors and also control them; () the Web portal whch can be used to represent data n a logcal and frendly fashon; (3) the Web Servce whch holds the logc to access and modfy the data for outsde consumers (clents). All was centered on the data logc and modeled as a separate project wth logc shared between the other components (servce, reports, web portal, admn applcatons). As a development platform we used.net 4 wth ts enhancements for Entty Framework and ASP MVC. For modelng the data layer t has been used Entty Framework 4 and Unty.0 n order to assure a persstence and context gnorant scenaro for each applcaton ths was deployed to. Persstence gnorance was assured by POCO objects (a feature ntroduced n Entty Framework 4) whle the context gnorance was handled by makng use of Dependency Injecton found n Unty.0 Framework. On top of ths came the servce wth ts logc to access and modfy database sensble content. The Servce was done wth WCF and f the clent supports WS Bndng, than t can make use of sessons (dfferent nstance/sesson) enablng cachng and logc enhancements. The Webste was meant to provde frontend busness capabltes and was developed wth ASP MVC.0 makng also use of the same logc as the servce. Rch clent graphcs and effects were accomplshed by usng jquery wth some of ts famous controls/plugns (apple lke menus, tabs, grds) whch we enhanced to support dfferent busness scenaros for example pagng n grds, autocomplete n combo boxes. The software part of the system s descrbed n Fg. 6. As mentoned before, the varous components follow the general system archtecture, wth the code on the ebox beng the one offerng the man functonalty. The applcatons wrtten n dfferent levels of the system have dstnct characterstcs and are descrbed below. Frst, we frst have the low level code that s wrtten for the mcrocontroller n the sensor nodes. There s a separate part that regards the coordnator. Ths conssts of the seral communcaton protocol for the connecton wth the ebox. The code on the endponts dffers from the one wrtten to the coordnator, because the controller on the endpont has to communcate wth the measurement devce and read data from t. So, the seral nterface s replaced by the nterface wth the devces. Both types of sensor nodes mplement a communcaton protocol between them, whch bulds on top of the already exstng layers. Second, we have the software on the ebox, buld on top of a Wndows Embedded 6.0 Image. The ebox gathers all data from the montored devces and stores t usng the compact verson of SQL Server 008 for embedded devces. A montorng module congregates data nto clusters of measurements comng from the same source and adds a tmestamp to make chronologcal orderng possble. 83

84 Fg. 6 Overall software archtecture Then a mld analyss s done to remove nconsstent data from the clusters, such as msreads or values that could not practcally exst, but are reported due to specfc events n the power lne, especally n alternatve current. After the analyss, the data can be stored nto the database. After the analyss, the data can be stored nto the database. In ths state, the data s structured nto chronologcal data samples from the same source, and each source has ts own data. Reportng and analyss features were provded by Mcrosoft s Reportng Servces 008. Data was stored n Mcrosoft Sql Server 008 R. Though not mplemented yet n the web portal, support for localzaton (example Bng Maps) t s present. One mportant step toward our research goal s to fnd a smple, effcent and general method of power sgnature extracton and analyss n order to deeply characterze the operaton of varous consumer devces. The workflow of the power sgnature and product workload detecton software applcaton s shown n Fg. 63. Power meterng nfrastructure contnuously measures the electrcal parameters of the consumer devce and stores data nto the measurements database. Measurements database feeds two software components one that detects devce specfc events from the power seres and the second that detects devce specfc workload. The database also contans the deal power sgnature computed n advance at nomnal workload parameters. A power event s defned as a change n power values of a devce that dentfes a specfc functonal event of the product. A power workload s a complete set of actons an electrcal devce executes n order to provde ts ntended servce. 84

85 Research and Contrbutons n Energy-Effcency and Context-Awareness of 1 Measurements DB Power seres Power events detector Power seres Power events Power workload detector 3 Power sgnature Power sgnature normalzaton 4 Normalzed power sgnature Power sgnature classfer 6 Workload detecton Pass / Fal Ideal power sgnature Power metrcs extracton 5 Power consumpton metrcs Fg. 63 Power workload detecton workflow 4.4 EXPERIMENTAL RESULTS An analyss of the entre power sgnature s dffcult for an anomaly detecton algorthm usng correlaton. Because of that, we decded to splt the obtaned shape nto peces (components) that can be analyzed more easly. Furthermore, such segmentaton provdes us a better localzaton of anomales. Furthermore, the analyss should be personalzed for each knd of electronc devce, because of the dfferences and ther specfc parameters. Hence one case studes wll be gven n ths secton, addressng a laundry washng machne (medum ntellgent devce) Devce under analyss In our nvestgaton we analyzed power profles of a washng machne produced by Wrlpool (AWO/D43135) mplementng the 6 th sense technology. The power lne electrcal parameters have been measured contnuously usng the proposed nfrastructure usng a samplng rate of 1 Hz. In our tests we are nterested only n statc parameters therefore the samplng rate s enough for our goal. For the purposes of ths case study the system s a washng machne whch we consder as an ensemble of nterconnected electrcal nternal component, each one havng a specfc purpose: nlet water, water heatng, clothes agtaton content, water (and detergent) trays, dran water, and squeezng (Fg. 64). Water admsson s carred out by means of a solenod valve. Dranng the water s carred out by means of an electrc pump. Washng process s accomplshed by rotatng a drum drven by a DC motor fed by an electronc drver that controls speed rotaton. Water heatng s acheved wth an electrcal heater (resstance). The washng cycle s done by the washng machne controller. Of course there here are also other equpment: water level control (pressure swtch) and water temperature (thermal resstance) all of them beng automatcally montored by the wash machne controller. These have no observable mpact on consumpton them beng consdered as passve components. Also access door has a lock devce aganst openng durng the runnng of the program. Ths lock devce s operated thermal resstance coupled to a bmetal that drves the lockng devce. 85

86 Fg. 64 Block dagram of the washng machne under test 4.4. Power sgnature analyss Power consumpton varaton durng executon of a washng program for synthetc laundry heated at 40 o and centrfugaton at 1000 rpm, s presented n Fg. 65. We selected n our tests one sngle type of washng program n order to detect power sgnature varatons dependng on changes n the envronment (e.g. water temperature) and nternal load (e.g. laundry weght and type). The power sgnature of one washng program s very smlar from one executon to another. We can consder thus, the power sgnature a characterstc of one specfc washng program. However, changes n power sgnature from one executon to another wll occur due to the changes of program parameters. Fg. 65 Power sgnature of the washng program The washng program executon phases can be easly seen n Fg. 65: startup and water admsson A1; heatng (H1) and washng W1; three rnsng phases (R1, R and R3) and fnal three dranng phases (D1, D and D3). They are further descrbed here. 86

87 Research and Contrbutons n Energy-Effcency and Context-Awareness of Fg. 66 Phases of the washng program: (a top left) water admsson sgnature; (b toprght) heatng and washng phase; (c bottom left) heatng and washng phase; (d bottomrght) rnsng phase Water admsson phase allows water to enter nto washng machne tub and soak the laundry for a whle. Durng water admsson, the admsson valve s open whle the engne slowly spns the washng tub. The engne actvty s revealed n the power sgnature (Fg. 66 a) as 10 seconds long spkes occurrng at regulate ntervals (approx. 16 seconds). The power consumpton of the engne ncreases steadly durng water admsson because of the ncreasng force needed to spn an ncreasng weght of water and soakng laundry. Pm s power consumed by the engne when spnnng slowly the laundry once the admsson valve has been closed. The ncrease n power consumpton of the engne from the frst actvty untl the admsson valve s closed, Pw, s dependent on the volume of water and weght and type of the laundry. If we look at the bottom lne of the power sgnature, two power levels can be observed: Pv and Pc. Ps s manly the contrbuton of the admsson valve but t ncludes also Pc that s the contrbuton of the controller board, consdered constant durng the washng program. Therefore, analyzng the power sgnature of the water admsson phase we dentfed power consumpton of three components: engne (Pm), admsson valve (Pv) and controller board (Pc). Pc s a constant value n the power sgnature that has to be subtracted from all other components. The man washng task takes place mmedately after the water admsson valve s closed. It has two man parts: heatng the water and spnnng the laundry wthn the tub. In ths phase one more component becomes actve: the electrcal resstance used to heat the water (Fg. 66 b). Ph s power 87

88 consumpton of the resstance requred for heatng the water. Heatng H1 duraton depends on the temperature of the water and target temperature requred by the washng program. Subsequent heatng events, smaller n duraton, can also occur durng ths phase. The man washng phase s fnshed wth used water dranng out of the tub Fg. 66 c. Pp n the sgnature s power consumpton of the dranng pump. Analyzng power sgnature of ths phase four components can be dentfed: heater (Ph), motor (Pm), evacuaton pump (Pp) and controller board (Pc). The power sgnature of the rnsng phase s presented n Fg. 66 d. Durng ths phase a hgher volume of water s used generatng a hgher power consumpton (Pr). The frst part the water admsson valve s open whle n the last part, the pump s used to empty the tub. The phase ends wth hgh speed spnnng n order to squeeze and remove the water out of laundry. Analyzng power sgnature of ths phase several components can be dentfed: motor spnnng wth small water level nsde (Pm), motor spnnng wth maxmum rnsng water volume nsde (Pm+Pr); admsson valve (Pv); evacuaton pump (Pp) motor hgh speed spnnng (Ps) and controller board (Pc) Ideal power sgnature The frst step n our analyss has been to propose and dentfy a normalzed or deal power sgnature of one specfc washng program. Ths was acheved by usng a smoothng flters and edge detecton algorthms. The best results were obtaned by applyng a Gaussan smoothng functon and frst dervatve edge detecton. These post processng outcomes can be seen n Fg. 67. By smoothng the perodc low speed engne actvty s fltered out n order to detect automatcally the man phases of the program. An event detecton algorthm s necessary when we are searchng for certan peces of a sgnal or when we are tryng to segment the sgnal n multple parts. Ths algorthm detects all the behavoral changes that occur n sgnal evoluton. Fg. 67 Smoothng flter and edge detecton results 88

89 Research and Contrbutons n Energy-Effcency and Context-Awareness of Power Factor Sgnature Analyss Power factor s a postve electrcal parameter and subunt sze that reflects the effcency of electrcal equpment fed wth alternatng current. Smlar to power sgnature, power factor varaton for the washng program s presented n Fg. 68. In case we draw the relaton between power factor and actve power for the whole program, we obtan the graphc n Fg. 10. Two clusters can be observed n Fg 10: one dentfes the heatng phase H1 and the second one ncludes components requred by all other phases. These components are however hdden by the sze of the frst component. Fg. 68 Power factor sgnature of the washng program In case we plot power factor and power consumpton for each phase ndvdually, components consumng less power reveals n the graphc as seen n Fg. 69for R1 rnsng phase Fg. 69 Power factor and actve power consumpton for rnsng phase Sgnal segmentaton Sgnal segmentaton s done based on the sgnal obtaned from the event detecton algorthm. A smplstc approach n ths case could be: any non zero value of the sgnal could be seen as a change n the behavor of the devce. The hgher the value, the greater change has occurred n sgnal evoluton n that moment. Ths approach cannot be done n our case because the sgnal shows contnuous oscllatons and that s why most of the values are non zero. Analyzng the values obtaned from event detecton 89

90 algorthm, we chose a cuttng threshold that separates a neutral area (values between [, ]) for an area of nterest for us. Usng ths threshold, the mportant components of the sgnal can be seen n Fg. 70. Fg. 70 Detecton of sgnal components usng an algorthm based on values from event detecton method and after applyng a threshold cut Fg. 71 Detecton of short tme ntervals where sgnal has a transent behavor (anomales) These components succeed segmentaton for a power sgnature sgnal nto consttuent parts. Also, the algorthm manages to detect other short tme ntervals too n whch sgnal have a transent behavor (Fg. 71). It can be observed the presence of these ntervals n the begnnng/end of the whole program and when rnsng cycle starts. Because these ntervals have a short perod of tme, an automated analyss of them could not be done, so they were analyzed n a separate mode. The other proposed segmentaton method s based on normalzaton of a sgnal accordng to another sgnal. For ths method we need a prevous processed sgnal (standard sgnal consdered to be a normal behavor of the devce). Ths sgnal must have segmentaton ntervals defned n advance by the user. Further the normalzaton operaton s performed n the tme doman for our sgnal and after that, the segmentaton operaton s appled to tme ntervals obtaned from the standard sgnal. 90

91 Research and Contrbutons n Energy-Effcency and Context-Awareness of Fg. 7 Segmentaton usng a standard sgnal for other two dfferent sgnals Fg. 73 Sgnal component reconstructon usng polynomal regresson 91

92 In Fg. 7 we can see the segmentaton result for two sgnals usng a standard sgnal. Some components have faled to be detected and for others the begnnng / end are totally wrong. The results vary from sgnal to sgnal and that s why we propose ths method to be used only as a secondary one Regresson functon for sgnal components Defnng a regresson functon for each sgnal component s an mportant part of our approach because an analyss of the sgnal s much easer to be done n ths case. Thus, a functon s characterzed by a reduced set of values (parameters) than a relatvely large number of sample sgnals. For our sgnal, we try fndng regresson functons from three classes: polynomal, exponental and a combnaton of snuses. For a polynomal regresson varant we chose a polynomal of nne degree. Usng a polynomal of degree greater than nne s dffcult and leads to obtanng coeffcents wth values less than Fg. 73 presents the reconstructon of some of the sgnal components where polynomal regresson functons are used. It can be seen that some sgnal components cannot be exactly reconstructed usng polynomal functons. Fg. 74 Sgnal component reconstructon usng exponental regresson 9

93 Research and Contrbutons n Energy-Effcency and Context-Awareness of Fg. 75 Sgnal component reconstructon usng combnaton of snuses For the second method we used multple regresson exponental functons. The obtaned results for the same components of the sgnal are shown n Fg. 74. In ths case, the components of the sgnal were reconstructed even worse (component 3 could not be reconstructed). The last regresson method uses a combnaton of snuses (Fg. 75). It can be seen from Tab. 3 that usng the combnaton of snuses we obtan the best results (e.g. the smallest error). Further we used ths method to fnd the regresson coeffcents for each component of the sgnal. Regresson method C1 C C3 Polynomal *10 6 Exponental *10 5 Combnaton of snuses * *10 7 Tab. 3 Coeffcents Calculaton of correlaton ndces between two components Correlaton s a statstcal measure that determnes the dependences between two data sets and from our pont of vew; t has an mportant role as t hghlghts the relatons of two sgnals. The correlaton method s based on Pearson product moment correlaton coeffcent and t s named "Pearson's Correlaton". If we defne two sets X and Y, the correlaton coeffcent ρx,y s gven by E X Y ( X, Y cov( X, Y ) X Y (Eq. 1). X Y X Y 93

94 X, Y cov( X, Y ) E X X Y Y (Eq. 1) X Y X Y To calculate the correlaton coeffcents we need two data sets of equal length. In order to do that we should determne the sgnal component that has the largest length (the total number of contaned ponts). For all the remanng components wll be added (at the end) multple zero values untl we get a vector of length equal to the determned maxmum length. Thus, each component wll be composed of a number of samples equal to the maxmum length. Further, we present a correlaton analyss based on three sgnals (see Sgnal 1, Sgnal and Sgnal 3 from Fg. 76) Each of these three sgnals wll be compared wth the sgnal presented throughout ths paper named the standard sgnal. Each component of a sgnal wll be compared wth each of the components of the standard sgnal. A correlaton ndex between the two components wll be calculated for each comparson. For example when we compared the Sgnal 1 wth the Standard sgnal, actually we compared the 7 components found n Sgnal 1 wth the 6 exstng components n Standard sgnal (Fg. 77). The correlaton matrx resulted after comparson operaton can be seen n Tab. 4. We noted by SC, the component of standard sgnal and Cj the j component of the Sgnal 1. Fg. 76 Sgnals used n correlaton analyss. From top to bottom: Sgnal 1, Sgnal and Sgnal 3 94

95 Research and Contrbutons n Energy-Effcency and Context-Awareness of Fg. 77 Top: Standard sgnal contans SC1 - SC6 components. Bottom: Sgnal 1 and C1 - C7 components Sgnal 3 SC 1 SC SC 3 SC 4 SC 5 SC 6 C C C C C C C Tab. 4 Correlaton matrx Correlaton analyss. Determnng smlarty and anomaly detecton It can be seen from Fg. 77 that Sgnal 1 s very smlar to the Standard sgnal. Ths s also revealed by the matrx of correlaton coeffcents. Thus: Component C1 and C from Sgnal 1 are very smlar wth the SC1 and SC components from Standard sgnal (0.983 respectvely 1.000). That means that the washng machne works fne n the frst part of the program and does not show any anomales. Component C3 from Sgnal 1 s very smlar to the component SC1 from Standard sgnal (0.95 smlarty) but also wth component SC3 from Standard sgnal (0.811 smlarty). Ths s due to the fact that the C3 from Sgnal 1 has a double length (n tme) than the smlar component from the Standard sgnal. Agan, we can conclude that there are no anomales present. Component C4 from Sgnal 1 has smlarty wth the component SC5 from Standard sgnal (0.697 smlarty). Ths means that a slghtly wear of the machne s present n ths part of the program. 95

96 Component C5 from Sgnal 1 has much smlarty wth the component SC5 from Standard sgnal (0.741 smlarty). Agan, we can menton a slghtly wear of the machne for ths part of the program. Component C6 from Sgnal 1 s very smlar to the component SC4 from Standard sgnal (0.871 smlarty). Because all the SC4, SC5 and SC6 are part of the rnse cycles, there s not a bg ssue, that ths component s most smlar wth a component other than SC6. Component C7 from Sgnal 1 s very smlar to the component SC3 from Standard sgnal (0.881 smlarty). Ths s an anomaly because the two components are part of dfferent washng cycles. The frst s from rnse cycle and the last s from wash cycles. Wthout C7 we have a smlarty value of 0.85 between Sgnal 1 and the Standard sgnal. That means a strong correlaton between the two sgnals. An analyss for the Sgnal showed a correlaton of 0.83 between the two sgnals. It also revealed the exstence of another component (smlar wth C3) n ths sgnal. Ths s also an anomaly and can be observed n Fg. 76. The correlaton for Sgnal 3 s only 0.793, so there are many smlartes between the two sgnals (there s a good correlaton). Also the analyss detected that the C3 for the Standard sgnal does not have a counterpart component n Sgnal 3. The absence of a standard component represents also an anomaly Synthetc analyze on components Based on analyss done on data acqured of values for power consumpton and power factor of the system, components have values of parameters gven n Tab. 5. These values remans unchanged from one program executon to another. Other parameters, such as program duraton, number of rotatons, duraton and number of heatng power are varable, for the same washng program. These parameters are varable because the washng program s adaptve functon on actual sensors values. Equpment Actve power [W] Power factor [%] Varablty Electrc heater very low Electrc motor <50 hgh (0.065 Hz) Evacuaton pump 0 30 very low Solenod valve very low Tab. 5 Component level power estmaton 4.5 RELATED WORK Durng last decade a consderable amount of research and development work has been undertaken to mprove energy effcency of electrcal products and to buld an ntellgent nfrastructure for power dstrbuton, montorng and predcton. There are a large varety of research and development drectons startng wth energy meterng devces, contnung wth energy proflng of 96

97 Research and Contrbutons n Energy-Effcency and Context-Awareness of dfferent products and endng wth varous applcatons developed on top of ntellgent power grd and meterng nfrastructure. In our work we drect our efforts toward energy effcency applcatons based on power sgnatures and usng the meterng nfrastructure we bult. All ths soluton we call ntellgent montorng, analyss, predcton and control energy effcency platform. Reducng energy consumpton of electrcal devces has both economc and ecologc benefts, but t also opens new research drectons related to the nterpretaton of power consumpton data. The research drectons we are explorng n our work s: energy and power sgnatures defnton and ther characterstcs; the relaton between usage patterns, power profles and energy sgnature; and new applcaton aware power management technques for energy effcency. In ths secton we frst dscuss current tools for montorng electrcal consumpton then we present some research papers whch address power and energy montorng and analyss. Nowadays there are a number of optons for measurng ether the power consumpton at the level of a whole buldng or the power consumpton of an electrc product usng an on the self devce lke Kll A Watt or Watts Up Pro. In [Fehrenbacher009] there are presented ten energy montorng tools: EnergyHub, Tendrl, Onzo, Aglewaves, Google PowerMeter, GreenBox, The Energy Detectve, PowerMand, Green Energy Optons, and Energy Aware. It s out of the scope of ths paper to present and compare all these devces, but [Fehrenbacher009] s a good startng pont to explore these solutons. The author of [LeBlanc007] proposed an electrcal power montorng system contanng dstrbuted unts that transmt power consumpton data wrelessly va RF rados to a central base staton. The desgned montorng unts plug nto an outlet and then the devce beng montored s plugged nto them. The base staton parses the ncomng data from multple montors to determne the power consumpton of each devce n order to have an overvew on overall power consumpton. Our meterng soluton s smlar wth the soluton descrbed n [Berges009] n terms of hardware overall archtectures but t much more orented to applcaton level to offer nfrastructure for top level energy effcency applcatons. In [Adamo007] the authors proposed to mplement a vrtual nstrument for the electrc power qualty montorng amng to act n real tme for detectng, montorng and recordng all typcal dsturbances supermposed on the deal sgnal. Ther goal s to extract the voltage and power qualty parameters for the power dstrbuton network. The authors present a completely dgtal method for the fast and accurate montorng of the electrcal power qualty useful to produce real tme qualty/ dsturbance reports. In the paper, the mathematcal bass of the proposed estmaton algorthm s dscussed n terms of relablty and uncertanty. Ths work s dfferent from ours because we do not address the qualty or dsturbances of power lnes but we consder the power sgnatures and ther relaton wth the usage pattern of the devce. An nterestng dea s presented n [Berges009], where the authors try to fnd a way to obtan detaled nformaton about electrcty consumpton n a buldng, at a low cost, wthout the usage of dstnct power meter for every target devce. They ntend to acheve ths goal usng a nonntrusve method, maxmzng the use of the exstng nfrastructure rather than mposng the need to nstall varous new devces n the buldng, thus reducng the assocated hardware and labor 97

98 costs. In order to splt overall power consumpton data they bult a data acquston system that samples voltage and current at 100 khz and calculates real and reactve power, harmoncs, and other features at 0Hz. The authors showed that under certan condtons dsaggregatng the total power consumpton between dfferent plugged devces s an achevable task, and can be done wth a relatvely hgh degree of accuracy. However, the problem s much more challengng n the real world, where not only does the number and type of applances ncreases, but also the measurements are susceptble to more nose and obtanng ground truth data becomes more dffcult [Berges009]. Furthermore, they dd not take n account complex devces, lke computers, whch do not have constant levels of power consumpton, but t vares sgnfcantly wth the runnng applcatons. Energy effcency and power consumpton profles are other mportant research topcs dscussed recently n the lterature. In [Crosbe008] the author explores the energy ntensve behavors of the users and how they are encouraged by the desgn, marketng and servces supported by consumer electroncs. The study based on the data collected from 0 households for TV products concludes that energy consumpton of household consumer electroncs s to be reduced ths wll necesstate the development of new products and servces that are not based on redesgn or ncremental changes to exstng products and servces; but rather on provdng the consumer wth the functon and style they requre, n the most energy effcent way. McAlster et. all nvestgate n [McAllster007] another growng type of devces and household energy consumpton patterns: chargng batteres of moble and battery powered devces. Ther study pont that the large number of battery powered devces nduce a large and ncreasng amount of consumed energy at macrolevel and about only 15% of ths energy s used for battery chargng, the rest s lost as waste heat durng no load and charge mantenance perods [McAllster007]. In [Elas009] the authors propose and demonstrate a methodology for quantfyng the energy mpacts of user behavors for dfferent resdental products. They follow the product lfecycle and break down the overall power consumpton of the devce n several values. Frstly the user related value whch s related to neffcent use. Secondly the ntrnsc value, whch are the energy losses assocated wth the desgn and constructon of the product, based on the ntrnsc engneerng technology and materals that have been used. And lastly a theoretcal mnmum value, whch s an amount of energy that must be used n order for the product to delver ts desgned functon, below whch t s mpossble to go due to the laws of physcs [Elas009]. One of the frst uses of the power sgnature occurred n the PCB (prnted crcuts boards) ndustry. In order to dfferentate whether a PCB operates normally or exhbts abnormaltes, the voltage and current values were recorded durng a contnuous operatng mode [Mller1999]. After that, these values (power sgnatures) are compared wth a standard shape, representng the normal operatng mode for the boards. The resulted dfferences consttute a startng pont n the decson process that specfes whether there can be operated problems wth the board. Current researches are performed wth the ad of complex devces. Most of them are focused on the need of low consumpton of domestc users. A recent study [Froehlch011] provdes an nterestng soluton for dsaggregated consumpton of each electrcal devce used. The authors manage to extract nformaton that ultmately leads to a soluton to calculate the power 98

99 Research and Contrbutons n Energy-Effcency and Context-Awareness of consumpton for each devce. It should be noted that much of the research s focused on how to obtan the power sgnature, because the author does not am to make an analyss process. Startng from ths, we must menton that there are numerous solutons to obtan the power sgnature. A new soluton s proposed n [Ou01] and uses the new concept of Internet of Thngs (IoT) n order to speed up the process of data acquston. In ths way, the authors ensure us that t can prevent certan natural dsasters and also, the transmsson of nformaton s done wth a low cost. There are many methods for analyzng the power sgnature and extractng the mportant nformaton from t. We start by presentng a method for classfyng domestc devces usng two features: the power sgnature and the harmonc features. [Huang011] Ths study attempts to solve the problem of how to predct the power consumpton especally for resdental housng. For ths purpose, t determnes several categores of consumer and tres to classfy every devce n a certan category. A postve outcome of ths approach les n a better understandng of the power consumpton by the resdents. Ths artcle seeks to determne how a power sgnature s changed when there appears some malfunctonng of the electrcal devce. Ths s done by comparng the current power sgnature wth an deal sgnature (obtaned by the manufacturer n the normal operaton mode). Smlar goals had as well the projects descrbed n [Lee01] and [Jang009]. The research n [Lee01] focused on two man drectons: (1) the dentfcaton of a method capable to determne the load characterstcs of a devce and () several ways of sgnal processng needed to determne varous types of workload for the analyzed devce. The authors of [Lee01] used the AC voltage and current sgnals and ther detaled varatons. In our work we used the hgh level dgtzed measured values of actve power, voltage and current consumpton. The authors of [Jang009] explan the method by whch there was mplemented a soluton used for montorng the AC (ar condtonng) devces. Usng a sensor network, t s controllng several AC devces n dfferent types of buldngs. The paper s focused on the montorng soluton presentaton that s manly used for energy usage reportng and analyss. However, some power sgnatures of daly usage patterns for several offce and consumer devces are presented and dscussed. But no automatc power sgnature analyss s presented n [Jang009]. An nterestng analyss [Drf014], based on power sgnature s made n order to detect the type of fault whch can appear nto an nducton motor drve. The analyss attempts to separate the electrcal faults cases from mechancal faults. Detectng faults n an electrcal devce, usng dfferent sgnatures (e.g. load sgnatures or frequency response analyss sgnatures) was also the goal for the authors from [Hassan014] and [Abu Sada013]. Fndng the best operaton mode of the electrcal devces, by studyng the power sgnature, was also the man goal n [Jang009]. The authors used varous sensors to montor the ar condtonng devces, and based on obtaned data, they presented and dscussed some usage pattern for dfferent buldngs. However, the presented soluton can't be obtaned nto an automatc way and s not adaptable durng tme. 99

100 Detectng exstng nose nto resdental power lnes s another study that supports dea of montorng house applances through the smart grd nfrastructure [Patel007]. The authors rely on the fact that flppng a swtch could produce a nose (sngular or contnuous) that can damage electrcal applances exstng nto a house. As an earler work we can pnpont the work of Farnacco et Al. that developed an algorthm able to fnd operatng pattern of electrcal applances (each pattern was assocated wth an electrcal devce) [Farnacco1999]. They tred to decompose the total consumpton exstng nto a house n dfferent parts, each part havng assocated an electrcal devce. A smlar approach was realzed by the load dsaggregaton algorthm [Marceau000]. By comparng a change nto the total power system wth each operatng applance sgnal, t tred to determne the home applance responsble wth that change. Recent developments n the smart grd permt the usng of phasor measurement unts (PMUs) to detect possble anomales nto system [Armena010]. Recently, mplementatons of FNET (frequency montorng network) use PMU for a better detecton of anomales [Zhang010]. 4.6 SUPPORTING GRANTS, RESEARCH TEAM AND SCIENTIFIC OUTCOMES Ths work has been partally supported by the MobPower project presented before. The ntellgent power meterng nfrastructure has been selected two tme, n 009 and 010 to compete at the fnal phase of the ImagneCup students competton organzed by Mcrosoft. The soluton has been selected out of more than 300 projects worldwde as one of the top 15 projects. The research team nvolved n the project ncluded experenced researchers, young researchers, external advsors and students: Eng. Cataln GHEORGHIU PhD. Cosmn CERNAZANU GLAVAN PhD. Marus DARIE PhD. Fucu SEBASTIAN PhD. Valentn STANGACIU PhD. Crstna STANGACIU PhD. Stud. Andre STANCOVICI PhD. Stud. Alexandru TOPIRCEANU Eng. Bogdan POPESCU Eng. Danel VOLCINSCHI There are several contrbutons clamed by our work: An ntellgent power meterng nfrastructure deployed as a wreless sensors network for energy montorng, analyzng, controllng and predctng of electrc, electronc and computng devces; 100

101 Research and Contrbutons n Energy-Effcency and Context-Awareness of Defnton, mplementaton and valdaton of the concept of power sgnature appled to runtme operaton of home applances and computer devces; A database storng power sgnatures of many knds of devces, such as refrgerator, freezer, washng machne, bread cookng machne, TV set, DVD player, and desktop computers; A method usng dgtal processng and pattern matchng technques for characterzng the functonal parameters of the components, user operaton modes and patterns, system agng or falures. Ths secton s based on the followng papers publshed by the author: [ISI1], [ISI6], [ISI10], [ISI14], [BDI10], [BDI18], [BDI33] 4.7 CONCLUSIONS AND FUTURE WORK In ths secton we present an applcaton of ths energy montorng nfrastructure to dentfy the devce specfc both ntrnsc and usage parameters that have large mpact on energy effcency of these devces. The energy effcency of studed devces s evaluated based on the patterns dentfed n the measured power consumpton profles, called power sgnatures. Based on the acheved power profles patterns we ntend to develop power management set of control rules and notfcaton alerts for such devces. Ths secton presents also a method for an automatc detecton of malfunctonng for lowntellgence consumer electrcal devces. The method s fully automated and t s based on the analyss of the correlaton matrx between the components of the sgnal. It managed to analyze and to determne the degree of smlarty and, to fnd dfferences between two sgnals. The method was tested on dfferent power sgnatures obtaned from 10 washng machnes. Durng testng phase, the washng machnes executed both a normal program and fractons of program. The method captures the smlar phases wth a normal program and prompts when abnormal behavor s presented: a phase from program s skpped or presents malfunctonng. Also, based on smlarty coeffcents t s possble to compute the degree of agng. Durng the correlaton analyss we showed how an anomaly can be captured and analyzed based on the two exstng sgnals. We want to further mprove ths method by refnng the analyss part of the correlaton matrx and by takng other parameters nto consderaton. We are actvely lookng for partners nterested n acqurng the nnovatve soluton through technologcal transfer. 101

102 5 INDOOR POSITIONING SYSTEMS AND CONTEXT AWARE MOBILE APPLICATIONS 5.1 OVERALL DESCRIPTION AND RESEARCH OBJECTIVES Ubqutous moble computng s a new and very nterestng research topc wth wde applcablty n context aware solutons and poston dependent provded servces. One of the most sgnfcant elements of context awareness n ubqutous envronments s moble devce localzaton. There have been a number of attempts to desgn systems for ndoor localzaton usng dfferent wreless sensng technques, although currently there s no conclusve method for ths purpose. There are also a lot of challenges that prevent from obtanng a good postonng accuracy whch are not often addressed by exstng solutons. The man goal of our work s develop a soluton for ndoor localzaton based on exstng WF nfrastructure. The postonng nfrastructure s needed for delverng context aware moble servces n ndoor envronments wthn an accuracy of several meters. Ths secton presents the mathematcal model we used to develop the postonng soluton together wth the set of test cases and expermental results for wreless local postonng systems based on rado sgnal strength n order to valdate the prototype and emphass exstng ssues and challenges. In our work we nvestgated how trlateraton can be used n ndoor postonng, to estmate ts accuracy and ts needed resources for the moble devces. We targeted postonng n large rooms wth dfferent objects nsde the room and people movng nsde the room. We also want to be realstc and provde also the problems such a postonng system mplementaton wll face durng ts explotaton. 5. THEORETICAL CONSIDERATIONS The trlateraton assumes the exstence of at least three access ponts (APs) wth known postons. The dstance between each access pont (AP) and the moble devce (MD) have to be determned by computatons. For every dstance a crcle can be drawn. In the deal case, these three crcles must ntersect n a sngle pont whch s actually the poston of our moble devce (MD). The method chosen for obtanng the dstance between AP and MS s based on the sgnal strength (RSSI) measurement. The propagaton of rado waves s nfluenced by three factors: free space loss, attenuaton by the objects on the propagaton path, and the sgnal s scatterng. In the absence of obstacles, the model for propagaton s free space loss whch can be expressed for the deal Pt 4 d 4 f d P sotropc antenna as n ( r c (Eq. ): P t P r 4 d 4 f d c 10 (Eq. )

103 Research and Contrbutons n Energy-Effcency and Context-Awareness of Pt sgnal power at the emtter Pr sgnal power at the recever d propagaton dstance between emtter and recever λ carrer wavelength f carrer frequency c speed of lght The deal stuaton, when there s no obstacle, we consder the b dmensonal case when all APs and the moble devce are n the same plan. If no perturbatons nterfered along the measurng, at moment t, M receves a sgnal wth P power from the transmtter AP. The dstance between M and AP could be calculated wth the formula ( (Eq. 3): d P t P r c 4 f d P t P r c 4 f (Eq. 3) In the real world, measurng RSSI s made wth some errors, because the RSSI cannot be determned wth very hgh precson, even n the case of obstacle absence. If we take nto account the attenuaton nduced by some obstacles the problem could be more complcated. Hence the ntersecton of the three crcles s not a sngle pont. For three access ponts the maxmum number of ponts s sx, because every two crcles can generate two ponts of ntersecton. The deal stuaton, when there s no obstacle, we consder a b dmensonal case. If no perturbatons nterfered along the measurng, at the t moment, M receve P1, P and P3 from the 3 transmtters AP1, AP, AP3 respectvely. The recever s at the ntersecton of the crcles havng the centre n AP, of radus d, because n every pont of a crcle the same power s ntercepted. In deal case, the ntersecton of the 3 crcles s one pont only, whch s M (Fg. 78). 103

104 M : Fg. 78 Poston of M n D deal case x M x AP y 1 M y AP1 x M x AP y M y AP xm x AP y y 3 M AP3 (Eq. 4) If we accept that the sgnal reaches the recever nfluenced by some perturbatons, then the ntersecton of the crcles s no longer a crcle but a doman as n the Fg. 79. d 1 d d 3 104

105 Research and Contrbutons n Energy-Effcency and Context-Awareness of Fg. 79 The D real case Doman D can be estmated to one pont consderng ths pont ts centre of mass and t can be consdered that the approxmate poston of M. D : x x AP y y 1 AP1 x x AP y y AP x x AP y y 3 AP3 The coordnates of the centre of mass are: ( x, y) x y M M D D D D x x, y dxdy ( x, y) dxdy y x, y dxdy ( x, y) dxdy d d d beng the densty of the envronment n the pont (x, y) (Eq. 5) (Eq. 6) In the three dmensonal case, n the deal varant when there are no perturbatons n nterceptng the sgnal, and the sgnal does not meet any obstacle, the recever s the ntersecton of the spheres wth the centers n AP1, AP and AP3 of radant d1, d, and d3 respectvely, gven by the ( d P t P r c 4 f 1 3 (Eq. 3) relatons. 105

106 Fg. 80 The 3D real case In the real case, where perturbatons appear at the ntercepton of the sgnal, the ntersecton of the four spheres wll be a D doman whch also s reduced to ts centre of mass, as t s shown n: x, y, z D : x y z M M M x x AP y y 1 AP z z 1 AP1 x x AP y y AP z z AP x x AP y y z z 3 AP3 AP3 D D D D D D x x, y, z dxdydz x, y, z dxdydz x, y, z dxdydz z x, y, z dxdydz x, y, z dxdydz y x, y, z dxdydz d d d beng the densty of the envronment n the pont (x, y, z) 1 3 (Eq. 7) (Eq. 8) Fg. 81 D doman for the 3D case Ths centre of mass approxmates the poston of M. In order to resolve ths problem of trlateraton we propose two geometrc methods Method 1 In the deal case, the soluton s generated by the followng system of equatons: 106

107 Research and Contrbutons n Energy-Effcency and Context-Awareness of 107 (Eq. 9) Where, are the moble node s coordnates, are the AP s coordnates and s the dstance between MS and AP. But, as we mentoned earler, n a real stuaton, the ntersecton of the three crcles generates not a sngle pont, but a set of ponts. The problem s how to choose between those many nodes. We propose a pure geometrc method, whch s very smple to mplement and computatonal effcent. The frst condton s for the APs not to be on the same axs. Ths condton s gven by the next equaton: (Eq. 30) Our soluton requres makng pars wth every two APs, havng as a result the next relaton: (Eq. 31) Where and are the coordnates of the two APs. We consder and the raduses of the two crcles. The radus s the same wth the dstance between AP and MS, dstance calculated based on the sgnal strength sensed by de moble devce. A. If both nequaltes n relaton ( (Eq. 31) are true, ths means that we have two ponts of ntersecton. The coordnates of these ponts are gven by the followng system of equatons ( (Eq. 3): (Eq. 3) (Eq. 33) : d y y x x d y y x x d y y x x M M M M M M M ), ( M M y x ), ( y x d y y y y x x x x j j j j r r y y x x r r ), ( y x ), ( j y xj r j r j j j j r r y y x x r r j j M j M M M r y y x x r y y x x j j M j M M M r y y x x r y y x x 1 1 1,, j j j j y x M y x M

108 108 Fg. 8 Intersecton ponts of the three crcles In case each par of AP generates two ponts of ntersecton, t results a total number of sx ponts, as n the Fg. 8. B. If the rght nequalty of relaton ( (Eq. 31) s false, then we have: (Eq. 34) Ths means that the two crcles are not ntersected. In ths case we consder a sngle pont stuated on the axs defned by the centers of the two crcles. The coordnates of ths pont are: (Eq. 35) C. If the left nequalty of relaton ( (Eq. 31) s not satsfed, then we have: (Eq. 36) j j j j r r y y x x r r j j j r r y y x x k ky y k kx x M j j j 1, 1 j r r k j j j j r r y y x x r r j j j r r y y x x

109 Research and Contrbutons n Energy-Effcency and Context-Awareness of 109 Ths means that one crcle s contaned by the other one. As n the prevous case the pont s stuated on the axs defned by the centers of the two crcles. (Eq. 37) (Eq. 38) The cases B and C generate a sngle pont, but n case A we have two ponts. In order to choose between them, we apply the next computaton. For each of them we make the sum of dstances between the node and every other node obtaned through one of the three cases: A, B or C. (Eq. 39) If then we choose node, else we choose the node. Thus, we generate a set of ponts:. The selected ponts n ths way form a polygon and the poston of MS wll be the pont M, approxmated wth the center of gravty of ths polygon. The relatons are: (Eq. 40) 5.. Method The second method mposes the same general condton [14], namely n the zone where moble devce s actng to be at least three access ponts. If there are more than three access ponts a new k ky y k kx x M Q P Q P j 1, 1 j r r k j j j j j P x x x y y x x r x j j j j j P y y y y y x x r y j j j q x x x y y x x r x j j j q y y y y y x x r y N k k j k j N k k j k j y y x x S y y x x S S S 1 M M ), ( j j j y x M N y y N x x j M j M

110 110 condton arses: the access ponts need to create a convex polygon lke n Fg. 83. In ths fgure we exemplfy a case wth 4 access ponts. Fg. 83 Access ponts surroundng the moble devce If no perturbatons nterfered along the measurng, at the t moment, M receve P power from the transmtters AP respectvely and dstances between M and AP could be calculated wth the formula ( (Eq. 3). The algorthm of ths method requres groupng every two receved RSSI measures therefore we may wrte: (Eq. 41) Solvng ths system, we wll obtan two solutons: and (Eq. 4) From these two solutons we shall choose the pont that s at the same sde of the lne determned by AP and AP+1, wth another AP (for example AP 1). We can choose any other AP (not AP or AP+1) because they are the vertces of a convex polygon. Ths pont wll verfy the relaton: (Eq. 43) f c P P d r t AP AP AP AP d y y x x d y y x x 1, M1 M y x, M x M y M M y y y y x x x x y y y y x x x x

111 Research and Contrbutons n Energy-Effcency and Context-Awareness of The selected ponts n ths way form a polygon. The poston of pont M wll be approxmate by the center of gravty of ths polygon. x y M M x y 1 1 x y... x n n... y n n (Eq. 44) 5.3 EXPERIMENTAL RESULTS In order to establsh the set of test cases for evaluatng wreless postonng systems (WPS), we elaborate a number of experments, every selected experment was performed to run a long perod of tme (from tens of mnutes to a number of days). The test measurements have been performed at a samplng rate of 1 to 10 seconds, and saved n log fles. We used two provders for wreless equpment and a number of more than 10 devces: Lnksys: Dual Band Wreless A+G Access Ponts (WAP55AG), Wreless G Broad Band Router (WRT54GS), Dual Band and Sngle Band wreless PCI adapters (WMP54G and WMP55AG). D Lnk: ArPlus G Access Ponts (DWL G700AP) and ArPlus G Wreless router (DL 54). The test applcaton was mplemented n Vsual Studo 005 and was run on Wndows 000, Wndows XP, Wndows 003 Server and Wndows Moble 5.0 operatng systems. The envronment for the tests s a laboratory wth two rooms (Fg. 84). The montorng equpment are placed n dfferent locatons, accordng wth the test case. In all graphcs on the Ox axs s a representaton of tme and on Oy axs s RSSI n mdb. Conventonal WLAN based postonng systems use rado sgnal strength receved by the moble termnal, n order to estmate the locaton of each moble termnal separately. The local postonng evaluaton ste s composed of a number of access ponts (AP), a number of fxed or reference recevers (R) and a number of moble recevers (M). Reference recevers are used to calbrate the system whle usng t. The mnmum number of APs s 3. The locaton of the moble statons has to be estmated based on the model ntroduced before. Fg. 84 WPS evaluaton ste 111

112 5.3.1 Wreless transmtter devce types The frst test case was selected to dstngush the nfluence of AP devce on the WPS accuracy. We used two dentcal APs (WAP55AG) placed n the same locaton n the same tme and we measured RSSI n dfferent locatons n the room. Ths test case s ntended for proper equpment selecton for WPS mplementaton. Experments have shown that for dfferent AP of the same type placed n the same locaton and n the same tme, the RSSI measured at the recever has dfferent values (Fg. 8, 9 and 10). Ths test ran for two full days, and both 80.11g and 80.11a RSSI were logged. Dfferences could be observed n receved sgnal power between the two devces, between day and nght and between sgnal level and sgnal dsperson AP-g-40 AP-g AP-a-40 AP-a Fg. 85 RSSI from two APs placed n the same locaton at the same tme: (a left) 80.11g standard; (b rght) 80.11a standard Durng the day, the room was used by the students and the presence of people has nfluence on the RSSI. Ths could be a problem because the WPS are ntended to be used when the users are nsde the room. Therefore a WPS should consder the day characterstcs of the test when people are present and move n the room. The same result was obtaned also for the 80.11a standard, but n ths case the dfferences between devces are not so large (Fg. 85). Averagng the measured values for both devces and standards (g and a) used we obtaned the chart n Fg. 86. A dfference of almost 10 mdb was measured between the receved sgnal strength from two dentcal devces placed n the same locaton. 11

113 Research and Contrbutons n Energy-Effcency and Context-Awareness of AP-g-40 AP-g-41 AP-a-40 AP-a Fg. 86 Average RSSI from two APs placed n the same locaton at the same tme As a frst concluson we can say that before WPS deployment, an equpment selecton phase s needed, n order to select the proper devces for the system. After ths test case we conclude that AP g 41 t s not recommended to be used n WPS due to ts large standard devaton of the measured RSSI. A second recommendaton s to use 80.11a standard n WPS or both 80.11a and 80.11g standards for a better accuracy, due to smaller devatons obtaned for 80.11a n our tests Wreless recever devce types The second test was proposed to show the nfluence of recever devce (hardware and software) on the RSSI. The test bench establshed for ths test case s shown n Fg. 87, where the three dfferent recever devces used are placed n the same locaton: a laptop wth Atheros wreless adapter ntegrated on the motherboard; a desktop wth Lnksys WMP55AG PCI wreless adapter; a desktop wth Lnksys WUSB55G USB wreless adapter. Fg. 87 Three dfferent recever devces placed n the same locaton at the same tme 113

114 The average results of the measurements are presented n Fg. 88a. It can be easly observed that there are qute bg dfferences n RSSI on the three recevers. We tested also the nfluences of software nstalled on the recever devces: operatng system, network drver, power montorng software. The tests were run on the same recever machne wth two operatng systems nstallatons: Wndows XP and Wndows 003 Server. We used two power montor drvers and software: Wreless Zero Confguraton Servce from Mcrosoft and Lnksys Montor from Lnksys. Fve dfferent access ponts and the results are presented n Fg. 88b. 0 wap55g-01 dwlg wrtg55g wrt54g-0-10 dwlg Atheros MB Lnksys PCI Lnksys USB wap55g-01 Wn XP - Wndows montor Wn XP - Lnksys montor Wn 003 SE - Wndows montor Wn 003 SE - Lnksys montor -40 wap55g-0-50 wap55g Fg. 88 RSSI measured by three dfferent devces: (a left) network card; (b rght) OS Envronmental factors The thrd test case tred to emphass the external envronment nfluence over the WPS: people n the rooms, devces runnng tme, doors opened or closed, and wndows opened or closed and even the weather. Dfferences n RSSI measurement can be also observed, on both standards (80.11a and 80.11g), between daly hours and nght hours (Fg. 85). In daly hours the room was used by people workng n the lab and students, therefore the receved sgnal has more perturbatons. Better results are obtaned n the nght when no nterferences and reflectons wll occur. Between the two rooms n the lab (Fg. 84) there s a door. Another test was run wth the door open and then closed (Fg. 89a). Surprsng n all our tests wth the door closed better results were obtaned. Runnng the system n three successve nghts, n the same condtons (devce postons, door postons, etc.) some dfferences could be observed (Fg. 89b) n terms of average value or measurements dsperson. These dfferences whch could be qute bg, are supposed to appear due to: devce runnng tme (the number of hours from startng the devce) and weather condtons (temperature, humdty, etc.) In concluson we showed through ths second test case that a large number of uncontrolled external parameters have nfluence on the RSSI measurements. All these nfluences and parameters are very hard to be expressed n the mathematcal model. Therefore a soluton for ths drawback s to place one or more fxed sgnal recevers (desktop systems R n Fg. 84) called reference devces, n well known postons. These devces wll montor the RSSI from all APs and wll ntroduce a control loopback for the system. 114

115 Research and Contrbutons n Energy-Effcency and Context-Awareness of nght-open day-nowork nght-close day+nght-close wrt54gs Fg. 89 Envronment condtons (a left) door status; (b rght) nght condtons Dstance estmaton The man test ams at valdatng the relaton between dstance and RSSI by measurements. The test bench proposed for ths test case s presented n Fg. 90. We placed a number of access ponts and we measured the RSSI n dfferent well known postons. For smplcty we placed a moble devce between two APs, from 1 meter to 1 meter. For every poston a 30 mnutes capture was saved. Fg. 90 Test bench for poston accuracy estmaton ,000 1, dwlg Poly. (dwlg700-10) Fg. 91 Relaton between RSSI and dstance 115

116 The relaton between the receved sgnal strength and the dstance between transmtter and recever for some devces s presented n Fg. 91. From these measurements t can be observed that the relaton between RSSI and dstance are not qute the same for every devce. Ths test set s requred for the calbraton of the model accordng to the specfcty of the ste where the system s deployed and equpment used. Averagng the measurements for more devces a polynomal functon was Pt c d P obtaned accordng wth r 4 f (Eq. 3). Ths test case could be used n a WPS mplementaton for transmtter sgnal power estmaton, postonng accuracy estmaton, RSSI dstance relaton estmaton and fnally system calbraton. 5.4 RELATED WORK In the lterature there are many approaches for desgnng methods for postonng systems, whch are dfferent n terms of dstance measurement technques and mathematcal models. There are a few dfferent localzaton methods that can be used for the postonng procedure. These methods are dvded nto three major categores based on the envronment n whch the nformaton s spread: ndoor, outdoor or mxed. Postonng systems consst of algorthms and methods to estmate the poston of an unknown target, and are classfed based on [Lm006]: the sgnal types: o nfrared, o ultrasound, o ultra wdeband, and o rado frequency the sgnal metrcs o global locaton systems outdoor methods o cellular locaton systems mxed methods o ndoor locaton systems. The most popular outdoor localzaton system s known as GPS (global postonng system). The GPS recever calculates ts current poston (longtude, lattude, elevaton) usng a trlateraton technque. The dstance s computed based on the tme delay between the transmsson and recepton of the encrypted rado sgnal ssued by the satelltes. In comparson wth these systems, the ndoor system poses addtonal challenges. Dfferent technques exst for estmatng the poston of a moble devce n a wreless network [Grosmann006]: cell based wth ths localzaton technque the poston of a devce s smply located around the poston of the access pont where the devce s connected. sgnal propagaton tme based the poston s determed usng the tme of arrval of the receved sgnal from several access ponts (APs) to the target devce. sgnal angle of arrval the poston of a devce could be estmated based on the measured angle of arrval of receved sgnal from surroundng APs. recever sgnal strength based the poston of a target devce s estmated usng the receved sgnal strength from surroundng APs. 116

117 Research and Contrbutons n Energy-Effcency and Context-Awareness of Cell based postonng method s very smple and consders that a moble devce s located near the known poston of the AP ths devce s connected to. Despte ts smplcty ths method s not largely used because of the lack of accuracy. The propagaton tme can be drectly translated nto dstance, based on the known sgnal propagaton speed [Broxton005]. Based on sgnal propagaton tme from surroundng APs to the target devce, ts poston can be estmated. These technques offer ncreased accuracy but they requre precse clock synchronzaton and more expensve nfrastructure. There are two mportant methods n ths category: ToA (Tme of Arrval) [Al005] and TDoA (Tme Dfference of Arrval) [Zhang006]. The most mportant parameter for accurate ndoor postonng systems s the tme of arrval TOA of the Drect Lne of Sght path [L004]. Therefore an accurate estmaton of TOA from receved communcaton sgnals s requred. Angle measurements can be used for ndoor postonng usng AoA (Angle of Arrval) of the receved sgnal or DoA (Drrecton of Arrval) [Chen00, Pryantha000]. For ths technque addtonal hardware s also needed n order to measure the angle of ncdence of the receved sgnal. The AOA requres antenna arrays at each node whch ncrease the complexty of the exstng system, as well as, performng worse n multpath envronment [Zhang006]. The fourth solutons class for ndoor postonng system s based on receved rado sgnal strength of the surroundng APs. Ths postonng method uses the exstng WLAN nfrastructure and does not need any extra hardware attached to the target devce. The network card n the moble devce contnuously measures the RSSI (Rado Sgnal Strength Indcator) of the APs n ts neghbor. Ths nformaton s avalable due to beacon broadcast multple tmes per second by every AP [Retscher006]. Based on RSSI the moble devce can estmate the dstance from ts poston to the AP t measured the RSSI. Usng at least three APs wth well known postons, a moble devce can estmate ts poston based on measured RSSI from these APs. RSS based WPS (Wreless Postonng Systems) were studed a lot n the last years. There are at least three locaton algorthms n ths class of WPS: fngerprntng (RSS patterns [Retscher006, Wang005, Salter006]) smulaton (lnes of constant RSS [Grosmann006, Grossmann007]) trlateraton (Eucldan dstance extracted from RSS our soluton) The fngerprntng method s the most common used for WPS. An estmate of the target devce poston s obtaned from the RSSI measurements and usng a rado sgnal propagaton model nsde the buldng [Retscher006]. The propagaton model can be obtaned usng a pror RSS measurements n dfferent locatons n the buldng. These measurements compose a RSS map, called fngerprnt, are stored n a database and can further be used to estmate the poston of a target devce. Ths method s dvded n two phases [Grosmann006]: ntal calbraton phase where the RSS map s acheved and the postonng phase, the measured RSS values from surroundng APs are compared to the ones stored n the database n order to estmate the current poston of the devce. The dsadvantages of ths approach are the database generaton and mantenance requrements [L005]. Durng the WPS lfetme, every change n the nfrastructure requres the buld of the RSS map. 117

118 The second class of WPS methods uses smulaton algorthms to buld the propagaton models of the rado sgnal nsde the buldng. The smulaton starts from the buldng map and postons of APs on the map. Durng the smulaton for every AP the lnes of constant RSS, called sobars, are computed. After the smulaton the map of RSS sobars for every AP s obtaned. Ths map can be further used by a moble devce to estmate ts poston nsde the buldng. The drawbacks of ths method are the complexty of the propagaton model smulator and the computaton resources needed to run the smulaton algorthms. A network based localzaton method s presented n [Ymng006], whch uses the rado propagaton sgnal strength that covers a D plane, where three snffers are placed n order to lsten to a sngle sgnal strength emtted by the moble and to automatcally generate an estmated sgnal strength map. Also, the algorthm s able to establsh the moble s poston by browsng ths table. Unlke the prevously descrbed method a clent based localzaton soluton s presented n [Bahl000], usng rado frequency (RF) as well, n whch the man element s recordng and processng the sgnals receved from several base statons that are placed by overlappng coverage n the D plane. The trangulaton s acheved by usng two methods: the frst one requres measurng the sgnals and creatng a sgnal strength map SS MAP and searchng the best sgnal strength measurements; the second method requres the usage of a smple propagaton model n order to estmate the SS MAP. The authors of [Retscher006] developed and tested a software framework called pos for ndoor postonng based on WLAN fngerprntng the can be used to buld locaton based applcatons. It conssts of an effcent, freely confgurable framework, whch s sutable for multple applcaton archtectures. The RSS measurements are performed on the moble devce, the computaton and vsualzaton of poston can be run on an nfrastructure server or on the devce tself. Based on ther tests they obtaned and accuracy of better than 3 meters for an area of 1500 m covered by 7 APs. The authors of [Grosmann006] developed a method to dentfy ntersectons of lnes of constant RSSI values, called solnes, of several APs wthn nterpolated rado maps based on trangulaton. Based on ther tests an average devaton of 3 meters was obtaned for 330 m exhbton room equpped wth 4 APs. The am of the work presented n paper [Karakos005] s to study the possbltes that the WLAN's offer to ndoor localzaton and to mplement an applcaton that wll help to localze a devce equpped wth a WLAN's card supportng the IEEE 80.1lb protocol. The applcaton developed by the authors called Wlb uses a database wth sgnal strength values stored and a mathematcal model n order to estmate the poston of a user wth a wreless devce nto a lbrary of ther Unversty. The dsadvantage of all RSS methods s the random devaton from mean receved sgnal strength caused by shadowng and small scale channel effect [Zhang006]. We consder based on our tests, that the accuraces obtaned by other postonng applcatons are the best that can be acheved and n the real lfe usage scenaros the postonng accuracy wll decrease sgnfcantly due to: changes 118

119 Research and Contrbutons n Energy-Effcency and Context-Awareness of n the envronment, people movng around n the measured envronment, moble devce speed and orentaton, APs rado sgnal transmtter s fluctuatons, etc. 5.5 SUPPORTING GRANTS, RESEARCH TEAM AND SCIENTIFIC OUTCOMES Ths work has been supported by nternal resources. The research team nvolved n the project ncluded researchers and students: PhD. PhD. Fucu SEBASTIAN Eng. Bogdan STRATULAT There are several contrbutons clamed by our work: A mathematcal model capable of dstance and poston estmaton of a moble devce usng trlateraton n a WF nfrastructure; A set of test cases requred to select the equpment, place the WF hotspots, calbrate the model and valdate the WPS system deployment; A prototype mplementaton of the model able to detect moble devces n ndoor envronment wthn the accuracy of 3m. Ths secton s based on the followng papers publshed by the author: [ISI8], [ISI15], [ISI16], [ISI], [ISI4], [BDI30], [BDI34]. 5.6 CONCLUSIONS AND FUTURE WORK A large number of hours of tests summng more than 1 month were run n order to dstngush the ssues of wreless LAN based postonng technques and ther possble solutons. Our conclusons states that n real lfe envronment postonng accuracy s nfluenced by much more parameters than used n the prevous artcles, parameters that have to be taken n account when developng the real system. Wreless devce type (both emtters and recevers), wreless communcaton standard, access ponts postons, antenna orentaton, rado channel all have nfluence on locaton accuracy. Startng from these ssues of WPS we proposed a set of test cases whch could be used ether for WPS mplementatons comparng or for proper WPS confguraton and deployment. The expermental results of the proposed test cases conducted us to the dea of desgn for local postonng. We fnally developed the prototype ncludng the model and usng the obtaned expermental measurements. We obtaned a postonng accuracy of 3 m, whch s comparable wth the other work results. 119

120 Ths work forms the bass for retrevng context nformaton whch wll be later used n extractng hgh level contexts of moble users. Moble users have several daly or weekly contexts they use moble applcatons and servces. Dependng on current user context the needed moble applcatons may vary. Low level context data (such as locaton) are collected and stored on moble devce to compose hgh level user contexts. The man challenge of moble context aware applcatons development s to defne the hgh level context n a manner that s relevant for the user and for the applcatons. Wth respect to ths challenge we propose an abstract and vsual hghlevel context representaton. For example, the user s habts reveal several statc contexts (e.g. home, school and work) and several dynamc contexts (e.g. transportaton). The proposed vsual representaton model of the revealed user contexts s depcted n Fg. 9. By car By car Fg. 9 Hgh-level context abstracton The basc elements used to construct the model are D ellpses. Several attrbutes of a context can be exposed through dverse measures of the basc elements. For example, the statc context representaton shown n Fg. 93 can beneft of ellpses sze to descrbe the duraton the user spent n ths context and the type of wreless connectvty the user benefted wthn the context. The color of the basc elements descrbe the tme of day the user attended the context (e.g. mornng, afternoon, evenng, nght). 10

121 Research and Contrbutons n Energy-Effcency and Context-Awareness of connectvty Fg. 93 Statc context representaton The dynamc context representaton shown n Fg. 94 can beneft too of ellpses sze and color. The length and speed of movement s descrbed by ellpse sze and the color descrbes the type of transportaton. Fg. 94 Dynamc context representaton The basc context elements can be grouped together n context dagrams (Fg. 9). These dagrams descrbe the locaton of contexts (e.g. relatve or absolute), placng the ellpses nto the dagram accordng to ther locaton. The second challenge of mplementng context awareness n moble applcatons s the process of hgh level context extracton startng from avalable low level context values (both current and hstorcal). In our work we use data mnng on preprocessed low level context parameters. Data mnng represents the process of analyzng data from dfferent perspectves and summarzng t nto useful nformaton. When t comes to usng data mnng for user context estmaton, the man purpose would be to analyze a set of nput parameters (sensors and network parameters) and see how these parameters can be classfed nto classes representng the user s context. Data mnng usually nvolves four classes of tasks: Assocaton rule learnng whch means searchng for rules between the varables Clusterng whch means dscoverng groups of data that are smlar Classfcaton whch means generalzng a known structure and applyng t to new data Regresson whch means searchng a functon whch models the data wth the least error 11

122 1

123 Research and Contrbutons n Energy-Effcency and Context-Awareness of 6 DIRECT FPGA BASED ENERGY PROFILING OF EMBEDDED COMPONENTS 6.1 OVERALL DESCRIPTION AND RESEARCH OBJECTIVES Power and energy proflng of mult core embedded SoC desgns s a dauntng task due to the lack of fne gran accurate and hgh samplng rate montorng nfrastructures. Furthermore, shared components used n common by multple processng cores, make SoC desgns dffcult to analyze the thread level energy consumpton. FPGA development boards are currently used to mplement mult core SoC prototypes n order to valdate them on real hardware and to perform thoroughly performance proflng. In ths work, we nvestgate the capacty of FPGA desgns to profle the power consumpton and energy usage of mult core embedded archtectures and applcaton benchmarks runnng on them. Improvng the energy effcency of computng devces s one of the man challenges of our tmes. For a better evaluaton of a computng devce n terms of power consumpton, component level power consumpton analyss has partcular mportance n the early stages of the desgn. However, accurate energy proflng can be performed only on a physcal prototype, whch s avalable durng the fnal development stages. Instead, model based energy proflng s usually performed, but t lacks the physcal measurements accuracy and calbratons. Reconfgurable devces are beng used n a wde range of applcatons, therefore, they are good canddates to perform physcal energy proflng durng prototypng. The man goal of our work s to perform both hardware and software accurate proflng of any mult core archtecture usng low level profles of ts components, such as CPU cores, memores, and buses. Therefore, n ths paper, we nvestgate the capacty of FPGA desgns to profle the power consumpton and energy usage of mult core embedded archtectures and applcaton benchmarks runnng on them. 6. FPGA BASED ENERGY PROFILING METHODOLOGY 6..1 Measurement setup Performng energy proflng on a mult core SoC s a dffcult task due to the multtude of nternal hardware power consumers and lack of ndvdual per module power rals wth montorng capablty. Furthermore, some modules such as processng cores, consumes less or more energy dependng on the software they execute. Energy proflng requres thus many physcal measurements whch must be done wth hgh precson n a strctly controlled envronment usng dedcated energy proflng benchmarks. Many FPGA development and evaluaton boards provde hardware and software embedded developers wth bult n support for physcal measurement of current consumpton. Ths goal s acheved by measurng the voltage drop on very small and accurate shunt resstors (mllohms) that are placed on the exstng power rals powerng ndvdual FPGA modules. Accuracy of the 13

124 measurements may dffer from one board to another, as there are dfferent accuracy values used for shunt resstors, as well as for the ADC resoluton and samplng rates. Man requrements of FPGA based energy proflng are hgh measurement resoluton (at tens of ua) at hgh accuracy and hgh samplng rates (hgher than 1 KHz). In case the sensor and ADC accuracy s low, hgh level of nose wll nfluence the analyss. If samplng rate s low, measurements and analyss wll mss accountng the short events. We performed power and energy proflng tests on ZC70 evaluaton board. It provdes a hardware envronment for developng and evaluatng applcatons for Zynq 7000 SoC based on XC7Z00 devce. The ZC70 board provdes features requred by any multcore embedded system, such as DDR3 shared memory, shared L cache and fast on chp memory (OCM), and general and common I/O nterfaces (GPIO, UART, USB, Ethernet). The Zynq 7000 SoC conssts of one ntegrated processng system (PS) and programmable logc (PL) on a sngle de. The PS ncludes two ARM Cortex A9 cores, AMBA AXI nterconnects, nternal memores (L cache and OCM) and perpherals. Both ARM cores run at 667 MHz and contan local L1 data and nstructon caches. The PL conssts of a 7 seres FPGA core, featurng 5300 slce LUTs, slce regsters, 140 Block RAMs and 0 DSPs. PS and PL runnng ndependently are nterconnected through several AXI based hgh performance nterconnects and general I/O ports. [ZC70] The ZC70 board ncludes power management and montorng nfrastructure. Voltage and current montorng and control are avalable for selected power rals through three onboard power controllers nterconnected through one PMBus [ZC70]. Out of the ten power rals that can be measured ndependently, the followng one are of nterest n our nvestgaton: VCCINT s a nomnal 1.0V supply that powers all nternal PL FPGA core. The power consumpton of the target desgn mplemented by FPGA logc can be measured as a whole on ths power lne. VCCPINT s a nomnal 1.0V supply that powers the all PS nternal components ncludng ARM cores and nternal caches and OCM. VCCBRAM s a nomnal 1.0V supply that powers all the Block RAM memores of PL. BRAM transactons can be analyzed ndependently by FPGA core crcuts. VCC1V5 s a 1.5V nomnal supply that powers several board components ncludng the DDR3 memory. DRAM memory transacton performed from PS or PL can thus be analyzed from energy perspectve. In concluson, power consumpton of PS, PL, BRAM and DRAM can be measured ndvdually, whle power consumpton of PS and PL nternal components have to be estmated out of global measurement and component usage. ZC70 power montors sample measurements at a rate of 10 KHz and mv measurements resoluton. 6.. Measurement achevement The same mult core desgn can be mplemented ether wth FPGA or ASIC technologes. The comparson between FPGA and ASIC n terms of power consumpton s problematc due to the heurstc nature of the desgn synthess. On FPGA, a full logcal block mght be used for one sngle bt regster, whch s a sngle flp flop n ASIC. However, f the FPGA logcal blocks fts the desgn 14

125 Research and Contrbutons n Energy-Effcency and Context-Awareness of very well, t translates to more complex combnatonal logc and flp flops on an ASIC. Therefore, there s a hgh degree of uncertanty n terms of power, area and tmng. The power consumed nsde an FPGA s dvded n two major categores: statc power and dynamc power. The statc power s dsspated whenever the FPGA board s connected to a power supply, the desgn s programmed on FPGA and before applyng any clockng. On the other hand, dynamc power consumpton s hghly correlated wth the gate level swtchng actvty, whch s utlzed by exstng solutons for power estmaton models. Therefore, dynamc power consumpton measurements s worth nvestgatng n order to study the desgn behavor n tme and energy usng hardware emulated mplementatons. The man goal of our work s the nvestgaton dynamc power consumpton behavor of a multcore desgn mplemented n FPGA technologes by drect measurements. The dynamc power has two components: the dynamc dle power, whch dsspates whenever the FPGA core s clocked and the dynamc actve power, whch s dsspated accordng to the core utlzaton, the last one beng larger and harder to estmate. Thus, the dynamc power can be measured by makng modfcatons to clock frequency, voltage supply values, actvty rates and usage patterns. As the nput vectors determne the actvty of the crcut, changng them can help measure the dynamc power. Idle and workload actvty have to be defned for every component to profle (Fg. 10) n order to measure and hghlght the dynamc power. Dfferent workloads proposed n the next subsecton are defned by specfc hardware test benches and software benchmarks. Every test s carred out n three phases whle power measurements are recorded: pre workload measurements (dle), workload actvty measurements and post workload measurements (Fg. 10). The energy accounted to a benchmark or workload s obtaned by averagng power consumpton measured durng workload actvty and subtractng the dle actvty average power, the result multpled by workload duraton. Consderng that the complex workloads are splt nto smple basc operatons repeated for suffcent tme, the dynamc energy can be estmated and accounted. In order to measure and estmate energy consumpton of the platform mplemented by FPGA fabrc and development board, ts power consumpton varatons have to be analyzed. Power proflng of host FPGA development board ams at montorng power consumpton varatons of development board components, ncludng FPGA core, wth respect to FPGA workload actvtes. The tests were conducted smultaneously on two dentcal Zynq boards. The temperature n the room was mantaned at 6 degree Celsus usng an nternal ar condtonng nstallaton. For all test cases we performed three seres of measurements. A seres of measurements means that we load nto FPGA a certan confguraton and, after we reset the board, we montor the power lnes of the entre board accordng to the measurement phased descrbed before (Fg. 10). Each test has been repeated three tmes wth the same confguraton. Thus, for each test case we obtaned 6 tme seres Hardware Energy Proflng Test Benches The frst set of tests have been performed usng dfferent numbers of counters powered at the same voltage and clock frequency (system clock) as descrbed n Fg. 95. For ths goal a dfferent number 15

126 of counters were syntheszed, startng wth one counter and endng wth the maxmum number of counters that ft the FPGA core. Each counter has 3 bts. The frst set of tests amed at measurng power consumpton of the LUTs blocks of FPGA fabrc. Ths test set s expected to show a lnear relaton between the FPGA used area by the counters and FPGA core power consumpton. The second set of tests were performed usng a phase locked loop (PLL) crcut, whch allows us to multply/dvde the clock frequency. Durng the second set of tests, we changed the operatng frequency for the counters as follows from 10 MHz to 50 MHz. Ths test set s expected to show a lnear relaton between the counters swtchng frequency and FPGA core power consumpton. Fg. 95 Area/Frequency test bench Block RAM memores test form the thrd test set. BRAM can be profled ndependently whle t s stmulated by RD, WR and RD+WR sequences mplemented by a memory test bench programmed nto FPGA core. For proflng several pars of test bench BRAM have been used, startng wth 1 and endng wth 3 as presented n Fg. 96. Fg. 96 BRAM test bench In the fourth set of tests, we mplemented FIR flter processng blocks (Fg. 97) whose parameters and values are taken from BRAM memory. Wth ths set of tests the DSP blocks and LUTs logc have been evaluated from power consumpton perspectve. 16

127 Research and Contrbutons n Energy-Effcency and Context-Awareness of Fg. 97 DSP test bench 6..4 Software Energy Proflng Test Benches More complex hardware components such as processng cores and DRAM controller and memory have to be profled at software level. Two test cases have been performed n order to estmate power consumpton and energy consumpton of load/store operatons on DRAM (Fg. 98): (1) execute memory transfers form a RISC core (Mcroblaze) programmed n FPGA and () execute memory transfers from ARM cores. For each test case, several benchmarks have been performed: sequental loads (LDR seq) blocks of read operatons from successve addresses; fxed address loads (LDR fx) blocks of read operatons from the same address; sequental stores (STR seq) blocks of wrte operatons to successve addresses; and fxed address stores (STR fx) blocks of wrte operatons to the same memory address; blocks of RD/WR operatons. The memory transfers blocks szes have been vared for each test. Fg. 98 DRAM test bench Proflng a processng core s acheved by proflng each nstructon ndvdually. For each CPU nstructon, a program called mcro benchmark, has been wrtten n order to capture the power consumpton varaton nduced by the nstructon. The mcro benchmark conssts of two man loops: one loop whch contans nop nstructon and one loop whch contans the nstructon to profle (Fg. 99). Mcroblaze s a 3 bts soft core embedded RISC processor provded by Xlnx s optmzed for mplementaton n FPGA. It s hghly confgurable wth nstructon and data L1 cache, debugger, performance counters or floatng pont unt. 17

128 Fg. 99 Instructon proflng mcro-benchmark 6..5 System Level Energy Proflng Benchmarks The reference system desgn mult core archtecture energy proflng s presented n Fg It has one clusters of four Mcroblaze soft cores. The clock frequency for the MB s 100 MHz. The cores nclude local nterrupt controller, local nstructon and data memory and local nstructon and data buses. In a mult core system we consder three types of components: processng cores (could be homogeneous or heterogeneous), prvate resources and shared resources (e.g. memores and nterconnects). Processng cores and prvate resources have been profled ndependently whle for shared resources, specfc bus montors IPs have been mplemented n order to dentfy the processng cores ntatng the data transfers. The four MB cores cluster needs thus two shared DRAM bus montors: one for nstructon bus and the second one for data bus. These montors allows us to dspatch the component energy to the core the current operaton belongs. We have consdered the followng representatve benchmark applcatons to be executed on the reference desgn: a compresson benchmark (COMPRESS), a CRC calculator (CRC), a FFT algorthm (FFT), a bt manpulaton benchmark (BIT), a FIR flter (FIR), a Petr Net smulator (PETRI) and an auto generated code (AGC). These are self contaned software programs that do not requre any addtonal lbrares, operatng or fle systems. The self contaned benchmarks were needed to valdate the energy nterrupt, n order to avod any nterference wth other programs, because the lack of an OS makes the results determnstc. Whle executng the benchmarks, performance and energy proflng have been performed. The frst test case conssted of FIR benchmark on multple cores wth four tests changng the locaton of nstructons and data: (1) both benchmark s nstructons and data are executed from DRAM, () both nstructons and data are n BRAM, (3) nstructons are executed from DRAM and data are stored n BRAM, and (4) nstructons are executed from BRAM and data are stored n DRAM. 18

129 Research and Contrbutons n Energy-Effcency and Context-Awareness of Core S-LEM MB 1 BRAM I + D LMB bus INTC Tmer INT Energy INT Core 0 x x S-LEM S-LEM x x S-LEM S-LEM 3 Core 1 Core I + D AXI Interconnect DRAM 4 Core 3 C-LEM Fg. 100 Mult-core reference desgn 6.3 EXPERIMENTAL RESULTS The expermental result of frst tests executons are presented n Fg. 101 for FPGA core area usage and for frequency varaton. As expected, a lnear regresson between dynamc power consumpton of FPGA core and number of counter used (area or slces used) on one sde and frequency on the other sde. These results shows however that FPGA proflng can dfferentate between power consumpton of components at regster level. Fg. 101 (a left) FPGA power consumpton vs. utlzed Number of Slce LUTs; (b rght) FPGA power consumpton vs. frequency In the thrd test bench we tred to see f there are dfferences n power consumpton when are utlzed logc blocks (Slce LUTs) or specalzed DSP Slces. For ths, we mplemented an Nthorder Fxed Pont FIR flter. The mplementaton of the FIR flter s made so that t can use or not the DSP blocks. The mplementaton wth DSP blocks uses exstng bult n unts for the followng operatons: addton, multplcaton and sgnal delays. 19

130 Fg. 10 FPGA power consumpton for FIR Flter mplementaton usng LUTs, N=[30, 0, 10] and usng DSP, N=30 Durng flter testng procedure, operatng modes were used: flter on and flter off. The graphc representatons of the FPGA consumed power can be seen n Fg. 10. We removed from the graphc, the confguratons for N=[10, 0] mplemented wth DSP blocks, because the consumed power has a low value comparatve wth the rest of the values. We can conclude that usng specalzed blocks of the FPGA can decrease fve tmes the consumed power. Also, the consumed power s proportonal wth the N (order of the flter). Next, the obtaned results for DDR shared component power and energy consumpton are presented. Two test cases have been performed n order to emphasze power consumpton and energy consumpton of shared component: (1) execute memory transfers form Mcroblaze cores and () execute memory transfers from ARM cores. For each test case, several benchmarks have been performed: (1) sequental loads (LDR seq), fxed ad dress loads (LDR fx), sequental stores (STR seq), and fxed address stores (STR fx). The memory transfers blocks szes have been vared for each test. The average power consumpton for load and store operatons are shown n Fg LDR P avg [W] STR Pavg P avg[w] Pavg[W] Bblock sze LDR-fx LDR-seq Block Fg. 103 DDR power consumpton: (a left) LOAD transfers; (b rght) STORE transfers Measured data on Zynq 700 development board for GB DDR3 SDRAM (MT41J56M8 3 Meg x 8 x 8 Banks) are dentfed through proflng: Power down: Po = 45 mw Power dle (refresh): Ps = 585 mw 130

131 Research and Contrbutons n Energy-Effcency and Context-Awareness of Power of read (max): Prd max = 1050 mw Power of read transactons (avg): Prd avg = x RD_usage_rate + Ps Energy of read transactons: Erd = pj A lnear power consumpton model for loads and stores can be appled based on measurements and a constant value for energy of load and stores operatons has been obtaned. The memory model of power consumpton of load transfers functon of memory usage s shown n Fg The energy consumpton of load transfers functon of loads transfer rate s shown n Fg Fg. 104 Memory loads power consumpton measurements Smlar results are obtaned for store operatons: Power of wrte transactons (max): Pwr = 1005mW Power of wrte transactons (avg): Pwr avg = x WR_usage_rate + Ps Energy of wrte transactons: Ewr = pj In concluson we can estmate DRAM power by: PDRAM = C1 x urd + C x uwr + Ps and DRAM energy EDRAM = NRD x ERD + NWR x EWR + Ps x t where urd s usage level of load transfers and uwr s usage level of store transfers. Fg. 105 Memory loads energy consumpton estmatons 131

132 Fnally two RISC processors have been analyzed for power consumpton and energy: PD_RISC (Synopsys Tools) and Mcroblaze (Xlnx). The chosen nstructons for testng the ALU unt of the processor are: and16, or16, and, or, xor, add16, add, sub and mul. Each of these nstructons use the ALU unt of the processor n the own way, but there are many smlartes between them. The measured power could vary, but only wth mnor varatons. In tme, there are absolutely no varatons. Fg. 106 Power consumpton of a program sequence conssts of followng nstructons: nop, and, or and xor Fg. 106 shows the power varaton for a testng program for followng nstructons: and, or and xor. For each of these nstructons we have a large loop flled wth only one nstructon, followed by a pause loop. These pauses allow us to see the dfferences between the consumpton of each nstructon. Fg. 107 Power consumpton of ALU Instructons The power consumpton for ALU nstructons can be seen n Fg The logc nstructons have a lower consumpton than the arthmetc nstructons. The nstructon wth the most power consumpton s the mul nstructon, and f we consder only the logc nstructons we have the xor nstructon. To access the memory, the PD_RISC processor has the followng nstructons: lw, lh, lb, sw, sh and sb. These nstructons permt to store/load nformaton on 3 bts, 16 bts and 8 bts. Consumpton for all store nstructons doesn't depend on the nformaton stored n memory, but 13

133 Research and Contrbutons n Energy-Effcency and Context-Awareness of for load nstructons, the consumpton could be dfferent. Because of that, 3 types of experments were made, whch dffer only by the loaded nformaton. In the frst experment, the nformaton loaded from the memory s changed every tme, so that each bt of the regstry must swtched from 1 to 0 or from 0 to 1 every tme (e.g. suppose we load 8 bts of nformaton, one tme we load , the next tme we load and so on). In the second experment we loaded only 0 from memory, and n the thrd experments we loaded only 1. Fg. 108 Dfferences n power consumpton of load nstructons due to the loaded nformaton. For 16 bts nformaton we have: (blue) - one tme load AAAA, the next tme load 5555, and so on. (red) - load only 0000 words from memory. (green) - load only FFFF words from memory The power consumpton for all 3 experments can be seen n Fg Regardless of the length of the nformaton loaded from memory (8, 16 or 3 bts), the power consumpton s hgher when the bts of the regster must swtch when new nformaton s loaded (frst experment). Fg. 109 Power consumpton of memory access nstructons To establsh a level of consumpton for the load nstructons, the obtaned values for each nstructon, n all of the 3 experments, have been averaged. Puttng together the store and the load nstructons t can be easly seen that the level of power consumpton for load nstructon s lower that the level of power consumpton for store nstructon (Fg. 109). 133

134 In Fg. 109, dfferent modes of load nstructons show very close values of power consumpton, but small dfferences can be observed. To nvestgate on ths effect, standard cell based power smulaton s performed to check power consumpton of ndvdual archtectural components. Evaluaton shows that the extra power values of lb and lh are consumed by the data maskng logc n the MEM ppelne stage. Once the processor loads data word n 3 bts, the lb nstructon masks 4 bts data out of 3 bts whch consumes extra power. In contrast, the lh nstructon masks only 16 bts data, whch causes less overhead than lb. The lw nstructon does not need any data maskng, whch consumes no addtonal power for data loadng. A number of 3 nstructons exstng n PD_RISC processor and used for programmng control have been analyzed. These nstructons are: b, bcc and call. The dfference between b and bcc nstructons s that the bcc nstructon executes the branch based on a condton. Fg. 110 Power consumpton of cmpeq followed by bcc nstructon s approxmately equal wth power consumpton of cmpeq followed by b nstructon Internally, the bcc nstructon means an analyss pror of the condton (resulted from another nstructon), and after that t could make the jump. We wanted to verfy ths assumpton, so t has been made the followng experment: we measure the power consumptons for b (uncondtonal jump), bcc nstructons (condtonal jump) and for a compare nstructon cmpeq. The values for the consumpton of b nstructon and for the consumpton of cmpeq nstructon, together wth the average of the two values, can be seen n Fg. 110 (the blue lne). The red lne s the consumpton of one compare nstructon followed by a bcc nstructon. The red lne s approxmately equal wth the end of blue lne (the average value of b and cmpeq), the lttle dfference represents the power consumpton due to the pror analyss (whch s part of a bcc nstructon). Ths experment valdated the correctness of the measurements and also, gave us mportant detals regardng how nstructons are executed nternally n the processor. The last tested control nstructon was the call nstructon. Lke b, t s an uncondtonal branch nstructon, but, n addton, the call nstructon stores the address of the followng nstructon nto a regster. Fg. 111 shows the consumpton power values for all control nstructon. As a reference, the power consumpton for nop nstructon was added. 134

135 Research and Contrbutons n Energy-Effcency and Context-Awareness of Fg. 111 Power consumpton for control nstructons The last set of experments was to determne the power consumpton for compare and move nstructons. Regardng compare nstructons, t have been used nstructons whch compare regster wth an mmedate sgned/unsgned number and nstructons whch compare regsters. The chosen nstructons were: cmpltu, cmpeq (regster regster and regster number), cmplt, srl and sll. Fg. 11 Power consumpton for compare and move nstructon The power consumpton for all these nstructons can be seen n Fg. 11. It can be observed three levels of power consumpton: the lowest level s for compare nstructons between regster, the medum level s for compare nstructons between one regster and one number, and the hgher level s for move nstructon. The power consumpton for all tested nstructons can be seen n Fg The nstructon wth the most power consumpton s mul nstructon, and wth the lowest power consumpton s nop nstructon. Another observaton s that the nstructons whch are part of a group of nstructons (e.g. arthmetc, logc, memory access, etc.) are grouped together n ths chart. For benchmarkng purpose wth FPGA power measurement, the test benches used on FPGA are smplfed for gate level smulaton due to the long smulaton tme. Typcally, each test bench contans one type of nstructon wth random operands, whle the test bench s smulated for only 1,000 clock cycles. Compared to test benches used n FPGA measurement, such tmng trade off leads to naccuracy n smulated power values, whch s caused by the less swtchng actvtes n operand values. 135

136 Fg. 113 Power consumpton for all tested PD_RISC nstructons The correlaton coeffcent between physcal measurements of a RISC core mplementaton on FPGA board (45nm) and smulated ASIC (45nm) power values, s 86.39%. Even though ths value shows a strong correlaton between the two seres, the method based on physcal measurements s recommended because of the reduced executon tme and ts hgher accuracy and valdaton. The complete correlaton matrx of the nstructon level power consumpton seres acheved for dfferent technologes and manufacturng processes s presented n Tab. 6. Very strong correlatons between ASIC estmated seres are observed, whle good correlaton between FPGA and ASIC exsts too. 130nm 90nm 65nm 45nm 45nm (faraday) (faraday) (faraday) (Nangate) (Atlys) 130nm (faraday) 1 90nm (faraday) 9.11% 1 65nm (faraday) 98.95% 9.53% 1 45nm (Nangate) 98.67% 93.16% 98.37% 1 45nm (Atlys) 85.78% 95.47% 84.34% 86.39% 1 Tab. 6 Power consumpton correlaton matrx Fnally, the power technology gap between the RISC core FPGA mplementaton and ASIC smulatons for 45nm manufacturng process s between 00 to 1000 tmes larger. Smlar analyss has been carred out for the Mcroblaze core. Power consumpton of man Mcroblaze nstructons are shown n Fg Even MB core are optmzed for FPGA desgns, some dfferences n power consumpton can be observed. 136

137 Research and Contrbutons n Energy-Effcency and Context-Awareness of Fg. 114 Power consumpton for all tested Mcroblaze nstructons 6.4 RELATED WORK At present, there are many technques and tools used for montorng an FPGA. Most of these tools have ntegrated power montorng and energy consumpton estmaton solutons capable of dong most of the work. In [Tong008], a survey of proflng tools s presented and they are categorzed as follows: software based, hardware based and FPGA based. The software based proflng s wdely used n order to analyze the performance of applcaton code and can be further classfed n two approaches: smulaton and nserton of nstrumentaton code. The hardware based proflng tools [Tong008] make use of hardware counters avalable on chp that are used to montor certan events that occur whle an applcaton s executed. The events that can be checked are: ppelne stalls, cache msses, memory accesses and others. FPGA based proflng tools [Tong008] make use of the soft processor avalable on FPGAs, whch s used as target processor for the executon of software programs. The proflng process s as follows: the software s executed on the target soft processor by the desgner and after that, the nformaton about performance s captured usng the hardware for proflng avalable on chp. Many of these tools used a soft processor n order to perform the evaluaton for a gven desgn. The estmaton s done based on code analyss and other external nstruments. LEAP s presented as an FPGA based hardware profler beng developed as a non ntrusve and area effcent tool [Aldham011]. In order to analyze an executed program, LEAP montors the nstructon bus of the processor together wth the program counter. Its objectve s to fnd a perfect correlaton between the routnes and the counters, based on the startng address for each functon. In [Genser009], the authors developed two profles for each software applcaton: a power estmaton based profle and a power measurement based profle. The estmaton based profle s less accurate because t's based on power modelng, but t provdes hgher flexblty. The other profle, provdes extremely accurate results, but requres addtonal equpment. A framework made by many abstracton layers s presented n [Powell013]. Ths framework s useful for the desgn space exploraton process. Insde the framework many unts are presented, 137

138 lke: control unt, nstructon management unt, data processng unt or memory management unt. Each unt has dfferent metrcs and bulds a separate power profle. Another energy estmaton method s va nstructon level energy proflng [Laopoulos003, Kavvadas004]. There, every nstructons power cost s broken nto multple costs (e.g. base cost, nteracton cost, operand costs, etc.). Ths approach tred to capture all the dependences between nstructons. However, ths method s dffcult to mplement because of the multple dependences between nstructons (e.g. data dependences, processng features, cache type, multpler desgn, etc.) In [Ou004] the authors propose an nstructon level proflng methodology on FPGA desgns. The proposed methodology can rapdly estmate the energy dsspaton of software programs runnng on FPGA mplemented soft processors. In our work we address energy proflng of mult core archtectures. In [Aff014], a method s proposed to estmate the dynamc power consumpton of Mcroblaze soft core used n embedded desgns for FPGA. The proposed method s based on expermental test bench of mplemented desgns where the processng unt s repeated dstnctly, and on real power measurements are captures. The authors of [Pallares01] focus on nstrumentaton and measurement of FPGA desgns for power qualty measurements. In [Attallah013] the authors present a global framework for power and energy estmaton and optmzaton of heterogeneous multprocessor system on chp. Wthn ths framework, a power modelng methodology s defned, and an open platform s developed. The proposed methodology takes nto account all the embedded system layers: the software, the hardware, and the operatng system. Our approach s based on physcal power measurement of the FPGA devce. A smlar approach was used n [Nakuts009], for several types of embedded systems. However, our method s not restrcted on desgns whch use soft processors and can be performed on any FPGA devce. Smlar work has been performed on Zynq development board for power control and montorng [Beldach014]. Power montorng and estmaton do not target only processng cores but also memory and nterconnect components [Schurmans013]. 6.5 SUPPORTING GRANTS, RESEARCH TEAM AND SCIENTIFIC OUTCOMES Project ttle: GreenEr Moble Systems by Cross LAyer Integrated energy Management Natonal competton: CHIST ERA Implementaton perod: Project acronym: GEMSCLAIM Project code: CHIST ERA/1/ Budget: EUR 138

139 Research and Contrbutons n Energy-Effcency and Context-Awareness of Project summary: The GEMSCLAIM project ams at ntroducng novel approaches for reducng the greed for energy of modern battery powered systems, thereby mprovng the user experence and enablng new opportuntes for moble computng. Moble termnals and consumer devces are among the fastest growng markets n computng. In the long term, further growth s endangered by the power/ energy wall. The purpose of GEMSCLAIM s to explore new technques n energy optmzaton va an nterdscplnary vertcal approach: a novel combned optmzaton across the major HW/SW system layers (compler/os/hw platform). The ever growng need for energy effcent computaton requres adequate support for energyaware thread schedulng that offers nsght nto a systems behavor for mproved applcaton energy/performance optmzatons. Runtme accurate montorng of energy consumed by every component of a mult core embedded system s an mportant feature to be consdered for future desgns. Although, mportant steps have been made n ths drecton, the problem of dstrbutng energy consumpton among threads executed on dfferent cores for shared components remans an ongong struggle. We am at desgnng a generc low cost and energy effcent hardware nfrastructure whch supports thread level energy consumpton montorng of hardware components n a mult core system. The proposed nfrastructure provdes upper layers (operatng system and applcaton threads) wth per thread and per component energy accountng API (Applcaton Programmng Interface), smlar wth performance proflng functons. Implementaton results ndcate that the proposed LEM (Load and Energy Montor) adds around 10% resource overhead to the montored system. Regardng the power estmates, the one derved by LEM acheve a correlaton degree of more than 95% wth the ones obtaned from physcal power measurements. The research team nvolved n the project ncluded experenced researchers, young researchers, external researchers and students: PhD. (local partner drector) PhD. Oana AMARICAI BONCALO PhD. Alexandru AMARICAI BONCALO PhD. Cosmn CERNAZANU GLAVAN PhD. Sebastan FUICU PhD. Razvan BOGDAN PhD. Gabrel GIRBAN Eng. Lucan BARA Eng. Madaln GHENEA Eng. Maran IONASCU Partners: Innsbruck Unversty (Lead partner) Queen s Unversty Belfast RWTH Aachen Unversty The contrbutons of ths work are as follows: 139

140 hardware nfrastructure for dynamc energy consumpton montorng n a heterogeneous mult core system wth per thread energy accountng; energy nterrupt specfcaton and desgn; a use case on the software sde (OS and drvers) for run tme per thread energy accountng mplementaton on FPGA; and valdaton of proposed nfrastructure on a hgh end FPGA board wth physcal energy measurements. Ths secton s based on the followng papers publshed by the author: [ISI5], [BDI] and t has been submtted to ISCAS 016 conference. 6.6 CONCLUSIONS AND FUTURE WORK FPGA development boards are broadly used nowadays to mplement target platforms prototypes and test them on real hardware. In our work we nvestgated the possblty to profle energy of target hardware desgns usng FPGA synthess and we presented energy proflng results for a FPGA development board. The man goal of our study was to nvestgate the power measurement and proflng capablty of FPGA development boards. The processor to be profles has been mplemented on FPGA and dfferent benchmarks programs have been executed. The goal of these measurements has been to nvestgate the correlaton between dynamc power consumpton measurements of RISC processor nstructon set on FPGA board wth the ones estmated for the same processor mplemented n a dfferent technology. The processor nstructon set s dvded nto several groups: arthmetc logc nstructons, memory access nstructons, control nstructons, compare and move nstructons. An nterestng observaton s that the nstructons from a group of nstructons have smlar power consumpton. If we chart the power consumpton for all the nstructons we can observe that each group of nstructon has a certan level for power consumpton (dstnct from other groups). The nstructon wth the hghest power consumpton s mul nstructon, and wth the lowest power consumpton s nop nstructon. The correlaton coeffcent between the FPGA 45nm power measurements and ASIC 45nm power estmaton s 86.39%. The benefts of ths work are two folds. On one hand we can estmate dynamc power consumpton by physcal measurements, whle on the other hand, we can valdate power consumpton models usng real measurements. As a future work, t s mportant to determne how the power estmaton accuracy scales wth ncreasng program complexty. Furthermore, an accurate power montorng and management soluton based on fne hardware parameters tunng wll be mplemented. 140

141 Research and Contrbutons n Energy-Effcency and Context-Awareness of 7 LOW-COST HARDWARE INFRASTRUCTURE FOR RUNTIME THREAD LEVEL ENERGY ACCOUNTING 7.1 OVERALL DESCRIPTION AND RESEARCH OBJECTIVES The ever growng need for energy effcent computaton requres adequate support for energyaware thread schedulng that offers nsght nto a systems behavor for mproved applcaton energy/performance optmzatons. Runtme accurate montorng of energy consumed by every component of a mult core embedded system s an mportant feature to be consdered for future desgns. Although, mportant steps have been made n ths drecton, the problem of dstrbutng energy consumpton among threads executed on dfferent cores for shared components remans an ongong struggle. We am at desgnng a generc low cost and energy effcent hardware nfrastructure whch supports thread level energy consumpton montorng of hardware components n a mult core system. The proposed nfrastructure provdes upper layers (operatng system and applcaton threads) wth per thread and per component energy accountng API (Applcaton Programmng Interface), smlar wth performance proflng functons. Implementaton results ndcate that the proposed LEM (Load and Energy Montor) adds around 10% resource overhead to the montored system. Regardng the power estmates, the one derved by LEM acheve a correlaton degree of more than 95% wth the ones obtaned from physcal power measurements. 7. PER-THREAD ENERGY ACCOUNTING 7..1 Hardware nfrastructure The proposed PTEA soluton, called Load and Energy Montor (LEM), mplements a dstrbuted sensor network through a dedcated bus nterconnect based on the open hardware Wshbone Bus (WB) specfcaton [OpenCores010], whch s both cost effectve and lght weght. It conssts of a generc hardware montorng nfrastructure whch s able to connect the dstrbuted sensors attached to the components of an embedded target desgn. LEM montorng nfrastructure allows software layers to access at runtme, both the component level usage and the energy estmates. LEM control and confguraton s centralzed, thus provdng a unque nterface to the upper layers. The LEM nfrastructure buldng blocks are: LEM sensors (S LEM), LEM controller (C LEM) and LEM nterconnect (LEM Bus) (Fg. 115). The sensors are hardware components that collect data from the underlyng system at a programmable hgh speed rate. Furthermore, they perform component level performance or energy accountng computatons; thus, allowng fne gran component power tunng. The sensors sampled values may be swtchng actvty, performance counters, and power or temperature physcal measures. Therefore, the proposed sensors offers hgh flexblty to system desgners. For the consdered uses cases n our work, we have mplemented only energy accountng sensors, because we amed at valdatng per core energy accountng as 141

142 hardware support for PTEA. Sensors can be attached to ndvdual cores, accelerators, or shared component components of the target system such as memores or buses. C-LEM EINT 0 EINT n-1 S-LEM I/O DRAM Bus Core 0 Core 1 Core n-1 Fg. 115 Overall energy montorng archtecture C LEM performs energy accountng at core level, collectng and summng energy consumpton values from both local sensors, attached to cores local buses and memores, and shared sensors, attached to shared components, such as DRAM memory or system busses. Two mportant features of LEM nfrastructure are non ntrusveness and energy nterrupts. Nonntrusveness s acheved by weak couplng between the montorng nfrastructure and the target system (Fg. 100), due to the specal sensor desgn. Energy nterrupts are generated for each core n the target desgn when the energy budget correspondng to the core has been consumed. The sensors mplement a standard nterface for the varous performance and/or consumpton montorng support exstng n hardware. The sensors are composed of (Fg. 116.a): (1) sensor nterface used to connect the sensor core wth the central LEM; () sensor back end (wth some processng and tunng support hardcoded coeffcents and/or look up tables) wth lmted energy consumpton accountng and (3) hardware nterface probes whch s component or bus specfc. The sensors can be confgured to provde energy, power or raw data. Energy accountng s performed by summng up the samples from the component untl then next poll from the master LEM controller. Power montorng s performed by averagng the samples from the component untl the next read from the master controller. Raw data from low level component montors are passed drectly as nstantaneously values to the LEM controller. Sensor back end ether reads the energy consumed by a component (some processng cores offer ths nformaton through some dedcated ports), or derves the energy consumed by addng for each accounted event a value from a stored table wth a pror computed values. Some approaches whch rely on software post processng of C LEM data, smlar n functonalty as the ones used n HEMA tool [Cho01], can be used to reduce the resource overhead for the montorng nfrastructure. 14

143 Research and Contrbutons n Energy-Effcency and Context-Awareness of LEM bus nterface Bus nterface AXI Slave LEM memory LEM Controller Interrupt / core Tunable knobs Processng core Readable counters Sensor core LEM Bus LEM bus nterface LEM Bus LEM Bus LEM Bus Montorng ports Physcal probes S- LEM S- LEM S- LEM S- LEM a) b) Bus Montor Look-up table MB LEM Sensor Energy counter LEM Bus AXI Montor Energy model DDR LEM Sensor Energy counter/ Core LEM Bus c) d) Fg. 116 LEM components: a) Sensors archtecture; b) C-LEM; c) MB nstructon sensor; d) DRAM shared data sensor Dependng on the power meterng nfrastructure avalable on the board the LEM sensors can be attached to physcal sensors or can mplement energy models. Our soluton ams at dervng energy consumpton by correlatng event accountng (.e. event counters at varous levels n our system) wth component based energy n the pre computed look up tables. Usng montorng ports, LEM sensors can access underlyng montorng components (e.g. performance counters, physcal sensors, or events montors). C LEM (Fg. 116.b) controls and collects sensor data from exstng LEM sensors and provdes the OS wth structured access to the sensors data. The OS communcates wth the central LEM unt through the global memory address space for sensor control and samplng. Data receved from S LEM s aggregated nto the C LEM local memory. Each component of the target system has a reserved 18 bts memory structure, ncludng tmestamp, component usage, processng energy, and data movement energy. One or more sensors collect measurements for every component, whle C LEM aggregates these values at the component level. For each component two energy values are accounted: component operaton energy and data movng energy. These values are collected from the sensors montorng the respectve component and ts nterfaces. Each memory locaton stores the last value calculated from all the sensors that are attached to the core tself or to a shared component accessble to the core. Furthermore, C LEM s also hghly parameterzed, and t can be programmed by the underlyng software same as the router from [Maddur009]. Dedcated regsters allow the programmng of the LEM for: enablng/dsablng montorng for a component, enablng/ dsablng energy nterrupt, changng the samplng rate, controllng the power model or selectng the sensors accountng mode. LEM bus s based on WB standard [OpenCores010], havng one master (C LEM) and several slaves (S LEM, up to 56 n the current mplementaton). It has a confgurable number of data lnes for read and wrte channels, whch provdes C LEM wth effcent access to S_LEMs. As 143

144 read operatons are more frequent, we have selected an ncreased bus wdth for ths channel (3 n the current mplementaton), wth respect to the wrte channel (8 bts). Fg. 116.b hghlghts the C LEM and ts LEMbus master and AXI slave nterfaces. C LEM has also an AXI slave nterface, thus, provdng access for the target system to read data and wrte commands for the LEM. The cores can poll C LEM for ther current load and energy counters through the AXI nterface. There are currently three classes of sensors used by LEM: (1) nstructon sensors (core processng sensors), that montor an nstructon bus and calculate the energy of each nstructon executed by a sngle processng core; () shared data sensors, that montor a shared data bus and calculate the energy consumpton of data transfers for each processor montored; (3) local data sensors, that montor a data bus that corresponds to a sngle processor. The LEM reads data from each sensor sequentally and aggregates the data dependng on the type of the sensor and stores t n the energy counters of C LEM memory. Instructon sensors provde LEM wth support to measure or estmate the processng energy of the cores they are attached to. These sensors are specfc to the processng core they montor and the nstructon bus they are connected to. However, beng modular, S LEM sub components have a hgh degree of flexblty: the S LEM processng core can be connected to dfferent busses only by changng the bus nterface montor. Instructon sensors ncluded n the FPGA desgn target the Mcroblaze (MB) processor, a soft core provded by Xlnx [Xlnx014]. Mcroblaze s S LEM s mplemented as a vrtual sensor that montors the core s nstructon bus and partally decodes the MB opcodes n order to assocate estmates wth the executon energy (Fg. 116.c). Energy counter s ncremented wth the energy amount assocated to the nstructons executed by the processor. Energy values stored n the S LEM look up table have been computed through energy proflng on the target FPGA board. Shared data sensors attached to the shared components of the target system allow per core energy estmaton of these components. These sensors are able to dentfy and dspatch the amount of energy consumed by the shared component to the core that s responsble for the energy consumed by the component (Fg. 116.d). Shared data sensors mplement nternally one energy counter per core, whose contents are summed up at the core level, wthn the C LEM. Each data transfer and nstructon executon made by a processor have an energy budget. The aforementoned data transfers and nstructons are montored by several sensors whch transmt the energy consumed to C LEM. Component load and energy counters can be accessed drectly by cores through ther memory space or an nterrupt s generated when a specfc energy threshold has been reached. Energy nterrupts are hardware nterrupts that become actve when the energy budget allocated to a specfc component or core has been consumed. LEM can be programmed to send an energy nterrupt to a processor whch s beng montored when an energy budget threshold s reached. The threshold value s stored by one energy quantum regster allocated per core. The energy budget value s compared to the current energy consumpton, whch s calculated by summng the values stored n the Instructon Energy Regster and the Data Energy Regster. If the current energy consumpton exceeds the energy budget value and the LEM nterrupt opton s actve, then an nterrupt sgnal s generated for one clock cycle 144

145 Research and Contrbutons n Energy-Effcency and Context-Awareness of and s captured by an nterrupt controller, ths s transmtted to the correspondng processor. After the deactvaton of the nterrupt sgnal, the LEM energy regsters correspondng to the current processor are reset. The LEM can montor several processors smultaneously and can generate ndependent nterrupts for each processor when t reaches ther correspondng energy threshold. Each energy nterrupt can have a dfferent nterrupt handler; thus, a hgher degree of flexblty s acheved. 7.. Implementaton use-case LEM nfrastructure s a hardware soluton that can be customzed for dfferent applcatons. It has been further customzed and used to mplement PTEA n a mult core system. In a mult core system we consder three types of components: processng cores (could be homogeneous or heterogeneous), prvate resources and shared resources (e.g. memores and nterconnects). In a mult core hardware envronment, every core has a unque core ID. Our dea s to use ths ID n hardware transacton wth shared components to dentfy the processng core whch wll be charged wth the energy budget of the current transacton. The LEM sensors connected to these shared components wll use master ID to account per core energy consumpton. Modern nterconnects lke Wshbone (open source) and AXI (ARM) allow system desgners to attach meta nformaton to each transfer. For example, Wshbone bus standard specfes userdefned tags to apply extra nformaton to each bus cycle [OpenCores010]. On the other hand, AMBA open specfcaton [ARM003] assocates mplctly hardware IDs of the master to each bus cycle. ARID, RID, AWID, WID and BID bus sgnals are carryng ID tags of the read address, read, wrte address, wrte and response bus transfers. Hence, t makes sense for the LEM sensors of shared resources to use the master ID of the access to splt the energy consumed for shared components. Usng the LEM nfrastructure and the ID taggng bus support, PTEA mplementaton can be splt n two steps: (1) Per core energy accountng of processng cores and shared resources based on hardware support; () Per thread energy accountng mplemented at OS level durng context swtchng, usng the provded LEM drvers. LEM drver provdes OS wth an API smlar to exstng performance proflng counters functons. The LEM drver nterface s based on start/stop accountng operatons. When a thread context swtch occurs, the OS wll store the energy counters of the current thread and wll restart the counters for the next thread. Whle a thread s executed by a core, per core energy accountng mplemented n hardware wll be used to account for the energy of a runnng thread. Consderng that a core wll execute only one thread at the tme, the coordnaton between OS and HW wll account for the thread level energy n a mult core/mult threadng executon envronment. 145

146 S- LEM DRAM DRAM Controller Instr. & Data Bus Bus snffers S- LEM L cache Instr. & Data Bus L cache Instr. & Data Bus S- LEM S- LEM L1 ICache Core 0 L1 DCache L1 ICache Core 0 L1 DCache S- LEM S- LEM L1 ICache Core 0 L1 DCache L1 ICache Core 0 L1 DCache S- LEM Fg. 117 Memory herarchy montorng LEM hardware nfrastructure comprses of bus/nterconnect snffers (S LEM). These montor for the number and type of accesses for each shared components. Energy accountng s estmated usng look up tables whch correlated the energy consumed wth the number and type of accesses. We further dscuss the PTEA use case for the example target platform used n [Lu013] Fg In case core0, from cluster0, has a cache mss n L cache, three events are reported by three sensors: access L1 cache (by the processng core s sensor), access L cache (event reported by the cluster bus: L cache access), access memory controller (event reported by the system bus). Each of these events are accounted on behalf of core0. The proposed approach dffers from the one descrbed n [Lu013] by the fact that events such as drty lne, cache lne evcton, cache ht or mss are not montored solely on the shared component sde. These are a drect consequence of our proposed accountng method, and are transparent for the nfrastructure. For example, a cache lne evcton requre a number of events on the system bus; the shared cache sensor for the processng core (dentfed by master ID) s notfed by the sensor on the system bus that energy needs to be accounted on ts behalf. Ths mechansm s herarchcal. Furthermore, the means for these types of notfcatons represent transactons on the LEM nfrastructure. Therefore, the bus topology of the LEM nfrastructure s smlar wth the one n the montored system. So far we dscuss the possblty of usng LEM as a passve montorng component, much lke the way performance montorng counters are used by system software. In bref, at context swtch dctated by schedulng tme ntervals, the OS kernel on each core queres C LEM to retreve energy sensor readngs and attrbutes energy consumpton to runnng threads. Whle ths approach can accurately account energy consumpton at the thread level, t provdes lmted support to mplement energy budgetng polces whch are crucal n optmzng energy effcency of embedded platforms [Zeng00][Snowdon009]. Ths s because the OS can account of energy consumpton only by samplng at tme based schedulng ntervals. Durng such an nterval, the OS has no control over how much energy a thread spends, thus t cannot enforce energy budget lmts. 146

147 Research and Contrbutons n Energy-Effcency and Context-Awareness of We extend LEM to mplement what we refer to as the energy nterrupt. In the same way a programmable tmer generates an nterrupt whenever ts tme slce depletes, LEM s extended wth an energy slce and generates an energy nterrupt when ths energy slce depletes. Specfcally, LEM s extended wth an extra regster per core (assocated wth a unque core ID) to store the energy slce value. Recall core IDs unquely dentfy thread IDs n the OS, snce only one thread can be runnng on a core at a tme. The OS sets LEM s energy slce regster to the avalable budget for ths core whch corresponds to the allotted energy budget for the core s executng thread. LEM decreases the energy slce by montorng the energy consumpton due to the core s actvty across all hardware components. When the energy slce s depleted, LEM generates an energy nterrupt to the core, to be handled by the OS. The OS nterrupt handler reads the LEM s sensor values per hardware component for a breakdown on thread s energy consumpton and overwrtes the LEM s energy slce regster wth the new energy budget value for the scheduled n thread, accordng to the energy budgetng polcy. A further extenson, left as future work, s to enable energy slces for each hardware component nstead of accumulatng energy consumpton across all of them. Ths wll permt even fner control on dstrbutng the energy budget among hardware components, to be leveraged n component level energy budgetng polces. 7.3 EXPERIMENTAL RESULTS The LEM nfrastructure has been mplemented on the Xlnx ZC70 evaluaton kt, wth Xlnx Zynq 700 devce. Xlnx Vvado toolset has been used for the mplementaton of the system. The development board has bult n power montorng sensors for the power lnes of the man components: processng system cores (ARM cores), programmable logc core (FPGA fabrc), DRAM, I/O etc. Four target systems smlar wth the reference desgn (see Secton 5.) have been analyzed n order to estmate the area/performance/energy overhead of the LEM mplementaton compared wth montorng free stuaton. Furthermore, LEM mplementaton was compared wth other solutons that can provde support for energy accountng mplementaton: exstng Mcroblaze (MB) performance counters and Xlnx IP AXI PerfMon. The four systems feature 1,, 4, and 8 cores respectvely, each beng extended wth all the nfrastructure needed to estmate energy consumpton per core. The mplementaton overhead of the Mcroblaze SoC system featurng 1,,4, and 8 cores respectvely s presented n Fg Fg. 118.a presents the slce cost for the system wth the followng montorng confguratons: no montorng, MB performance counters montorng, Xllnx bus performance montors, and the proposed montorng nfrastructure. The cost for the 8 core system wth performance montors dd not ft the Zynq board resources. Compared to other montorng solutons LEM nfrastructure gves a better area/power consumpton tradeoff (Fg. 118.b). Wth respect to the Xlnx bus perfomance montors, t presents up to 30.7% less slce based resources, whle offerng the same degree of observablty. Compared to the MB performance counters, t present a % ncreased cost. However, the proposed nfrastructures has the followng advantages: () t has ncreased observablty, because t provdes performance nformaton for other components n the system (bus, memory controller, etc), () t has better performance, as t requres less nstructon cycles for confguraton and readng. 147

148 Base system ub performance counters LEM Performance montors Base system ub performance counters LEM Performance montors core cores 4 cores 8 cores a) b) * Xlnx PerfMon component for 8 cores desgn exceeds the avalable board resources, the values are thus not avalable 0 1 core cores 4 cores 8 cores Fg. 118 Cost estmates for the system wth dfferent montorng nfrastructures: a) Number of used slces; b) Statc power consumpton The reference system desgn for PTEA valdaton s presented n Fg. 100 and has four Mcroblaze soft cores. The clock frequency for the MB s 50 MHz. The cores nclude local nterrupt controller, local nstructon and data memory and local nstructon and data buses. Local nterrupt controllers serve two nterrupt sources: tme nterrupt (1 ms) and energy nterrupt (~100 nj). The reference desgn mplements the LEM nfrastructure attached to the 4 cores desgn. The system wth four MB cores need two shared DRAM sensors Fg (one for nstructon bus and the second one for data bus) and three more local sensors per core (one DRAM nstructon sensor, one BRAM data sensor and one BRAM nstructon and data sensor 3). In total LEM mplements 14 sensors and one C LEM (4) wth 16 ports. To valdate the LEM nfrastructure, standalone benchmarks from the WCET project [WCET] have been selected. We have consdered the followng representatve benchmark applcatons: a compresson benchmark (COMPRESS), a CRC calculator (CRC), a FFT algorthm (FFT), a bt manpulaton benchmark (BIT), a FIR flter (FIR), a Petr Net smulator (PETRI) and an auto generated code (AGC). These are self contaned software programs that do not requre any addtonal lbrares, operatng or fle systems. The self contaned benchmarks were needed to valdate the energy nterrupt concept, n order to avod any nterference wth other programs, because the lack of an operatng system makes the results determnstc. The benchmarks have been run two tmes on two dstnct Zynq boards. Each benchmark has been executed on the reference system on one core, two cores and four cores. Regardng the storage of data and nstructons for each benchmark, the followng cases have been consdered: (1) both nstructons and data are located n DRAM, () nstructons are executed from DRAM and data are located n BRAM, (3) nstructons are executed from BRAM and data are located n DRAM and (4) both nstructons and data are located n BRAM. BRAM s the local memory of each core, havng the same performance as an L1 cache. L1 and L cache levels have been dsabled durng the tests n order to observe the energy mpact of shared/local components. Whle executng the benchmarks, performance and energy proflng have been performed. For each test set tmer tcks, 148

149 Research and Contrbutons n Energy-Effcency and Context-Awareness of LEM energy quants and physcal measurements have been recorded for further analyss. However, physcal measurements needed many sequental runs of the benchmarks wth the same parameters n order to let the system stablze. In total more than 48 tests have been performed for each benchmark, each test lastng 1 mnutes. LEM sensors have been calbrated usng exstng energy proflng technques as descrbed n the prevous secton. The frst test case conssted of FIR benchmark on multple cores wth four tests changng the locaton of nstructons and data: (1) both benchmark s nstructons and data are executed from DRAM, () both nstructons and data are n BRAM, (3) nstructons are executed from DRAM and data are stored n BRAM, and (4) nstructons are executed from BRAM and data are stored n DRAM. We amed at determnng the correlatons between the power estmaton provde by LEM nfrastructure wth the physcal measurements on the Zynq board. The graphc n Fg. 119.a depcts the correlaton obtaned for the FIR benchmark. Overall correlaton value for ths benchmark s 96.57%. For ths case, LEM sensors have mplemented smple MB, DRAM and BRAM energy models based on look up tables and lnear regresson, respectvely. However, ths result valdates the LEM nfrastructure both as (1) a mean for new energy models calbraton and evaluaton based on runtme hardware measurements and () onlne system hardware proflng based on physcal onboard sensors or vrtual model based sensors. 15 Power consumpton of FIR executon n dferent contexts a) b) Fg. 119 Power consumpton measurements for FIR benchmark: a) Correlaton results b) LEM normalzed power Fg. 119.b depcts an analyss for the onlne system hardware proflng for systems wth 1 MB core, MB cores and 4 MB cores whch execute the FIR benchmark. When nstructons are executed from local BRAM memores, the performance and the energy consumpton of the system scales lnearly wth the number of cores. Ths remark shows the effcency of L1 nstructon caches (whch for FPGA systems are mplemented n BRAM); ths result also valdates the proposed montorng envronment. On the other hand, when nstructons are executed from DRAM, the system s lmted both n performance and power consumpton at two cores. The second test case amed at emphaszng the energy effcency of the benchmarks executons n dfferent system contexts: number of cores, locaton of nstructons and data. In order to characterze benchmarks executons n dfferent contexts we accounted for runtme tmer tcks 149 P [normalzed] # of cores Instr & Data BRAM Instr BRAM & Data DRAM Instr DRAM & Data BRAM Instr & Data DRAM