Wireless Embedded Systems Powered by Energy Harvesting

Transcription

1 SLOVAK UNIVERSITY OF TECHNOLOGY IN BRATISLAVA Faculty of Informatics and Information Technologies Attila ŠTRBA Wireless Embedded Systems Powered by Energy Harvesting Dissertation Thesis FIIT Supervisor: Assoc. Prof. Tibor Krajčovič May, 211

2

3 SLOVAK UNIVERSITY OF TECHNOLOGY IN BRATISLAVA Faculty of Informatics and Information Technologies Wireless Embedded Systems Powered by Energy Harvesting Dissertation Thesis FIIT Study Program: Applied Informatics Field of Study: Applied Informatics Institute of Applied Informatics Faculty of Informatics and Information Technologies Slovak University of Technology in Bratislava Supervisor: Assoc. Prof. Tibor Krajčovič Bratislava, 211 Attila ŠTRBA

4 Author: Supervisor: Reviewers: Attila ŠTRBA Assoc. Prof. Tibor Krajčovič (Slovak University of Technology in Bratislava) Prof. Jiří Šafařík (University of West Bohemia in Pilsen) Prof. Štefan Kozák (Slovak University of Technology in Bratislava) Keywords: wireless embedded systems powered by energy harvesting, energy harvesting, rapid prototyping, prototype rating, design technique, operating system design, operating system quantification, performance prediction ACM Subject Classification: D.4.7 [Operating Systems]:Organization and Design Real-time systems and embedded systems; C.3 [Special-Purpose and Application-Based Systems]: Real-time and embedded systems; D.4.8 [Operating Systems]:Performance Measurements, Modeling and prediction; D.2.8 [Software Engineering]:Metrics Product metrics; C.4 [Performance Of Systems]: Measurement techniques;

5 ANNOTATION This dissertation thesis deals with the challenges of designing and developing wireless embedded systems powered by energy harvesting, with the focus placed on the software challenges. The thesis is based on the assumption that energy harvesting is rapidly evolving and soon general purpose embedded systems will become energy-autonomous. The work raises awareness that generic embedded system and wireless sensor nodes are different from wireless embedded systems powered by energy harvesting, therefore a different design approach is required. Following this theory, the term wireless embedded system powered by energy harvesting (WESPEH) is defined and introduced. The work introduces a new design technique based on rapid prototyping and constraints analysis. From different groups of constraints, the software (SW) challenge is laid out in further detail with a focus on operating system design. Comprehensive analysis of thin-resource operating systems leads to the conclusion that existing systems are not designated to run on a dedicated WESPEH HW platform. Consequently, the requirements and design aspects of an energy-autonomous operating system are defined. Based on these definitions, a new operating system DolphinAPI is designed and implemented on the EO3I HW platform. This is the first operating system implemented on this HW platform. To demonstrate the suitability of DolphinAPI, for reference purposes the most popular wireless operating system, TinyOS, is migrated to the EO3I HW platform. As part of the migration the EnOcean protocol stack is implemented in NesC. Analysis of existing benchmark methods shows that common benchmark methods focus entirely on the computational performance, neglecting other important features of an operating system such as memory needs or influence on the energy consumption. Therefore a new operating system quantification methodology considering energy consumption, footprint size and scheduler behavior - is introduced. The methodology is based on vector definition and trace-driven performance analysis. Using the methodology, TinyOS and Dolphin API is evaluated and compared. To prove the correctness of the results, additional micro- and macro benchmarks are performed. The measurement results are compared to those calculated using the methodology.

6 SLOVENSKÁ TECHNICKÁ UNIVERZITA V BRATISLAVE Fakulta informatiky a informačných technológií Bezdrôtové vnorené systémy napájané zbieraním energie dizertačná práca FIIT Študijný program: Aplikovaná informatika Študijný odbor: Aplikovaná informatika Ústav aplikovanej informatiky Fakulta informatiky a informačných technológií Slovenská technická univerzita v Bratislave Školiteľ: Doc. Ing. Tibor Krajčovič, PhD. Bratislava, 211 Ing. Attila ŠTRBA

7 Autor: Školiteľ: Oponenti: Ing. Attila ŠTRBA Doc. Ing. Tibor Krajčovič, PhD. (Slovenská technická univerzita, Bratislava) prof. Ing. Jiří Šafařík, CSc. (Západočeská univerzita, Plzeň) prof. Ing. Štefan Kozák, CSc. (Slovenská technická univerzita, Bratislava) Kľúčové slová: bezdrôtové vnorené systémy napájané zbieraním energie, zbieranie energie, funkčný prototyp, hodnotenie prototypov, návrhová technika, návrh operačného systému, kvantifikácia operačného systému, prognóza výkonnosti ACM klasifikácia pojmov: D.4.7 [Operating Systems]:Organization and Design Real-time systems and embedded systems; C.3 [Special-Purpose and Application-Based Systems]: Real-time and embedded systems; D.4.8 [Operating Systems]:Performance Measurements, Modeling and prediction; D.2.8 [Software Engineering]:Metrics Product metrics; C.4 [Performance Of Systems]: Measurement techniques;

8 ANOTÁCIA Dizertačná práca sa zaoberá problematikou návrhu a vývoja bezdrôtových vnorených systémov napájaných zbieraním energie. Hlavný dôraz práce je kladený na softvérovú problematiku týchto zariadení. Práca je založená na predpoklade, že princípy zbieraní energie sa rýchlo vyvíjajú a onedlho sa vnorené systémy stanú energeticky sebestačnými. Práca poukazuje na problematiku, že generické vnorené systémy a bezdrôtové senzory sa značnou mierou odlišujú od bezdrôtových vnorených systémov napájaných zbieraním energie a preto je potrebný odlišný postup pri ich návrhu. Dôsledkom tohto pozorovania je potreba zadefinovania pojmu bezdrôtových vnorených systémov napájaných zbieraním energie (WESPEH). Práca zavádza novú návrhovú techniku založenú na analýze návrhových aspektov a vytvárania funkčných prototypov. Z rôznych skupín návrhových aspektov je podrobne rozoberaná problematika softvéru so zameraním na operačné systémy. Komplexná analýza operačných systémov vedie k záveru, že súčasné systémy nie sú vhodné pre bezdrôtové vnorené systémy napájané zbieraním energie. V rámci práce sú stanovené požiadavky a návrhové aspekty operačného systému pre energeticky autonómne zariadenia. Na základe týchto aspektov je navrhnutý a implementovaný nový operačný systém DolphinAPI. Operačný systém je implementovaný na hardvérovej platforme EO3I ako prvý operačný systém realizovaný na tejto hardvérovej platforme. Na preukázanie vhodnosti operačného systému DolphinAPI, bol TinyOS portovaný na hardvérovú platformu EO3I. Súčasťou portovania bola implementácia EnOcean rádio protokolu v NesC. Analýza benchmarkov poukazuje na fakt, že súčasné metódy hodnotenia výkonnosti operačných systémov kladú dôraz na výpočtovú rýchlosť a zanedbávajú ďalšie dôležité parametre ako nároky pamäte, vplyv na spotrebu energie. Z toho dôvodu je v rámci práce zadefinovaná nová metodológia kvantifikácie operačných systémov založená na definícii systémového a aplikačného vektora a na základe analýzy vykonávania programu. Metodológia zohľadňuje parametre ako spotreba energie, pamäte a spôsob paralelného vykonávania úloh. Navrhnutá metodológia je použitá na porovnanie a hodnotenie operačných systémov TinyOS a DolphinAPI. Na preukázanie správnosti výsledkov metodológie sú vykonané mikro- a makro benchmarkové merania na oboch operačných systémoch. Výsledky meraní sú porovnané s výsledkami metodológie.

9 ACKNOWLEDGMENT I would like to thank everyone who supported me in writing this thesis. Many thanks go to my supervisor Assoc. Prof. Tibor Krajčovič who assumed the role of supervisor. I would like to thank for his helpful advice. I am very grateful to Dr. Matthias Heiden, and Frank Schmidt, who supported me by giving very important feedback, advice and made it possible for me to organize my working hours with respect to my studies. I am also thankful to the whole EnOcean software team, especially to Jozef, Marian, Armin, Marcos and Tobias, for giving me valuable feedback and helping me a lot. Further thanks go to my colleagues Sven, Peter, Dirk, Heiko and Holger for their valuable technical advice. Finally, I would like to thank my wife Maria for her love, patience, encouragement and support given to me not only during my thesis work, but also in all aspects of my life. Without you, Maria, this work would be far from possible. I devote this work to our baby Picuri. A dedication goes to my parents for their care and support.

10 INDEX 1 INTRODUCTION MOTIVATION THESIS OBJECTIVES WORK STRUCTURE WIRELESS EMBEDDED SYSTEMS POWERED BY ENERGY HARVESTERS DISCUSSION WESPEH DEFINITION ENERGY HARVESTING Energy harvesters delivering periodical energy Photovoltaic energy harvesters Vibration energy harvesters Thermoelectric energy harvesters Energy harvesters delivering energy bursts Piezoelectric energy harvester Electrodynamic energy harvester Conclusion APPLICATIONS HW Platform EH-Link Energy Harvesting Wireless Sensor Node PTM2 - Push button transmitter GP5C EO3I Conclusion Application scenarios Intelligent buildings and homes Safety critical applications Health monitor applications Wire replacement applications DESIGN PROBLEMS WESPEH design WESPEH design approach Energy aspect Components aspect Radio platform Microcontroller platform Price aspect SW Aspect Prototypes quantification CONCLUSION OPERATING SYSTEM FOR WIRELESS EMBEDDED SYSTEMS POWERED BY ENERGY HARVESTERS WESPEH OS REQUIREMENTS Abstract the power management Scenario 1: Monitor power level Scenario 3: Storage capacitor control Scenario 2: MCU power management control Abstract wireless interface and implement wireless protocol stack Thin resourced Modular Hard real-time Parallel tasks execution Remote configuration Hardware abstraction EXISTING OS ANALYSIS x

11 3.2.1 Embedded Operating System FreeRTOS RTX Salvo Operating System for Wireless Sensors VROS Contiki Mantis SOS LiteOS Nano-RK TinyOS Conclusion OPERATING SYSTEM DESIGN FOR WESPEH Kernel Architecture Process Management Memory management File System Device drivers Radio protocol stack Peripheral interface Power management Programming language selection Conclusion WESPEH OS IMPLEMENTATION Compiler selection and implementation language C Source code energy saving techniques DolphinAPI Architecture Hardware Abstraction Layer (HAL) System Software Layer (ESSL) Conclusion PORTING TINYOS 2.X TO THE EO3I PLATFORM Tool chain adjustment Mangle script adjustments Porting modules to components io_mod timer_mod radio_mod power_mod uart_mod Conclusion CONCLUSION WESPEH OPERATING SYSTEM QUANTIFICATION MOTIVATION AND GOALS RELATED WORK Conclusion WESPEH OS QUANTIFICATION METHODOLOGY Definition of the methodology System characterization vector Application vector Power consumption vector System matrix Memory footprint Summary DOLPHINAPI AND TINYOS EVALUATION Application used for OS evaluation Measurement Setup Applying the methodology Results analysis Proof of TinyOS bottlenecks xi

12 Generalizing the evaluation results performance prediction CONCLUSION CONCLUSION CONTRIBUTIONS FUTURE WORK LIST OF PUBLICATIONS BIBLIOGRAPHY APPENDIX APPENDIX A APPENDIX B B.1 Solar cell measurements B.2 ECO1 Measurements APPENDIX C C.1 Operating system comparison APPENDIX D D.1 Quantification measurements xii

13 LIST OF FIGURES Figure 1 Moore s Law showing CPU transistor count increase Figure 2 Coca Cola vending machine and Pacemaker embedded system Figure 3 Architecture of WESPEH Figure 4 Wireless sensor node architecture Figure 5 Spectral distribution of light Figure 6 Power measurement of photovoltaic energy harvesters... 3 Figure 7 Power spectrum of PMG17 vibration energy harvester Figure 8 Power spectrum of JTRA-e5mini vibration energy harvester Figure 9 Finger heat powered sensor and LCD display Figure 1 Power measurement of thermoelectric energy harvester Figure 11 Thermoelectric energy harvesters, left TE-Power, right ECT Figure 12 Piezoelectric energy harvester voltage and current waveform Figure 13 ECO1 - electrodynamic energy harvester Figure 14 Voltage measurement of ECO Figure 15 Power measurement of electrodynamic energy harvesters Figure 16 EHK-Link module and applications Figure 17 PTM2 module and applications... 4 Figure 18 GP5C Block Diagram Figure 19 EO3I Block Diagram Figure 2 STM3XY modules and applications Figure 21 Example of bi-directional communication through a repeater Figure 22 WESPEH cell form deployment in a building Figure 23 Heating automation with WESPEH devices Figure 24 Intelligent office Figure 25 Example deployment of WESPEH for safety critical applications... 5 Figure 26 Prototypes of WESPEH for health monitor applications Figure 27 WESPEH tire pressure sensor prototype Figure 28 Temperature sensor energy flow Figure 29 Frequency bands for optimum WESPEH radio performance... 6 Figure 3 Equilibrium demonstration Figure 31 Quantification evaluations of three prototypes Figure 32 Layered hardware abstractions in TinyOS Figure 33 Architecture of embedded operating system [3] Figure 34 Timer driver implementation example Figure 35 WESPEH OS architecture Figure 36 Loop, indexing elements of an array Figure 37 Assembler listing of loop, indexing elements of an array Figure 38 Optimized loop execution with pointers... 1 Figure 39 Assembler listing of optimized loop execution... 1 Figure 4 Constant calculation after the loop... 1 Figure 41 Calculation of 16 bit variables Figure 42 Calculation of 16 bit variables using unions Figure 43 Assembler listing of calculation of 16 bit variables using unions Figure 44 Assembler listing of calculation of 16 bit variables using unions Figure 45 Timer period calculation function Figure 46 Timer period calculation using macro Figure 47 Switch case statement xiii

14 Figure 48 Assembler listing of switch case statement Figure 49 Optimized assembler listing of switch case statement Figure 5 Timer calibration optimization steps Figure 51 DolphinAPI architecture Figure 52 Data type redefinition Figure 53 Structure of the HAL layer Figure 54 UART passive driver structure Figure 55 DolphinAPI IO module configuration using DolphinStudio Figure 56 Universal telegram structure Figure 57 The original and the modified tool chain flow Figure 58 Keyword substitution process Figure 59 TinyOS architecture ported on the EO3I platform Figure 6 OS with cooperative scheduler Figure 61 Example task on OS with preemptive scheduler, time in ms Figure 62 State diagram of application used for OS evaluation Figure 63 Performance measurement setup schematics Figure 64 Shunt resistor Figure 65 OS evaluation measurement setup Figure 66 Test case application in TinyOS Figure 67 Current flow of WESPEH running the application on DolphinAPI Figure 68 Current flow of WESPEH running the application on DolphinAPI Figure 69 Energy consumption comparing DolphinAPI and TinyOS Figure 7 Current flow of a tasks running on TinyOS and DolphinAPI Figure 71 Telegram reception rate (1x subtelegrams) Figure 72 Telegram reception rate (1x subtelegram) Figure 73 Subtelegram processing latency Figure 74 Subtelegram spectrum of application running on DolphinAPI Figure 75 Subtelegram spectrum of application running on TinyOS xiv

15 LIST OF TABLES Table 1 Solar cell efficiency according the crystal type Table 2 Typical Indoor Illumination Levels Table 3 Vibration sources and their parameters Table 4 Summarization of energy sources and energy harvesters Table 5 Temperature sensor energy consumption calculation Table 6 Example of component aspect analysis Table 7 Summary of wireless standards Table 8 Decision matrix fo three prototypes... 7 Table 9 Resources of microcontroller used for WESPEH in application scenarios Table 1 Average resources of WESPEH microcontroller Table 11 Overview of embedded and wireless sensor operating systems Table 12 Frameworks for embedded systems Table 13 Description of asynchronous and synchronous system tasks Table 14 Summary of power modes Table 15 Typical Macro Benchmarks Table 16 Comparison of memory consumption of the application running on two OS. 143 Table 17 Power characteristic measurement of solar cells Table 18 Power characteristic measurement of ECO Table 19 RTX51 features and differences between Tiny and Full version [32] Table 2 DolphinAPI primitive operations measurements Table 21 TinyOS primitive operations measurements Table 22 Application trace-log running on DolphinAPI Table 23 Application trace-log running on TinyOS Table 24 Average execution time of DolphinAPI Table 25 Average execution time of TinyOS Table 26 Primitive parallel execution, DolphinAPI Table 27 Primitive parallel execution characteristic, TinyOS xv

16 LIST OF ACRONYMS A ASIC: Application-specific integrated circuit... 17, 41, 157 C CISC: Complex Instruction Set Computer D DPM: Dynamic Power Management , 156 E ERP: EnOcean Radio Protocol... 19, 11, 117 ESP: EnOcean Serial Protocol... 52, 11 F FMEA: Failure Mode and Effects Analysis H HAL: Hardware Abstraction Layer 15, 16, 17, 18 HW: Hardware 5, 17, 19, 39, 41, 7, 73, 74, 75, 78, 79, 8, 81, 82, 83, 84, 85, 86, 89, 9, 92, 93, 94, 95, 98, 15, 16, 18, 11, 111, 112, 113, 119, 12, 121, 122, 124, 126, 129, 134, 135, 14, 151 I IC: Integrated Circuit IPSO: Internet Protocol for Smart Objects ISM: Industrial, Scientific and Medical... 41, 61 M MCU: Microcontroller Unit... 42, 63, 64, 65, 7, 14 O OSI: Open System Interconnection model... 62, 75, 92 P PAS: Polyacenic Semiconductor PLL: Phase-locked loop... 93, 18 R RF: Radio Frequency 17, 22, 25, 38, 39, 4, 41, 42, 46, 63, 65, 18, 137 RISC: Reduced Instruction Set Computer S SMA: SubMiniature version A SW: Software. 5, 17, 18, 19, 21, 24, 56, 66, 7, 72, 73, 91, 94, 14, 18, 111, 12, 129, 13, 15, 152 U UART: Universal Asynchronous Receiver Transmitter...17, 111, 115, 136, 138, 14, 145, 148, 171, 176 W WESPEH: Wireless Embedded Systems Powered by Energy Harvesting.. 5, 8, 18, 19, 2, 21, 24, 25, 27, 29, 3, 32, 34, 35, 36, 38, 39, 44, 45, 46, 47, 48, 49, 5, 51, 52, 53, 54, 55, 56, 57, 58, 59, 6, 61, 62, 63, 65, 66, 67, 68, 69, 72, 73, 75, 77, 78, 79, 8, 81, 82, 83, 84, 85, 86, 87, 88, 89, 9, 91, 92, 94, 95, 97, 98, 112, 113, 119, 12, 122, 123, 124, 125, 126, 127, 129, 13, 133, 134, 135, 149, 15, 151, 152 WSN: Wireless Sensor Networks... 21, 45, 81 X XTAL: Crystal Oscillator... 93, 112 xvi

17 1 Introduction 17 1 INTRODUCTION To fulfill the vision of ambient intelligence, the design of small wireless embedded systems powered by energy harvesting is needed. Classical embedded systems have two common powering possibilities. They are either line or battery powered. Neither of these solutions is flexible enough for wireless sensors/actuator or wireless smart intelligent devices implementation. Ambient intelligence requires that devices integrated into the environment are self-sustaining and maintenance free. Consequently, the only powering possibility available to them is to gain energy from the environment with the help of energy harvesting. Design and implementation of such devices is challenging work. Conventional design techniques are insufficient for these highly constrained energy systems. Consequently, wireless embedded systems powered by energy harvesting cannot be treated as generic purpose embedded systems. They also differ from conventional wireless sensor nodes. Furthermore, the limited resources of these systems make the usage of general purpose embedded and wireless sensor operating systems inappropriate. Generic embedded operating systems have no embedded radio stack support and their architecture is too complex to run on a system powered by an energy harvester. Wireless sensor operating systems are usually thinly resourced. In contrast, their feature set focuses on the challenges of network architecture, remote configuration and remote firmware updates. Wireless energy autonomous devices require an operating system that is designed to run on systems powered by an energy harvester, effectively utilize the HW power management resources and has the embedded support of an energy optimized radio protocol stack. The aim of the thesis is to find a solution for these issues. 1.1 Motivation The dissertation thesis was written during a five-year project called Dolphin (started in 24) in collaboration between two industrial partners. The aim of this project was to build a wireless hardware platform based on an ASIC for energy autonomous applications powered by energy harvesting. Several teams worked together on this project. The primary task of my team was to create a software platform that enables easy development of wireless ultra low power application powered by energy harvesters. Our secondary task was to support the RF and test development team with SW tools for the evaluation. During the Dolphin project development I was facing challenges where design trade-offs had to be made due to various constraints such as energy, the number of components, radio performance and price. Since the project had a tight schedule, there was no time for comprehensive research of these challenging aspects. In my experience, following common embedded system design approaches does not offer guidance about the problems we were encountering. I was aware of the fact that the design issues we were facing fall neither under the category of embedded systems nor under the category of wireless sensor nodes. I felt there is a gap in the current understanding of energy autonomous wireless devices and this gap needs to be filled. This gave me the motivation to start my scientific research parallel to the Dolphin project at the Slovak University of Technology in Bratislava supervised by Assoc. Prof. Krajčovič. Based on the practical experiences gained from the Dolphin project, I targeted

18 1 Introduction 18 my research towards various challenging aspects dealing with the design issues of wireless energy autonomous systems, with the focus placed on software. In my research I used several results from the Dolphin project. Since those results were created in a team, I would now like to clearly state what have I used from the Dolphin project which was developed by my team members, which part of the results in this thesis where developed by me during the Dolphin project and which results in this thesis where developed by me during my scientific research: The definition of Wireless Embedded Systems Powered by Energy Harvesting (WESPEH), an overview of energy harvesters, analysis of design constraints, definition of design techniques, analysis of existing operating systems, operating systems requirements and design approach definition result from my research. In order to understand the energy challenges and to apply them to the SW problem and performance evaluation, I have performed various measurements with solar cells and electrodynamic energy harvesters. These measurements were performed during my research. My colleagues provided me the necessary HW and assisted me building up the energy measurements setups. The idea of an operating system for wireless embedded systems powered by energy harvesters, the architecture, design, and initial implementation of DolphinAPI on the EO3I platform was what occupied me during the Dolphin project. As the project got more complex, two more SW engineers took over the implementation from me. I continued to be responsible for the design and project coordination. I used DolphinStudio for the configuration of the applications in my benchmarking scenarios during my research. The design of DolphinStudio was the result of team work with my colleague during the Dolphin Project. The implementation was done by my colleague. The initial TinyOS source code was taken from the TinyOS851 working group. The porting of TinyOS to the EO3I chip, the implementation of the EnOcean protocol stack in NesC, the creation of TCM3 platform in TinyOS, the applications and the adjustment of the tool chain result from my research. For the porting I used pieces of source code of the EnOcean radio protocol stack from DolphinAPI that was implemented by my team members. I have rewritten these codes in NesC and adjusted the modules for the architecture of TinyOS. The operating system quantification methodology, mathematical analysis, application implementation, measurement HW setup, performance measurements, is a result of my research. For the characterization vector determination, I have used the whitebox simulation framework that was created by my colleague and me during the Dolphin project. Most of the whitebox test scripts were implemented mainly by my colleague during the Dolphin Project. Transforming the test source code to TinyOS is a result of my research. Although my scientific research was done parallel to the Dolphin project and some results were used from the project, hereby I declare that this thesis is purely my individual work and my own intellectual property. Additional, I have to note that the

19 1 Introduction 19 Dolphin project was driven by commercial requirements and it had several hard requirements relating to performance, functionality, stability and price. I have to admit that these factors strongly influenced my research proceedings and design choices. 1.2 Thesis Objectives The aim of this research is to examine various challenging aspects of energy autonomous wireless devices and to propose solutions. The thesis goals and major contribution to the scientific community in the field of applied informatics can be summarized in three categories: Introduction of the device category wireless embedded systems powered by energy harvesting; architecture, application scenarios, powering possibilities and a new design approach definition. With the definition of a new device category, the thesis tries to raise awareness in the research community that these types of devices need different design approaches than classical embedded systems or wireless sensor networks. Furthermore, the thesis should be a starting point for other research works in order to find solutions for the described challenges. Description of the software challenges inherent in energy-autonomous wireless devices. Including the requirements, architecture, design and implementation aspect definition of an operating system for energy autonomous devices. Furthermore, the research community will benefit from the implementation of a new operating system, and by the porting of TinyOS to a new hardware platform, including the EnOcean radio protocol stack. The third contribution will be to embedded operating system evaluations, since the thesis will attempt to introduce a new quantification methodology. Based on this methodology the performance of ultra low power operating systems could be evaluated and predicted with a dedicated application. 1.3 Work structure The thesis is structured into three parts. The first part of the thesis deals with the definition of wireless embedded systems powered by energy harvesting. Several powering possibilities using energy harvesters are presented and the amount of available power is analyzed. WESPEH HW platforms and application scenarios are introduced and design approaches and problems are discussed. A new design technique with constraints analysis and prototype quantification is introduced. The second part of the thesis deals with the operating system design for wireless energy autonomous devices. A comprehensive analysis of thin resource operating systems is presented and it is explained why the existing systems are not feasible for WESPEH HW. Various WESPEH OS design problems and SW techniques for power consumption reduction are discussed and solutions proposed. Design and implementation of a new WESPEH OS called DolphinAPI is presented. The last part of the chapter describes the porting of TinyOS 2.x to the EO3I HW platform and the implementation of EnOcean radio protocol stack in NesC. The last part of the thesis deals with the operating system quantification. Several OS performance evaluations are discussed and analyzed to determine if they are adequate for

20 1 Introduction 2 WESPEH OS evaluation. A new OS quantification methodology based on vector definition and trace-driven performance analysis is introduced. Using the methodology, TinyOS and Dolphin API are evaluated and compared running a dedicated application. To prove the correctness of the results, additional micro- and macro benchmark measurements are performed on both operating systems and the results are presented.

21 2 Wireless Embedded Systems Powered by Energy Harvesters 21 2 WIRELESS EMBEDDED SYSTEMS POWERED BY ENERGY HARVESTERS This chapter introduces the term Wireless Embedded System Powered by Energy Harvesting (WESPEH). It is explained why there is a need for a new device category. The architecture and properties of WESPEH are described and compared to the generic embedded systems and wireless sensors. The chapter gives an overview of energy harvesting powering possibilities and shows how much power can be transformed from various ambient energy sources. The second part of the chapter deals with the design challenges of WESPEH devices and introduces a new design technique based on constraint group analysis and prototype quantification. 2.1 Discussion The following chapter builds up some background for the definition of wireless embedded systems powered by energy harvesters. The aim of this chapter is to introduce ambient intelligence and to explain to the reader by going through the evolution of embedded systems why there is a need to define a new device category. It was 62 years ago when the first computer ENIAC with the size of 63m 2 and weight of 27 tons executed the first man-written program at 1kHz clock speed in Fourteen years later, in 1963, the Apollo Guidance Computer with the size of 61x32cm and weight of 32 kg at 512 khz CPU clock speed controlled the landing on the moon and the successful return of the Apollo 11 crew to the earth. The Apollo Guidance Computer is recognized as the first embedded system and it opened the era of embedded technologies. Two years later, in 1965, Gordon E. Moore [8] describes a trend of doubling the power of microprocessors every 18 months. The tendency of miniaturization predicted by Moore s Law has held true with astonishing accuracy and consistency as shown in Figure 1. This trend made it possible for the embedded systems to become smaller, with lower power needs, but at the same time maintain the increasing computing performance. Thirty-five years after the Apollo landing in 1998 as part of the Smart dust project, the world s first smallest one cubic millimeter sized autonomous wireless sensor node was created. This transformed the concept of embedded systems and set down the basics of wireless sensor networks (WSN). Wireless sensor networks were separated from embedded systems and became a new device category with their own architecture, design problematic and SW solutions. Moore s Law did not reach its limits at the end of 2 th century and the trend of miniaturization and increases in performance continues into the 21 st century. In 29, IBM announced the usage of a 32nm technique to print circuits [9] and for a moment, it seemed that Moore s Law would come to an end. A few months later, Kelin J. Kuhn in her paper [16] indicated that 32nm is not the final barrier and that the trend of transistor scaling and performance increasing will continue for several further chip generations. Looking back over the last 4 years of development, we can conclude that Moore s law is a trend that may carry on for further decades. Even if the technological limit of transistor size is reached, the trend of performance increases and miniaturization will continue using other new technologies. The proof for this statement is the research on threedimensional transistor design performed by Intel [172] or the research of memristors currently being conducted by the company HP and Hynix, which is expected to become available in the year 213 [17].

22 2 Wireless Embedded Systems Powered by Energy Harvesters 22 Figure 1 Moore s Law showing CPU transistor count increase Rapid miniaturization and performance increases of the integrated circuit leads to the development of tiny embedded systems integrated more and more into our everyday objects and will create a world of smart devices surrounding us. The Information Society and Technology Advisory Group in 1999 defined a concept of future computing called ambient intelligence [143][144]. This concept is based on the fact that technological progress in the microelectronics makes the increasing miniaturization of embedded systems possible. The ambient intelligence concept expects that the miniaturization trend will soon lead to the development of tiny wireless smart embedded devices, integrated more and more into our everyday objects. In a world of ambient intelligence, parents will no longer lose track of their children, when location sensors and communication modules are sewn into their clothes. Similar devices attached to timetables and signposts could guide blind or foreign people in unknown environment by talking to them [1]. People would live in intelligent homes equipped with window handles that can regulate heating, with refrigerators that can detect old food or with washing machines that can examine dirty clothes for washing instructions. What in the year of 1999 seemed to be a vision ten years later is starting to become a reality, as indicated by the formation of IPSO Alliance (Internet Protocol For Smart Object) and by the introduction of 6LoWPAN standard. Furthermore, to fulfill the vision of ambient intelligence requires that there are several small-embedded devices integrated in the environment. Each of these devices requires some source of powering possibility and communication interface. While power can be transported with the help of cables or devices could be powered by batteries, neither of these possibilities offers an effective and long-term solution. Embedded systems will fulfill the ambient intelligence concept only if they are self-sustaining and maintenance free. Such a requirement can be achieved only if these devices have a wireless communication interface and are powered from the environment using energy harvesting. Energy harvesting creates the possibility to use the omnipresent energy sources from our surroundings such as, 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, a temperature difference of 12K or just 5 lux of light generates enough energy to power a module equipped with a microcontroller and a RF-transmitter and to transmit a wireless signal. Using energy harvesters in embedded devices is not a novel invention. In the late 198s several calculators were equipped by solar panels and powered by light. However, the real power of energy harvesting integration in consumer electronics is just being discovered. Big

23 2 Wireless Embedded Systems Powered by Energy Harvesters 23 companies recently have started to introduce energy harvesters in their products. For instance, Nokia in its latest development has announced an idea to capture the energy generated by the phone s movements using a piezoelectric energy harvester and to power cell phone batteries with this energy [78][79]. Introducing energy harvesting in consumer products means that the philosophy of battery utilization will change in the near future. Probably the main purpose of the future batteries will be to store energy gained from the environment. If we observe those emerging trends in embedded systems - miniaturization, wireless interface, energy harvesting questions may arise as to whether embedded systems as we know them nowadays are able to cover the requirements of ambient intelligence. To be able to answer these questions let us briefly discuss the term embedded system. Understanding the term embedded is helpful for understanding what application scenarios embedded systems cover. Embedding means to enclose or implant as essential or characteristic. The exact definition of an embedded system, according D. Gajski [7], is as follows: From the viewpoint of computing systems, an embedded system is a special-purpose system in which a computer is entirely encapsulated by the gadget it controls. Unlike a general-purpose computer, an embedded system performs predefined tasks, usually with very specific requirements and constraints. Such a definition is outdated. The target of embedded systems has been transformed in the last ten years. Most of the embedded systems of the 21 st century perform a 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 has completely changed from the origin. It is also used as a multifunctional device for taking photographs, browsing the internet, and much more. An anecdote from Bjarne Stroustrup [75] provides a very good description of this status quo: I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Figure 2 Coca Cola vending machine and Pacemaker embedded system A common element in the definition of embedded systems is that they cover a wide variety of applications with vastly varying requirements. Consequently we cannot speak anymore about generic design methodologies, application requirements and research

24 2 Wireless Embedded Systems Powered by Energy Harvesters 24 challenges in terms of embedded systems. Let us demonstrate this fact with the following example (Figure 2). The term embedded system refers to a line powered Coca Cola vending machine [74] with TCP/IP networking capabilities, running Windows CE on a 4MHz processor and several MB of RAM. At the same time, a pacemaker [73] device is also categorized as an embedded system powered by lithium iodine battery running a proprietary SW on an 8MHz processor with 48kB flash and 1kB RAM. Despite the fact that both the systems comply with the definition embedded system, the design approach and requirements of these two systems are contradictory. 2.2 WESPEH definition The previous discussion leads us to the conclusion that categorizing ambient intelligence devices as embedded systems is not a good solution. There is a gap in the current understanding of these devices. This gap needs to be filled. Ambient intelligence devices need specific state-of-the-art design methodologies and solutions. In order for the vision of ambient intelligence to be fulfilled, a new category of devices needs to be introduced. Paper [1] discusses the vision of ambient intelligence in detail. Based on this paper we can derive the requirements of devices fulfilling ambient intelligence, they: are powered from the environment with the help of energy harvesting. are maintenance-free. have a wireless communication interface. have a sensor/actuator interface. can interact with real-time events. have unobtrusive hardware. From the requirements, we can derive the name of this device category as following Wireless Embedded Systems Powered by Energy Harvesters (WESPEH). An analogous term Energy Harvesting Wireless Embedded System was already used in paper [147] published in 25. Ambient Energy: Motion, Vibration, Temperature, Light, etc. WESPEH Energy Conversion Energy Management (Energy store, threshold monitor, sleep timer) Micro - controller Sensors RF Transceiver / Tramsitter Actuator Peripherals: Digital, analogue, etc. Sensor: Temperature, pressure, position, presence, etc. Figure 3 Architecture of WESPEH Although the term is very similar to the definition introduced in this thesis, no significant overlap of that paper to this thesis topic can be determined. In this thesis, we are

25 2 Wireless Embedded Systems Powered by Energy Harvesters 25 introducing a new device category inclusive requirements and architecture definition, use cases and design methodology. The paper doesn t cover the problematic of WESPEH in general. The mentioned paper discusses one application design of a solar powered wireless embedded system. The architecture of a WESPEH is shown in Figure 3. The device consists of an energy conversion unit that is the energy harvester itself. This unit converts the ambient energy to electrical energy. The energy management block stores the electrical energy to a storage capacitor. In addition, the energy management unit is responsible for converting the voltage using a step down or step up converter to a lower or higher value. Using this method, the capacitor can be loaded more effectively. For further functions, the energy management block provides ultra low sleep timers to control the CPU and a voltage threshold detector. The microcontroller communicates using the RF interface and interacts with the environment using sensor or actuator interfaces. From the above description, we can formulate the following definition of WESPEH. Definition 2.1: Wireless Embedded System Powered by Energy Harvester - designated as WESPEH - is a standalone; maintenance-free special-purpose computing system powered by ambient energy; equipped with an uni- or bidirectional wireless communication interface; capable of hard or soft real-time interaction with the environment using sensor and actuator interfaces. Considering WESPEH device architecture (Figure 3) and comparing it to a wireless sensor node (Figure 4), we can see several similarities. A question may arise if wireless sensor node corresponds to a wireless embedded system. To answer this question there is a need to understand the difference between wireless embedded systems powered by energy harvesters and wireless sensor networks. According Thomas Haenselmann [76] the wireless sensor network is defined as following: A sensor network is a set of small autonomous systems, called sensor nodes which cooperate to solve at least one common application. Their tasks include some kind of perception of physical parameters. One of the main aspects in which embedded systems and wireless sensor networks differ is that embedded systems are designed to work standalone. Wireless sensor network (WSN) devices core design space is the network infrastructure [173]. The target application of wireless sensor network is to build a large-scale ad-hoc, multi-hop infrastructure composed of several thousands of nodes. A standalone wireless sensor node has no relevant functionality. Another aspect in which embedded systems and wireless sensor networks differ is the purpose for which they use their communication interface. The embedded system wireless interface's purpose is to enable the human to access information or trigger action. The sensor node wireless interface's primary focus is to interact with other nodes. In the case of the wireless sensor node, the bidirectional wireless communication interface is obligatory, while WESPEH may use unidirectional communication interfaces like in the applications described in Wireless sensor

26 2 Wireless Embedded Systems Powered by Energy Harvesters 26 nodes differ from WESPEH devices also in having only sensing interfaces. WESPEH can be equipped also with an actuator as described in the application scenarios. The last major difference between WESPEH and WSN is the powering option. While in certain wireless sensor network scenarios battery is an acceptable option WESPEH must be maintenance-free, and energy autonomous. Figure 4 Wireless sensor node architecture Part of the wireless sensor network has a lot in common with wireless embedded systems powered by energy harvesting. Especially in applications where WESPEH devices have a sensing role. Still the design problematic of wireless sensor networks does not fully covers the problematic of WESPEH. WESPEH has to be handled as a separate device category.

27 2 Wireless Embedded Systems Powered by Energy Harvesters Energy harvesting This chapter deals with the powering possibility of WESPEH using ambient energy sources from the environment. The reason why we deal with energy harvesting in more detail is because understanding the power challenges of WESPEH is a key objective to understanding the device and software design decisions discussed in later chapters. Energy harvesters make it possible to capture and to transform environmental energy to electrical energy. Energy harvesting from natural sources has been known and used for decades. Water power plants and wind power plants were already used at the beginning of the 2th century. We refer to this type of harvesting as a macro-scale energy harvesting. Micro-scale energy harvesting has become available only recently. Technological progress made it possible to build energy harvesters at a size small enough to fit in an unobtrusive embedded system and at the same time deliver enough energy to power the whole system. The aim of this chapter is to give a brief overview of micro-scale energy harvesters that are appropriate to power a WESPEH device. Focus is placed on the type of energy source, harvesting efficiency and amount of electrical energy. For some types of energy harvesters measurements were performed to show the average power output Energy harvesters delivering periodical energy We can divide energy harvesters into two groups. The first group of converters can power a system seamlessly and continuously for a longer period of time. In such a scenario, the time for completing the tasks is not as critical as for energy harvesters delivering short energy bursts. The concept of efficient energy management in such systems is to switch on the circuit for a short time and as infrequently as the application allows. For the rest of the time, the circuit is idle in a sleep mode with very low power consumption. Systems powered by periodical energy sources have typically two types of energy storage: a short- and a long-term one. The short-term energy storage is loaded by the energy harvester very quickly, thus enabling the system to have a very quick startup. After the system completes its designated task, it enters an ultra low power consumption mode. One of these ultra low power operation modes is the charge control. During this phase, the energy harvester first recharges the short term store with a sufficient load for the next task. As soon as this charge is completed, all surplus energy loads into the longterm energy storage. Every time the system wakes up it is directly powered by the recharged short-term energy storage. When no energy is available from the energy harvester, the long-term energy storage transfers energy into the short-term storage. Harvesters delivering periodical energy are photovoltaic energy harvesters, thermo converters, vibration converters and dynamos Photovoltaic energy harvesters Solar cells can convert solar energy into electricity employing the photovoltaic effect. The photovoltaic effect generates a voltage in a non-homogeneous semiconductor, such as silicon, or at a junction between two types of material and by the absorption of light or

28 2 Wireless Embedded Systems Powered by Energy Harvesters 28 other electromagnetic radiation [18]. Level of efficiency in % Monocrystalline Silicon Approx. 24% Polycrystalline Silicon Approx. 18% Amorphous Silicon Approx. 13% Table 1 Solar cell efficiency according the crystal type We can characterize three types of solar cells according to the type of crystal they are built of: monocrystalline, polycrystalline and amorphous silicon. The production of a monocrystalline silicon solar cell requires pure semiconducting material. Therefore, monocrystalline solar cells are very efficient but also are the most expensive ones. Polycrystalline solar cells are produced by pouring melted silicon in a mould where it is cooled and then sliced into wafers. This process results in cells that are significantly cheaper to produce, but whose efficiency is limited to less than 18%, due to internal resistance at the boundaries of the silicon crystals. The cheapest, but also the least efficient solar cell types, are the amorphous crystal-based, also called thin-layer solar cells. The production process of these cells consists of putting a 1µm silicon film on glass or another substrate material. Since amorphous silicon cells have no crystal structure at all, their efficiencies are presently only about 1% due to significant internal energy losses [111][113]. The summary of solar cell efficiency dependent of the crystal material is shown in Table 1. Illumination [lux] Home 1 5 Classroom in general 3-75 Office workspace 2-5 Canteen, restaurant 15-3 Factory production hall 5-15 Hospitals 3-15 Hotels reception 3 7 Stores 3 15 Indoor sports arena 2-5 Table 2 Typical Indoor Illumination Levels Solar cells conversion efficiency depends not only on the silicon material and production technology, but also on the light-wavelength, -temperature and -intensity. For outdoor solar cells, the best light source is daylight, while fluorescent lamps that have a cold light represent the worst case lighting condition. Typical illumination levels are shown in Table 2. Indoor solar cells can work effectively in low light environments of 1 5 lux. On the other hand, this solar cell lifetime is reduced if they are exposed to high intensity light or direct sunshine. Solar cells can produce approximately 1 mw of average power from a 1 cm 2 photovoltaic cell exposed to a typical daylight intensity of 1 Lux. The power delivery of the solar cell is also dependent on the number of cells the unit has [11]. To understand the correlation between the amount of energy, solar cell size and light

29 2 Wireless Embedded Systems Powered by Energy Harvesters 29 intensity, measurements with various solar cells were made. For the measurement target, thin layer solar cells with amorphous silicon crystal were selected. Although these solar cells are not very efficient for outdoor use, they are acceptable in terms of costs for WESPEH design and are appropriate for indoor use. We will base our measurements on the observation that the amorphous silicon solar cell spectral sensitivity approximately covers the visible-light spectrum that is detectable by a Lux meter, as shown in Figure 5. The first diagram shows the spectral sensitivity distribution of different types of solar cells. The second diagram shows the light wavelength and relative spectral sensitivity of different light sources. Consequently, it is possible to make an analogy between the Lux meter sensitivity and the electrical energy the solar cell delivers. A calibrated white LED array was used for the measurements. Due to the regulation of the LED array current, the light intensity changes, but the spectrum of the light source stays the same. Figure 5 Spectral distribution of light The measurement was performed by placing the solar cell and a lux meter in a black box. Through a 5x5 cm opening, the LED array was pointed at the solar cell and lux meter. The solar cell was connected to a 1kΩ resistor. The resistor simulates the load, thus converting the open circuit voltage (V oc ) to the operating voltage (V op ). The value of the resistor is dependent on the tested solar array. In our measurement, the operating voltage and operating current were measured. By regulating the light intensity of the LED array, the power characteristics of the solar cell was measured.

30 2 Wireless Embedded Systems Powered by Energy Harvesters 3,25,2 Power [mw],15,1,5, sinonar ss-6782-a sinonar ss-5516 sanyo am Illuminance [Lux] Figure 6 Power measurement of photovoltaic energy harvesters The result of the measurements can be found in 8B.1. Diagram created from the values is showed in Figure 6. The increasing open circuit voltage has a logarithmical behavior. The photo short circuit current is nearly linear with the illumination. Therefore the operational voltage is always lower than the diode threshold. This leads to the fact that the operational power is not ideal but rather linear to the brightness. Ideal solar energy harvesters for WESPEH systems are lower cost solar cells with amorphous silicon technology. The efficiency of this technology is only around 13%. However, at low levels of illuminance of 1 to 5 lux, that is typical for indoor use. These solar cells are considerably more affordable than highly optimized expensive monocrystalline cells. Solar power is one of the most common energy harvesting possibilities for WESPEH as there are many types of solar cells commercially available with different sizes, levels of efficiency. In addition, photovoltaic energy is available nearly everywhere Vibration energy harvesters Vibration energy harvesters convert mechanical motion to electricity. Suitable vibrations can be found in several applications including household appliances such as fridges, washing machines, microwave ovens; in industrial environments; in moving vehicles and in structures such as buildings and bridges. Some research shows that even raised floors and dropped ceilings in most office buildings provide measurable vibrations from vehicles driving down nearby streets or from people walking on the upper floors [127]. There are two principles according to which vibration energy harvesters work. The most common method of operation is to use stationary magnets in which a coil attached to an oscillating mass moves through the magnetic field thus inducing AC voltage with varying amounts of magnetic flux. There are also energy harvesters where this principle is inverted; the coil is fixed and the movement of the magnets is triggered by the oscillation. The second vibration harvesting principle is using piezoelectric membranes to turn the vibration energy into electricity. The major difference between electromagnetic and piezoelectric harvesters is the impedance. The piezoelectric harvester has an impedance factor of a thousand and more. High impedance means that most of the energy gets lost in

31 2 Wireless Embedded Systems Powered by Energy Harvesters 31 the source impedance of up to several mega ohm. Electromagnetic systems compared to piezoelectric harvesters have an impedance of several tens of ohms, therefore they have higher energy conversion efficiency, longer life cycles and the capabililty of working effectively through strong vibrations. The efficiency of conversion and the amount of energy harvesters deliver depends on several factors. Not all types of vibration are suitable for energy harvesting. The source vibration must have certain characteristics for it to be usable. The amount of energy generated from vibration depends upon: vibration frequency it has to be repeatable and match within a certain range to the host environment frequency. vibration level the root mean square amplitude level determines the power output of the energy harvester. oscillating mass the higher the oscillating mass is, the higher the amount of energy can be expected to be. quality the quality factor of the energy harvester. Acceleration (m/s 2 ) Frequency (Hz) ASTF (a 2 /ω) Car engine compartment Base of 3-axis machine tool Blender casing Clothes dryer Car instrument panel Breadmaker Walking (head acceleration) Table 3 Vibration sources and their parameters Vibration energy harvesters are capable of generating relatively large amounts of power with small mass if the object acceleration is high enough. Acceleration of up to 2g and frequencies between 2Hz and 2Hz are typical values that can be measured with operating machines [115]. The maximum electrical power available for a linear displacement movement at resonance can be calculated as shown in the equation: P max 2 ( a / ω) 4 mq = (2.1) where a is the acceleration, ω is the angular velocity, m is the oscillating mass and Q is the quality factor. The limiting factors are the acceleration-squared-to-frequency (ASTF) ( a 2 / ω), the proof mass and the quality factor. Table 3 shows several common vibration sources and their appropriate acceleration, frequency and ASTF parameters [19]. Most of the vibration harvesters commercially available are intended to be used in an industrial environment, because line-powered machinery are excellent vibration sources. An example of such an energy harvester is the PMG17 [139]. The harvester operation is

32 2 Wireless Embedded Systems Powered by Energy Harvesters 32 magnetic-based and it is capable of converting up to 1mW at 25mg from kinetic energy harvested from a vibration environment tuned to 12Hz frequency. The energy harvester and its power output spectrum is shown on Figure 7. 55mm Figure 7 Power spectrum of PMG17 vibration energy harvester Another interesting vibration energy harvester using piezoelectric operation concept is the Joule Thief JTRA-e5mini [138]. Its power spectrum sampled in a transportation environment is shown on Figure 8. The energy harvester is intended to be used in industrial and transportation environments and can harvest energy from low amplitude random vibration environments (around 14Hz). Figure 8 Power spectrum of JTRA-e5mini vibration energy harvester Although several attempts are being made to construct small size energy harvesters like those described in papers [116][117][118][119], these projects are either still in the research phase or the results are not commercially available. One of the biggest disadvantages of the vibration harvesters is the small bandwidth requirement. Most of the vibration harvesters need resonance for reaching the required amplitude. This resonance is the reason for a very narrow bandwidth, which means that the harvesters are tuned too narrowly for an exact host frequency. This limits their use to a very specific environment. The advancing development of micro-electromechanical systems will in the near future eliminate such constraints and vibration energy harvesters will become a standard power supply for WESPEH devices Thermoelectric energy harvesters Thermoelectric energy harvesters convert thermal energy to electricity. Thermoelectric harvesters can be used everywhere where a few degrees of temperature difference at sufficient thermal mass occurs. The function of thermoelectric harvesters is based on the Peltier-Seebeck effect, which states that voltage is created in the presence of a

33 2 Wireless Embedded Systems Powered by Energy Harvesters 33 temperature difference between two different metals or semiconductors. The thermoelectric energy harvesters are composed of a Peltier element. The Peltier element is an electrothermal converter consisting of a thermocouple composed of p- and n-types of semiconductors connected electrically in series and thermally in parallel. Peltier elements are used for instance in cooling boxes or in processor coolers. Based on the Peltier-Seebeck effect, by applying a current on the element, one side of the element will be cold and the other side warm, caused by charges flowing through the n-type of the element to the p-type of element. This effect is reversible, consequently the Peltier element can be used as an energy harvester. The generated power depends on the temperature gradient and on the size of the energy harvester element. To calculate the voltage of a thermo element, the following equation is used: T = 2 ( S ( T) S ( T ) B A V dt (2.2) T 1 where S a and S b are the Seebeck coefficients of the metals A and B as a function of temperature, and T 1 and T 2 are the temperatures of the two elements. Thermoelectric energy harvesters can be used effectively in heating and cooling sources that build a large temperature gradient with the environment as is the case with air conditioners or radiators. The human body also works as a heating source. A laboratory setup in Figure 9 shows a finger-heating source providing enough energy to power a wireless sensor and an LCD display. Figure 9 Finger heat powered sensor and LCD display A significant constraint of this solution is that it relies on the relatively low temperature gradient in the range of 5-1K or even lower, between the human body and the environment. The typical conversion efficiency of thermoelectric harvesters is below 1%. Low cost thermoelectric elements produce small voltages. The solution to this problem is to use an ultra low power DC/DC converter that is capable of transforming the small voltage to a higher one. With an effective 1cm 2 Peltier element and 3x3x1 cm 3 heat sink a continuous power of 1mW (regulated 3V) is available at a 12 K temperature difference, as shown in Figure 1. The temperature difference measurement was taken between the hot side and ambient air.

34 2 Wireless Embedded Systems Powered by Energy Harvesters 34 1,6 1,4 1,2 Power [mw] 1,8,6,4, Temperature difference [K] Figure 1 Power measurement of thermoelectric energy harvester Two commercial systems are available to harvest thermal energy. One system is called TE-Power [14]. TE-Power is a modular thermoelectric energy harvester with integrated Peltier element, DC/DC converter and a heat sink. The module can produce around 3.628mAh per year at a 35K temperature difference. Another module used for thermal energy harvesting is the ECT31 Perpetuum [141]. This module is an ultra low power DC/DC converter that can be used with any kind of Peltier element. The module starts the operation at typical 2mV relating to a 2K temperature difference with a standard low-cost Peltier element. It can generate 4.4mWh per year at a 8K temperature difference with a low cost Peltier element. Figure 11 Thermoelectric energy harvesters, left TE-Power, right ECT31 To get efficient power budget where the temperature difference between the heating source and the environment is around 12 2K, a relatively large heat sink is required. This often represents a problem for WESPEH design, caused by the large size of the energy harvesters. Therefore, thermoelectric energy harvesters for WESPEH design are limited to areas where the average temperature gradient between the heating source and environment is beyond 8K.

35 2 Wireless Embedded Systems Powered by Energy Harvesters Energy harvesters delivering energy bursts The second group of energy harvesters delivers a single energy impulse. Such energy harvesters are ideal for systems where a single immediate state of information has to be captured and transferred. The concept of efficient energy management in such a system can be achieved by starting the system and completing the required tasks within the shortest possible time. After the task is completed the system is completely powered off. An example of such a harvester is a piezo membrane or electro dynamical energy harvester Piezoelectric energy harvester Piezoelectric energy harvesters convert mechanical energy to electricity. The piezoelectric energy harvester s electrical power is gained from piezoelectricity. The piezoelectricity is the charge, which is accumulated in solid materials as crystals or ceramic in response to applied mechanical strain. By applying stress or deformation on the materials, an electric potential is created. Many materials both, natural and synthetic, exhibit piezoelectricity, for instance minerals such as quartz and topaz, different polymers such as polyvinylidene fluoride and ceramics such as langasite. Piezoelectric energy harvesters are mostly used in electric cigarette lighters. There is a wide potential to apply these energy harvesters in many different applications. Just to mention a few examples, piezoelectric energy harvesters integrated to shoes could power electronics during walking [134]; piezoelectric stripes attached to human body could convert biomechanical energy into electricity by muscle-movement [136]; or a dance club where the lights are powered by dancing people from the dance floor, where piezoelectric energy harvesters are integrated into the floor [133]. Although there is much ongoing research with piezoelectric harvesters, there are significant problems with their integration to a WESPEH application. The first problem is the force that needs to be applied to deform a piezoelectric element. For instance, a monolithic piezoceramic cylinder with a 5mm diameter and 15mm length requires 1N force to provide few µm of deformation. Another significant problem with the use of piezoelectric energy harvesters is the conversion of the voltage level. Piezoelectric generators deliver very high voltage in a magnitude of 5-1V. The output current by this case is only few na. Therefore, a very effective step-down converter is required with a very high input voltage and efficiency. In Figure 12, the current (CH2, 5 mv/div that corresponds to 1mA/div) and voltage (CH1, 5V/div) waveform measured on a resistive load of a piezoelectric harvester is shown [135].

36 2 Wireless Embedded Systems Powered by Energy Harvesters 36 Energy[mWs] Time[µs] Figure 12 Piezoelectric energy harvester voltage and current waveform Electrodynamic energy harvester Electrodynamic energy harvester converts mechanical energy to electricity. The principle of electrodynamic energy harvester is based on the induced voltage on a coil by a moving magnet triggered by linear motion. The amount of electrical power depends on the strength of the magnetic field, the number of turns of the coil, and the change of the magnetic flux density through the coil. The efficiency of these energy harvesters is around 6%. Electrodynamic harvesters can be used anywhere where a certain mechanical motion exists. There are many applications in which macro-scale electrodynamic energy harvesters are used, for instance, bicycle dynamos, wind-up light sources, etc. Nevertheless, there are only a few micro-scale devices available that are usable for the WESPEH devices. One example of a suitable WESPEH energy harvester is the ECO1 [142] shown in Figure 13. It is an energy converter for linear motion. Figure 13 ECO1 - electrodynamic energy harvester By pressing the energy bow with around 3N actuation, from the force of the spring sufficient energy is converted to power a WESPEH. The voltage flow measured on a capacitor and without a load is showed in Figure 14.

37 2 Wireless Embedded Systems Powered by Energy Harvesters 37 12, Voltage of ECO1 without load Voltage on the capacitor 1, 8, Voltage [V] 6, 4, 2,,,8,9,1,11,12,13,14,15,16 Time [s] Figure 14 Voltage measurement of ECO1 To determine the average power delivered by ECO1, we have made several measurements with various qualities of ECO1. The measurement results can be found in the Appendix B.2. Figure 15 shows the force, power and displacement relationships. The measurements where performed on a 1µF capacitor. The electrical power was calculated using the equation: 1 P = CU 2 (2.3) 2 where C is the capacitance of the capacitor, and U is the voltage level measured on the capacitor. P ower [m Ws],18,16,14,12,1,8,6,4,2 1 Forece vs Power,9 Force vs Displacement,8,7,6,5,4,3,2,1 Displacem ent [m m ], 2 2,2 2,4 2,6 2,8 3 3,2 3,4 3,6 3,8 Force [N] Figure 15 Power measurement of electrodynamic energy harvesters Mirco-scale electrodynamic energy harvesters have a promising future in powering

38 2 Wireless Embedded Systems Powered by Energy Harvesters 38 WESPEH devices. Although their efficiency is below 1%, their compact size and solid energy output makes them ideal harvesters for many applications, as showed in Conclusion In this chapter we presented common energy harvesters that are usable for powering WESPEH systems. The discussion about the functionality of the energy harvesters, their efficiency and amount of power they deliver system should help in understanding the design problems of WESPEH discussed in the next chapters. There are also many other energy sources and energy harvester types that were not mentioned in this chapter because these types of energy harvesters are still in the research phase (RF, rotation energy, bio energy harvesting). From all the mentioned energy sources, the most proven and widespread harvesting technology is the photovoltaic. The summarization of common WESPEH energy harvesters, energy sources and their properties is showed in Table 4. Mechanical Vibration Solar Thermal Energy harvester Electrodynamic - Magnet & Coil Magnet & Coil Photovoltaic cell Peltier element Harvester dimension 33 x 22 x 1 mm 55 x 55 mm 18 x 2 mm 5 x 5 x 2 mm Energy input 3N x.5mm displacement 12Hz vibration of 25 mg 5 lux 12K temperature difference Energy output.125mws per operation 1mW permanently.1mw permanently 1mW Permanently Conversion Efficiency ~6% ~2% ~13% ~1% Table 4 Summarization of energy sources and energy harvesters

39 2 Wireless Embedded Systems Powered by Energy Harvesters Applications It is important to understand the application scenarios and use casess of WESPEH in order to understand the design problems. In this chapter, different HW platforms and application scenarios are presented where WESPEH are used HW Platform This chapter discussess various HW platforms suitable for WESPEH design. The aim of the chapter is to give an overview of the platform features, energy requirements and the applications where these modules are used. From these platforms the most appropriate HW will be selected for the further research proceeding EH-Link Energy Harvesting Wireless Sensor Node EH-Link [137] is a WESPEH module that can be powered by several energy harvesting sources such as thermal gradient, light, electromagnetic field and piezoelectricity. The module has two energy harvesting inputs and is compatible with piezoelectric, electrodynamic, solar, RF field, and thermoelectric harvesters. The module can operate with high impedance AC or DS sources in range of 5-2V, as well as with ultra low power sources from 2-6mV. The module has an integrated onboard capacitor. The module has several integrated sensors: on-board triaxial accelerometer, relative humidity sensor, temperature sensor and signal conditioning torque sensors, pressure transducers, and a magnetic sensor. EH-Link comes with an integrated microcontroller with 2MB Flash and 256kB FRAM memory and a 2.4Ghz RF transceiver. The module can be used in various application scenarios such as strain measurement for aircraft tests, civil structures monitoring, etc. The module and its applications are shown in Figure 16. Figure 16 EHK-Link module and applications

40 2 Wireless Embedded Systems Powered by Energy Harvesters PTM2 - Push button transmitter PTM2 [166] is a WESPEH transmitter module powered via mechanical energy. The module is a completely functional WESPEH solution with integrated electrodynamic energy harvester, RF module, storage capacitor, energy management block and microcontroller with a preprogrammed firmware. When the energy bow is pushed down 1.8mm with approx 7N force, it generates enough energy to power up a microcontroller. The microcontroller queries the status of the contact nipples and a radio signal is transmitted over the air. The transmission range is approximately 3m in a free field; the RF frequency is MHz or 315MHz. The module implements the EnOcean radio protocol stack. Although the module can be used in several types of applications, the key applications of this device are wall-mounted flat rocker switches, as well as handheld remote controls. The module and applications are shown in Figure 17. Figure 17 PTM2 module and applications The variant PTM23 [167] is a standalone configurable version of this module without the mechanical part and integrated energy harvester. PTM23 can be powered with an energy impulse >.45mWs. The impulse has to generate at least 2.5V and a maximum of 5.5V for the duration of min,.1ms and maximum 11ms. This type of module can be connected to various energy harvesters.

41 2 Wireless Embedded Systems Powered by Energy Harvesters GP5C The GP5C [168] is a single chip WESPEH hardware platform. The chip integrates a 2.4GHz transceiver, ncluding the IEEE physical layer, thus is prepared for the Zigbee radio protocol stack. The -93 dbm receiver sensitivity allows extended coverage. The chip has a HW support for the AES-128 encryption. Furthermore, the circuit comes with built-in power management that has various timed power down modes. The lowest power down mode is at 25nA using a 32kHz oscillator, 4nA event driven. The chip can work with energy harvesters, although it was optimized for lithium button cell batteries. It has an integrated battery monitor. A block diagram of the chip is shown in Figure 18. Figure 18 GP5C Block Diagram Based on the GP5C platform, various prototypes of remote controllers have been realized based on the Zigbee radio protocol stack. These remote controllers realize bidirectional communication, thus enabling features such as finding the lost remote controller EO3I The EO3I [161] is a single chip WESPEH hardware platform. EO3I is an RF transceiver chip with an integrated 8bit 851 core, 32kB Flash and 2kB RAM and an advanced ultra low power management module. A block diagram of the chip is shown in Figure 7. The RF transceiver implements a bidirectional communication layer and covers ISM frequency bands, 868 and 315MHz. It has a -97dBm receiver sensitivity and is capable of transmitting a signal with up to 1dBm. The RF interface is designed to support ASK modulation with 125 kbps data rate and 1kHz bandwidth. EO3I comes with a variety of peripheral interfaces. The chip implements a pair of high precision 8 channel, 12 bit analog to digital converters, and one 8bit 4 channel digital to analog converter. It has 16 configurable I/O mixed signal interfaces for both digital and analog signals. All the digital IO ports implement Schmitt triggers. From the HW communication interfaces, the ASIC offers one RS232 and one master/slave SPI interface. The chip has an integrated temperature sensor, a PWM signal generator and two ultra low power wakeup pins. The ultra low power management block enables the direct operation of the sensor interface and radio transceiver using energy harvesters of

42 2 Wireless Embedded Systems Powered by Energy Harvesters 42 various energy strengths: electrodynamic, solar, temperature, vibration and rotation. Figure 19 EO3I Block Diagram The power management block includes a voltage regulator with a voltage limiter and a threshold detector, enabling the system to work within a supply range of between V. The ultra low power block implements several ULP timers running on different time domains. The microcontroller can put various parts of the system into power down mode, and the MCU can wake up from these modes through timer overflow or wakepins. The module supports various power down modes. The lowest power mode with 22nA current consumption, with an active 1Hz timer, has a 32bytes memory to retain information. Based on the EO3I HW platforms, several WESPEH modules have been created. STM3XY [165] is a WESPEH module with bidirectional RF interface. It has 3 digital and 3 analog I/O interfaces and 2 wake pins. In the 32kB FLASH memory, customized firmware can be downloaded. The HW variant STM31 is a completely functional solution and comes with an integrated 34 x 16mm solar cell, integrated energy storage, power management block and preconfigured firmware. The energy storage at full load ensures the module s functionality for up to 4 days of darkness. The startup time of the module with empty energy storage is 2.5min at 4lux. The transmission range is approximately 3m in a free field. The module makes possible a wide range of wireless and maintenance-free sensors and actuators, such as: magnet contacts, temperature sensors, humidity sensors, room operating panels, pressure sensors, gas sensors and heating valve actuators. The module and its applications are shown in Figure 2. The HW variant STM3 [163] doesn t have an integrated energy harvester and energy storage block. This module can be powered by various external energy harvesters and the firmware can be freely configured.

43 2 Wireless Embedded Systems Powered by Energy Harvesters 43 Figure 2 STM3XY modules and applications Conclusion From the discussed HW platform, the EH-Link module seemss to be an interesting solution for WESPEH applications. According the documentation, it supports many energy harvesters. From the specification we are missing much basic information, such as information about the power consumption, type of microcontroller, firmware features, configuration possibilities, integrated capacitor values, supported RF power levels, temperature dependency etc. Furthermore, we were unable to find applications developed with the EH-Link module. PTM2 HW platform is a very interesting ultra low power system. Several applications has been realized with the module. The major disadvantage of the module is the proprietary firmware, which is not adjustable. The GP5C is a single chip WESPEH platform with built in support for the IEEE physical layer. This makes it appropriate for use with the Zigbee radio protocol stack. The chip has very low power consumption with active timers. The disadvantage of the circuit is the lack of a microcontroller block. We were unable to find any application or HW modules developed with the GP5C. The EO3I is a single chip WESPEH platform with a built in 8-bit microcontroller. The chip has very low power consumption with active timers and RAM retention. Based on the chip, several HW modules and applications were developed. As this platform offers the most features from the analyzed platforms and has the lowest energy needs and integrated RF interface, we will use it in our proceeding research.

44 2 Wireless Embedded Systems Powered by Energy Harvesters Application scenarios The following chapters present various WESPEH application scenarios. The definition of scenarios should help to understand the design challenges of WESPEH that are discussed in chapter 2.5. Furthermore, these scenarios will be used to derive the requirements of a WESPEH operating system discussed later in chapter Intelligent buildings and homes Scenario 1 Aim of WESPEH usage: Available energy sources: Direct user interaction: Energy saving Automation Installation cost saving by reducing wire usage Increase of living comfort Light Mechanical Temperature difference Yes The most widespread applications of WEPSEH are in intelligent buildings and homes. A precondition of these scenarios is that all the WESPEH devices are interoperable and are using the same wireless protocol. Usage of WESPEH saves on wire installation costs in buildings and homes. Additional buildings equipped with WESPEH make possible further energy savings, by utilizing intelligent heating and air condition controls, switching off unnecessary light sources, etc. WESPEH devices installed in intelligent buildings can undertake the following roles: Passive sensors Passive sensors are WESPEH devices equipped with several sensing interfaces, and with an uni-directional radio interface with transmission capability. These type of devices are for most of their lifetimes in a power saving or power off mode. The wake up of the sensor is triggered by an event. After the wakeup, the information from the sensing interfaces is queried. Optionally a power level measurement is performed. Depending on the measurement results, the measured information is transmitted. The wake up of the sensor can be triggered by the following events: timer overflow - a sensor is configured to periodically check the sensing interface. An example is a temperature sensor that wakes up regularly, measures the temperature and transmits this information. rapid increase of power the sensor is in off mode and is awakened to initialize its status and transmit information. An example is a mechanically powered push button transmitter that transmits the state of buttons. decrease of energy below a critical level the sensor needs to power off various blocks of the system to survive a low power state. An example is a state where solar powered sensors have to survive overnight. change of the state on the sensing interface the sensor needs to react to an

45 2 Wireless Embedded Systems Powered by Energy Harvesters 45 event in real time and transmit this information without delay. An example is a window contact that is woken up by a signal from a reed contact, indicating that the window has been opened. The direct interaction of the user with the WESPEH device is typical only for the mechanically powered devices where an energy impulse is generated by the user s actions. It needs to be noted that the discussed passive sensors differ from wireless sensors used in wireless sensor networks, as they do not create a network topology. The information is transmitted redundantly as a broadcast without handshaking. Unlike in wireless sensor networks, a failure of one sensor would mean the malfunction of the whole system. Application examples of passive sensors are: solar powered temperature or humidity sensors, window contacts, motion detectors, mechanically powered window openers and light switches. Detailed application scenarios are described at the end of this chapter. Self-powered controllers Self-powered controllers are WESPEH devices equipped with several sensor and actuator interfaces. These devices have a bidirectional radio communication interface with reception and transmission capabilities. WESPEH controllers can be optionally equipped with mechanical controls for direct interaction with the user (i.e. thermostats with a display). A control action is performed either through direct interaction by the user (button pressed) or upon receiving information from a sensor. Since these types of WESPEH devices have the capability to control and perform bidirectional communication with other wireless components, the power level of these devices should never be allowed to sink under a critical level. The self-powered controller is capable of being paired with various sensors. This requires that the device has a non-volatile memory where the sensor identifications can be stored. The self-powered controllers are in a sleep mode for most of their lifetimes. The wake up of the controller can be triggered by the following events: incoming radio transmission - information is delivered to the controller from a sensor. An example is when a heating valve control is directed to start heating once the temperature has dropped below a critical level. timer overflow - a controller is acquiring information from a line powered device. An example is a thermostat awaiting system-status information to be shown on a display. change of the state on the sensing interface the sensor needs to react to a user interaction. An example is a thermostat where the heating level has been changed by the user. Application examples of self-powered controllers are: solar powered thermostats with a display, solar powered window blind controls, thermal powered heating regulators, solar powered air ventilators. Detailed application scenarios are described at the end of this chapter. Apart from WESPEH devices, intelligent buildings and homes are further

46 2 Wireless Embedded Systems Powered by Energy Harvesters 46 equipped with line powered devices assuming the following roles: Battery or line-powered controllers Have the same role as the self-powered controllers. These devices are used in the installation with low ambient energy resources for effective energy harvesting. An example is an air conditioner mounted under the ceiling. Repeater Is a line powered transceiver ensuring the extension of wireless signal by repeating the messages received from various WESPEH devices. Furthermore, a repeater can act as a temporary storage for messages delivered to self-powered controllers. If the self-powered controller does not have the capability of waking up on a RF signal transmission, using a repeater it can perform a power saving bi-directional communication in the following way: The repeater temporarily stores the messages received. The self-powered controller wakes up periodically and fetches these messages from the repeater. This way the selfpowered receiver interface is on for a very short period of time. The communication flow is showen on Figure 21. Figure 21 Example of bi-directional communication through a repeater Gateway Is a line powered transceiver usually connected to a backbone. The device exchanges the information received from an installation to other cloud networks such as for building automation or internet. Gateways enable the monitoring of the status of the installations and their remote configuration. Additional remote gateways can also have the role of repeaters. The deployment of the WESPEH installation in a home can be as a standalone without the need for extra gateways or repeaters. WESPEH installations in buildings are created in a cell with a certain diameter covering several rooms and corridors. The interconnections of these cells are ensured using line powered gateways that connect these cells to the building automation system (see Figure 22). Therefore there is no routing requirement for the devices. Upon the deployment of the WESPEH devices, the sensors are paired to the controllers. The installation can be enhanced any time with an

47 2 Wireless Embedded Systems Powered by Energy Harvesters 47 additional device without the need to reconfigure the whole system. For a better understanding of the functionality of intelligent buildings and homes in the next section, two practical scenarioss will be presented where various WESPEH devices are used. Figure 22 WESPEH cell form deployment in a building Scenario 1.1: Heating automation The system consists of several wireless, energy-autonomous modules: a window opener sensor, heating regulator, occupancy sensor and a central device. The heating regulator is mounted on the radiator. It is able to adjust the thermostat valve and has a built-in temperature sensor. The module is powered by a thermo converter that harvests energy from the temperature difference between the radiator and its surroundings. The window opener is attached to the window and can detect when it is open and closed. It is powered by the opening and closing motion of the handle using an electrodynamic energy harvester. The occupancy sensor is fitted in the ceiling. It is powered by a solar cell and can detect motion and changes in temperature. The central device is also solar-powered. It is attached to the wall of the room. It collects information from the other modules and sends commands to the heating regulator about valve adjustments. When the central device receives information from the occupancy sensor that the room is not occupied anymore, it will send a command to the heating regulator to reduce the level of the heating. Alternatively, if the central device detects that a window is open, it commands the regulator to turn off the heating. The thermal WESPEH regulator measures the heat consumption. The person who is collecting meter information can examine the regulator for information without entering the room.

48 2 Wireless Embedded Systems Powered by Energy Harvesters 48 Figure 23 Heating automation with WESPEH devices Scenario 1.2: Intelligent Office A company office is equipped with several wireless intelligent, WESPEH modules: solar powered occupancy, temperature sensors, weather monitor, air flow regulator, window contact and CO2 sensors, blinds, window controller; mechanically powered chairs with weight detectors and light switches. Additional line powered controller is integrated into the ceiling light and electrical socket. There is no central device in this scenario. As soon as a person enters the room, the occupancy sensor starts the periodic transmission of a presence signal. The air flow regulator detects this presence signal, and using a small motor, adjusts the ventilation to let warm air flow in to the room. If the person sits on the chair, all the electrical appliances such as the computer, monitor, table lamp will be turned on. If the person leaves the chair, the electrical appliances will be turned off. By pressing the light switch, a signal is sent to the integrated light receiver and the light will be turned on. If the lamp receiver stops receiving the periodical presence signal from the motion sensor, then the light will be turned off automatically after a certain period of time. The window contact has an integrated CO 2 sensor. If the amount of CO 2 reaches a critical level, the sensor transmits a signal to the controller integrated into the window and the motor will open the ventilation part of the window. As soon as the window is opened, the window contact detects this state, and by transmitting a signal, instructs the air flow regulator to close the hot air flow. The blinds ensure automatic shading outside of working hours for security reasons. Furthermore, if the wind velocity exceeds the preset threshold of the solar powered weather monitor located outside of the building, the blinds are instructed via wireless signal to move to their secured position. Similar in case of rain the weather monitor instructs the window controller to close the window.

49 2 Wireless Embedded Systems Powered by Energy Harvesters 49 Figure 24 Intelligent office Safety critical applications Scenario 2 Aim of WESPEH usage: Ensure human safety through emergency signalization Provide data for rescue personal Available energy sources: Light Vibrations Direct user interaction: No Using WESPEH various safety critical applications can be realized such as in everyday life, but also in case of disasters. These application scenarios overlap with the wireless sensor network scenarios. The major difference in scenario is that WESPEH sensors in the mentioned ntioned applications are powered by energy harvesters and therefore are maintenance free. The precondition of these devices is long lifetime and robustness. WESPEH used in safety applications applications are equipped with various sensor interfaces and an uni-directional directional communication interface. WESPEH in these scenarios are for most of their lifetimes in an inactive power saving mode mode until the occurrence of a critical event. The critical design in these devices is that during inactive mode the collection of maximum power reserves has to be ensured. Critical ritical event occurrence wakes up the system and WESPEH starts to transmit the information periodically acquired from the sensor interfaces.. The receivers are always line powered. In some scenarios, the information transmission carries on until all the energy reserves of the device have been exploited. For successful functionality, the information has to be transmitted real time. In the following section three practical scenarios will be described.

50 2 Wireless Embedded Systems Powered by Energy Harvesters 5 Scenario 2.1: Stove ventilation A simple safety scenario represents the stove ventilation hood interaction with a WESPEH window contact. The window contact is solar powered and detects the open/close state of the window. If the window is open, this information is transmitted to the stove ventilation hood. The stove ventilation hood will only run when at least one window is open. This ensures the fresh air circulation in a room. Starting the stove ventilation without opening window could result in the increase of carbon monoxide level that would be present a danger for humans. Scenario 2.2: Intelligent smoke detector A smoke detector can be developed as a solar powered WESPEH. The smoke detector is equipped with a carbon dioxide, carbon monoxide and an ultrasonic occupancy sensor. In case of a high level concentration of carbon monoxide or carbon dioxide, the system wakes up, begins the transmission of the CO and CO 2 levels and the information from the occupancy sensor. This information should trigger a fire alarm. The information from the occupancy sensor should help the rescue personnel to determine if there are still persons located in the dangerous area. With deployment of these WESPEH devices, a valid radio link to the line powered receiver has to be ensured. WESPEH disaster monitor experimental deployment in a tunnel WESPEH geological monitor deployment on a rock fall net Figure 25 Example deployment of WESPEH for safety critical applications Scenario 2.3: Geological monitor A geological monitor is a solar powered WESPEH device that detects geological incidents such as rock falls, mudflows and similar events. The device is attached to rock fall barrier and monitors the condition of the net. It has a vibration sensor that can detect a break in the guard net, as well as vibrations caused by the rock fall. In case of a disaster, an alarm message is transmitted to the nearest base station that is line powered. This station forwards the detected information per GSM module [149]. Scenario 2.4: Tunnel disaster monitor In this scenario, WESPEH devices are integrated into the walls of tunnels. The devices are powered by vibrations produced by vehicles driving through the tunnels. The

51 2 Wireless Embedded Systems Powered by Energy Harvesters 51 WESPEH devices have several sensor interfaces such as CO and CO 2 sensors, ultrasonic occupancy sensors, temperature sensors and vibration detectors. In case of an explosion or fire, the WESPEH system is activated and information transmission begins from all the sensor interfaces. This information should help the rescue personnel to gather information about the extent of damage and information about the number of living people in the disaster area. The precondition of the system functionality is that the failure of several sensors does not endanger the functionality of the complete system [15] Health monitor applications Scenario 3 Aim of WESPEH usage: Available energy sources: Direct user interaction: Monitoring of patient Vital data collection for health evaluation Light Mechanical Temperature difference Yes Scenario 3.1: Vital monitoring WESPEH can be used effectively in a health care. Cables attached to patients bodies for monitoring vital signs cause a lot of discomfort during hospital stays. The cables can be replaced by a WESPEH attached to the patient s body that monitors various vital signs such as temperature, blood pressure and pulse rate. The WESPEH device has the following powering possibilities: breathing tension of the patient. thermal differences between human body and the surroundings. solar powered. mechanical per finger pressure. The measured data is logged in the device memory for an extended period. Once a day, when the receiver is within range of the WESPEH, the data is transmitted for further evaluation. In case the vital signs were to reach a critical level, an emergency signal is transmitted to the receiver. The patient is also capable of triggering an emergency signal by pressing a mechanical switch on the WESPEH. This finger pressure would generate enough energy to transmit an emergency signal. Similar devices can be used not only in hospitals, but also in nursing homes to monitor patients vital signs. In additional to the mentioned sensor, a gyroscope is integrated to the WESPEH system that provides information about the average movement of the person during the day. Health monitor WESPEH applications require fault-safe functionality and real time reaction to critical events [151][152].

52 2 Wireless Embedded Systems Powered by Energy Harvesters 52 Temperature powered vital signs monitor Mechanically powered vital signs monitor Mechanically powered emergency button Figure 26 Prototypes of WESPEH for health monitor applications Wire replacement applications Scenario 4 Aim of WESPEH usage: Available energy sources: Direct user interaction: Enable/ease installation in areas where wire installation is not possible/difficult Light Mechanical Temperature difference Motion Yes WESPEH can be efficiently used in applications where wire installation is very difficult or even impossible. Although similar applications have already been covered by previous chapters, for the sake of completeness we provide three additional scenarios. Scenario 4.1: Tire pressure sensor Modern cars have many sensors that are attached to the control unit of the car using wires. The average length of wiring in a modern car is approximately 2km [153]. This extensive wiring raises the risk of a system malfunction, while the environmental effects to which the cables are exposed over the car s lifetime can damage the wiring. Most of these sensors could be replaced using WESPEH devices. There are three ambient energy sources which could be used to power these devices: thermal differences between the motor and ambient environment, motor vibrations and car motion energy. WESPEH usage in car installation represents challenges that have yet to be solved. The first problem is the propagation of the wireless signal. Since the car has a steel construction, the wireless propagation of the radio signal is absorbed by the metal parts. For critical sensors controlling the ESP or ABS systems, it must be ensured that information is reliably delivered to the control unit in is real-time. This requires a bi-directional WESPEH communication interface. Another problem is the collision rate. With many WESPEH communications in a limited space, the rate of collision can increase rapidly. For non-critical information delivery, WESPEH devices can already be used today. An example of a WESPEH device prototype is showed in Figure 27. This is a tire pressure sensor powered by the rotational energy of the car wheels. The sensor samples the actual pressure of the tire and sends it to the control unit of the car.

53 2 Wireless Embedded Systems Powered by Energy Harvesters 53 Figure 27 WESPEH tire pressure sensor prototype Scenario 4.2: Airplane window blind controls Similar to cars, airplane wiring installation is also a significant issue. To reduce installation costs and increase the comfort of the passengers, WESPEH devices can be used to control airplane window blinds. The blinds are placed between the glass and plastic insulation of the window. The WESPEH is located in the insulation part of the plane. The energy for the WESPEH and for the blinds motor is gained from the temperature difference between the passenger cabin and the outside temperature. The control of the blinds is ensured through a mechanically powered WESPEH switch integrated into the passenger s seat. In this WESPEH application, there are no power issues since the 1K temperature difference is enough to generate several tenths of a watt of power. Since the transmitter and receiver are within a close range, the radio performance will be ideal. The major issue in such scenarios is the EMC compatibility. It is very critical that the signal from the WESPEH does not interfere with the plane s onboard electronics. Furthermore, for the wireless standard a radio frequency such as 2.4GHz has to be used which is approved in all countries around the World. Scenario 4.3: Industry end switch Wiring installations are also an issue in industrial buildings and production areas. Mechanical and solar power can be used effectively as ambient energy sources. Position switches with an autonomous energy generator are easily fitted in areas difficult to access and are flexible when it comes to moving them elsewhere. The issue in such WESPEH design is both the EMC compatibility and the signal propagation reliability.

54 2 Wireless Embedded Systems Powered by Energy Harvesters Design problems In the next chapter, we give a short overview of the common embedded system design approaches and discuss the challenges encountered in WESPEH device design. As a solution for this problem, this chapter introduces a straightforward design technique that is based on rapid prototyping and constraints analysis WESPEH design The WESPEH scenarios and use cases show that the applications can be heterogeneous. For their successful implementation, an appropriate design methodology is required. Embedded system design is a very complex problematic as the system consists of hardware and software. This brings the complexity to the design problematic since the method of hardware and software design has a significant difference. Hardware systems are designed as the composition of parallel components represented as analytical models. Software systems by contrast are designed from sequential components (objects, threads) represented by computation models [14]. For a successful design, it is crucial to have good synchronization between hardware and software design steps. Failure to do so can lead to a hardware/software design gap problem. Several known design approaches try to solve these diverse problems with the help of model abstraction. Although these models seem to offer a generic solution, they are often diametrically opposed. A certain model can only be applicable for a certain type of embedded system. This problem has already been recognized by both the industrial and science communities and there are several ongoing research studies which are attempting to address these problems and are searching for optimal solutions [125]. Other embedded system design approach is through critical system engineering. This approach tries to guarantee system safety at all costs, and is achieved mainly by using massive redundancy of resources. WESPEH can't be characterized as critical systems and the system has limited energy resources for redundancy. Best-effort system engineering design approach tries to optimize system performance when the system operates under expected conditions. Best-effort system engineering is based on average case analysis and on dynamic resource allocation. In case of a WESPEH system an average case analysis doesn't resolve critical factors such as critical energy state [14]. WESPEH devices are heterogeneous as the powering possibility dictates the critical requirements on the system. This heterogeneity makes it difficult to follow a generic design model. The difficulty of the design is due to the contradictory constraints placed on the system for instance low energy needs with high radio transmission power or unobtrusive hardware with energy harvester delivering high amount of energy. Design process of WESPEH with similar functionality but different harvesting method may completely differ. There is a different proceeding for a system powered by an electro dynamic converter where the main emphasis is placed on the optimization of the energy generator as for a solar powered device where the emphasis is concentrated on the longterm energy storage. We believe that best WESPEH design proceeding are practical straight-forward techniques.

55 2 Wireless Embedded Systems Powered by Energy Harvesters WESPEH design approach Based on several years of experience and observation of WESPEH devices development we conclude that the most successful WESPEH projects were those where several functional prototypes with hardware and software were built and evaluated. Therefore we propose a straightforward design technique based on prototype quantification. Prototyping of WESPEH devices has several advantages: allows the opportunity to test various design options. helps to determine design flaws earlier. simplifies the energy consumption estimation. verifies the product feasibility. allows the possibility to test radio performance. enables the definition of the test in the early project phase. There are many different possibilities for building relatively fast working WESPEH prototypes. On the other hand, prototyping alone does not guaranteed that the final system will be a product feasible for mass production. Lots of universities and research institutes have succeeded in creating their own WESPEH prototypes. However, most of these projects remained in the research phase and were not realized as commercial products. There are a limited number of WESPEH devices available on the market for mass consumers. We suggest that the explanation for this phenomenon lies in a common problem: underestimating the complexity of WESPEH design. The difficulty of WESPEH design is due to the fact that there are usually opposing requirements placed on the device. In order to fulfill these requirements, often critical design constraints are 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 into unresolvable issues the moment the device is to become a product ready for mass production. To overcome these problems, our proposal is that prototypes must be evaluated subject to design constraints. Based on this knowledge, it is a possibility to define a straightforward design approach that consists of the following steps: 1. Requirement definition 2. Design constraint definition 3. Preliminary specification 4. Prototype creation 5. Prototype evaluation 6. Prototype quantification 7. Technical specification 8. Product development As the first step in development, the requirements of the WESPEH device must be established. An important second step for a WESPEH development is to identify the major design constraints. For a typical WESPEH system -- based on the architecture and application scenarios in the previous chapter -- we can identify five typical design constraint groups:

56 2 Wireless Embedded Systems Powered by Energy Harvesters 56 Energy aspects Radio platform Microcontroller platform SW aspects Component aspects Price aspects With design constraints defined a preliminary specification of various technical solutions is created. The specification is preliminary as it is not yet clear which technological solution will be the most suitable. In the next design step functional prototypes - including hardware and software - are created employing various technical solutions. As the next step, each prototype is evaluated and compared to the defined requirements. The sixth step includes the quantification of the prototypes as the subject of design constraints. The prototypes are given a rating according to the evaluation of the design constraint groups. The best rated prototype is selected and a specification created. Finally the product development is started which can follow any common design procedure. We introduce a ranking system where each constraint group is assigned a value from 1 to 5 where 1 is the lowest rating and 5 is the highest rating. Based on this rating value, the prototypes can be quantified as it is discussed later in chapter In the next chapters, the constraint groups will be briefly discussed. Techniques and solutions will be presented to show how to proceed with different constraints ratings. Based on these solutions, it will be possible to understand which factors influence the rating of the prototypes Energy aspect The energy aspect constraints define the minimum amount of energy delivered by the energy harvester to the system. This amount of energy has to cover the worst-case energy consumption of the system. The energy aspect constraint can be evaluated through an energy usage analysis. The energy budget determines energy consumption as a function of time. There are three design steps to determine the precise energy budget of the WESPEH system: ad hoc energy consumption calculations. energy consumption simulation using the system model. energy consumption measurement on prototype.

57 2 Wireless Embedded Systems Powered by Energy Harvesters 57 In the first step, the approximate energy budget is determined by ad hoc calculations of the electrical component's average power consumption. t [ms] Execution stage t 25 o C I 25 o C (I* t) [mams] Energy 1.8V Off,55, 1,1 Deep Sleep 1,55,55,2 1,22 Wake-up from Deep Sleep,2 3,8,76 1,39 11,43 XTAL-Stabilisation (Standby) 1,2 1,8 2,16 5,27 12,584 CPU init 1,18 4 4,72 13,77 13,868 A/D converter activation,18 6,6 1,188 15,91 14,429 Temperature measurement, ,72 28, 14,57 A/D converter deactivation,14 1,6 1,484 3,68 18,27 Packet preparation,2 4,4,88 32,26 19,228 Transmission 1,2 24,3 29,16 84,75 34,229 Shortterm Sleep 15,1,15 85,2 34,4 CPU init,17 3,8,646 86,18 36,1 Packet preparation 1,6 1,8 2,88 91,36 37,373 Transmission 1,2 24,3 29,16 143,85 52,374 Shortterm Sleep 15,1,15 144,12 52,545 CPU init,17 3,8, ,29 53,746 Preparation 1,2 1,8 2,16 149,17 53,917 CPU,17 3,8,646 15,34 55,118 Transmission 1,2 24,3 29,16 22,82 55,118 Deep Sleep 5,55,275 22,87 Energy consumption for 1x active run: 131, ,73 22,87 Consumption for 1 sec deep sleep: 1,E+5,55 55, 99, Table 5 Temperature sensor energy consumption calculation In the second step, it is essential to validate energy consumption calculations with simulations. Building up a simulation model of the system is not a trivial task. There are several software tools available on the market that can help here, for example Matlab Simulink or P-Spice. The last design step is to adjust the energy consumption calculation and simulation by performing measurements on the WESPEH prototypes. This step delivers the most precise results because additional factors are also evaluated, such as the formatting state of the storage capacitors and the influence of temperature. For the measurements, the WESPEH execution process has to be broken down into execution stages. For each execution stage, the power consumption of the system is measured on the prototype. The power consumption of a system is also influenced by temperature changes, therefore the measurements have to be performed in worst-case temperature conditions. The result of this analysis is the complete energy consumption of the system, which can

58 2 Wireless Embedded Systems Powered by Energy Harvesters 58 be calculated with the equation: E n = U t Ii [ J ] (2.4) i= 1 i µ In the equation, E represents the energy consumption of the system over a period of time, U is the system voltage, t i is the execution stage duration and I i is the current consumption of the system. Sample energy budget calculation is shown in Table 5. The calculations are derived from the energy measurements shown in Figure 28. This is a very simplified energy budget for a solar powered temperature sensor that transmits the change of temperature every 1 seconds. The red line represents the accumulated power consumption; the blue line represents the current consumption as the function of time. As can be seen from the energy usage table, most of the power in the system is consumed by the radio communication and microcontroller. The calculated energy value is used in the prototype evaluation. In additional to the energy budget calculation, the type of energy management has to be evaluated. In this case, the most important aspect is the type and control of long term and short term energy storage. There is no single best long term storage device. Every solution has its own advantages and drawbacks (more information about this topic is provided in chapter ). In the energy aspect evaluation, the pros and cons of these aspects must be considered Current [ma] 1,1,1,1, Time [ms] Figure 28 Temperature sensor energy flow Components aspect For the successful mass production of WESPEH, components aspect plays an important role. The component aspect has a strong influence on the energy and price aspects. The component aspect can be evaluated based on the following parameters:

59 2 Wireless Embedded Systems Powered by Energy Harvesters 59 Number of components Energy autonomous devices have an unobtrusive size therefore the device PCB has small dimensions. This is the reason why the SMD components need high integration density. Devices with high-density components have a higher risk of production problems like bad soldering or incorrect assembly. Radio platform solutions built up from discrete components have a higher failure probability because they are composed of a high number of electrical components. These hazards can be reduced when the radio platform is built upon integrated circuit solutions. The number of components also has an influence on the production price. The high number of components has an influence on the assembly and production test duration. Parameter tolerances An important aspect needs to be considered when designing a WESPEH system. The power consumption of the system varies over the product lifetime caused by a parameter change in the electrical components. Therefore it is essential during the component selection to consider the parameter tolerances. As an example, a capacitor has a certain maximum charge-discharge cycle and certain leakage current [126]. These parameters vary over the capacitor lifetime and this has an influence on the energy budget. It can easily lead to device failure if the design of the system is based on the nominal parameters of the components and the parameter fluctuation inside the component tolerance is not taken in account. Second source availability The success of mass products can be jeopardized if a key component is not being produced anymore (for instance the storage capacitor). It is important to ascertain how long the key components will be available on the market. It must be ensured that for key components, such as the microcontroller, storage capacitor and radio block, a second source option is available that can be used as a replacement in the future. The second source component has to have the same parameter set, otherwise the evaluation of the device will have to be repeated upon changing the component. Prototype1 analog radio with SAW Prototype2 digital radio Number of components PCB Size 6cm 2 4cm 2 Key Components PIC12F629 NCP14A MSP43F21I CC111 Support Second Source PIC12F675 14AS MSP43F212 n/a Energy block tolerance 1% 1% Rating: 4 3 Table 6 Example of component aspect analysis When designing a WESPEH device, the mentioned parameters have to be summarized and evaluated for each prototype. During the evaluation, an FMEA analysis can help to determine the risk factor. Based on this summarized information, each prototype can be assigned a rating. An example of a component analysis is shown in Table 6.

60 2 Wireless Embedded Systems Powered by Energy Harvesters Radio platform The radio interface has the highest power consumption in a WESPEH system; therefore the optimal choice of radio platform has a strong influence on the energy aspect. There are several factors affecting the power consumption characteristics of the radio communication, including the type of modulation scheme, data rate, transmission power and the operational duty cycle [16]. The first decision in the radio platform choice is the radio band selection. For the sake of demonstration, the next section covers what factors must to be considered during band selection. Let s consider the pros and cons of the 2.4GHz frequency band. Devices working in 2.4GHz have good outdoor coverage, but the transmission range in buildings is significantly lower than in lower frequency bands because of the signal attenuation through walls. Another important factor is the occupancy of the frequency band. 2.4GHz is used by several wireless standards such as Bluetooth, WLAN, Zigbee. Devices using these wireless standards are either line or battery powered, thus they have a strong transmission power in comparison to WESPEH where the transmission power is partially limited by the energy consumption of the device. Therefore WESPEH devices communicating at the 2.4 GHz frequency band have a higher interference probability 1. Figure 29 Frequency bands for optimum WESPEH radio performance One big advantage of the 2.4GHz band is that it is available and standardized all around the world. If a WESPEH device is intended to be used in different countries this fact makes the integration easy. Also it is important to mention that the sizes of antennas are significantly smaller at 2.4 GHz than for lower bands. Finally, the most reasonable argument is the energy efficiency and performance. Wireless energy autonomous devices can reach the optimum radio performance and energy efficiency in the frequency bands between 1Mhz and 1GHz, as shown in the Figure 29 [129]. This corresponds to the ISM band 868.3MHz in Europe, China and to the 315MHz in USA, Canada and Japan. 1 A white paper [128] raises awareness of the problematic of interference in the 2.4 GHz band.

61 2 Wireless Embedded Systems Powered by Energy Harvesters 61 The second important parameter influencing the radio design of WESPEH is the transmission power. This parameter has a significant influence on the energy aspect of the device. Therefore, it is important to calculate the optimal transmission power of the energy autonomous system to reach the required TX range. This can be determined using the radio link budget and path loss in free space calculation. The equation of path loss in free space is: PathLoss= log F + 2log D Gtx + Grx [ dbm] (2.5) where F is the band frequency, D is the distance, G tx is the transmission antenna gain and G rx is the receiving antenna gain. The radio link budget is expressed: LinkBudget + = Ptx Srx + Gtx Grx (2.6) where the P tx is the radio power, S rx is the receiver sensitivity and G tx is the transmit antenna gain, and G rx is the receiver antenna gain. In order for a signal to propagate from the transmitter to the receiver, the sum of the transmitter power, receiver sensitivity, and antenna gains must be larger than the free-space path loss. By using these two equations, the optimum transmission power can be calculated as: P Srx + Gtx + Grx PathLoss (2.7) tx > A comprehensive model for transmission energy can be calculated using the equation shown: E N R [ P + ( α + β P )] tx( Prad, N) = Pstart Tstart + tx rad rad rad (2.8) where P start and T start represent the power and latency of radio startup, P tx the active transmission power, P rad the power radiated from the antenna, N the number of bits transmitted and R the radio bit rate. The α rad and β rad allow a linearized model for power amplifiers and end-to-end antenna losses. The energy of the receiver can be modeled as: N E + R rx( N) = Pstart Tstart + Prx NEdecbit (2.9) where P rx represents the active receiver power, E decbit represents the energy per bit required for decoding information [13]. Using these equations, the optimum range and optimum energy for WESPEH can be calculated and evaluated on the physical layer. Another important fact that needs to be considered in the context of radio platform

62 2 Wireless Embedded Systems Powered by Energy Harvesters 62 selection is the higher OSI communication layers (network, transport, session) of the radio protocol stack. Good practice in WESPEH systems is to switch on the radio as infrequently as possible. Various approaches in the higher OSI layers can make the communication more efficient by communication strategies supporting this rule directly in the protocol stack. As an example let s consider a scenario where two energy autonomous devices want to exchange information, but they are not synchronized and the radio interface has to be active only for the duration of data transmission and reception. A solution to this challenge can be the exchange of the information through a third party line powered device, which may act as a mailbox for intermediate storage of the information. In order to make the implementation of such a communication strategy easy, the information exchange sequence has to be directly supported by the radio protocol stack. The design effort of the WESPEH system can be significantly reduced if, instead of a proprietary radio platform, an existing short-range wireless standard is selected, where solutions exist for the energy autarkic communication problematic scenarios. Using an existing wireless standard ensures the WESPEH interoperability with other products using the same wireless standard. Frequency 2.4 GHz 868/915 MHz 315/868 MHz 2.4GHz 2.4GHz Modulation Minimum packet length GSK DQPSK BFSK ASK GFSK DSSS, FHSS, OFDM 4ms 2ms.6ms.7ms - - Data Rate 2-25 kbs 4 kbs 125 kbs.72-24mbs 1 15 Mbs Interference Risk Very high Medium Low High Very high Approximate outdoor range (max) Approximate indoor range (max) 75m 1m 3m 1m 25m 1m 3m 1m 3m 7m Transmission power 2dBm 2dBm - 6dBm 2dBm 2dBm Receiver sensitivity -92dBm -94dBm -97dBm -7dBm -8dBm Chanel access algorithm Energy autonomous Tx and Rx concept Power requirement CSMA/CA No CSMA/CA No None or CSMA/CA Yes, SmartACK TDMA CSMA/CA Moderate Moderate Low High Very high No No Table 7 Summary of wireless standards 2 The comprehensive summary of actual short-range wireless standards and their properties is shown in Table 7. If there is no compatibility requirement, it is recommended that prototypes for various radio platforms be built. By summarizing and evaluating the radio 2 The table was created in 29. Therefore, recent protocols as 6LoWPAN are not described. In addition, some parameters could be subject to change, because of recent further developments in existing wireless standards.

63 2 Wireless Embedded Systems Powered by Energy Harvesters 63 platform properties according the parameters radio band, link budget and stack features, the appropriate rating value can be assigned Microcontroller platform Following the RF interface, the microcontroller has the second highest power consumption in a WESPEH system. In a generic embedded system, the microcontroller (MCU) platform choice is usually dictated by the: price functionality peripheral interface memory interface performance requirements power consumption For a WESPEH application, the major selection criteria of the MCU is the power consumption. There is a common misconception that MCU power consumption is governed solely by the operating voltage and current consumption of the circuit. This is only partially true. There are various factors which affect the power consumption of the circuit. In order to be able to determine the exact power requirements, it is necessary to understand where power is consumed in the circuit. Microcontrollers are built on digital CMOS logic. There are two types of power consumption in a CMOS circuit: Static power consumption Dynamic power consumption CMOS devices in general have very low power consumption, which is the result of leakage current. This power consumption occurs when all inputs are held at some valid logic level and the circuit does not change states. The static power consumption is influenced by supply voltage, temperature and integrated circuit process technology. The dynamic power consumption of a CMOS circuit is the consumption of power when a logical block or a clock signal changes state. This power consumption is defined in equation as: 1 2 P dyn = fccloadvdd (2.1) 2 where P dyn is the dynamic power consumed by the circuit, f c the clock frequency, V dd is the voltage of the circuit, C load is the capacitive load. The overall power characterization of the MCU equals to P dyn in addition to the leakage current of the digital logic and the current consumed by analog modules in idle mode. As we can see from the equation of P dyn several factors affect the power consumption of the microcontroller. These factors are strongly dependent on various properties of the microcontroller. When evaluating the MCU power needs, it is important to analyze these properties and to understand how they influence the factors in the equation. In the next

64 2 Wireless Embedded Systems Powered by Energy Harvesters 64 few sections, the power-relevant MCU properties are briefly listed and discussed. Supply voltage Often current consumption is the only factor considered when describing the power consumption of the microcontroller. The power is the factor of operating voltage multiplied by current consumption. Power consumption is proportional to the square of the supply voltage. The lower the supply voltage of the microcontroller is, the better the power perspectives are. Clock domains and frequency The more gates which are toggling with higher frequency, the higher the power consumption is. A method to achieve power savings in MCU is through clock gating. Clock gating stops the clock signal to a certain portion of MCU logic. Modern MCU has several clock domains, thus the whole system does not run on the same frequency, and not every gate toggles with the same speed. Domains with slower clocks consume less power, but on the other hand, the execution of tasks in these domains takes longer. When selecting MCU, the possible clock domains and their frequency must be considered. Architecture complexity and register width The number of peripheral interfaces, memory size, address bus width, register width has a certain influence on power consumption. Although in theory the more gates the MCU has the higher the leakage current should be, we cannot take this as an implicit assumption. The chip manufacturers keep increasing the efficiency of the microcontroller design by improving synthesis techniques and process technologies. This makes it possible that newer architectures with more complex structures can have lower power consumption than an older MCU with less complex architecture. It is also a myth that 8- bit MCU architecture has smaller power consumption than 16bit or 32bit MCU architecture. In fact, the program code for an 8bit architecture can be significantly larger than for 16 or 32bit. In several applications, it is necessary to process more data than the architecture width, so every time an integer variable is used the compiler has to generate extra code. The larger program code takes longer to execute, thus this means an increase in power consumption. Instruction set architecture The instruction set architecture has an influence on the power consumption. Generally, microcontrollers with RISC architecture have lower power consumption, because RISC architecture is not as complex as CISC. RISC microcontrollers have fewer instructions and fixed instruction length. The pipeline is built up with fewer transistors and this influences both the dynamic and static power consumption of the microcontroller. The architecture also has an effect on the execution speed. RISC architectures typically execute instructions in a single clock cycle instead of dividing the clock. Power features Microcontrollers offer several features to scale power consumption such as adjustable clock frequency, voltage scaling, different power down modes, and controlling the on/off

65 2 Wireless Embedded Systems Powered by Energy Harvesters 65 status of peripherals. A common method of power consumption reduction is static power management. In this mode, the application puts the microcontroller into a sleep state where most of the blocks are powered down and have no clock signal. Only an ultra-lowpower timer or some I/O peripheral are active. In such a case, the power consumption is near zero and only the active peripherals and the leakage current consume power. Dynamic voltage scaling is another method used to reduce energy consumption of the microcontroller. Dynamic voltage scaling adjusts the power and clock parameters of the system on the fly [18]. However, reducing the supply voltage may require a decrease in clock speed and an increase in task execution latency. When selecting the microcontroller for WEPSEH all these feature sets have to be considered. Latency times Time means energy, thus upon selecting a microcontroller, the latency times of the MCU have to be considered. There is always a certain delay with MCU power ups caused mainly by the oscillator startup latency. Mechanical resonant devices, such as crystals and ceramic resonators, can take several milliseconds to stabilize. RC oscillators in contrast provide fast startup, but generally suffer from poor accuracy in relation to temperature and supply voltage. Further, it is important to take into account the latency times for peripheral startup, power mode change, and memory access. RF interface An integrated RF interface in the microcontroller can significantly reduce the overall power consumption caused by the lower overhead of the data preparation and communication with an external RF chip. An RF interface built up of discrete components, or a two-ic solution, has several disadvantages in comparison to an integrated solution. The microcontroller platform rating value is assigned based on the MCU properties analysis. Although the rating value suggests which MCU is more appropriate for the WESPEH design, it is a good practice to build at least prototypes with two different microcontroller platforms Price aspect The price of WESPEH devices must compete with battery powered or even with wired solutions. Often WESPEH designs remain in the prototyping phase and cannot be developed as an end product, because they violate the price aspect. Ambient energy powered systems become economically feasible if the costs of the devices, together with energy converters, are comparable to battery-powered devices for similar performance of the whole system. That is why the price aspect plays an important role during the system design. The price aspect is affected by the following factors: Table of BOM (Bill of Material) is the hierarchical list of materials required to produce the system, showing the quantity of each required item. Other information such as scrap factors may also be included in the BOM for use in materials planning and costing. This constraint is strongly dependent on the

66 2 Wireless Embedded Systems Powered by Energy Harvesters 66 components aspect. Production price indicates the complete price of the device production, including component assembly duration, production tests and programming time. This factor is strongly influenced by the components aspect. It is also influenced by the microcontroller platform, since the programming time is a critical factor in production. As an example, if one second production time costs.1, in the case of producing 1 million devices, the difference between one or two seconds programming time means a difference of 1 of lost profit. Development time and number of design cycles indicates how many development cycles need to be completed until the device is stable and can be qualified for mass production. The WESPEH development time is not directly proportional to the complexity of the system. The price aspect rating is straightforward. The higher the price calculation of the prototype, the lower this constraint is rated SW Aspect The SW Aspect constraint is strongly dependent on the WESPEH operating system. Since the majority of the thesis discusses the SW aspect in detail, I will not analyze this constraint further. The constraint is assigned a rating based on benchmark results as discussed in chapter Prototypes quantification In order to do determine which prototype has the best chance for a successful design, the prototypes have to be quantified. This is done in two steps: 1. prototype rating using decision matrix 2. constraint group equilibrium determination The prototype quantification process is the following. The number of prototypes to evaluate is i, the number of constraint groups are designated as j. Each evaluated prototype constraint group is assigned a rating value designated as x ij. From this we can define the decision matrix as follows: X ij x = M xi 11 1 L L L x 1 j M x ij where x ij {1,...,5 } (2.11) where x ij is the prototype design constraint rate. 1 is the lowest rate and 5 is the highest rate. As the design constraint groups can have varying importance, dependent on the application, each group is assigned a weighting factor satisfying the condition that is:

67 2 Wireless Embedded Systems Powered by Energy Harvesters 67 n j = 1 w = 1, w (2.12) j j Where w j is the weight of the constraint. The prototypes summary rate designated as is calculated using the weighted average of the constraints in following way: R i Ri = n j= 1 w j xij (2.13) where w j is the weight of the constraint and x ij is the rate of the prototype design constraint. As we can see from the discussion in previous chapters, design constraints place an overall boundary around the system design process. All these parameters are tied together and for a successful design, they must be properly balanced. Although prototype design with unbalanced constraint groups may fulfill all the core requirements of the system, it is an indication that over the long term, the selected choice may lead to failure. We can demonstrate this fact with a complex example. Let s consider the design of WESPEH window contact described in chapter Let's consider a design of WESPEH solar window contact. The core requirement of the device is appropriate radio signal strength to cover an area of 3 meters. The prototype design for this purpose requires energy for the transmission with 6dBm signal strength. A solar cell with the size of 5cm 2 could deliver the right amount of energy but the core requirement of unobtrusive hardware limits the size of the cell. The selected microcontroller power requirements are relative high (still in target range), but it has significant RAM, FLASH and I/O reserves. One solution for reaching the design objective is to exchange the type of microcontroller with lower power consumption. The microcontroller with lower power consumption has less RAM, FLASH and no I/O reserves. Naturally microcontroller is rated lower. Although the constraints rating is not balanced, with the new microcontroller the power consumption is in the target range. The decision is made to use this prototype for the final device design. As the project enters its final phase integration test shows that at high temperature the microcontroller A/D converter is not linear. This issue could be easily fixed using a software workaround with a conversion table. Unfortunately the new microcontroller has no FLASH reserves to implement this solution. The design fails and a new development cycle has to be undertaken. The optimal solution in this case would be instead changing the microcontroller to adjust the radio constraint. One possibility would be to introduce a better antenna thus leading to a lower transmission power need. This would fulfill the power requirement. The unbalanced design constraints is an indication for a not optimized design. One may argue that requiring balance from a WESPEH design is not possible, since changing one of the constraints in a positive manner probably has a negative influence on

68 2 Wireless Embedded Systems Powered by Energy Harvesters 68 another constraint. Example: selecting a microcontroller with higher clock rate would mean higher power consumption. When changing a design, it is important to consider evaluating all the parameters and rating the constraints again. As in this example with higher processor clock rate, the calculations will be performed faster, so even with increased power consumption, the device will require on average the same or even less energy. Although the constraint balance requirement was demonstrated only for theoretical example, my experience in the design of WESPEH shows that unbalanced constraint design has a higher risk factor than balanced constraint design. From these facts, we can derive the following statement: Definition 2.2: A WESPEH design is successful when the solutions to all constraint groups are in equilibrium. For the visual determination of the constraint group equilibrium, the rating values represented in a radar chart are useful. For demonstration purposes, Figure 3 shows the evaluation of two WESPEH prototypes. Prototype 2 has as overall better rating, except for the components aspect which is very low. Prototype 1 has a worse overall rating, but offers a solution that is in complete equilibrium with all design constraints. In this case, if there is no solution to adjust the component aspect constraint rating of Prototype 2, it would be less risky to use Prototype 1 as the reference design. When several prototypes are shown in a radar chart, it is difficult to evaluate the equilibrium state. For this reason, to determine which prototype is the closest to the equilibrium state, we define a balance rate calculated using the standard deviation of the rating values in the following way: s i = n j= 1 w ( x j ij xi ) 2 (2.14) where w j is the weight of the design constraint, x ij is the rate of the design constraint, is the average rate of the prototype i.

69 2 Wireless Embedded Systems Powered by Energy Harvesters 69 Figure 3 Equilibrium demonstration The quantification of the prototypes is performed by the evaluation of the summary rate and the balance rate. The significant evaluation parameter is the summary rate. The prototype with the highest summary rate is taken and the balance rate is evaluated. The following results are possible: R R R k k k > > > R, l R, l R, l s s s k k k > s l = s l < s l (2.15) where R k and R l is the prototype summary rating, and s k and s l is the balance rate of prototype k, l. In case the summary rate between two prototypes is higher, but the balance rate is lower, this indicates a problem. Although the prototype is rated the best, one design constraint represents a risk. In such case, there are three possibilities: the prototype is redesigned in a manner to have balanced design constraints. the prototype with lower summary rate but better balance rate is taken. in case the unbalanced prototype represents no rational risk, the prototype with the highest summary is used. We will demonstrate the prototype quantification by an example. The aim of the development is to create a WESPEH transmitter powered by an electro dynamical energy harvester. Three prototypes are created with the following parameters: Prototype 1 is created with an 8bit P12F629 microcontroller. The radio platform

70 2 Wireless Embedded Systems Powered by Energy Harvesters 7 is developed using analog components and an SAW resonator. The software is written in assembler and the radio data is modulated in real time using the microcontroller I/O port. Prototype 2 is created using a 16bit MSP43 microcontroller. The radio platform is developed using a CC115 SoiC transceiver. The microcontroller is communicating with the transceiver transferring the radio data through the SPI interface. The software is written in C. Prototype 3 is created using an 8bit EO3I microcontroller with an integrated radio transceiver. The SW is written in C. Energy aspect Price aspect Radio Platform MCU platform Software Aspect Component aspect Summary rating (R) Balance rate (s) Weight 2% 2% 15% 2% 15% 1% 1% - Prototype ,95 3,65 Prototype ,6 2,73 Prototype ,25 1,15 Table 8 Decision matrix fo three prototypes The rating of the design constraints is shown in Table 8. Prototype1 has the best energy budget and is also the cheapest solution. On the other side, the development of the radio platform requires many analog components which raises the risks to production stability. The SW is written in assembler and the radio signal is modulated real time. Future enhancement of the software would destabilize the software and would trigger a new process of HW evaluation. This is the reason the SW constraint has the lowest rating. Prototype 2 is developed with a fast 16bit micro-controller platform. The energy aspect is not as well rated as for Prototype1, but it has a better rating than Prototype3. The two chip solution is the most expensive one. Viewed from the component aspect, the two chip solution requires less analog components. Still, the transceiver chip frequency synthesizer requires calibration in production, therefore it is rated low. The SW is written in C, thus this software aspect is rated better than for Prototype1. Prototype3 has in average good energy consumption and a decent speed 8bit microcontroller. The radio performance is lower than Prototype2, but from the price aspect this solution is cheaper. The components aspect has the highest rating, since this prototype is a one chip solution with only a few analog components. From the decision matrix we can see that Prototype2 has the highest summary rate. When we look at the radar chart, we can see that Prototype3 is the closest to the equilibrium and this is also indicated by the balance rate.

71 2 Wireless Embedded Systems Powered by Energy Harvesters 71 Figure 31 Quantification evaluations of three prototypes Prototype2 has a badly rated component constraint since the production requires calibration. Also, the price is higher than for Prototype3. The calibration during production represents a potential risk, while the calibration parameters could get lost or could be incorrect. Although Prototype3 has a lower rating, on average it is better balanced and fulfills all the core requirements. In such a case, the best solution is to choose Prototype 3 for the design.

72 2 Wireless Embedded Systems Powered by Energy Harvesters Conclusion This chapter has introduced Wireless Embedded System Powered by Energy Harvester. The term and device category Wireless Embedded System Powered by Energy Harvester was defined, and the architecture and requirements of these systems were discussed. It was explained why there is a need to introduce a new category of devices and why WESPEH doesn t fall under the category of Wireless Sensor Networks. The chapter discussed the powering possibilities of WESPEH with the help of energy harvesting, and gave an overview of the amount of energy various energy harvesters deliver, and the average conversion efficiency. For better understanding WESPEH, several use case application scenarios were presented and discussed. Based on these scenarios, the design challenges of WESPEH was discussed in detail. The chapter defines a new design methodology based on rapid prototyping and constraint analysis. Various constraints group challenges are briefly discussed, and examples of the quantification methodology of the prototypes are explained. To extend the design methodology in detail, a comprehensive analysis of the constraint groups is required by presenting a detailed solution. This task would require the work of experienced researchers in different fields and is beyond the focus of this thesis. We have several years of experience in the field of SW. Consequently, in the next portion of research we will focus on the SW aspect of the constraint group. Significant portions of these chapters have appeared in various publications [1][2][4].

73 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 73 3 OPERATING SYSTEM FOR WIRELESS EMBEDDED SYSTEMS POWERED BY ENERGY HARVESTERS We will focus on the challenges of the SW aspect. The architectures of various lowpower operating systems are presented and analyzed. Based on this analysis and application scenarios described in chapter 2.4, requirements, design constraints and architecture of a WESPEH OS is defined. Based on the WESPEH OS definitions, an operating system DolphinAPI is implemented. The first version of the operating system is implemented on the EO3I HW platform. In order to prove the implementation feasibility using a benchmark study, TinyOS is ported to the EO3I HW platform and the EnOcean radio protocol stack is implemented. 3.1 WESPEH OS Requirements Based on the application scenarios described in chapter 2.4, we lay down the core requirements for WESEPEH operating systems Abstract the power management Energy is one of the most critical design constraints in a WESPEH system. As discussed in chapters 2.3, the system has to work with very limited energy resources, therefore a major requirement for the WESPEH operating system is the efficient control and handling of power resources. In order to better understand the requirements-placed power management of the operating system, three power scenarios will be presented. These scenarios are typical problems the software has to deal with in a WESPEH system Scenario 1: Monitor power level The highest energy consumption of the WESPEH system is the radio interface, as discussed in chapter The energy consumption of a WESPEH system can vary greatly, therefore the WESPEH software must always monitor the system energy resources, especially during radio communication. An example of highly varying energy levels is in mechanically powered devices, for instance, in the finger press powered emergency button discussed in chapter The reason is that the variation of the actuation force is not only dependent on the strength of the person pressing the button, but also on the angle of the actuation. That s why before each transmission or reception of a packet, it must be ensured that there are enough energy reserves to perform the radio operation. Failure to do so can lead to erroneous states, as in the following scenarios: during the transmission, the critical power level is reached. transmission of data is interrupted. since there is not enough power available, the CPU shuts down. without CPU control, the RF front-end performs an uncontrolled powerdown. this may result in spurious emissions.

74 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 74 Considering an emergency button application used in a hospital environment, the emission of spurious signals could even lead, in the absolute worst case, to fatal consequences, because the signal could influence the functionality of other medical equipment. This leads to the conclusion that software power level monitoring in such scenarios is a must. The only exception where this requirement does not have to be implemented in the software, is in case the wireless interface has a dedicated HW. This HW performs the monitoring of the power level and initiates a controlled shutdown of the RF module, in case of critical energy levels Scenario 2: Storage capacitor control Although some WESPEH are powered by energy harvesters delivering energy periodically, as discussed in chapter 2.3.1, typically ambient energy is not always continuously available to power WESPEH applications. For example, light powered WESPEH devices discussed in the scenarios of intelligent buildings and homes in chapter have to ensure enough energy reserves for the period after sunset when no light is available. Consequently, nearly all WESPEH devices are equipped with long term energy storage capacitors (for instance goldcaps, supercaps or ultracaps). The disadvantage of long term storage capacitors is that they need a long charging time, thus when all the energy reserves are exhausted, the system will need a long time to start. Long startup time will cause the system to react to events with latency, and this would violate the real time requirements. Therefore, many WESPEH devices are equipped with two types of energy storage: a long term and a short term storage capacitor. In order to start the WESPEH system fast, the short term storage capacitor is used, which charges very quickly. Later, the system is switched over to the long term storage. During this time, the short term storage capacitor is reloaded from the long term storage. One of the WESPEH software tasks is the switching between the long term and short term storage capacitors. The switching between the capacitors in real time has to be ensured, thus the operating system has to support this mechanism. Furthermore, some energy storage devices such as PAS capacitors, should not be allowed to be discharged completely, otherwise their lifetime and maximum charging capacity is decreased [155]. In this case, the software has to ensure that whenever the critical energy level is reached, it will power off the system correctly Scenario 3: MCU power management control After radio interfaces, microcontrollers have the second highest power consumption in a WESPEH system. By controlling the microcontroller power modes, significant energy can be saved. Controlling the power features of the microcontroller can ensure energy glitches are bridged. Every time the energy level of the system is nearing a critical level, the application must be informed about this state. This situation in an energy autonomous device may be a temporary event caused by a glitch in the energy source. In such cases, the software may put the system into a sleep mode, reduce the MCU clock speed or deactivate interfaces in order to save energy. Another case of using the MCU power management is during scheduling. When all the tasks are idle, the operating system has to put the device into power saving mode without the interaction of the application. When a HW event is triggered, the operating system has to be able to recover from this power saving mode. To perform these operations, the MCU power control mechanism has to be

75 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 75 abstracted. From these scenarios, we can determine the following requirements to be used for the implementation of the WESPEH operating system power management module. Power management module requirements: abstract the microcontroller power modes provide interfaces to control the microcontroller power resources provide interfaces to switch between various clock domains provide interfaces to monitor energy resources. signal critical power events to the application Abstract wireless interface and implement wireless protocol stack A basic requirement of a WESPEH operating system is the abstraction of the wireless interface and to make the implementation of wireless protocol stacks possible. As discussed in chapter , for successful WESPEH deployment, the precondition is that devices communicate with the same protocol stack. The operating system has to implement at least the three bottom OSI layers of the communication protocol stack. Implementing the protocol stack on the application layer is not a solution, because the resource usage on the application layer cannot be effectively optimized. From this can be derived that the operating system must fulfill the real time requirements of the communication protocol. The low level network communication has to run parallel to the application, and the operating system must ensure that no lost packets are caused by software racing conditions. The application must be able to initiate radio communication seamlessly using the interfaces provided by the OS. Radio interface consumes the largest amount of energy in a WESPEH system, therefore during the implementation, the focus must be placed on code optimization Thin resourced After the radio interface, the microcontroller consumes the most power in a WESPEH system. The usual objective of WESPEH design is to select ultra-low power microcontrollers, with good power saving features. As discussed in , the number of logic gates in a microcontroller has an influence on higher current leakage. Furthermore the number of peripheral interfaces, memory size, address bus width, memory size and register widths also have a certain influence on the power consumption. Therefore the ultra-low power microcontrollers are usually thin resourced. To prove this fact, Table 9 shows the resource analysis of five microcontrollers. These microcontrollers were used in various applications scenarios discussed in chapter

76 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 76 Architecture Register Width RAM (bytes) FLASH (kb) STACK (bytes) Integrated RF CPU Speed (MIPS) PIC12F629 PIC16 8bit (8x13) No 5 PIC16F913 PIC16 8bit (8x13) No 5 EO3I 851 8bit Yes 2.6 MSP43F2131 MSP43 16bit No 16 CC bit Yes 8.25 Table 9 Resources of microcontroller used for WESPEH in application scenarios From the Table 9 we can conclude that an average microcontroller suitable for WESPEH has the following average resources. Resources Architecture 8 bit RAM 2kB FLASH 36kB STACK size 176 bytes MIPS 7.3 Table 1 Average resources of WESPEH microcontroller From this fact we can derive the requirement that the operating system has to be thin resourced. The operating system must have a low footprint and must be executed on a microcontroller with the average resources showed in Table 1. Furthermore, there should be enough RAM and ROM resources left for the application execution Modular From the requirement 3.1.3, we can conclude that the operating system must have a modular architecture. The OS may provide several sets of functionality for diverse applications. It may implement different communication interfaces like SPI, RS232, I2C, various scheduler techniques and protocol stack algorithms. However, not all of these interfaces are used in the same application. Due to the small footprint requirement, it is important that the OS is modular and only the objects that are used by the application are stored in the memory Hard real-time From the application scenarios described in chapter and from the power requirement scenarios described in chapter the 3.1.1, the following hard real time events typical for WESPEH can be derived:

77 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 77 power level sinking under the critical level. request of processing of incoming radio packets. transmission of radio packet with a critical information. clock stabilization signal. wakeup signal through rapid increase of power. switch between short term and long term storage is required. processing peripheral request. timer overflow. The operating system has to ensure an on-time reaction to critical events and has to pass the events to the application Parallel tasks execution The operating system must make it possible to execute parallel tasks on the system level. In a WESPEH system, many operations must be executed in a parallel manner. For instance, a self-powered controller described in chapter can have the following tasks executed in parallel: monitoring the system power level. receiving incoming packets. transmitting the control signal to the attached system. The OS task execution must be non-blocking and the task with hard RT requirements must be assigned the highest priority. A cooperative operating system is not acceptable for a WESPEH system, since here tasks could monopolize the whole system. Another reason for this requirement is the radio protocol stack support. Since the radio has the highest amount of energy consumption in a WESPEH system the protocol stack must be implemented in the operating system and executed parallel to the application. This ensures maximum control and utilization of the wireless interface Remote configuration Wireless sensor operating systems require dynamic program execution. This is understandable because the core concept of wireless sensor networks is to build a network infrastructure composed of several nodes. Manually reprogramming and restarting large amounts of devices is impossible. WESPEH applications are different. WESPEH devices usually work standalone, and they use their wireless interface for communication with a line-powered gateway. They do not need dynamic application runtime, but rather need the possibility to have a remote parameterization interface. Let s consider the pairing of the light controller from the intelligent office application scenario - described in chapter with the light switch. When the light controller is deployed, the mechanically powered light switch ID is paired with the light controller in the following way: learn button on the controller is pressed. controller enters learn mode. at same time, packet is transmitted with the light switch.

78 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 78 ID of the light switch is stored in the controller. light controller is installed in the ceiling. Let s consider that after a few months another light switch needs to be installed in the office. In order to couple the switch to the light controller, the learn button would have to be pressed. Instead, using a remote configuration interface, the ID can be transmitted to the controller through the air. To perform this procedure, an operating system can provide the possibility of re-configuring the application remotely through the radio interface. This functionality of the configuration can be implemented in the application, but the handling of remote management communication has to be supported by the OS in order to work with self-powered receivers, and to ensure interoperability between systems Hardware abstraction Question may arise, such as why does a thin resource operating system need platform independence? Let s consider the task of designing software for a heating system control, as is discussed in the application scenario in chapter Even though we are talking about energy-autonomous devices, the system is complex enough to use high level software methodology approaches. Different WESPEH are running on different microcontroller platforms adjusted for the energy requirements of the energy harvesters. Thus, it is important that the operating system implements an HW abstraction layer that ensures the operating system s platform independence. Platform-independent software is a challenging requirement. Providing platform independence for an OS for WESPEH is a much more difficult task than for desktop computer based operating systems. The reason is the great variety microcontroller architectures available on the market. Commercially available desktop computer operating systems have made platform selection easier, because the range of available processor families used in commercial desktop computers is not as wide as the processor architectures used by embedded systems. Despite this fact, commercial operating systems on desktop computers support only a few processor architectures. The most popular commercial operating system Windows runs on two processors architectures, x86 and DEC Alpha processor [47]. MacOS, the operating system for all Apple desktop computers, was supported only by the PowerPC and Motorola 68 processor architecture until 26. Oktober 27. After the Mac OS X Leopard release the x86 processor architecture is also supported. The most flexible and platform independent desktop operating system is Linux. Thanks to its open source philosophy, the Linux kernel was ported to support several architectures beginning with PowerPC, through Sun Sparc, HP PA and including the x86 architecture. WESPEH OS has a much greater choice of processor architectures. On the top of this, some of the processor architectures have various architecture implementations from different chip vendors. Usually these architecture implementations differ mostly for the peripherals. However, there are also implementations where the architecture is not 1% compatible with the genuine chip definition. This can happen either because the vendors introduce new features, such as extending the memory architecture, or providing DMA blocks, or simply because they don t stick to the specification. A very good example for this is the Intel 851 processor architecture, which was implemented by several vendors and now exists in hundreds of different variants [86] not all of them conform to the

79 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 79 genuine Intel 851 specification. Although realizing platform independence is a challenge, hardware abstraction is a difficult requirement for a WESEPH OS. This ensures that the most optimum microcontroller in the design is selected for the WESPEH system, and thus the OS can easily be migrated to the new HW platform. 3.2 Existing OS Analysis This chapter analyzes ten different operating systems. The primary aim of this chapter is to give a comprehensive overview of all thin resourced operating systems. A further objective is to find an operating system that fulfills all the requirements stated in the previous chapter, thus making it an OS appropriate for running on a WESPEH platform. The analyzed systems are divided into two groups. The first group incorporates embedded operating systems. The second group embodies operating systems for wireless sensor networks Embedded Operating System There are various embedded operating systems. A comprehensive analysis of all the systems would not be effective, since most of the systems are far too complex to run on a WESPEH platform. In order to reduce the number of the systems that must be analyzed, the focus of this chapter is on embedded operating systems that offer direct support for the 851 platform. The genuine Intel 851 processor architecture is very thin resourced and contains low number of logic gates, thus feasible to build a WESPEH HW platform. Furthermore five from analyzed WESPEH application were built on a microcontroller with an 851 architecture FreeRTOS FreeRTOS [3][31] is a GPL license based, portable, open source mini operating system. The OS supports both preemptive and cooperative scheduling. The development of application is performed on a cross-development platform on Windows hosts. The OS supports queues, binary semaphores and mutex implementation with priority inheritance. The OS structure seems to be very portable. It officially supports 23 HW platforms, among them the 851F12 device from Silicon Labs, based on 851 Intel architecture. The main disadvantage of the OS is the stack constraint on tasks. Each real time task in the FreeRTOS requires its own stack. A limited resource microcontroller like the 851 only allows a stack to reside in the 256 bytes of internal RAM. When a task is swapped, the FreeRTOS scheduler copies the entire stack from the internal RAM to the external RAM. The genuine Intel 851 processor external RAM access goes through the processor external ports. These ports have a shared data and address bus, therefore external RAM operations are very time consuming. Fetching 1 byte from the XRAM can take up to 4 CPU cycles, which in the case of an average 5 bytes stack copies per task would mean 2 CPU cycles. There were no further references about how much time it takes for the rest of the task context switching. Moreover, the operating system has no support for power management. The memory requirements and the lack of power management makes the OS unsuitable for a WESPEH platform.

80 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters RTX51 RTX51 [32] is a real-time commercial operating system from the Keil company. The operating system is distributed in two versions: RTX51 Tiny and RTX51 Full. The applications for the OS are developed using ANSI C, and compiled with the Keil C51 compiler. The Keil C51 compiler offers direct support for the operating system features, and extends the ANSI C with the operating system specific keywords for task execution and control. A comprehensive overview of the operating system features and the difference between RTX51 Tiny and Full is shown in Table 19 in Appendix C. The scheduler of the operating system features priority-based preemptive multitasking. The task switching latency is relatively low. The RAM and ROM footprints are acceptable for the WESPEH platform. The operating system is distributed as a pre-compiled library. The main drawback of the OS is the lack of support for power management. The OS is distributed in closed libraries and is intended to be used for specific 851 targets. Consequently, it is not possible to extend its functionality for effective utilization of extra WESPEH HW resources, such as radio interface, for instance. Furthermore, implementation of a radio protocol stack in a closed operating system is not possible. The operating system has no support for power management. The aforementioned disadvantages make the OS unacceptable for usage on a WESPEH platform Salvo Salvo [29][57][58] is a commercial operating system from the Pumpkin company. It supports 851 and its derivates, but it was ported to 9 different HW platforms. Salvo is a cooperative multitasking RTOS with full support for event and timer services. Multitasking is priority-based with fifteen priority levels. Tasks sharing the same priority are executed in a round-robin fashion. The cooperative tasks do not use their own stack space in memory, because the task switching occurs at the application level. Salvo has modest ROM and RAM requirements. It is distributed as a precompiled library the same way that RTX51 is and the library is compatible with the Keil C51 compiler. The OS has no power management support. Since the OS is a closed library, it has the same limitations as RTX51. Extending the system for efficient support of WESPEH specific HW is not possible. Moreover, the cooperative type of scheduler may introduce a problem for the implementation of a radio protocol stack which demands real time reaction to events. The closed structure and the cooperative scheduler, lack of power management and closed library make the system not appropriate for usage on WESPEH platforms Operating System for Wireless Sensors Operating systems for wireless sensor network nodes are typically less complex than embedded operating systems. The design of these systems focuses on wireless sensor networking capabilities, and in most of the system architectures, the power management is part of the kernel and plays an important design role. Thus, these systems would be a much better fit for the requirements of a WESPEH platform. We have analyzed seven different operating systems.

81 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters VROS VROS [61] is a light-weight multitasking operating system based on message queues. The operating system was developed in China as a part of a research grant. The interesting thing about the VROS architecture is that the OS supports no tasks, only message handling. The tasks are represented as messages, so the message is the basic scheduling unit. Any operation with a resource must be submitted to message scheduling. There are two kinds of messages in VROS: event and data messages. The messages can have different priorities so the scheduling is capable of preemption. An additional unique feature among WSN OS is the support of a deadlock prevention mechanism. The paper presents benchmarking results where TinyOS and SOS are compared with VROS. In the [61] benchmarking measurements, macro benchmarks are executed where different nodes are propagating messages in a sensor network. The benchmark result represents the delay of the message propagation. During the benchmarking application, the CPU idle and active states are also measured. The developers claim that the VROS performance is identical to the TinyOS. The message-based architecture of the operating system seems to be similar to the TinyOS event-based structure. The operating system has no power management support. The project looks promising and its HW resource requirements would be acceptable for WESPEH Platform. Except for the referenced paper, it is not possible to find any more information about the project Contiki Contiki [59][62] is an open source, highly portable multi-tasking operating system implemented in ANSI-C language. It was designed to be used for both generic purpose embedded systems and wireless sensor networks. Contiki has a very interesting and unique architecture. It is a hybrid architecture operating system, which combines the benefits of both event-driven systems and preemptive threads. The operating system kernel is event-based. The kernel does not provide a hardware abstraction layer, but lets the application communicate directly with the hardware. There are two types of events: asynchronous and synchronous. At the moment an asynchronous event happens, it is queued by the kernel, and later propagated to the process when it becomes active. Synchronous events work the same way, with the difference being that the process to which the event is targeted is scheduled immediately. In addition to the events, the kernel provides a polling mechanism for high priority events that are scheduled between each asynchronous event. Processes operating near the hardware uses this polling mechanism to check the HW device status. To avoid racing hazards, events cannot preempt each other. Another very interesting feature is that the Contiki kernel never disables interrupts, therefore interrupt handlers are not allowed to post events. Instead, the kernel provides a polling flag to request a poll event. The flag provides interrupt handlers with a way to request immediate polling. To enable the real time aspect of the operating system, Contiki supports preemptive multitasking implemented as a library on top of the kernel. The library can be optionally linked with the application. The multitasking is implemented using a timer interrupt that saves the processor registers on the stack and switches back to the kernel stack. To enable this functionality, the library has a HW platform specific part. The main difference between Contiki and the other analyzed operating system is that Contiki supports application loading using a run-time environment. The applications are

82 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 82 loaded into the system by the program loader. Either the application binaries are transferred to the device by the communication stack implemented in the OS, or they are programmed directly. Contiki has no support for power management. Instead it allows the application to decide when to power down the system. Contiki has support for several libraries. It has support for IPv4 and IPv6 communication stack, and implements VNC and terminal services. The Contiki was ported to several HW platforms. Contiki is a very interesting lightweight operating system, but its architecture, code structure, complexity, ROM and RAM memory requirements are beyond the capabilities of most WESPEH platforms Mantis Mantis [63][64][65] is a traditional preemptive, multi-threaded,open source operating system. The aim of the Mantis designers was to create a lightweight operating system motivated by the UNIX architecture. Mantis has a UNIX-style round-robin scheduler with priority levels. The thread time slices are customizable and by default they are set to 1ms. The context switch is based on a HW timer interrupt trigger. Since the thread table is allocated statically, there are a fixed maximum number of threads and a fixed level of memory overhead. By default, the system supports 12 threads. Each thread has its own stack, so upon context switch, the scheduler needs to take care of stack moving. Mantis also implements binary and counting semaphores. The HW abstraction layer is solved using device driver implementation, which has standard POSIX-style calls like dev_read(), dev_write() etc. Mantis has implemented partial power management that is initiated from the application layer. The kernel offers the mos_thread_sleep(period) function for the application thread similar to the UNIX sleep function. Before calling this function, the application thread must initialize the power-save mode. When the thread has nothing to process, it can put itself into a power-saving modus using the sleep command. Additionally the sleep function has a parameter that defines the duration of the sleep. Initially, all threads have the power-save mode disabled. When all the threads have put themselves in power-saving mode, the scheduler puts the CPU into a sleep mode and wakes it up when the earliest thread sleep deadline expires. In addition to the implementation of the Mantis operating system, the developers have provided several tools to bridge sensors running Mantis operating system to the Internet. They have built frameworks in which a virtual sensor node can be simulated when it is run on a PC. Mantis also supports dynamic reprogramming through a remote shell. Mantis implements the architecture of a traditional operating system on devices with low memory resources. It was not possible to analyze the system source code, because the project has been abandoned for a long time and the webpage [63] of the Mantis project is no longer active. Although the Mantis operating system is supposed to be lightweight and uses only 5 bytes RAM, its architecture is too complex to support the WESPEH platform SOS SOS [66][67] is a cooperative multitasking operating system supporting dynamic program load and priority scheduling. SOS was the project of a team of graduate students at the University of California in Los Angeles. The OS implements message handling and dynamic memory management. The operating system architecture is based on modules.

83 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 83 Instead of using tasks, the scheduler schedules these dynamic modules cooperatively. The specialty of the OS is that these modules can be loaded and unloaded dynamically without the need to recompile or relink the kernel of the operating system. This dynamic loading process is somehow different from the Contiki implementation where the application had its own memory space reserved for its execution. In SOS, the modules can be loaded into any memory area. SOS provides no memory protection for the modules. Instead, it represents different programming techniques such as typed entry points, and supporting processes such as primitive resource garbage collection, to avoid the problems of memory corruption. The operating system has no power management support. The main advantage, and most interesting property of SOS, is its dynamic module loading capability. This capability is very useful when deploying reconfigurable sensor networks. The code footprint is relatively high (around 19k on the ATMega 128L platform) compared to the features the OS offers. In addition, the cooperative scheduler architecture is a limitation for hard-real time event reaction which is a strict requirement for WESPEH OS. SOS is no longer under active development, but the source code is still publicly downloadable LiteOS The LiteOS [68][69][7][8] is an open source interactive, UNIX-like operating system for wireless sensor networks developed by graduate students from the University of Illinois. Its kernel features dynamic loading of application and dynamic memory management. The OS multitasking is thread-based, it implements both priority-based and round robin scheduling mechanisms. The round robin time slice for one task is 1ms. The operating system supports events by using callback functions. The LitOS has few special features that are not typical for wireless sensor network operating systems. It supports a flash file system called LiteFS through which the wireless sensor node running LiteOS can be seamlessly mounted to the root of the base station file system. The base station can be a desktop computer running Linux. Once mounted, the LiteOS node looks like a file directory from the base station. The operating system also implements a Unix-like shell called LiteShell. The LiteShell provides a Unixlike command line interface to sensor nodes. The shell runs on the base station and the LiteOS only implements the response to the translated messages delivered to the node through the wireless interface. Using this shell, the applications can be dynamically downloaded and executed. The kernel of the operating system does not support power management. LiteOS is an interesting research project. Unfortunately, there are not many details about how the kernel handles task switching. It was not possible to find any information on how time-consuming the context switch of a task is, how many task priorities are supported or how many bytes are required for each thread. The OS footprint is relatively large and the architecture is too complex to be used on the WESPEH HW platform Nano-RK Nano-RK [71][72] is a fully preemptive, reservation-based, real-time operating system from Carnegie Mellon University with multi-hop networking support, for use in wireless sensor networks. Nano-RK supports fixed-priority preemptive multitasking for ensuring that task deadlines are met. The system scheduler granularity is 1ms. The memory

84 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 84 allocation of the Nano-RK kernel is static. Nano-RK supports a very interesting power management technique in the form of virtual energy reservation.this technique considers that during the battery lifetime, the sensor can be woken up different numbers of times. Each time the sensor wakes up, the radio is switched on, sensors are sampled and data processed. After the process, the node goes back to sleep. The node consumes the most amount of energy during the active operations. If these wake-up cycles happen too often, the battery lifetime will be short. The operating system makes it possible to map a resource table of CPU, network and sensor reservations to a particular power level. The CPU is the energy the microcontroller consumes in the active state; the network is the energy consumption of enabled radio interface; the sensor is the power consumption of the enabled sensor interface. By modifying these resource reservation values, the mean energy consumed by each task can be varied. Using this mechanism, the operating system can set an upper limit on the number of wakeup accesses made by the sensor. The energy reservation values are set during the pre-deployment stage, thus they are static values. The Nano-RK ROM requirements would be acceptable for WESPEH. The task switching latencies would make it hard to fulfill the real time requirement, and the RAM requirements are too high for WESPEH platforms TinyOS TinyOS [27][28][81][82] is an open-source, component-based, event-driven operating system developed for wireless sensor networks. TinyOS 2.x is considered the standard operating system for wireless sensor networks. The initial development of TinyOS 1.x was done in collaboration between the University of California, Berkley and Intel Research and Crossbow Technology. In line with its open-source philosophy, since its release TinyOS has grown into an international consortium, the TinyOS Alliance. Several individuals, academic and commercial organizations are participating in the development of this project. TinyOS is an event-based operating system. Its architecture is layered and the operating system is based on components. Commands are non-blocking calls to lower level components. Event handlers are calls from lower level to upper level components. The task handlers perform the primary work. The operating system is built up by wiring the components together. There are two types of components: modules and configuration. Modules contain the actual implementation of the operating system functionality. Configuration wires the components together. TinyOS supports cooperative multitasking with no real-time guarantees. The tasks are atomic and they run to completion. The default scheduler in TinyOS has non-priority support. It is a FIFO based scheduler running on a single stack. Therefore, the task switching requires very few RAM resources, and because no context switch is realized, there is no extra CPU time needed. TinyOS scheduler also supports power management. If there is no task to execute, the scheduler puts the microprocessor into a sleep mode. From the sleep mode, the CPU can by woken up by a HW resource event. TinyOS has been developed in the programming language NesC [83][84]. NesC is an extension of the C programming language designed to support the concepts and execution model of TinyOS architecture. The result of the NesC compilation is a single ANSI-C file that is compiled by the target HW platform compiler. NesC interfaces are wired at compilation time, therefore callbacks in TinyOS are very efficient. In most C-

85 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 85 like languages, callback function addresses are registered at run-time with a pointer. This prevents the compiler from optimizing code across callback call paths. Since all the functions are wired statically in nesc, the compiler knows exactly what functions are called where, and can optimize the target source code [28]. On the other hand, the drawback of NesC language is its unusual architecture, which requires a relatively long learning curve. One of the strengths of TinyOS is its readiness for HW platform independence in comparison to all other analyzed OS. From all the analyzed operating systems, TinyOS architecture offers the best conditions for the support of multiple HW platforms. This confirms the fact that TinyOS 2.x was ported onto more than 2 different microcontrollers. The easy platform porting is enabled thanks to the layered hardware abstraction architecture. The layered architecture separates the code for each HW platform into distinct layers, as shown in Figure 32. The detailed hardware abstraction architecture is described in TEP2 [48]. Figure 32 Layered hardware abstractions in TinyOS TinyOS in its initial source code 3 does not support dynamic memory allocation. All the memory resources are allocated at compilation time. TinyOS source code is statically linked with the application code TinyOS. Compared with the other analyzed operating systems, it has a very small footprint operating system with a wide variety of platform support. The component-based architecture is unique and the wiring philosophy enables a high flexibility for the application development. TinyOS architecture and resource requirements are acceptable for the WESPEH HW platform. It has power management support and it s architecture enables the implementation of any radio protocol stack. The major weakness of the OS is it s cooperative scheduler. A poorly-designed application could easily monopolize the entire 3 Although there are libraries present which implement the functionality of malloc and calloc.

86 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 86 system, thus violating the hard RT requirement. Another disadvantage of TinyOS is that it uses the GCC compiler, thus thin resourced microcontroller cores, for instance the Intel 851, or PIC12F629 or similar cores, are initially not supported. Although several attempts were made as a part of research projects to port the OS onto the 851 platform, neither of these project results were included in the official TinyOS 2.x repository. More information about this shortcoming and possible solutions are described in chapter Conclusion The primary aim of this chapter was to introduce and analyze thin resource operating systems running on WESPEH. Several operating systems were analyzed. The contribution of this chapter is a detailed overview of existing low-power, small-footprint operating systems. A comprehensive summary of the operating systems analysis is shown in Table 11. The second objective was to find an appropriate operating system that is capabel of running on a WESPEH platform, fulfills all the requirements described in 3.1. The analysis showed that neither of the analyzed systems meets all these preconditions. From the embedded operating system group, all analyzed systems were directly supporting the 851 platform. Fixed task switching latencies was specified only for the RTX51. Almost all the operating systems task scheduler is based on cooperative task switching that violates the hard RT requirement. In a cooperative system, the application developer has to exactly calculate the maximum time slices which the application can run on. This can lead to a complex system architecture which does not effectively utilize the HW resources. The secondary problem of the analyzed systems was the closed library architecture of RTX51 and SALVO. This makes it impossible to implement any wireless protocol stack. The wireless sensor network operating system were more appropriate to run on a WESPEH platform, on the other hand, neither of the OS s has fulfilled all the requirements defined in chapter 3.1. Each of the analyzed operating systems had at least one very interesting unique feature. The specialty of Contiki was architecture that combines the properties of event-driven operating systems with preemptive multitasking. LiteOS showed that it is possible to implement Unix-like features such as a shell and file system on a low resource device. Such features are good for experimental purposes, but in a real WESPEH application, this would waste valuable system resources. Mantis has followed the implementation of classical Unix-based preemptive architecture with kernel and user space, which led to high RAM and ROM resource needs. SOS s main feature, dynamic loading possibility, enables remote updates of an application and is very useful for wireless sensor networks. Although this concept would fulfill the requirement remote configuration, on the other hand it is over-dimensioned for a WESPEH where the same application runs on the device. Nano-RK showed an interesting power management method through which the battery lifetime can be prolonged by setting limits of the task execution. However, its memory footprint was too high for the WESPEH platform. From the analyzed wireless sensor operating systems TinyOS 2.x seems to be the most appropriate system for WESPEH platform. The main drawbacks of this OS are the cooperative scheduler - that violates the hard RT requirement and NesC programming language.

87 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 87 Embedded Operating System Wireless Sensor Operating Systems FreeRTOS RTX51 Salvo TinyOS 2.x SOS Contiki LiteOS Nano-RK Mantis VROS Analyzed HW Platform generic ATMega 128L ATMega 128L MSP43 ATMega 128L ATmega 128L ATmega 128L ATmega 128L Multitasking architecture Preemptive or Cooperative Cooperative Preemptive Cooperative Event driven & Cooperative Cooperative Event driven & Preemptive Preemptive Preemptive Preemptive Message queue Tasks Specification No priority limit / no task limit 1 Priority level, max 16 Tasks 16 Priority level, task 255 mem limit No Priority High and Low Priority Tasks Not specified Priority Priority 5 Priority levels Messages Task Switching Latency (CPU cycles) Not specified 1 7 Not specified 8 31 Not specified Not specified static 312 dynamic messages Aprox. RAM req. + RAM per each Task (bytes) * 236 (+64/task) 7 (+ 3/task) 23 (+ 6/task) (+2/task) 1.6k 2k Aprox. ROM requirement 4k.9k 9k 1k 3.5k 19k 4k 3k 16k 14k 5kB (kbytes) * Power management support No No No Yes, integrated to scheduler No No, application layer No Yes Partial, application layer No Dynamic code No No No No Yes Yes Yes No No No Dynamic memory management No Yes No Partially (through TinyAlloc) Yes Yes Yes No No Not specified Distribution Source Code Library Library Source Code Source Code Source Code Source Code Source Code Source Code Not specified License GPL Single user Single user Open Source Open Source Open Source Open Source GPL Open Source Not specified Development Status Active Active Active Active Inactive Active Inactive Inactive Inactive Inactive Table 11 Overview of embedded and wireless sensor operating systems 4 As neither of the analyzed system fulfills all the requirements as defined in chapter 3.1 we can draw a conclusion that there is a need for a new operating system specially designed to run on WESPEH devices. As the next step of this research the design aspects of a WESPEH OS will be elaborated. 4 The ROM, RAM consumption information are orientation values. They were measured on the analyzed platforms running a certain application with a certain protocol stack. The values are platform dependent and can vary by feature set the analyzed operating system offers, by buffer allocation of the application, by compiler type and optimization settings.

88 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters Operating System Design for WESPEH This chapter deals with the challenges of operating system design for WESPEH devices. The objective of this chapter is to define an optimal architecture for a WESPEH operating system. The typical architecture of embedded operating systems is shown Figure 33. Based on this architecture, various design considerations for the components are presented and we discuss how these components have to be designed in order to be suitable for a WESPEH system. Figure 33 Architecture of embedded operating system [3] The proposed design considerations are inspired from practical experience and from the analysis of existing systems described in Kernel Architecture The typical architecture of embedded operating systems with standard components is shown in Figure 33. While not all embedded operating systems implement all the components, every general purpose operating system has a kernel at the very least. The purpose of the kernel is to perform process execution, handle interrupts, control process scheduling, memory management and inter-process communications. The kernel source code is usually loaded into a protected area of the memory that is not accessible by the application. The application is executed in the application memory space and can access the kernel function through system calls. Such architecture ensures that in case of an application malfunction, the kernel still stays intact. There are three types of typical kernel design models: Monolithic Microkernel Hybrid kernels

89 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 89 In monolithic kernels, all the components, such as device drivers and process schedulers, are part of the OS. The most famous monolithic kernel operating systems are Unix, Linux, and MacOS. In microkernel design, the kernel is stripped down to minimal functionality and additional component functionalities are made possible with services which are programs dynamically loaded into the kernel memory space. The most famous microkernel operating systems are MINIX and Symbian. Hybrid kernels are a combination of the previous kernel designs. Hybrid kernels are like micro kernels, except that they run some of the processes in the kernel space (networking of file system). Examples of hybrid kernel operating systems are Windows XP, Windows 7 [87]. Exokernels differ from the other types of kernels, since they do not abstract the hardware, instead they allocate physical HW resources such as processor time and memory pages. Exokernel is in its functionality limited to the protection and multiplexing of the raw hardware. Determining which of the kernel design approaches is better is a difficult choice. This is confirmed by the famous flame war discussion between Dr. Andrew S. Tanenbaum and Linus Torvalds. The discussion topic revolved around whether microkernels are superior to monolithic kernels or not. The outcome of the discussion was that it mostly depends on the type of use case decided upon for the evaluation of the operating system. The analyzed operating system kernel from chapter 3.2 followed various designs. Contiki, SOS, FreeRTOS have followed the microkernel-, whereas Mantis and LiteOS have followed a monolithic kernel design. Nano-RK has followed a special resource-based kernel architecture [9]. The other operating systems: Salvo, RTX51 and VROS, were following a custom kernel design. TinyOS does not implement a kernel, instead NesC upon compilation statically links the OS source code together with the application. Operating systems implementing monolithic kernel architecture have much larger memory requirements than operating systems with other kernel architectures. Microkernel architecture implementation requires less memory resources than a monolithic kernel, on the other hand, microkernels require inter-process communication. This would mean that every time the scheduler processes a task, it has to process message queues that introduce additional CPU processing time. Implementing kernel architecture with separated kernel and application spaces introduces extra resource costs. As with a WESPEH system, only one application is executed at a time, therefore no kernel space protection is needed. This suggests that WESPEH operating system should not follow any standard kernel architecture design. In order to save as many system resources as possible, WESPEH OS must have a strong stripped-down OS architecture where no kernel architecture implementation is needed. Thus the CPU and memory resources used for kernel and user-space separation, and memory protection, can be effectively used for other purposes. A layer of HW abstraction through which the application gets direct access to the HW should replace the implementation of kernel Process Management Process management enables the parallel execution of individual tasks, controls the CPU time assigned for each task, implements tasks context switching and provides a system tick. The parallel task execution can be realized using either preemptive or cooperative scheduling. Task execution using preemptive scheduling implementation is an attractive option for an embedded operating system. The main advantage of preemptive scheduling is that it ensures a real-time response on the task level. The other advantage of this

90 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 9 method is the simplification of the application programming. In a preemptive system, the application developer does not have to concern himself with how long the current application code is blocking system HW resources. However, preemption costs HW resources, both RAM, ROM and CPU. In cases of task switching, the actual context of task has to be saved, the next task context has to be restored and in case of priority preemption, the task with the highest priority has to be executed. The preemptive system also has to introduce protection for memory resources shared between tasks. In a cooperative system the task scheduling is simple. Tasks always run to completion and their execution cannot be interrupted. Cooperative scheduling requires less resources because no context switch is needed. For an operating system implementing a radio protocol stack with hard RT requirement, a cooperative scheduler is not an option. As indicated in the requirements 3.1.6, a WESPEH operating system definitely needs parallel task execution. WESPEH OS must quickly respond to hard RT events, and this can be ensured effectively only by a preemptive priority scheduler. Since the HW resources are very limited, instead of using a classical preemptive mechanism, the solution is to go for a light-weight preemptive scheduler. The scheduler must fulfill hard RT requirements. The preemption needs no context switching and the system does not have to support parallel execution of application tasks. Instead, the real-time control of the application task can be realized using events. From chapter 2.4.2, it can be seen that the priority of WESPEH tasks varies during the application execution. For example, when a self-powered controller queries a status from the repeater, the tasks controlling the packet reception process has to be assigned the highest execution priority. On the other hand, when a energy autarkic device transmits a packet, task monitoring of the system energy consumption must have the highest priority, in order to ensure correct system power down and entering deep sleep, in case of critically low energy levels. This means that the OS scheduler is required to be configurable, and that priorities can be adjusted both during compile and runtime Memory management Memory management controls access and memory allocation among processes. It also implements address space isolation, to protect the kernel by dividing the memory space between application and kernel processes. The memory management is responsible for the dynamic memory allocation. Typically in energy autonomous devices, the hardware platform RAM is limited to a few kilobytes. As discussed in the previous chapter, WESPEH OS needs no kernel, consequently implementing memory management for memory protection is not necessary. The only purpose memory management serves in a WESPEH OS is for dynamic memory allocation. Five of the ten analyzed operating systems in the chapter implement dynamic memory management. However, these types of routine implementation are not suitable for energy autonomous devices. Several research papers deal with the challenges of developing effective dynamic memory mechanisms [93]. Instead of analyzing which of the methods are suitable for a WESPEH system, we can question whether dynamic memory management for a WESPEH OS is needed at all. By implementing dynamic memory support, new problems are introduced to the operating system, such as memory fragmentation, determining the minimum management space and handling memory leaks. The operating system must handle these problems, therefore this requires system resources. Since WESPEH systems are thin resourced, dynamic memory management

91 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 91 implementation for a few kilobytes of RAM would an extravagance. We can argue based on facts that for a typical WESPEH application (considering the scenarios discussed in chapter 2.4), most of the time the amount of processed data can already be determined before application deployment. One can say that static memory allocation is wasting memory resources, because the same memory is always locked together with the same variable during the whole application execution. With the help of dynamic allocation, unused memory resources of an idle task could be assigned to the active task. The opposing argument is that if an ultra low power application RAM requirement on a 4kB system is higher than 4kB, introducing dynamic memory management will not satisfy the application memory needs. The conclusion is that a WESPEH operating system requires no memory management, because the exact memory needs of the application can be determined at compilation time. The memory for the application and operating system has to be allocated statically at compilation time File System The file system controls access to files stored in a permanent memory such as Flash or EEPROM. Although Contiki and LiteOS implement a file system for a WESPEH device, this feature of the operating system is not needed, as only one application runs during a WESPEH device lifetime Device drivers A device driver allows the SW to interact with hardware devices. The key design goal of the device driver is abstraction. For energy autonomous systems, the device drivers have to be implemented in the form of a hardware abstraction layer. The proposal for hardware abstraction discussed in paper [94] is a very flexible and resource efficient. The drivers for WESPEH OS must have simple, resource efficient interfaces. The most efficient driver implementation method is to create passive drivers using the C language macro preprocessor functionality. An example of such a driver in implementation is shown in Figure 34.

92 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 92 //! enable/disable count #define TIMER enable_count() \ ( t_ctrl = T_COUNT_ENABLE_BITMASK ) #define TIMER disable_count() \ ( t_ctrl &= ~T_COUNT_ENABLE_BITMASK ) //! get/set count register of timer #define TIMER set_count(value) \ t_cnt_upper = (uint8)((uint16)value >> 8); \ t_cnt_lower = (uint8)((uint16)value & (uint16)xff)\ #define TIMER get_count() \ ((((uint16)t_cnt_upper) << 8) (((uint16)t_cnt_lower) & (uint16)xff) ) //!Description: This function sets up the timer to count for msec #define TIMER set_msec_start(msec,prescaler)\ TIMER set_count(timer COUNT_MAX - TIMER calc_msec_val(msec,prescaler));\ TIMER enable_count()\ //!Calculation of timer periode in msec #define TIMER_calc_msec_val(msec,prescaler) \ (uint16)((uint16)(msec) / (float32)( (SYSTEM_CLK_PERIOD_NS/1)*prescaler)) Figure 34 Timer driver implementation example Radio protocol stack A radio protocol stack implements the network communication protocol based on the OSI layer model. The main source of power consumption in a WESPEH system is represented by the radio interface as discussed in For efficient network operations, the core requirement is that from the physical to the transport level, the protocol stack is implemented as the part of the operating system. In WESPEH, the low level network operations like reliable packet transmission, routing and repeating, and medium access algorithms have to be handled by the OS. The reason for this requirement is that efficient energy management and timing can be achieved only if the protocol stack has direct access to low power driver resources. This is needed in scenarios where data exchange must be realized in a very short time, as in the case of self-powered controllers Peripheral interface This part of the OS controls different I/O hardware devices, such as digital I/O port, A/D converter, RS232 communication, etc. In order to fulfill the modularity requirement for energy autonomous devices, this part of the OS should be divided into small independent modules. At compilation time, only those peripheral modules used by the application are linked to the OS Power management Power management is not a standard component in a general purpose embedded OS. From the analyzed systems in chapter 3.2, only three from ten operating systems have implemented a power management module. Each WESPEH HW implements an energy management block, therefore WESPEH operating systems have to provide support for this. To better understand the requirements placed on the OS power management module, for demonstration purposes various WESPEH power scenarios were discussed in

93 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 93 chapter Solving the power management problems discussed in the scenarios is possible either dynamic on the operating system level or static on the application level. From this results that question what is better proceeding if an OS handles the power management static or dynamic. Dynamic power management has two aims in WESPEH systems: 1. to change the power state of HW parts dynamically, dependent on executed task requirements. 2. To react to power events in a controlled manner. There are many different dynamic power management techniques discussed in various publications [95][96][97][98][99]. All of these techniques focus on the first aim, changing the power state of the system, dependent on the executed task. The basic idea behind the discussed technique is to shut down microcontroller blocks that are not needed for the current task execution. This can be done by accessing the microcontroller in different operating states for example, in standby or sleep mode. The main drawback of a dynamical power management implemented in the operating system is the latency introduced by the actions. This could lead to a violation of the real-time requirement. The explanation can be demonstrated with an example. The application receives a radio packet, must process it, creates a new packet and transmits this packet within a definite time. Let us consider that during the packet processing no other packet is expected. The packet processing can take several hundred microseconds. The power management block of the operating system, knowing that no other packet is expected, can switch off the radio interface during the processing time of the packet. When the packet processing is completed, the operating system can restart the radio interface. To start the radio interface means the PLL has to be activated, and until there is a stable lock, the radio interface cannot be used. All the tasks in the system will wait for the radio interface to be ready, and this causes latency during the packet transmission. Latencies will also be introduced when the CPU enters power saving mode. For instance, switching off the XTAL oscillator can put the microcontroller into standby mode, and this can save significant energy. Latency is introduced when exiting the standby mode, because by reactivating the XTAL clock, the system must wait for the clock to become stable. Realization of dynamic power management is not a trivial task as it requires the implementation of prediction techniques. The power management block has to decide based on observation whether the change of the system power state is beneficial or not. This can be demonstrated on the following example. Prior to putting the CPU into sleep mode, the power management must know if the upcoming task is time-critical or not. If the latency introduced by the powered down block is too high, it could jeopardize the upcoming task timing. Most of the predictive techniques are based on the analysis of the correlation between the past CPU workload and it s near future workload, but there are also many other techniques, such as predictive technique-based program counters [98] or non-predictive techniques based on stochastic control [95]. Implementation of a predictive technique on an energy autonomous device is very resource consuming. An additional complication is represented by the nondeterministic behavior of the ambient energy resource. One interesting option for a predictive technique that compensates for resource consumption is to use hybrid prediction techniques. In paper [22], a dynamic power management technique is presented with a hybrid technique where the compiler inserts so-called power management hints in the

94 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 94 application code. The operating system periodically invokes a power management point to change the processor's performance, based on the timing information from the power management hints. The idea is very interesting, although it requires the collaboration of the compiler and the OS. Another disadvantage of this technique is the need for a proprietary compiler. Leaving power control entirely to the operating system can be a problematic solution, because the power needs of the system vary according to the type of energy harvester used (see chapter 2.3 type of energy). Therefore it is questionable whether dynamic power management based on predictive techniques is feasible for an energy autonomous system. For instance, the execution of a prediction algorithm may consume more power in the OS than is saved by the power management itself. Furthermore, the WESPEH system is influenced by nondeterministic events such as the critical energy states of storage capacitors. Still, dynamic power management methodology is an attractive energy saving option for a WESPEH system. The solution proposal to this challenge is to reduce the prediction overhead by utilizing an application driven power management model. This alternative means moving dynamic power management out of the OS and into the application. Power management is then controlled by the application using the interfaces provided by the OS. In a system with a low number of parallel tasks, the SW developer still has an overview of the complete execution process. Therefore, the developer can make the best decision about where the power management should be applied in the application. To help the application task decide if now is the right moment for a power mode change, the OS provides interfaces to examine the detailed state of various OS blocks. Through these interfaces, the application can access information, for instance about the scheduled tasks, memory states, etc. Knowing the execution path of a task, strategic places in the source code can contain calls to the power management module. These calls invoke a power management routine whereby the scheduler and operating system states are examined, and this information is then delivered back to the application. Based on this information, the application can decide to put the system into sleep mode or to deactivate system blocks. This technique is a compromise between static and dynamic power management. A similar technique is implemented in the Contiki operating system discussed in chapter This type of technique has low CPU and memory resource requirements and offers the flexibility to optimize energy resources Programming language selection Selection of the programming language is an important issue when implementing an operating system for energy autonomous systems. General purpose OS has a variety of compilers available for different microcontroller platforms. The basic requirements for the programming language are as follows. It must: be close to the HW without complex memory management requirements. generate effective code. be supported by most of the 8 and 16bit microcontroller platforms. By introducing.net Micro Framework and Embedded Java framework, all

95 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 95 programming languages used in desktop computers, such as C#, C++, Visual Basic and Java become available for embedded platforms. Java ES Embedded.NET Micro HW Platforms x86, x64, PowerPC, SPARC (32 and 64 bit) ARM7, STM9, Blackfin (32 and 64 bit) Min. RAM requirement Min. ROM requirement CPU requirement 32MB 32MB 6MHz 256kB 512kB 4MHz Table 12 Frameworks for embedded systems Table 12 shows that programming languages like Java, or C# running on frameworks, are far beyond the capabilities of WESPEH, due to their high memory and CPU requirements. Neither of the frameworks support a 8 or 16 bit CPU, which are the typical platforms used in energy autonomous systems. Another significant problem with these frameworks is the memory management-using garbage collector. This causes nonpreemptive behavior, which makes it impossible to fulfill the hard real-time requirement. The other non-framework based programming languages are C and C++. Since the WESPEH system is thin resourced, another possibility is to perform the implementation in assembler. Implementing programs in assembler is supported by every HW platform, although nowadays nearly every HW platform has its own C compiler. When it comes to software development for a system with limited resources, and where time is a critical constraint, developers would certainly opt for assembler. There is a general belief among embedded software developers that states: If you need to write time-critical and spaceoptimized software code, you should write it in assembler. This is true. On the other hand, how many software developers are able to write assembler code that really gets the most out of a system? Writing efficient and optimized C code is not an easy task. It takes several years of coding experience, analyzing different source code, until a developer's coding style is efficient enough. It probably takes the same amount of time with assembler. When a project developed in assembler is migrated to a new platform, the developer has to start gaining experience from the beginning. That is not the only drawback of using assembler. Assembler, unlike C, is not a programming language. It is a symbolic representation of hardware-platform-specific machine code. It is very difficult for one developer to read another developer s poorly commented assembler code. A number of tools that make software development more efficient, like Doxygen (documentation generator from C source code), Lint (C source code checker), as well as the model-based design based on UML language, cannot be used with assembler. The C programming language offers platform independence and flexibility. Developers using C can focus more on the actual problem to be overcome. This also confirms the fact that all 1 operating systems analyzed in chapter 3.2 were implemented in the C language. Now the question arises: what is better, C or C++, for energy autonomous systems? It is a frequent question and one which is difficult to answer. According Dominic Herity [17], C++ is always preferable to C as an implementation language for embedded systems. On the other hand, only a few C++ compilers support 8-bit HW platforms [85]. From a WESPEH point of view, the answer to the question is the C programming language. C is HW oriented, provides the low level features necessary for accessing HW and is

96 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 96 supported by most of the microcontroller platforms Conclusion In the previous chapters, embedded operating system components were discussed with the focus on adjusting them, in order make these components suitable for WESPEH. From the discussion results, the architecture proposal of a WESPEH operating system is shown in Figure 35. Figure 35 WESPEH OS architecture In a typical WEPSEH OS architecture, the application is tightly coupled with the OS. Either the application source code is compiled with the OS or the application objects are linked to the OS objects. Furthermore, the application has the possibility in some cases, through system calls, to directly access the hardware abstraction layer. For a successful WESPEH OS implementation, the design considerations listed below must be followed: implementation language is C. OS has no kernel or user space. OS code is statically linked to the application. OS has no memory management. OS implements no file system. memory of the OS and application is allocated at compilation time. OS is modular. OS modules are linked only if they are used by the application. OS implements a light-weight preemptive priority scheduler. scheduler type and priority can be changed dependent on the application needs. OS implements no device drivers. drivers are replaced with a thin hardware abstraction layer. drivers are implemented using the C macro language. radio protocol stack is part of the OS implementation.

97 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 97 power management is part of the OS implementation. power management module abstracts the microcontroller power features. power management module provides interfaces for to the application to: o control energy storage. o monitor energy resources. o control MCU power features. o query the OS about status information for prediction purposes. o signal critical power events to the application. o control the clock domains of the MCU. OS provides the abstraction of peripheral interfaces. The major contribution of this chapter is the clear definition of design aspects of WESPEH operating systems. In the next chapter, the implementation of WESPEH operating system will be described, based on these design aspects. Significant parts of these chapters have appeared in various publications [5].

98 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters WESPEH OS implementation This chapter describes an operating system implementation of the WESPEH operating system called DolphinAPI which fulfills all the requirements described in chapter 3.1 chapter. The operating system design is based on the conclusions discussed in chapter The initial implementation of the system was developed for the EO3I hardware platform. We have selected this HW platform because with its feature set is currently the most appropriate HW platform for WESPEH design, as discussed in In the future, the operating system may be ported to other HW platforms. At the beginning of the chapter, various energy saving implementation techniques used for the OS implementations in C language are discussed. In the following part of the chapter, the architecture of the DolphinAPI and the design and implementation of the relevant OS modules are described Compiler selection and implementation language As was established in the discussion in chapter 3.3.2, the ideal language for WESPEH implementation is the C programming language. DolphinAPI source code is implemented in C. Since the EO3I microcontroller part is based on the Intel 851 controller for the DolphinAPI implementation, the appropriate 851 compiler had to be selected. The best 851 compiler among all the compilers available is the Keil company s C51 compiler. Initially, the OS implementation was done for both the SDCC [64] and C51 [23] compilers. At the time the OS implementation had begun, the SDCC compiler was not mature enough to use. Several ANSI C features were not fully supported. Additional problems were caused by the fact that SDCC used different keywords for memory access than Keil and had no assembler support. Later on, we dropped SDCC support, because these problems were costing us enormous extra efforts C Source code energy saving techniques As discussed in chapter 3.3.2, C is the most appropriate language for designing the WESPEH operating system. Nevertheless, the compiled C code is often not as optimal as an assembler code would be. Significant performance increases can be achieved by optimizing routines written in C. Several optimization algorithms are implemented in embedded C compilers [25]. Using these, the code of a program can be reduced so that execution of the program will require less energy. Most compiler optimization methods focus on low level code optimization, i.e. generating the most effective code for the particular hardware platform. Compared to low level optimization techniques, only a few high level approaches are proposed that are applicable to generic C source code [24]. Apart from compiler optimization, significant efficiency in software execution can be achieved by utilizing manual code reorganization. In this chapter, various manual source code techniques are introduced which ensure optimal energy saving code translation from C to assembler. All the methods described in this chapter are based on the fact that C is a very flexible language, and the same routine can be written in many different ways. The following part of the chapter introduces some examples, showing how reorganization of C code can lead to effective assembler results. The assembler code for the examples was generated with the Keil C compiler for the

99 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters platform. Using pointers Accessing more dimension arrays or complex structures can be very time-consuming, especially when implementing a loop where an operation is necessary for every element of a complex array. Consider the piece of code shown in Figure 36, where multiple elements of multiple arrays are accessed for a checksum calculation. The resulting checksum is written as the last element of the array. The selected array is indexed with the u8b variable, the elements of the array are indexed with u8i. for (u8i=; u8i < (MAXLENGTH-1); u8i++) u8chk += u8buff[u8b][u8i]; u8buff[u8b][u8i] = u8chk; Figure 36 Loop, indexing elements of an array If we look at the assembler listing in Figure 37, we can see that every time the u8buff variable is accessed, the array indexing variable u8b is loaded, and the absolute address of the actual array item is calculated with a multiplication. After the checksum loop is finished, the u8b variable is loaded again for the checksum saving operation in the array. Calculating the u8b absolute address with the multiplication command is a timeconsuming operation. Frequent repetition of this operation in the loop wastes a lot of time. The reason why the compiler generated this code is that it cannot detect that the u8b variable does not change during the loop.?c7?test: ;checksum calculating loop MOV A,u8b ;the u8b is loaded every time MOV B,#1EH MUL AB ;the item addr. calculation ADD A,#LOW u8buff ADD A,u8i MOV R,A MOV A,@R ADD A,u8Chk MOV u8chk,a INC u8i MOV A,u8i CJNE A,#9H,?C7?TEST ;storing the checksum result to the array MOV A,u8b MOV B,#AH MUL AB ADD A,#LOW u8buff ADD A,u8i MOV R,A Figure 37 Assembler listing of loop, indexing elements of an array Execution of the code above takes 179 µs. Using pointers, the time to execute the previous code can be reduced, as shown in Figure 38.

100 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 1 ptr = u8buff[u8b]; for (u8i=; u8i < (MAXLENGTH-1); u8i++) u8chk += *(ptr + u8i); *(ptr + u8i) = u8chk; Figure 38 Optimized loop execution with pointers The absolute address of the array u8buff indexed with u8b is loaded to a pointer variable called ptr. This ptr address is incremented with the loop variable u8i. The assembler code shows that the mul instructions are removed, and the ptr address is loaded only once to the R7 register. Storing the checksum value is also faster because the ptr remains in the R7 register. ;loading ptr variable to R7 register MOV A,u8b MOV B,#1EH MUL AB ADD A,#LOW u8buff MOV R7,A ;loop label?c7?test: MOV A,R7 ADD A,u8i MOV R,A MOV A,@R ADD A,u8Chk MOV u8chk,a INC u8i MOV A,u8i CJNE A,#1DH,?C7?TEST ;storing the checksum result to the array MOV A,R7 ADD A,u8i MOV R,A Figure 39 Assembler listing of optimized loop execution The code execution of assembler source in Figure 39 takes 12µs. With a larger array (tested with 23 elements), the speedup is more significant and several µs of execution time can be saved. It is good practice to put calculations with constants before or after the loop. The following example in Figure 4 shows the increase of each checksum value by 3. Doing it after the loop can save much more time, even if multiplication is needed. for (u8i=; u8i < (MAXLENGTH-1); u8i++) u8chk = u8buff[u8b][u8i] + 3; //instead here u8chk += u8i*3; //do it rather here Figure 4 Constant calculation after the loop

101 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 11 Structures and more dimensional arrays are very powerful tools in C. Nevertheless, when software is developed for a time- and energy-critical environment, the compilergenerated code should be checked often, to avoid surprises with ineffective code. Using union with structures In an embedded system development, there is often the need to create a 16bit value from two 8bit variables. A common way of solving this problem is to use mask operations, as shown in the example in Figure 41. #define getlowbyte() xaa #define gethighbyte() xbb int u16value = ; u16value = (int)(gethighbyte() << 8); u16value = (unsigned char)( getlowbyte() ); Figure 41 Calculation of 16 bit variables Shifting is a very time-consuming operation, especially if the underlying microcontroller has no dedicated hardware support for the operation. The code shown in Figure 8 is executed in 3µs. Using unions, the same functionality can be reduced to just.75µs execution time, as shown in Figure 42. typedef union { unsigned char u16byte; struct { unsigned char u8highbyte; unsigned char u8lowbyte; } r; } union_t; union_t u16value; u16value.r.u8highbyte = gethighbyte(); u16value.r.u8lowbyte = getlowbyte(); Figure 42 Calculation of 16 bit variables using unions The advantage of this solution is that the whole 16bit variable, or just the 8bit parts, can be accessed through the union parameters. The compiled assembler code is very simple, as shown in Figure 43. MOV u16value,#bbh MOV u16value+1h,#aa Figure 43 Assembler listing of calculation of 16 bit variables using unions Another way to access separate bytes of a 16bit variable, is to use pointers, as shown in Figure 44. When using this solution, we have to know if the compiler stores variable in

102 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 12 Big or Little Endian format. int u16value = ; *(((uint8*)&u16value)+1) = u8lowbyte; *((uint8*)& u16value) = u8highbyte; Figure 44 Assembler listing of calculation of 16 bit variables using unions The power of preprocessors The preprocessor built into the C compiler processes the source text of a source file before it is actually compiled into machine language and object code. Perhaps one of the most useful aspects of the C preprocessor is the ability to create and use macros. Assume there is a need to create a function that calculates the timer period based on the oscillator frequency (OF), time slice in milliseconds (u16msec) and prescaler (u8presc) settings. An example of such a function is shown in Figure 45. uint16 CalcTPeriode(uint16 u16msec, uint8 u8presc) { return (uint16)( msec / (float32) ( OF * u8presc); } Figure 45 Timer period calculation function Execution of the function can take several hundred microseconds on an 8bit microcontroller architecture, caused by the 32bit division with floating point number. The timer period calculation is usually needed only once per software life cycle - only the constant value to be written to the timer register must be calculated. This is an ideal situation where the preprocessor and macros should be used in the following way, as shown in Figure 46. #define CalcTPeriode(u16msec, u8presc) \ ((uint16)( msec / (float32) ( OF * u8presc)); Figure 46 Timer period calculation using macro The code shown in Figure 46 generates only two assembler instructions. The calculation is done by the preprocessor and the result is a 16bit constant value. Using a preprocessor and advanced macros can bring modularity to the software without loss of performance. Switch-case statement The execution time switch-case statement can vary according to the definition of the case constants. Consider the following switch case statement consisting of at least six arguments, shown in Figure 47.

103 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 13 switch (u8curstate) { case 4: u8res = 'A'; break; case 21: u8res = 'S'; break; case 11: u8res = 'D'; break; // further case elements } Figure 47 Switch case statement The compiler generates assembler code where the switch statement is broken up to test and branch instructions, as shown in Figure 48. MOV A,u8CurState ADD A,#F5H JZ?C1?TEST ;evaluation of case 11 ADD A,#F6H JZ?C9?TEST ;evaluation of case 21 ADD A,#11H JNZ?C11?TEST ;evaluation of case 4 ; further jumps Figure 48 Assembler listing of switch case statement Such code is not effective for energy-critical systems, because in the worst case situation, all branch instructions have to be evaluated before jumping to the correct statement code which with six case statements means 6 x 2 = 12 instructions. Instead, using random case arguments constants 4,21,11 numbers in increasing order should be used (if possible). Assuming the case arguments are,1,2,3, the compiler generates a jump table where the destination address for each case is calculated in six instruction times, as shown in Figure 49. MOV A,u8CurState CJNE A,#7H,?C17?TEST?C17?TEST: ;calculating jump address JNC?C15?TEST MOV DPTR,#3FH ADD A,ACC ;jump table AJMP?C8?TEST AJMP?C9?TEST Figure 49 Optimized assembler listing of switch case statement As can be seen from the assembler code, such a solution is effective if we use several case arguments. On the other hand, if the number of case arguments is below six, the branch and jump method generated assembler code is faster. Effective timer calibration

104 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 14 A common use case in WESPEH SW is the calibration of the timer with lower precision. During the calibration procedure, the lower precision timer frequency is measured with a more precise timer and the calculated factor is stored in flash. Let us consider a calibration procedure of Timer 2 that is a 16bit timer with 1kHz clock frequency and a 3% calibration error. For the calibration, we will use Timer 1, which is 32bit and has a 16Mhz clock frequency and 1% error. One method of calibration is to start both timers, measure the same time period and calculate the correction factor by stopping Timer 2 when Timer 1 reaches the appropriate count value. For instance, at a 2.48ms period measurement, Timer 2 will be stopped at tick 215, which shows a 4.9% error, and for this the needed correction factor is 1.4. This value is stored in flash in a 32bit float variable. The calculation of Timer 2 s period with the correction factor is shown in the first line of Figure 5, where the application uses the Timer 2 to measure 1.2ms periods. The calculation of floating point values on 8bit MCU without floating point unit takes a long time, thus consuming much energy and program code. The operation with floating point calculations running on 851 architecture would take 52µs. One optimization possibility is instead of storing the float correction factor, store the low precision Timer 2 tick 215. Using the timer tick, the correction factor in the application can be calculated with the precise calibration tick 248. Integer division and multiplication is much faster than in float, thus as shown in the second line of Figure 5, applying the timer calibration calculated with the precise and lower precise tick now takes 26µs. If the measured period and the 248 calibration tick have a common factor, we can divide the numbers by the divisor: 12. T 2 _ CAL 15. TCAL = (3.1) This the casting from 32bit can be reduced to 16bit, which indicates a major speed increase. The reason for this change is that the multiplication 12.( T 2_ CAL± (3%. T2_ CAL)), even with the 3% error margin, will fit into a 16bit variable. A minor speed increase will result if instead division using the shift operation instead of the integer division, as shown in the third line of Figure 5. T2_set_cycle((uint16)(12*(float32 xdata *)T2_CAL)); //52µs T2_set_cycle((uint32)(12) * (uint32)(*((uint16 xdata *)T2_CAL) )/ 248); //26µs T2_set_cycle((uint16)(15) * (uint16)(*((uint16 xdata *)T2_CAL) )>>8; //19µs Figure 5 Timer calibration optimization steps

105 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters DolphinAPI Architecture DolphinAPI is an ultra low power WESPEH operating system that has the following features: modular operating system. fulfills hard RT requirements. is thin resourced and requires 1k RAM and up to 4k-24k FLASH. implements EnOcean protocol stack. capable of telegram transmission and reception in ultra-low power mode without the runtime of scheduler. implements the capability of remote management. implements various power saving modes. The OS architecture is shown in Figure 51. The OS has a modular layered structure and is built up by the following layers (bottom up): Hardware Abstraction Layer (HAL) System Software Layer (ESSL) Application Layer Application DolphinAPI interface ESSL LAYER radioulp_mod filter_mod reman_mod time_mod radio_mod repeater_mod smack_mod uart_mod timer1_mod io_mod spi_mod mem_mod pwr_mod misc_mod scheduler smack - repeater isr_mod Hardware Abstraction Layer (HAL) EO3I HW Figure 51 DolphinAPI architecture Hardware Abstraction Layer (HAL) The HAL is the lowest layer of the OS and it interacts directly with the underlying hardware. The HAL layer abstracts the EO3I HW platform. With the help of this abstraction, the OS components are not dependent on the HW. The abstraction makes it possible to migrate the OS to other HW platforms in the future. The structure of the HAL is composed of several components, as shown in Figure 53.

106 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 16 The Common component defines all supported HW platform properties, such as bus width, register width, C variable types and compiler-specific definitions. DolphinAPI, like other OS s following MISRA C rule 13 [34][1], does not use the standard C names for variable types char, int and long, instead it declares types which define the variable width and signed/unsigned property, see Figure 52. These types are mapped to the real C type, dependent on the HW platform. For example, a C compiler for an bit HW platform interprets the integer data type as 8 bit. The C compiler for an ARM 32-bit HW platform interprets this data type as 32-bit. // // Definitions to have base types with explicit size and sign // as suggested by MISRA rule 13 // #ifdef USE_851 typedef unsigned long int uint32 ; //!< Unsigned Integer 32 bits typedef signed long int sint32 ; //!< Signed Integer 32 bits typedef unsigned int uint16 ; //!< Unsigned Integer 16 bits typedef signed int sint16 ; //!< Signed Integer 16 bits typedef unsigned char uint8 ; //!< Unsigned Integer 8 bits typedef signed char sint8 ; //!< Signed Integer 8 bits typedef unsigned char uchar8 ; //!< Unsigned Character 8 bits typedef signed char schar8 ; //!< Signed Character 32 bits typedef float float32 ; //!< Floating point 32 bits typedef bit bit1 ; //!< Single bit Figure 52 Data type redefinition The HAL resources are divided into separate structures that are HW platform-dependent. One structure consists of two further layers: top level and low level layers. The top level layer contains platform constants and settings like registry definitions, bus bridges, memory address, etc. The low level layer implements the drivers the abstraction of the hardware component. There are three different driver types: bus drivers memory drivers peripheral drivers The low level drivers are using the definitions from the top level module. Among the low level drivers, further layering is also possible. A low level driver can use the functions of other low level drivers. For example, the SPI HW block can be accessed through an APB bus, thus the SPI driver uses the APB bus drivers. Most of the drivers are passive drivers. They do not allocate memory and do not use CPU for performing operations.

107 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 17 Hardware Abstraction Layer (HAL) Common EO3I ASIC generation2 ASIC generation3 Low Level Top Level drv_uart drv_irq drv_spi platform_const bus_bridge Figure 53 Structure of the HAL layer These passive drivers are built up from definitions and the preprocessor before compilation translates these definitions into constants. An example of such a driver is shown in Figure 54 #ifndef UART_H_INCLUDED #define UART_H_INCLUDED #include <platform_const.h> #define REN_BIT_MASK x1 #define RM2_BIT_MASK x2 #define UART_config_baudrate(baud_rate,freq_in_mhz) uart51_brr=(uint8)(((float32)freq_in_mhz/(float32)(.16*(baud_rate)))-1) #define UART_get_baudrate() #define UART_set_mode() #define UART_set_mode1() #define UART_enable() #define UART_disable() uart51_brr SCON = SCON & x1f SCON = SCON & x6f SCON = SCON REN_BIT_MASK SCON = SCON & ~REN_BIT_MASK #endif Figure 54 UART passive driver structure There are also some active drivers implemented in assembler that make possible a bus communication, for instance System Software Layer (ESSL) The ESSL layer contains the implementation of the scheduler, power management, radio protocol stack and peripheral components. DolphinAPI does not implement classical kernel architecture. Operating system libraries are linked to the application upon compilation time, thus there is no kernel and user space separation. The structure of the ESSL is modular. Most of the modules are independent. Modules interacting together are shown as horizontal boxes in Figure 51. Modules that are directly accessible from the application have a configuration and function interface. The modules implemented in this

108 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 18 layer access the HAL layer drivers, thus their implementation is HW platform independent. Some core modules are not directly accessible from the application, such as scheduler and interrupt handlers. The other modules have an interface that is used by the application. Each application-accessible module has two types of interfaces: a configuration interface and a function interface. The function interface is called by the application and it provides access to different OS resources. In the next section, the design and implementation of the ESSL layer is described. Modules configuration The configuration interface of the module activates the module (by linking it to the application), allocates memory for the module variables, passes memory resource pointers allocated by the application, configures the HW resources and activates interrupts. If the configuration interface is not called by the application, the module will not be linked to the application, thus it will not use any ROM, RAM or HW resources. Configuring radio_mod or io_mod requires various combinations of dependent parameters. For instance, to configure the RF front-end, the modulation frequency has to be set, PLL and various filters have to be configured. To perform such an operation on a C level, several configuration interfaces would be needed. Each call to the OS requires time and energy. This problem is solved in DolphinAPI by moving the parameter logic out of the OS to a configuration SW running on a desktop computer. We have implemented a configuration SW called DolphinStudio. It offers a comfortable GUI interface to select the appropriate configuration. The selected configuration is generated to an array that is passed to the module configuration interface. The array parameters are directly translated by the OS to the low level drivers. The configuration interface of the module gets a pointer to an array where all the parameters are stored. An example of how the IO module is configured is shown in Figure 55. Figure 55 DolphinAPI IO module configuration using DolphinStudio

109 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 19 Memory management There is no memory management in the OS; the memory is assigned statically to the objects during compilation. Each module has its own static RAM allocation. Some modules, like the radio implementing the radio protocol stack, or the mem module implementing the flash memory storage, require a larger part of memory resources. For instance, the radio module needs buffer allocation for packets and the mem module needs a shadow memory for flash processing. These memory resources are allocated by the application and transferred to the module through the configuration interface. The advantage of this technique is that the application has direct control over the amount of the memory the OS uses and no extra resources are needed for memory management. Another advantage of this method is that the application can share memory resources among modules that are not executing parallel tasks. For example, the shadow buffer of the mem module can be used by the application for analog values sampling until a function of the mem module is called. Radio Protocol Stack From the discussed radio platforms in chapter , Table 7, the most energy efficient is the EnOcean Radio Protocol stack (ERP). The ERP sends very short packets, has a high data rate and ASK modulation covers a transmission range of 3m in free field and 3m in buildings. The communication is performed on regulated frequency ranges 868.3, 315MHz with highest airtime availability. This ensures relative low collision probabilities with other line-powered radio standards. Furthermore, these frequencies are not used by other radio standards such as BLUETOOTH, DECT, WLAN, etc. Additionally, the protocol stack has support for unidirectional and energy autonomic communication in the higher communication layers (Subtelegrams, SmartACK). All these features were motivating factors in the selection of ERP as the standard protocol stack for DolphinAPI. The ERP communication protocol is packet based and it contains different data units. The smallest data unit is called subtelegram. The protocol initially was designed to work as a unidirectional protocol without handshaking. To ensure the transmission reliability, the same information in the form of subtelegrams is transmitted three times in a dedicated time slots. The subtelegrams counter defines the radio channel reliability. For example, if on average one subtelegram is received from the three subtelegrams transmitted, this means the radio link is not stable there are either collisions, or the received radio signal strength is low. The telegrams are composed of subtelegrams. The telegram has a universal data structure, as shown in Figure 56. Figure 56 Universal telegram structure

110 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 11 The universal fields of the telegram are: Choice telegram type identification Data payload ID unique 4 byte device ID Status control information Chk hash control sum The length of the telegram is not transmitted in the telegram structure. The length is determined by counting the number of bytes received until the end-of-frame. Each transmitted subtelegram is an atomic unit and contains all the information the composed telegram contains. All the functionalities of the ERP must be ensured by the operating system implementation. DolphinAPI implements all the layers of the ERP protocol stack in the module radio_mod. The details of the implementation and the detailed description of the protocol stack is beyond the scope of our work. More information about the ERP can be found in [169]. EnOcean Serial Protocol 2, 3 In order for the telegrams using the ERP protocol to be transmitted to a second microcontroller, or to a host computer, an encapsulation is needed. This encapsulation is performed using the EnOcean Serial Protocol version 2 or 3 (ESP2, ESP3). The ESP encapsulates radio telegrams and attaches additional information like radio signal strength, number of subtelegrams, address, etc. The ESP protocol typically uses the UART interface for the transmission of the information. DolphinAPI implements both ESP2 and ESP3. More information about these protocols can be found in [171] Scheduler DolphinAPI utilizes a unique preemptive priority scheduler on the system level. We differentiate between two types of tasks: single application and several system tasks. System tasks run preemptively to application tasks, but concurrently with other system tasks, thus a system task can always interrupt an application task. System tasks always run to completion. One of the system tasks can be assigned a high priority. Such system tasks can also preempt other system tasks. There is only one application task; thus no parallel application task can be executed. The OS implements no message handling. System tasks can execute application code using static callbacks. System tasks are divided into synchronous tasks and asynchronous tasks. Most of the synchronous system tasks provide the function of the radio protocol stack. To execute the synchronous system task, a scheduler is used using the HW timer interrupt. The scheduler runs on a round robin basis and each task has a 1ms timer slice. Every millisecond the execution of the application is interrupted and one of the system tasks takes over the CPU. Synchronous system tasks are executed sequentially according to their priority and demand. Some of the synchronous tasks can be triggered by events from asynchronous tasks. Asynchronous system tasks are HW module dependent and are connected to HW interrupts. Although the system tasks run to completion, it is ensured by the implementation that neither of the tasks monopolize the CPU. The maximum execution time slice of a system task is around 6µs.

111 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 111 Synch Task Execution Synch Task Description Asynch Task Execution Asynch Task Description SynchTask 1 Always System timer increment a counter representing the system clock counter increments Priority High: AsynchTask 1 event-based Uart Rx/Tx interrupt process uart byte and put in the ring buffer SynchTask 2 Always Radio buffer update Processes Radio SW buffer and subtelegram timings. If there is a telegram that has to be transmitted, it is placed in the Radio HW buffer AsynchTask 2 event-based Radio Rx interrupt process incoming subtelegram SynchTask 3 event-based Telegram decoding decodes only one received telegram and stores it in a free radio buffer AsynchTask 3 event-based Radio Tx interrupt finishes telegram transmission, stops ongoing HW state machine SynchTask 4 event-based Telegram converting converts all UxS / TxS telegrams to RPS AsynchTask 4 event-based Timer1 processes timer 1 interrupt and calls the application callback function SynchTask 5 event-based Telegram compressing Processes received subtelegrams. It checks whether the same subtelegram exists. If the telegram is new, the repeating option is proven. AsynchTask 5 event-based IO processes gpio interrupt and calls the application callback function Table 13 Description of asynchronous and synchronous system tasks The structure of the scheduler is modular. There are several different scheduler configurations in the OS. The modular implementation of the scheduler makes it possible to change the scheduler module by invoking other init functions of the time module. With this method, the OS can be configured to support other synchronous system task configurations with different execution priorities. For instance, we can introduce a new system task supporting a routing or repeating process. An example of a typical scheduler configuration is shown in Table 13. The scheduler selection and configuration is performed using DolphinStudio. Peripheral control DolphinAPI supports various peripherals. The operating system implements a module for UART communication called uart_mod. The bytes transmission and reception is performed parallel to the application in the operating system as an asynchronous task. Furthermore, the OS implements an SPI master communication module called spi_mod. To save processor time, this communication interface was not implemented as an asynchronous task, and is performed as a blocking system call. The OS also implements functions for the control of digital and analog ports in the module io_mod. Few digital I/O ports can trigger an event and thus execute an asynchronous task.

112 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 112 Power management The OS implements an application-driven power management model. The OS abstracts the power management features of the HW and provides interfaces to the application for controlling power domains. The application can select different CPU clock sources and can put the HW into different power modes. A summary of the power modes and the power management module features of the OS is shown in Table 14. The power management module in the OS ensures smooth transitions between the power modes selected by the application. Prior to entering sleep mode, the power management module of the OS makes sure that all pending tasks run to completion, all interrupts are switched off, the scheduler is stopped, radio communication is powered down safely and the HW buffers are cleared. The low-power timers and wake up events that trigger the power mode transition are controlled by the application. After the wakeup, the OS informs the application about the last power mode and provides the event information which triggered the power mode transition. Such a power management scheme gives the application great flexibility to control the power consumption of the whole system. The reason why the OS does not implement dynamic power management (DPM) is partially because DPM requires a lot of system overhead. In addition, different types of WESPEH applications have different power lifecycles. Creating an optimal DPM solution in a WESPEH application would not be as optimal as application-driven power management. Current Wakeup Event Startup Startup State Description Deep Sleep Flywheel Sleep ShortTerm Sleep Standby 8 na 72nA 1uA 1.4mA Watchdog timeout, Wake pins Watchdog timeout Flywheel timeout, Wake pins ShortTerm timeout Watchdog timeout, Flywheel timeout, Wake pins Timer, Wake pins, External Pin, Radio Rx telegram Reset vector Reset vector Continue in application Continue in application RAM Retained, XTAL off, running on CRCO RAM Retained, XTAL off, running on CRCO All RAM retained except radio configuration XTAL off, running on CRCO CPU inclusive all RAM retained Used for weak ambient energy powered, event triggered TX applications Used for high precision system timing, lowest duty-cycle synchronous network. Used for short periods which are significantly longer than the XTAL startup time (e.g. between subtelegrams) Used for waiting for an event Table 14 Summary of power modes Conclusion We have introduced the implementation of a full functional WESPEH OS based on the design guide discussed in chapter 3.3. The implementation supports the EnOcean Protocol Stack and was tested on several HW modules running on the EO3I platform. We have successfully implemented several energy autonomous applications on the DolphinAPI to prove the functionality of the operating system. The OS was used for the development of the TCM3 [164], STM3 [163] and STM31 [165] applications. Further applications are continuously being developed, including by third parties.

113 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters Porting TinyOS 2.x to the EO3I platform The next step in our research is to evaluate the DolphinAPI performance of the operating system and compare it to other operating systems. This requires that another benchmarked operating system running on the EO3I HW platform and implementing the EnOcean Radio Protocol stack. The analysis in chapter 3.2 showed that the best OS candidate for WESPEH systems was TinyOS. TinyOS has several similarities with the DolphinAPI and an initial quick analysis shows that it would fulfill most of the requirements defined in chapter 3.4. TinyOS architecture is modular, has a small footprint and has static memory allocation. The only issue TinyOS 2.x has is its non-preemptive cooperative scheduler. A scheduler based on task cooperation can cause problems with the hard RT requirement. To be able to provide evaluation measurements between TinyOS 2.x and DolphinAPI, the aim of our research was to port the TinyOS 2.x to the EO3I platform, and implement the EnOcean Radio Protocol stack on this system. This chapter describes these proceedings Tool chain adjustment While TinyOS has a good layering structure and its architecture is prepared to support diverse platforms, porting the OS to the EO3i HW was an advantageous step. The main difficulty encountered during the porting was getting the tool chain adjustment to support the 851 architecture. For the original TinyOS 2.x source code, currently no platform exists which is based on the 851 architecture. There were several attempts made to introduce the TinyOS 2.x port onto the 851 architecture [5][51][52]. From all of these attempts the best-documented, most popular solution is a TinyOS 2.x port provided by the team of Leopold Martin. Martin team s idea of porting TinyOS to 851 architecture was discussed with the TinyOS community in the form of a TinyOS Enhancement Proposal (TEP) [49]. After the TEP proposal was completed, they founded the TinyOS 851 working group. Members of this working group have ported TinyOS 2.x to several 851 platforms. The most complete port was done on the CC243 platform from Texas Instruments. The ported source code is available on the working group s web page [5]. Our porting process of the EO3I was based on the work of the TinyOS851 working group. To be able to focus solely on the OS s performance during quantification measurement and ignore the compiler performance, it is important to use the same compiler as was used during the DolphinAPI development. The first task of the TinyOS 2.x migration to the EO3I platform was to adjust the tool chain to support the Keil C51 compiler. Even though TinyOS architecture provides several levels of abstraction, TinyOS designers were expecting that the NesC-generated output C file would be passed to GCC or to a full ASNI-C compatible compiler. That is the reason why the NesC compiler supports only GCC or ANSI-C syntax. Although Keil C51 is an ISO/IEC 9899:199 standard compiler (which is also known as ANSI C Standard C9), in order to provide the full support of the 851 architecture, the Keil C51 language is extended by several keywords. These extensions are used mainly for memory areas and memory models, but they are also used in register definitions or recursive function declarations [23]. The NesC syntax checker is unable to process Keil C51 language extensions keywords.

114 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 114 One solution for this problem is to modify the NesC compiler and to adopt it to the Keil special keyword structure. Such a proposal is discussed and evaluated in the work of Beck and Johnson [52], but there was no further work done to implement the proposed changes in NesC. The second solution is a workaround in NesC, instead of using Keil original keywords to replace them with definitions representing the keywords of the 851 compiler. The output C code of the NesC compiler is then post processed with a scripting language and the definitions are replaced with the appropriate Keil C51 language extension keywords. Component.nc Component.nc NesC NesC App.c mangleappc App.c MangleApp.c Keil gcc App.hex App.hex Figure 57 The original and the modified tool chain flow In the TinyOS851 working group, this problem was solved with a PERL script called mangle Script and used PERL regular expression. The process of code transformation follows when the NesC finishes the compilation of the source code (Figure 57). The mangle script does a C to C transformation, where the define keywords are replaced with real Keil compiler keywords. The mangle script does not only process keyword replacement, but it transforms code parts that are GCC specific and not supported by the Keil compiler. An example is the processing of the inline keyword [53]. Mangle script adjustments The mangle script solution works well but the implementation does not support all the Keil keywords. For instance, memory target keywords like data, idata are not supported, or is it possibile to map the bit area of the microcontroller on an 8bit variable. We have extended the implementation of the mangle scripts. It was necessary because in the original script implementation no bit variables were supported. Using bit variables is the key to processing the energy-efficient decoding of the radio telegrams, and with the help of bdata, mapping the decoding process of the raw subtelegrams can be rapidly sped up. The way the define transformation is provided is shown in the Figure 58.

115 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 115 NesC uint8_t_data u8datavar; uint8_t_idata u8idatavar; uint8_t_xdata u8xdatavar; uint8_t_bdata u8byte1; uint8_t_sbit bbyte1 attribute((u8byte1at)); uint8_t_sbit bbyte1_1 attribute((u8byte1at1)); Keil uint8 data u8datavar; uint8 idata u8idatavar; uint8 xdata u8xdatavar; uint8 bdata u8byte1; sbit u8byte1 = u8byte^; sbit u8byte1 = u8byte^1; Figure 58 Keyword substitution process Another problem during the porting was the tool chain support of assembler routines. The EO3I chip has, beside the SFR, access to an additional bus called APB. The APB bus is often used in interrupt routines, hence the access time to this bus is critical, and all the APB bus drivers are implemented in standalone assembler files. If we define the call to these driver routines as extern, NesC prefixes the function call with the component name where it is used. This presents a problem, because Keil linker is unable to identify the correct object file with the prefixed function name. One option would be to rewrite all these drivers in C following the guidelines from chapter Another option is to solve this problem using the mangle script. We have chosen the second solution. Each driver routine call in the source code has a prefix asmfn_. The mangle script simple removes this prefix. The last problem of the tool chain adjustment was the call to the Keil standard libraries such as to the library intrins.h. It was not possible to include these header files directly in the NesC components, since the NesC was unable to process these header files. The solution was to declare the intrins functions as extern, and during the execution of the mangle script replace these extern declarations with the correct include file Porting modules to components To be able to perform an objective differential performance measurement between TinyOS and DolphinAPI, we had to select which blocks of the EO3I HW support will be implemented in the TinyOS 2.x components. The minimum requirement was the implementation of the EnOcean radio protocol stack, power management and I/O control. This included the porting of the functions to control the radio front end, the power management module and the I/O peripheral modules. For debug purposes, we have also decided to implement the UART functionality and the partial implementation of ESP2. TinyOS architecture significantly differs from DolphinAPI. TinyOS 2.x execution is based on events, while the DolphinAPI execution is sequential, running parallel tasks. TinyOS uses NesC, while the implementation of DolphinAPI was written in C. Therefore we were forced to completely rework the HAL layer, power_mod, radio_mod, io_mod, timer_mod, uart_mod of DolphinAPI and adjust them to the structure of TinyOS.

116 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 116 Because the implementation of the TinyOS port on EO3I has taken several months, not all HW control parts have been implemented, in order to reduce the implementation effort. In order to provide benchmark measurements between TinyOS and DolphinAPI, the minimum requirement was to implement in TinyOS, the functionality of the radio, power-, io-, timer- and for debugging purposes, the uart module. The architecture of TinyOS running on EO3I is shown on Figure 59. In the next chapters we give a brief overview of the porting procedure. We focus on the problematic aspects that have been encountered during the implementation. TinyOS Application Radio Timer PlatformLED Power ESP2 ERP HalEO3I Uart HalEO3I Radio HplEO3I Timer HplEO3I GeneralIO HplEO3I Power HplEO3I Uart HplEO3I Radio EO3I Figure 59 TinyOS architecture ported on the EO3I platform io_mod The IO module porting was straightforward. We have used the macro definitions from the CC243 chip implementation. These macros enable the easy configuration of the all the EO3I I/O ports. We have extended the initial implementation with the possibility to configure the correct pull functionality registers. The created HPL component uses the standard GeneralIO interface from the TinyOS library, thus the pin control can be used in any other HIL layer of the TinyOS. For debugging purposes, we have implemented the PlatformLedsC.nc timer_mod Initially, we were trying to use the native timer structure of TinyOS as is specified in TEP12 [54]. Timers in TinyOS are implemented with several levels of abstraction, which enables the upper level of the timer components to be both width and precision independent. The TEP recommends that the HPL timer interface should provide either 32kHz, 1ms or 1µs tick precision. In the HPL layer, we were using the Timer HW resources. Timer is 16bit with counter and compare capability and with 2, 4 and 8bit pre-scalers. The clock source is the 16Mhz system clock. By enabling the prescaler functionality, neither the 32kHz or 1ms precision could be reached. Therefore, we have introduced a new precision tag called T16Mhz, and implemented the counter and alarm interface. Both HPL alarm and counter components were transformed to the HIL layer using the TransformCounterC, TransformAlarmC components from the TinyOS library.

117 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 117 This way we have gotten a hardware-independent 32bit AlarmMilli32C.nc and CounterMilli32C.nc components. These components were used in the HilTimerMilliC.nc, which represents the universal millisecond timer in the TinyOS2.x. After the implementation was completed, the component was not working correctly, because the timer events were firing irregularly. The HPL component was working correctly, but in performing all the abstraction with the components, the timer didn t schedule the events precisely. We have started a discussion topic about this problem on the TinyOS mailing list [174]. We were unable to identify the source of this problem. During the timer problem analysis, we realized that too many abstraction levels could cause a potential performance decrease due to the many nested function calls, and would introduce the risk of stack overflow. We have decided to drop the usage of the generic HilTimerMilliC component and instead to implement our own timer component interface. The Timer 1 control was not implemented in TinyOS radio_mod The radio_mod makes possible the implementation of the ERP protocol stack and control of the RF front end of the EO3I. The TinyOS implements the physical and datalink layer of the ERP protocol. Further layers, as well as SmartACK and repeating, were not implemented in TinyOS. For the ERP implementation, three components were created. HplEO3IRadio is a thin software layer on top of the EO3I hardware providing the abstraction for the state machine and registers. The HalEO3IRadio component provides control over the radio state machine, fetching subtelegram data from the buffer, preparing telegrams to the buffer for transmission, converting switch telegrams, etc. This component implements a task sendsubtel for the subtelegram transmission that is posted from the components implemented in the higher layers. This component also implements two signals, one that the subtelegram transmission is finished and another for signaling telegram reception. The ERP component is a hardware-independent part of the OS and makes possible functionalities such as: encoding/decoding telegrams, calculating hash values, realizing subtelegram timing, storing telegrams in HW buffers, calculating maturity time, etc. The ERP component consists of 4 tasks that provide the following functionality: updating the timestamp in the radio telegram buffers. encoding/decoding subtelegrams. switch telegram conversion. processing incoming subtelegrams and merging them into telegrams. The number of tasks is relative high in the ERP component. Although we have made several efforts to reduce the number of tasks, the architecture of TinyOS didn t make it possible. One solution was to merge the tasks, for instance implement the decoding and switch telegram conversion into one task. In such case, the task would monopolize the CPU for longer than 1ms, which would cause a violation of the maturity time. Finally, the RADIO component makes possible interfaces for fetching telegrams from the buffer, or placing telegrams for transmission to the buffer power_mod The power module ensures the power management of the EO3I hardware. In TinyOS,

118 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters 118 the hardware of the EO3I was abstracted using the HplEO3IPower component. Additionally, the Power component provides an interface for controlling switching from RCO to XTAL clock sources and for controlling the standby mode. DeepSleep, Flywheel Sleep and ShortTerm Sleep modes, as well as these timer controls, were not implemented in the TinyOS uart_mod UART mod ensures communication in the serial interface of the EO3I. Additionally, in DolphinAPI the implementation of ESP2, ESP3 is done using these modules. In TinyOS, the abstraction of the UART interface was done using the HplEO3IUart and HalEO3IUart. The HAL layer provided two signals for informing the operating system about the reception or transmission of a byte. The ESP2 component in the HIL layer made possible the implementation of the EnOcean Serial Protocol Stack. The receiving of a serial telegram was accomplished with a task. The transmission of the serial telegram is done as a blocking command. The support of the ESP3 was not implemented in TinyOS Conclusion To test the implementation, a TCM3 platform was created. Based on this platform, the following applications have been created: LedTest performing test of the GPIO ports. RadioTest application receiving telegrams and transmitting it through the ESP2. Testsendtel performs the testing of the telegram transmission interface. Uarttest performs tests on the UART interface. Performance application for the quantification discussed in chapter 4. The implementation of the TinyOS port on the EO3I was successful. We are able to run TinyOS on the EO3I platform and were able to transmit and receive telegrams.

119 3 Operating System For Wireless Embedded Systems Powered by Energy Harvesters Conclusion We have discussed various topics of WESPEH operating system design and implementation. We have defined the core requirements for the WESPEH operating system. Finally, we performed a comprehensive analysis of existing low resource embedded operating systems and wireless sensor network operating systems. The analysis showed that the existing systems are only partially fulfilling the requirements of WESPEH OS. In the next section of the chapter the design challenges of the WESPEH operating system were discussed. We have established the generic architecture of a WESPEH operating system and presented various design procedures. Based on the defined procedures, a new WESPEH operating system called DolphinAPI was presented. The initial implementation of the operating system was realized on the EO3I HW platform. Proving DolphinAPI efficiency requires another benchmarked operating system running on the EO3I HW platform and implementing the EnOcean Radio Protocol stack. The analysis in chapter 3.2 showed that the best OS candidate for WESPEH systems was TinyOS. Therefore we have to ported the TinyOS to the EO3I platform, including implementation of the EnOcean Protocol Stack. The next step in our research is to compare the TinyOS and the DolphinAPI operating system, and prove the suitability of these systems for WESPEH. Significant parts of these chapters have appeared in various publications [3][5][6].

120 4 WESPEH Operating System Quantification 12 4 WESPEH OPERATING SYSTEM QUANTIFICATION This chapter deals with the operating system quantification. The first part of the chapter discusses different OS quantitative methods. In the second part of the chapter, a new vector-based quantification methodology is introduced for WESPEH OS characterization. Using this methodology DolphinAPI and TinyOS are evaluated. The results of the measurements are discussed in the last part of this chapter. 4.1 Motivation and goals In chapter 3.2.3, to determine the feasibility of the OS for WESPEH devices, a pragmatic approach was used by observing and comparing OS parameters and architectures. Such a procedure made it possible to exclude operating systems not fulfilling WESPEH HW resource capabilities. On the other hand, this approach did not answer the question of whether the TinyOS cooperative scheduler makes it unsuitable for WESPEH systems or if Contiki has a better architecture as SOS. Using a purely pragmatic approach, is not possible to determine such if a scheduler architecture violates the application requirement. Therefore, we need a quantitative analysis method through which the performance of the operating systems can be determined. The following part of this research has the following aims: provide a quantification method suitable for categorizing the WESPEH operating system. evaluate TinyOS and DolphinAPI running on the EO3I HW platform, and compare their performance. In the following chapter, existing quantification methods are investigated and discussed to explain which methods are the most suitable for an WESPEH operating system evaluation. 4.2 Related work The quantification method of operating systems is done using benchmarking where the OS performance is measured. There are three common approaches for quantifying OS performance: Macro-benchmarks Micro-benchmarks Kernel profiling Macro-benchmark measures the performance of a system as a whole inclusive of HW and SW. It compares different systems with respect to an application level. A summary of typical macro benchmark suites and their description is listed in Table 15. The macrobenchmarking method is suitable for complex systems where system components are not accessible and the operating system appears to be a black box. In such systems, benchmarking single system parts is not meaningful. An example is parallel computer

121 4 WESPEH Operating System Quantification 121 systems, where benchmarking a single computer would be misleading. The drawback of the macro-benchmark method for WESPEH OS is that it involves too many factors and the benchmark result does not reveal why a system performs well or badly. In a WESPEH system the optimization is a key factor in a successful design, therefore the reason for bad performance must be possible to deduce from the evaluation results. Short Name Name Area of usage NAS Numerical Aerodynamic Simulation Parallel Computing Benchmarks - The NAS Parallel Benchmarks (NPB) are a small set of programs designed to help evaluate the performance of parallel supercomputers. These benchmark suits were developed by NASA [38] PARKBENCH PARallel Kernels and BENCHmarks Parallel Computing Benchmarks SPEC Standard Performance Evaluation Corporation Mixed benchmark family - Designed to provide performance measurements that can be used to compare compute-intensive workloads on different computer systems [36] SPLASH Stanford Parallel Applications for Shared Memory Parallel computing benchmark - Benchmark suite consists of several kernels and applications to evaluate aspects of parallel performance [37] TPC Transaction Processing Performance Council Commercial Applications EEMBC Embedded Microprocessor Benchmark Consortium Embedded System Benchmark - Industry standard for evaluating the capabilities of embedded microprocessors, compilers, and Java implementations according to objective, clearly defined, application-based criteria [4] Table 15 Typical Macro Benchmarks Micro-benchmarks measure a specific aspect of a computing system, such as CPU-, memory-, I/O speed, operating system kernel performance, etc. Micro-benchmarks are more HW oriented than macro-benchmarks. While in macro-benchmarking the operating system is a black-box, in micro-benchmarking the user is required to understand the operating system architecture access down to its lowest level parts. A set of benchmark tests developed by Ousterhout measuring the performance of various OS running on different HW platforms [41] and McVoy's lmbench [42] package are common OS microbenchmark suites [35]. Evaluating of system just by micro-benchmarks has the drawback that micro-benchmarks results can be correctly interpreted only with an understanding which role each micro-workload plays in the complete system. Widespread OS benchmarking is profiling. Kernel profiling is a mechanism that determines where the operating system is spending its time during an operation. Linux kernel has a built-in kernel profiler that collects trace information [14] [35]. While kernel profiling is useful in spotting the performance bottlenecks of an operating system running a specific workload, it often requires unavailable kernel source code from the operating system. Another way of analyzing the performance of an embedded OS is using ad hoc testing

122 4 WESPEH Operating System Quantification 122 methods focusing on the OS requirements. An example of an ad hoc test measuring the performance of the real-time QNX operating system was presented in paper [45]. The test s focus was to measure the efficiency of the OS. For this purpose, simple ad hoc tests were created where the speed of inter-task communication, speed of task switching and timer interrupt handling was measured. Research paper [46] describes performance benchmarks, based on robustness benchmarks. In robustness benchmarking, operating system calls are made with various combinations of valid and invalid parameters. The result of the test is the severity of the effect on the OS caused by the invalid parameter calls. Robustness benchmarking is a good option for operating systems designed for desktop computer or safety critical embedded systems, but the method is not applicable for WESPEH devices. An application-specific benchmarking based on vector and trace methodology is described in the paper [11]. The paper states that standard benchmarking methods, such as micro-benchmarks or macro-benchmarks, often provide only partial information on how well a particular system will handle an application. The authors of the paper argue that the system performance should always be measured in the context of a particular application. The paper discusses application-directed benchmarking techniques and introduces three different approaches: vector-based, trace-based and hybrid-based methodologies. These methodologies were used by several research papers to evaluate operating systems or HW performance. Leopold Martin, the creator of the TinyOS 851 workgroup, has adapted this vector-based methodology in his work [12] and evaluated Mote performances on different HW platforms. The vector-based methodology was also used by A. Brown to evaluate the Apache web server performance described in his thesis [13]. The methodology was furthermore used for desktop operating system and [175] Java Virtual Machines [176] evaluation. In chapter 3.2, several operating systems were analyzed. Most of the research publications presenting the operating systems contained a performance evaluation either using an ad hoc method or macro- or micro- benchmarking. The evaluation of the SOS operating system was performed using the Surge application with the help of macrobenchmarks. The operating system was installed on several wireless nodes and different system characteristics such as code update time, packet forwarding delay, packet delivery ratio, etc. were measured. The same experiments were repeated with TinyOS and the results were compared [67]. LiteOS performance evaluation was also done using macrobenchmark applications. The benchmarking focused on packet throughput measurements, average response times and source code length comparison. As with SOS, the results were compared with TinyOS [68]. NanoRK used an experimental evaluation method also based on macro-benchmarking where the multi-hop packet latency was measured as a function of the system power cycle. [72]. The evaluation of VROS was focusing not only on the performance of the operating system, but it also compared the memory footprint of the application while using SOS and TinyOS. For performance measurements, VROS used micro-benchmark techniques where the system scheduling costs where measured Conclusion As WESPEH operating systems are coupled tight with the application therefore the evaluation of the system has to be made in the context of the application. The common benchmark methods focus entirely on the computational performance, neglecting other important features of an OS such as memory or energy consumption. These features are

123 4 WESPEH Operating System Quantification 123 crucial for WESPEH systems, therefore they have to be considered during the evaluation. No standard definition exists for how the features of an operating system should be measured or compared in an objective manner. Even using the same benchmark package on two different systems does not ensure that the information provides the answer to which system is better, as is shown in a case study from paper [11]. Benchmark results can also often be misleading if they are misinterpreted. As can be seen from the previous chapter, most of the evaluation methods of wireless sensor operating systems was performed using macro-benchmarks. The performance measurements were specially targeted to unique system features of the implemented operating system. For instance, operating systems supporting dynamic code benchmarked the application s upload latencies. OS s with power management implementation were evaluating the influence of the implementation on energy consumption. These evaluation results can t be used as reference for comparing operating systems from the entire system aspect point of view. A further mistake typically made during operating system evaluation is to compare benchmark results of two systems that are characterized with different application scenarios. Since WESPEH operating systems are coupled tightly with the application, the evaluation of the system has to be made in the context of the application. To derive an appropriate quantification methodology for WESPEH operating system, we can summarize the result of this discussion and define the following requirements: methodology must characterize the entire WESPEH OS. methodology has to consider OS performance, energy influence, footprint. methodology must consider the application influence. quantification results of the methodology has to be comparable. methodology must offer the possibility to determine which components of the OS behave badly. From the discussed benchmark methods Seltzer method was the only one that performed the evaluation in the context of the application. Consequently we adapted Seltzer methodology and enhance it with the energy, footprint and parallel execution aspect. In our proceeding we were motivated by Leopold Martin work [12] who adapted Seltzer methodology to evaluate the Mote performance. Leopold in his work was considering the hardware influences while in our proceeding we will consider the performance from the operating system point of view. Our work is the first to propose a performance methodology in the context of WESPEH operating systems inclusive energy consideration.

124 4 WESPEH Operating System Quantification WESPEH OS Quantification Methodology This chapter introduces a step-by-step WESPEH OS quantification methodology definition based on the requirements defined in the previous chapter Definition of the methodology The first step for finding a methodology for WEPSEH OS quantification is to define the benchmark parameters that characterize the system. We can define these parameters by deriving them from the key requirements placed on WESPEH OS, as defined in chapter 3.1. The key parameters that characterize a WESPEH OS are execution time, power consumption and memory footprint. execution time power consumption memory footprint [ ms] [ mw ] [ kbytes] Execution time is derived from the hard real-time and parallel task requirements (3.1.5, 3.1.6) and gives overall information about the operating system s execution speed. The power consumption is derived from the power management requirement (3.1.1). It defines how power efficiently controls the application execution in the operating system, and how it abstracts and optimally uses the HW power management blocks. The footprint parameter is derived from the limited HW resources requirement (3.1.3). It indicates the OS capability to run on limited memory microcontrollers. To understand the performance of a specific operating system the system has to be decomposed to primitives. Each primitive operation in an operating system takes a fixed amount of time to be completed. By characterizing the performance of these primitives, it is possible to relate the analysis results to the complete system performance. A primitive operation in a WESPEH OS is either a system call to an operating system function or an event. As the basis of the breakdown in the WESPEH OS, we will use the generic WESPEH OS architecture discussed in chapter We will consider only the high level layers of the operating system, in order to avoid the influence of latencies introduced by the hardware abstraction layer that is HW platform-specific. These operations are the following: radio communication peripheral control power management task switching Note that these operations are not yet primitive and we need to break them down further. We can break down the radio operation into radio RX and radio TX primitives. In the case of the peripheral operation, each peripheral system call is defined as an OS primitive operation. For instance, reading an I/O pin, or fetching values from the A/D converter are

125 4 WESPEH Operating System Quantification 125 primitives. The power management primitive operations are system calls that change the system power mode. The task switching primitive operation is the scheduler that ensures timing and execution of various tasks. The list of all primitive operations characterizing a WESPEH OS is: O = o, o, o, o... o, o... o } (4.1) { radio_ rx radio_ tx scheduler powerm1 powermn peripheral1 peripheral N As discussed in chapter there is a strong dependency between the application and WESPEH OS architecture. Therefore, standalone OS primitive operations and their benchmark parameters do not cover the characterization of the whole system. For instance, a certain application would work very well on WESPEH OS type A, while another type of application would have had much better performance on WESPEH OS type B. This leads to the conclusion that if we want to do a meaningful evaluation of WESPEH OS, we need to map the application behavior onto our quantification methodology. When measuring OS performance with application contents, it is also important to understand which parts of the OS are representing the performance bottlenecks. For instance, if the application spends only a few percent of its time executing OS functions; it is not fully utilizing the OS resources. In such a case, any effort to tune the OS will not bring much of a performance increase. The primitive operation performances are represented as a vector quantity and the vector collecting this information is called system characterization vector. The primitive performance is measured by running an appropriate micro benchmark. The vector itself is meaningless - it represents only summarized micro benchmark values. To obtain a meaningful result, the system characterization vector has to be combined with a corresponding application vector. Each component in the application vector represents the application s utilization of the corresponding primitive operation as either a frequency, number of bytes or other quantity [11]. Once the application vector is determined, it can be used with different system characterization vectors. The final benchmark of the system can be calculated as a dot product of the system characterization vector with the application vector: System performance = s. a (4.2) where s is the system characterization vector and a is the application vector. I the next chapters we will derive the vector parameters for WESPEH OS System characterization vector To apply the Seltzer method to a WESPEH operating system requires us to first determine the parts of the system characterization vector. For the initial step we can use the set of primitive operations defined in the previous chapter. We have to select the appropriate benchmark parameter for these primitive operations. From the defined benchmark parameters, the best parameter that characterizes the operating system primitive is the execution time. The execution time parameter gives overall information

126 4 WESPEH Operating System Quantification 126 about the operating system reaction time. The longer the OS overhead latencies take, the more energy is consumed by the application. To determine the execution time parameters of a primitive operation we can use classic micro-benchmark methods in which the execution time of the system calls is measured on a real HW during a particular application execution. We have applied this method in practice and made several measurements on a real HW with different applications. After analyzing the results, we have determined that there are several problems with this approach. The first problem is the variation of execution time of system calls. For instance, the duration of a Radio Rx system call when fetching a packet from the radio buffer is dependent on how many packets are currently waiting in a buffer for the application. The more packets which are in the buffer, the longer the call will take. In addition, the measurement is influenced by parallel task executions and interrupts. Another problem is that the Radio Rx primitive execution time cannot be entirely characterized by system call durations. A Radio Rx primitive in WESPEH system is composed of several radio functions executed parallel in the OS and hidden from the application. One way to determine the time parameter of these functions is to measure the latency from the point a radio packet arrives in the system until it is processed by the OS and transferred to the application. In such measurements, the problem resides again in the fact that the execution of other parallel tasks and interrupts are influencing the measurement results. The final problem with this measurement method is that each application behaves differently and represents different loads on the operating system. Due to the system influences on the primitive measurement we dropped the execution speed measurements on a real HW. The measurements did not give exact information why the OS behaves badly. An option for obtaining precise results using HW measurements would be to define benchmark package with various typical applications, which would vary the load on the analyzed primitive. Several measurements would be performed and the results statistically evaluated. Such an approach assumes that the benchmark application runs on the different WESPEH OS without major modification. This is not the case. As discussed in chapter 3.3.2, the applications have a strong dependency on the WESPEH OS, thus every benchmark application would need to be ported to the measured platform. We see a solution to the problem of exact time measurement using execution profiling. As discussed in chapter , the source code is available for most of the WESPEH OS. Using a simulator and an executer profiler, the execution time of functions composing the primitive operation can be measured. In a measurement performed by a profiler, all parallel function influences can be eliminated, thus the result is very precise. At least two measurements have to be performed. In the first measurement, the target primitive operation has to be set up for the best case execution; in the second measurement, the target has to be set up for the worst case execution time. An additional advantage of this method is that execution profiles, apart from the time measurement, can give additional useful statistical data, such as the percentage of code coverage, depth of stack usage, etc. We can use these data to get a better picture of the characterized primitive operation. A further advantage of this method is that the measurement focuses on the performance of the implemented code, and the latencies introduced by the HW are not considered in these measurements.

127 4 WESPEH Operating System Quantification 127 By having the best and worst execution time of the primitive, the typical execution time of the primitive has to be determined. There are various possibilities using: Arithmetic mean Harmonic mean Geometric mean Weighted harmonic mean The selection of the correct method is not easy, computer scientist have been arguing which mean is more appropriate for several decades. Various papers state that one or the other mean is closest to relative performance of a system. In paper [156], it is stated that the arithmetic mean can be used as an accurate measure of performance expressed as time. In paper [157], the usage of the weighted harmonic mean is recommended where it is claimed that the geometric mean does not represent anything meaningful when aggregating performance metrics over benchmarks in a suite. Fleming and Wallace, in paper [158] recommend the usage of the geometric mean and warn that it is a mistake to use the arithmetic mean for normalized benchmark results. In paper [159], the challenges of means are discussed and the conclusion is made that, after analyzing several hundreds of benchmark results, the influence of various mean is small. Based on this paper and on the fact that in our evaluation method the execution time is not the only performance parameter we can conclude that the selection of the mean algorithm doesn t have a significant impact on the result of our evaluation. For the execution time calculation we will select the algorithm of the arithmetic mean. t t r t = t t t t t RxBest TxBest schedoverheadworst powerm1worst powerm NWorst peripheral1worst peripheral NWrost + t 2 + t 2 + t 2 + t 2 M + t 2 + t 2 M + t 2 RxWorst TxWorst schedoverheadbest powerm1best powerm N Best peripheral1best peripheral N Best (4.3) Applying this method we can get the characterization vector of the WESPEH OS like shown in (4.3) where t is the execution time of the primitive in millisecond.

128 4 WESPEH Operating System Quantification Application vector The application vector characterizes how an application utilizes the primitive operations of the system characterization vector in a way independent of the operating-system. The application vector components have no unit and they must be same dimensions as the system characterization vector. Our system characterization vector represents the execution time of several primitives. For each primitive operation we need the utilization value. One easy way to determine how excessively the OS primitive operations are being used is by collecting function call frequencies. Such an approach can be misleading when comparing event-based or scheduler based operating systems. Let us consider an application that is awaiting a packet from the radio interface. The application running on a scheduler-based OS regularly makes a system call to receive the packet. Since the radio buffer is empty, the call returns immediately. Let us consider the 6 th call result in a successful packet reception. In an event-based OS, the application will call the function to retrieve the radio packet only once; when the OS signals that there is a new packet in the buffer. If we derive the application vector by monitoring function calls of the scheduler, we would get incorrect information about how intensively the application utilizes the radio Rx interface. Another way to determine OS utilization by an application is by analyzing the application trace log. We can create a trace log of the application by injecting pin toggling operations in the measured system calls and OS tasks. Using a logic analyzer, we can collect the trace information of the application runtime. From the trace log, we derive the exact call frequencies of the primitive operation. The call frequencies of the primitives will be the parameters of the application of vector a. The application vector for our system is: a a a a r a = M a a M a RadioRx RadioTx Scheduler Powerm 1 PowermN Peripheral 1 Peripheral N (4.4) where a represents the primitive call frequencies Power consumption vector The way in which an application and operating system utilize the underlying hardware has a significant impact on the complete power dissipation of the system. Different studies in papers [121][122] observed that the choice of algorithm and other high level programming decisions measurably affect the system power. For instance, using C code optimization methods discussed in chapter can have a significant energy

129 4 WESPEH Operating System Quantification 129 consumption impact. The same effect can be observed if the operating system manages the HW power resources effectively. For example, a floating-point division operation executed with active radio interface can consume three times as much energy as executing the same operation with inactive radio interface. All these examples indicate that for a WESPEH OS evaluation, the power consumption parameter has to be considered. Several techniques exist to determine the software power consumptions. In the simulation-based approaches, the processor architectural model is used and the software power consumption is estimated through simulation at different abstraction levels [124]. This method offers high flexibility for experimenting, nevertheless, commercial microprocessors circuit-level implementation is not available. Another common approach is to determine the instruction power consumption, and by combining this information with the SW analysis of the instruction level [123], the complete SW power consumption can be estimated. Using such a method does not cover the measurement of dynamic power management of the SW, where the CPU is entered into standby mode, or unnecessary peripherals are switched off in order to save power. The most accurate results can be obtained by measuring the physical energy consumption of the application executed on the real HW platform. We can apply this measurement method by measuring the power consumption of each operating system primitive operation. A special application can be created that utilizes only one primitive operation in a loop with default parameters. During the implementation of these applications, we have to make sure that there is no other parallel task execution occurring. We measure the power consumption of the primitive as the function of time. The measured values we get are summarized in a power consumption vector: p p p p r p = M p p M p RadioRx RadioTx Scheduler Powerm 1 Powerm N Peripheral 1 Peripheral N (4.5) where p is the energy cost of the primitive either in milliwatt-seconds [mws]. One could argue that the power consumption vector represents the HW block s constant power consumption, and that these values are HW dependent, thus constant for different WESPEH OS s. In fact, this may be the case, if the analyzed OS primitive operation would not adjust the HW power modes during execution. An example of this scenario would be if the Radio Tx primitive system call would immediately turn the radio Tx state machine on, and would turn it off after the packet transmission was finished. In such case, the power consumption parameter would equal to the radio Tx HW power consumption. On the other hand, in a WESPEH OS, the SW tries to reduce the power

130 4 WESPEH Operating System Quantification 13 consumption by applying a different algorithm. For instance, the OS can put the system in standby while waiting for the radio Tx state machine to start. Alternatively, the OS can switch on the Tx state machine immediately before the packet transmission. The ways in which these algorithms are applied are operating system specific and have an influence on the power consumption. Furthermore, each primitive makes various function and system calls to the OS. All these calls have a certain overhead dependent on the OS driver and interface implementations. As the power consumption vector incorporates these overhead latencies, it gives more precise information about how efficient the OS implementation is. For prove of this hypothesis, please read the results of the evaluation in chapter System matrix We have defined a methodology where three vectors characterize the WESPEH OS. The weakness of the current methodology is that it does not reflect the strategy of parallel primitive operation execution. In all vectors, we consider that the primitive operation s execution happens in a consecutive manner, and the actual primitive operation is the only running task in the operating system. Latencies introduced by scenarios where primitive operations are blocking each other, or where one awaits the output of another, are not modeled in the current vector definition. The strategy of primitive operations execution significantly influences the WESPEH OS evaluation result, because it has a major influence on both execution time and power consumption. We can demonstrate this influence with an example. Let us consider the following scenario: we have an energy-autonomous application with the following simple functionality, to receive a packet through the radio interface and compare the packet data with data saved in the flash memory. The execution process is as follows: first, in order to receive the packet, the application turns on the radio interface. While waiting for the packet, the application starts reading out the data from the flash to store it in a variable. As soon as the packet receiving is finished, the radio interface will be turned off and the data extracted from the packet will be compared to the variable. In our example, we consider two primitive operations, RxPacket and FlashRead. We will analyze the runtime of this scenario on two operating systems: one with a cooperative and the other one with a preemptive scheduler. Let us consider that the FlashRead primitive operation is composed of one task. The RxPacket primitive operation is composed of several tasks: a raw packet receiving task, a packet decoding task, a checksum proving task and a task that stores the packet in the SW buffer. The complete execution time of the RxPacket primitive operation is t 1 and the Read Flash primitive operation is t 2.

131 4 WESPEH Operating System Quantification 131 Time [ms] Figure 6 OS with cooperative scheduler In Figure 6, we can see the process of execution with an OS based on a cooperative scheduler. There are two timelines. One represents the process of RadioRx. This timeline shows the runtime sequence of the RxPacket primitive operation and application task that turns the radio interface on and off. The other timeline represents the process of Flash reading. In a cooperative OS, all tasks run in competition. We can see that the packet is ready for application processing at 45 ms. At this moment, the application would receive an event and would turn off the radio if the FlashRead task were not already using the CPU. The Radio will stay turned on for the whole reading flash process, until 6 ms. When we ignore the time waiting for the packet, the complete RadioRx process execution time in this scenario is t1+t2. The complete power consumption of the application will be increased by t2.pradiorx In Figure 61, we can see how this scenario is performed on an OS with preemptive scheduler. The read task of the OS is interrupted as soon as the event packet is available and is triggered. At this moment, the application task takes over the CPU and turns off the radio interface. The read flash primitive execution will take 4ms longer, but the complete energy consumption of the application will be significantly lower than in the previous case. Time [ms] Figure 61 Example task on OS with preemptive scheduler, time in ms

132 4 WESPEH Operating System Quantification 132 Based on the experience we gained from the above application scenario, we define a system matrix M of dimension N x N, where N is the number of primitive operations in the system characterization vector. The system matrix models the strategy of primitive operation execution by encoding parallel states of primitive operations. The rows and columns represent the primitive operations. The elements of the matrix represent the delay or enhancement factors of the parallel execution of two primitive operations. If all diagonal elements equal 1, and other elements equal, we talk about sequential execution of tasks. Let the matrix functionality explain the example scenarios. The following system matrix characterizes the Figure 6 scenario, where parallel tasks in a system with cooperative schedulers are blocking each other: 1 1 M = (4.6) 1 The same scenario in a system with preemptive schedulers is shown in Figure 61 where parallel execution of the tasks just slightly influences the execution time, as described by the following matrix: 1 M = (4.7).1 1 In the event that a parallel execution speeds up the radio operation, such a scenario is described with a following matrix:.8 M = (4.8).3.7 This situation can happen when one process awaits for an event and during this waiting time other processes can be executed. Finally, a system matrix where all tasks run sequentially and their execution do not influence each other is as follows: 1 M = (4.9) 1 The system matrix is always multiplied by the system characterization vector. According to the definition of the system matrix, we should note that the matrix is both application and operating system dependent. The behavior described in the system matrix depends on the application flow. A certain

133 4 WESPEH Operating System Quantification 133 scheduler type can give a good performance with a certain application while the same type of scheduler can have a bad performance with another application flow. Thus, a WESPEH OS with a preemptive scheduler strategy does not ensure that 1% of all the application will consume less energy in comparison to an OS with a cooperative scheduler. A preemptive OS scheduler has a significant overhead in contrast with a cooperative one. Applications where the events happen in a sequential manner may cause a preemptive scheduler to perform worse than the cooperative one. In the examples, we have described one scenario using the system matrix that represented a certain state of the operating system primitive operations. To model the whole system precisely, the whole application flow, with all combinations of the application states would have to be represented as different system matrixes. This would make the model very complex, therefore for the sake of simplicity we will consider that each element of the system matrix models the average behavior of the application flow. The system matrix can be determined by analyzing the operating system scheduler strategy, and by analyzing the trace log of the current application Memory footprint The time is energy in a WESPEH system, thus when evaluating OS s, the RAM and ROM consumption of the application and OS binary has to be considered. We will consider two parameters: m ram and m rom. These two parameters will be measured for every application that is evaluated with the OS Summary Based on the discussion in pervious chapters we can define the performance of the WESPEH operating system. Definition 4.1: Let O = o, o,..., o } be a WESPEH operating system defined as a tuple { 1 2 n of primitive operations, and o i, i {1,..., n} is the primitive operation, let t s o 1 r s = M = t son o best 1 o best n + t 2 M + t 2 o worst 1 o worst n (4.1) be the system characterization vector dependent on the WESPEH OS where the component s oi is the arithmetic mean of the primitive operation execution time o i, i {1,..., n} expressed in milliseconds [ms].

134 4 WESPEH Operating System Quantification 134 Let po r p = M p 1 o n (4.11) be the power consumption vector dependent on the WESPEH OS where the component p is the energy cost of primitive operation o, i {1,..., n } oi i expressed in milliwattseconds [mws]. Let M R n n m M = M m 11 n1 L L L m m 1n M nn (4.12) be the system matrix where m ij characterizes the parallel execution of primitive operation oi and o j, i, j {1,..., n}. The matrix is dependent on the WESPEH OS scheduler architecture and application execution trace. Let ao r a = M a 1 o n (4.13) be the application vector where o i, i {1,..., n}. Then we know that aoi is the call frequency of the primitive operation T T [( s M p) ] T Π = a ) (4.14) is called the performance of the operating system composed of primitives operation o i, i {1,..., n}. is the direct product of the vectors. The triplet ( Π, m ram, m rom ) contains the quantification parameters of the WESPEH operating system. Using these parameters, a certain application runtime on different WESPEH OS s can be evaluated and compared. To get precise and objective evaluation results, the measurement of the vector parameters has to be done on the same HW platform. If the OS source code needs to be compiled for objective results the assumption is that the same compiler should be used and linked with the same optimization settings. We have applied the methodology to compare the DolphinAPI and TinyOS. The results are discussed in the next chapter.

135 4 WESPEH Operating System Quantification DolphinAPI and TinyOS evaluation In the previous section, we have defined a methodology for WESPEH OS quantification. In this chapter, the methodology will be applied to evaluate evaluate DolphinAPI and TinyOS. The aim of this chapter is to determine whether a WESPEH application performs better on DolphinAPI or TinyOS. In order to get an objective result, we make the following assumption. Both operating systems are: implementing the same feature set and the radio protocol stack. using the same C compiler with the same optimization level. running on the same HW platform. executing an application with the same functionality and feature set. To prove the correctness of the measurement results, additional micro- and macrobenchmark measurements are made Application used for OS evaluation For the operating system evaluation, we have decided to use a simplified version of an WESPEH heating regulator described in chapter The reason for this choice was because this application utilizes several parts of the operating system as: Figure 62 State diagram of application used for OS evaluation

136 4 WESPEH Operating System Quantification 136 The WESPEH regulator is powered by the temperature differences between the hot and cold pipes of the radiator. To eliminate extra power consumption factors in our measurement, no real heating valve hardware is attached to the application. The functionality of heating control is emulated. We will consider in the application that the heating valve control is provided by an external circuit controlled over the UART interface. On the other hand, the radio, UART communication and I/O interface control are real. This way we can focus purely on the operating system evaluation parameters. The detailed software process is described in Figure 62. The functionality of the application is as follows: The aim of the application is to measure the actual temperature of a heating valve and transmit this information to the central device; The central device evaluates the transmitted information and responds with a radio command; This command contains regulation instructions to the heating valve; The control information will be transmitted over the UART interface to the heating valve control circuit; After this process is executed, the system will enter in deep sleep mode. In our measurement scenario the deep sleep mode will be replaced with a systematic restart of the application. We will perform this execution several times to get an overview of how the system behaves over a longer time period. In DolphinAPI, the execution of the application was done using the system scheduler. Although it would be possible to run the application using the ultra-low power function, and the execution would be more energy efficient, our aim was to include the scheduler influence of the operating system behavior into the evaluation. The application runs as a small state machine. The application performs system calls and the reception, transmission of packets is effected using the system scheduler. The application in TinyOS was run as two tasks and several asynchronous events: task radiotx task measure event esp2.gettelegram event radio.telegramtxfinished event radio.telegramreceived The measure task was performing the A/D measurement emulation. After the measurement was completed, the execution of RadioTx task was posted to the system scheduler. The task RadioTx initiated the transmission of a telegram with the measurement information and left the system in standby mode. The event of transmission completed wakes up the system from standby and enables the radio rx interface. After this execution has been finished, the application waits for the event of an incoming radio packet. The event of an incoming radio packet re-activates the system and schedules the transmission of the radio packet through the UART interface Measurement Setup While both operating systems run on the EO3I platform, and implement the EnOcean radio protocol for the measurements, we have decided to use two EDK3 [16] kits. To simplify the measurement, instead of using energy harvesters, line powered devices were used. The block diagram of the measurement setup is shown in Figure 63. For the measurement, two evaluation boards, EVA3 with the TCM32 [164] modules, were

137 4 WESPEH Operating System Quantification 137 used. The TCM32 module is a transceiver module equipped with the EO3I microcontroller, balun and a 5Ω SMA interface. The EVA3 is an evaluation board enabling easy access to the TCM module interfaces. The TCM32 was located in the EVA3-B board and was designated as the device under measurement. This is the hearing regulator. The TCM32 located in EVA3-A is the emulation of the central device. Figure 63 Performance measurement setup schematics The RF connection of the boxes was done using SMA connectors attached to the box and a semi-rigid coaxial cable. To get the best RF performance, 4dB attenuators were used to sink the signal to approximately -4dBm. Using a power splitter, the RF signal was monitored with a spectrum analyzer. The measurements were performed in an environment with lots of RF communication. Therefore, to avoid the interference of external RF signal, the EVA boards included modules were placed in a shielded box. To create a detailed trace of the application runtime, the I/O interface of the TCM32 modules were be used. The six GPIO ports of the TCM32 module located in the EVA3-B board were connected to a logic analyzer. We injected pin controls to different parts of the operating system. Using a logic analyzer, the pin s state is monitored during the application execution. The power consumption of the system is measured using a shunt resistor. A shunt resistor is attached to the system in series as showed on Figure 66. Junctions V+ and V- are the connection junction to the EVA board. Junction A, B are the measurement points. Using the voltage drop on the resistor, the current can be calculated with the help of Ohm s law. I A V+ R = 1Ω B V- Figure 64 Shunt resistor The shunt resistor was connected to the Tektronix Oscilloscope through an active

138 4 WESPEH Operating System Quantification 138 differential preamplifier. With this technique, the voltage will be amplified and the current flow of the application execution can be visualized and logged with the oscilloscope. The EVA3 boards were powered by the PC USB ports using the ESP3 programmer. The ESP3 programmer was also used as a programming and UART interface to the PC. To see the correct functionality of the application, the UART interface was monitored using a serial terminal. DEVICE-B DEVICE-A PREAMPLIFIER Programmer OSCILLOSCOPE SPECTRUM ANALYZER LOGIC ANALYZER Power splitter Figure 65 OS evaluation measurement setup The complete measurement setup is shown in Figure 65. The measurement process was as follows: The application was compiled with the operating system being tested and was downloaded to the EVA3-B board; A client application responding to the packets simulating the central device - was downloaded to the EVA3-A; The trigger on the oscilloscope and in the logic analyzer is set and both boards are reset at the same time. The application is executed while the following data is logged: pin voltage toggling (trace log) current flow through the shunt resistor (current consumption) UART packet message exchange (debug) RF signal (debug) The correct execution of the application is monitored through the PC UART interface, where it can be seen which data was exchanged. Additionally, the RF signal is monitored with the help of a spectrum analyzer Applying the methodology With the data available, the methodology can be applied to determine on which OS the application behaves better. The operating system is evaluated as the function of the application. The first step is to determine the relevant OS primitives the application uses. From the described application, we can derive the following primitive operations:

139 4 WESPEH Operating System Quantification 139 O = o, o, o, o o } (4.15) { radio _ rx radio _ tx s tan dby uarttx ana log The second step of the evaluation is the determination of the system characterization vector. For this vector, the worst and best case execution time parameter of each primitive is needed. As discussed in previous chapter, the best method to determine these values is by using an execution profile. We use the Keil simulator, debugger environment. With the help of the execution profiler, the worst case and best case execution times of primitive operations can be determined. To have a precise result, we have created various test cases that apply various loads to the primitive functions. We will demonstrate this on the following example from the DolphinAPI analysis. The radio_rx primitive is composed of six functions, as described in Table 2. The purpose of the function radio_gettelegram is to fetch the packet information from the operating system. The execution of this function can vary, depending on the length of the packet, destination ID, radio filter set, etc. To determine the best and worst case execution speeds, a test is executed with various scenarios in the simulator. In the first scenario, the function fetches a packet with shortest length, no destination ID or filter set. In the second scenario, the function fetches the longest packet, also with no destination ID or filter set. Further scenarios combine these parameters, and repetitive calls are made to this function. During the scenario execution, the profiler monitors the speed of the execution, and the executed code coverage of the function. The resulting arithmetic mean of worst case and best case times will be used to calculate the primitive system characterization vector. In DolphinAPI, the measurements with the tests are straightforward, since the execution is performed in C code. In TinyOS, the measurements are more complicated, which is caused by the NesC compiler. In TinyOS, the test cases are applied in the compilation chain after the mangle script, where the NesC compiler has already translated the OS and application code, as shown in Figure 66. Component.nc NesC App.c Applying testcases mangleappc MangleApp.c Keil App.hex Figure 66 Test case application in TinyOS The code of test cases is inserted into the appropriate function where the primitive functionality is executed. For instance, the RadioMac.decodeRx function in TinyOS is processing the incoming packets. The execution speed depends on various properties of

140 4 WESPEH Operating System Quantification 14 the packet such as the hash value type of the packet (CRC/Checksum). After the translation of the RadioMac module from nesc to C, the test case is applied to the scheduler call of decoderx function. The test adjusts the state of the receiving buffer to various packets, and again various scenarios are executed using the simulator. The detailed results of the simulation measurements can be found in Table 2, Table 21 in Appendix D. From these results, we can create the system characterization vector for both operating systems: S DolphinAPI = 25, TinyOS = s r (4.16) As a consistency check, the simulation values can be compared with the actual measured execution time determined from the trace log shown in Table 25 in Appendix D. Note that in the simulation values, no HW delay (for instance, delay through the UART Baudrate or interrupt events) is considered. The following step of the quantification methodology is taken to determine the application vector and system matrix. The sampled data from the logic analyzer is exported to CSV files and imported to Excel (Table 22, Table 23 in Appendix D). The execution state of the primitives can be encoded as a binary value. For example, let s consider that the Analog primitive and UART are executed at the same time while no other primitive is running. The least significant bit will be the Analog primitive, and the most significant bit will be the UART. In such a case, we can encode the state of parallel execution as b11 = 17. With the help of a pivot table, the analysis of all the states can be performed. The results of this analysis can be found in Table 26, Table 27 in Appendix D. Based on the trace log analysis and by knowing the scheduler strategy we can create the system matrix of both operating systems. First we will determine all primitive operations' parallel execution states. We create the system matrix by weighting the parallel execution states. Note that during the calculation if two primitive operations run parallel we consider in the matrix the primitive operation having the higher power consumption. This can be interpreted by populating the row of the primitive operation with the higher power consumption. For the sake of simplicity, we consider fair CPU arbitration between parallel-executed primitive operations by populating matrix elements with 1/2 value. The behaviors of parallel tasks that may block each other caused by the cooperative scheduler in TinyOS are represented as an increase of the element value by 1/2. We apply this value as an addition to elements where this behavior can significantly increase the power consumption, in our case on the parallel execution of Analog & UartTx and on RadioTx & UartTx. The calculation details can be seen in (8.1) and (8.2) in Appendix D. The resulting system matrixes are the following:

141 4 WESPEH Operating System Quantification M DolphinAPI =.5.5, M TinyOS = (4.17) The application vector determination is in this simple scenario straightforward, as each primitive was executed exactly 1 times. We derive the application vector from the trace logs created with the logic analyzer. 1 1 a r = 1 (4.18) 1 1 The power consumption vector determination is based on the current measurement performed on the shunt-resistor. The current flow of both operating systems is shown in the diagrams in Figure 67 and Figure Current [ma] Energy [mws] Time [s] Figure 67 Current flow of WESPEH running the application on DolphinAPI

142 4 WESPEH Operating System Quantification 142 To get the energy consumption of the system, the current consumption has to be integrated. The result of the integral is designated as a red line. For the methodology, the energy needs of the primitives have to be determined. This can be calculated the following way: The trace log timing has to be synchronized with the energy measurements, to see in which moment which primitive operation was executed; This way, the time sequences of the primitive operations can be determined; The next step is to calculate the integral of these time sequences; In this manner, we get the energy consumption of the primitive, which will be the value for our power consumption vector. The red circles in the diagram represent the time synchronization points of the primitives Current [ma] 2 8. Energy [mws] Time [s] Figure 68 Current flow of WESPEH running the application on DolphinAPI The final power consumption vectors derived from the measurements for both operating systems are the following: p r DolphinAPI = p r TinyOS =.216 (4.19) Now that all vectors are known, we can perform the performance calculation based on the equation (4.14). The details of calculation can be seen in (8.3), (8.4) in Appendix D. The performance parameter results are the following:

143 4 WESPEH Operating System Quantification 143 Π DolphinAPI Π TinyOS =1.782 = (4.2) As discussed in chapter , in addition to the performance parameter, the memory consumption parameters are needed. This can be determined from the logs of the compiler. The values are summarized in Table 16. CODE [bytes] XDATA [bytes] DATA [bytes] DolphinAPI TinyOS Table 16 Comparison of memory consumption of the application running on two OS The analysis of the performance evaluation is discussed in detail in the next chapter Results analysis By looking at the memory consumption in Table 16, we can determine that the memory requirements of both operating systems are similar. The footprint of the DolphinAPI with the application is 613 bytes larger than TinyOS. On the other hand, DolphinAPI uses 433 bytes less XDATA than TinyOS. Both operating memory resources are thin enough to run on most ultra-low power microcontrollers. From the calculation in (4.2), we can see that the application executed on DolphinAPI behaves better than on TinyOS. The application performance running on DolphiAPI is around 1.5x better than for TinyOS. This result was already possible to predict from the trace log and energy measurements. By comparing the current flow in the diagrams shown in Figure 67 and Figure 68, it can be determined that the execution time of the application in TinyOS took 28ms longer than in DolphinAPI. This is an interesting fact, since when looking at the system characterization vector (4.16) of both operating systems, we can see that the vector values indicate that the execution duration of some primitives in TinyOS are faster than in DolphinAPI (radiorx or Standby). The system characterization vector is created based on the micro-benchmark simulation method. Therefore the scheduler, event processing overhead and other influences are not embedded in these values. This is the reason why standalone micro-benchmark results can be misleading. In our evaluation method, the real application execution and all system influences are embedded in the power consumption vector. Thus, all these influences are visible in the final evaluation. As discussed in previous chapters, the major energy needs in a WESPEH originate in the radio receiving interface (see current consumption Rx from [161]). From the measurements, the power consumption vector (4.19) indicates that in both systems the most energy was consumed by the radio packet transmission. This is explained by the fact that the transmitter A responded to the packet very quickly, therefore the radio Rx interface was only active for a very short time. This proves the fact that it is important to always measure the system with the executed application. In a macro benchmark where only the HW power consumption values would be considered, this fact would not be

144 4 WESPEH Operating System Quantification 144 visible. Further measurement shows that the way TinyOS has controlled the power resources of the microcontroller was not as energy efficient as the way DolphinAPI did. The energy consumption of both operating systems is compared in Figure DolphinAPI TinyOS Energy [mws] Time [s] Figure 69 Energy consumption comparing DolphinAPI and TinyOS During the porting of TinyOS to the EO3I platform, the implementation of the power component was motivated by the source code of DolphinAPI. Although the type of implementation can have a certain influence on the energy consumption, this does not explain the major differences. We consider that TinyOS has the same access to the microcontroller resources as DolphinAPI does. The explanation of the energy difference can be explained by the operating system s architecture and scheduler differences. The scheduler in TinyOS is utilized more often since it is responsible for the management of events and tasks. Therefore, the scheduler overhead in TinyOS is more significant than in DolphinAPI. Every time a new event occurs, or a task is started or stopped, the scheduler is invoked. In DolphinAPI, the scheduler is invoked once in 1ms. Since the tasks are constant and scheduling happens only on the system level, no extra overhead is represented. Further reasons for the increased power requirements in TinyOS can be explained by the cooperative behavior of the scheduler. Cooperative tasks may block the system for a certain time, which may have the result that turning off the radio interface can take longer than in DolphinAPI. Also, the switch of microcontroller power modes can only be utilized at the moment when the application receives the processor time. The proof of this fact is shown on diagram in Figure 7.

145 4 WESPEH Operating System Quantification TinyOS 35 DolphinAPI Current [ma] 2 Current [ma] Time [s] Time [s] Figure 7 Current flow of a tasks running on TinyOS and DolphinAPI The figure shows the current flow during the analog measurement, radio transmission and UART transmission in TinyOS and DolphinAPI. Despite the fact that the duration of both routines is different, in the areas marked red the differences between the OS s control of the microcontroller energy control can clearly be seen. The first circle indicates that probably turning off the analog block in TinyOS took longer than in DolphinAPI. Furthermore, switching off the transmission state machine and turning on the receiving state machine was more energy efficient in DolphinAPI (second circle). The third circle indicates that in DolphinAPI there was enough time to enter the CPU at standby before the packet processing was started. In TinyOS, the delay represented by the overhead causes the event of a received packet to come sooner, since the processor could enter into power saving mode. The defined evaluation methodology gives an indication about the operating system in which the application behaves better or worse. It offers the possibility to quantify the operating system, and also shows where the bottlenecks in the system are. From all these results, we can conclude that in this particular scenario, DolphinAPI has more appropriate architecture for the runtime of the application, and can control and handle the WESPEH HW more energy efficiently Proof of TinyOS bottlenecks The results of the performed measurements from the previous chapter indicate that the way TinyOS implements the EnOcean protocol stack and handles the radio interface control is not very efficient. To prove our evaluation s correctness and to indicate this bottleneck, we have performed additional micro- macro- benchmark measurements. For the measurement, the same HW setup was used as described in chapter Three more applications were implemented in both TinyOS and DolphinAPI. The focus in the applications was placed on radio interface stress testing. The first measurements focused on stress testing of the system through the radio interface. The aim of this test was to prove the feasibility of the DolphinAPI scheduler design and to point out the problems of the TinyOS cooperative scheduler. We have implemented an application where several radio telegrams are exchanged between device A and device B. The reception and transmission was controlled through the UART interface using a desktop computer. In the first test case, 1 telegrams, each containing one subtelegram with different time delays, were transmitted. The time delay started at 1ms and was decreased after 1 packet transmissions to 4ms. This way, the speed of

146 4 WESPEH Operating System Quantification 146 packet processing was tested on both OS s. To ensure correct functionality, the test setup was monitored with a spectrum analyzer. Applications on both OS s had 1 radio buffers and a 14byte serial ring buffer. Until the time difference of the transmitted telegrams reached 15 milliseconds, both OS s were capable of processing all 1 incoming packets in real time. When the interpacket delay was decreased to 14 millisecond, TinyOS started to loose packets. DolphinAPI started to loose packets first by 13ms interpacket delay. As the number of subtelegrams increased, the number of unprocessed tasks in TinyOS also increased, therefore the delay overhead had also increased. Furthermore, this behavior can be also explained by the monopolization of the MCU with the cooperative tasks. The result of the measurement is shown on the diagram in Figure 71 Number of received subtelegrams TinyOS DolphinAPI Tim e delay betw een transm ission [m s] Figure 71 Telegram reception rate (1x subtelegrams) In the second series of measurements, 1x subtelegrams were sent with a very short delay between transmissions. The 1 radio buffers enable the buffering of the telegrams, therefore the real time processing shouldn t be a problem. The results are shown in Figure 72. Again, the speed of packet processing in TinyOS indicates that packets are being lost significantly faster than in DolphinAPI.

147 4 WESPEH Operating System Quantification TinyOS Number of received subtelegrams Tim e delay betw een transm ission [m s] DolphinAPI Figure 72 Telegram reception rate (1x subtelegram) To prove the latencies in the telegram processing in the third series of measurements, pin control code was inserted into different low-level drives for both OS s. Using a logic analyzer a trace log was created, from which the latency of telegram processing was measured. The benchmark application was the same as the one in the second test case. The results are shown in Figure 73. Telegram reception Latency [ms] TinyOS DolphinAPI Subtelegram number Figure 73 Subtelegram processing latency The latency difference can be clearly seen on the diagram. Interesting is the fact that when processing 2 or 3 subtelegrams TinyOS has completed the operation slightly faster as DolphinAPI. This can be explained by the fact that in DolphinAPI the preemptive scheduling has interrupted the application task in a not efficient moment. From all the measurements, the bottleneck of TinyOS was proved. We have observed that DolphinAPI packet processing performance is on average better than for TinyOS. This

148 4 WESPEH Operating System Quantification 148 proves correctness of the results discussed in chapter Generalizing the evaluation results performance prediction In chapter it was shown how to use the quantification methodology to select the appropriate operating system for a WESPEH application execution. We have to note that the results tell us how the current application behaves in the operating system. Although we have proven the fact that DolphinAPI radio processing is more optimized, the performance evaluation doesn t reveal if DolphinAPI is better than TinyOS in general. Comparing operating systems in a generic manner is not an objective procedure, since it always depends on the application and the scenario where the operating system is used. Changing the application implementation, or measurements performed with a different application could give a result in which TinyOS performance would be better. One of the biggest advantages of the suggested methodology is that once all the vector values are known, additional performance estimation can be performed without extra measurement effort. By knowing the values of the system characterization vector, power consumption vector and system matrix for both DolphinAPI and TinyOS, we can calculate and predict any application performance, and compare its runtime to the analyzed operating systems by determining the application vector. For demonstration purposes let s take the following example. We will consider the same application scenario as discussed in chapter 4.4.1, but with a slightly modified execution. The application will perform only four packet transmissions, and one reception. Furthermore, there will be an intensive UART communication where 3 packets will be transferred to control the heating valve. In addition, only five analog measurements will be performed. In such a case, the application vector definition is the following: 4 1 a r = 5 (4.21) 3 5 Applying the methodology to this modified application, we will get the following performance results: Π DolphinAPI Π TinyOS =1.418 =1.31 (4.22) The results indicates that TinyOS will behave slightly better than DolphinAPI with the described application. By adjusting various vector parameters in the evaluation method, the performance changes in the system can be monitored. For instance, we can see that by optimizing various execution routines what an influence this has on the overall performance. Similar by introducing a new scheduler strategy, we can predict how the energy consumption will be influenced.

149 4 WESPEH Operating System Quantification Conclusion This chapter has discussed various benchmark methodologies for operating system evaluation. At the beginning of the chapter existing quantitative methodologies where discussed. The conclusion was made that the focus of classical operating system benchmark methods is placed entirely on the computational performance, neglecting other important features of the OS, such as memory or energy consumption. Since these features are important for WESPEH systems, therefore they have to be considered during an evaluation. WESPEH operating systems are coupled tightly with the application, therefore the evaluation of the system has to be made in the context of the application. This discussion led to the conclusion that WESPEH operating system evaluation needs a new methodology. The next section of this chapter contained the definition of a new quantification methodology based on vector definition and trace-driven performance analysis. The approach is based on the vector methodology proposed in the papers [11] [12]. In the methodology, the operating system is evaluated in the context of the application. The evaluation methodology involves various parameters, such as the operating system s influence on the energy consumption, method of parallel task execution and speed of operating execution, and factoring in how intensively the application uses the operating system. Based on the methodology, a dedicated application scenario was evaluated on both TinyOS and DolphinAPI. The results of the evaluation showed that the application running on TinyOS performed worse than DolphinAPI. Using the methodology the TinyOS performance bottlenecks were identified. To prove the existence of the bottlenecks, additional macro- and micro- benchmarks where performed. These performance benchmarks have proved the hypothesis of the problematic cooperative behavior of the operating system, and the negative performance influence of the scheduler overhead. A significant advantage of the suggested methodology is the possibility of performance estimation without extra measurement efforts. This property of the methodology was proven in the last chapter where the performance prediction is discussed.

150 5 Conclusion 15 5 CONCLUSION This thesis deals with the challenges of designing and developing wireless energy autonomous devices, with the focus placed on the software challenges. The first part of the thesis is devoted to the overall challenges facing wireless energy autonomous systems. Based on observation and experience, we claim that energy autonomous systems cannot be treated as generic embedded systems, nor as conventional wireless sensor nodes. Hence, a new device category called wireless embedded systems powered by energy harvesting was introduced. The architecture of these devices was established and application scenarios were presented. To demonstrate the major design issues these devices pose, the thesis discusses the energy harvesting problem in more detail. Various power measurements were performed with solar and electrodynamic energy harvesters to show the amount of power these units can deliver. Based on these measurements and discussions, software design decisions were made. In the next phase of the thesis, the focus was placed on the design challenges of WESPEH. Based on the examination of existing design techniques and on the practical experience, it was concluded that classical embedded systems design techniques do not apply for WESPEH. A new design technique based on constraints analysis and prototype quantification was introduced. It was concluded that for successful WESPEH implementation, the design constraints have to be in equilibrium. The problems common to design constraints groups are discussed briefly and solutions are presented. To provide a comprehensive solution for all the problem fields, the work of a variety of experienced researchers dedicated to this research field is required. Therefore, due to the discussed design constraint groups, the thesis deals with the software challenges in detail. In the next part of the thesis, the requirements for a WESPEH operating system are laid out. A comprehensive analysis of general-purpose embedded operating systems and wireless sensor network operating systems showed that these systems do not fulfill all defined requirements based on WESPEH OS. Next, the architecture and design aspects of a WESPEH OS were elaborated and defined. Based on these design aspects, the successful implementation of a new WESPEH operating system called DolphinAPI is presented. During the implementation, various energy saving SW optimization techniques are presented in the C language. The initial implementation of the operating system was done for the EO3I HW platform. To prove the implementation feasibility, TinyOS was ported to the EO3I platform and the implementation of the EnOcean protocol stack was performed in NesC. The next part of the thesis discusses existing operating system benchmarking methodologies. It was concluded that the focus of classical operating system benchmark methods is placed entirely on the computational performance, neglecting other important features of the OS, such as memory or energy consumption. Since these features are important for WESPEH systems, a new quantification methodology for WESPEH OS was introduced. The methodology is based on vector definition and trace-driven performance analysis and involves various parameters such as the operating system s influence on energy consumption, method of parallel task execution, speed of operating execution and factoring in how intensively the application uses the operating system. Based on the methodology, a dedicated application performance is evaluated on both

151 5 Conclusion 151 DolphinAPI and TinyOS operating systems. The results of the evaluation showed that application behaves better on DolphinAPI than on TinyOS. Using the methodology, the TinyOS performance bottlenecks were identified. To prove the measurement accuracy, additional micro- and macro- benchmarks were performed. The benchmarks proved the hypothesis of the problematic cooperative behavior of the operating system and the negative performance influence of the scheduler overhead. In the final part of the thesis, we showed using the methodology how the score can be predicted for various WESPEH applications without the need for extra measurements. The following chapter summarizes the main contributions of this thesis. 5.1 Contributions The title of the thesis suggests that the objective of this work was to comprehensively address the challenges posed by wireless embedded systems powered by energy harvesting. Since this is a very broad topic for a single dissertation thesis, it is impossible to fulfill such an ambitious goal. Still, the title of the thesis was selected intentionally. Despite the fact that the main focus of this research effort was on the software aspects, the primary objective of the thesis was to raise the awareness of the research community to the challenges posed by wireless embedded systems powered by energy harvesting. Although the generic design topics are discussed only briefly, it should motivate other researchers to think more about these aspects, and explore and extend them further. The thesis makes several new theoretical and practical contributions to the scientific community in the field of applied informatics by defining WESPEH architecture, introducing application scenarios, defining a design methodology and constraints group. Furthermore, the thesis lays down the requirements and design aspects of operating systems designated to be utilized by WEPSEH. The thesis also makes contributions in the area of operating system evaluation though the introduction of a quantification method based on vector definition and trace-driven performance analysis. A further significant contribution to the research community is the porting of TinyOS to a new EO3I HW platform, and by the implementation of the EnOcean protocol stack in NesC. I claim that all objectives of the thesis were fulfilled. The summarization of the thesis contributions can be divided in two groups and is expressed with the following definitions: Thesis contributions to the scientific community in the field of applied informatics: Raising awareness that the design challenges of wireless energy autonomous systems is different from generic embedded systems and wireless sensor nodes. Defining the term WESPEH, and defining the architecture of wireless embedded systems powered by energy harvesting. Defining WESPEH application scenarios. Defining WESPEH design techniques, based on constraints analysis and prototype quantification and a brief discussion of typical design problems.

152 5 Conclusion 152 Defining the requirements and design aspects of WESPEH operating systems. Porting TinyOS to the EO3I platform and implementation of the EnOcean protocol stack in TinyOS. Introduction of a new quantification methodology for the WESPEH operating system, based on vector definition and trace-driven performance analysis. The methodology makes the prediction of application performance possible. Generic thesis contributions: Overview of WESPEH powering possibilities using energy harvesters and summarizing the available ambient energy sources and amount of energy. Overview of radio standards and their energy requirements. Comprehensive analysis and overview of available thin resource operating systems. Introduction of various energy saving code optimization methods in C. Implementation of DolphinAPI as a new WESPEH operating system on the EO3I hardware platform. Quantification of TinyOS and DolphinAPI using the quantification methodology. Performing micro- and macro- measurements on both TinyOS and DolphinAPI. 5.2 Future work This thesis has introduced a new device category called wireless embedded system powered by energy harvesters. We are confident that the introduction of this category was needed and that in the near future more and more wireless embedded systems powered by energy harvesters will appear on the market. We hope that this aspect introduced by this work will be welcome in the research community and will be further developed. Although the energy harvesting technology evolves fast, significant further efforts have to be directed toward WESPEH research, in order to make the vision of ambient intelligence become a reality. The thesis has introduced a design methodology based on constraint analysis and prototype quantification. As a part of this work, SW constraint challenges were analyzed in detail. Putting further research effort into the analysis of the radio, micro-controller platform and energy aspect design groups would be beneficial and would ease the development of WESPEH devices. Furthermore, based on the methodology, various real

153 5 Conclusion 153 prototypes should be evaluated and results published. This would prove the efficiency of the methodology and would foster further enhancements. The current implementation of DolphinAPI operating system is already being used in several WESPEH applications. A further improvement to the operating system would be the introduction of a message-passing mechanism between the operating system and application layer. Currently, the only possibility for applications to receive events from the operating system is if it initiates a system call or through a callback function. These system calls can take a long time and may block the execution of interrupt-based tasks. By the introduction of messages, the application layer could get much faster information about the system events. Another possibility for the enhancement of the operating system in the future would be the introduction of cooperative task execution in the application layer. Currently, the application runs in a single task that can be interrupted any time by system task execution. Thus the creation of a state machine is the only possibility for allowing the application to organize its runtime flow. Moreover, the operating system should be ported to further WESPEH HW, thus new HAL layers should be implemented in the future. To reveal the true power of the operating system quantification methodology, additional measurements have to be performed on various low power operating system platforms running various application scenarios. Collecting and publishing the measurement data would reveal the strengths and weaknesses of the operating system, and would guide the designers in the selection of the correct platform for the WESPEH application.

154 6 List of publications LIST OF PUBLICATIONS 27 A. Strba: Design Approach of Embedded Systems Gaining Power from Energy Harvesting In: Proceedings in Informatics and Information Technologies Student Research Conference 27, April 18, 27, Bratislava, Slovak University of Technologies, Bratislava, Slovakia A. Strba, T. Krajcovic: Embedded Systems with Limited Power Source In: Proceedings of the Ninth International Conference on Informatics 27, June 21-22, 27, Bratislava, Slovakia 28 A. Strba, T. Krajcovic: Software Design challenges for self-sustaining Embedded Systems In: Proceedings of the IEEE International Conference on Applied Electronics 28, September 7-8, 28, Pilsen, University of West Bohemia, Czech Republic A. Strba: Design and quantification approach of Wireless Embedded Systems powered by Energy Harvesters In: Proceedings of the Hungarian PhD Conference, November 1, 28, Budapest, Balaihssi Institute, Hungary 29 A. Strba: Operating system design challenges for wireless embedded systems powered by energy harvesters5 In: Proceedings of the 7 th International Symposium on Applied Machine Intelligence and Informatics - paper published in the IEEE Xplore database, January 29-31, 29, Technical University of Košice Herľany, Slovakia 21 A. Strba, T. Krajcovic: Operating System for Wireless Embedded Systems Powered by Energy Harvesters In: International Joint Conferences on Computer, Information, and Systems Sciences, and Engineering, Springer 21, December 3 rd 12 th, 21 5 Awarded with the Baltazár Frankovič Young Researcher award for the outstanding paper and presentation on the symposium.

155 7 Bibliography BIBLIOGRAPHY [1] A. Strba: Design Approach of Embedded Systems Gaining Power from Energy Harvesting In: Proceedings in Informatics and Information Technologies Student Research Conference 27, April 18, 27, Bratislava, Slovak University of Technologies, Bratislava, Slovakia [2] A. Strba, T. Krajcovic: Embedded Systems with Limited Power Source In: Proceedings of the Ninth International Conference on Informatics 27, June 21-22, 27, Bratislava, Slovakia [3] A. Strba, T. Krajcovic: Software Design challenges for self-sustaining Embedded Systems In: Proceedings of the IEEE International Conference on Applied Electronics 28, September 7-8, 28, Pilsen, University of West Bohemia, Czech Republic [4] A. Strba: Design and quantification approach of Wireless Embedded Systems powered by Energy Harvesters In: Proceedings of the Hungarian PhD Conference, November 1, 28, Budapest, Balassi Institute, Hungary [5] A. Strba: Operating system design challenges for wireless embedded systems powered by energy harvesters In: Proceedings of the 7 th International Symposium on Applied Machine Intelligence and Informatics - paper published in the IEEE Xplore database, January 29-31, 29, Technical University of Košice Herľany, Slovakia [6] A. Strba, T. Krajcovic: Operating System for Wireless Embedded Systems Powered by Energy Harvesters In: International Joint Conferences on Computer, Information, and Systems Sciences, and Engineering, Springer 21, December 3 rd 12 th, 21 [7] D. Gajski, F. Vahid, S. Narayan, and J. Gong: Specification and Design of Embedded Systems, Prentice Hall, 1994 [8] The Origin, Nature, and Implications of Moore s Law Last access [9] D. Lammers: IBM Alliance Partners 'Open For Business' for 32nm Highk/Metal Gate Designs, Semiconductor International, 4/14/28 [1] J. Bohn, V. Coroama, M. Langheinrich, F.Mattern, and M. Rohs: Social, Economic, and Ethical Implications of Ambient Intelligence and Ubiquitous Computing In: W.Weber, J.M. Rabaey, E.AArts: Ambient Intelligence, Netherlands: Springer, 25 [11] Ubiquitous Computing: An Interesting New Paradigm Last access [12] F. Schmidt, M. Heiden: Wireless Sensors Enabled by Smart Energy Concepts and Solutions, White Paper, EnOcean GmbH, Oberhaching, Germany,

156 7 Bibliography 156 [13] F. Schmidt, Wolfgang Heller: Radio sensors powered by ambient energy: from strange ideas to mass market products, White Paper, EnOcean GmbHOberhaching, Germany [14] Thomas A. Henzinger, Joseph Sifakis: The Embedded Systems Design Challenge, In: Proceedings of the 14th International Symposium on Formal Methods (FM), Lecture Notes in Computer Science 485, Springer, 26, pp [15] Language Design: Lustre Last access [16] V. Raghunathan, C. Schurgers, S. park, M. B. Srivastava 24: Energy efficient design of wireless sensor nodes, In: Wireless Sensor Networks. Edited by: C.S. Raghavendra, K. M. Sivalingam, T. Znati. Boston/Dordecht/London, Kluwer Academic Publishers, [17] C++ in Embedded Systems: Myth and Reality by Dominic Herity Last access [18] WU Xue: Dynamic power management technique and its application on a multiprocessor architecture Last access [19] Z. Lei, Z. Wei-Hong, XU Chao-Nong, XU Young-Jun, LI Xiao-Wei: Energyaware System Design for Wireless Sensor Network, 26 Last access [2] Tanenbaum, A.S.: Modern Operating Systems 2 ND edition, Prentice Hall PTR, Prentice Hall, Upper Saddle River, NJ. [21] Randy Martin and Sheridan Ethier: Application-Driven Power Management for Embedded Systems, Embedded World, 28 [22] N. AbouGhazaleh, B. Childers, D. Mossé, R. Melhem, M. Craven: Energy Management for Real-Time Embedded Applications with Compiler Support In: Proceedings of the 23 ACM SIGPLAN conference on Language, compiler, and tool for embedded systems, June 11-13, 23, San Diego, California, USA [23] Keil Cx51 Compiler User s Guide [24] Eui-Young Chung, L. Benini, G. de Micheli: Energy Efficient Source Code Transformation based on Value Profiling In: Proc. International Workshop on Compilers and Operating Systems for Low Power, 2 [25] Advanced Compiler Optimization Techniques Last access [26] T. Noergaard: Embbededd System Architecture, Elsevier, 25 [27] Introduction to TinyOS Last access

157 7 Bibliography 157 [28] D E. Culler: TinyOS: Operating System Design for Wireless Sensor Networks Last access [29] Pumpkininc - Salvo Networks Last access [3] FreeRTOS Source Code Last access [31] FreeRTOS Last access [32] RTX51 Real-Time Kernel Last access [33] EO3I ASIC meets building engineering challenges In: Electronicstalk, Nov. 12, 28 Last access [34] MISRA C rules description Last access [35] S. Na and D. Han, "MicroBenchmarks of Operating System Performance, on the Multiprocessor Platform" Context, 1999, pp [36] Standard Performance Evaluation Corporation Last access [37] Water Simulation in the SPLASH Benchmark /results/oakamil/hw.htm Last access [38] D. Bailey, E. Barszcz, J. Barton, D. Browning, R. Carter, L. Dagum, S. Fineberg, P. Frederickson, T. Lasinski, R. Schreiber, H. Simon, V. Venkatakrishnan, and S. Weeratunga, "THE NAS PARALLEL BENCHMARKS 1 GENERAL REMARKS," Contract, 1994 [39] Parkbench Last access [4] EEMBC Last access [41] Ousterhout, J.K. Why Aren't Operating Systems Getting Faster As Fast as Hardware? In: Proceedings of USENIX Summer. 199, [42] A.B. Brown and M.I. Seltzer, "Operating System Benchmarking in the Wake of Lmbench: A Case Study of the Performance of NetBSD on the Intel x86," Architecture, SIGMETRICS 97 Seattle, vol. pp, pp [43] LMBench Last access

158 7 Bibliography 158 [44] Why LMbench is Evil? Last access [45] K. Sacha, "Measuring the Real-Time Operating System Performance," Technology, 1995, pp [46] P. Koopman, J. Sung, C. Dingman, D. Siewiorek, and T. Marz, " Comparing Operating Systems Using Robustness Benchmarks" Symposium A Quarterly Journal In Modern Foreign Literatures, [47] Microsoft Windows & Linux/Unix Supported Processors Last access: [48] TinyOS 2.x TEP2: Hardware Abstraction Architecture Last access: [49] TinyOS Enhancement Proposal TEP121 Last access: [5] TinyOS 851 Working Group Last access: [51] Neema, S., Mitra, A., Banerjee, A., Najjar, W., Gunopulos, D., Kalogeraki, V., et al. (n.d.). NODES : A NOVEL SYSTEM DESIGN FOR EMBEDDED SENSOR NETWORKS. Symposium A Quarterly Journal In Modern Foreign Literatures, 2-3. [52] Beck, N., & Johnson, I. (27). Shaping TinyOS to Deal with Evolving Device Architectures:. differences, (83), [53] M. Leopold, Sensor Network Motes: Portability and Performance, Ph.D. Dissertation, December 27 TinyOS 2.x TEP12: Timers Last access: [54] [55] EnOcean Radio Technology description Last access: [56] Smart Ack Bi-directional Thermostat with Display (PDF), 9/29 CK.pdf Last access: [57] Salvo User Manual Last access: [58] Salvo Reference Manual for the 851 platform Last access: [59] Contiki Last access:

159 7 Bibliography 159 [6] F. Schmidt, W. Heller, D. Rahusen, A. Sikora, V. Groza, "Design and Implementation of a Routing Protocol for Seamless Integration of Unidirectional Energy-Autonomous Wireless Sensor Nodes", IEEE I²MTS International Instrumentation and Measurement Conference, Austin [61] Wang, C., Wu, W., A Light-weighted Operating System with Deadlock Prevention Strategy for Wireless Sensor Nodes, Communications and Mobile Computing, 29. CMC '9. [62] Dunkels, A., Onvall, B. G., & Voigt, T., Contiki - a lightweight and flexible operating system for tiny networked sensors, Proceedings of the 29th Annual IEEE International Conference on Local Computer Network, 24 [63] Mantis Operating System Last access: n/a [64] Bhatti, S., Carlson, J., Dai, H. U., Deng, J., Rose, J., Sheth, A., et al. (25). MANTIS OS : An Embedded Multithreaded Operating System for Wireless Micro Sensor Platforms. Mobile Networks and Applications, [65] Abrach, H., Bhatti, S., Carlson, J., Dai, H., Rose, J., Sheth, A., et al. (23). MANTIS : System Support for MultimodAl NeTworks of In-situ Sensors. Network, [66] SOS Operating System Last access: [67] Han, C., Kumar, R., Shea, R., Kohler, E., & Srivastava, M. (n.d.), A Dynamic Operating System for Sensor Nodes, Technical Report NESL-TM , University of California Los Angeles, Networked Embedded Systems Lab, November 24 [68] Q. Cao, T. Abdelzaher, and J. Stankovic, "The LiteOS Operating System : Towards Unix-like Abstractions for Wireless Sensor Networks", Proceedings of the 7th international conference on Information processing in sensor networks, 28, pp [69] LiteOS Operating System Last access: [7] Qing Cao; Fesehaye, D.; Nam Pham; Sarwar, Y.; Abdelzaher, T.;, "Virtual Battery: An Energy Reserve Abstraction for Embedded Sensor Networks," Real- Time Systems Symposium, 28, vol., no., pp , Nov Dec [71] NanoRK Operating System Last access: [72] A. Eswaran, A. Rowe, and R. Rajkumar, "Nano-RK : an Energy-aware Resourcecentric RTOS for Sensor Networks, Real-Time Systems Symposium, 25. RTSS th IEEE International Conference [73] Chede, S., & Kulat, K..: Design Overview Of Processor Based Implantable Pacemaker, Journal of Computers VOL.3 No.8, 28 [74] Neue Coca-Cola-Automaten laufen mit Windows CE Last access:

160 7 Bibliography 16 [75] Bjarne Stroustrup's homepage Last access: [76] T. Haenselmann, Sensor networks GFDL Wireless Sensor Network textbook, 26 [77] Römer, Kay; Friedemann Mattern (December 24). "The Design Space of Wireless Sensor Networks", IEEE Wireless Communications (6): [78] Nokias latest patent application: Piezoelectric Kinetic Energy Harvester Last access: [79] Nokia wants patent on self-regenerating phone batteries Last access: [8] LitOS presentation Last access: [81] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister, "System Architecture Directions for Networked Sensors," in Proc. ACM ASPLOS, 2 [82] P. Levis and D. Gay, "TinyOS Programming," Computing Systems, 29. [83] D. Gay, M. Welsh, P. Levis, E. Brewer, and D. Culler, "The nesc Language: A Holistic Approach to Networked Embedded Systems," ACM Conference on Programming Language Design and Implementation (PLDI), June 23. [84] NesC Language Reference Manual Last access: [85] IAR C++ compiler Last access: [86] 851 complete list of all the variants Last access: [87] Kernel Definition Last access: [88] Why Monolithic Kernels Aren't the End of the World Last access: [89] Why I Like Microkernels Last access: [9] R. Rajkumar, K. Juvva, A. Molano, and S. Oikawa. Resource kernels: A resource- centric approach to real-time and multimedia systems, In Proc. of the SPIE/ACM Conference on Multimedia Computing and Networking. January 1998 [91] Exokernel Last access:

161 7 Bibliography 161 [92] D.R. Engler, M.F. Kaashoek, and J.O. Toole, "Exokernel : An Operating System Architecture Management for Resource," Proceedings of the fifteenth ACM symposium on Operating systems principles New York, NY, USA: ACM (1995), p [93] Min, H., Yi, S., & Cho, Y., An Efficient Dynamic Memory Allocator for Sensor Operating Systems The 27 ACM SIGAPP Symposium on Applied Computing (SAC'7), Vol.2, pp , March, 27 [94] Handziski, V., Polastre, J., Hauer, J., Sharp, C., Wolisz, A., Culler, D., et al. (n.d.). Flexible Hardware Abstraction for Wireless Sensor Networks. Science. [95] R.K. Gupta, S. Irani, S. K. Shukla, Formal Methods for Dynamic Power Management, International Conference on Computer Aided Design Proceedings of the 23 IEEE/ACM [96] Snowdon, D., Ruocco, S., & Heiser, G., Power Management and Dynamic Voltage Scaling: Myths and Facts, Proceedings of the 7th ACM & IEEE international conference on Embedded software, 27 [97] Benini, L., Bogliolo, A., & Micheli, G. D., A Survey of Design Techniques for System-Level Dynamic Power Management. IEEE Trans. VLSI Systems, 2 [98] Gniady, C., Hu, Y. C., & Lu, Y., Program Counter Based Techniques for Dynamic Power Management, IEEE Transactions on Computers, vol. 55, no. 6, pp , June 26 [99] Q. Cao, D. Fesehaye, N. Pham, Y. Sarwar, and T. Abdelzaher, "Virtual Battery: An Energy Reserve Abstraction for Embedded Sensor Networks", Real-Time Systems Symposium, pp , 28 [1] Misra C Last access: [11] M. Seltzer, D. Krinsky, K. Smith, and X. Zhang, "The Case for Application- Specific Benchmarking," Workshop on Hot Topics in Operating Systems, [12] M. Leopold, M. Chang, P. Bonnet: Characterizing Mote Performance: A Vector-Based Methodology, 5th European conference on Wireless Sensor Networks (EWSN 28), January 28 [13] Brown, A., A Decompositional Approach to Computer System Performance Evaluation, Harvard Senior Thesis, 7 April 1997 [14] Linux Kernel Performance Last access: [15] R. Jain, "The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling," Wiley- Interscience, New York, NY, April 1991 [16] K.J. Kuhn, "Moore's Law Past 32nm: Future Challenges in Device Scaling," 29 13th International Workshop on Computational Electronics, 29, pp [17] Researchers rescue Moore's Law Last access: [18] McGraw-Hill, McGraw-Hill Dictionary of Scientific and Technical Terms, 22, McGraw-Hill Professional

162 7 Bibliography 162 [19] K. Najafi, Micro Energy Harvesters An Alternative Source of Renewable Energy, Commercialization of Micro and Nano Systems Conference, Mexico 28 [11] M. Raju, "ULP meets energy harvesting," Texas Instruments White Paper [111] Photovoltaic, Solar Electricity and Solar Cells in Theory and Practice, Last access: [112] Adnan Adla: Instrumentation for Quantum Efficiency Measurement of Solar Cells, Photovoltaics World Magazine, Issue 2, August 4, 21 [113] Solar Cells, Shedding a little light on photovoltaic html Last access: [114] EL-MAN-45 Datasheet Last access: [115] E. H. Callaway Wireless Sensor Networks: Architectures and Protocols, Auerbach Publications, 23 [116] S.P. Beeby, R.N. Torah, M.J. Tudor, P. Glynne-Jones, T. O'Donnell, C.R. Saha, and S. Roy, "A micro electromagnetic generator for vibration energy harvesting," Journal of Micromechanics and Microengineering, vol. 17, 27, pp [117] S. Meninger, J.O. Mur-miranda, R. Amirtharajah, A.P. Chandrakasan, and J.H. Lang, "Vibration-to-Electric Energy Conversion," Integration The Vlsi Journal, vol. 9, 21, pp [118] B.A. Hande, R. Bridgelall, and B. Zoghi, "Vibration Energy Harvesting for Disaster Asset Monitoring Using Active RFID Tags," Proceedings of the IEEE, vol. 98, 21, pp [119] M. Wischke, M. Masur, F. Goldschmidtboeing and P.Woias: Resonance: tunability of clamped free piezoelectric cantilevers, Journal of Micromechanics and Microeng. 19, IOP, 29, 1252 [12] Wireless Sensors That Live Forever, IEEE Spectrum, Last access: [121] A. Sinha, A. Wang, and A.P. Chandrakasan, "Algorithmic transforms for efficient energy scalable computation," Proceedings of the 2 international symposium on Low power electronics and design - ISLPED ', 2, pp [122] V. Tiwari, S. Malik, A. Wolfe, and T.C. Lee, "Instruction level power analysis and optimization of software," Journal of VLSI Signal Processing, vol. 13, 1996, pp [123] N. Kavvadias, P. Neofotistos, S. Nikolaidis, C. Kosmatopoulos, and T. Laopoulos, "Measurements Analysis of the Software-Related Power Consumption in Microprocessors," IEEE Transactions on Instrumentation and Measurement, vol. 53, 24, pp [124] R.Y. Chen, M.J. Irwin, and R.S. Bajwa, "Architecture-level power estimation and design experiments," ACM Transactions on Design Automation of Electronic Systems, vol. 6, 21, pp

163 7 Bibliography 163 [125] Embedded System Design Methodologies, project SPI and project MEAT Last access: [126] Remmel, T.; Ramprasad, R.; Walls, J.;, "Leakage behavior and reliability assessment of tantalum oxide dielectric MIM capacitors," Reliability Physics Symposium Proceedings, st Annual. 23 IEEE International, vol., no., pp , 3 March-4 April 23 [127] da Silva, J.L., Jr.; Shamberger, J.; Ammer, M.J.; Guo, C.; Li, S.; Shah, R.; Tuan, T.; Sheets, M.; Rabaey, J.M.; Nikolic, B.; Sangiovanni-Vincentelli, A.; Wright, P.; "Design methodology for PicoRadio networks," Design, Automation and Test in Europe, 21. Conference and Exhibition 21. Proceedings, vol., no., pp , 21 [128] WLAN Interference Raises Doubts about ZigBee, IEEE Products Last access: [129] Heller, W., Schmidt, F., Radio sensors powered by ambient energy : From strange ideas to mass market products, White Paper [13] R. Min, M. Bhardwaj, Nathan Ickes, A. Wang, A. P. Chandrakasan, "The Hardware and the Network: Total-System Strategies for Power Aware Wireless Microsensors," CAS Workshop on Wireless Communication and Networking, September 22. Invited Paper. [131] CMOS Power Consumption and C pd Calculation, SCAA35 September 1996, Texas Instrument [132] Arne M., Asmund S., Innovative techniques reduce power consumption of 8-bit MCUs, Boards & Solution ECE, August 21, pp [133] Dancefloor generates electricity at London s first eco-disco Last Access: [134] Piezoelectric generator creates power from shoes Last access: [135] Schmidt, F., Batterielose Funksensoren, betrieben mit Energie aus der Umgebung, 11. ITG/GMA-Fachtagung Sensoren and Mess-Systeme, Ludwigsburg, Mar , 22. [136] Yang, R., Qin, Y., Li, C., Zhu, G., & Wang, Z. L. (29). Converting Biomechanical Energy into Electricity by a Muscle-Movement-Driven Nanogenerator. Nano. doi: 1.121/nl8394b. [137] EH-Link Energy Harvesting Wireless Node Last access: [138] JTRA-e5mini Vibration Energy Harvester Last access: [139] PMG17 Vibration Energy Harvester Last access: [14] TE-Power Thermoelectric Energy Harvester Last access:

164 7 Bibliography 164 [141] ECT31 Thermoelectric Energy Harvester DataSheet_Oct1_2.pdf/ Last access: [142] ECO1 Electrodynamic Energy Harvester Last access: [143] Ambiente Intelligence: from vision to reality ftp://ftp.cordis.europa.eu/pub/ist/docs/istag-ist23_consolidated_report.pdf Last access: [144] ISTAG: Orientations for Workprogram 2 and beyond ftp://ftp.cordis.europa.eu/pub/ist/docs/istag-99-final.pdf Last access: [145] ADA Programming language Last access: [146] Why, When and How: The basics of embedded systems prototyping, EETimes Last access: [147] V. Raghunathan, A. Kansal, J. Hsu, J. Friedman, and M. B. Srivastava, Design considerations for solar energy harvesting wireless embedded systems, in Proc. IPSN, Apr , 25, pp [148] F. Cottone, Nonlinear Piezoelectric Generators for Vibration Energy Harvesting, Dissertation Thesis, Universita Degli Studi di Perugia, 27 [149] Protect Sentinel Last access: [15] Automated generation of information and protection of critical infrastructures in the event of a disaster Last access: [151] SOMATEK Last access: [152] Gesund Wohnen mit Stil &Itemid=86 Last access: [153] Guter Draht ist teuer html Last access: [154] Smart Acknowledge Specification CK.pdf Last access:

165 7 Bibliography 165 [155] Application note 28: STM3 Energy Storage Energy_Storage_Feb211.pdf Last access: [156] J. E. Smith, Characterizing Computer Performance with a Single Number, Commun. ACM, 31(1): , [157] L. K. John, More on finding a Single Number to indicate Overall Performance of a Benchmark Suite, SIGARCH Computer Architecture News, 32(1):3 8, 24. [158] P. J. Fleming and J. J. Wallace, How not to lie with statistics: the correct way to summarize benchmark results. Commun. ACM, 29(3): , [159] D. Citron, A. Hurani, A. Gnadrey, The harmonic or geometric mean: does it really matter?, SIGARCH Comput. Archit. News 34, 4 (September 26), [16] EDK3 EnOcean Development Kit Supporting Dolphin modules Last access: [161] Dolphin Core Specification inary_.96_9.pdf/ Last access: [162] Small Device C Compiler Last access: [163] STM3 Last access: [164] TCM3 Last access: [165] STM31 Last access: [166] PTM2 Last access: [167] PTM23 Last access: [168] GP5C et%2v1.1.pdf Last access: [169] EnOcean Radio Protocol Stack Last access: [17] Timer precision problem during proting to platform Last access:

166 7 Bibliography 166 [171] EnOcean Serial Protocol 3 ol_3_v1.15_2.pdf/ Last access: [172] Three-Dimensional Transistors Last access: [173] K. Romer and F. Mattern. The design space of wireless sensor networks. Wireless Communications, IEEE, 11(6):54 61, dec. 24. [174] TinyOS Mailing list help@millennium.berkeley.edu/msg32294.html Last access: [175] Chen, J. B., Endo, Y., Chan, K., Mazières, D., Dias, A., Seltzer, M., The measured performance of personal computer operating systems, ACM Transactions on Computer Systems, 14(1), 3-4 [176] Zhang, X., & Seltzer, M., HBench:Java: An application-specific benchmarking framework for Java Virtual Machines, Concurrency and Computation: Practice and Experience, 13(8-9),

167 8 APPENDIX Appendix A About the author Attila Štrba was born in Nové Zámky, Slovakia in 198. He graduated in engineering sciences from the Slovakian Technical University Bratislava in 25. Attila is working as a software engineer at the company EnOcean. He is responsible for embeddedand high level software development. He was involved in the EO3I Dolphin project and was responsible for the software development. Since 26, parallel to his work he is doing his extern PhD studies at the Slovak University of Technology in Bratislava. He has published his research results in various journals and presented his work at both national and international conferences. His paper Operating system design challenges for wireless embedded systems powered by energy harvesters won the Baltazár Frankovič Young Researcher award for the outstanding paper and presentation. Attila is married and his first child is on the way. His other interests include movie editing, reading, swimming, and enjoying his family.

168 Appendix B B.1 Solar cell measurements Illuminance [Lux] Current [ma] sinonar ss-6782-a sinonar ss-5516 sanyo am ,7 x 27,8mm 55 x 15,5 mm 17,9 mm x 2 mm Voltage [mv] Power [mw] Current [ma] Voltage [mv] Power [mw] Current [ma] Voltage [mv] Power [mw] 1,47 4,72,222,41 4,14,17,45 4,54,24 937,5,47 4,68,22,41 4,1,168,44 4,47, ,46 4,62,213,4 4,5,162,43 4,39, ,5,45 4,56,25,4 3,99,16,42 4,29,18 75,45 4,49,22,39 3,92,153,41 4,16, ,5,44 4,41,194,38 3,84,146,39 3,99, ,43 4,33,186,37 3,74,138,38 3,79, ,5,42 4,22,177,36 3,6,13,35 3,53,124 5,41 4,1,168,34 3,42,116,32 3,222,13 437,5,39 3,95,154,32 3,19,12,28 2,88,81 375,37 3,75,139,28 2,85,8,25 2,52,63 312,5,35 3,47,121,24 2,45,59,21 2,15,45 25,31 3,9,96,2 2,1,4,17 1,76,3 187,5,25 2,56,64,15 1,539,23,13 1,37,18 125,18 1,83,33,1 1,61,11,9,92,8 62,5,1,97,1,5,545,3,4,494,2 Table 17 Power characteristic measurement of solar cells B.2 ECO1 Measurements Displacement [mm] Force [N] Voltage [N] Power [mws] ECO1 no.1,44,44,44,44 ECO1 no.2,54,54,54,54 ECO1 no.3,55,55,55,55 ECO1 no.4,73,73,73,73 ECO1 no.5,63,63,63,63 Table 18 Power characteristic measurement of ECO1

169 Appendix C C.1 Operating system comparison Parametric Specifications RTX51 Full RTX51 Tiny Round-Robin Multitasking Yes Yes Preemptive Multitasking Yes - Cooperative Multitasking Yes Yes Timeout Events Yes Yes Interval Events Yes Yes Signal Events Yes Yes Message Events Yes - Semaphore Events Yes - Memory Pools Yes - Code Banking Support yes Yes MAX Defined Tasks MAX Active Tasks Required CODE Space 6K-8K bytes 9 bytes Required DATA Space 4-46 bytes 7 bytes Required Stack (IDATA) Space 2-2 bytes 3 bytes for each task Required XDATA Space 65 bytes min. bytes Timer Used, 1, or 2 System Clock Divisor 1,-4, cycles 1,-65,535 cycles Interrupt Latency < 5 cycles < 2 cycles Fast Task Switch Time Depends on Stack Load. 7-1 cycles - Standard Task Switch Time Depends on Stack Load cycles 1-7 cycles Task Priority Levels 4 1 Table 19 RTX51 features and differences between Tiny and Full version [32]

170 Appendix D D.1 Quantification measurements Primitives 1 buffers 1 buffers Function of primitives Best runtime [µs] Worst runtime [µs] Arithmetic mean [µs] Code coverage [%] Radio_getTelegram % Radio_updateRadioBuff % Radio_decodeRx % Radio_convertUxTx % Radio_checkSub % Radio_rx % Radio_sendTelegram % Radio_subTelTiming % Radio_tx % Sum. Mean [µs] Standby pwr_standbysleep % byte buffer Uart_sendTelegram % Uart_sendBuffer % A/D Converter io_measanalog % 1 Table 2 DolphinAPI primitive operations measurements

171 Primitives 1 buffers 1 buffers Function of primitives Best runtime [µs] Worst runtime [µs] Arithmetic mean [µs] Code coverage [%] Radio.getTelegram % Erp.updateRadioBuff % Erp.decodeRx % Erp.convertUxTx % Erp.checkSub % RadioMac.Radio_rx % Erp.processSubtelegram % RadioMac.subtelReceived % Erp.TelegramReceived % RadioMac.getSubtelegram % Radio.sendTelegram % Erp.subTelTiming % Erp.TelegramTxFinished % RadioMac.sendSubtelegram % RadioMac.subTelSent % Sum. Mean [µs] Standby pwr_standbysleep % byte buffer Esp2.sendTelegram % UART.putDone % A/D Converter measanalog % 1 Table 21 TinyOS primitive operations measurements

172 Time [s] Analog- SCSEDIO RadioTx- RSDADIO3 StandBy- ADIO2 RadioRx- ADIO UARTTx- SCLKDIO1 States binary encoded 1, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,4475 1, , , , , , , , , ,4262 1, , , , , , , , , , , ,

173 1, , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,54984 Table 22 Application trace-log running on DolphinAPI

174 Time [s] Analog- SCSEDIO RadioTx- RSDADIO3 StandBy- ADIO2 RadioRx- ADIO UARTTx- SCLKDIO1 States binary encoded 2, , , , , , , , , , , , , , , , , , ,8627 2, , , , , , , , , ,8315 2, , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,9244 2, , ,

175 2, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,191 3, , , , , ,1781 3, , , , , , , ,24448 Table 23 Application trace-log running on TinyOS

176 Table 24 Average execution time of DolphinAPI Analog- SCSEDIO [ms] RadioTx- RSDADIO3 [ms] StandBy-ADIO2 [ms] RadioRx-ADIO [ms] UART-SCLKDIO [ms] 1,99 2,33 6,42 1,6 13,92 1,92 2,31 6,45 1,18 13,96 1,75 2,34 6,38 1,43 13,98 1,62 2,33 6,4 1,56 13,94 1,48 2,32 6,45 1,69 14,2 1,36 2,3 6,22 1,63 14,1 1,41 2,32 6,33 1,64 14,5 1,41 2,31 6,35 1,65 14,3 1,38 2,32 6,34 1,66 14,4 Average: Average: Average: Average: Average: 1,59 2,32 6,37 1,5 14, Analog- SCSEDIO [ms] RadioTx- RSDADIO3 [ms] StandBy-ADIO2 [ms] RadioRx-ADIO [ms] UART-SCLKDIO [ms] 11,6,9 5,89 1,6,89 11,61 2,51 6,36 1,53 14,49 11,61 2,26 6,6 1,83 14,6 11,55 2,25 6,23 1,74 14,5 11,55 2,22 6,19 1,84 14,54 11,55 2,23 6,19 1,95 14,56 11,55 2,24 6,71 2,33 14,48 11,61 2,61 6,68 2,44 14,47 11,61 2,28 6,32 2,31 14,54 11,61 2,35 6,66 2,67 14,53 Average: Average: Average: Average: Average: 11,53 2,17 6,35 1,95 13,1 Table 25 Average execution time of TinyOS

177 States Description of parallel primitives execution Count Probability weight 4 Standby 9,1 8 Radio Rx 9,1 12 Standby & RadioRx 9,1 17 UartTx & Analog 9,1 18 UartTx & RadioTx 9,1 No primitive running 21,24 16 UartTx 23,26 Table 26 Primitive parallel execution, DolphinAPI = = = m m m m m Analog m m m m m UartTx m m m m m Standby m m m m m RadioTx m m m m m RadioRx Analog UartTx Standby RadioTx RadioRx M DolphinAPI (8.1) Calculation of the system matrix for DolphinAPI

178 States Description of paralel primitives execution Count Probability weight 1 Analog 1,1 17 UartTx & Analog 8,7 8 RadioRx 1,9 12 Standby & RadioRx 1,9 18 UartTx & RadioTx 1,9 4 Standby 11,1 2 RadioTx 12,11 16 UartTx 23.2 No primitive running 28,25 Table 27 Primitive parallel execution characteristic, TinyOS = = = m m m m m Analog m m m m m UartTx m m m m m Standby m m m m m RadioTx m m m m m RadioRx Analog UartTx Standby RadioTx RadioRx M DolphinAPI (8.2) Calculation of the system matrix for TinyOS

179 = Π DolphinAPI = a T [ p] T T ( s M ) ( ) ( ) = =.13 T (8.3) Calculation of DolphinAPI performance Π = TinyOS = a T T T [( s M ) p] = ( ) ( ) = T (8.4) Calculation of TinyOS performance Figure 74 Subtelegram spectrum of application running on DolphinAPI

180 Figure 75 Subtelegram spectrum of application running on TinyOS