Wireless Embedded Systems Powered by Energy Harvesting

Wireless Embedded Systems Powered by EnergyHarvestingAttila Strba ∗Institute of Applied InformaticsFaculty of Informatics and Information TechnologiesSlovak University of Technology in BratislavaIlkovičova 3, 842 16 Bratislava, Slovakiastrba@yahoo.comAbstractAmbient intelligence requires that devices integrated tothe environment are self-sustaining and maintenance free.To fulfill the vision of ambient intelligence, the designof small wireless embedded systems powered by energyharvesting is needed. Our work raises awareness thatgeneric embedded system and wireless sensor nodes aredifferent from wireless embedded systems powered by energyharvesting (WESPEH) therefore a different designapproach is required. The work introduces a new designtechnique based on rapid prototyping and constraintsanalysis. From different groups of constraints the softwareproblematic is developed in detail further with the focuson operating system design.Comprehensive analysis of thin resource operating systemsleads to the conclusion that existing systems arenot designated to run on a dedicated WESPEH hardwareplatform. We define the requirements, architectureand design aspects of energy autonomous operating systems.Based on these definitions a new operating systemDolphinAPI is designed and implemented. The initialimplementation is performed on the EO3000I hardwareplatform.Analysis of existing benchmark methods shows that commonbenchmark methods focus entirely on the computationalperformance, neglecting other important features ofan operating system such as memory needs or influenceon the energy consumption. Therefore a new operatingsystem quantification methodology - considering energyconsumption, scheduler behavior and application utiliza-∗ Recommended by thesis supervisor: Assoc. Prof. TiborKrajčovič. Defended at Faculty of Informatics and InformationTechnologies, Slovak University of Technology inBratislava on November 24, 2011.c⃝ Copyright 2012. All rights reserved. Permission to make digitalor hard copies of part or all of this work for personal or classroom useis granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies show this notice onthe first page or initial screen of a display along with the full citation.Copyrights for components of this work owned by others than ACMmust be honored. Abstracting with credit is permitted. To copy otherwise,to republish, to post on servers, to redistribute to lists, or to useany component of this work in other works requires prior specific permissionand/or a fee. Permissions may be requested from STU Press,Vazovova 5, 811 07 Bratislava, Slovakia.Strba, A. Wireless Embedded Systems Powered by Energy Harvesting.Information Sciences and Technologies Bulletin of the ACM Slovakia,Vol. 4, No. 1 (2012) 1-13tion - is introduced . The methodology is based on vectordefinition and trace-driven performance analysis. Usingthe methodology TinyOS and Dolphin API is evaluatedand compared. For an objective evaluation TinyOS is migratedto the EO3000I hardware platform. As part of themigration the EnOcean protocol stack is implemented inNesC.Categories and Subject DescriptorsD.4.7 [Operating Systems]: Organization and Design—Real-time systems and embedded systems; D.4.8 [OperatingSystems]: Performance—Measurements, Modelingand prediction; D.2.8 [Software Engineering]: Metrics—Productmetrics; C.3 [Special-Purpose andApplication-Based Systems]: Real-time and embeddedsystems; C.3 [Performance Of Systems]: MeasurementtechniquesKeywordswireless embedded systems, energy harvesting, rapid prototyping,prototype rating, design technique, operatingsystem design, operating system quantification, performanceprediction1. IntroductionWith our work we would like to raise the awareness ofthe research community that to fulfill the vision of ambientintelligence requires the introduction of a new devicecategory. The aim of this research is to examine variousproblematic aspects of wireless embedded systems poweredby energy harvesting and propose solutions. Themajor goals of the research can be summarized in threecategories:• Introduction of the device category wireless embeddedsystem powered by energy harvesting. Definitionof the architecture, application scenarios andpowering possibilities of these devices. Discussionand categorization of design problems, proposal ofappropriate design methodology.• Discussion of specific software design issues for energyautonomous wireless devices. Definition of requirements,architecture, design and implementationaspects of operating systems for energy autonomousdevices. The feasibility of the definitionshas to be demonstrated by implementation.

2 Strba, A.: Wireless Embedded Systems Powered by Energy Harvesting• Finding an appropriate quantification methodologyfor energy autonomous operating system evaluation.2. Wireless embedded systems powered by energyharvestingWe introduce the term Wireless Embedded Systems Poweredby Energy Harvesting (WESPEH). It is explainedwhy there is a need for new device category. The architectureand properties of WESPEH are described. Theuse case of WESPEH is presented on various applicationscenarios. We give an overview of energy harvestingpowering possibilities and show how much power can betransformed from ambient energy sources. Furthermorewe deal with the design problematic of WESPEH devicesand introduce a new design technique based on constraintgroup analysis and prototype quantification.2.1 DiscussionRapid miniaturization and performance increases of theintegrated circuit leads to the development of tiny embeddedsystems integrated more and more into our everydayobjects and will create a world of smart devices surroundingus. The Information Society and TechnologyAdvisory Group in 1999 defined a concept of future computingcalled ambient intelligence. This concept is basedon the fact that technological progress in the microelectronicsmakes the increasing miniaturization of embeddedsystems possible. The ambient intelligence conceptexpects that the miniaturization trend will soon lead tothe development of tiny wireless smart embedded devices,integrated more and more into our everyday objects.To fulfill the vision of ambient intelligence requires thatthere are several small-embedded devices integrated inthe environment. Each of these devices requires somesource of powering possibility and communication interface.While power can be transported with the help ofcables or devices could be powered by batteries, neitherof these possibilities offers an effective and long-term solution.Embedded systems will fulfill the ambient intelligenceconcept only if they are self-sustaining and maintenancefree. Such a requirement can be achieved only ifthese devices have a wireless communication interface andare powered from the environment using energy harvesting.Energy harvesting creates the possibility to use theomnipresent energy sources from our surroundings suchas, for example, moving objects, vibrating machine parts,temperature changes, electromagnetic waves such as light,radio waves or infrared waves and other energy sources.Pressing a button with 3N force, temperature differenceof 12K or just 500 lux of light generates enough energyto power a module equipped with a microcontroller anda RF-transmitter and to transmit a wireless signal.If we observe those emerging trends in embedded systems- miniaturization, wireless interface, energy harvesting –questions may arise as to whether embedded systems aswe know them nowadays are able to cover the requirementsof ambient intelligence. To be able to answer thesequestions let us briefly discuss the term ’embedded system’.Understanding the term embedded is helpful forunderstanding what application scenarios embedded systemscover. Embedding means to enclose or implant asessential or characteristic. The exact definition of an embeddedsystem, according D. Gajski [5], is as follows:“From the viewpoint of computing systems, an embeddedsystem is a special-purpose system in which a computer isentirely encapsulated by the gadget it controls. Unlike ageneral-purpose computer, an embedded system performspredefined tasks, usually with very specific requirementsand constraints.”Such a definition is outdated. The target usage of embeddedsystems has been transformed in the last ten years.Most of the embedded systems of the 21st century performa variety of different tasks with different requirements.We can demonstrate this fact with the cell phone.The original use of the cell phone was to make phone calls.By technological evolution, the purpose of this device hascompletely changed from the origin. It is also used as amultifunctional device for taking photographs, browsingthe internet, and much more. An anecdote from BjarneStroustrup provides a very good description of this statusquo:“I have always wished that my computer would be as easyto use as my telephone. My wish has come true. I nolonger know how to use my telephone.”A common element in the definition of embedded systemsis that they cover a wide variety of applicationswith vastly varying requirements. Let us demonstratethis fact with the following example. The term embeddedsystem refers to a line powered Coca-Cola-Automatwith TCP/IP networking capabilities, running WindowsCE on a 400MHz processor and several MB of RAM. Atthe same time, a pacemaker device is also categorized asan embedded system powered by lithium iodine batteryrunning a proprietary SW on an 8MHz processor with48kB flash and 10kB RAM. Despite the fact that boththe systems comply with the definition embedded system,the design approach and requirements on these two systemsare contradictory. Consequently we can not speakanymore about generic design methodologies, applicationrequirements and research challenges in terms of embeddedsystems.2.2 WESPEH DefinitionThe previous discussion leads us to the conclusion thatcategorizing ambient intelligence devices as embedded systemsis not a good solution. There is a gap in the currentunderstanding of these devices. Moreover existing embeddedsystem design techniques does not necessarily ensuresa successful design. This gap needs to be filled. Ambientintelligence devices need specific state-of-the-art designmethodologies and solutions. In order the vision of ambientintelligence is fulfilled a new category of devices has tobe introduced. Paper [1] discusses the vision of ambientintelligence in detail. Based on this paper we can derivethe requirements of devices fulfilling ambient intelligence.Devices fulfilling the vision of ambient intelligence:• are powered from the environment with the help ofenergy harvesting• are maintenance free• have a wireless communication interface• have a sensor/actuator interface• can interact with real-time events• have unobtrusive hardware

Information Sciences and Technologies Bulletin of the ACM Slovakia, Vol. 4, No. 1 (2012) 1-13 3Figure 1: Architecture of WESPEHFrom the requirements we can derive the name of thisdevice category as following Wireless Embedded SystemsPowered by Energy Harvesters (WESPEH). The architectureof a WESPEH is shown in Figure 1. The deviceconsists of an energy conversion unit that is the energyharvester itself. This unit converts the ambient energy toelectrical energy. The energy management block storesthe electrical energy to storage capacitor. In addition,the energy management unit is responsible for convertingthe voltage using a step down or step up converter tolower or higher value. Using this method the capacitorcan be loaded more effectively. For further functions, theenergy management block provides ultra low sleep timersto control the CPU and a voltage threshold detector. Themicrocontroller communicates using the RF interface andinteracts with the environment using sensor or actuatorinterfaces. From the above description, we can formulatethe following definition of WESPEH.Definition 1. Wireless Embedded System Powered by EnergyHarvester - designated as WESPEH - is a standalone;maintenance-free special-purpose computing system poweredby ambient energy; equipped with an uni- or bidirectionalwireless communication interface; capable of hardor soft real time interaction with the environment usingsensor and actuator interfaces.Considering WESPEH device architecture and comparingit to a wireless sensor node we can see several similarities.A question may arise if wireless sensor node correspondsto a wireless embedded system. To answer thisquestion there is a need to understand the difference betweenwireless embedded systems powered by energy harvestersand wireless sensor networks. According ThomasHaenselmann [6] the wireless sensor network is defined asfollowing:“A sensor network is a set of small autonomous systems,called sensor nodes which cooperate to solve at least onecommon application. Their tasks include some kind ofperception of physical parameters.”One of the main aspects in which embedded systems andwireless sensor networks differ is that embedded systemsare designed to work standalone. Wireless sensor networkdevices core design space is the network infrastructure[11]. The target application of wireless sensor networkis to build a large-scale ad hoc, multi-hop infrastructurecomposed of several thousands of nodes. A standalonewireless sensor node has no relevant functionality.Another aspect in which embedded systems and wirelesssensor networks differ is the purpose for which theyuse their communication interface. The embedded systemwireless interface’s purpose is to enable the humanto access information or trigger action. The sensor nodewireless interface’s primary focus is to interact with othernodes. In the case of the wireless sensor node, the bidirectionalwireless communication interface is obligatory,while WESPEH may use unidirectional communicationinterfaces. Wireless sensor nodes differ from WESPEHdevices also in having only sensing interfaces. WESPEHcan be equipped also with an actuator as described inthe application scenarios. The last major difference betweenWESPEH and WSN is the powering option. Whilein certain wireless sensor network scenarios battery is anacceptable option WESPEH must be maintenance-free,and energy autonomous. Part of the wireless sensor networkhas a lot in common with wireless embedded systemspowered by energy harvesting. Especially in applicationswhere WESPEH devices have a sensing role. Still thedesign problematic of wireless sensor networks does notfully cover the problematic of WESPEH. WESPEH hasto be handled as a separate device category.2.3 Powering possibilityUnderstanding the power problematic of WESPEH is akey objective to understand the device and software designdecisions discussed in later chapters. For this purposewe have analyzed various ambient energy sources and harvestingpossibilities. We have performed measurements todetermine how many energy is available from which typeof energy harvesters, what is the typical conversion efficiencyand dimension of the energy harvesters. All thesefacts are summarized in the thesis. From all the energypowering possibilities most proven are the photovoltaicenergy harvesters.2.4 Application scenariosWESPEH find the usage in various application fields. Thedefinition of scenarios should help to understand the designproblematic of WESPEH. The thesis discusses variousWESPEH application scenarios in detail. This extendeddissertation abstract contains only the summarizationof the relevant WESPEH application categoriesas follows:Intelligent buildings and homes - The most widespreadapplications of WEPSEH nowadays are in intelligent buildingsand homes. The precondition of these scenarios isthat all WESPEH devices are interoperable and are usingthe same wireless protocol. Usage of WESPEH saveswire installation costs in buildings and homes. Additionalbuilding equipped with WESPEH gives the possibility forfurther energy saving, by intelligent heating and air conditioncontrol, switching of unnecessary light sources, etc.Typical ambient powering possibilities are the following:light, mechanical, temperature difference. Applicationsexamples are: solar powered blind control, thermal poweredheating regulator, solar powered air ventilation.Safety critical applications - Using WESPEH varioussafety critical applications can be realized as in everydaylife also in disaster cases. The precondition of thesedevices is long lifetime and robustness. WESPEH usedin safety applications are equipped with various sensorinterfaces and with unidirectional communication interface.WESPEH in these scenarios are most of their life-

4 Strba, A.: Wireless Embedded Systems Powered by Energy Harvestingtime in an inactive power saving mode until an occurrenceof a critical event. The critical design aspect in these devicesis that during inactive mode the collection of maximumpower reserves has to be ensured. In case of a criticalevent occurrence the WESPEH wakes up and startsto transmit the sensor information periodically. The receiversare always line powered. In some scenarios theinformation transmission carries on until all the energyreserves of the device are exploited. For successful functionalitythe information has to be transmitted in realtime. Typical ambient powering possibilities are the following:light, vibrations. Applications examples are: solarpowered cooker extractor sensor, solar powered intelligentsmoke detector, solar powered geological rock fallguard, vibration powered tunnel disaster monitor.Health monitor applications - WESPEH can be usedeffectively in a health care. Many cables for vital monitoringattached to patients’ body causes a lot of discomfortin a hospital. The cables can be replaced bya WESPEH attached to the patient body that monitorsvarious vital function like temperature, blood pressure,pulse rate. Health monitor WESPEH application requiresfault safe functionality and real time reaction on criticalevents. Typical ambient powering possibilities are the following:breathing tension of the patient, thermal differencebetween human body and the surrounding, mechanicalper finger press, solar power. Application examplesare: temperature powered vital monitor, mechanical poweredemergency button.Wire replacement applications - WESPEH can be efficientused in applications where wire installation is verydifficult or even impossible. Modern cars have many sensorsthat are attached to the control unit of the car usingwires. The average wiring length in a modern caris around 2km. The lengthy wire installation raises therisk of a system malfunction as wires exposed longer toenvironmental effects can be damaged. Most of these sensorscould be replaced using WESPEH devices. Similaras in cars airplane wire installation is also a significantissue. As an example to reduce the costs of the installationWESPEH device can be used to replace blinds controlof the airplane window. Wire installations are alsoan issue in industry halls and productions. Mechanicaland solar power can be used effectively as ambient energysources. Position switches with an autonomous energygenerator are easily fitted in areas difficult of access andflexible when it comes to moving them elsewhere. Typicalambient powering possibilities are the following: thermaldifference, vibration, motion energy.2.5 WESPEH designThe WESPEH scenarios and use-cases are showing thatthe applications can be heterogeneous. For their successfulimplementation an appropriate design methodologyis required. Embedded system design is a very complexproblematic as the system consists of hardware and software.This brings the complexity to the design problematicsince the method of hardware and software design hasa significant difference. Hardware systems are designedas the composition of parallel components representedas analytical models. Software systems by contrast aredesigned from sequential components (objects, threads)represented by computation models [7]. For a successfuldesign, it is crucial to have good synchronization betweenhardware and software design steps. Failure to do so canlead to a hardware/software design gap problem.Several known design approaches try to solve these problemswith the help of model abstraction. Although thesemodels seem to offer a generic solution, they are often diametricallyopposed. A certain model can only be applicablefor a certain type of embedded system. This problemhas already been recognized by both the industrialand scientific communities and there are several ongoingresearch studies which are attempting to address theseproblems [9]. Other embedded system design approach isthrough critical system engineering. This approach triesto guarantee system safety at all costs, and is achievedmainly by using massive redundancy of resources. WE-SPEH can’t be characterized as critical systems and thesystem has limited energy resources for redundancy.Besteffortsystem engineering design approach tries to optimizesystem performance when the system operates underexpected conditions. Best-effort system engineering isbased on average case analysis and on dynamic resourceallocation. In case of a WESPEH system an average caseanalysis doesn’t resolve critical factors such as critical energystate.WESPEH devices are heterogeneous as the powering possibilitydictates the critical requirements on the system.This heterogeneity makes it difficult to follow a genericdesign model. Design process of WESPEH with similarfunctionality but different harvesting method may completelydiffer. There is a different proceeding for a systempowered by an electro dynamic converter where the mainemphasis is placed on the optimization of the energy generatoras for a solar powered device where the emphasisis concentrated on the long-term energy storage. We believethat best WESPEH design proceeding are practicalstraight-forward techniques.2.5.1 Design approachBased on several years of experience and observation ofWESPEH devices development we conclude that the mostsuccessful WESPEH projects were those where severalfunctional prototypes with hardware and software werebuilt and evaluated. Therefore we propose a straightforwarddesign technique based on prototype quantification.Prototyping of WESPEH devices has several advantages:• gives the opportunity to test various design options• helps to determine design flaws earlier• simplifies the energy budget estimation• verifies the product feasibility• gives the possibility for radio performance test• enables the definition of test in the early projectphaseIt is important that during the development lifecycle notonly one but several prototypes are built in parallel. Thismakes the evaluation easier and ensures to find most optimaltechnical solution.There are many different possibilities how to build relativefast working WESPEH prototype. On the otherhand just by prototyping is not guaranteed that the finalsystem will be feasible to become a product for massproduction. Lot of universities and research instituteshas succeeded in creating their own WESPEH prototypes.However, most of these projects remained in the research

Information Sciences and Technologies Bulletin of the ACM Slovakia, Vol. 4, No. 1 (2012) 1-13 5phase and were not realized as commercial products. Wesuggest that the explanation of this phenomenon lies ina common problem of underestimating the complexity ofWESPEH design problematic. The difficulty of the WE-SPEH design is given by the fact that there are usuallyopposing requirements placed on the device. In order tofulfill these requirements oft critical design constraints arebeing violated. As long as a device is developed as a prototype,design constraints like the number of components,component availability, form factor, radio performance,device lifetime, temperature dependency, production stability,aging of energy storage and price are disregarded.All these minor problems will turn to unsolvable issuesin the moment the device has to become a product readyfor mass production. To overcome these problems ourproposal is that prototypes have to be evaluated as thesubject of design constraint. Based on this knowledge wedefine a straight forward design approach that consist ofthe following steps:1. Requirement definition2. Design constraints definition3. Preliminary specification4. Prototype creation5. Prototype evaluation6. Prototype quantification7. Technical specification8. Product developmentAs the first step of the development the requirements onthe WESPEH device has to be settled down. An importantsecond step for a WESPEH development is to identifythe major design constraints. For a typical WESPEHsystem – based on the architecture and application scenariosin the previous chapter – we can identify five typicaldesign constraint groups:• Energy aspect• Radio platform• Microcontroller platform• Software aspect• Component aspect• Price aspectWith design constraints defined a preliminary specificationof various technical solutions is created. The specificationis preliminary as it is not yet clear which technologicalsolution will be the most suitable. In the followingdesign step functional prototypes - inclusive hardware andsoftware - are created with various technical solutions. Asthe next step each prototype is evaluated and comparedto the defined requirements. The sixth step includes thequantification of the prototypes as the subject of designconstraint. The prototypes are given a rate according theevaluation of the design constraint groups. The best ratedprototype is selected and a specification created. Finallythe product development is started which can follow anycommon design procedure.2.5.2 Prototypes quantificationIn order to determine which prototype has the best assumptionfor a successful design the prototypes has to bequantified. This is done in two steps:• prototype rating using decision matrix• constraint group equilibrium determinationThe prototype quantification process is the following. Thenumber of prototypes to evaluate is i, the number of constraintgroups are designated as j. Each evaluated prototypesconstraint group is assigned a rating value designatedas x ij. From this we can define the decision matrixas follows:⎛X ij =⎜⎝x 11 · · · x 1j⎞. · · ·.⎟⎠ , x ij ∈ {1, ..., 5} (1)where x ij is the prototype design constraint rate. 1 is thelowest rate and 5 is the highest rate. As the design constraintgroups can have different importance dependenton the application, each group is assigned a weightingfactor satisfying the condition that is:n∑w j = 1 (2)j=1where w j is the weight of the constraint. The prototypessummary rate designated as R i is calculated using theweighted average of the constraints in following way:n∑R i = w j x ij (3)j=1where w j is the weight of the constraint and x ij is therate of the prototype design constraint.2.5.3 Design constraint equilibriumDesign constraints place an overall boundary on the designprocess. All these parameters are tied together andfor a successful design, they must be properly balanced.Although prototype design with unbalanced constraintgroups may fulfill all the core requirements of the system,it is an indication that for long term the selectedchoice may lead to failure. We can demonstrate this facton example.Let’s consider a design of WESPEH solar window contact.The core requirement of the device is appropriateradio signal strength to cover an area of 300 meters. Theprototype design for this purpose requires energy for thetransmission with 6dBm signal strength. A solar cell withthe size of 5cm 2 could deliver the right amount of energybut the core requirement of unobtrusive hardware limitsthe size of the cell. The selected microcontroller powerrequirements are relative high (still in target range), butit has significant RAM, FLASH and I/O reserves. Onesolution to reach the design objective is to change thetype of microcontroller with lower power consumption.The microcontroller with lower power consumption hasless RAM, FLASH and no I/O reserves. Naturally microcontrolleris rated lower. Although the constraints ratingis not balanced, with the new microcontroller the powerconsumption is in the target range. The decision is madeto use this prototype for the final device design. As theproject enters its final phase integration test shows thatat high temperature the microcontroller A/D converteris not linear. This issue could be easily fixed using asoftware workaround with a conversion table. Unfortunatelythe new microcontroller has no FLASH reserves

Information Sciences and Technologies Bulletin of the ACM Slovakia, Vol. 4, No. 1 (2012) 1-13 9⎡⃗t =⎢⎣t RxBest +t RxW orst2t T xBest +t T xW orst2t schedOverheadW orst +t schedOverheadBest2t powerm1 W orst+t powerm1 Best2...t powermN W orst+t powermN Best2t peripheral1 W orst+t peripheral1 Best2...t peripheralN W rost + t peripheralN Best2An additional advantage of this method is that executionprofiles apart the time measurement can give additionaluseful statistical data like the percentage of code coverage,depth of stack usage, etc. We can use these datato get a better picture of the characterized primitive operation.The further advantage of this method is thatthe measurement focuses on the performance of the implementedcode and the latencies introduced by the HWare not considered in these measurements. By having thebest and worst execution time of the primitive the typicalexecution time of the primitive has to be determined.The typical execution time can be calculated using: arithmeticmean, harmonic mean, geometric mean, weightedharmonic mean. In paper the problematic of means arediscussed and the conclusion is made that after analyzingseveral hundreds of benchmark results the influenceof various mean is small. Based on this paper and on thefact that in our evaluation method the execution time isnot the only performance parameter, we can conclude thatthe selection of the mean algorithm doesn’t have a significantimpact on the result of our evaluation. Therefore forthe execution time calculation we will select algorithm ofthe arithmetic mean. Applying this method we can getthe characterization vector of WESPEH OS as showed inequation (6) where t is the time characterizing the primitiveexecution.4.2.2 Power consumption vectorThe way in which application and operating system utilizesthe underlying hardware has a significant impact onthe complete power dissipation of the system. Differentstudies in papers [14] [13] observed that the choice of algorithmand other high level programming decisions measurablyaffect the system power. The same effect can beobserved if the operating system manages the HW powerresources effectively. For example, a floating-point divisionoperation executed with active radio interface canconsume three times as much energy as executing thesame operation with inactive radio interface. All theseexamples indicate that for WESPEH OS evaluation thepower consumption parameter has to be considered.Several techniques exist to determine the software powerconsumptions. In the simulation-based approaches, theprocessor architectural model is used and the softwarepower consumption is estimated through simulation atdifferent abstraction levels [4]. This method offers highflexibility for experimenting, nevertheless, commercial microprocessors’circuit-level implementation is not available.Another common approach is to determine the instructionpower consumption and by combining this informationwith the SW analysis of the instruction level [8]⎤⎥⎦(6)the complete SW power consumption can be estimated.Using such a method does not cover the measurement ofdynamic power management of the SW where the CPUis entered into standby mode or unnecessary peripheralsare switched off in order to save power. The mostaccurate results can be obtained by measuring the physicalenergy consumption of the application executed onthe real HW platform. We can apply this measurementmethod by measuring the power consumption of each operatingsystem primitive operation. A special applicationcan be created that utilizes only one primitive operationin a loop with default parameters. During the implementationof these applications, we have to make sure thatthere is no other parallel task execution. We measurethe power consumption of the primitive as the function oftime. The measured values we get are summarized in apower consumption vector:⎡⃗p =⎢⎣p RadioRxp RadioT xp Schedulerp P owerm1.p P owermNp P eripheral1.p P eripheralNwhere p is the energy cost of the primitive in milliwattseconds[mWs]. One could argue that the power consumptionvector represents the HW blocks constant power consumptionand these values are HW dependent thus constantfor different WESPEH OS. In fact, this may be thecase if the analyzed OS primitive operation would notadjust the HW power modes during execution. An exampleof this scenario would be if the Radio Tx primitivewould immediately turn the radio Tx state machine onand would turn it off after the packet transmission wascompleted. In such case, the power consumption parameterwould equal to the radio Tx HW power consumption.On the other hand, in a WESPEH OS the SW tries toreduce the power consumption by applying different algorithm.For instance, the OS can put the system instandby while waiting for the radio Tx state machine tostart. Alternatively, the OS can switch on the Tx statemachine immediately before the packet transmission. Theways in which these algorithms are applied are operatingsystem specific and have an influence on the powerconsumption. Furthermore each primitive makes variousfunction and system calls to the OS. All these calls havea certain overhead dependent on the OS driver and interfacesimplementation. As the power consumption vectorincorporates these overhead latencies it gives more preciseinformation how efficient the OS implementation is.⎤⎥⎦(7)4.2.3 System matrixWe have defined a methodology where three vectors characterizethe WESPEH OS. The weakness of the currentmethodology is that it does not reflect the strategy of parallelprimitive operation execution. In all vectors, we considerthat the primitive operation’s execution happens ina consecutive manner and the actual primitive operationis the only running task in the operating system. Latenciesintroduced by scenarios where primitive operations

10 Strba, A.: Wireless Embedded Systems Powered by Energy Harvestingare blocking each other or where one awaits the output ofanother are not modeled in the current vector definition.The strategy of primitive operations’ execution significantlyinfluences the WESPEH OS evaluation resultwhereas it has a major influence on both execution timeand power consumption. We define a system matrix M ofdimension N x N where N is the number of primitive operationsin the system characterization vector. The systemmatrix models the strategy of primitive operationexecution by encoding parallel states of primitive operations.The rows and columns represent the primitiveoperations. The elements of the matrix represent the delayor enhancement factor of the parallel execution of twoprimitive operations. If all diagonal elements equals 1and other elements equal 0 we talk about sequential executionof tasks. The system matrix is always multipliedwith the system characterization vector. By the definitionof system matrix we should note that the matrix isboth application and operating system dependent. Thebehavior described in the system matrix depends on theapplication flow.A certain scheduler type can give a good performance witha certain application while the same type of scheduler canhave a bad performance with other application flow. Tomodel the whole system precisely the whole applicationflow with all combination of the application states wouldhave to be represented as different system matrixes. Thiswould make the model very complex, therefore for thesake of simplicity we will consider that each element ofthe system matrix models the average behavior of theapplication flow. The system matrix can be determinedby analyzing the operating system scheduler strategy andby analyzing the trace log of the current application.4.2.4 DefinitionBased on the discussion in previous chapters we can definethe performance of the WESPEH operating system.Definition 3. Let O = {o 1 , o 2 , ..., o n } be a WESPEHoperating system defined as a tuple of primitive operationsand o i, i ∈ {1, ..., n}is the primitive operation, let⃗s =⎛⎜⎝s o1. .s on⎞⎟⎠ =⎛⎜⎝t o1 best+t o1 worst2...t onbest +t o nworst2⎞⎟⎠ (8)be the system characterization vector dependent on theWESPEH OS where the component s oi is the arithmeticmean of the primitive operation execution time o i , i ∈{1, ..., n} expressed in milliseconds [ms].Let⃗p =⎛⎜⎝p o1. .p on⎞⎟⎠ (9)be the power consumption vector dependent on the WE-SPEH OS where the component p oi is the energy cost ofprimitive operation o i , i ∈ {1, ..., n} expressed in milliwatt-⎞seconds [mWs]. Let M ∈ R n×n⎛m 11 · · · m 1nm n1 · · · m nn⎜M = ⎝. · · ·.⎟⎠ (10)be the system matrix where m ij characterizes the parallelexecution of primitive operation o i and o j , i, j ∈ {1, ..., n}.The matrix is dependent on the WESPEH OS schedulerarchitecture and application execution trace. Let⃗a =⎛⎜⎝a o1. .a on⎞⎟⎠ (11)be the application vector where a oi is the call frequency ofthe primitive operation o i , i ∈ {1, ..., n}. Then we knowthat[( )]Π = a T s T M) T ⊗ p(12)is called the performance of the operating system composedof primitives operation o i , i ∈ {1, ..., n}. ⊗is the directproduct of the vectors. The triplet (Π, m ram , m rom )are the quantification parameters of the WESPEH operatingsystem. Using these parameters a certain applicationruntime on different WESPEH OS can be evaluated andcompared. To get precise and objective evaluation resultsthe measurement of the vector parameters has to be doneon the same HW.4.3 Experimental resultsWe have applied the methodology to compare theDolphinAPI and TinyOS. For the operating system evaluationwe have used a simplified version of a WESPEHheating regulator described in the heating automation scenario.The details of the measurement is described in thethesis.4.3.1 Applying the methodologyWith the data available the methodology can be appliedto determine on which OS the application behaves better.The first step of the evaluation is to determine the relevantOS primitives the application uses. From the applicationwe can derive the following primitive operations:O = {o radio rx , o radio tx , o standby , o uartT x , o analog }⎛⃗s DolphinAP I = ⎜⎝⎛⃗s T inyOS = ⎜⎝194912412586110000226710162763410000⎞⎟⎠⎞⎟⎠(13)The second step of the evaluation is the determination ofthe system characterization vector. For this vector theworst and best case execution time parameter of each

Information Sciences and Technologies Bulletin of the ACM Slovakia, Vol. 4, No. 1 (2012) 1-13 11Figure 4: Current flow of WESPEH running theapplication on DolphinAPIFigure 5: Current flow of WESPEH running theapplication on TinyOSprimitive is needed. As discussed in previous chapter thebest method to determine these values using an executionprofiler. We use the Keil simulator, debugger environment.With the help of the execution profiler the worstcase and best case execution time of primitive operationscan be determined. To have a precise result, we have createdvarious test cases that apply various loads on theprimitive functions. From these results, we can create thesystem characterization vector for both operating systemsas showen on 13.The following step of the quantification methodology is todetermine the application vector and system matrix. Thesampled data from the logic analyzer are analyzed andprocessed. Based on the trace log analysis and by knowingthe scheduler strategy we can create the system matrix ofboth operating systems. First we will determine all primitiveoperations’ parallel execution states. We create thesystem matrix by weighting the parallel execution states.Note that during the calculation if two primitive operationsrun parallel we consider in the matrix the primitiveoperation having the higher power consumption. This canbe interpreted by populating the row of the primitive operationwith the higher power consumption. For the sakeof simplicity, we consider fair CPU arbitration betweenparallel-executed primitive operations by populating matrixelements with 1/2 value. The behaviors of paralleltasks that may block each other caused by the cooperativescheduler in TinyOS are represented as an increaseof the element value by 1/2. We apply this value as anaddition to elements where this behavior can significantlyincrease the power consumption, in our case on the parallelexecution of Analog & UartTx and on RadioTx &UartTx. The result system matrixes are the following:⎡M DolphinAP I = ⎢⎣⎡M T inyOS = ⎢⎣0.1 0 0 0 00 0.05 0 0 00.05 0 0.05 0 00 0.05 0 0.13 0.050 0 0 0 0.050.09 0 0 0 00 0.145 0 0 00.045 0 0.05 0 00 0.045 0 0.095 0.080 0 0 0 0.045⎤⎥⎦⎤⎥⎦The application vector determination is in this simple scenariostraightforward as each primitive was executed exactly10 times.⎛⃗a = ⎜⎝1010101010⎞⎟⎠The power consumption vector determination is based onthe current measurement performed on the shunt-resistor.The current flow of both operating system is showed inFigure 4 and Figure 5.To get the energy consumption of the system the currentconsumption has to be integrated. The result of the integralis designated as a red line. For the methodologythe energy needs of the primitives has to be determined.This can be calculated the following way. The trace logtiming has to be synchronized with the energy measurementsto see in which moment which primitive operationwas executed. This way the time sequences of the primitiveoperations can be determined. Following step is tocalculate the integral of these time sequences. In such waywe get the energy consumption of the primitive which willbe the value for our power consumption vector. The redcircles in the diagram represent the time synchronizationpoints of the primitives.The final power consumption vectors derived from themeasurements for both operating systems are the following:⎛⃗p DolphinAP I = ⎜⎝⎛⃗p T inyOS = ⎜⎝0.13820.41960.01540.26120.14280.22370.66900.02160.28350.1982⎞⎟⎠⎞⎟⎠(14)

12 Strba, A.: Wireless Embedded Systems Powered by Energy HarvestingNow when all vectors are known we can perform the performancecalculation based on the equation . The performanceparameter results are the following:Π DolphinAP I = 1.782Π T inyOS = 2.799(15)Additional to these measurements we have performed analysisof the memory consumption. The details of theseanalysis can be found in the thesis.4.3.2 Results analysisFrom the results we can see that the application executedon DolphinAPI behaves better than on TinyOS. The applicationperformance running on DolphiAPI is around1.5x better than TinyOS. This result was already possibleto predict from the trace log and energy measurements.By comparing the current flow in diagrams shown in Figure4 and Figure 5 can be determined that the executiontime of the application in TinyOS took 28ms longer thanin DolphinAPI. This is an interesting fact, as when lookingat the system characterization vector (13) of both operatingsystems we can see that the vector values indicatesthat the execution duration of some primitives in TinyOSare faster than in DolphinAPI (radioRx or Standby). Thesystem characterization vector is created based on microbenchmarksimulation method. Therefore the scheduler,event processing overhead and other influences are notembedded in these values. This is the reason why standalonemicro-benchmark results can be misleading. Inour evaluation method the real application execution andthe whole system influences are embedded in the powerconsumption vector. Thus all these influences are visiblein the final evaluation.The major energy needs in a WESPEH has the radio receivinginterface. From the measurements the power consumptionvector (14) indicates that in both systems themost energy was consumed by the radio packet transmission.This is explained by the fact that the transmitter Aresponded on the packet very fast therefore the radio Rxinterface was active only a very short time. This provesthe fact that it is important to measure the system alwayswith the executed application. In a macro benchmarkwhere only the HW power consumption values would beconsidered, this fact would not be visible.Further measurement shows that the way TinyOS hascontrolled the power resources of the microcontroller wasnot as energy efficient as DolphinAPI did. The energy differencecan be explained with the operating systems architectureand scheduler difference. The scheduler in TinyOSis used more often as it is responsible for the managementof events and tasks. Therefore the scheduler overhead inTinyOS is more significant than in DolphinAPI. Everytime a new event occurs or a task is started or stoppedthe scheduler is invoked. In DolphinAPI the scheduleris invoked once in 1ms. As the tasks are constant andscheduling happens only on the system level no extraoverhead is represented. Further reason of the increasedpower requirements in TinyOS can be explained with thecooperative behavior of the scheduler. Cooperative tasksmay block the system for a certain time that may causethat turning off the radio interface can take longer asin DolphinAPI. Also the switch of microcontroller powermodes can be realized only in the moment when the applicationreceives the processor time.To prove our evaluation correctness and to indicate thisbottleneck we have performed additional micro- macrobenchmarkmeasurements. These measurement resultsare discussed in the thesis in detail. The results indicatethe cooperative scheduler as the major bottleneck ofTinyOS.4.3.3 Performance predictionWe have to note that the evaluation results tell how thecurrent application behaves on the operating system. Althoughwe have proven the fact that DolphinAPI radioprocessing is more optimized, the performance evaluationdoesn’t reveal if DolphinAPI in general is better thanTinyOS. Comparing operating system in generic manneris not an objective proceeding as it always comes to theapplication and the scenario where the operating systemis used. By changing the application implementation ormeasurements performed with different application couldgive a result where the TinyOS performance would bebetter.One of the biggest advantages of the suggested methodologyis that once all the vector values are known additionalperformance estimation can be performed without extrameasurement effort. By knowing the values of the systemcharacterization vector, power consumption vector andsystem matrix for both DolphinAPI and TinyOS we cancalculate and predict any application performance andcompare its runtime to the analyzed operating systemsby determining the application vector. For demonstrationpurpose let’s take the following example. We will considerthe same application scenario but with slightly modifiedexecution. The application will perform only four packettransmissions, and one reception. Furthermore there willbe an intensive UART communication where 30 packetswill be transferred to control the heating valve. In additiononly 5 analog measurements will be performed. Insuch case the application vector definition is the following:⎛⃗a = ⎜⎝415305⎞⎟⎠Applying the methodology on this modified applicationwe will get the following performance results:Π DolphinAP I = 1.418Π T inyOS = 1.310(16)The results indicate that TinyOS would behave slightlybetter as DolphinAPI with the described application. Themethodology makes it possible to predict how the optimizationof the operating system routines influences theoverall system performance.5. ConclusionThis work deals with the problematic of the design and developmentof wireless energy autonomous devices with thefocus placed on the software problematic. Based on observationand experience we claim that energy autonomoussystems cannot be treated as generic embedded systemsnor as conventional wireless sensor nodes. Hence a newdevice category called wireless embedded systems poweredby energy harvesting was introduced. The architectureof these devices was established and applicationscenarios were presented.

Information Sciences and Technologies Bulletin of the ACM Slovakia, Vol. 4, No. 1 (2012) 1-13 13We presented a design technique based on constraintsanalysis and prototype quantification. It is concludedthat for successful WESPEH implementation the designconstraints have to be in equilibrium. From the discusseddesign constraint group the work deals with the SW problematicin detail.The architecture and design aspects of a WESPEH OSis elaborated and defined. Based on these design aspectsthe successful implementation of a new WESPEH operatingsystem called DolphinAPI is presented. The initialimplementation of the operating system was done for theEO3000I HW platform. To prove the implementation feasibilityTinyOS is ported to the EO3000I platform andthe implementation of the EnOcean protocol stack is performedin NesC.We have introduced a new quantification methodology intendedto be used for WESPEH operating systems. Themethodology is based on vector definition and trace-drivenperformance analysis. The main contribution of the methodologyis that it can be used for prediction of applicationrunning on various WESPEH operating systems. Usingthe methodology we have performed measurements of anapplication running on DolphinAPI and TinyOS. The resultsshowed that the application running on DolphinAPIhad a slightly better score as running on TinyOS. Usingthe methodology the TinyOS performance bottleneckswere identified.5.1 ContributionsThe title of the work suggests that the objective of thiswork was to cover the whole problematic of Wireless EmbeddedSystems Powered by Energy Harvesting. As thisis a very wide topic, single research thesis can’t fulfill suchan advantageous aim. Still the title of the work was selectedintentionally. Despite the fact that the main focusin the work is placed on the software aspect, the primaryobjective was to raise the awareness of the research communityon the problematic of WESPEH.The work brings several new theoretical and practicalcontributions to the scientific community in the field ofapplied informatics by the definition WESPEH architecture,introducing application scenarios, definition of designmethodology and constraint group. Furthermore thework lays down the requirements and design aspects of operatingsystem designated to be used by WEPSEH. Thework also contributes the area of operating system evaluationby the introduction of a quantification method basedon vector definition and trace-driven performance analysis.Further on a significant contribution to the researchcommunity is the porting of TinyOS to a new hardwareplatform and by the implementation of the EnOcean radioprotocol stack.References[1] J. Bohn, V. Coroama, M. Langheinrich, F. Mattern, and M. Rohs.Social, economic, and ethical implications of ambient intelligenceand ubiquitous computing.http://www.vs.inf.ethz.ch/publ/papers/socialambient.pdf, 2004.institute for pervasive computing. In In. Springer-Verlag, 2004.[2] A. B. Brown. A decompositional approach to computer systemperformance evaluation, 1997.[3] J. B. Chen, Y. Endo, K. Chan, D. Mazières, A. Dias, M. Seltzer,and M. D. Smith. The measured performance of personalcomputer operating systems. ACM Trans. Comput. Syst., 14:3–40,February 1996.[4] R. Y. Chen, M. J. Irwin, and R. S. Bajwa. Architecture-levelpower estimation and design experiments. ACM Trans. Des.Autom. Electron. Syst., 6:50–66, January 2001.[5] D. D. Gajski and F. Vahid. Specification and design of embeddedsoftware/hardware systems. IEEE Design and Test of Computers,12:53–67, 1995.[6] T. Haenselmann. Gfdl wireless sensor network textbook.www.informatik.unimannheim.de/haensel/snbook.[Online; accessed 19-05-2011].[7] T. A. Henzinger and J. Sifakis. The embedded systems designchallenge. In Proceedings of the 14th International Symposium onFormal Methods (FM), Lecture Notes in Computer Science, pages1–15. Springer, 2006.[8] N. Kavvadias, P. Neofotistos, S. Nikolaidis, K. Kosmatopoulos,and T. Laopoulos. Measurements analysis of the software-relatedpower consumption of microprocessors. IEEE TRANSACTIONSON INSTRUMENTATION AND MEASUREMENT,53(4):1106–1112, 2004.[9] D. Lammers:. Embedded system design methodologies. http://www12.informatik.uni-erlangen.de/research/meat/.[Online; accessed 19-05-2011].[10] M. Leopold, M. Chang, and P. Bonnet. haracterizing moteperformance: A vector-based methodology. In Proc. of the 5thEuropean Workshop on Wireless Sensor Networks (EWSN).Springer-Verlag, Jan. 2008.[11] K. Romer and F. Mattern. The design space of wireless sensornetworks. Wireless Communications, IEEE, 11(6):54 – 61, dec.2004.[12] M. Seltzer, D. Krinsky, K. Smith, and X. Zhang. The case forapplication-specific benchmarking. In Hot Topics in OperatingSystems, 1999. Proceedings of the Seventh Workshop on, pages102 –107, 1999.[13] A. Sinha and A. Chandrakasan. Dynamic power management inwireless sensor networks. Design Test of Computers, IEEE,18(2):62 –74, mar/apr 2001.[14] V. Tiwari, S. Malik, A. Wolfe, and M.-C. Lee. Instruction levelpower analysis and optimization of software. In VLSI Design,1996. Proceedings., Ninth International Conference on, pages 326–328, jan 1996.[15] X. Zhang and M. Seltzer. Hbench:java: An application-specificbenchmarking framework for java virtual machines. In ACM JavaGrande, pages 62–70. ACM Press, 2000.Selected Papers by the AuthorA. Strba, T. Krajcovic. Operating System for Wireless EmbeddedSystems Powered by Energy Harvesters. In International JointConferences on Computer, Information, and Systems Sciences,and Engineering, December, 2010. Springer.A. Strba. Operating system design challenges for wireless embeddedsystems powered by energy harvesters. In Proceedings of the 7thInternational Symposium on Applied Machine Intelligence andInformatics, Kosice, Slovakia, January, 2009. IEEE Computersociety.A. Strba. Design and quantification approach of Wireless EmbeddedSystems powered by Energy Harvesters. In Proceedings of theHungarian PhD Conference 2008, Budapest, Hungary,November 10, 2008.A. Strba, T. Krajcovic. Software Design challenges for self-sustainingEmbedded Systems. In Proceedings of the IEEE InternationalConference on Applied Electronics 2008, Pilsen, Czech Republic,June, 2008.A. Strba, T. Krajcovic. Embedded Systems with Limited PowerSource. In Proceedings of the 9th International Conference onInformatics, Bratislava, Slovakia, 2007.A. Strba. Design Approach of Embedded Systems Gaining Powerfrom Energy Harvesting. In Proceedings in Informatics andInformation Technologies Student Research Conference ,Bratislava, Slovakia, April 18, 2007.