PiCSE: A Framework for Simulation and Emulation ofPervasive Computing Appli ationsVin ent Reynolds

A thesis submitted to the University of Dublin, Trinity Collegein ful�llment of the requirements for the degree ofDo tor of Philosophy (Computer S ien e)Mar h 2015

De larationI, the undersigned, de lare that this work has not previously been submitted to this or anyother University, and that unless otherwise stated, it is entirely my own work.

Vin ent ReynoldsDated: 9th Mar h 2015

Permission to Lend and/or CopyI, the undersigned, agree that Trinity College Library may lend or opy this thesis upon re-quest.

Vin ent ReynoldsDated: 9th Mar h 2015

A knowledgements� Oh odswallop! It's taken me eleven years, and it's perfe t. �Edmund: AButler's Tale� � a giant roller- oaster of a novel in four hundred sizzling hapters.A searing indi tment of domesti servitude in the eighteenth entury, with somehot gypsies thrown in. My magnum opus, Baldri k. Everybody has one novel inthem and this one's mine�,Edmund Bla kadder, 1793.

I have had the pleasure of working with many olleagues who have be ome some of my losestfriends. In parti ular, Anthony, Daire, Ray, Andronikos and Melanie have supported me whenI needed it and that means a lot to me, more than I an express in these short words. There'sfar too many others to list all the names, but thanks for all the o�ees, the football, the akes,the bis uits, the Star raft and the beers.I owe a spe ial debt of gratitude to my supervisor, Vinny Cahill. His guidan e andpatien e throughout the years have kept the ship steady, and I am indebted to him for all ofthe opportunities whi h have arisen out my time in the DSG.Finally, out in the real world, I wouldn't be where I am today without the support andlove of Ba and my daughter Maya. Obrigada amores.vii

Vin ent ReynoldsUniversity of Dublin, Trinity CollegeMar h 2015

viii

Abstra tThe �eld of pervasive omputing is hanging rapidly, with the proliferation of and advan esin hardware and ommuni ation te hnologies resulting in a shift towards a large-s ale, het-erogeneous pervasive omputing world where people and devi es move seamlessly betweenpreviously isolated pervasive omputing appli ations. Prototyping and evaluation of per-vasive omputing s enarios is a ne essary yet inherently di� ult step between design anddeployment of new appli ations, and simulation has traditionally been both an e�e tive anda epted modelling and evaluation methodology that addresses this step.Previous e�orts to provide generi simulation tools that ful�ll the unique requirementsof pervasive omputing have met only limited su ess and these have typi ally fo used onextending or modifying existing tools that have been designed for other purposes. There areseveral existing simulators dedi ated to spe i� pervasive omputing domains su h as wire-less sensor networking, ontext-aware omputing, smart spa es, or intelligent transportationsystems. Additionally there are many emulators that provide platform-spe i� appli ationprogramming interfa es for the evaluation of pervasive appli ations in these domains. Per-vasive omputing now en ompasses so many sub-domains, te hnologies, and dis iplines thatperhaps it is no surprise that truly generi pervasive omputing simulators have yet to be re-ated. Previous work generally su�ers from one of two problems: simulators target a spe i� appli ation platform or a sub-domain of pervasive omputing, with the result that substantialmodi� ations are required to either simulate or integrate simulations of other sub-domains;or, generi simulators that are too abstra t require substantial e�ort in re- reating re urringelements when spe ializing the simulator to a parti ular domain.The resulting systems do not meet the modelling and evaluation requirements of large-ix

s ale, heterogeneous pervasive omputing appli ations so there remains a signi� ant openresear h hallenge in this area, whi h is to investigate whether a generi simulator an bedeveloped that an model a broad range of existing pervasive appli ations as well as newappli ations that may emerge in the future. The hypothesis of this thesis is that a framework-based approa h to building generi integrated pervasive omputing simulators and emulatorsis a su� iently �exible and extensible approa h for the evaluation and modelling of pervasiveappli ations.The use of frameworks is a well-re ognised software engineering paradigm that is appropri-ate when �exibility, extensibility and reusability are required from the outset. A framework omprises a set of abstra t lasses that apture re urring patterns within a group of relatedproblems.The ontribution of this thesis is to show that using a framework is a su� iently �exibleand extensible approa h to reating simulators and simulations for a broad range of perva-sive omputing domains. The PiCSE framework - the Pervasive Computing Simulation andEmulation Environment - identi�es the most ommon abstra tions found in this �eld, su h assensors and the physi al environment, and provides an ar hite ture for building simulators forthe many di�erent pervasive omputing sub-domains that exist. These simulators an thenbe used to reate spe i� simulations of parti ular s enarios for these sub-domains. Further-more, the framework an be used to provide an emulation environment for appli ations, andmediate the intera tion between those emulated appli ations and any simulated omponents.This thesis des ribes the design and implementation of the PiCSE framework and showshow this approa h addresses the resear h hallenge in this area. The ontribution is evaluatedby instantiating three s enarios meeting di�erent requirements su h as s ale, use of diversehardware artefa ts, and omplex appli ation exe ution environments. These instantiationsvalidate the framework's modularity, �exibility and suitability as an approa h for the reationof simulators and simulations for the modern pervasive omputing domain.x

ContentsA knowledgements viiAbstra t viiiList of Tables xixList of Figures xxChapter 1 Introdu tion 11.1 Pervasive Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.1 Current Approa hes to Evaluating Pervasive Computing Appli ations 51.2.2 A Set of Challenges for the Modelling and Evaluation of Pervasive Com-puting S enarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 A Framework Approa h to Simulating and Emulating Pervasive ComputingAppli ations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3.1 The PiCSE Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3.2 Using the PiCSE Framework . . . . . . . . . . . . . . . . . . . . . . . 121.4 The Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.4.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.4.3 Thesis Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14xi

Chapter 2 Related Work 152.1 Introdu tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Model-Based Formalisms and Methodologies . . . . . . . . . . . . . . . . . . . 162.2.1 Simulation Formalisms . . . . . . . . . . . . . . . . . . . . . . . . . . . 16The Dis rete Event System Spe i� ation . . . . . . . . . . . . . . . . . 16The Dis rete Time System Spe i� ation . . . . . . . . . . . . . . . . . 172.2.2 Emulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.3 Alternative Software-Based Methodologies . . . . . . . . . . . . . . . . 202.3 The Review Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.4 An Overview of Pervasive Computing Simulators . . . . . . . . . . . . . . . . 252.5 The Key Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.5.1 UbiWise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28RC1: Flexible Heterogeneity . . . . . . . . . . . . . . . . . . . . . . . . 29RC2: Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29RC3: Ar hite ture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29RC4: Appli ation Emulation . . . . . . . . . . . . . . . . . . . . . . . 30RC5: Intera tion of Emulated and Simulated Components . . . . . . . 30RC6: Network Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 30RC7: Experimental Support . . . . . . . . . . . . . . . . . . . . . . . . 30RC8: External Intera tion . . . . . . . . . . . . . . . . . . . . . . . . . 312.5.2 Tatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32RC1: Flexible Heterogeneity . . . . . . . . . . . . . . . . . . . . . . . . 32RC2: Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33RC3: Ar hite ture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33RC4: Appli ation Emulation . . . . . . . . . . . . . . . . . . . . . . . 33RC5: Intera tion of Emulated and Simulated Components . . . . . . . 33RC6: Network Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 34RC7: Experimental Support . . . . . . . . . . . . . . . . . . . . . . . . 34RC8: External Intera tion . . . . . . . . . . . . . . . . . . . . . . . . . 34xii

2.5.3 Lan aster Simulation Environment . . . . . . . . . . . . . . . . . . . . 35RC1: Flexible Heterogeneity . . . . . . . . . . . . . . . . . . . . . . . . 36RC2: Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36RC3: Ar hite ture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36RC4: Appli ation Emulation . . . . . . . . . . . . . . . . . . . . . . . 36RC5: Intera tion of Emulated and Simulated Components . . . . . . . 37RC6: Network Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 37RC7: Experimental Support . . . . . . . . . . . . . . . . . . . . . . . . 37RC8: External Intera tion . . . . . . . . . . . . . . . . . . . . . . . . . 372.5.4 UbiREAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38RC1: Flexible Heterogeneity . . . . . . . . . . . . . . . . . . . . . . . . 38RC2: Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39RC3: Ar hite ture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39RC4: Appli ation Emulation . . . . . . . . . . . . . . . . . . . . . . . 40RC5: Intera tion of Emulated and Simulated Components . . . . . . . 40RC6: Network Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 40RC7: Experimental Support . . . . . . . . . . . . . . . . . . . . . . . . 40RC8: External Intera tion . . . . . . . . . . . . . . . . . . . . . . . . . 412.5.5 SitCom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42RC1: Flexible Heterogeneity . . . . . . . . . . . . . . . . . . . . . . . . 42RC2: Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43RC3: Ar hite ture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43RC4: Appli ation Emulation . . . . . . . . . . . . . . . . . . . . . . . 44RC5: Intera tion of Emulated and Simulated Components . . . . . . . 44RC6: Network Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 44RC7: Experimental Support . . . . . . . . . . . . . . . . . . . . . . . . 44RC8: External Intera tion . . . . . . . . . . . . . . . . . . . . . . . . . 442.5.6 P-VoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45RC1: Flexible Heterogeneity . . . . . . . . . . . . . . . . . . . . . . . . 46xiii

RC2: Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46RC3: Ar hite ture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47RC4: Appli ation Emulation . . . . . . . . . . . . . . . . . . . . . . . 47RC5: Intera tion of Emulated and Simulated Components . . . . . . . 47RC6: Network Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 47RC7: Experimental Support . . . . . . . . . . . . . . . . . . . . . . . . 47RC8: External Intera tion . . . . . . . . . . . . . . . . . . . . . . . . . 482.5.7 StarBED2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48RC1: Flexible Heterogeneity . . . . . . . . . . . . . . . . . . . . . . . . 49RC2: Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49RC3: Ar hite ture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49RC4: Appli ation Emulation . . . . . . . . . . . . . . . . . . . . . . . 50RC5: Intera tion of Emulated and Simulated Components . . . . . . . 51RC6: Network Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 51RC7: Experimental Support . . . . . . . . . . . . . . . . . . . . . . . . 51RC8: External Intera tion . . . . . . . . . . . . . . . . . . . . . . . . . 512.6 Perspe tives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522.6.1 RC1 - Flexibility in Modelling Pervasive Computing Components . . . 542.6.2 RC4 - Appli ation Emulation . . . . . . . . . . . . . . . . . . . . . . . 602.6.3 RC6 - Network Simulator Integration . . . . . . . . . . . . . . . . . . . 612.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Chapter 3 The PiCSE Framework Ar hite ture 653.1 Introdu tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.2 A Framework-Driven Approa h for the Testing of Pervasive Computing Appli- ations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.3 A Frame of Referen e for a Pervasive Computing Simulator . . . . . . . . . . 673.3.1 The S ope of External-Fa ing Features . . . . . . . . . . . . . . . . . . 683.4 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703.5 The PiCSE_Core Ar hite ture . . . . . . . . . . . . . . . . . . . . . . . . . . 72xiv

3.6 The Composition of a PiCSE Instantiation . . . . . . . . . . . . . . . . . . . . 763.6.1 Minimum Requirements for a PiCSE Instantiation . . . . . . . . . . . 783.6.2 PiCSE Instantiations as Sub-Frameworks . . . . . . . . . . . . . . . . 803.7 Supported Abstra tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813.7.1 Supporting the Modelling of the Physi al Pervasive Computing Com-ponents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82The Obje t lass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Physi al Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853.7.2 Supporting the Modelling of the Soft Pervasive Computing Abstra tions 863.8 Emulation support within PiCSE . . . . . . . . . . . . . . . . . . . . . . . . . 873.8.1 Enabling Emulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873.8.2 The Physi al Ar hite ture for Emulated Appli ations . . . . . . . . . . 893.8.3 Supporting Multiple Appli ations . . . . . . . . . . . . . . . . . . . . . 91Dis retising an Appli ation . . . . . . . . . . . . . . . . . . . . . . . . 92Exe uting Multiple Appli ations . . . . . . . . . . . . . . . . . . . . . 933.9 Experimental Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 933.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Chapter 4 Modelling the Key Pervasive Computing Components 954.1 The PC_Abstra tion lass ategory . . . . . . . . . . . . . . . . . . . . . . . 954.2 Exe utionEnvironments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974.3 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004.3.1 Push and Pull models . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014.3.2 Measured Phenomenon . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024.3.3 Querying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024.3.4 Chara teristi s of Individual Sensor Readings . . . . . . . . . . . . . . 1034.3.5 External Interfa es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044.4 A tuators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044.4.1 Exe utionEnvironment Intera tion . . . . . . . . . . . . . . . . . . . . 1054.4.2 Modelling A tuator's E�e ts . . . . . . . . . . . . . . . . . . . . . . . . 105xv

4.5 EnvironmentLayers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064.5.1 A Single Modelled Phenomenon . . . . . . . . . . . . . . . . . . . . . . 1064.5.2 A Lo ation-Based API . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094.5.3 EnvironmentLayer Complexity . . . . . . . . . . . . . . . . . . . . . . 1114.6 EntityLayers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114.6.1 Lo ation based Intera tion . . . . . . . . . . . . . . . . . . . . . . . . . 1134.7 PiCSE as a Combinatorial Framework . . . . . . . . . . . . . . . . . . . . . . 1154.7.1 Physi al Dependen ies . . . . . . . . . . . . . . . . . . . . . . . . . . . 1164.7.2 Logi al Dependen ies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1164.7.3 Limiting the e�e ts of updates . . . . . . . . . . . . . . . . . . . . . . 1174.8 Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194.9 Con lusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Chapter 5 Evaluation 1235.1 Introdu tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1235.2 Experimental Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1235.2.1 The S enarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1265.3 The STEAM Emulation S enario . . . . . . . . . . . . . . . . . . . . . . . . . 1265.3.1 S enario Modelling requirements . . . . . . . . . . . . . . . . . . . . . 1275.3.2 Building the S enario Model . . . . . . . . . . . . . . . . . . . . . . . . 129Modelling the S enario's Software Components . . . . . . . . . . . . . 129Modelling the S enario's Hardware Components . . . . . . . . . . . . . 138Interlinking of Simulated Hardware and Software Components . . . . . 1395.3.3 Exe uting the S enario Simulation . . . . . . . . . . . . . . . . . . . . 141Initialising the Experimental S enario . . . . . . . . . . . . . . . . . . 141Exe ution of the Simulation . . . . . . . . . . . . . . . . . . . . . . . . 1435.3.4 S enario Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Insights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Evaluating the PiCSE requirements . . . . . . . . . . . . . . . . . . . . 1535.4 The Car Hardware S enario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154xvi

5.4.1 S enario Modelling requirements . . . . . . . . . . . . . . . . . . . . . 1555.4.2 Building the S enario . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Modelling the s enario's software omponents . . . . . . . . . . . . . . 156Modelling the s enario's hardware omponents . . . . . . . . . . . . . 159Interlinking of simulated hardware and software omponents . . . . . . 1605.4.3 Exe ution of the modelled domain . . . . . . . . . . . . . . . . . . . . 162Initialising the experimental s enario . . . . . . . . . . . . . . . . . . . 162Exe ution of the simulation . . . . . . . . . . . . . . . . . . . . . . . . 1625.4.4 S enario Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Insights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Evaluating the PiCSE requirements . . . . . . . . . . . . . . . . . . . . 1655.5 The Intelligent Transportation Systems S enario . . . . . . . . . . . . . . . . 1675.5.1 S enario Modelling Requirements . . . . . . . . . . . . . . . . . . . . . 1685.5.2 Building the Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Modelling the S enario's Software Components . . . . . . . . . . . . . 169Modelling the s enario's Hardware Components . . . . . . . . . . . . . 1695.5.3 Exe ution of the modelled domain . . . . . . . . . . . . . . . . . . . . 173Initialising the Experimental S enario . . . . . . . . . . . . . . . . . . 173Exe ution of the simulation . . . . . . . . . . . . . . . . . . . . . . . . 1745.5.4 S enario Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Insights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Evaluating the PiCSE requirements . . . . . . . . . . . . . . . . . . . . 1785.6 Requirements Validation and Con lusion . . . . . . . . . . . . . . . . . . . . . 1805.6.1 Requirements R1, R2, and R3 . . . . . . . . . . . . . . . . . . . . . . . 1805.6.2 Requirement R4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1825.6.3 Requirement R5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1835.6.4 Requirement R6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1845.6.5 Requirement R7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1845.6.6 Con lusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185xvii

Chapter 6 Con lusions 1876.1 The Challenge Restated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1876.2 The Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1886.3 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1896.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Appendix A Appendix 193A.1 PiCSE Ar hite ture Header Files . . . . . . . . . . . . . . . . . . . . . . . . . 193A.2 Evaluation S enarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230Bibliography 241

xviii

List of Tables2.1 Simulator Review Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2 Comparing the review riteria for the key pervasive omputing simulators . . 532.3 Pervasive Computing Components Modelled . . . . . . . . . . . . . . . . . . . 545.1 Requirement evaluation metri s . . . . . . . . . . . . . . . . . . . . . . . . . . 1255.2 The STEAM API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1295.3 System alls made by STEAM to the underlying operating system. . . . . . . 1305.4 The DUMMY-SEAR API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1325.5 Lines of ode required to implement the STEAM emulation s enario . . . . . 1495.6 Requirements analysis for the STEAM emulation s enario . . . . . . . . . . . 1535.7 Mapping from system alls to their emulated equivalent . . . . . . . . . . . . 1585.8 Requirements analysis for the Car Hardware s enario . . . . . . . . . . . . . . 1665.9 Requirements analysis for the ITS s enario . . . . . . . . . . . . . . . . . . . . 1795.10 Overall requirements analysis for R1, R2 and R3 . . . . . . . . . . . . . . . . 1815.11 The hardware and software models required by the three evaluation s enarios 1825.12 Overall requirements analysis for R4 . . . . . . . . . . . . . . . . . . . . . . . 1835.13 Overall requirements analysis for Requirement 5. . . . . . . . . . . . . . . . . 1835.14 Overall requirements analysis for Requirement 7. . . . . . . . . . . . . . . . . 184

xix

List of Figures2.1 Overlapping Domains of Pervasive Computing Simulators . . . . . . . . . . . 263.1 The PiCSE_Core ar hite ture . . . . . . . . . . . . . . . . . . . . . . . . . . . 743.2 Con eptual ar hite ture showing layers within a generi instantiation of thePiCSE framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763.3 Con eptual diagram of a PiCSE simulation in Algorithm Mode . . . . . . . . 793.4 A PiCSE instantiation in Appli ation Mode . . . . . . . . . . . . . . . . . . . 803.5 UML Sequen e diagram depi ting ollo ated obje ts s enario . . . . . . . . . 843.6 A split level implementation of the PiCSE support for emulating appli ations 884.1 The lo ation of the PC_Abstra tion lasses within the logi al ar hite ture. . 964.2 Obje ts instantiated from the PC_Abstra tion lass ategory are pre-de�nedto intera t using ertain methods. . . . . . . . . . . . . . . . . . . . . . . . . . 974.3 The pro ess by whi h a reading passes through a pipeline formed of a ombi-nation of blo king and modifying �lters . . . . . . . . . . . . . . . . . . . . . 1034.4 Temp_environment lass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074.5 A Pre ipitationLayer obje t models rainfall within the simulated environment. 1084.6 EnvironmentLayer instantiations an intera t dire tly with other Layers . . . 1094.7 Obje t instan es within lose proximity, de�ned by the grid's dis retised spa e,are bundled into a single list . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124.8 Cal ulating the Obje t instan es within a ertain range in EntityLayer instan-tiations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114xx

4.9 Logi al dependen ies an be aptured using Loose or Stri t Causality . . . . . 1185.1 CommandSensor announ es event types periodi ally . . . . . . . . . . . . . . 1275.2 The CommandSensor appli ation broad asts events to his subs ribers. . . . . 1285.3 The appropriate point at whi h STEAM should be emulated must be deter-mined by the user and is not onstrained by PiCSE. . . . . . . . . . . . . . . 1305.4 STEAM is omprised of an RTE and SUMMY_SEAR library. . . . . . . . . . 1315.5 Extra ts from the emulated STEAM library, as de�ned in steamExe Env.h.The full de�nition of this program may be found in the Appendix. . . . . . . 1335.6 Original STEAM library and emulated STEAM library . . . . . . . . . . . . . 1345.7 Comparing original behaviour of the Dummy-SEAR and the emulated DUMMY2-SEAR omponents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1355.8 Extra ts from the CommandSensor program, whi h is de�ned in Command-Sensor. pp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1365.9 Extra ts from the TestDevi e program, whi h is de�ned in TestDevi e. pp . . 1375.10 The TestDevi e event allba k fun tion, whi h is de�ned in TestDevi e. pp . 1375.11 Modelling of a stati obje t an be a hieve by passing a lo ation parameterduring the instantiation of an Exe utionEnvironment obje t. . . . . . . . . . . 1385.12 Physi al obje ts an be parameterised with a mobility pattern whi h de�nestheir movement during the s enario experiment. . . . . . . . . . . . . . . . . . 1395.13 Code fragment demonstrating the interlinking of the s enario's TestDevi e ap-pli ation and emulated STEAM middleware instan e. . . . . . . . . . . . . . . 1405.14 Code fragment demonstrating the interlinking of the s enario's CommandSen-sor appli ation, emulated STEAM middleware instan e and the modelled mo-bile devi es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1415.15 Code fragment showing the initialisation of the PiCSE_Core aspe ts of theSTEAM s enario environment. . . . . . . . . . . . . . . . . . . . . . . . . . . 1425.16 Code fragment showing the initialisation of the STEAM s enario environment. 1435.17 A s reenshot showing the logged output from the STEAM emulation evaluation.144xxi

5.18 A se ondary s reenshot showing the logged output from the STEAM emulationevaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1455.19 Original STEAM library and emulated STEAM library . . . . . . . . . . . . . 1475.20 Table showing the number of modi�ed lines of ode with the emulated DUMMY-SEAR library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1505.21 Photograph of the hardware being emulated. . . . . . . . . . . . . . . . . . . 1545.22 The hardware setup of the Car Hardware S enario. The program running onthe IPAQ, onsumes sensor data via the PIC board. . . . . . . . . . . . . . . 1555.23 System alls made by the IPAQ appli ation . . . . . . . . . . . . . . . . . . . 1575.24 System all de�nition �les for the invoked system alls . . . . . . . . . . . . . 1595.25 Co-lo ation of Exe utionEnvironment and the IPAQ appli ation . . . . . . . . 1615.26 Co-lo ation of Exe utionEnvironment and Sensor Obje ts . . . . . . . . . . . 1615.27 A s reenshot showing the logged output from the Car Hardware S enario eval-uation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1635.28 The Dublin City road tra� network . . . . . . . . . . . . . . . . . . . . . . . 1675.29 A snippet from the ity entre.xml �le des ribing the road network topologyand onstraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1705.30 A sample entry from the path de�nition �le . . . . . . . . . . . . . . . . . . . 1725.31 A se tion of ode demonstrating how the ar path �le is parsed. . . . . . . . . 1745.32 Parsing the CityCentre.xml map �le . . . . . . . . . . . . . . . . . . . . . . . 1745.33 Two s reenshots from a visualisation of the Dublin tra� s enario . . . . . . . 1755.34 A vehi le intera ts with its environment to inform its next movement . . . . . 177A.1 Ar hite ture Diagram for typi al instantiation . . . . . . . . . . . . . . . . . . 193A.2 Class Category distribution of header �les. . . . . . . . . . . . . . . . . . . . . 194xxii

Chapter 1Introdu tionSimulation an play an important role in the life- y le of software engineering proje ts (Zeigler 00).This is parti ularly true in the ase of pervasive omputing where the s ale of appli ations anbe large and they are often designed to be deployed in less than ideal physi al environments(Raza�ndralambo 10). Designing a simulator that meets the modelling requirements of per-vasive omputing is a di� ult hallenge arising from three fa tors: there is a broad diversity ofappli ation areas within the domain; these appli ation areas are now interse ting, and �nally,new appli ation areas are emerging qui kly. At present, new simulation tools are being de-veloped to keep pa e with ea h new appli ation area (Mangharam 06; Eugster 06; Jouve 09)within the evolving pervasive omputing domain. This thesis des ribes the Pervasive Com-puting Simulation and Emulation (PiCSE)1 framework, its ar hite ture and design, the om-bination of whi h addresses these hallenges.PiCSE is a framework (Johnson 88) that supports both the reation of pervasive om-puting simulators and individual simulations through the modelling of re urring pervasive omputing abstra tions and their relationships. The reation of domain-spe i� pervasive omputing simulators su h as intelligent transportation system (ITS) simulators or smart-spa e simulators is enabled by spe ialising the PiCSE framework's abstra tions to reatedomain-spe i� abstra tions.The instantiation of a group of PiCSE abstra tions, or of any spe ialised domain-spe i� 1 Pronoun ed as Pixie 1

1.1. Pervasive Computingabstra tions provided by a domain-spe i� simulator results in the reation of an instan esimulation: a simulated model of a spe i� pervasive omputing s enario. Moreover, thePiCSE framework supports the emulation of appli ations that form an integral part of theses enarios, and these emulated appli ations an be integrated into instan e simulations. ThePiCSE simulation engine, whi h underpins the framework, mediates the intera tion of em-ulated appli ations with simulated artefa ts. PiCSE's �exible approa h enables a person toinstantiate the framework to reate domain-spe i� simulators and simulations to evaluate adiverse range of pervasive omputing appli ation areas.The remainder of this hapter is stru tured as follows. Se tion 1.1 provides a broadintrodu tion to the area of pervasive omputing. The motivation and urrent methodologiesfor evaluating pervasive omputing appli ations are presented in se tion 1.2 whi h then drawson a dis ussion of these approa hes in the �eld to derive the key hallenges in this area. Se tion1.3 introdu es the on ept of frameworks and suggests why a framework-driven approa hmight be su essful in addressing these hallenges. A des ription of the ontribution of thethesis and the evaluation methodology used is provided in se tion 1.4 and a road map of theremainder of the thesis on ludes this hapter.1.1 Pervasive ComputingPervasive omputing (Weiser 91; Weiser 93) as an area of resear h is one that en ompassesmore fo used areas su h as ambient intelligen e (Bres iani 04), sensor networking (He 04), ontext-aware omputing (Benere etti 01), and smart spa es (Dearle 03). Consider the follow-ing pervasive omputing appli ations. Smart-spa es (Tapia 04) are often passive appli ations,a ting in the ba kground and driven by lo al sensors, whi h an then adapt some aspe t of thespa e su h as a ess ontrol (Selvarajah 10) or telephone all re-routing to a user's require-ments. An environmental-monitoring wireless sensor network (Ji 04) ould omprise sensors,perhaps monitoring pre ipitation, noise, or temperature, atta hed to wireless sensor motesthat propagate that sensor information to other sensor motes through an ad-ho ommuni- ation network. Intelligent transportation systems (Klein 01) typi ally use embedded sensorssu h as indu tive loops in the road network as inputs into algorithms (Salim 08) that improve2

Chapter 1. Introdu tionthe throughput of the vehi les in the system. Despite the diversity of these appli ations, allof them an be onsidered to lie within the broad domain of pervasive omputing.More re ently, there has been a shift towards the integration of heterogeneous pervasive omputing appli ations. As adoption and deployment of pervasive omputing te hnologiestakes hold, the physi al and logi al boundaries between these appli ations are being redu edand now overlap in many ases (Handte 09). The traditional notion of a pervasive omputingappli ation as a losed, isolated system is being eroded with the integration of servi e-orientedar hite tures into pervasive omputing appli ations (Guinard 10), enabling users to exploitthe servi es and fun tionality of di�erent pervasive omputing appli ations as they move be-tween them. If the integration of these pervasive appli ations is to be su essful, informationdes ribing users of these appli ations and the appli ations themselves must be freely availableand understandable by all so that it an be onsumed by all pervasive omputing appli a-tions when and where they need it. As a result, there has been attempts re ently towards entralising these servi es: two re ent examples are Google Latitude2 whi h provides servi esfor managing a user's lo ation and Conserv (Hynes 09) whi h manages a wider spe trum of auser's ontextual data su h as their alendar events and personal devi es that might identifythem.In addition, a new lass of ad-ho pervasive omputing is now emerging with the userat its entre. In itizen sensing (Campbell 08) or parti ipatory sensing as it is sometimesknown, users with powerful sensor-enabled mobile devi es are augmenting, and in some asesrepla ing, stati embedded sensors in the physi al environment. The �wisdom of rowds�, ortheir olle tive sensed information in this ase, is leading to innovative rowd-sour ed ap-proa hes to environmental monitoring (Lu 09) and even supporting the reation of intera tiveart installations (Vyas 10).These examples represent a small sub set of all the domains that pervasive omputingaddress, yet despite the diverse nature of these pervasive omputing sub-domains, there are aset of re urring hara teristi s that are ommon within them. They are typi ally deployed insensor-equipped spa es, whether those sensors are stati or mobile, where information regard-2www.google. om/latitude 3

1.2. Motivationing the environment and lo al ontextual information is leveraged by appli ations to providemore tailored and ontextualised fun tionality and servi es within that environment. In ad-dressing this area, pervasive omputing appli ations have to ontend with many non-trivialproblems in luding dependability, large s ale, physi al distribution, se urity and timeliness.Moreover, typi al environments in whi h these appli ations are deployed in lude buildingsfor smart-spa e s enarios (Tapia 04), rugged terrain for environmental monitoring (Ji 04) androad networks for intelligent transportation systems (Klein 01). These environments are oftenphysi ally in a remote lo ation making deployment and maintenan e both di� ult and ostly.1.2 MotivationModelling and evaluation plays a riti al role in the life- y le of any software engineeringproje t but presents some parti ular hallenges in pervasive omputing appli ation s enar-ios. The appli ation typi ally extends beyond the omputer into the physi al environmentthrough the use of sensors, a tuators, or lo ation-based servi es. The impli ations for thetesting of these s enarios is that the omplete pervasive omputing e o-system, in luding theenvironment, devi es, their users and other fa tors should be onsidered. However, this in-trodu es di� ulties that must be over ome. Testing in physi al environments su h as o ean�oors (Jiang 09), o� es and homes (Selvarajah 10) to road networks (Salim 08) and sportsenvironments (Kranz 07) an be invasive, disruptive and often hampered by bureau ra y, ifa ess is even available. Many of these appli ations are predi ated upon hardware te hnolo-gies su h as heap, reliable sensors, for example, radio frequen y identi� ation tags (Xu 10) orwireless sensors (Medagliani 10), whi h are yet to be widely deployed or even available in thes ales that are envisioned, and as a result, a urate real-world deployments in some domainsmay not yet be feasible. Pervasive omputing appli ations in the areas of intelligent trans-portation systems or urban-sensing for example, an involve the intera tion of thousands ortens of thousands of elements. Finally, the evolving nature of the �eld means that new areasare emerging and the pervasive omputing ommunity urrently la ks the appropriate toolsto evaluate some of these areas su h as parti ipatory-sensing (Campbell 08). In these ases,proof-of- on ept prototypes or ustom evaluation tools may have to be developed. Fa tors4

Chapter 1. Introdu tionsu h as these impa t upon the time and e�ort required to evaluate and debug a pervasive om-puting prototype, parti ularly when onsidering that an exhaustive set of ontrolled s enariosmay have to be deployed in order to evaluate a prototype rigorously.1.2.1 Current Approa hes to Evaluating Pervasive Computing Appli a-tions(Nakata 07) lists testbeds, small-s ale laboratory tests and simulation as three methodologiesfor evaluating pervasive omputing appli ations. Whi h of these methodologies is hosen toevaluate any parti ular pervasive omputing s enario is in�uen ed by experimental fa torssu h as the appli ation's urrent stage of development and on what the desired out ome ofthe evaluation is. The methodology hosen an additionally be in�uen ed by lo al fa torssu h as the tester's a ess to hardware devi es and testing fa ilities, osts, and the time thatis available to test the appli ation. If the purpose of the evaluation is to validate whether apervasive omputing appli ation is robust enough to be ready for a ommer ial release andsubsequent real-world deployment, then an appropriate evaluation methodology might be touse a large-s ale testbed, whereas in the reation of an appli ation prototype in an emerginglarge-s ale �eld, a simulation-based evaluation may be used.Physi al testbeds su h as the Twist (Handziski 06) and MoteLab (Werner-Allen 05) testbedsprovide an experimental platform in whi h appli ations are exe uted on hardware devi esin a stable environment, where there is usually a supporting infrastru ture in the form ofba k- hannels and monitors for the management, ontrolled exe ution and debugging of ex-periments. Using native hardware devi es as the platform for an experiment potentially givesgreater redibility to results gathered from any experiment when ompared, for example, withsimulated results however, the methodology and supporting infrastru ture usually restri ts thetestbed to that parti ular platform and thus to a spe i� domain of pervasive omputing. Todate, most testbeds are very domain spe i� , have not been designed with integration ofother domains in mind and thus are not suitable as a generi pervasive omputing evaluationplatform.Small s ale laboratory testing is a methodology similar to the use of testbeds in that5

1.2. Motivationexperiments are exe uted on real hardware devi es. In ontrast to testbeds however, there israrely a permanent infrastru ture supporting the experiments, resulting in experiments thatare often not very s alable and that an be di� ult to reprodu e in other laboratories.Finally, there are several existing pervasive omputing simulators but few that re ogniseor re�e t that pervasive omputing is be oming a more multi-dis iplinary domain with newemerging areas of resear h and their rossover with existing areas of resear h. As an eval-uation methodology, simulation's popularity is demonstrated by its wide a eptan e withinthe pervasive omputing ommunity as a valid methodology, and many simulation librariesare open-sour e and are available for little or no ost (Fall 01; Martin 06a) so it has a lowbarrier of entry in this respe t. However, in general, these simulators are rarely designed forinter-operation (Kuhl 99) and are not apable of modelling the diverse range of pervasive om-puting s enarios that exist, i.e., a network simulator is not readily adapted to the modellingof a ontext-aware omputing s enario be ause it was not intended to model on epts su h asuser behaviour and a tivities. Therefore, any simulated s enario that in ludes both aspe ts of ontext-aware omputing and wireless networking requires either the reation of a new sim-ulation tool for that parti ular domain, or the modi� ation and integration of existing tools.In addition to simulation, emulation provides a low ost alternative to the evaluation of appli- ations by removing the physi al requirement for the intended devi e platform to be availablefor the evaluation of a parti ular appli ation. S alable and ost-e�e tive prototyping an bea hieved as multiple instan es of an emulator an be run in parallel, without the experimentaloverhead of managing and deploying an appli ation on the hardware devi es. Many existingemulators within the pervasive omputing domain are written for appli ations targeted fora single spe i� platform. For example, the TOSSIM emulator (Levis 03) supports TinyOS(Hill 00) appli ations only, although these an run on several related hardware platforms su has the TMote Sky3 and the MoteIV. By onstraining an emulator to a single appli ation plat-form, an emulator is impli itly onstraining its s ope to a spe i� domain as these appli ationplatforms are generally domain-spe i� , in this ase, wireless sensor networking.3www.sentilla. om 6

Chapter 1. Introdu tion1.2.2 A Set of Challenges for the Modelling and Evaluation of PervasiveComputing S enariosThis thesis is on erned with methodologies that are both suitable for the evaluation of awide range of diverse pervasive omputing s enarios and that an be extended to evaluate news enarios that may emerge in the future.It an be seen from the approa hes that have been des ribed in the pre eding se tions thattestbeds, small-s ale laboratory testing, simulators and emulators meet these requirements tovarying degrees of su ess. Testbeds are very e�e tive tools and an provide ex ellent ex-perimental support, however they are expensive to reate and maintain, and are usually onstrained to a single appli ation domain and hardware platform. In many domains su h asintelligent transportation systems (ITS) and urban sensing, large-s ale testbeds may not evenbe feasible to anyone ex ept the largest industrial resear h labs. Whilst it is possible to reatebespoke small-s ale laboratory tests for almost any domain, these are inherently limited ins ale, are often built without onsideration for extensibility and require physi al re on�gura-tion for ea h new s enario. In the ase of both existing simulators and emulators, there are awide range of domain-spe i� tools and libraries in existen e whi h are often extensible withintheir domain but annot be easily integrated with ea h other despite their software-only ap-proa h. They additionally address omplimentary aspe ts of pervasive omputing s enarios.Simulators an model and be used to evaluate physi al elements su h as sensor devi es, users,a wireless network, and the environment, whilst an emulator an model the run-time environ-ment of appli ations that exe ute within those s enarios and potentially intera t with thoseelements. In on lusion, there is no one size �ts all evaluation strategy that an be appliedto pervasive omputing appli ations however, a �exible and ombined approa h of both sim-ulation and emulation ould potentially support the evaluation of large-s ale heterogeneousappli ations.Based on the issues identi�ed in the overview of pervasive omputing domains in se tion1.1 and in the range of modelling and testing methodologies used to evaluate those domainsin se tion 1.2.1, the following resear h problem has been identi�ed. As pervasive omput-ing appli ations grow in s ale and ubiquity, the range of elements that have be taken into7

1.2. Motivation onsideration when evaluating those appli ations is also in reasing. However, all of the eval-uation methodologies su�er to a ertain degree from the same weakness, in that they are tiedto a spe i� pervasive omputing domain and are generally not designed to be extended toevaluate new appli ations whi h ould draw from more than one independent domain.One of the main arguments for maintaining the status quo of testing individual aspe tsof parti ular pervasive omputing domains in isolation is the need for rigorousness in theexperimental method. By isolating as many experimental fa tors as possible, it is then easierto a hieve quanti�ably independent, reprodu ible and obje tive results. Certainly, using asingle independent simulator is at least theoreti ally more suitable for this task. However, ashas been noted, new multi-dis iplinary areas of pervasive omputing su h as vehi ular ad-ho networks (VANETs) and smart spa es makes it more di� ult to treat these areas in isolation.In the ase of VANETs(Klein 01), the behaviour model responsible for the movement of avehi le is a fa tor in the e�e tiveness of a routing proto ol that might be running within thatVANET. Of ourse, the behavioural model of the vehi le an be redu ed to a plug-in or amobility pattern that might be integrated into a network simulator, but that model still has tobe built by an expert in the vehi ular ommunity. Furthermore, there may be appli ations inthe future whereby the out ome of an appli ation that is using the routing proto ol in�uen esthe behaviour of the vehi le. In that ase, the limitations of a simple plug-in based approa hwill be exposed and the integration of both network and vehi le simulators will then have toa hieved.The following hallenges have been identi�ed as key issues in addressing this open resear hproblem:1. Flexible Heterogeneity: Any simulator or emulator should be able to support hetero-geneous elements, both hardware and software based, and the fa t that these elements an intera t in a manner that is unrestri ted by any adopted approa h. These elementsmay ome from di�erent pervasive omputing domains.2. Extensibility: Any simulator or emulator should be able to a ommodate new emerg-ing areas of pervasive omputing not yet identi�ed, where these new areas an ompriseof both new hardware and software elements not yet identi�ed.8

Chapter 1. Introdu tion3. Reusability: Any simulator or emulator should simplify the task of building and inte-grating elements that are to be evaluated.Simulation and emulation are two evaluation methodologies that an support large-s ale s e-narios and that are ommonly implemented using extensible ar hite tures, albeit generallywithin their domain only. The hypothesis of this thesis is that a new framework-based ap-proa h to building generi integrated simulators and emulators for pervasive omputing ap-pli ations is a su� iently �exible, extensible, and reusable approa h for the evaluation andmodelling of these appli ations. These three hallenges are not exhaustive by themselveshowever. There are additional hallenges in this area that in lude:1. Modelling Large-S ale S enarios: Many pervasive omputing appli ations requirethe intera tion of many thousands of intera ting features su h as appli ations, sensors,and users, and in some ases even more. This motivates the need for a s alable approa hin addressing this hallenge.2. Timeliness: The realisti modelling of appli ation behaviour in many pervasive om-puting domains ne essitates the a urate modelling of the time taken for an event su has a sensor reading or an appli ation behaviour.Whilst these are important hallenges in the simulation of pervasive omputing appli ations,they are not the key hallenges when addressing the issue of the modelling and simulationof overlapping of new and emerging pervasive omputing appli ation domains. Nevertheless,these two hallenges present se ondary hallenges and their onsideration is addressed inthe thesis where appropriate. Finally, appli ation-spe i� requirements su h as se urity anddependability provide additional hallenges but these are pertinent to the appli ations thatmay run within the s enarios and are not spe i� features that are addressed independentlyin this study. 9

1.3. A Framework Approa h to Simulating and Emulating Pervasive ComputingAppli ations.1.3 A Framework Approa h to Simulating and Emulating Per-vasive Computing Appli ations.Johnson et al (Johnson 88) de�ne a framework as�a set of lasses that embodies an abstra t design for solutions to a family ofrelated problems.�This de�nition en apsulates the abstra t nature of frameworks, while apturing their suitabil-ity to addressing families of related problems. Other de�nitions, notably those of Campbell(Campbell 91) and Boo h (Boo h 93) in orporate the on ept that the olle tion of lasses onstituting a framework, intera t in a de�ned manner or pattern. The bene�ts of usingframeworks are well known, and S hmidt (S hmidt 97) lists these primarily as modularity,reusability and extensibility. He states, that frameworks�enhan e modularity by en apsulating volatile implementation details behind sta-ble interfa es. This lo alisation redu es the e�ort required to understand andmaintain existing software.�This de�nition highlights the use of stable interfa es de�ned by a framework to abstra t fromthe implementation of the framework. He goes on to state that stable interfa es�provided by frameworks enhan e reusability by de�ning generi omponents that an be reapplied to reate new appli ations. Framework reusability leverages thedomain knowledge and prior e�ort of experien ed developers in order to avoid re- reating and re-validating ommon solutions to re urring appli ation requirementsand software design hallenges.�This de�nition of reusability a knowledges that if re urring requirements and software design hallenges an be identi�ed amongst a set of related problems, then these an be exploitedwithin a framework to redu e the e�ort in reating new appli ations. Finally, S hmidt et al(S hmidt 97) state that a well-designed framework enhan es extensibility10

Chapter 1. Introdu tion�by providing expli it hook methods that allow appli ations to extend its stableinterfa es.�and that�framework extensibility is essential to ensure timely ustomisation of new appli- ation servi es and features.�The bene�ts of extensibility are lear within frameworks, as it means that the framework anbe extended to support new appli ation features identi�ed in addition to the original set ofrelated appli ation features.1.3.1 The PiCSE FrameworkThe PiCSE framework is implemented as a set of abstra t lasses that an be grouped intotwo lass ategories (Kru hten 95), the PC_Abstra tions and the Abstra t_Interfa es lass ategories, that address the three key hallenges identi�ed; �exible heterogeneity, extensibility,and reusability. A third lass ategory, the Core_Components lass ategory, provides a setof ore omponents, for example, the simulation engine, that underpin and are ommon, toall simulations reated using the PiCSE framework.PiCSE's PC_Abstra tions lass ategory provides the lass de�nitions of re urring ele-ments of pervasive omputing appli ations su h as sensors, environments, and appli ationplatforms. These abstra tions are designed to be su� iently generi that they may be in-stantiated to reate a diverse range of on rete instan es with variable hara teristi s, thusmeeting the requirement of supporting heterogeneity. In addition to this, the abstra tions takeinto onsideration the likely intera tions between these instantiations, and the framework ap-proa h allows on rete instan es to be modularly ombined, allowing the �exible reation ofmore omplex instantiations.The framework's Abstra t_Interfa es lass ategory omprises a set of abstra t interfa esthat also underpin the PC_Abstra tions lass ategory, allowing for the extension of theframework to reate new abstra tions. These set of abstra tions apture on epts su h asmobility, whether an obje t an be arried, whether a feature an be sensed, and others that11

1.4. The Thesisare re urring a ross pervasive omputing domains. This lass ategory addresses the hallengeof extensibility within the framework's ar hite ture that an a ount for emerging domainsin the future.The framework-driven approa h addresses the hallenge of reusability by providing om-mon solutions to re urring appli ation requirements and software design hallenges. All three lass ategories, the PC_Abstra tions, Abstra t_Interfa es and Core_Components lass at-egories ontribute here by providing the base of an extensible framework, that also aptureshow these omponents an potentially intera t. The apture of these re urring omponentsand their intera tions in a generi way within the framework redu es the e�ort required to reate new simulators and simulations.1.3.2 Using the PiCSE FrameworkThe PiCSE framework an be spe ialised by domain experts to a range of pervasive omputingsub-domains. Two experts in separate domains an spe ialise the PiCSE framework usingPiCSE's re urring intera tion patterns to reate simulators for their respe tive sub-domains,and that these simulators an themselves be provided in the form of frameworks that an befurther spe ialised where appropriate. Furthermore, simulated and emulated elements of therespe tive sub-domains an exist and intera t within the same simulated spa e if desired.1.4 The ThesisDomain-spe i� simulators address parti ular appli ation domains su h as wireless sensornetworking or ontext-aware omputing and these play an important role in the evaluationof individual appli ation areas. However, their onstrained and in�exible ar hite tures donot meet the modelling and evaluation requirements of large-s ale, heterogeneous pervasive omputing appli ations so there remains a signi� ant open resear h hallenge in this area,whi h is to investigate whether a generi simulator an be developed that an model a broadrange of existing pervasive appli ations as well as new appli ations that may emerge in thefuture. 12

Chapter 1. Introdu tionThis thesis addresses this open resear h hallenge. PiCSE's framework-driven approa hand lass ategory implementations will be shown to be su� iently �exible and extensiblethat users an reate simulators for a broad range of pervasive omputing appli ations thathave diverse hara teristi s, and is a novel ontribution to the state of the art in this �eld.1.4.1 ImplementationThis framework approa h is implemented as a set of C++ (Stroustrup 98) libraries, that aregrouped into three separate lass ategories. The simulation engine underlying the system isbuilt upon an existing event-based simulator, Simpa k (Fishwi k 95), whi h has been extendedusing a multi-thread approa h to seamlessly and �exibly manage multiple heterogeneous emu-lated appli ations and simulated hardware omponents. Furthermore, the engine supports theintera tion of both these simulated hardware omponents and emulated appli ations, enablingrealisti input and output hannels to be reated for the emulated appli ations. Appli ationsthat intera t dire tly with an underlying operating system via system alls or alternativelythat are built upon middleware an be modelled.1.4.2 EvaluationThree instantiations of the framework were reated to validate the hypothesis of the thesis'sframework-driven approa h. In the �rst So ial-Sensing S enario, an event-based middleware isemulated. Appli ations that are built upon that middleware then ex hange messages whilstmoving around a onstrained physi al spa e. In the se ond Car-Hardware Emulation S e-nario, Linux system alls are emulated, and appli ation instan es use those system alls tointera t with simulated sensors reading data from the environment. The third and �nal In-telligent Transportation Systems S enario models vehi ular tra� in part of Dublin, Irelandand demonstrates the simulator's support for large-s ale simulations, a omplex environment,and omplex inter-related obje t types. 13

1.5. Summary1.4.3 Thesis RoadmapThe remaining hapters of this thesis provide a detailed des ription of the PiCSE framework,its ontribution to the state of the art and an evaluation of the work. Chapter 2 providesan examination of the state of the art in simulators and emulators for pervasive omputingand related domains. Chapter 3 des ribes the framework, its ar hite ture and design and anadditional se tion within that hapter also des ribes the framework's support for the emulationof appli ations. Chapter 4 examines the implementation and features of the key omponentssupported in more detail. An evaluation of the thesis and its ontributions is do umented inChapter 5 and the on lusions are presented in Chapter 6.1.5 SummaryThis hapter outlines the motivation for, approa h, and ontribution of the thesis - the designof a framework that an be spe ialised to reate simulations of pervasive omputing s enar-ios. An introdu tion to the area of pervasive omputing is presented to de�ne the s ope ofthe thesis. The work is then motivated by examining the urrent methodologies for evaluat-ing pervasive omputing s enarios and identifying a set of open hallenges. An overview ofPiCSE's framework-based approa h is then provided before the ontribution of the thesis ispresented.

14

Chapter 2Related Work2.1 Introdu tionThe use of simulation as a valid methodology for the modelling and evaluation of pervasive omputing appli ations has been established, and three ore hallenges, �exibility, extensibil-ity, and reusability have been identi�ed that must be addressed by generi simulators for thebroad pervasive omputing domain. This thesis des ribes a modular generi and extensibleapproa h that enables the simulation of a broad range of existing pervasive omputing ap-pli ations as well as new appli ations that may emerge in the future. The obje tive of this hapter is to examine established and prior works in this area that have attempted to addressthese resear h hallenges. In doing so, the strengths and weakness of these approa hes areidenti�ed and these will be used to derive requirements for the proposed framework-drivenapproa h that forms the ontribution to this thesis.In this hapter, an overview is provided of the many simulators in this �eld; examiningboth generi pervasive omputing simulators that attempt to address the entire domain, aswell as some of the simulators for the many sub-domains of pervasive omputing. What isestablished is that there are few truly generi simulators that take a �exible and extensibleapproa h to modelling the pervasive omputing domain as a whole.This hapter begins by providing a brief overview of some of the lassi al simulationformalisms and methodologies. Based on these and the hallenges identi�ed in hapter one,15

2.2. Model-Based Formalisms and Methodologiesa set of evaluation riteria are identi�ed by whi h the simulators established in this state ofthe art will be examined. A broad overview of the representative work in this �eld is thenprovided, before seven of the most well known and ited simulators representing the stateof the art in this spa e are then examined. The salient points and other notable features ofea h simulator are noted, and these simulators are measured against the evaluation riteria.Finally, Se tion 2.6 takes a step ba k and o�ers a wider view on the issues raised by theexamination of the simulators. Additional simulators are onsidered at this stage to broadenthe overall perspe tive, and assess alternative approa hes and features that are not employedby those examined in detail.2.2 Model-Based Formalisms and Methodologies2.2.1 Simulation FormalismsSimulation is a software-oriented modelling and evaluation methodology and is one of the mostpopular and widely used within the pervasive omputing ommunity today. A simulation isa des ription of a system, or at least of some of its omponents expressed in terms of a set ofstates and events (Zomaya 96). Several simulation formalisms exist (Law 00), most notablythe dis rete event system spe i� ation but also the dis rete time system spe i� ation, and thedi�erential equation system spe i� ation formalisms.The Dis rete Event System Spe i� ationThe most popular formalism, the Dis rete Event System Spe i� ation, known as DEVS(Zomaya 96), spe i�es a system in terms of a time base, a set of inputs, outputs, urrentstate, and a set of state transition fun tions. An implementation of a DEVS simulator typ-i ally ontains a time-ordered list of events, often in the form of fun tion pointers, a lo k,some state information, a set of fun tions for handling events and a loop that advan es thesimulation. As the lo k progresses to the time of the next s heduled event, that event isremoved from the event list and any orresponding fun tionality to that event is invoked.This fun tionality an have two e�e ts: Firstly, a hange in the state information may o ur,16

Chapter 2. Related Workand se ondly, the event list may be updated, whereby either more events are s heduled in thefuture or existing future events are an elled. The hallenge in building a su essful modelor simulation of any system is in the implementation of fun tionality asso iated with anypro essed events.DEVS, as a formalism, an also be extended to parallel and distributed ar hite tures(Fujimoto 00; Tropper 02). Simulations of omplex systems an take a long time on singlesequential ma hines, and opportunities to parallelise these simulations an greatly speed upthe exe ution of these simulations. The amount of a tual gain that an be a hieved in su hsystems is determined by a number of fa tors in luding the spe i� ation of the level of �delityrequired and the inter-dependen e of any parallelised data sets and pro esses.One weakness of the DEVS formalism is that the approa h is not easily adapted to real-time simulations, i.e., simulations that appear to pro eed at the same speed as the modelledbehaviour would appear in the real world. In the DEVS formalism, the simulation steps fromevent to event, and there is no behaviour modelled or exe uted in between those events. As,su h, there is no modelling of the passing of time in between those events, and the simulationusually ompletes as qui kly as possible. Simulators built using the Dis rete Time SystemSpe i� ation formalism take some steps towards addressing this de� ien y.The DEVS model is arguably the most popular model amongst the simulation ommunityat the present time and several onferen es1 and workshops2, both a ademi and industrial,are dedi ated to solely advan ing the model. There are many popular DEVS simulators andtools that are pervasive omputing oriented su h as ns-2 (Fall 01) and Diasim(Jouve 09). Inaddition to that, there are several generi simulation tools and libraries, su h as C-Sim3,JavaSim4, and SimPy whi h are also available under open sour e li enses.The Dis rete Time System Spe i� ationIn the Dis rete Time System Spe i� ation (Zomaya 96), a simulation advan es at �xed time-steps, and at ea h time-step the orresponding modelled fun tionality or behaviour is invoked.1http://www.s s.org/ onfern /springsim/springsim09/ fp/springsim09.htm2http://www.isima.fr/~traore/SCSCDEVS/index.html3http://www. -sim.z u. z4http://javasim. odehaus.org 17

2.2. Model-Based Formalisms and MethodologiesAn implementation of this formalism typi ally ontains a lo k, some state information, a setof fun tions that model that state information, and a loop that invokes those fun tions atea h �xed time-step thus advan ing the simulation. In the Dis rete Time System Spe i� ation(DTSS) formalism, all events o ur �at the same logi al time� and are exe uted in the orderin whi h they were s heduled, whereas in the DEVS formalism the events are totally orderedglobally.Real-time simulations are a parti ular variation of the DTSS simulation formalism wherethe time steps are syn hronised with the time of an entity observing the simulation. Inthis ase, the simulation appears to run at what is alled the �wall-time�. This parti ularvariation has many bene�ts, most notably that it appears real from a timing perspe tive toan external observer and is thus suitable for approa hes where the observer plays a role inthe simulation. This is often the ase where there is a graphi al interfa e for the observerin, for example, a training simulator, or a game. This syn hronisation with the real worldintrodu es a timeliness requirement of ourse, whi h is that all events that must be observedexternally must be modelled within that time-step. This an introdu e an arti� ial bound onthe number of events that an be simulated given that a simulation is being exe uted on adevi e with a �xed number of omputing resour es.2.2.2 EmulationAnalysis of appli ation behaviour is an important part of the evaluation of a pervasive om-puting s enario and is addressed by numerous emulators (Girod 04a; Sobeih 05). An emulator an be de�ned as a system that implements the behaviour of an original system, i.e., a thirdsystem annot di�erentiate between the behaviour of the original and the emulated system.However due to system resour es and fa tors su h as the run-time interpretation of instru tionsets, there may be di�eren es in the speed at whi h the emulated appli ation runs, usuallyslower. Unlike a simulation whi h attempts to model the state of a system, an emulator's em-phasis is on realisti ally modelling the intera tion between the system and an external party,an appli ation in this ase. Emulators allow appli ations to be exe uted as if they were a tu-ally deployed within their native run-time environment, a requirement that simulators annot18

Chapter 2. Related Workmeet within the overall modelling and evaluation of pervasive omputing s enarios. This isimportant as it allows developers to bypass some of the problems in urred whilst bridgingthe gap between a simulated algorithm and a real appli ation. The a t of implementing andevaluating ode twi e (Nishikawa 06), on e for the simulation and on e for the a tual imple-mentation, is time onsuming and the translation from algorithm to appli ation an introdu edi�eren es in appli ation behaviour. Emulation addresses this problem by providing a simu-lation platform for the evaluation of appli ation ode but requires that the target platform isrealisti ally modelled.There are various approa hes to emulating omputer programs but these an be split intoeither hardware- or software-level emulation and the approa h that is hosen is usually de-pendent on the interfa es upon whi h the emulated program is built. For example, when theemulated appli ation is programmed so that it intera ts dire tly with the hardware, perhapsaddressing hardware su h as memory, then a hardware emulation te hnique su h as �binarytranslation� an be used. This involves the interpretation and translation of ma hine in-stru tions from their original form into instru tions that the host platform an interpret andexe ute. The hardware-level approa h is also used when the aspe t of the program underevaluation is dependent on the hardware being used. For example, within wireless sensornetworks, evaluating the performan e of a sensor mote an be dependent on the behaviour ofthe CPU or the radio.For programs that do not address hardware but perhaps are implemented at a higher logi- al layer, for example, appli ations that are built upon system alls, then software emulation ismore typi ally used. In this ase, a ompatibility layer must be des ribed that provides a map-ping from the original system alls to system alls on the host platform. For example, transla-tion software implementations su h as Wine (Win 07) and WABI (Sun Mi rosystems 96) bothemploy this te hnique, e.g., allowing Windows programs to run unmodi�ed on x86 UNIX andSolaris SPARC ma hines respe tively. The TOSSIM (Levis 03) and EMTOS (Girod 04b)emulators, both emulating TinyOS (Hill 00) appli ations, implement the traditional software-level emulation by inter epting and redire ting fun tion alls when the program is being ompiled. In this ase, TinyOS system alls are redire ted to a simulated TinyOS operating19

2.2. Model-Based Formalisms and Methodologiessystem that provides all of the required fun tionality of the a tual operating system but that an intera t with the emulator. Using this approa h, there is no need to inter ept fun tionsduring the exe ution of the program.It should be noted that some of the related works examined in this hapter use the termsimulation when the term emulation would stri tly be more a urate. TOSSIM, a TinyOSemulator is an example of su h an instan e, and these instan es are noted throughout thethesis when they o ur.2.2.3 Alternative Software-Based MethodologiesThere are several software-based approa hes that ould be adopted here in addressing these hallenges but these are inadequate in meeting the broad hallenges identi�ed in hapter 1.For example, one approa h would be to build a �super-simulator�, an all-in-one simulator of theentire pervasive omputing area. However, in order to build this type of simulator, it wouldrequire a level of domain expertise in all of the sub-domains in order to implement models ofall the required elements and would not ne essarily support areas of pervasive omputing thatare yet to emerge. Simulators that laim to be general pervasive omputing simulators su has UbiWise (John J. Barton 03) ommonly only model a subset of the omplete set of aspe tsof the domain. Any approa h that does not expressly in orporate �exibility and extensibilityinto its initial design and ar hite ture is not well positioned to be adapted to the hallengesof modelling overlapping and emerging new domains within pervasive omputing.A se ond alternative approa h is the modi� ation and integration of existing simulators.For example, resear hers in a ademia and the motor industry have long spe ulated on theimpa t that the emerging area of vehi ular ad-ho networks, might have on vehi ular appli- ations in luding driver safety and vehi le oordination (Salim 08). There are many existingvehi le and network simulators so an integration of one of ea h of these simulator types shouldbe able to leverage the independent domain expertise of both the vehi le simulation ommu-nity and the network simulation ommunity, and ould address the modelling needs of thevehi ular ad-ho networking (VANET) ommunity. Depending on the implementation andunderlying formalism of the respe tive simulators, this approa h requires an understanding20

Chapter 2. Related Workof ommon properties su h as the simulated time and the lo ation of ommon obje ts. Ina simulated VANET s enario (Mangharam 06), the ommon obje ts, the vehi les and theirnetwork interfa es have the same lo ation whi h must be syn hronised within the respe tivevehi le and network simulators.Clearly this approa h an address the hallenge of modelling overlapping domains, butuntil standardised API's are agreed upon for all simulators, this an only be a hieved on abespoke basis. At present there are no agreed interfa es, and few simulators that an inter-operate. The integration of two or more simulators does not address the hallenge of beingable to model new and emerging areas of pervasive omputing, and this approa h is only asextensible as its onstituent simulators are. Finally, an integrated approa h ne essitates thetester to have the required expertise in ea h of the simulators that are to be integrated.In on lusion, building a super-simulator is not a viable approa h as it is inherently on-strained with respe t to future extensibility whilst e�orts to integrate independently reatedsimulators are limited by a la k of standardisation and by the �exibility and extensibility ofthe onstituent simulators. So what are the alternatives? One approa h is to in orporate�exibility, extensibility and re-usability from the start and make these prin iples ore featuresof the adopted approa h rather than add-ons at the end.2.3 The Review CriteriaThe simulators in this hapter are examined using eight review riteria, of whi h abridgedworking de�nitions are provided in table 2.1 and are subsequently expanded. These rite-ria an be ategorised as follows. Review riteria one to three spe i� ally map to the ore hallenges identi�ed in hapter 1: namely �exible heterogeneity, extensibility and reusability.Review riteria four through eight address spe i� features that are ommon to pervasive omputing simulators that merit examination and are in luded in order to draw out spe i� noteworthy features. These riteria an help to identify features of simulators that mightnot ne essarily address the identi�ed ore hallenges but may in�uen e its ar hite ture andimplementation. As will be seen in the following de�nitions, there is some small overlap insome of the review riteria and this is highlighted when it o urs.21

2.3. The Review Criteria

# Review Criteria De�nitionRC1 FlexibleHeterogeneity Examines whether the simulator supports the �exiblemodelling of multiple instan es of pervasive omputing's ommon omponents.RC2 Extensibility Examines whether the simulator is extensible and an bemodi�ed with ease to support di�erent pervasive omputingdomains.RC3 Ar hite ture(in l.Reusability) An overview of the ar hite ture from a software engineeringperspe tive. Issues overed here may overlap with otherevaluated riteria.RC4 Appli ationemulation Examines whether the simulator supports the emulation ofappli ations that exist within the modelled appli ationdomain.RC5 Intera tionbetweenemulated andsimulated omponents Examines whether the intera tion between instantiations ofabstra tions and emulated appli ations is supported.RC6 Networksimulation Examines the support the simulator provides for networksimulation of both wired and wireless networks.RC7 Experimentalsupport Examines the support the simulator provides for evaluatingsimulations. This relates also to usability.RC8 ExternalIntera tion Examines whether the simulator is self- ontained, or whetherit is possible to intera t with external simulators, servi es orpro esses.Table 2.1: Simulator Review Criteria22

Chapter 2. Related WorkFlexible HeterogeneityThis riteria examines whether the simulator supports the modelling of heterogeneous fea-tures of pervasive omputing appli ations. These heterogeneous features may in lude a vari-ety of sensors and other hardware devi es, multiple appli ations possibly running on di�erentplatforms, users, the physi al environment, and other features, both mobile and stati . Addi-tionally, the simulators are reviewed to determine their support for the �exible intera tion ofthese heterogeneous features, a feature that is required if a simulator is to support emergentand ross-over pervasive omputer appli ation domains.ExtensibilityThis review riteria examines whether the simulator is extensible by design. Systems areexamined to determine what support exists for the modelling of new emerging appli ationareas of pervasive omputing not yet identi�ed, where these appli ation areas an ompriseof both new hardware and software elements.Ar hite ture in luding ReusabilityThe third review examines the system's ar hite ture from a software engineering perspe tive.Issues overed here may overlap with other evaluated riteria. The reusability aspe ts of thear hite ture are also examined in ases where the ar hite ture an be used to model severalpervasive omputing domains.Appli ation EmulationThis review riteria examines what support the system provides for the emulation of appli a-tions that would typi ally exist within the modelled appli ation domain.Intera tion between Simulated and Emulated ComponentsThis review riteria examines what support is provided for modelling intera tion between anysimulated elements and any emulated appli ations within the one appli ation domain. Thereis a small overlap here with the review riteria on erning �exible heterogeneity.23

2.3. The Review CriteriaNetwork SimulationThis review riteria examines what support the system provides for the network simulation ofany networked elements within the modelled domain. This may in lude both wired and wire-less networks. This review riteria also examines what interfa es are available to algorithmsand any emulated appli ations within the simulator.Experimental supportThis review riteria examines what support the system provides for the running, exe ution andsubsequent evaluation of any modelled experiments. This ould in lude for example s riptingsupport, debugging features, or the ability to program user behaviour.External Intera tionThis review riteria examines the systems ability to intera t with external simulators, servi esor pro esses. Often systems o�er an API to onne t external servi es for debugging or systemextension. Any API's that are provided to support this fun tionality are examined.Omitted CriteriaThe simulators under review ould also have evaluated against riteria su h as performan e,ease of use, and a ura y, however, the number of simulators attempting to address the generi modelling of pervasive omputing is so few, that to ben hmark these against ea h other wouldnot be to ompare like with like. The performan e or �ease of use� of StarBED, a distributedplatform for simulation an not be ompared in a meaningful way against UbiWise, a simulatorbased upon a PC-based games engine.The �eld of pervasive omputing simulators is not as strongly developed as that of networksimulation for example, where there are maybe twenty a epted simulators that an all berun on a lo al ma hine. In mature simulation �elds su h as these, the resear h questions havemoved on from whether or not it is possible to model some aspe t of network behaviour tohow a urate and how qui k that model is. 24

Chapter 2. Related WorkFinally, the a ura y and �delity of any simulator is important, and this is aptured withinRC1 for simulated hardware devi es, and in RC4 for emulated appli ations, and is a themewhi h is arried throughout the frameworks implementation and its evaluation.2.4 An Overview of Pervasive Computing SimulatorsSe tion 1.1 in hapter 1 introdu ed the many overlapping areas of pervasive omputing, allof whi h involve di�erent te hnologies and have di�erent modelling requirements yet ontainsome ommonalities. For example, smart spa es (Tapia 04) are often rea tive appli ations,driven by sensors su h as door onta t swit hes embedded within the spa e, whi h an thenadapt some aspe t of the spa e to a user's requirements. An environment-monitoring wirelesssensor network (Ji 04) ould omprise of sensors, perhaps monitoring pre ipitation, atta hedto wireless nodes that propagate that sensor information to other nodes through an ad-ho network. ITS systems (Klein 01) typi ally use embedded sensors su h as indu tive loops in theroad network to improve the throughput of the vehi les in the system. All of these domains,and others onsidered, form the broad overlapping spa e that is pervasive omputing.This review of related work interse ts several dis iplines, as shown in �gure 2.1 , someof whi h are subsets of pervasive omputing and some that are independent resear h areasthat have some ommonalities with pervasive omputing. There are many interpretations ofpervasive omputing, and o asionally simulators that are targeted at pervasive omputinga tually only address a subset of the area. Compared with an area of resear h su h as wirelesssensor networking, there are surprisingly few well-known simulators targeted spe i� ally atthe overall pervasive omputing area. This is mainly due to its broad de�nition, and that fewresear h groups address pervasive omputing as a omplete spa e, instead preferring to fo uson spe i� pervasive appli ation areas, su h as ontext-aware or lo ation-aware omputing.Simulators for pervasive omputing an be broadly ategorised into two groups. The �rstgroup in ludes simulators su h as UbiWise (John J. Barton 03), Tatus (O'Neill 05), and theLan aster simulator (Morla 04), whi h are pervasive omputing simulators not addressing anyparti ular sub-domain. UbiWise and Tatus support reating omplex 3-D simulations of apervasive omputing environment su h as a building or a smart-spa e, but not the omponents25

2.4. An Overview of Pervasive Computing Simulators

Figure 2.1: Overlapping Domains of Pervasive Computing Simulators26

Chapter 2. Related Worksu h as wireless sensors that may exist within those environments. The se ond group of simula-tors are those that address spe ialised subsets of the pervasive omputing �eld. For example,Siafu (Martin 06a) is a simulator for ontext-aware omputing appli ations. Additionally,there are many instan es of simulators su h as network simulators (Sundresh 04; Sobeih 05)and agent simulators (North 06; Narendra 05) being modi�ed and used to model subsets ofpervasive omputing.In fa t, of the many simulators identi�ed in �gure 2.1, only those inside the red oval laimto spe i� ally address pervasive omputing, in the broad multi-dis iplinary sense that thisthesis onsiders. These seven are perhaps the most important of the simulators onsidered, asthey attempt to address the hallenges that have been identi�ed for a �exible and extensiblesimulator for pervasive omputing. An additional ten simulators, those inside the blue oval,and outside the red oval, either address subsets of pervasive omputing, or are in the overlapof appli ation domains su h as intelligent transportation systems with pervasive omputing.To date, there has only been one simulator developed using a framework for the pervasive omputing domain. Shibuya applied a framework approa h (Shibuya 04) to modelling thespatial aspe ts of human behaviour in a pervasive omputing environment. The fo us of thiswork was on human intera tion within these environments, rather than the environmentsthemselves, however, and the physi al aspe ts of the devi es, and appli ations that might usethose devi es within a pervasive omputing environment were negle ted.2.5 The Key Simulators�..This thesis is on erned with methodologies that are both suitable for the evaluation of awide range of diverse pervasive omputing s enarios and that an be extended to evaluate news enarios that may emerge in the future...�. As seen in the previous se tion, there have beennumerous works addressing a subset of the requirements of pervasive omputing simulation,but few taking a more omplete approa h to modelling the domain as a whole. Of thesesimulators, seven are hosen that o�er the most interesting and note-worthy approa hes, andthat are losest in spirit and exe ution to a framework-based approa h to building �exibleand extensible simulators 27

2.5. The Key SimulatorsThese seven simulators were hosen based on the following riteria. Importantly, theyattempt to address almost all aspe ts of the identi�ed review riteria, but with varying degreesof su ess.Se ondly, the typi al user of the PiCSE framework is a resear her within a small to mediumsized resear h group with limited a ess to hardware resour es su h as a luster or even a loud-infrastru ture. Therefore, this review is on erned with lightweight simulators thatare suitable for ondu ting experiments in a ost-e�e tive manner. By lightweight it is meantthat the simulator an exe ute on a single o�-the-shelf desktop omputer that does not requireadditional hardware to a hieve a normal level of performan e. As a by-produ t this avoidssome of the downfalls of using distributed infrastru tures whi h in lude the high osts, andhaving to negotiate and s hedule shared a ess to that infrastru ture.Finally, this review fo uses on simulators that are widely available and are being a tivelyused within the pervasive omputing ommunity.2.5.1 UbiWiseUbiwise (John J. Barton 03) was one of the original simulators developed for pervasive om-puting, and was motivated by the need for rapid and heap prototyping of pervasive devi esand servi es. The simulator provides�a three-dimensional world, built on the Quake III Arena graphi s engine, andserves to simulate a �rst person view of the physi al environment of a user"(John J. Barton 03)A simulated deployment enables the testing of pervasive servi es, implementations of proto olsand integration of devi es. Essentially, UbiWise is a human-in-the-loop simulator, whi hallows users to intera t virtually with simulated devi es in a 3-D spa e. The simulator aimsto mix simulated and prototype devi es and servi es where possible.28

Chapter 2. Related WorkRC1: Flexible HeterogeneityUbiWise's environmental modelling is provided by using proprietary Quake III formats, andeditors su h as GtkRadiant are available to develop intera tive 3-D models. These editorsprovide a graphi al interfa e for modelling the environment allowing a developer to positiondevi es, walls, and so forth. The most basi obje t within UbiWise are 'devi es' and these arespe i�ed through an XML devi e des ription �le and asso iated Java lass �les. The graphi alrepresentation of the devi e is also en oded in the �le, by spe ifying the shape of the obje tand asso iated JPEG images for various aspe ts of the devi e.Supporting new sensors, �whether handheld or environmental� is one of the stated aims ofthe UbiWise platform and lo ation trigger-based sensors, devi e inputs as well as networkedsensors are all des ribed theoreti ally. User models are an intrinsi part of any game baseddevelopment platform and are available.RC2: ExtensibilityThe solution proposed is extensible in that new devi es, sensors and java based appli ations an be integrated into platform, however the platform itself is a devi e- entri and whilstreadily suited to smart-spa e type environments, it would be di� ult and time- onsuming toextend the platform to model other types of environments.RC3: Ar hite tureUbiWise uses a lient/server ar hite ture whi h is built upon the Quake III game engine.A single UbiSim server hosts ea h simulation and maintains a 3-D representation of theenvironment. A Wise5 lient, representing a user and a hardware devi e then onne ts tothe UbiSim server. The lient maintains a onsistent view of the environment by ex hangingphysi al environment messages with the server, whi h are then propagated to other users.The devi e view and the devi e's intera tion with the environment are similarly handled bypassing devi e intera tion messages. The ombined system of the UbiSim server and Wise lients is known as UbiWise.5Wireless Infrastru ture Simulation Environment 29

2.5. The Key SimulatorsRC4: Appli ation EmulationWise supports the exe ution of appli ation ode in the form of Java . lass �les and sin e thedevelopers of the system des ribe simulating user inputs su h as mouse events, then it appearsthat at least these devi e oriented appli ations are at least emulated.RC5: Intera tion of Emulated and Simulated ComponentsAppli ations within UbiWise are intended to intera t with simulated devi es and these devi es an onsume events that are driven by events within the simulated environment, su h aslo ation-based sensors. There is no eviden e of intera tion of emulated devi es with a tuatorsalthough this is most likely to be a hievable through hard- oding.RC6: Network SimulationUbiWise supports the simulation of hara teristi s of network behaviour su h as variablelaten y and intermittent onne tions but provide no details of how this simulation is a hievedso this is most likely to be a hieved with their own proprietary simulator.Additionally, network intera tion within this simulator an be a hieved with an a tual livenetwork interfa e. As this is a human-in-the-loop simulator, this is possible as a simulationruns at the same speed as in the real world.RC7: Experimental SupportWise is a resear h-driven tool for rapid prototyping and provides ex ellent support for therunning of experiments. Debugging, tra ing of appli ation behaviour as well as user- entri ontrols su h as re ord and playba k make it easy to evaluate appli ations with the Wisesystem. Beyond evaluating appli ations, there are no des ribed me hanisms for the samelevel of tra ing although a re ord and playba k fun tion is likely to be provided within thegraphi al part of the platform. 30

Chapter 2. Related WorkRC8: External Intera tionPart of the Wise devi e spe i� ation, modelled in XML, allows the appli ation's . lass �lesto build upon proto ols ode su h as HTTP, enabling the integration with external servi esoutside the ontrol of the simulator. As UbiWise runs in wall- lo k time6, proto ol issuessu h as laten ies in the network do not have to be simulated but are introdu ed naturally asthe simulated devi e ex hanges HTTP messages with external HTTP servi es.SummaryIn UbiWise, the developers orre tly laim to have a hieved a balan e between ��delity�and �simpli ity�. Fidelity in this ase meaning �delity to the user intera tion experien e,and to a realisti environment. In addition to this, UbiWise o�ers realisti modelling ofappli ation-level devi es and an intera tive 3-D model of the environment in whi h they exist.Enabling simulated devi es to intera t with external servi es lends even more redibility tothis laim, however overall, UbiWise is de� ient in several aspe ts. It does not provide a�exible ar hite ture for simulating anything other than hardware devi es, and their embeddedfun tionality, and the environment in whi h those devi es exist. Hardware devi es, su h assensors and a tuators, whi h are ommon to pervasive omputing s enarios, an be modelledbut no framework or generi abstra tions are provided to support the development of thesemodels. They must be built from s rat h using the Quake native Software Development Kit(SDK).Furthermore, no metri s are provided regarding the performan e or the a ura y of thesimulator. As UbiWise only attempts to prototype appli ation devi es and their environment,any analysis regarding a ura y and performan e are valid only in relation to the modellingof the image representation of the devi es and the environment. In this respe t, UbiWise isarguably e�e tive. The modelling of devi es is both a urate and realisti from the perspe -tives of both the look-and-feel and the fun tionality of those devi es. However, this modelling omes at the expense of the time and e�ort required to develop these models. The developers6Wall- lo k time is when one se ond of simulated time takes one se ond of a tual time to exe ute. This isrequired as UbiWise is a human-in-the-loop simulator.31

2.5. The Key Simulatorsthemselves a knowledge the large e�ort required to build the graphi al models required forea h simulation.Finally, UbiWise is not suitable as an experimental platform. Support for running sets ofexperiments does not seem to be built into the design and an API exposing data of interestfor experiments has not been provided. Furthermore, the human-in-the-loop model employeddoes not lend itself to evaluating s enarios or running large sets of repeatable experiments.Introdu ing a random element su h as human behaviour makes it di� ult to repli ate ex-periments thus rendering the platform unsuitable for experiments other than those in whi hhuman intera tion is a requirement. This is, however, one of the main selling-points of Ubi-Wise. The lengthy development period is an additional and potentially time onsuming fa torin running large sets of experiments with varying parameters.UbiWise is primarily a graphi al simulator however, and not an experimental tool that iseasily extended to new s enarios. As su h, it is not surprising that it is de� ient in meetingmany of the requirements identi�ed for this thesis. It is, however, one of the original and fewsimulators targeted spe i� ally at this domain, and therefore it is in luded.2.5.2 TatusTatus (O'Neill 05) adopts a similar approa h to UbiWise to modelling pervasive omputingsystems. A well-known game engine, Half-Life, is adopted to simulate immersive pervasive omputing environments in whi h users and appli ations an intera t with virtual worlds.RC1: Flexible HeterogeneityUsing Half-Life's graphi al editors, it is possible to reate omplex 3-D implementations ofphysi al environments, su h as buildings, rooms and open spa es. A proprietary format,Binary Spa e Partitioning (BSP), is used to apture the topology, shape, and even texture ofthe environment as a binary tree whi h ensures that the environment an be both mapped andexplored e� iently. In addition to this, users and their a tions an be a urately portrayed byusing either a) a real human to drive the simulation or b) programming a �bot�, or Non PlayerChara ter (NPC), to repli ate these a tions. Sensors and a tuators are simulated by means32

Chapter 2. Related Workof an API allowing appli ations to query and to a t upon the simulated environment. Thedevelopers note that only simple a tuation is possible due to method parameter restri tions:only a single unparameterised use() method is provided.RC2: ExtensibilitySimilar to UbiWise, the Tatus platform provides extensibility through the games engine uponwhi h it is built. The Half-Life SDK allows the reation of new physi al spa es and for sensorsthat an measure data within that environment. Although the game's SDK does provide ameans of extensibility, the developers of Tatus note the di� ulty and steep learning urvein using that, highlighting that they do not feel that the SDK is an appropriate means ofproviding extensibility for resour e- onstrained resear hers.RC3: Ar hite tureThe Tatus ar hite ture is omposed of three main omponents. The simulator, a modi�edgame engine is the main omponent, whi h takes a map de�nition �le and an XML �lede�ning the message format for the sensing and a tuation API. A Java proxy ommuni atesa network with the games engine, and provides an API for sending and re eiving messages tothe simulator. Any appli ations that are �under test� an use the Java API to intera t withthe simulator.RC4: Appli ation EmulationThe external proxy provided by the Tatus ar hite ture does not provide an emulated interfa efor appli ations that are onne ting to the simulator. These appli ations must be built uponthe proxy's API.RC5: Intera tion of Emulated and Simulated ComponentsThere are no emulated software omponents within the Tatus ar hite ture, and hen e thereis no intera tion between emulated and simulated omponents. Un-emulated appli ations33

2.5. The Key Simulatorsthat are onne ted to the simulator via the proxy may intera t via the sense and query APIsprovided.RC6: Network SimulationAn ar hite ture has been proposed for the integration of a third party network simulationtool, TOSSIM, into the Tatus simulator for the integrated simulation of wireless networkings enarios in pervasive omputing environments. The proposed ar hite ture reating a newinterfa e between the network simulator and a �Real life Simulator�, itself a proxy that aninterfa e with the Tatus Simulator. The lo ation of wireless nodes, and their mobility patternswould be spe i�ed by the Real Life Simulator.RC7: Experimental SupportThe simulator also supports the running of experiments through the in lusion of three features,that exploit the underlying Half-Life infrastru ture. Multi-player games allow experiments tobe run with up to eight appli ations and eight users, a onstraint imposed by the underlyinggame engine. As previously mentioned, Tatus allows reprodu ible experiments to also beimplemented by removing the human element and repla ing it with an NPC. In addition tothis, experiments an be saved, re-run and logged, using the Half-Life game API, allowingo�-line analysis and evaluation to be performed.RC8: External Intera tionTatus employs an external proxy that enables the integration of appli ations, termed SoftwareUnder Test, into the simulated world. The proxy, whi h is not ne essarily running on the samema hine as the simulator, provides an API allowing appli ations to both query and updatethe world. Events of interest are pushed to a database in the proxy, whereas the proxy's queryAPI allows appli ations to �extra t� real information from that database. Similarly, a tuationevents are performed using an a tuation API, that pushes events dire tly into the simulatedenvironment. XML messages are used to ex hange data between the simulator and the proxywhi h then pushes the data to the appli ation, and this ex hange is also supported remotely34

Chapter 2. Related Worka ross a network.SummaryThe aim of Tatus is to support the in orporation of real-user behaviour into a simulation.In this sense, similar to UbiWise, it an be argued that Tatus allows the a urate modellingof both users and physi al environments. These are however only two aspe ts of pervasive omputing. Both sensors and a tuators are abstra ted to an API, provided by the proxy,mediating intera tion with Tatus's model of the environment. Furthermore, the simulator'sability to be extended to a tually in lude di�erent ategories of these devi es is supportedonly by the Half-Life SDK. There are no generi models of devi es, although developers anutilise Half-Life's support for event triggers to generate events when ertain riteria, su h asproximity, are met.The proxy-style support for external appli ations works quite su essfully, and allows manyappli ations to intera t with the simulator. Ultimately however, these appli ations have tobe built upon the proxy's API, and there is no support for emulating the inputs and outputsof the data streams between the proxy and the appli ation.Finally, there is no support for integrating a network simulator into this work, although ithas been identi�ed as future work and a potential ar hite ture has been proposed. However,sin e Tatus runs with a human-in-the-loop, appli ations an intera t outside the ontrol ofthe simulator with networked servi es if required.2.5.3 Lan aster Simulation EnvironmentThe Lan aster hybrid test and simulation environment (LSE) (Morla 04) is an environmentthat supports the integration of third party simulators to evaluate lo ation-based appli ations.Support is provided for external appli ations, using a Web Servi es interfa e, allowing themto intera t with simulated environments. The ontrol and intera tion of both, simulators andappli ations, are mediated and ontrolled by a Systems Manager that is also responsible foroverall experimental ontrol. 35

2.5. The Key SimulatorsRC1: Flexible HeterogeneityThe LSE simulator is built using an open approa h allowing the onne tion of third-partysimulators that an simulate di�erent aspe ts of pervasive omputing environments su h asmobility or ontext simulators. No des ription is provided of how these simulators mightbe extended in a manner de�ned by the LSE ar hite ture and any integration may only bea hievable if the third party simulators are designed to provide this fun tionality.RC2: ExtensibilityLSE's approa h of supporting the integration and mediation of third-party simulators is in-herently extensible. In separating other features su h as the experimental support and theappli ation daemons, the simulator has provided a framework for potentially targeting newand emerging pervasive omputing domains.RC3: Ar hite tureLSE is built upon a distributed ar hite ture whi h mediates the ontrol and exe ution of ap-pli ations and third party simulators. A system manager ontrols the exe ution of simulatorsand appli ations using a Web Servi es interfa e allowing these to be exe uted on separatema hines. Low-level kernel a ess is required for the ma hine on whi h appli ations are be-ing tested. The System Manager is also responsible for gathering experimental results andprovides data to a graphi al user interfa e.RC4: Appli ation EmulationSupporting a tual appli ation ode is one of the requirements of the LSE test environment,and the simulator distinguishes between two aspe ts of the emulation required for those ap-pli ations so that the minimum number of hanges to the appli ation ode are required.The �rst aspe t is that the emulation omponent must support a realisti network inter-fa e. Appli ations should be able to send and re eive messages a ross both 802.11 wirelessLan and GPRS. The emulation omponent should additionally provide interfa es for36

Chapter 2. Related Workre eiving any lo ation information and any kind of ontext information that mightbe relevant for the appli ation behaviour.RC5: Intera tion of Emulated and Simulated ComponentsThe LSE ar hite ture enables the integration of the emulated appli ations with third-partyintegrated simulators. By providing a � ontext� api for example, an emulated appli ation anintera t with a ontext simulator over a Web Servi es interfa e.RC6: Network SimulationLSE integrates a popular network simulator, ns-2 (Fall 01) into their test environment, allow-ing the simulator to model the wireless ommuni ation between appli ations. This is donewithout modi� ation of the appli ation ode. Using this software emulation te hnique, pa k-ets generated by the appli ations are inter epted in a modi�ed kernel and redire ted throughthe ns-2 simulator. Importantly, this approa h is transparent to the appli ations themselves.RC7: Experimental SupportLSE provides good support for experimental ontrol. Appli ation daemons are providedenabling instantiations and monitoring of individual appli ations. Appli ation outputs anderror streams are re orded by a system manager for logging whi h also an ontrol and monitorthird-party simulators su h as the network and lo ation simulators.RC8: External Intera tionLSE exe utes in wall- lo k time and intera tion with external servi es is both possible andtransparent in simulated s enarios. This is a hieved using the web servi es based Global GridForum7 standards to �disseminate the sensor data to other Grid appli ations�, that themselves ontribute to the overall simulated s enario.7http://www.globus.org 37

2.5. The Key SimulatorsSummaryNo abstra tions are provided for the lassi al pervasive omputing omponents su h as sensorsor other hardware devi es. However as noted, LSE's �exibility or suitability as a pervasive omputing simulator is a hieved through the use of a Web Servi es interfa e whi h allowsthird-party simulators to be atta hed to the overall system. As will be shown later in this hapter, there are simulators that address individual aspe ts of the overall pervasive omput-ing spa e, and potentially these ould be integrated into the LSE simulation environment.Using Web Servi es to integrate third party simulators o�ers potential extensibility, however,some on erns arise. The integration of multiple simulators a knowledges and a ommodatesthe expertise that ea h brings. These simulators an provide omplimentary modelling of sep-arate aspe ts of pervasive omputing s enarios, yet there is no on rete ar hite ture withinLSE, to support the ontrolled intera tion of multiple simulators. For example, there is nospe i� ation of a ommon user model, that might allow the user model from one simulator,to intera t with a sensor model from a se ond simulator.2.5.4 UbiREALUbiREAL (Nishikawa 06) is a smart-spa e simulator, that extends the traditional �modi�edgame simulator� employed by UbiWise and Tatus to o�er a more omplete simulation environ-ment. In addition to graphi al 3-D environment models, the UbiREAL simulator allows usersto spe ify physi al quantity simulators and also to integrate simulated and real appli ationsin the same virtual smart-spa e. The basi UbiREAL ar hite ture omprises four omponentsthat interlink to a hieve these goals. These omponents are: physi al quantity simulators, anetwork simulator, a visualiser and GUI, and appli ation programs.RC1: Flexible HeterogeneityThe UbiREAL simulator supports the integration of physi al quantity simulators. Thesesimulate�invisible physi al quantities su h as temperature, humidity, ele tri ity and radio38

Chapter 2. Related Workas well as visible (audible) quantities su h as a ousti volume and illumination.�(Nishikawa 06)A developer must spe ify a physi al quantity in terms of an appropriate physi s formula, forexample, spe ifying the rate at whi h heat dissipates given temperature di�eren es in di�erentareas. This model is supported by a publish-subs ribe event me hanism, whi h enables theintera tion between sensors and the physi al quantity being sensed. Very simply, as thephysi al quantity hanges over time, sensors, whi h are implemented as software drivers, arenoti�ed of these hanges, and a sensing event an o ur.RC2: ExtensibilityThe UbiREAL stru ture has been designed as a losed and omplete system. Integrationof third-party simulators and emulation libraries is not onsidered, however a framework forthe simulation of physi al quantities does provide a means for extensibility with respe t toenvironmental, sensing and potentially a tuating models. A methodology for integration ofemulated appli ations has been proposed for two emulation API's and on eptually, it isfeasible to onsider how this approa h may be extended for other appli ation libraries thatthe UbiREAL simulator may integrate in future work.RC3: Ar hite tureUbiREAL is a modular omponent-based ar hite ture omprised of four intera ting modules.At the entre of the ar hite ture is a smart-spa e designer and visualiser whi h de�nes thephysi al environment, the omponents within and a means for exe uting the simulation. Thismodule takes provides inputs to the network simulator, and also provides a physi al envi-ronment in whi h emulated appli ations an be exe uted. Finally, the entral module alsoprovides an environment and informs the �nal module, whi h is the simulator for physi alquantities. 39

2.5. The Key SimulatorsRC4: Appli ation EmulationUbiREAL allows the emulation of appli ations built upon ommon libraries. The emulationis a hieved after by linking with libraries that interfa e with UbiREAL, instead of the originallibraries that the appli ations were built upon. This linking is performed between the om-pilation and exe ution of the program. Thus, any appli ation invo ations of that library areredire ted to the simulator, a hieving emulation. The BSD So ket and java.net libraries, areboth supported, and inter epted alls to these libraries are redire ted to UbiREAL's bespokenetwork simulator. Emulation of appli ations built on software devi e drivers is a hieved in asimilar fashion. Calls to the modi�ed devi e drivers retrieve values from the physi al quantitysimulators, and return them to the appli ation.RC5: Intera tion of Emulated and Simulated ComponentsNo dire t intera tions are de�ned between emulated appli ations and simulated physi al quan-tities. Dire t readings from the physi al quantities may be obtained through �devi e drivers�but this is not provided through an emulated API.RC6: Network SimulationUbiREAL provides its own internal network simulator for the simulation of wireless ommu-ni ation. It supports models in luding the free spa e model, the line-of-sight model and theray-tra ing model, and their model takes into onsideration variables su h as the transmis-sion range, re eived signal power and wavelength. Radio propagation is al ulated before thesimulation is exe uted, and in simulations involving mobile nodes, the radio propagation is al ulated periodi ally. Periodi al ulations may result in some loss of simulation a ura ywith respe t to the wireless model.RC7: Experimental SupportFinally, UbiREAL o�ers a fa ility for the systemati testing of smart-spa e appli ations. Ituses a formal methods approa h to modelling the domain, in terms of sets of smart-spa es U,rooms R, and devi es D. The approa h also models physi al quantities as attributes in ea h40

Chapter 2. Related Workroom. A servi e spe i� ation is de�ned as a set of rules AP, and a set of propositions, P. Usingthis formal approa h, an experiment an be des ribed as a servi e spe i� ation Spe =(AP,P),that spe i�es a range of values that attributes an vary over, a ross many rooms, R, omprisinga smart spa e, U. As these attributes hange during the run of the experiment, events aregenerated and pushed to appli ations, thus exer ising them.RC8: External Intera tionUsing a similar approa h to LSE, a redire tion of alls is performed at the networking layerwithin the operating system, to enable the integration of real appli ations with virtual appli- ations. A modi�ed NAT8 pro ess on the host omputer of the real appli ation examines allnetwork pa kets, and pa kets destined for emulated appli ations are modi�ed and redire tedto the address of the host running the simulator. This o urs at the TCP level with theresult that no modi� ations are required to enable external appli ations to intera t with realappli ations.SummaryThe UbiREAL simulator integrates many novel and pra ti al features into its ar hite ture.Parti ularly, the integration of real and virtual appli ations is an enhan ement of LSE's simi-lar approa h to integrating external appli ations. Similarly, it extends the graphi al approa hadopted by UbiWise and Tatus, to in lude a model for simulating physi al quantities, provid-ing a more omplete model of an environment that is �measurable� by sensors.Although the UbiREAL simulator runs in wall- lo k time, an approa h that an lead tolengthy experimental times, the in lusion of a formal approa h to modelling the experimentsis a signi� ant advan ement in the state of the art. Its integration into the simulator makesup partially for the inherent short omings of using a graphi al game-based approa h to runexperiments.However, the UbiREAL simulator is onstrained to smart spa es and modelling environ-ments in terms of rooms, and spa es only. It is di� ult to see how this approa h ould be8Network Address Translation 41

2.5. The Key Simulatorsextended or modi�ed to in lude large-s ale s enarios, or s enarios where the devi es or im-portant omponents are anything other than appli ations or sensors. The formal approa h tomodelling is onstrained to smart-spa e s enarios, and experiments run within those s enar-ios, although potentially the modelling language used ould be extended to support a broaderrange of s enarios.2.5.5 SitComSitCom (Fleury 07) is an open and extensible framework developed at IBM that assists in�developing ontext-aware servi es, editing and deploying ontext situation mod-els, and simulating per eptual omponents.� (Fleury 07)SitCom whi h stands for Situation Composer, provides abstra tions of the main omponentsin ontext-aware omputing servi es, and provides a two-tiered ar hite ture that supportsthe reation of models of these s enarios. SitCom itself provides the underlying framework,providing fun tionality su h as modelling the environment, in both 2-D and 3-D, and also anarray of managers for managing the inputs and outputs of a simulation instan e. SitMod is aninstantiation of the framework abstra tions that forms a situational model, e.g. an instan eof a parti ular simulation or experiment.RC1: Flexible HeterogeneityThe working de�nition of ontext that SitCom uses is that of Dey in the development of theContext Toolkit (Dey 00). Here ontext is de�ned as�any information that an be utilised by an appli ation, in luding sensed andsynthesised knowledge on users, the obje ts of the s ene, situations, the appli ationitself, environment, and world.� (Dey 00)SitCom provides a set of abstra tions based around this de�nition that allow ontext-aware omputing s enarios to be modelled. These abstra tions are partitioned into �ve ategories,ea h addressing a general lass of abstra tions. Entities are de�ned as features that an42

Chapter 2. Related Workbe mapped one-to-one to real world obje ts. Entities have a set of attributes, that an beupdated during a simulation, and an be the inputs for Sensors. Sensors onsume attributesof parti ular entities, and produ e raw sensor data. Per eptual omponents onsume datastreams from sensors and provide the mapping from sensor data to higher level ontextualdata. Contextual data, modelled as fa ts, is onsumed by instantiations of Situation Modellingabstra tions, and provide information about situations, whi h onsists of a set of states andtheir asso iated transitions. Finally, a Servi es abstra tion is provided allowing ontext-awareservi es to be developed using appli ation logi , and user interfa e design.RC2: ExtensibilityThe SitCom simulator does not onsider extensibility as a key requirement. It is targetedspe i� ally at the ontext-aware omputing sub-domain of pervasive omputing and its ar hi-te ture, des ribed in the following se tion, re�e ts that. The simulator does not support theintegration of third-party simulators that might assist in a hieving that extensibility.RC3: Ar hite tureSitCom is des ribed as a four-tier ar hite ture. At the lowest level, sensors provide raw sensordata, whi h is onsumed by per eptual omponents whi h are at the se ond level. Per eptual omponents add a level of ontextual or semanti meaning to that raw sensor data. Situationalmodelling is the third tier and here information from the per eptual omponents is used in anappli ation spe i� manner. For example, an appli ation here ould interpret a range of sensorinputs in luding presen e and a tivity to dete t whether a room is in use or not. The toptier of omponents are servi e-oriented omponents whi h a t upon individual appli ationssu h as the presen e appli ation. The SitCom simulator is implemented as an extensible Javatoolkit that provides fun tionality that support the development of simulations at all fourtiers of its ar hite ture. 43

2.5. The Key SimulatorsRC4: Appli ation EmulationAppli ation emulation is not one of the requirements for the SitCom ar hite ture and appli- ations are omposed as part of the Java runtime within the simulation.RC5: Intera tion of Emulated and Simulated ComponentsAs there is no emulated appli ations within the SitCom simulator, no intera tion betweenthose appli ations and simulated omponents is noted. However, appli ation lasses thatare deployed an onsume both simulated and real ontextual information from per eptual omponents.RC6: Network SimulationNetwork simulation is not in orporated as a module within the SitCom ar hite ture. TheSitCom framework targets ontext-driven appli ation and onsiders standalone appli ationsthat onsume raw sensor and ontextual information as their inputs. It an be inferred thatsome network omponent may exist within appli ations deployed at the servi es tier, howeverthese are likely to intera t a ross real networks and not through ontrolled simulated networks.RC7: Experimental SupportThe SitCom simulator allows experiments to be spe i�ed through its GUI, allowing prede�nedsituations (experiments) to be loaded. �Syntheti � or �re orded data� an then be fed into thesimulation. In parti ular, SitCom supports the loading of semi-simulated, and real data intoa simulation, allowing the higher-level abstra tions su h as the Per eptual Components andthe Situation Modelling abstra tions to exploit these real data sour es.RC8: External Intera tionA remote API is provided by the SitCom simulator allowing standalone modules to intera twith the simulator. These remote modules are part of the situational modelling tier of SitCom omponents and the API therefore provides methods from querying simulated per eptual omponents. 44

Chapter 2. Related WorkSummarySitCom provides a set of abstra tions that model a range of aspe ts of ontext-aware omput-ing. What is unusual and relatively novel about these abstra tions is that they are alignedin the verti al domain, allowing the modelling of all parts of a ontext aware appli ation.In addition to this, it enables the modelling of omplex sensors su h as video ameras, andhigher-level per eptual omponents su h as a Body Tra ker that an exploit these omplexsensors. SitCom has been used to model a range of ontext-aware appli ations, su h as aMeeting State Dete tor and Crowd Dete tor amongst others, and these s enarios leverage therange of abstra tions provided by the simulator.SitCom's ability to integrate data streams from external sensor sour es is a novel feature inthis domain, and allows the evaluation of ontext-aware appli ations against real data sour es,enabling a stronger validation of those appli ations.The authors express that �exibility is a hieved, and this is true for the ontext-aware omputing domain. However, it is di� ult to see that SitCom might be �exible enough toextend to modelling other subsets of pervasive omputing. Perhaps the most glaring omissionfrom the spe i� ation of SitCom is that network simulation is not supported internally orexternally.2.5.6 P-VoTP-VoT, the POSTECH Virtual reality system development tool, has been extended by (Seo 05)to provide a virtual pervasive omputing environment, that is suitable for rapid prototyping.Spe i� ally, the work is targeted at a subset of pervasive omputing where the a urate mod-elling of the display of data to users is the most important requirement. Although this thesisand state of the art is not on erned with multimedia displays in the general ase, the imple-mentation of the simulator o�ers some novel features, and it is therefore onsidered. Thesefeatures in lude the ability to model the behaviour of devi es in a State hart and the use ofa s ripting language to asso iate fun tionality with that State hart.45

2.5. The Key SimulatorsRC1: Flexible HeterogeneityThe simulator implements three lasses of obje ts, that re�e t the targeted multimedia do-main. These obje ts are sensors, displays, and pro essing obje ts. An instantiation of theP-VoT simulator is a omposition of these obje ts, whi h an intera t in a pre-determinedfashion. Sensors push data to pro essors, whi h then ontrol the output of the display. Adisplay is analagous to an a tuator in this parti ular pervasive omputing domain.Ea h omponent an be spe i�ed at di�erent levels of abstra tion o�ering an additionallevel of �exibility. For example, sensors an be instantiated to produ e raw data, �ltered data,or even higher-level data su h as ontextualised data. Pro essor obje ts an be instantiatedto implement raw data pro essing patterns su h as �ltering, or higher-level pro essing su has pattern re ognition. Finally, displays an be spe i�ed at the level of LEDs9 or text at themost basi level, up to 2D and 3D displays.The intera tion between these obje ts are modelled using State harts. A State hart spe -i�es the states, the transitions between states and the messages that an be sent betweeninstan es. Upon rea hing a ertain state, some Python (a s ripting language) ode is invoked.The intera tions between the di�erent obje t types is aptured within the State hart. Forexample, a model of a passive sensor, remains in an idle state until an obje t or the mea-sured phenomenon meets some riteria and the sensor undergoes a state transition. This hange in state an result in the invo ation of a Python method, whereby further a tions and omputations an be arried out.RC2: ExtensibilityP-VoT's s ripting based approa h is low-level but potentially extensible. One of the advan-tages of s ripting languages, that they allow rapid prototyping, has been apitalised upon bythe developers and it would be feasible for s ript-based extensions to be built within the sys-tem spe ifying new appli ation behaviour and new simulated models. Indeed the developersof P-VoT have validated their simulator's approa h against other pervasive omputing do-mains beyond ontext-aware appli ations, whi h in lude smart devi es, smart environmental9Light Emitting Diode's 46

Chapter 2. Related Workmonitoring, and smart spa es su h as an information kiosk.RC3: Ar hite tureThe P-VoT simulator is a omponent based simulator that is omprised of a set of authoringtools. An integrated development environment (IDE) provides a State hart editor, a libraryof reusable virtual and intera tion obje ts and a Python exe ution environment. The ombi-nation of tools runs on a lo al ma hine, and provides a graphi al user interfa e for the reationand spe i� ation of simulated experiments. No external intera tion with external servi es,simulators or external appli ations is supported within the ar hite ture.RC4: Appli ation EmulationAppli ations are not emulated within the P-VoT system. Instead, they are modelled as �pro- essing obje ts� and are implemented using State harts and the Python s ripting language.Within these State harts, ea h state is de�ned by a s ript ontaining algorithms de�ningbehaviour and outputs based on existing states and sensed data.RC5: Intera tion of Emulated and Simulated ComponentsAs there are no emulated appli ations in P-VoT, there is no intera tion between emulated andsimulated omponents. Appli ations that are modelled as state- harts and behaviours maya ess simulated sensor information and use this as part of the s ripted appli ation behaviour.RC6: Network SimulationThere is no network simulation omponent within P-VoT. The fo us of the simulator is on ontext-driven, multimedia based pervasive omputing appli ations, a very ni he domainwithin pervasive omputing that does not ne essarily require network simulation.RC7: Experimental SupportThe P-VoT simulator provides experimental support via an artifa t des ribed as a data ol-le tion obje ts. These an olle t appli ation performan e data as well as aggregate data47

2.5. The Key Simulatorsprovided by users of the simulator su h as usability information and survey answers.RC8: External Intera tionNo external intera tion is supported within the P-VoT simulator.SummaryLike SitCom, P-VoT is a simulator targeted at a very parti ular subset of pervasive om-puting, in this ase ontext-aware multimedia enhan ed pervasive omputing environments.With this in mind, it is perhaps unfair to judge the simulator on the riteria by whi h othersimulators have been judged. However, this simulator has adopted an approa h to spe ifyingthe behaviour of obje ts that is novel in the area of pervasive omputing simulators. Theuse of a ombination of a State hart and the Python s ripting language results in a rapidprototyping and evaluation model. The result is a simulation that an be rapidly prototypedand implemented. The developers report that the overall authoring pro ess, �simple s ripting, reating states, and transitions�, an take less than an hour, for a user with experien e of thesystem.2.5.7 StarBED2The last of the ore pervasive omputing simulators to be onsidered is StarBED2 (Nakata 07),whi h is a large-s ale hybrid of both simulator and physi al testbed for pervasive networks.Although not a lassi al simulator in the sense of what is onsidered for this thesis, it isnevertheless worth onsidering. Spe i� ally, StarBED2 enables the emulation of hundredsof thousands of heterogeneous nodes within pervasive omputing networks. In order to dothis, it outlines the required fun tionality to exer ise what it has determined to be the mostimportant hara teristi s of pervasive omputing networks. These hara teristi s are that:• A realisti pervasive omputing s enario omprises heterogeneous sensor nodes.• Those nodes may have a high spatial density.48

Chapter 2. Related Work• The intera tion between the environment and those nodes is an important fa tor in theoverall model, whi h is a hara teristi of pervasive omputing.• The lo ation of those nodes is important in modelling the intera tion of these nodes andtheir environment.In order to a hieve this, StarBED2 provides a physi al testbed that emulates the physi alenvironment, supports the emulation of several node types and ar hite tures, and supportsthe intera tion of the environment and those nodes. The overall ar hite ture of the distributedStarBED2 testbed is not onsidered here, only the ar hite ture at a single node within thattestbed.RC1: Flexible HeterogeneityThe environmental spa e with StarBED2 is a hieved through either statisti al models, orthrough a �realisti manner� where the physi al phenomenon is simulated a ording to somedomain expertise. There is no support within StarBED for the emulated on ept of a sensor,rather that the environmental spa e is a data sour e whi h an provide inputs to nodes thatare within that modelled spa e.RC2: ExtensibilityThe �xed and hardware entri approa h that StarBED2 has used is not ondu ive to exten-sibility to other pervasive appli ation domains. The fo us of the testbed is on the realisti testing of physi al nodes in �xed lo ations and a ounting for mobile nodes su h as physi alusers or vehi les would be di� ult within the physi al testbed des ribed.RC3: Ar hite tureThe StarBED2 ar hite ture is logi ally stru tured as a three tier ar hite ture. At the lowesttier, the network spa e provides the ommuni ation infrastru ture of the physi al testbed,whi h is omposed of approximately seven hundred personal omputers (p ). Two networks onne t the nodes. The experimental network is the network in whi h experiments run and49

2.5. The Key Simulators ommuni ate. The se ond network is the management network, a separate network allowinga user of the testbed to remotely manage the experimental setup and the on�guration of thenodes within that experiment. The physi al testbed an also be logi ally partitioned and antherefore allow multiple experiments to run with di�eren e parts of the physi al testbed.The se ond tier of the ar hite ture is the node tier, in whi h emulated appli ations runand have a ess to the underlying physi al testbed. Finally, the top tier of the ar hite tureis the environmental spa e, a simulated environment whi h nodes an intera t with, eitherquerying or a ting upon that environmental spa e.RC4: Appli ation EmulationEmulation of heterogeneous nodes within StarBED2 is a ommodated at three levels: Themiddleware level, the system all level and the instru tion level. Depending on the targetedar hite ture and the implementation of the ar hite ture, the appropriate level is hosen. Forexample, emulation would be performed at the middleware or system level when the appli- ation on the node is spe i�ed in a high-level language. Alternatively, emulation would beperformed at the instru tion level if the operating system on that node was not fully available,and if appli ations were being written lose to the hardware layer. In the ases of system alland middleware emulation layers, the emulated appli ation must be re ompiled and linkedagainst a library that redire ts to the StarBED2 testbed instead of the physi al hardware.In the ase of instru tion-level emulation, an instru tion translation is performed to mapinstru tions to methods invoking the orresponding methods within StarBED2.Ea h emulated node then runs within its own VMware10 virtual ma hine, making ea hnode virtual. Up to ten nodes are then run on ea h physi al ma hine within the testbed,and the responsibility then transfers to the VMware software to manage the exe ution of theindividual virtual nodes.10http://www.vmware. om 50

Chapter 2. Related WorkRC5: Intera tion of Emulated and Simulated ComponentsThe intera tion between emulated appli ations and their environment is aptured as a seriesof on eptual spa es and onduits between these spa es. Three types of spa es exist, anenvironment spa e, a network spa e, and a node spa e. Within the node spa e, the physi allo ation of the devi e is riti al and it a�e ts the nodes intera tion with the environmentspa e, also addressed through physi al oordinates. The node's lo ation within the networkspa e onsists of an IP address and port number pair. The logi al stru ture of StarBED2,as a series of spa es and onduits manage the bindings between the physi al oordinates andthe network oordinates, enabling the intera tion between nodes and their environment, andamongst nodes themselves.RC6: Network SimulationThe StarBED2 testbed is a physi al testbed and the underlying hardware omponents arenetworked using wired and wireless omponents. There is no network simulation omponentwithin the testbed as the goal of the testbed is to move beyond simulation into hardwarebased testing.RC7: Experimental SupportA separate management layer within the physi al part of the testbed is an indi ator of howexperimental support is managed. A ontroller tier manages the exe ution and on�gurationof individual nodes within the testbed and an re ord logged information out-of-band, i.e.the management overlay of the testbed does not a�e t any ongoing experiments, a potentialproblem in distributed testing ar hite tures.RC8: External Intera tionEmulated nodes within the StarBED2 ar hite ture run in a real-time environment and ontheir virtual ma hine within a physi al node. As there are no onstraints on the appli ation ode that run on the emulated nodes, it an be inferred that these an intera t with externalsour es without a�e ting other nodes within the overall. experiment.51

2.6. Perspe tivesSummaryStarBED's approa h to emulation is �exible and relatively unique within the pervasive om-puting spa e in that it enables the emulation of heterogeneous nodes. The implementationusing a VMware solution eases this task to a degree, in that it transfers the responsibilityof managing the individual instan es to the VMware server. This partially addresses oneof the main problems of emulating multiple appli ations: appli ation syn hronisation. Asappli ations exe ute in wall- lo k time, it is possible for ina ura ies to enter the simulationwhen appli ations do not run in their orre t ordering, a problem, that is exa erbated whentrying to integrate emulated real devi es with simulated models. StarBED2's VMware-basedapproa h addresses this problem, however the overall solution is an expensive one. Runninga VMware server is ostly in terms of ma hine overhead, a fa t noted by the developers ofStarBED2 and one of the reasons why the number of nodes per single ma hine within thetestbed is restri ted to ten.The developers make no e�ort to enfor e ausal ordering with respe t to the ordering ofindividual appli ation exe utions within a VMWare instan e. In restri ting the number ofnodes per instan e to ten, they attempt to mitigate the negative side a�e ts of overloading theVMWare. The developers note, that on the original StarBED testbed, upon whi h StarBED2is based, that when above ten virtual nodes were run, then �realism of experimental resultsbe omes una eptably low�.2.6 Perspe tivesAs a result of the wide range of simulator domains examined, ases will arise where a simulatormay only address a subset of the review riteria. For example, a pervasive omputing simulatormay provide support for environmental models but not for a tuators that intera t with thoseenvironments. In these ases, the simulators ability to meet a riteria is marked as not-appli able, N/A. In general, however, the simulators are examined against all of the appli ablereview riteria, and are marked as either partially, ◦, or ompletely, •, meeting that review riteria. Review riteria 3, the system's ar hite ture is omitted as it is too subje tive to52

Chapter 2. Related WorkFlexibleHeterogeneity

Extensibility Appli ationEmulation

ComponentIntera tion

NetworkSimulation

ExperimentalSupport

ExternalIntera tion

UbiWise ◦ ◦ ◦ • n/a n/a •Tatus ◦ ◦ • • ◦ ◦ •LSE ◦ • • • ◦ ◦ •UbiREAL ◦ ◦ • • • • •SitCom ◦ ◦ ◦ ◦ ◦ ◦ ◦P-Vot ◦ ◦ n/a n/a • • n/aStarBed2 ◦ ◦ • • • • •Table 2.2: Comparing the review riteria for the key pervasive omputing simulators ompa t the review in a single olumn.The evaluation riteria for the simulators dis ussed have been met with varying degreesof su ess. Table 2.2 reveals that LSE, UbiREAL and StarBED2 were the most su essfulin meeting these requirements, although none met all of them ompletely. Two importantquestions are raised. Are all of the requirements ne essary? Why are some of the require-ments not met? To answer the �rst question, one must examine table 2.2 again. What anbe observed is that none of the original six requirements are ompletely negle ted. Only re-quirement four, support for network simulation, is not addressed by more than one simulator.In this ase, two simulators, SitCom and P-Vot were targeted at sub-domains of pervasive omputing: ontext-aware omputing and multimedia enhan ed smart-spa es. In these ases,an a urate model of the user and the environment from its perspe tive is more importantthan the modelling of the intera tion of appli ations within that domain. In general though,all of the simulators examined address the requirements to some degree, but do not ne essarilymeet them all su essfully.To answer the se ond question, the answer an again be found in SitCom and P-VoT. Theseare two simulators that target spe i� domains within pervasive omputing, domains that donot require network simulation. The requirements that have been identi�ed though, are that53

2.6. Perspe tivesComponent Type Environment Sensor A tuator UserUbiWise • • n/a •Tatus • ◦ ◦ •LSE ◦ • n/a ◦UbiREAL • ◦ n/a •SitCom • • n/a ◦P-Vot • • n/a •StarBed2 ◦ ◦ n/a n/aTable 2.3: Pervasive Computing Components Modelleda generalised pervasive omputing simulator should be able to simulate all sub-domains of thebroad pervasive omputing domain. To address this, an examination omparing the variousapproa hes employed by the simulators is now presented. In addition to highlighting thestrengths and weaknesses of ea h approa h, alternative approa hes that may not have been onsidered by the original seven simulators are introdu ed, supplementing those approa hesalready examined. Thus, it is hoped that a more omplete set of approa hes is identi�ed,along with any di� ulties that a ompany those approa hes.2.6.1 RC1 - Flexibility in Modelling Pervasive Computing ComponentsTable 2.3 shows the degree to whi h the simulators modelled the omponents that are typi alof pervasive omputing environments. Apart from the observation that none of the simulatorsmodel all of the omponents, the most notable feature is that almost all of the simulators, allwith the ex eption of Tatus, fail to provide any support for a tuators. This is most likely are�e tion of the fa t that the proliferation of sensors in pervasive omputing environments haso urred at a mu h faster rate than that of a tuators, thus generating a greater requirementfor the modelling of this fun tionality.EnvironmentThree approa hes of note have been introdu ed by the simulators dis ussed. Using a graphi altool, Ubiwise, Tatus, and P-VoT an spe ify a model of the environment in a realisti 3-Dformat. From a person's perspe tive, this seems ideal, as it is far more tangible than spe ifying54

Chapter 2. Related Workthe environment in terms of a physi al quantity, whi h is the approa h adopted by UbiREAL.However, the lengthy time required to develop a model of a physi al spa e makes this approa hprohibitive, even though it is adopted by many simulators. Another point to note is that ithas been previously time- onsuming and di� ult to expand these models into larger and moredetailed representations of the environment, although tools are emerging that will assist inthe automation of this task in the future.Spe ifying an environment in terms of a physi al formula is more expressive from the pointof view of the phenomenon being measured. A physi al formula is also more �exible when onsidering the intera tion that omponents an have with that environment. For a sensor to al ulate the value of the environment at a point in the modelled spa e, it simply has to plugin some values, su h as its lo ation, into the physi al formula spe i�ed.What is ommon amongst these two approa hes is that they both support a publish-subs ribe me hanism to notify sensors of hanges in the measured phenomenon. Similarly,game engines typi ally provide a trigger me hanism, whi h an be exploited for this purpose.The �nal approa h is to use a simple set of key-value pairs. This approa h has been used inSitCom and also in work by (Martin 06b) in the development of their simulator for ontext-aware omputing. In this approa h, some aspe t of the environment, whether a physi alphenomenon or a sense-able �thing�, is indexed by a key and the value of the sensed data isreturned. This approa h is limited to phenomena that are simple in type, and do not varya ross more than one parameter. For example, in order to simulate a phenomenon a rossa physi al spa e, in the way that the physi al quantity simulators su h as UbiREAL do, akey-value pair would have to be generated at every lo ation, whi h is ine� ient.(Naumov 03) have des ribed an extension to ns-2 (Fall 01), that improves the modellingof the environment with a view to improving the e� ien y of a simulation. Naumov et al,have proposed partitioning the spa e tra king the lo ation of nodes into a grid omprisingphysi al spa es. This logi al partitioning enables a more e� ient al ulation of the lo ation ofnodes within the network simulation, and has been shown to improve the performan e of thesimulator by signi� ant fa tors. A similar approa h is used by (Sundresh 04) in implementingtheir model of an environment in their wireless sensor network simulator, SENS. The model55

2.6. Perspe tivesof the environment is partitioned into smaller physi al spa es, whereby ea h spa e, alled atile, assumes a value of either grass, on rete or wall. The model of the environment is usedto model more a urate radio-propagation models for wireless sensor networks.SensorsTatus, UbiREAL and SitCom o�er the most varied approa hes to the modelling of a sensor.The most basi approa h to modelling a sensor is to abstra t the physi al devi e to a queryAPI. This approa h is adopted by UbiWise and Tatus, whereby alls to a sensor API returnsensor data from the graphi al environment. The Lan aster simulator provides a slightlymore omplex API, that returns ontextual data rather than raw physi al data, but the queryAPI abstra tion remains the same. This simplisti model does not take into a ount any hara teristi s of the sensor itself.A slightly more omplex approa h is to model the devi e driver that would be used tonormally a ess a sensor, an approa h that is used by UbiREAL. In this ase, the sensordata returned is the same as that of UbiWise and Tatus, but it is returned in a format thatthe appli ation is expe ting. As is noted, using a simple query API means that appli ationshave to be re-written to use that API. UbiREAL's approa h of abstra ting sensors to devi edrivers, essentially provides an emulated interfa e, on top of a basi query API. A similarapproa h is used in the wireless sensor network simulator domain. TOSSIM (Levis 03), andEmStar (Girod 04a) to a ertain extent, provide the notion of an Analog to Digital Converter(ADC) hannel, but only provide a simplisti implementation with port/value pairs, i.e. aport is read and a single 10 bit value is returned. This value an be random, or a generalmodel an also be implemented using an external fun tion.The resultant emulated sensor datais pushed to the emulated TinyOS appli ation.SitCom uses its 3-D game-engine based environment model to its advantage to generatea urate models of more omplex sensor streams su h as video feeds or audio streams. Thisis a great example of exploiting the graphi al model of the physi al environment to its fullpotential, something that UbiWise and Tatus arguably do not.What is missing from all of these models is apturing the a tual devi e itself. When an56

Chapter 2. Related WorkAPI is presented to an appli ation as an abstra tion of the sensor, all of the hara teristi sof the sensor are missing. Di�erent sensors have di�erent thresholds for example, and behavedi�erently a ording to an error model. Capturing this error and these sensor hara teristi s an be useful in the omplete modelling of the domain. In wireless sensor networks, modellingwhat happens at the physi al sensor is often negle ted, be ause the fo us of the resear h isoften on the network layer or the query. There are, however, some wireless sensor network sim-ulators that o�er more omplete models of sensor devi es than the simulators in the pervasivedomain, and is more re�e tive of the error-prone data that sensors provide in reality.SensorSim (Park 00) introdu ed the notion of a �sensor hannel�, whi h models the phe-nomena whi h is sensed rather than the hannel for delivery of sensor events. A sensor hannelexists that models the wave propagation hara teristi s of infra red light, and a separate modelexists for representing sound waves. In J-Sim (Sobeih 05), the notion of a sensor hannel isagain used to model senseable phenomenon. A sensors physi al layer is used as an interfa eto this hannel and is the sole input into the sensor hannel. A sensor propagation model isused in the sensor hannel. Signals propagated over the sensor hannel may be attenuated,a ording to signal strength, re eiving thresholds and other hara teristi s determined by thesensor propagation model. Other fa tors taken into a ount in the model are the lo ation ofthe sensor, and that the lo ation of other sensors may also impa t upon the signal propagatedover the hannel.A tuatorsThe only pervasive omputing simulator to address the model of an a tuator is Tatus, andsimilarly to its model of a sensor, it is abstra ted to an API rather than modelling the devi eitself. The simple API o�ers appli ations the opportunity to update some state in the world,the e�e ts of whi h are aptured within the graphi al environmental model. However, thiste hnique o�ers no opportunity to spe ify a tuators with di�erent hara teristi s, that mighta�e t the environment in di�erent ways.A tuators, however, are more ommon in the roboti s ommunity, and a simulator de-veloped by (Labella 06) for the sensor and a tuator network (SANETs) domain has merged57

2.6. Perspe tivesa roboti s simulator and a wireless sensor network simulator. The ODE (Ordinary Di�er-ential Equations) system (Parker 04), models the rigid body dynami s of a physi al roboti a tuator. Similar resear h work has been a hieved in Player/Stage11 and has re ently beenapplied (Kranz 06) to the pervasive omputing domain. This library approa h to modellinga tuators is however onstrained to roboti s, and is not extensible to a tuators, for examplelight swit hes, or radiators, that are often onsidered in the smart-spa e domain, a subset ofpervasive omputing. From a more general perspe tive, it would be useful to onsider a tu-ators as they might apply to a physi al environment. In parti ular, UbiREAL's approa h ofspe ifying the environment in terms of mathemati al fun tions de�ning the hara teristi s ofthe spa e would appear to overlap with the roboti s approa h. Given the expertise requiredto generate the formulae of the phenomenon, the formulae ould be extended to a ommodateupdates to the model based on the a tions of an a tuator.UsersTwo approa hes are evident in modelling the users within a pervasive omputing environment.UbiWise, Tatus and UbiREAL all exploit the fun tionality of the underlying game engine toprovide realisti models of human users that an intera t with their respe tive modelled en-vironments. Gamebots and Non-Playing-Chara ters (NPCs), an be programmed to intera twith their environments, in luding moving around the environment, using obje ts, su h asappli ations (in Tatus) or physi al devi es (in UbiWise) modelled within that environment,and intera ting with other NPCs. The game engine API simpli�es the task of modelling thefun tionality of users within the model.It seems lear though, that the approa h of using an NPC is dependent on the physi alenvironment that is aptured by the game-engine. In wireless sensor networks, the user isusually de�ned in a stri t mobility patterns or more re ently, a tra e-based mobility patterns.In intelligent transportation systems, the user is a vehi le or a person inside a vehi le. Con-sidering this broader range of pervasive omputing domains, then individual NPCs must be reated for ea h domain.11http://playerstage.sour eforge.net/ 58

Chapter 2. Related WorkP-VoT spe i�es the behaviour of users in terms of a State hart, i.e. modelling states, andstate transition fun tions. More omplex behaviour an be spe i�ed in the Python s riptinglanguage, although there is no spe i� ode base for modelling users.There are two points to note. The �rst is that the model of a user is dependent on themodel of the environment in whi h that user exists. Se ondly, that model of the user mustintera t with that environment in a spe i�ed way. This means that the model of the physi alenvironment, must be explorable or queryable from a user's perspe tive. This holds truewhether the model of the environment is aptured as a building, or a series of rooms, as isthe ase in UbiWise and Tatus, or if the model of the environment is aptured as a series ofstates, in the ase of P-VoT.Several models from outside the pervasive omputing spa e have been applied to modellingusers. Formalised models su h as random walk and random waypoint (Camp 02) have beenlong established and used within the wireless network simulation ommunity. These are,however, basi models of a user's lo ation, moving around an open spa e, whose patternof movement is often not a�e ted by their environment. More omplex mobility patternshave been established for parti ular transport domains su h as rail (Li 06), and road tra� (Esser 97) simulators, and these models apture an in reased dependen y on the environment ompared to the lassi al mobility patterns.In addition to these mobility patterns, e�orts have also been made to apture the be-haviour of users spe i� ally in the pervasive omputing domain. (Narendra 05) has spe i�eda user's behaviour in terms of event- ondition-a tions, a rule-based system that has its rootsin multi-agent simulation. The omplete system models hardware devi es as resour es andappli ations, and they are also spe i�ed in terms of event- ondition-a tions. The environmentitself is presented in terms of ontextual information. An alternative approa h to modellingthe user using XML has been addressed by (He kmann 03), who exploits an ontology lan-guage, UserML, to model attributes of the user su h as their lo ation, their a tions, and the onditions they are a ting under. This model is to be used by real appli ations to ex hangedata about users though, rather than being part of a larger simulation model, so unfortunatelyit does not tie into any spe i� models of the environment that a user might exist in.59

2.6. Perspe tives2.6.2 RC4 - Appli ation EmulationA typi al pervasive omputing appli ation requires emulation on two fronts. An appli ation an use sensors and a tuators to intera t with its environment, and it an also use a network,either wired or wireless, to ommuni ate with its peers. There are two main approa hes toa hieving the emulation of these two interfa es.The �rst emulation te hnique, adopted by UbiREAL, and StarBED2 uses a ompile-and-link approa h. In this approa h, the target appli ation is emulated at the immediate level ofits intera tion with its underlying exe ution environment. A library is written that onformsto the API of the system alls or middleware, but interfa es with the simulator instead ofthe original target platform. The emulated appli ation is ompiled and linked against thesimulators library instead of the original libraries.A similar approa h is used by LSE to enabling the emulation of the appli ation's network-ing fun tionality. However, instead of redire ting method invo ations within the appli ation,the appli ation is ompiled and linked as normal, and the kernel is modi�ed to inter eptmessages and re-dire t them into the network simulator.The de ision of what level to emulate at is dependent on a variety of fa tors, and maybe in�uen ed by whether it is the network interfa e or hardware interfa e, or both, that isbeing emulated. Additional important fa tors in lude the availability of the sour e ode forthe appli ation, middleware and system alls upon whi h the appli ation is built, and thea ura y of emulation required. A ompile and link approa h to emulation is only possiblewhen the sour e ode of the appli ation is freely available. In this ase, inter epting allswithin the kernel is possible, but may only be suitable for emulation of the network interfa e.An additional fa tor to onsider is the a ura y of the emulation required. In the ompile-and-link approa h, alls to the underlying fun tionality, whether it is system alls or middle-ware are redire ted into the simulator. If an appli ation is built upon middleware, and allsto that middleware are redire ted immediately into the simulator, then all of the fun tionalityof the middleware is lost. If the sour e ode for the middleware is available, it may be moreappropriate to retain some of the fun tionality, and redire t methods to the simulator aftersome of this fun tionality is invoked. 60

Chapter 2. Related Work2.6.3 RC6 - Network Simulator IntegrationThere are two approa hes to supporting network simulation within these simulators: buildyour own or integrate an external simulator. UbiREAL and Tatus have developed theirown network simulators, whi h have been integrated dire tly into their simulators. Thereare positives and negatives to this approa h. There are well established network simulators,su h as J-Sim (Sobeih 05), whi h are already widely supported by the wireless sensor network ommunity. Developing yet another network simulator is a time onsuming task, and is an areaof resear h in its own right. However, designing your own simulator does allow the developerto exploit fa tors spe i� to network simulation in pervasive omputing environments. Tatus,for example, fa tors in the lo ation of rooms and walls, provided by its world model, to modelmore omplex wireless networking environments than a standard network simulator.An alternative approa h is to integrate an existing network simulator into the simulatorto perform the role. This approa h, used by LSE, requires that mappings from the pervasive omputing simulator to the network simulator is provided. For example, the lo ation infor-mation of the individual nodes may be modelled by the pervasive omputing simulator, butis needed by the network simulator for the al ulation of nodes within a transmission rangefor example.An additional fa tor for onsideration is that if the appli ations are being exe uted inwall- lo k time, then there may be limits on the number of nodes that an external networksimulator an model. The network simulator has two tasks. The �rst is to al ulate there eivers of a message that is sent, and the se ond is the delivery of that message to the orre t re eiver at the orre t time. If the time taken for the two of these tasks is greater thanthe time taken to deliver the message in the real world, then the simulation of the networkis ina urate. The time taken to al ulate the re eivers in reases substantially as the numberof nodes in the simulated wireless network in reases, so this may be a limiting fa tor in thisapproa h. 61

2.7. Summary2.7 SummaryThere have been numerous simulators that have been developed to address the need forevaluation tools for pervasive omputing. UbiWise, the su essor to QuakeSim, was the �rstof the well known simulators to be developed, and its game-engine based approa h has beenutilised by further simulators in re ent years, notably Tatus and SitCom. More re ently,UbiREAL has re ognised the importan e of a more omprehensive approa h to simulatingthe domain, integrating improved models of the physi al aspe ts of the environment.However, these simulators have only met with limited su ess, and none have addressedall of the requirements identi�ed for modelling a domain. Perhaps the most striking areaof this is in the modelling of the omponents that are the very fabri of these pervasive omputing s enarios. None of the simulators dis ussed attempt to model a physi al sensoritself, instead they prefer to abstra t it typi ally to a query interfa e or a devi e driver. Thereis less support for a tuators in the existing state of the art. One of the ex iting prospe tsin pervasive omputing is the use of a tuators to a�e t the environment, yet this intera tionbetween the environment, and the a tuator, and the a tuator devi e itself is rarely modelled.The la k of models for these devi es is partly due to the fa t that pervasive omputingis a very broad area, that en ompasses a wide array of physi al devi es. It is di� ult to ome up with a set of omponents that are representative of the domain, and that mayintera t with ea h other in unanti ipated ways. There have been attempts to integrate thirdparty simulators that address the modelling of these omponents individually, but without aninfrastru ture to bind these omponents together, this approa h an only ever have limitedsu ess.Although it has been established that pervasive omputing is a broad multidis iplinarydomain, the underlying omponents su h as appli ations, sensors and the model of the networkare in fa t onstrained at an abstra t level. For example, it has been noted that severalsimulators, UbiREAL, Tatus, and UbiWise all employ a publish-subs ribe design patternor similar to notify sensors of hanges in the environment, and that this design pattern isindependent of the implementation of the sensor. Similarly, it has been noted that in pervasive omputing the a tions of the user, who may be arrying devi es or appli ations, are in�uen ed62

Chapter 2. Related Workby their environment. Compared with the wireless sensor network simulator domain, wherea user is de�ned by a stri t mobility pattern, more realisti models of the user and theirintera tion with their environment are required.This hapter has provided an overview of the state of the art in the area of simulators forpervasive omputing. Using the review riteria determined, the main works in this area havebeen examined, and have been shown to be de� ient in several aspe ts. Finally, a omparisonof the adopted approa hes to modelling the main omponents was presented, and additionalrelated work in these areas were also identi�ed.

63

Chapter 3The PiCSE Framework Ar hite ture3.1 Introdu tionAs presented in the opening hapter, this thesis des ribes a framework enabling both the sim-ulation and emulation of pervasive omputing s enarios. The PiCSE framework is omprisedof three lass ategories, the PiCSE_Core, Abstra t_Interfa es, and PC_Abstra tions that ombine to form the PiCSE framework. Developers use the PiCSE_Core lasses to supportinstantiations of the PC_Abstra tions lass ategory to reate simulations of tailored perva-sive omputing s enarios. Additionally, the Abstra t_Interfa es lass ategory an be used toextend the framework to meet modelling requirements not provided by the PC_Abstra tion lass ategory.This hapter presents the PiCSE framework and examines how the reation of simulationsis supported by the PiCSE framework and the underlying infrastru ture. The hapter beginsby justifying the appli ability of the framework-driven approa h and identi�es requirementsthat will guide the framework's design. The on eptual ar hite ture of a typi al PiCSEinstantiation is then onsidered. This highlights the main levels of intera tion between therespe tive omponents of an instantiation. The main abstra tions that are provided to modelthese omponents are then introdu ed, and this is followed by presentation of the framework'ssupport for the realisti emulation of appli ations. Finally, the overall ar hite ture of thePiCSE_Core lass ategory is examined. 65

3.2. A Framework-Driven Approa h for the Testing of Pervasive Computing Appli ations.3.2 A Framework-Driven Approa h for the Testing of PervasiveComputing Appli ations.Based on the ore hallenges and the seminal de�nitions for frameworks introdu ed in hapter1, three riteria should be satis�ed in order to onsider a framework driven approa h for thetesting of pervasive omputing appli ations. These are:1. Are these a family of related problems?2. Do they intera t in a de�ned manner or pattern ?3. Could the urrent approa hes bene�t from avoiding re- reating and re-validating om-mon solutions to re urring appli ation requirements and software design hallenges?The answer in all three ases is yes.Are these a family of related problems? Currently, there are a wealth of simulatorsand emulators all addressing di�erent but related aspe ts of the pervasive omputing domain.Within these simulators and emulators, there are many re urring a tors, omponents andelements in luding persons, sensors, lo ations, ommuni ation abstra tions and the environ-ment and in many ases these aspe ts are on eptually similar but are simulated to di�erentdegrees of granularity or omplexity depending on the aim of the simulator. For example, in anetwork simulator su h as NS-2, a person is abstra ted to a mobility pattern su h as randomwalk, or random waypoint (Camp 02), whereas in a ontext-aware omputing simulator, aperson may have additional features su h as an identity, a urrent a tivity, and a plan asso i-ated with that mobility pattern. In this ase, learly the on ept of lo ation, mobility and aperson are related, but these are implemented using di�erent models and omplexities a rossthe di�erent simulators.Do they intera t in a de�ned manner or pattern ? The intera tions between elementsthat are re urring between simulators are not ne essarily pre-de�ned a ross all s enarios butthere are re urring intera tion patterns between them. For example, sensors often take sensor66

Chapter 3. The PiCSE Framework Ar hite turereadings from their lo al environment, and those sensor reading are generally used by someappli ation for the purpose of in�uen ing and driving some appli ation behaviour. Environ-mental monitoring appli ations often use stati wireless sensors and a gateway appli ationmay distribute a query to those sensors to gather data within the sensor network. Alterna-tively, a sensor an be event-triggered by a hange in the environment, for example a personentering a room or a proximity sensor that dete ts when a door has losed, and these events an trigger some rea tive appli ation behaviour. A se ond alternative intera tion is that anenvironmental monitoring sensor an be hosted on a mobile devi e whi h is arried by a per-son, and is only invoked when the person is using a ontext-sharing appli ation. In all threes enarios, wireless sensor networking, smart-spa es, and itizen sensing, there is a re urringrelationship, a pattern, between the sensor, the environment and the appli ation, althoughthe a tual me hani s and nature of the pattern di�er in ea h s enario.Could the urrent approa hes bene�t from avoiding re- reating and re-validating ommon solutions to re urring appli ation requirements and software design hal-lenges? At present, there are a wide range of simulators for ea h of the pervasive omputingsub-domains, and ea h has their own interpretation and implementation of the re urring ele-ments su h as lo ation, sensors, events, and mobility models. Avoiding the re-implementationof these omponents would both ease the task of development, and would give greater redibil-ity to any simulated results as those results would be built upon a ommon base. Finally, a setof omponents and abstra tions that were re urring a ross all pervasive omputing domainswould open up new opportunities for evaluation of overlapping domains as well as providinga base for an extensible ar hite ture that ould a ount for emerging domains in the future.3.3 A Frame of Referen e for a Pervasive Computing SimulatorIn hapter 1, a broad overview of pervasive omputing and its modern de�nition was presented.In re ognising that the future of pervasive omputing will be both multi-dis iplinary anddynami ally hanging, the fo us of this thesis's approa h is on an extensible ar hite ture that an a ommodate the modelling and evaluation of both new and existing sub-domains of67

3.3. A Frame of Referen e for a Pervasive Computing Simulatorpervasive omputing. As su h, the PiCSE ar hite ture is not targeting a sub-set of existingpervasive omputing domains and instead intends to be at least theoreti ally appli able to allpervasive omputing domains.The thesis's approa h onsiders the user to be a resear her or domain spe ialist who isusing a standard ommodity personal omputer, i.e. without a ess to high-performan e omputing hardware. There are no unusual restri tions on the platform that the frameworkshould be deployed on, but the �typi al� use- ase that we are onsidering is that of a resear herperforming some rapid prototyping, iteration and evaluation of a pervasive omputing s enarioand as su h is someone working at his own ma hine, typi ally a desktop omputer.3.3.1 The S ope of External-Fa ing FeaturesThe analysis of the most pertinent state of the art simulators in this domain, outlined in hapter 2, revealed a range of re urring features that are ommon to pervasive omputingsimulators. These in luded the modelling of sensors, users, domain-spe i� appli ations, theenvironment, and network simulation amongst others.Network SimulationThe design and implementation of the framework fo uses around the ore hallenges of �exibleheterogeneity, extensibility and reusability. One re urring omponent of pervasive omput-ing simulators is the aspe t of network simulation. There are already many well-establishednetwork simulators in this domain, and the PiCSE approa h does not attempt to reate anew network simulation omponent that ould ompete and potentially displa e one of these.Rather, it is re ognised that the resear h and development of su h network simulators isan entire and independent �eld of resear h in its own right, and PiCSE's framework imple-mentation does not attempt to dupli ate this resear h. Instead it fo uses on an extensibleopen ar hite ture that allows the future integration of a open network simulator, and thus ombining the best of both approa hes. 68

Chapter 3. The PiCSE Framework Ar hite tureUser Interfa esThe simulators outlined in hapter 2 implemented a variety of user interfa es ranging from ashell-based ommand-line interfa e up to a 3-D intera tive graphi al user interfa e used forboth the de�nition and the exe ution of a simulation. The overall system is implementedas a series of libraries and asso iated s ripts for the building and exe uting of simulations.Not having a graphi al omponent means that experiments that don't require a human inthe loop an be exe uted qui kly. In luding a �human in the loop�, i.e. in the exe ution ofa simulated experiment is an inherently slow approa h that is not suited to large s ale ex-periments. However, PiCSE's �exible and open implementation ensures that the ar hite ture ould be extended in that dire tion through the addition of a graphi al user interfa e if thatwas required.The Human or User Fa torNevertheless, the human or user element and behaviour is a key part of many pervasive omputing s enarios, parti ularly those involving smart spa es or ontext-aware omputing.The modelling of user behaviour within PiCSE is de�ned using a ombination of both mobilitypatterns and event-based model. Although it does not de�ne user behaviour in a manner asextensive as an agent-based model, the basi user model an intera t, sense, move within anda�e t both the modelled environment and other elements with that modelled environmentsu h as sensors or other domain-spe i� elements. This approa h allows PiCSE to handleusers as it would any other modelled element within a simulation. In line with Weiser'soriginal vision of pervasive omputing, PiCSE's support for appli ation and devi e emulationis restri ted to those devi es and appli ations that run in the ba kground, sensing, rea tingand ultimately prompting hanges in their environment. Therefore, the ar hite ture des ribedhereafter only onsiders appli ations that an run as dis rete servi es and not those that thatmay require dire t user input.As will be seen however, many of these restri tions that apply to the s ope of the frame-work's ar hite ture do not pre lude the integration of these omponents and features at alater date. Where appropriate, these extensions are dis ussed inline in the text.69

3.4. Requirements3.4 RequirementsThere were three main fa tors taken into onsideration when de�ning the requirements for apervasive omputing simulator. These were primarily highlighted by the analysis of the stateof the art. Review riteria su h as �exible heterogeneity and extensibility are only partially metby the urrent state of the art and are thus in luded dire tly as requirements. The requirementof a simulators support for external intera tion was omitted, as the fo us of the thesis wasto develop a standalone extensible ar hite ture that ould run on a lo al ma hine. Se ondly,the evolving multi-dis iplinary and emerging domains of the future of pervasive omputingmotivate and provide further requirements. Finally, the frame of referen e for a pervasive omputing simulator, as de�ned in the previous se tion also in�uen es the identi� ation ofthe requirements.There are many simulators that address subsets of the omplete pervasive omputingdomain but few are generi enough to address all of these subsets. Often, these simulatorsare not suitable for evaluating appli ation ode but fortunately there are platform-spe i� emulators that meet this requirement. However, these emulators often over simplify theinputs and outputs of the emulated appli ations, and it is a requirement of this frameworkthat the �exible and extensible modelling of these sensor inputs and a tuator outputs are afundamental part of the omplete evaluation of pervasive omputing s enarios. Se tion 3.2has stated that by identifying re urring ommonalities within the domain, using a frameworkis a suitable approa h to supporting the wide range of related pervasive omputing s enarios.The following requirements are therefore identi�ed for the PiCSE simulator:• R1 The framework should support the �exible and heterogeneous simulation of thehardware elements of pervasive omputing s enarios. This is be provided by reating ustomisable abstra tions representing physi al aspe ts of the s enarios su h as theenvironment, as well as hardware devi es su h as sensors and a tuators.• R2 The framework should support the emulation of real- ode appli ations developedfor pervasive omputing. These appli ations may be built upon middleware that shouldalso be supported. 70

Chapter 3. The PiCSE Framework Ar hite ture• R3 The framework should mediate the �exible intera tion of any simulated and emu-lated elements forming the simulation of a pervasive omputing appli ation.• R4 The framework should support the reation of new abstra tions of both hardwareand software elements, in order that future emerging appli ation s enarios an be in- orporated into the PiCSE framework.• R5 The framework should ombine re urring elements of pervasive omputing simula-tions into a set of reusable omponents thus redu ing the amount of work required toinstantiate any simulated s enarios.• R6* The framework should support network simulation for both wired and wirelessnetworks.• R7 A framework that supports the reation of pervasive omputing simulations mustprovide fun tionality to support the evaluation of those simulations.At present, there are no simulators for the pervasive omputing domain that meet all of theserequirements. A simulator designed as a framework ould potentially meet these requirementsand would form a ontribution to the state of the art in this area.Requirements R1, R2, R3Requirements R1, R2, and R3 all address the ore hallenge of �exible heterogeneity. A set ofmodelled hardware and software elements that were re urring a ross all pervasive omputingdomains and that ould be freely ombined would open up new opportunities for the evaluationof many pervasive omputing domains in luding future domains where the boundaries ofpervasive omputing and other domains begin to interse t. At present this level of �exibilityis not provided by any of the state of the art simulators and this requirement is mandated bythe future dire tion that pervasive omputing is moving towards.71

3.5. The PiCSE_Core Ar hite tureRequirement R4Requirement R4 maps dire tly to the ore hallenge of supporting extensibility. A frame-work should support the ability to a ommodate new emerging appli ation areas of pervasive omputing, and a ommodating these areas should be redu ed by leveraging on the previouswork en apsulated within the framework, i.e., the task of a ommodating these new areasshould be simpli�ed. Without this requirement, new modelling tools must be developed in onjun tion with ea h emerging appli ation area, despite the predi ted re urren e of many ofthe aspe ts of the emerging domain with aspe ts of previous pervasive omputing domains.Requirement R5The requirement R5 maps dire tly to the ore hallenge of reusability. Given the re urringelements, behaviours and patterns that have been identi�ed in pervasive omputing appli- ation s enarios, these should be en apsulated within a set of ore omponents within theframework that are ommon to all instantiations of the framework. This requirement followson from requirement R4 and is also mandated by the framework-driven approa h that hasbeen deemed to be the most appli able to this domain.Requirements R6* and R7Finally, R6 and R7 are two fun tional requirements for the framework. These requirementswere identi�ed as ne essary by their frequent re urren e in the simulators examined in thestate of the art, and address both key fun tionalities and usability. As noted however in theprevious se tion, although network simulation is a re urring feature of pervasive omputingsimulators, the approa h used is to allow the integration of an existing and proven networksimulator as a sub- omponent or an out-sour ed feature of the ar hite ture.3.5 The PiCSE_Core Ar hite tureThe PiCSE_Core lass ategory provides the ore and re urring omponents of an instanti-ation of the PiCSE framework, i.e., a simulation. It ontrols the dispat hing of events raised72

Chapter 3. The PiCSE Framework Ar hite tureby the simulated models and ontrols the exe ution of appli ations in the form of pthreads.Figure 3.1 identi�es the key omponents within the PiCSE_Core. The PiCSE_Core itselfis implemented as a olle tion of on rete stati lasses, and an be logi ally divided intotwo se tions: the majority of the omponents intera t with both the Simulated_Models andEmulated_Interfa es layer through the PiCSE API, whilst the Domain_Manager (in ludingits sub- omponent, the lo ation manager) intera ts solely with the Simulated_Models layer.Ea h of these omponents plays an important role in the instantiation of a PiCSE in-stantiation. The Domain_Manager is responsible for the management of instantiations thatrepresent the �physi al� aspe ts of the domain. It provides the layer sta k, the olle tion ofindependent EntityLayer and EnvironmentLayer instantiations, and maintains the depen-den ies between them. It provides a global de�nition of variables, su h as the dimensions ofthe modelled domain, and provides servi es to the simulated omponents, su h as generatingrandom lo ations, for the instantiation of simulated Obje ts.In addition to this, it also plays the role of a Lo ation_Manager. The Lo ation_Managermaintains the lo ation of Net_Interfa e instantiations, whi h are used to provide a basi network simulation interfa e. As an Exe utionEnvironment instantiation moves through-out the modelled domain, the lo ation of its respe tive Net_Interfa e also moves. TheLo ation_Manager manages the modelling of their lo ations, whi h is required by the net-work simulation omponent.The network simulation models the wired and wireless network ommuni ation of a PiCSEinstantiation. The model supported is very basi : A pa ket (in the form of a string ora void*) an be broad ast to all lo al neighbours or an be uni ast to a single neighbour.Pa kets an be �dropped�probabilisti ally, and also based on transmission range. Both of theseparameters an be set by the user. The al ulation of the distan e between potential re eiversand the sender is performed in onjun tion with the lo ation manager, whi h maintains thelo ation of all Net_Interfa e obje ts. The realisti modelling of a network simulator is nota feature of the PiCSE simulator. There are many existing network simulators, and thedevelopment of another is an area of resear h in its own right. Instead, the PiCSE ore hasbeen ar hite ted bearing in mind the future potential integration of a well-known network73

3.5. The PiCSE_Core Ar hite ture

Figure 3.1: The PiCSE_Core ar hite ture74

Chapter 3. The PiCSE Framework Ar hite turesimulators, su h as GlomoSim1 or Opnet. Although this has not been evaluated in any ofthe evaluation s enarios, the separation of the Lo ation_Manager and the Net_Interfa eabstra tion from the network simulation omponent ensures that the network simulation omponent itself ould be potentially repla ed.The Thread_Manager and the Event_List_Manager perform the joint role of exe uting aPiCSE simulation instantiation between them. As mentioned previously, the framework's sup-port for emulating multiple appli ations is implemented using a master-slave multi-threadedapproa h. The Thread_Manager manages the ontrolled exe ution of both master and slavethreads. The master thread itself is used not only to swit h between the slave threads, butalso to advan e the Event_List_Manager, whi h is responsible for the s heduling of eventsoriginating from both the simulated models and emulated appli ations. Slave threads ares heduled to wake up at a time determined in advan e of the thread being put to sleep.The Event_List_Manager maintains two lists: the S heduled_Event list and theS heduled_Appli ation list. The S heduled_Event list is an implementation of a lassi alDEVS event list: a set of events ordered by their timestamps. The S heduled_Appli ationlist is a set of <pthread, Exe utionEnvironment*> tuples, also ordered by their times-tamps. The master thread advan es the two event lists, by he king and determining thenext event. In the ase of the next event oming from the S heduled_Event list, the threadof ontrol remains with the master thread, the event is dispat hed, and the appropriate fun -tionality of the simulated entity is invoked. Alternatively, an event is dispat hed from theS heduled_Appli ation list. In this ase, the pthread ontained within the tuple is restartedas a slave thread, and when the appli ation has ompleted its exe ution y le, the thread of ontrol is returned to the master thread. In the ase of either event type o urring, the ur-rent event is stored as a global variable for the duration of the exe ution of the appropriatemethodology.Emulation transparen y is maintained as both the behaviour of intera ting hardware de-vi es and the timing of any behaviour is aptured within this model . Further detail of thebehavioural intera tion and transparen y is outlined in se tions 4.3.5 and 4.4.1 of hapter 4.1p l. s.u la.edu/proje ts/glomosim, www.opnet. om75

3.6. The Composition of a PiCSE Instantiation

Figure 3.2: Con eptual ar hite ture showing layers within a generi instantiation of thePiCSE framework3.6 The Composition of a PiCSE InstantiationThe framework supports three levels of modelling: the reation of simulated models only,emulated appli ations only and both together. Figure 3.2 represents a on eptual ar hite -ture apturing the most generi instantiation of the framework involving both simulated andemulated entities. The purpose of this is to have a frame of referen e when dis ussing theintera tion of omponents between these layers. The following on eptual layers are identi�edand now des ribed from the bottom up.The PiCSE Core LayerThe PiCSE_Core provides the main fun tionality required to support and manage all instan-tiations of the PiCSE framework. This in ludes, amongst others, an event list, a s hedulingAPI, an event manager, an obje t manager, a thread manager, and a network simulation omponent. The fun tionality here is provided by omponents within the PiCSE_Core lass ategory, and are dis ussed in detail in se tion 3.5.The Simulated Models LayerThe layer dire tly above the PiCSE_Core is the Simulated_Models layer. Classes withinthis layer are either derived from the abstra tions provided within the PC_Abstra tions lass ategory or are domain-spe i� models derived from the Abstra t_Interfa es lass ategory.76

Chapter 3. The PiCSE Framework Ar hite tureSimulated models from a typi al pervasive omputing s enario would in lude sensors, a -tuators, a model of the environment and domain-spe i� models. These intera t with thePiCSE_Core to s hedule events, thus driving the simulation. They an also intera t in-dire tly with other simulated obje ts through the spe i� ation of both physi al and logi aldependen ies, whi h are des ribed in detail in hapter 4.The Emulated Interfa es LayerThe Emulated_Interfa es layer is the next on eptual layer and is required when appli ationsform part of the modelled s enario. This layer sits between the simulated models and appli a-tions and mediates the intera tion between the two. Classes within the Emulated_Interfa eslayer are written to repli ate the behaviour of the native environment in whi h the appli ationwould run and provide the mapping between a real appli ation and simulated models. This an o ur in two situations:1. The �rst situation is when an appli ation has been written to intera t with a hardwaredevi e su h as a sensor. In the ase of a sensor, for example, an appli ation may intera twith the devi e physi ally via a serial able, and logi ally, through the underlying �lesystem of the operating system. In this situation, the simulated sensor must providean emulated interfa e so that the appli ation an read data from it in a parti ularformat. Modelling of these interfa es is performed through instantiation of lasses fromthe PC_Abstra tion lass ategory.2. The se ond o urren e is when appli ations are built dire tly upon system alls ormiddlewares, and is shown in �gure 3.2 as the dire t meeting point between the emulatedinterfa es layer and the PiCSE_Core layer. In the ase of a middleware providingnetworking fun tionality, the emulated interfa es layer provides a mapping betweenthe appli ation's alls to the middleware and the framework's network simulator. Alibrary ontaining mappings of ommon system alls is provided in the PiCSE_Core lass ategory, and users an instantiate their own appli ation spe i� mappings usingabstra tions provided in the PC_Abstra tion lass ategory.77

3.6. The Composition of a PiCSE InstantiationAs noted above, it is possible to reate instantiations of the framework without appli ations.It is even possible to reate instantiations of the framework that in lude appli ations andare built without emulated interfa es. But in these ases, the appli ation must be at leastpartially re-written to use the PiCSE APIs to a ess the simulated models.The Appli ation LayerThe �nal layer is made up of appli ations that are used within the s enario. The appli a-tions an transparently intera t with hardware devi es, middleware or the emulated operatingsystem through the Emulated_Interfa es layer. Appli ations are used as they would be inthe native environment, i.e. without hange and are ompiled into a PiCSE instantiation.Certain limitations exist that restri t the lass of appli ations that an be run within PiCSE,and these limitations are explored later.3.6.1 Minimum Requirements for a PiCSE InstantiationThere exists a set of minimum requirements for an instantiation of the framework. Theframework supports the dual fun tionality of simulation and appli ation emulation, ea h ofwhi h addresses the modelling of separate, yet inter-dependent, aspe ts of pervasive omputings enarios. It may be more helpful though to imagine the framework overing these twofun tionalities and the wide span between them. A typi al pervasive omputing s enario would ontain elements of both simulated and emulated omponents. However, at the boundariesof this supported span are instantiations of the framework where only simulated entities oremulated appli ations are required. The framework enfor es no restri tions or dependen ieson the number of instantiations of simulated and emulated models. Regardless of whether thes enario being modelled requires simulated or emulated elements, or both, an instantiationof the PiCSE_Core is required. The provision of the PiCSE_Core that is reused in allvariations of PiCSE instantiations partially address R5, the reusability requirement.78

Chapter 3. The PiCSE Framework Ar hite ture

Figure 3.3: Con eptual diagram of a PiCSE simulation in Algorithm ModeAlgorithm ModeIn instantiations with only simulated models, models are reated of the hardware devi es,the environment and additional domain-spe i� obje ts (or a subset of these three). As thereare no appli ations to intera t with these devi es, the obje ts an only intera t amongstthemselves. An API exists, within the lass de�nitions of the key abstra tions, that allowsother simulated models to query the sensors as simulated obje ts, although not through anemulated interfa e that an appli ation would typi ally use.Within the ontext of the use of the PiCSE framework, this is depi ted in �gure 3.3.This is so alled as typi ally a new obje t is introdu ed that implements an algorithm, thatintera ts with the hardware devi es and the environment. The in lusion of an algorithmobje t is not ne essary, but a simulation of hardware devi es and the environment on theirown, without any intera tion, is not very interesting! New lasses that implement algorithmsare reated using interfa es and abstra t lasses from the Abstra t_Interfa es lass ategoryand not from the PC_Abstra tion library.Appli ation ModeAt the opposite end of the supported spe trum are instantiations of the framework in Appli a-tion Mode2. In Appli ation Mode, shown in �gure 3.4 , appli ations use an emulated interfa e2No hanges have to be made or parametrised within the framework to a hieve the di�erent modes of use.The on ept of di�erent modes is purely on eptual and merely re�e ts instantiations reated with or without ertain abstra tions. 79

3.6. The Composition of a PiCSE Instantiation

Figure 3.4: A PiCSE instantiation in Appli ation Modeto intera t with the PiCSE ore. In this mode, there are no simulated models to intera t with,however the networking simulation fun tionality of the PiCSE_Core is available, allowing ap-pli ations to ex hange messages through the simulator. The Appli ation Mode is highlightedmerely to show that the framework supports the emulation of appli ations independently ifrequired.3.6.2 PiCSE Instantiations as Sub-FrameworksThe framework plays two di�erent roles: The primary role, as outlined in Chapter 1 is to reate simulations through the instantiation of the framework, whilst the se ondary role ofthe framework is that it an be used to instantiate domain-spe i� simulators whi h areframeworks in their own right. These an then be used to instantiate simulations for aparti ular sub-domain of pervasive omputing.The many domains of pervasive omputing, su h as ambient omputing, ontext-aware omputing, and smart spa es, ea h have their own modelling requirements, su h as the s aleand type of environment to be modelled and the various hardware omponents found withinsu h environments. Take for example, an intelligent transportation system (ITS) s enario.The required simulated models for this s enario might in lude the following:• GPS and indu tive loop sensors• Road network environment• Tra� light a tuators 80

Chapter 3. The PiCSE Framework Ar hite ture• Vehi lesIt is entirely feasible to reate an instantiation of the framework to model this s enario. Thisis in itself the primary role of the PiCSE framework. However, a single instantiation of theframework is restri ted by the fun tionality of that instantiation. For example, the vehi le be-haviour may be �xed or the behaviour of the tra� lights ould be �xed. Di�erent developers,that wish to evaluate separate appli ations within this domain, should be a ommodated. Oneappli ation might be examining the use of GPS sensor data in maximising vehi le throughput.A se ond appli ation might look at using the same sensor data to provide ollision avoidan esoftware within the vehi les. In these ases, it makes sense to allow users to instantiate thePiCSE framework to reate an intermediary framework that may be then instantiated to theindividuals requirements. The result of a PiCSE instantiation in this ase is not a simulation,but a framework allowing other developers to reate their own ITS simulations. The PiCSEframework is �exible enough to allow multiple appli ations with di�erent requirements to runwithin one simulation, should su h a s enario be required by a developer. This is a signi� antstep towards a hieving the requirement of R1 and R2, the requirements relating enabling the�exible simulation and emulation of multiple elements of heterogeneous pervasive omputingdomains.From an implementation point of view, the PiCSE_Core omponents remain the same.A new lass ategory of abstra tions and on rete lasses, that are spe i� to the ITS do-main, are reated using instantiations and derivations from the PC_Abstra tions and theAbstra t_Interfa es lass ategories. Abstra tions of this new lass ategory are then instan-tiated to reate individual on rete simulations. The ability to reate new frameworks fromthe PC_Abstra tions and the Abstra t_Interfa es lass ategories ontributes to meetingrequirement R4, the extensibility requirement.3.7 Supported Abstra tionsThe �generalised� PiCSE instantiation that is presented in se tion 3.6 has provided an intro-du tion to the general ategories of omponents that PiCSE supports. These are formalised as81

3.7. Supported Abstra tionsabstra tions within the PiCSE framework, whi h an be partitioned into three separate lass ategories. The PC_Abstra tions and the Abstra t_Interfa es lass ategories meet PiCSE'smodelling requirements and are now introdu ed in the following se tions 3.7.1 and 3.7.2. The�rst se tion explores the abstra tions required to support the modelling of the �physi al� as-pe ts of pervasive omputing, su h as an environment or a sensor. The se ond subse tionintrodu es models that abstra t the �software� omponents, the appli ations and middlewarethat might exist within the modelled domain. The abstra tions presented in these se tionsform the basis upon whi h the PC_Abstra tions are built whi h satis�es requirements R1,R2, and R3, the requirements for �exible heterogeneity.The implementation and intera tion of these omponents is explored in greater detail in hapter 4 and validated in hapter 5, whilst their integration in the overall PiCSE ar hite turehas been introdu ed in se tion 3.5.3.7.1 Supporting the Modelling of the Physi al Pervasive ComputingComponentsThe PiCSE framework is based on the dis rete event simulation formalism. In this formalism,a simulated event is de�ned as something that o urs at a parti ular dis rete time withina simulation. It is the o urren e of these events, the orresponding state hanges, andsubsequent hanges to the event list that make up an entire simulation instan e.All physi al abstra tions within the PiCSE framework are derived from the Simulatedabstra tion. This means that they an all produ e, s hedule and pro ess events during theexe ution of a PiCSE instantiation. An instantiation of a �physi al� abstra tion an s hedulean event to o ur at a spe i�ed interval in the simulated future. When this time is rea hed,the event instan e is dispat hed, and the instantiation, to whi h the event belongs a knowl-edges the event and performs some a tion. The Simulated abstra tion enables this eventpro essing to o ur at spe i� instantiations of �physi al� omponents, and these instantia-tions are required to implement a simple event pro essing fun tion ::doEvent( Event ) thatis invoked when the s heduled event o urs.In PiCSE, an Event is de�ned lo ally, i.e. events are spe i� to a parti ular type of entity,82

Chapter 3. The PiCSE Framework Ar hite tureand the same event for a di�erent entity may have a di�erent meaning, and may result indi�erent behaviour. In pra tise, they are represented simply as enumerated types, and a singleenumerated list is usually spe i�ed per instantiation of a physi al abstra tion.The Obje t lassSeveral key abstra tions have been identi�ed that are present to various degrees in manypervasive omputing domains. These in lude sensors, a tuators, and other domain-spe i� obje ts, su h as a vehi le in the ase of an ITS s enario, or a mobile node in the WSN domain.The most ommon attributes of these have been aggregated into the Obje t abstra tion.Lo ationAll instan es of the Obje t abstra tion have a lo ation, whi h an be either expli it or impli it.An Obje t instantiation with an expli it lo ation is an Obje t that is independent of otherObje t instan es. That is, it either exists by itself or it is in ontrol of its own lo ation.Alternatively, an Obje t an have an impli it lo ation. In this s enario, the obje t's reallo ation is the lo ation of another obje t with whi h it is physi ally asso iated.This an o ur through the feature of obje t ollo ation: a feature that supports the reation of omplex obje ts, through the aggregation and asso iation of instan es of spe- ialisations of ertain abstra tions. In the ase of the Obje t abstra tion, it is possible toasso iate physi al obje ts with ea h other using the ::addObje t(Obje t* b) method of theObje t abstra tion. The result is that the �added� Obje t instan e (b from above) assumesthe lo ation of the Obje t to whi h it was added. This frequently o urs in s enarios, inwhi h an Obje t, su h as a sensor, is arried by a user. The sensor's lo ation is impli itlythat of the person holding it, for example, a vehi le arrying a GPS devi e. Figure 3.5 is aUML sequen e diagram that outlines the intera tion between a �robot obje t� and a ollo- ated �sensor obje t�. As the robot moves, ea h ollo ated obje t is noti�ed of the movementand updated its own position internally, and noti�es any other referen es to that lo ation.EntityLayer instan es, whi h are mentioned in the diagram are a method for referring anda essing physi al obje ts and are dis ussed in detail in hapter 4.83

3.7. Supported Abstra tions

Figure 3.5: UML Sequen e diagram depi ting ollo ated obje ts s enarioSeveral related abstra tions to the Obje t lass are also provided. A Mobility_Obje tis an abstra tion that provides mobility patterns, su h as the random walk (Camp 02) andrandom way-point patterns, that are ommon in the simulation of wireless sensor networks.By impli ation, any Obje t instan es that are �added� to a Mobility_Obje t instan e wouldalso move a ording to that mobility pattern.Sensor and A tuator abstra tions are also provided. Within the PiCSE framework, theSensor abstra tion is provided to model a physi al sensing devi e, i.e. a devi e that anmeasure a physi al phenomenon modelled within a PiCSE instantiation. As an obje t, it hasa lo ation, and that lo ation an be used to sense an asso iated physi al phenomenon at a ertain point. A Sensor instantiation an a t periodi ally or sporadi ally, and may be queriedusing the ::getState() method. An invo ation of this method impli itly uses the sensor'slo ation to query the asso iated sensed physi al phenomenon at that lo ation.Similarly, an A tuator an �a�e t� the state of a physi al phenomenon at a ertain lo- ation. It has a lo ation, whi h again may be expli it or impli it, and an also generateevents. A user of the PiCSE framework is required to de�ne the e�e t that an A tuator an have on the asso iated physi al phenomenon by implementing a ::setState( void* )method. Lo ation-based a tuation on physi al environmental phenomenon is supported, aswell as a tuation upon other Obje t instan es.84

Chapter 3. The PiCSE Framework Ar hite turePhysi al DomainsAll instan es of the abstra tions introdu ed in se tion 3.7.1 are omponents of an overallmodel that aptures a parti ular pervasive omputing domain. The modelling of the physi alaspe ts of the domain in ludes the apturing of many physi al attributes su h as measurableand manipulable environmental phenomenon, additional domain-spe i� features that mayimpa t upon a model, and the obje ts themselves.For example, a typi al model of the domain of a smart spa e s enario may apture a user,any sensor that a user or appli ation may utilise, a representation of a room or a building,and any physi al phenomenon that the sensor may be measuring. If a user is to evaluate theperforman e or behaviour of the appli ation, then a realisti model of the appli ations inputs(i.e., the physi al phenomenon measured by a sensor) and outputs is required. Furthermore itis not possible to apture a building, or a road in the ase of ITS s enarios, in an abstra tionas broad as an Obje t.To model the physi al aspe ts of a domain, a new abstra tion, Layer, is introdu ed.The Layer abstra tion, and the related abstra tions Environment_Layer and Entity_Layer, an be spe ialised to reate models that support the �exible modelling of physi al aspe ts ofpervasive omputing domains that annot ne essarily be aptured by the abstra tions alreadyintrodu ed above. The Environment_Layer abstra tion an be used to apture environmentaland spatial physi al phenomenon whilst Entity_Layer abstra tions an be used to aptureobje ts that exist within those environments. These abstra tions are explained in furtherdetail in hapter 4.Modelling physi al phenomena using an extensible and �exible design is non-trivial giventhe wide range of phenomenon and environments en ountered in pervasive omputing. TheLayer abstra tion itself aptures only the most general aspe ts of a domain, leaving the userwith the task of building omplex models through spe ialisation. In general however, a singleinstan e of a Layer abstra tion is used to apture a single physi al aspe t of a modelleddomain. Con eptually, a layer is a 3-D grid of �xed size that maps onto the s enario beingmodelled. Layer instantiations are 2-D by default, but an support the third dimensionof physi al height. In addition to the physi al x and y dimensions of the spa e, ea h layer85

3.7. Supported Abstra tionsinstantiation is parametrised with the granularity of the grid within the layer. The granularityof a �spa e� within the grid an be arbitrarily large or small and o�ers an additional degreeof �exibility in the instantiation of the abstra tions. The APIs that are provided to interfa eto the Layer exploit the dis retisation transparently.Even greater �exibility and omplexity are a hieved through the use of the layer sta k.This is a representation whereby multiple layers representing individual physi al aspe ts ofthe simulated domain are logi ally ollo ated and threaded together to build models thatmay be dependent on more than one phenomenon. This olle tion of layers is the entirerepresentation of the domain being modelled, even though individual layers only apture asingle phenomenon.The intera tion of both the Sensor and A tuator abstra tions, with their asso iated phys-i al phenomenon, is aptured within the API of the Entity_Layer and Environment_Layerabstra tions. In addition, instan es of the Entity_Layer abstra tion are used internally tooptimise the performan e of PiCSE, through the management of existing Obje t instan esthat a user may de�ne.3.7.2 Supporting the Modelling of the Soft Pervasive Computing Abstra -tionsPiCSE provides three main abstra tions for supporting the integration of �soft� pervasive omputing aspe ts. The Appli ationWrapper abstra tion is used to integrate ode fromappli ations into a PiCSE instantiation. The Exe utionEnvironment abstra tion is providedto emulate the environment in whi h the appli ation originally would have been exe uted.Finally, the Net_Interfa e abstra tion an be instantiated to a ess PiCSE's basi networksimulator.The Appli ationWrapper abstra tion provides a wrapper that an be used to en apsulatean instan e of an appli ation. With some restri tions, it is possible to integrate appli ationsour e ode into a PiCSE instantiation without modi� ation, allowing the sour e ode tointegrate with the simulated models introdu ed in se tion 3.7.1. This is a hieved through theinstantiation and asso iation of an Exe utionEnvironment abstra tion.86

Chapter 3. The PiCSE Framework Ar hite tureThe Exe utionEnvironment may be viewed as either an emulated operating system oran emulated middleware, depending on the user's implementation. It supports multiple ap-pli ations in the form of Appli ationWrapper instantiations, and also multiple simulatedhardware devi es, su h as Sensor and A tuator instan es, that may be asso iated with theappli ation.Communi ation is an important aspe t of many pervasive omputing s enarios, andmany appli ations and middleware systems implement some sort of ommuni ation paradigm.PiCSE provides the Net_Interfa e abstra tion to address this. The abstra tion an be in-stantiated to implement both wired and wireless ommuni ation. Appli ations an use aNet_Interfa e abstra tion, via an instantiation of their asso iated Exe utionEnvironmentto broad ast or uni ast messages a ross either a simulated wired or wireless network, andmultiple network interfa es are supported.3.8 Emulation support within PiCSEAppli ation ode that an intera t with sensors and a tuators form an important part of thepervasive omputing domain. It is a ommon, but an ine� ient pra tise, that this ode is typ-i ally written on e for the simulation of a parti ular domain and is then rewritten at the timeof a tual deployment. This o urs be ause most simulators do not provide an API for the ap-pli ation being developed. PiCSE addresses this issue by providing the Appli ationWrapperand Exe utionEnvironment abstra tions introdu ed previously. This se tion addresses howPiCSE supports this important fun tionality and thus meets some of the framework's mostimportant requirements. Two aspe ts of the overall ar hite ture that are worth highlightingare how spe i� ally the framework supports emulation at the level of an individual appli ation,and se ondly, how the framework supports the emulation of many appli ation instan es.3.8.1 Enabling EmulationThe following hara teristi s of appli ations deployed in pervasive omputing environmentsare noted. Typi ally, they 87

3.8. Emulation support within PiCSE

Figure 3.6: A split level implementation of the PiCSE support for emulating appli ations• May intera t with hardware devi es su h as sensors and a tuators.• May ommuni ate with peers, servers and other devi es, using a wired or wireless net-work.• May be built upon middleware, that provides the above fun tions, or may a ess theseservi es dire tly using low level system alls.In the ase of PiCSE, the hardware devi es are implemented as instantiations of the abstra -tions introdu ed in se tion 3.7.1, and an API is provided to model the wired and wireless ommuni ation. Where e�e tive emulation is required, it is imperative to maintain the APIsupon whi h the appli ation is developed, whilst seamlessly intera ting with the simulatedmodels. The appli ation believes (and behaves as if) it is intera ting with real hardwaredevi es, when it is a tually intera ting with instantiations of the PiCSE abstra tions.PiCSE a hieves this using a split level design illustrated in �gure 3.6. The appli ation isintegrated into the framework using the Appli ationWrapper abstra tion. The API of thePiCSE_Core exists at the base level and provides an interfa e to all instan es of the �phys-i al� abstra tions, su h as the sensors and a tuators, as well as the remainder of the PiCSE88

Chapter 3. The PiCSE Framework Ar hite turefun tionality. An instantiation of an Exe utionEnvironment abstra tion exists between thePiCSE ore and appli ation levels, and mediates the intera tion between the appli ation andthe ore. This Exe utionEnvironment instantiation must �bind� the alls from the appli a-tion's original API to the orresponding fun tionality within the PiCSE_Core. The libraries,middleware or system alls, upon whi h the appli ation is based, have to be rewritten in orderto a hieve this su essfully. An instantiation of the Exe utionEnvironment abstra tion playsthis role. Using this methodology, PiCSE is in fa t transparent to the appli ation.Although this approa h requires some overhead in implementing theExe utionEnvironment instantiation, it is envisaged that these �bindings� will onlyhave to be written on e per appli ation type and that over time a library of ommonre-usable bindings an be produ ed, i.e. one binding for the TinyOS API, one binding toimplement Linux system alls and so on. When a binding already exists for a ommonplatform, it will be possible to integrate appli ations dire tly into PiCSE instantiations usingonly an Appli ationWrapper instantiation, whi h requires signi� antly less implementatione�ort. The split-level design partially satis�es requirement R4, software extensibility as itallows new software platforms to be integrated into the PiCSE framework in the future.3.8.2 The Physi al Ar hite ture for Emulated Appli ationsAn entire instantiation of the PiCSE framework onsists of instantiations of the abstra tionsintrodu ed in se tion 3.7, instantiations of abstra tions derived from the Abstra t_Interfa es lass ategory all supported by a single instantiation of the PiCSE_Core. All of the afore-mentioned lass ategories and abstra tions are implemented as libraries of C++ lasses.Emulated appli ations in the form of sour e ode, whi h must meet ertain requirements thatare now outlined, are ompiled and linked into the libraries.A point to note is that the pro ess of appli ation emulation begins with the ommand to ompile the exe utable. As the appli ation ode is unmodi�ed, alls within the appli ationto ertain methods must be inter epted. If they are not, then the ode will ompile and linkagainst the appli ations original libraries. By using ertain �ags, the ompiler is redire tedto the emulated versions of the appli ation's libraries. The linker ompletes the pro ess89

3.8. Emulation support within PiCSEof binding the appli ation alls to the emulated fun tionality of an Exe utionEnvironmentinstantiation.PiCSE provides support for the emulation of appli ations with ertain hara teristi s. Themain requirement is a tually that the appli ation intera ts with the underlying operating sys-tem or a middleware in some way. Sin e one of PiCSE's requirements is that appli ation odeis unmodi�ed, the framework exploits the appli ation's alls to the operating system or tothe middleware as an opportunity to redire t the appli ation. Ironi ally, simple appli ationswhi h have no intera tion with libraries or the underlying operating system are also not suit-able, as there is no easy way of ontrolling their exe ution without modifying the appli ation ode itself. Te hni ally PiCSE an support su h an appli ation provided that it will eventu-ally exit, but in any ase, an appli ation su h as this would not a tually be doing anything�interesting�, sin e it has no inputs or outputs.There are some limitations to the approa h that has been implemented. In order tomaintain �ne-grained ontrol over the exe ution of an appli ation, it was hosen to not usean o� the shelf virtual-ma hine based approa h but instead to modify libraries that theemulated appli ations have been built on so that they an intera t with the PiCSE simulationenvironment. If an appli ation has been built upon a library that has not yet been extended,then that appli ation annot be emulated with an experiment.At present, no threading libraries su h as the POSIX library have been ported for in lusionin the PiCSE ar hite ture and as a onsequen e, emulation of multi-threaded appli ationsis not yet supported. In reimplementing part of a library su h as the POSIX library, amapping would have to be provided between the s heduling fun tionality of the library to the orresponding fun tionality within the PiCSE ore ar hite ture. The ported library wouldhave to provide an API that supported the s heduling, exe ution, essation and interruptionof appli ations that would be built upon that library. However, �ne-grained ontrol of theindividual threads would not ne essarily be required for PiCSE to be able to support multi-threaded appli ations.The same level of appli ation ontrol that is required for multi-threaded appli ationswould be required when exe uting distributed simulation experiments, albeit at a more ourse90

Chapter 3. The PiCSE Framework Ar hite turelevel of ontrol. In addition to this, the distributed nature of the simulation would requirethe in lusion of a oordinating omponent at the ontrol level that provided and managedthe fun tionality to identify node simulators ompeting and a essing on�i ting resour eswith an experiment. In addition, this omponent would have to provide the fun tionality topotentially resolve any arising on�i ts, typi ally using a rollba k feature whereby a remotenode simulator ould roll ba k its simulation to a previous state. On the node simulator side,this would require the implementation of a omponent that ould store a series of rollba kstates, whi h would be subsequently released by the oordinating simulator when no on�i tshave been identi�ed. There is extensive literature (Fujimoto 00) on the suitability of extendingDEVS-based simulators to distributed environments, a primary reason why a DEVS-orientedapproa h was originally adopted, however this fun tionality and omponents have not beenbuilt into the urrent implementation of the PiCSE simulation framework.3.8.3 Supporting Multiple Appli ationsPiCSE is based upon the dis rete event simulator paradigm, but appli ation emulation andexe ution does not lend itself naturally to this model. A dis rete event simulator exe utes asqui kly as possible, and individual events take zero 'simulated time' to exe ute. Appli ations,both real and simulated, do however take time to exe ute, and it is di� ult to ontrol theexe ution of appli ation instru tions in a ontrolled manner, so that the exe ution of dis retemodel events and the exe ution of the appli ation's instru tions are orre tly ordered. Infa t it is very di� ult without ontrolling the individual exe ution of the instru tions formingthe appli ation and having knowledge of the time taken to omplete ea h instru tion. Thisapproa h is known as �binary translation� and is very umbersome. An alternative software-based approa h is possible in ases where the appli ation sour e ode is available. The abilityto support multiple appli ations, developed independently ontributes to meeting require-ments R2 and R3, the two requirements relating to the support for the �exible integration ofemulated software elements. This approa h is now dis ussed in se tion 3.8.3.91

3.8. Emulation support within PiCSEDis retising an Appli ationOne of PiCSE's main requirements is that no modi� ations are made to emulated appli ationsand therefore all ontrol of the appli ation's exe ution must o ur outside of the appli ationitself. It is possible to dis rete-ise the exe ution of the appli ation. The exe ution of a series ofinstru tions omprising a part of an appli ation would o ur at a dis rete point in simulatedtime, and would therefore take zero time to omplete. PiCSE makes this assumption andthus allows appli ations to be adapted transparently to an exe ution y le that is suitable forexe ution within a dis rete event simulator.In pra tise this means that an appli ation starts or resumes its exe ution whenever anevent o urs that should normally trigger the appli ation's exe ution. When the appli ationrea hes the end of its urrent exe ution y le, for example, it pauses its exe ution while wait-ing for another event or perhaps invokes the system all sleep(int se onds), the pro essingof the event list and the advan e of other simulated events then resumes. The PiCSE frame-work provides fun tionality to ontrol the exe ution, pausing, and resumption of emulatedappli ations. It does this in a transparent manner from the appli ation's perspe tive. How-ever, this omes at the expense of a urate modelling of the time taken for the program toexe ute. PiCSE makes attempts to alleviate this problem, allowing a �pause� to be introdu edtransparently into an appli ation's exe ution, thus slowing down the emulated exe ution ofthe appli ation. The result is that the net simulated-time taken for a series of instru tions tobe exe uted an be modelled orre tly, if that time taken to exe ute those instru tions in reallife an be measured. So if for example, a set of instru tions has been measured to take 5msto exe ute in real life, PiCSE will exe ute these instru tions in 0ms (i.e., a dis rete event),but an then model a pause of 5ms before the next instru tion is exe uted.The ability to approximate the total time taken to exe ute an aspe t of a programs fun -tionality ombined with a similar level of �ne-grained ontrol of other time-related aspe ts ofthe domain su h as hardware events and domain-spe i� events goes towards addressing these ondary hallenge identi�ed in hapter 1 of a urately modelling the timeliness requirementsof pervasive omputing appli ation domains. 92

Chapter 3. The PiCSE Framework Ar hite tureExe uting Multiple Appli ationsA multi-threaded approa h is implemented to support this feature of PiCSE. Appli ations areexe uted within their own thread, whose exe ution is ontrolled from within the simulator.A master-slave thread implementation ontrols the swit hing between threads. The masterthread manages the pro essing of the event list, thus advan ing the overall simulation, andalso manages the exe ution of the slaves and the appli ations.The PiCSE event list and event s heduling me hanism is modi�ed to allow for di�erentevent types. These types in lude Model_Events, Thread_Begin events and Thread_Swit hevents. All event type o urren es are treated dis retely, i.e. they take no simulated timeto o ur. When an event of type Thread_Swit h o urs, the master thread restarts theappropriate slave thread (whi h is the appli ation), and immediately relinquishes its ownthread of exe ution. It is the appli ation's asso iated Exe utionEnvironment instan e thatultimately relinquishes ontrol ba k to the master thread.Although there may be multiple appli ations (and orresponding threads) in the simu-lator, there is only ever a single thread being exe uted at any one time. The PiCSE_Coreexploits the thread's apabilities merely to retain ontrol of the exe ution of an appli ation,in order to a hieve a dis rete exe ution of the appli ation, and not to a tually have multiplethreads or appli ations exe uting on urrently. At present, only appli ations written in C++(Stroustrup 98) have been emulated. The sour e ode of the appli ation is ompiled into thesimulator to make a single program. In addition to this, only single threaded appli ationsare supported at present. In order to enable the emulation of multi-threaded appli ations,the pthread library will have to be partially ported, so that the underlying thread s hedulingbehaviour does not interfere with the threading me hanism of the PiCSE_Core.3.9 Experimental SupportThe well known Observer design pattern (Gamma 95) is supported within the PiCSE frame-work and is implemented by all of the abstra tions that are provided to model the �hard�aspe ts of pervasive omputing domains. This design pattern is exploited by the PiCSE93

3.10. Summaryframework to provide a Logger abstra tion that eases and supports the task of logging �eventsof interest� and results during the ourse of a simulation's exe ution.Several derived abstra tions su h as the Environmental_Layer_Logger,Entity_Layer_Logger and Obje t_Logger are also provided, all of whi h provide log-ging fun tionality but for di�erent sour es of interest. Con rete instan es of the Loggerabstra tion an subs ribe to events s heduled by instan es of the Simulated abstra tion,su h as Sensor and A tuator instantiations, and are noti�ed when these events o ur. Are ording of the event and any additional parameters required is then written to a �at text�le. Instan es of the Logger abstra tion an be additionally parametrised using the followingtwo methods:1. The method ::setPeriod(int period) is used to request periodi logging of someaspe t of a simulated domain, irrespe tive of when events of interest may o ur.2. The method ::setLoggingWindow (int time2start, int duration) is used to de�nea period of interest within an experiment. This is useful for experiments in whi h thereis a boot-strapping period and logging during this period is not required. A trigger analso be used to de�ne the time at whi h to begin logging if it is not known at the timeof instantiation.3.10 SummaryThis hapter introdu ed and derived the requirements that guided the design of the PiCSEframework. The ar hite ture of the PiCSE_Core, the underlying infrastru ture that supportsall instantiations of the PiCSE framework, was explored. The main abstra tions supportedby PiCSE were then introdu ed. These were divided between abstra tions that supportedthe modelling of the physi al aspe ts of a pervasive omputing s enario, and abstra tionsrequired to support the appli ations emulated within that s enario. A further examinationwas then provided of the framework's support for emulating appli ations that exist within thesimulated appli ation s enarios. 94

Chapter 4Modelling the Key PervasiveComputing ComponentsThis hapter des ribes the PC_Abstra tion lass ategory, whi h provides all abstra tionsrequired to reate an instantiation of the PiCSE framework. This hapter begins by exam-ining the relationships of the omponents and their role within a PiCSE instantiation. The omponents themselves, their �exibility and suitability for supporting the modelling of the omponents and their implementations are then addressed individually.4.1 The PC_Abstra tion lass ategoryThe PC_Abstra tions lass ategory provides a set of abstra t lasses that an be instanti-ated to meet the modelling requirements of the omponents identi�ed to be ommon a rosspervasive omputing s enarios. It is intended that developers instantiate lasses from this ategory, or reate new lasses using inheritan e where required. Dependen ies between in-stan es of these lasses are then modelled to reate more omplex instantiations. Theseinstantiations intera t with a single instantiation of the PiCSE_Core to form an exe utablesimulation. Alternatively, developers may reate more spe ialised abstra tions reating theirown framework, that may itself be instantiated for a parti ular pervasive omputing domain.In relation to the logi al ar hite ture presented in hapter 3, instantiations of abstra tions95

4.1. The PC_Abstra tion lass ategory

Figure 4.1: The lo ation of the PC_Abstra tion lasses within the logi al ar hite ture.from this lass ategory are found in both the Simulated_Models and the Emulated_Interfa eslayers, as shown in �gure 4.1. The lasses within this ategory provide the abstra tions for thesimulated models and also abstra tions enabling the emulated appli ations to be run withininstantiations of the framework. As su h, this lass ategory an be separated into two partsaddressing separate requirements R1, R2, and R3 introdu ed in hapter 3.• R1 The framework should support the �exible simulation of the heterogenous hardwareelements of pervasive omputing s enarios. This is provided by reating ustomisableabstra tions representing physi al aspe ts of the s enarios su h as the environment, aswell as hardware devi es su h as sensors and a tuators.• R2 The framework should support the emulation of real- ode appli ations developedfor pervasive omputing. These appli ations may be built upon middleware that shouldalso be supported.• R3 The framework should mediate the �exible intera tion of any simulated and emu-lated elements forming the simulation of a pervasive omputing appli ation.Five abstra tions are des ribed in this hapter and these an be broken into three logi- al ategories: obje ts, the environment, and appli ation environments. Both obje t- andenvironment-related abstra tions are lo ated within the Simulated_Models Layer in the logi- al ar hite ture, and the implementation of these addresses requirement R1. The appli ation96

Chapter 4. Modelling the Key Pervasive Computing Components

Figure 4.2: Obje ts instantiated from the PC_Abstra tion lass ategory are pre-de�ned tointera t using ertain methods.environment abstra tions support instantiations from the Emulated_Interfa es Layer and theimplementation of these address requirement R2.Figure 4.2 shows the typi al simpli�ed intera tion of instantiations of these omponents.As outlined in hapter 3, the support for these instantiations is provided by the underlyingPiCSE_Core lass ategory. In hapter 2, the ommon intera tion patterns of these om-ponents were identi�ed, and the design and implementation of the abstra tions re�e t therequirements of meeting these intera tion patterns. In this hapter, the features of note, the ommonalities and the intera tion patterns identi�ed in hapter 2 are addressed as they applyto ea h of the �ve abstra tions.4.2 Exe utionEnvironmentsThe Exe utionEnvironment abstra tion supports the emulation of the environment in whi han appli ation would normally exe ute. The abstra tion supports appli ations that are builton API's of the underlying platform, and also appli ations built on middleware instan es thatabstra t these underlying platforms. The abstra tion onsists of two parts. It supports thebuilding of libraries that provide a ess to the modelled hardware devi es within a PiCSEinstantiation. Se ondly, the abstra tion supports the reation of an API, upon whi h ap-pli ations an be built, allowing the appli ations to intera t seamlessly with the modelleddevi es.The abstra tion also supports the modelling of the networking fun tionality of an op-97

4.2. Exe utionEnvironmentserating system or middleware platform, through the networking interfa e provided by theNet_Interfa e abstra tion. The following requirements exist amongst all exe ution environ-ments.• An Exe utionEnvironment abstra tion an intera t with simulated hardware devi es,in the form of instantiations of the Sensor, A tuator and Obje t abstra tions. Theabstra tion must also support the intera tion of the Exe utionEnvironment with theunderlying PiCSE_Core.• The Exe utionEnvironment abstra tion must provide the interfa es required by theappli ation, so that the ode of appli ations an be preserved without hange. Thisallows seamless emulation of the appli ation behaviour.• The role of any Exe utionEnvironment instantiation is to mediate the intera tion ofthese two interfa es.Split-Level API ImplementationThe mediation between the di�erent interfa es is a hieved logi ally using the split-level APIapproa h that was des ribed in 3.8.1 of hapter 3. The Exe utionEnvironment abstra tionsupports the instantiation of the middle layer, whi h is termed the Repla eable EmulationUnit. This middle layer binds method invo ations from the appli ation, through the API tothe orresponding methods within the PiCSE instantiation. One method of doing this is torewrite partially the libraries on whi h the appli ation has been developed. Using this method-ology, the PiCSE instantiation, and all simulated models in luding the hardware devi es, theenvironment, and the network, are all transparent to the appli ation.The Repla eable Emulation Unit only has to be written on e to enable the emulationof a family of appli ations. For example, one instantiation of the Exe utionEnvironmentabstra tion is required to reate a TinyOS_Exe utionEnvironment that would enable theemulation of all TinyOS appli ations. Similarly, one instantiation would exist for the ContextToolkit middleware and so on. 98

Chapter 4. Modelling the Key Pervasive Computing ComponentsThe mediation of the two interfa es is supported within the Exe utionEnvironment ab-stra tion by another abstra tion of a �le, alled PFile. The Exe utionEnvironment abstra -tion supports a olle tion of these, that an be addressed by a key (analagous to a �lesystempath) providing an abstra t model of a �lesystem. Both appli ations and hardware devi es an read and write to these PFile instantiations, that an a t as a logi al bu�er between thehigher level (appli ations) and the lower level (hardware devi es).Appli ation Intera tionAppli ations are supported in the Exe utionEnvironment abstra tion through theAppli ationWrapper lass. The wrapper lass allows appli ations to be asso iated with asingle Exe utionEnvironment, and allows the Exe utionEnvironment to s hedule the initial-isation of the appli ation using the ::s heduleExe ution(long int t) method.Hardware Intera tionModels of hardware devi es are integrated into the Exe utionEnvironment abstra tion usingtheir Emulated interfa e. This interfa e will be introdu ed in more detail in the follow-ing se tions des ribing the Sensor and A tuator abstra tions, but very brie�y, it providesan interfa e allowing an Exe utionEnvironment instan e to intera t with an instan e of asimulated hardware devi e. From the Exe utionEnvironment perspe tive, ea h Emulatedinterfa e an be hooked into a PFile instan e. The Emulated interfa e of a sensor an pusha sensor reading through the PFile interfa e, where it an be read by an appli ation fromthat emulated �lesystem. A similar data �ow o urs in the opposite dire tion for a tuators.Appli ations an write ommands to the PFile interfa e whereby they are pushed to theA tuator instantiation and the resultant simulated a tuation is performed.Network Simulator Intera tion Typi al pervasive omputing appli ations may also ommuni ate with their peers and/or external servi es using wireless or wired ommu-ni ation, or both. Ex luding situations where middleware is used to provide abstra -tions, this is usually performed at the transport layer using known abstra tions, su h as99

4.3. Sensorsa 'so ket'. The Exe utionEnvironment abstra tion provides the Net_Interfa e interfa e,whi h supports this fun tionality. This interfa e allows messages to be sent to PiCSE'sNetwork_Simulation_Manager whi h supports the simulated broad asting and uni- astingof messages a ross wired and wireless networks.Abstra tion LimitationsTheoreti ally, PiCSE supports the emulation of large numbers of these instantiations.No upper limits are pla ed on the number of devi es or appli ations that a singleExe utionEnvironment instantiation an support, and the PiCSE framework itself pla es no onstraints on the number of Exe utionEnvironment instantiations. As des ribed in hapter3, however, ea h appli ation runs within its own thread of ontrol, so the overall number ofappli ations may be onstrained by the number of threads supported by the physi al ma hineused to run the simulation.4.3 SensorsThe Sensor abstra tion is provided as a generi abstra tion of all physi al sensors that an apture physi al phenomena. A ording to the Oxford English Di tionary (OED) (Soanes 05),a sensor:�is a devi e giving a signal for the dete tion or measurement of a physi al propertyto whi h it responds.�There are two parts to this de�nition and both are aptured within this abstra tion. The�rst is that a sensor measures a physi al phenomenon. Within the earth and o ean s ien e ommunities, the term software sensor (Chen 98; Masson ) has gained tra tion in re ent yearsand is used to des ribe a system used to � ompute an estimate of some quantity of interest,based on a mathemati al model and other (faithful) measurements.�The PiCSE Sensor abstra tion only aptures devi es that measure physi al phenomenon,su h as temperature, noise, et , but does not provide any support for the omputation orestimation of those physi al phenomenon. This is instead aptured in the EnvironmentLayer100

Chapter 4. Modelling the Key Pervasive Computing Componentsdes ribed later in this hapter. The OED de�nition also aptures that a sensor presents asignal, i.e., a reading, to the user of that sensor. Both of these intera tions, between thesensor and physi al phenomenon, and between the sensor and its user, are aptured withinthe Sensor abstra tion.Within the broad de�nition of pervasive omputing, there are a wide range of sensorswith a range of properties that have to be met. Consider for example two di�erent types of arbon dioxide sensors. The �rst, deployed in an environmental monitoring s enario ouldmeasure the ambient levels of CO2 in the sensor's lo ality, and ould potentially be on asensor board intera ting with an embedded operating system su h as TinyOS. A se ond CO2sensor, deployed as part of an engine management system in a vehi le, would be ontrolledby an on-board omputer, a essed a ross a ontroller area network (CAN)-bus and wouldreturn a value apturing the CO2 emissions of the vehi le. These are two examples of sensorsmeasuring the same phenomenon, but ea h having unique hara teristi s. In the �rst, themeasured phenomenon is dependent on the lo ation of the sensor within its environment.In the se ond, the measured phenomenon is independent of the lo ation, but dependenton the attributes of a modelled obje t, a vehi le. The basi Sensor abstra tion meets therequirement that a sensor an measure a phenomenon from a wide range of sour es withvarying hara teristi s.4.3.1 Push and Pull modelsAn additional hara teristi that is aptured by the Sensor abstra tion is whether the sensoris a tive or passive. An a tive sensor in e�e t measures or �pulls� its measurements from thephenomena that it is sensing. A passive sensor is driven by hanges in the phenomena that itis measuring and measurements are e�e tively �pushed� onto the sensor devi e. An exampleis a photosensitive swit h, that is a tivated whenever the level of light in its environmentrea hes a ertain threshold. 101

4.3. Sensors4.3.2 Measured PhenomenonThe Sensor abstra tion an support a diverse range of measurable phenomenon, whi h are lassi�ed as being either extero eptive or proprio eptive. An extero eptive sensor meansthat the sensor takes it readings from external stimuli, i.e. its environment. Proprio eptivesensors take their readings from obje ts to whi h they are physi ally atta hed. In the aseof extero eptive sensors, instantiations are parameterised to query an instantiation of eitheran EnvironmentLayer or an EntityLayer. Instantiations of proprio eptive sensors typi allyquery instantiations of the lass, or lasses derived thereof. An example of a proprio eptivesensor would be a GPS sensor measuring its �own lo ation� or the vehi le CO2 sensor men-tioned previously. A thermistor measuring the ambient temperature in the room would bebound to a EnvironmentLayer instan e that models the temperature of that room.4.3.3 QueryingDepending on the modelled phenomenon that a sensor measures, a reading is obtained usingone of three native methods.1. EnvironmentLayer instantiations are queried using theEnvironmentLayer::queryState( Lo ation l) method. The sensors lo ation isused as the default parameter.2. EntityLayer instantiations are queried using theEntityLayer::getObje tsWithinRange(Lo ation l, double range) method,whi h returns a group of Obje ts within a ertain lo ation.3. Obje t instantiations are queried using a simple Obje t::getReading() method, that an return either a numeri al or a more omplex obje t type su h as a lo ation.The returned value in all of these instan es an be passed dire tly to the user of the sensor,in whi h ase the sensor an be on eptualised as a user's or appli ation's gateway to thephysi al environment. Alternatively, the value an be manipulated and pro essed to reate amore realisti reading that is representative of an a tual physi al sensor.102

Chapter 4. Modelling the Key Pervasive Computing Components

Figure 4.3: The pro ess by whi h a reading passes through a pipeline formed of a ombinationof blo king and modifying �lters4.3.4 Chara teristi s of Individual Sensor ReadingsIndependently reated sensors that measure the same phenomenon may have unique proper-ties, su h as di�erent levels of a ura y and pre ision, that may a�e t the �nal reading thatis presented to the user of that sensor. An additional property ould be a threshold that asensor may not be able to measure above or below. These fun tional hara teristi s have tobe supported within the abstra tion.A �exible method for modelling these properties is to use a sensor pipeline, displayed in Fig4.3. The sensor pipeline omprises of a ombination of �lters whi h may "modify� or �blo k�a measured phenomenon in some way. The initial measurement is made when the sensorretrieves data from the measured phenomenon, either an EntityLayer, an EnvironmentLayeror an Obje t instantiation. This initial raw value is then pushed onto the sensor pipelinewhere it passes through a series of �lters. �Modifying �lters� may update the value in someway by adding some error based on a normal error distribution for example. A �blo king�lter� determines if it was physi ally possible to make the original reading, and may takethe lo ation of the sensor and the distan e to the sensed phenomenon into a ount. All�lters may themselves be dependent on other modelled omponents within a simulation, forexample, be that Obje t or Layer instantiations. By ombining many of these �lters into asingle on eptual pipeline, through whi h all sensor measurements must pass, it is possible toprovide a �exible and potentially, a urate model of a sensor.103

4.4. A tuators4.3.5 External Interfa esThe remaining part of the Sensor abstra tion is the delivery or the presentation of thereading to the appli ation. In PiCSE terms, this is mediated by an instantiation of theExe utionEnvironment abstra tion that plays the role of either a devi e driver for the sen-sor, or some middleware that abstra ts that fun tionality. The role of modelling the inter-a tion is split between the Sensor and the Emulated abstra tion. The instantiation of thesensor is responsible for the formatting of the �ltered data into a form understood by theExe utionEnvironment.The Emulated abstra tion, not previously introdu ed, is used to assist in the modelling ofthe intera tion between the obje t and the Exe utionEnvironment. Its role is to manage theintera tion of the sensor with an instan e of an Exe utionEnvironment, in a way that enablesthe a urate emulation of the interfa e. For example, an Exe utionEnvironment instantiationmay represent a Sensor as part of the �le system. In this ase, the Emulated instantiationpushes the sensor readings, as they o ur, to the appropriate part of that modelled �le system.4.4 A tuatorsTraditionally, a tuators would have been used within losed or embedded environments, su has manufa turing or tra� ontrol systems. Non-fun tional properties, su h as safety andse urity, had to be onsidered (and still are), and these losed systems were best suitedto meeting these requirements. In re ent years, Wireless Sensor and A tuator Networks(WSANs) have be ome a well established paradigm, and proje ts su h as WiSeNts1, and nowCONET2 are exploring the intera tion between embedded systems, pervasive omputing, andwireless sensor networks.The use of a tuators represents a �ow of e�e t in the opposite dire tion to that of sensors:sensors, in the shape of hardware or software measure some aspe t of their environmentand appli ations onsume sensor data to produ e some meaningful results; whilst a tuatorsenable appli ations to a�e t the environment. Therefore, the integration of a tuators in1 www.embedded-wisents.org2 www. ooperating-obje ts.eu 104

Chapter 4. Modelling the Key Pervasive Computing Componentspervasive omputing ompletes the loop of the intera tion between the appli ation and thereal world. (Verdone 07) larify the de�nition of an a tuator as �a devi e able to manipulatethe environment rather than observe it�. It is this �manipulation� of the environment thatthe PiCSE A tuator abstra tion must apture.4.4.1 Exe utionEnvironment Intera tionThe implementation of the a tuator abstra tion is similar to that of the Sensor abstra tion.There is however no push and pull distin tion in a tuators. All a tuators either a t inde-pendently, or more ommonly are under the ontrol of an appli ation. Again, the intera tionof the emulated appli ation and the model of the simulated a tuator is mediated by a om-bination of an Exe utionEnvironment instantiation and an Emulated Instantiation. In thiss enario, the role of the Emulated instantiation is to parse or interpret any ommand that theappli ation may issue, and invoke the appropriate method within the A tuator instantiation.This is analogous to the �formatting� role played by the Emulated instantiation in the Sensorabstra tion.4.4.2 Modelling A tuator's E�e tsWithin pervasive omputing, the environment is not just the stati physi al environment,su h as the road or the atmosphere, but also in ludes obje ts within that environment, thatmay themselves be a part of the s enario. The A tuator abstra tion therefore an intera twith the three PiCSE abstra tions, EnvironmentLayer, EntityLayer and Obje t that areprovided to model this environment.There are two methods of modelling a tuation on the environment within PiCSE, andthey are distinguished by where the knowledge of the e�e t of an a tuator lies. The �rstmethod pla es the responsibility of modelling the e�e ts within the omponent that has beena tuated upon. In this ase, the a tuator s hedules an event within the omponent, and whenthe event o urs, potentially immediately, the omponent onsumes the event and updatessome attribute to re�e t the e�e t of the a tuation.Alternatively, the a tuator itself may maintain a referen e to the omponent on whi h it105

4.5. EnvironmentLayersa tuates, and updates the state itself. Using the �rst te hnique, the a�e ted omponent musthave an understanding of the apabilities of the a tuator. Using the se ond te hnique, ana tuator must have knowledge of the modelling aspe t of the environment that it is updating.The main abstra tions, EnvironmentLayer, EntityLayer and Obje t, present an API thatexposes their state allowing A tuator instantiations to �a tuate� upon them.As introdu ed in the Sensor abstra tion, the use of a ��lter� pipeline is also supported,allowing the modelling of more omplex a tuation events, that are perhaps dependent onmore than one aspe t of the modelled environment. In the a tuator pipeline, the �lters anbe used to determine whether the a tuation an a tually o ur and what its e�e ts will be onthe environment.4.5 EnvironmentLayersThe simplest most abstra t on ept within the PiCSE framework is that of the physi al phe-nomenon. A physi al phenomenon is a tangible aspe t of an environment within a pervasive omputing domain and is aptured within the EnvironmentLayer abstra tion. By tangible,it is meant that the physi al phenomenon is both dete table and an also be manipulated. Inthe ontext of pervasive omputing, that means that it an be sensed and a tuated upon byhardware devi es. An EnvironmentLayer abstra tion supports the modelling of a single phe-nomenon. EnvironmentLayer instantiations an also be grouped and they then olle tivelyform part of a simulated model of the environment. A group of EntityLayer instantiationsform the remainder of the modelled environment.4.5.1 A Single Modelled PhenomenonThe most generalised representation of a physi al phenomenon, representing some aspe t ofan environment, is that it has a ertain state or value at a ertain lo ation at a ertain time.The EnvironmentLayer abstra tion uses lo ation as the fo al point of a grid-based approa hto modelling that physi al phenomenon. The EnvironmentLayer abstra tion implements athree-dimensional grid of �xed size, that maps onto the s enario being modelled. In addition106

Chapter 4. Modelling the Key Pervasive Computing ComponentsEnvironmentLayer

+populate()

+setInitialEvents()

FLOAT_EnvironmentLayer

#grid: float**

+setState(l:Location,f:float)

+queryState(l:Location): float

+getStateAverage()(): float

+getGrid(): float**

Temp_environment

+populate()

+setInitialEvents()

+transform()Figure 4.4: Temp_environment lassto the physi al x, y and z dimensions of the spa e, ea h EnvironmentLayer instantiation isparametrised with the granularity of the grid within the layer. The granularity of a �spa e�within the grid an be arbitrarily large or small and o�ers an additional degree of �exibility.Within ea h dis retised part of this grid, the value of modelled phenomenon is the same, asat all other points within the same dis retised spa e.A physi al environment is of ourse a dynami system, and the EnvironmentLayer ab-stra tion provides an abstra t method that an be implemented to update the phenomenonrepresented. The abstra tion an be parameterised to evolve periodi ally, i.e. an abstra tmethod, ::transform(), that is equivalent to a state transition fun tion, an be invoked at�xed time intervals. Alternatively, the transformation an be driven by events that o ur inother Layer or Obje t instantiations. This is examined in detail later.From a on rete lass point of view, an EnvironmentLayer obje t an represent any phys-i al phenomenon from the de�nition above. Figure 4.4 shows the lass hierar hy for a Tem-perature EnvironmentLayer instan e. The abstra t populate() method is de�ned to set theinitial environment temperature values and the abstra t transform() method de�nes to spe ifyhow those values hange over time.The abstra t implementation of EnvironmentLayer a�ords developers the freedom totailor the layer to their requirements and the parameters of freedom within an instantiationin lude the size of the modelled spa e, its granularity, its state and a state transition fun tionthat is invoked to update the state of the physi al phenomenon at a parti ular time.107

4.5. EnvironmentLayers

Figure 4.5: A Pre ipitationLayer obje t models rainfall within the simulated environment.The Modelling of Continuous PhenomenonWhilst some phenomenon lend themselves to oarse-grained modelling, other more ontinuousphenomenon su h as natural or physi al phenomenon are des ribed by mathemati al formulae.In these ases, an inherited instan e of the EnvironmentaLayer lass instan e should providea method implementing this formula, whi h an then be invoked to determine the state of thephenomenon at a parti ular point in time. This approa h is provided as an alternative to the�dis retised� approa h presented above.Environmental Monitoring S enarioConsider an environmental monitoring s enario. A set of sensors are physi ally deployeda ross a large geographi spa e and ommuni ate wirelessly to aggregate sensor informa-tion that has measured the pre ipitation in an environment. In modelling this s enario, anEnvironmentLayer obje t, Pre ipitationLayer an be instantiated to model the amount ofrainfall, a physi al phenomenon.By way of example, �gure 4.5 , shows the Pre ipitationLayer model, representing anarea of 10km*10km with a dis rete granularity of 500 metres. The state modelled is the108

Chapter 4. Modelling the Key Pervasive Computing ComponentsFigure 4.6: EnvironmentLayer instantiations an intera t dire tly with other Layersamount of rainfall, measured in millimetres. Rainfall is a oarse-grained phenomenon3 buta smaller granularity an be used if more a urate modelling is required. A transition fun -tion is de�ned to apture the amount of rainfall dependent on the time of day. Separatemeteorologi al onditions an be aptured within other Layer instantiations.By varying the granularity, and the orresponding ::transform() method, a wide rangeof phenomenon an be modelled. EnvironmentLayer obje ts an be tailored to model othersimple physi al phenomenon su h as the topology of the ground, the presen e of buildingsor roads, and the levels of light, noise or temperature at a parti ular lo ation within theenvironment.4.5.2 A Lo ation-Based APIThe EnvironmentLayer abstra tion is used to model physi al phenomenon. The role of sensingand a tuating is important within the de�nition of the EnvironmentLayer abstra tion, sin eit is only sensors and a tuators that an intera t with the modelled environment in PiCSEinstantiations. Considering this, the EnvironmentLayer abstra tion has to support that in-tera tion and it an be said that this intera tion is the driving for e behind the lo ation-basedAPI of the abstra tion.SensingWhen an EnvironmentLayer::queryState( Lo ation ) method is invoked, theEnvironmentLayer obje t maps the lo ation parameter to a region within the grid. The state3 Rainfall does not hange in quantitative terms signi� antly from metre to metre, so it possible to use alarge regional granularity. 109

4.5. EnvironmentLayersof the EnvironmentLayer obje t at that region is then returned. A sensor an 'sense' thestate of the modelled phenomenon by invoking the ::queryState(Sensor::getLo ation())method using its own lo ation as the parameter. Two sensors whose respe tive lo a-tions both map to the same region within an EnvironmentLayer, as determined by theEnvironmentLayer granularity, will both sense the same value of the modelled phenomenon.The ::queryState(Lo ation) method abstra ts the variable granularity and grid sizes ofdi�erent instantiations, thus simplifying the intera tion.A tuatingThe EnvironmentLayer provides two methods, one virtual and one abstra t, to supportthe intera tion of A tuator and the EnvironmentLayer instantiations. The �rst method::setState(Lo ation, state) provides a simplisti 'set' orresponding to the 'get' method::queryState(Lo ation). This method may be invoked by the a tuator, and from the per-spe tive of an EnvironmentLayer instantiation, it is the a tuator that is performing the a tion.Alternatively, the EnvironmentLayer lass provides an abstra t method::lo alTransform(Lo ation sour e, double s ope, int event=0) that an also beinvoked by an a tuator. In this instan e, the EnvironmentLayer obje t is required toimplement a lo alised version of its own ::transform() method, that takes into a ount thesour e, s ope and type of event that the a tuator has generated.The �rst method ::setState(Lo ation, double) is limited, sin e it does not take intoa ount the potential s ope of an a tuator's a tions. Furthermore, the a tuator is required tounderstand the semanti s of the behaviour of the EnvironmentLayer, so that it an updatethe state to an appropriate value. For this reason, the se ond method is preferred whenmodelling the e�e ts of an a tuator's a tions. However, this method has its own limitationsas the te hni al apabilities of the a tuator may not be known, and providing alternativemeans of intera tion between A tuator obje ts and EnvironmentLayer obje ts helps meetthe �exibility requirement. Furthermore, providing a lo alised version of the ::transform()method improves s alability, as it redu es the time and omputation required in modellingthe intera tions between a tuators and the environment.110

Chapter 4. Modelling the Key Pervasive Computing Components4.5.3 EnvironmentLayer ComplexityUsing logi al dependen ies, a large-s ale representation of a range of environments an bemodelled by instantiating multiple EnvironmentLayer obje ts and reating dependen ies be-tween them.The EnvironmentLayer abstra tion supports the modelling of more omplex phenomenonthrough the framework's underlying support for logi al dependen ies. An EnvironmentLayerinstantiation an implement its state and ::transform() methods to be dependent on otherinstantiations in a simulation. For EnvironmentLayer instan es, these are often alternativeEnvironmentLayer obje ts or EntityLayer obje ts, although te hni ally all simulated obje tssupport the logi al dependen ies paradigm.By way of an example, onsider a simple extension to the environmental monitoring s e-nario just introdu ed. A new lass TemperatureLayer is introdu ed that models anotheraspe t of the physi al environment, the temperature. More spe i� ally a s ientist wishes to apture the prin iple that in reases in the temperature in rease the likelihood of rainfall.This relationship is enabled and aptured within the PiCSE framework as a logi al depen-den y, i.e. a Pre ipitationLayer instan e is dependent upon a TemperatureLayer instan e.In this extended s enario, the Pre ipitationLayer instan e, an subs ribe to events fromthe TemperatureLayer, and an also use the TemperatureLayer interfa e to determine thetemperature at ertain lo ations.The separation of the grid-based implementation from the API means that omplexEnvironmentLayer instantiations an be built by treating other layers as simple state in-formation, that is lo ation dependent. Consequently, EnvironmentLayer instantiations anbe logi ally ollo ated to reate a more omplex model of an environment, that is independentof the underlying implementation.4.6 EntityLayersThe EntityLayer abstra tion implements the se ond Layer abstra tion, ompleting PiCSE'ssupport for modelling of pervasive omputing environments. Many di�erent types of obje ts111

4.6. EntityLayers

Figure 4.7: Obje t instan es within lose proximity, de�ned by the grid's dis retised spa e,are bundled into a single list an be found in pervasive omputing, su h as vehi les in intelligent transportation system(ITS) s enarios, people in smart spa e s enarios, and RFID tags in logisti s. In almost all ases, these obje ts themselves form part of the environment in whi h they exist. They intera twith ea h other and an a�e t the physi al aspe ts of the environment that are measured bysensors, as well as being dete table by sensors themselves. The EntityLayer abstra tionprovides a model that supports the modelling of these obje ts within a physi al spa e.Similar to the EnvironmentLayer abstra tion, the lo ation of these obje ts is entral tothe role within pervasive omputing environments and this is re�e ted in the implementationof this abstra tion. The same underlying model of a dis retised grid of physi al spa e exists,but ea h of these dis rete spa es no longer represents a physi al phenomenon, but ontainsa list of Obje t instan es within the dis retised spa e, as shown in �gure 4.7. All Obje tinstan es within a parti ular bounded region of an EntityLayer grid are in lose proximityin the simulated spa e.An alternative key-based approa h allows groups of Obje t instantiations to be referen edby an identi�er known to all. This approa h is suitable for modelling s enarios where theabsolute lo ation of the Obje t instan es is not as important, but some other non-lo ationbased identi�er may be used. For example, referen ing Sensor instantiations that are a tive,or updating the lo ation of all Obje t instan es representing people inside a building. Inthese s enarios, a key �ACTIVE� would be used to obtain all Obje t instan es, and in these ond s enario, the identi�er of the building would be used to referen e the person Obje tinstan es. 112

Chapter 4. Modelling the Key Pervasive Computing ComponentsAs noted in hapter 1, supporting the modelling of large-s ale appli ation domains is animportant se ondary hallenge that must be met by PiCSE's ar hite ture. The e�e tive lo- ation management of simulated obje ts plays a large role in developing e� ient simulationsthat support large s ale s enarios. The use of a lo ation-based referen ing me hanism formodelling and management of physi al omponents enables large-s ale simulations by ex-ploiting the lo ation information to bound the amount of intera tions that an o ur betweensimulated models.All Obje t instan es, whether they are Sensor, A tuator, or domain spe i� Obje tinstan es, implement their own ::transform() method, whi h may be invoked periodi allyor alternatively event driven. The EntityLayer abstra tion allows all Obje t instan es of a ertain type to be treated as a single Obje t, and an instantiation of the abstra tion an beparameterised to transform all obje ts independently or as a unit.4.6.1 Lo ation based Intera tionSimilar to the EnvironmentLayer abstra tion, EntityLayer instantiations an potentially in-tera t with instantiations of Sensors, A tuators, other domain spe i� Obje ts, and otherLayer instantiations. The EntityLayer abstra tion provides two APIs based on the under-lying modelling me hanisms mentioned in se tion 4.6, whi h are a lo ation- and a key-basedAPI.QueryingTwo methods are provided for retrieving olle tions of obje ts based on their lo ation.GROUP_OF_OBJECTS* getObje tsWithinRange(Lo ation sour e, long doublerange);GROUP_OF_OBJECTS* getObje tsWithinBoundingRe tangle(Lo ation,Lo ation);The �rst method, ::getObje tsWithinRange(...) returns a list of Obje t pointers, whi hare within a proximity of length range of the lo ation sour e. Figure 4.8 demonstrates113

4.6. EntityLayers

Figure 4.8: Cal ulating the Obje t instan es within a ertain range in EntityLayer instan-tiationsthe pro ess by whi h the nodes within range are al ulated. The EntityLayer uses thelo ation parameterised, and the range to al ulate the dis retised spa es that overlap with theparameterised range. Obje ts within these dis retised spa es are then he ked for proximityto the parametrised lo ation. Finally, the list of Obje ts that are al ulated to be withinthe range are returned. A similar method ::getObje tsWithinBoundingRe tangle(...)returns a list of Obje t pointers that are onstrained by the two parameterised lo ations.The key-based approa h to querying is supported with the ::getObje tsByKey() methodwhi h uses the key to index a hash-map of Obje t pointers, and then returns a list of Obje tpointers.GROUP_OF_OBJECTS* getObje tsByKey(string key);UpdatingUpdating the EnvironmentLayer abstra tion is also supported using either the lo ation- orkey-based methods. An EntityLayer abstra tion supports the modelling of obje ts withintheir environment, but not the a tual obje ts themselves. So any event, either updating ora tuation that is to be performed on a group of obje ts, i.e. an EntityLayer instantiationis performed on all obje ts individually. This mapping to the individual Obje t instan es, isperformed by the abstra tion transparently.The method ::setState(lo ation, range, event) applies an update to all Obje t in-stan es, within a determined range. The method ::setState(lo ation, lo ation, event)applies an event to all Obje t instan es within a re tangle, bounded by the two parameterised114

Chapter 4. Modelling the Key Pervasive Computing Componentslo ations. Finally, the ::setState( key, event) method applies an event to all Obje t in-stan es indexed by that key. In the ase of ea h of these methods, the abstra tion, usingthe query methods outlined, determines the list of obje ts to whi h the event pertains, andthen s hedules the event to o ur in 0 se onds in ea h individual Obje t instan e. In theevent, that two or more events are s heduled to exe ute at the same time step, the events arepro essed in the order that they were s heduled, but all at the same simulated time.MobilityMobility of Obje t instan es are handled transparently. As an Obje t updates its lo ation,any EntityLayer instantiations that referen e that Obje t are noti�ed, and in the event thatthe Obje t has moved from one dis retised part of the grid to another, the instantiation isupdated using the ::updateObje tsGridLo ation(Obje t*) method.4.7 PiCSE as a Combinatorial FrameworkThe PiCSE framework is intrinsi ally �exible as its ar hite ture provides generi abstra tionsthat an be instantiated to model the ommon omponents of pervasive omputing s enarios.However, learly not all omponents of all domains an be anti ipated in advan e and theAbstra t_Interfa es lass ategory provides lasses and interfa es that allow developers to reate models to meet their own domain modelling requirements. In addition to enablingthe reation of new abstra tions, the framework should support the apturing of logi al andphysi al relationships between instantiations of the PiCSE abstra tions, allowing the reationof models that are beyond the instantiation of a single abstra tion. Both physi al and log-i al dependen ies are aptured within the framework and supported by the lass ategories.Supporting the free intera tion, ombination and inter-dependen e of simulated hardware andsoftware elements within the framework is a key step towards addressing the hallenge iden-ti�ed in hapter 1 as �exible heterogeneity and is also requirement R3 with respe t to thePiCSE framework. 115

4.7. PiCSE as a Combinatorial Framework4.7.1 Physi al Dependen iesThe framework aptures physi al dependen ies that o ur regularly whilst reating realisti models. The main physi al dependen y on erns the lo ation and ollo ation of obje ts.This re urring pattern aptures the s enario where an obje t is being � arried� by anotherobje t, its �owner �. In this situation, a physi al dependen y is reated, whereby the lo ationof the � arried� obje t assumes the lo ation of its owner. It is ne essary to apture thisrelationship to allow instantiations of low-level obje t-based abstra tions to be ombined intomore omplex instantiations.4.7.2 Logi al Dependen iesThe framework should apture the dependen ies within a s enario whereby the state of anobje t is dependent on the state of another obje t. Take a typi al environmental monitorings enario, su h as the forest-�re dete tion s enario des ribed in (Yu 05). In this s enario, awireless sensor network is deployed to dete t forest �res. In the PiCSE framework, models ofthe environment are aptured as sets of instantiations of the EnvironmentLayer abstra tion.An instantiation of a s enario su h as this one ould in lude a layer representing a model ofthe forest and a layer representing the forest �re. A logi al dependen y exists here and isrequired to fully model this s enario, i.e. the state of the layer representing the forest �re isdependent on the layer representing the lo ation or presen e of trees.The PiCSE framework supports the re urring pattern of logi al dependen ies, again sup-porting the reation of omplex instantiations from ombinations of simpler instantiations.Capturing this dependen y requires that a hange within a simulated model an initiate anupdate within a dependent simulated model. The PiCSE framework provides an event noti-� ation servi e, so that omplex inter-dependent instantiations an be built if required. Thenature of the dependen y between two models an be aptured as implementing either stri tor loose ausality. 116

Chapter 4. Modelling the Key Pervasive Computing Components4.7.3 Limiting the e�e ts of updatesPiCSE supports the reation of omplex simulated types, su h as o-lo ated Obje ts throughthe addition of an event publish-subs ribe model. This an potentially lead to omplex inter-dependen ies between instantiations. Depending on the nature of these dependen ies, and thea ura y of the simulation required, an a tuator an ause events; that is events that o uras a result of an original a tuation event.PiCSE provides two approa hes that attempt to mitigate the potential omputationale�e t of simulating as ading events, although it does not fully prevent these errors at thehuman level. For example, it may be ne essary for developers to spe ify y li al dependen iesbetween obje ts within a simulation, whi h if un he ked would result in an in�nite numberof as ading events. Typi ally this an happen when an update in one obje t would s hedulean immediate update one or more other obje ts, whi h may ultimately in lude the original.To mitigate this, dependen ies between layers an be spe i�ed as being either LOOSE orSTRICT. A LOOSE dependen ies do not ne essarily result in an immediate update of statewhen an event o urs, whereas a STRICT dependen y does.1. Loose Causality Event noti� ations to dependent models are a knowledged and the::transform() method is invoked as usual at a s heduled time in the future. This isthe default behaviour.2. Stri t Causality The re eption of an event noti� ation auses an immediate lo alinvo ation of the ::transform() method.In the event of loose ausality being implemented, there exists a period of time betweenthe periodi invo ations of the ::transform() method, indi ated in �gure 4.9 where thedependent model has not been updated to take into a ount the new data in the model uponwhi h it is dependent. Implementing stri t ausality between dependent models however an ause as ading updates, whereby an update in one model for es another model to update,whi h an in turn for e more layers to update and so on. Therefore, a trade o� exists betweenmaintaining the onsisten y of inter-dependent models and the e�ort required to maintain that onsisten y. The amount of simulation �delity that may a tually be lost by implementing the117

4.7. PiCSE as a Combinatorial Framework

Figure 4.9: Logi al dependen ies an be aptured using Loose or Stri t Causality

118

Chapter 4. Modelling the Key Pervasive Computing Componentsloose ausality is dependent on the modelled domain, and only the user an put a value onthat �delity. Aside from implementing stri t ausality as the alternative rigid approa h, alazy approa h to ausality would be implement a rollba k fun tion within the framework ofthe loose ausality approa h, whereby if a on�i t was dete ted, an in onsisten y ould bereversed by rolling ba k the simulation to the point where the on�i t arose and implementinga lo alised and immediate STRICT update.A tuator instantiations an also exploit the lo ation-based APIs of the EnvironmentLayerand EntityLayer abstra tions to spatially limit the amount of a tuation that is performedupon the environment. This means that omputational time is not wasted evaluating thee�e ts of an a tuator on obje ts that are outside of its de�ned range. For example, when aspeaker (a tuator) makes a sound, it an spe ify a range that will determine what simulatedelements will be a tuated upon, whi h in this ase means will hear the sound.4.8 Requirements AnalysisThe requirements determined for the PiCSE framework were determined at the outset of hapter 3, and they are on e again presented and then examined to determine whether theyhave been satis�ed by the ar hite ture and design of the framework.• R1 The framework should support the �exible and heterogeneous simulation of thehardware elements of pervasive omputing s enarios. This is be provided by reating ustomisable abstra tions representing physi al aspe ts of the s enarios su h as theenvironment, as well as hardware devi es su h as sensors and a tuators.• R2 The framework should support the emulation of real- ode appli ations developedfor pervasive omputing. These appli ations may be built upon middleware that shouldalso be supported.• R3 The framework should mediate the �exible intera tion of any simulated and emu-lated elements forming the simulation of a pervasive omputing appli ation.• R4 The framework should support the reation of new abstra tions of both hardware119

4.8. Requirements Analysisand software elements, in order that future emerging appli ation s enarios an be in- orporated into the PiCSE framework.• R5 The framework should ombine re urring elements of pervasive omputing simula-tions into a set of reusable omponents thus redu ing the amount of work required toinstantiate any simulated s enarios.• R6 The framework should support network simulation for both wired and wirelessnetworks.• R7 A framework that supports the reation of pervasive omputing simulations mustprovide fun tionality to support the evaluation of those simulations.Requirements R1, R2, and R3 The modelling of both hardware and software om-ponents is provided by the high-level lasses, Sensor, A tuation, EnvironmentLayer,EntityLayer, Appli ationWrapper and Exe utionEnvironment and their respe tive inher-ited lasses. PiCSE's support for modelling multiple simulated heterogeneous hardware andsoftware elements and the framework's �exible implementation allows the potential intera -tion, ombination and inter-dependen e of these omponents without restri tion. These threerequirements have been met by the ar hite ture, design and implementation of the framework.Requirement R4 The support of the PiCSE framework's ar hite ture to address the re-quirement of extensibility is met by two aspe ts of its design. An instantiation of the PiCSEframework an itself be a domain-spe i� sub-frameworks, omposed of extensions of the soft-ware and hardware abstra tions provided by the PC_Abstra tions lass ategory. Addition-ally, the Abstra t_Interfa es lass ategory provides a set of interfa es that allow the develop-ment of new abstra tions that are not urrently modelled within the existing framework im-plementation. These extensions an intera t and interoperate with the existing PiCSE_Coreand the existing abstra tions. Additionally, the split-level design of the framework's emula-tion omponent allows new emulation appli ation APIs to be added when in the future whennew platforms or middlewares emerge. These fun tionalities and design features meet theframework's extensibility requirement, R4. 120

Chapter 4. Modelling the Key Pervasive Computing ComponentsRequirement R5 The PiCSE_Core framework engine omprises of a set of omponentsthat are ommon to all PiCSE simulations. This reusable engine, and the identifying ofre urring software patterns that are aptured within the lasses for the hardware and softwareelements, and their inter-dependen ies meets the framework's reusability requirement, R5.Requirement R6 The PiCSE framework provides two feature that address the aspe t ofnetwork simulation within pervasive omputing s enarios. The Net_Interfa e lass and theunderlying Network Manager omponent provide a rudimentary API for the simulation ofnetwork behaviour. This requirement, R6, is partially met.Requirement R7 The PiCSE framework's provides a �exible API that allows a developerto spe ify time windows, where the the behaviour and state of obje ts of interest within asimulation is re orded. This requirement, R7, is partially met.4.9 Con lusionOverall, the requirements identi�ed in hapter 3 have been satis�ed. Requirements R1, R2,R3, R4, and R5 whi h address the ore hallenges identi�ed in hapter 1 have been fullymet in the design of the ar hite ture and implementation of the PiCSE framework. Theadditional fun tional requirements R6 and R7 have been partially satis�ed. It was de idednot to in orporate a full network simulator into the framework's design as there are manyexisting well-established network simulators already in existen e. Rather than ompete withthese simulators, the framework provides an open lo ation-based API allowing all elementsto be queried so that the integration of the framework with a third-party network simulatormight be a hieved in the future. With respe t to the experimental support, there are nowidely a epted standards for re ording the output of simulated experiments in the pervasive omputing domain so this feature has not been implemented. In-line analysis and debuggingof pervasive omputing appli ation s enarios was also not implemented, and as su h thisrequirement is only partially met.121

Chapter 5Evaluation5.1 Introdu tionThe PiCSE framework has identi�ed ommon hara teristi s of a set of re urring omponents,and implemented these in a set of lass abstra tions that an be ustomised to a wide arrayof pervasive omputing s enarios. Instantiations of these abstra tions an be freely omposedinto more omplex instantiations, demonstrating the �exibility of the framework approa h.This is supported by the abstra tion's interfa es, that support the stru tured ompositionof these omplex instantiations, whilst impli itly en apsulating re urring intera tion patternswithin the domain. This hapter presents three s enarios that demonstrate the ful�lment ofthe framework's requirements as they were outlined in the beginning of hapter 3. Both thesimulation and emulation aspe ts of the framework are evaluated in three diverse independentappli ation domains that highlight the diversity of pervasive omputing s enarios.5.2 Experimental MethodologyWhen evaluating a framework based ar hite ture, the typi al approa h is to instantiate threedistin tive yet related s enarios that exer ise the ability of the framework to be �exiblyadapted to those s enarios. In addition to this requirement of a framework, further require-ments were determined for the PiCSE framework at the outset of hapter 3, and they are123

5.2. Experimental Methodologyon e again presented.• R1 The framework should support the �exible and heterogeneous simulation of thehardware elements of pervasive omputing s enarios. This is be provided by reating ustomisable abstra tions representing physi al aspe ts of the s enarios su h as theenvironment, as well as hardware devi es su h as sensors and a tuators.• R2 The framework should support the emulation of real- ode appli ations developedfor pervasive omputing. These appli ations may be built upon middleware that shouldalso be supported.• R3 The framework should mediate the �exible intera tion of any simulated and emu-lated elements forming the simulation of a pervasive omputing appli ation.• R4 The framework should support the reation of new abstra tions of both hardwareand software elements, in order that future emerging appli ation s enarios an be in- orporated into the PiCSE framework.• R5 The framework should ombine re urring elements of pervasive omputing simula-tions into a set of reusable omponents thus redu ing the amount of work required toinstantiate any simulated s enarios.• R6 The framework should support network simulation for both wired and wirelessnetworks.• R7 A framework that supports the reation of pervasive omputing simulations mustprovide fun tionality to support the evaluation of those simulations.The methodology adopted in this evaluation is to extend the subje tive approa h of frameworkinstantiation to measure, quantitatively where possible, the su ess of PiCSE framework inaddressing the additional requirements identi�ed. By evaluating the s enarios individually andthen subsequently drawing on lusions and insights a ross all three s enarios , a more rigorousevaluation is a hieved. The metri s that have been identi�ed to validate these requirementsare outlined in table 5.1. 124

Chapter 5. EvaluationRequirement Metri sR1 The number of diverse instan es of all hardware omponentsR2 The number of instan es of emulated omponents, bothappli ations and middlewares.R3 The number of instan es of omponent inter-relationships, whi his de�ned as an intera tion between two seperately reatedinstan es of PiCSE abstra tions.R4 The number of instan es of inherited reusable abstra tions.Measure the proportion of the simulation that is omprised ofre-usable domain spe i� elements.R5 The proportion of the simulation that is provided by the PiCSEframeworks ore lasses.R6 Demonstration of network fun tionality in appli ation s enarios.R7 Demonstration of eviden e of evaluation support fun tionality.Table 5.1: Requirement evaluation metri sThese metri s are applied a ross three distin t pervasive omputing s enarios. These s e-narios, a Steam Emulation s enario, a Car Hardware s enario and an Intelligent Transporta-tion Systems s enario are re�e tive of ommon appli ation domains a tively being onsideredwithin the pervasive ommunity at this time and have re urring hara teristi s that will exer- ise the �exibility, reusability and extensibility of the PiCSE framework. These hara teristi sin lude• Complex models omprising of many distin tive hardware and environmental ompo-nents.• Multiple appli ation types written both natively and on middleware platforms.• Complex intera tion between hardware, software and environmental fa tors for the pur-pose of domain-driven obje tives su h as oordinated behaviour, environmental dete -tion and distributed information gathering.The three s enarios are presented in the following format. A high level des ription of thes enario is presented, in whi h its hara teristi s and key omponents are drawn out. This isthen followed by a des ription of how PiCSE's abstra tions provide the supporting fun tional-ity required to model these omponents and their intera tion. The exe ution of the resulting125

5.3. The STEAM Emulation S enariomodelled s enario is dis ussed and any domain insights are highlighted. Finally, the evaluationmeasures how e�e tive the instantiated s enario exer ises the framework's requirements.5.2.1 The S enariosThe STEAM Emulation s enario models the intera tion between multiple mobile pervasive omputing appli ations, running on simulated PDA devi es, that ommuni ate using event-based middleware. This s enario aptures the e�e ts of mobility in the ommuni ation be-tween the two appli ations, through the emulation of the event middleware, and its integrationinto the network simulator.The Car Hardware S enario is hara terised by the modelling of the realisti integrationof simulated and emulated omponents. The realisti modelling of the hardware interfa eis entral to the e�e tive emulation of the appli ation, and this s enario exer ises PiCSE'ssupport for this requirement.The third and �nal s enario presented is an Intelligent Transportation Systems s enario.A simulation of a smart Dublin tra� environment, this s enario models a higher level of omplexity within the simulated aspe ts of the s enario in luding thousands of intera tingvehi les, roads and smart tra� lights. This large-s ale s enario aptures a large degree of bothphysi al and logi al dependen ies between a range of instantiations of PiCSE abstra tions.5.3 The STEAM Emulation S enarioThe �rst instantiation of the PiCSE framework models the emulation of two appli ations that ommuni ate using event-based middleware. The STEAM middleware, des ribed in detail by(Meier 03), enables event-based ommuni ation for ollaborative appli ations in distributedenvironments. The middleware provides several underlying servi es abstra ting from theunderlying ommuni ation medium. An announ ement servi e periodi ally broad asts a listof available event types that may be subs ribed to. A dis overy servi e is monitoring theenvironment for these announ ements. An appli ation may use STEAM's produ tion servi eto produ e and broad ast these events, whilst a subs ription servi e allows these events to126

Chapter 5. Evaluation

Figure 5.1: CommandSensor announ es event types periodi allybe subs ribed to, and provides �ltering fun tionality based on three riteria: event type, ontent and proximity. Combinations of these �lters allow a �ne-grain of ontrol over theultimate delivery of these events to the appli ation built upon the middleware. All servi esare available on ea h STEAM middleware instan e, but may not ne essarily be utilised; forexample, some instan es may be event produ ers only, whilst others may be both eventprodu ers and subs ribers.In this s enario, depi ted in �gures 5.1 and 5.2, two appli ations running on handhelddevi es, one stati and one mobile, use the STEAM middleware to ex hange messages. Themobile devi e, CommandSensor, produ es two types of message, �newMission� and �haltMis-sion� every seven se onds, and moves around the physi al environment following a randompath. The stati devi e, TestDevi e subs ribes to events of type �newMission�, and uponre eiving an event, an event handler is triggered, and a method is invoked within the appli- ation. In this simpli�ed s enario, the appli ation writes some output to a log. It should beevident that this type of middleware is typi al of pervasive omputing environments, and ouldunderpin for example smart environments where fun tionalities are dis overed only when auser moves into a ertain proximity of a devi e or a feature.5.3.1 S enario Modelling requirementsFrom the PiCSE perspe tive, there are three �software� elements that require modelling. Thetwo appli ations, CommandSensor and TestDevi e must be instantiated individually, and ares heduled to exe ute at a parameterised time. These two appli ations both run on instan es127

5.3. The STEAM Emulation S enario

Figure 5.2: The CommandSensor appli ation broad asts events to his subs ribers.of the STEAM middleware, the third software abstra tion, whi h must intera t with thenetwork simulator to model the wireless delivery of messages. As shown in �gure 5.2 , theCommandSensor appli ation raises events periodi ally, and broad asts them in the wirelessdomain; the TestDevi e appli ation re eives these events on its network interfa e wherebythey are re eived by a listener and an appropriate handler is invoked.There are two �hardware� modelling aspe ts of this s enario that map dire tly to the keyabstra tions within the PiCSE framework. The nodes are physi al obje ts that have a lo ationwithin the environment. As shown in �gure 5.1, one node is mobile and moves a ording to therandom waypoint movement pattern. The se ond �hardware� abstra tion is the environmentitself. In this s enario, the environment utilises PiCSE's default environment implementation,as no omplex environment features are required. In e�e t, the environment is a free spa e inwhi h the nodes an move freely.In addition to the highlighted hardware and software omponents, an e�e tive modelof this s enario must address two high level features. These features in lude mobility andthe modelling of the middleware fun tionality. Mobility is a key hara teristi of STEAMappli ations. The s enario an only demonstrate the e�e tiveness of the STEAM middlewareby realisti ally modelling the mobile omponents of the s enario. The STEAM middlewareimplements a range of fun tionality at di�erent levels within its libraries. The s enario mustretain the key parts of this fun tionality for the s enario to be a realisti validation of theSTEAM middleware. 128

Chapter 5. EvaluationFun tion name Fun tionality providedinit_rte_publish() Initialises the Real Time Event publish omponentinit_rte_subs ribe() Initialises the Real Time Event subs ribe omponent(un)announ e() Broad asts an event type announ ement ordenoun ementsend_event() Raises an event on the event hannel(un)subs ribe() Subs ribes/Unsubs ribes the middleware instan e to aparti ular event typeregister_update_lo ation_ b() Set a allba k method where the urrent lo ation anbe obtained fromvarious allo _x()fun tions Various supporting fun tions for memory managementet .Table 5.2: The STEAM API5.3.2 Building the S enario ModelModelling the S enario's Software ComponentsModelling the STEAM MiddlewareThe original STEAM middleware is implemented as a library written in C++. The library omprises of two main omponents. An RTE library provides the ore fun tionality for sub-s ribing to events, announ ing events and sending events, whilst the underlying se ond partof the library, Dummy-SEAR, provides fun tionality to both reserve and release hannels for ommuni ation and to send serialised messages on those hannels. The STEAM API, imple-mented in the C programming language, is provided allowing appli ations to be built uponSTEAM and provides the fun tions outlined in table 5.2. The Dummy-SEAR aspe t of themiddleware interfa es with the operating system and network sta k invoking the system allslisted in table 5.3.In order to su essfully emulate the STEAM middleware, its appli ation sta k, shown in�gure 5.3 has to be re-written in terms of PiCSE omponents so that any of the API's uponwhi h STEAM is built must be provided and repla ed by the orresponding fun tionalityprovided by the PiCSE ore. In the ase of this parti ular ommuni ation middleware, thisis primarily the networking fun tionality. There is some variability in how this might bea hieved as there is a number of points within STEAM where an integration with PiCSE may129

5.3. The STEAM Emulation S enarioFun tion name Sour eso ket()setso kopt()bind()sendto()Re vfrom() from sys/so ket.hhtons() from ma hine/endian.hinet_pton() from arpa/inet.hpthread_ reate()pthread_deta h()pthread_exit() from pthread.hTable 5.3: System alls made by STEAM to the underlying operating system.

Figure 5.3: The appropriate point at whi h STEAM should be emulated must be determinedby the user and is not onstrained by PiCSE.130

Chapter 5. Evaluation

Figure 5.4: STEAM is omprised of an RTE and SUMMY_SEAR library.be a hieved. The point at whi h the middleware is emulated ould be anywhere within theSTEAM appli ation sta k, ranging from the API where the appli ation interfa es dire tly withthe middleware, to the API between the STEAM middleware and the underlying operatingsystem. Choosing the appropriate point within that spe trum is a trade-o� between severalfa tors, whi h in lude:• the maintenan e of key fun tionality and logi provided within the middleware.• the provision of any required simulated fun tionality within the PiCSE ore.• the fa tor whi h the simulation is ultimately trying to measure.In the ase of this evaluation, the aim is to show that the framework is �exible enough toemulate the middleware behaviour with as mu h �delity as possible, and this is a hieved bymaintaining as mu h of the middleware's logi and fun tionality as possible. In the ase ofthe STEAM middleware, shown in �gure 5.4 , it is a tually omprised of two omponent131

5.3. The STEAM Emulation S enarioDUMMY-SEAR fun tion nameinit_dummy_sear_publish()init_dummy_sear_subs ribe()reserve_ hannel()reserve_ hannel_for_subs ribe()free_ hannel()send_on_ hannel()register_ b_for_re v_from_ hannel()Table 5.4: The DUMMY-SEAR APIparts: the RTE library and the DUMMY-SEAR library, where the RTE library is responsiblefor the event management, and the DUMMY-SEAR omponent is responsible for the timelyserialisation, marshalling and transmission of messages ontaining events raised by STEAMappli ations. Sin e the event-based logi was self- ontained within the RTE omponent, it isappropriate to leave that untou hed. In doing so, any appli ations within the s enario thatare built upon the STEAM middleware an run without modi� ation, an important riteriafor usability. The DUMMY-SEAR omponent primarily handles the network ommuni ation,and it was within this omponent where it was deemed appropriate to map fun tionality tothe PiCSE ore. DUMMY_SEAR provides the API, shown in table 5.4 whi h is a essed byRTE. The fun tionality abstra ted by these API's must be modi�ed to interfa e with PiCSEinstead of the originally targeted operating system.The two instan es of the STEAM middleware are implemented as instan es of theSteamExe utionEnvironment lass, shown in �gure 5.5 , whi h is derived from theExe utionEnvironment abstra tion. The Exe utionEnvironment abstra tion, whi h it-self implements the Net_Interfa e abstra tion, transparently registers itself with theNetwork_Simulator as a wireless sender and re eiver. Therefore, two basi methods haveto be implemented. Net_Interfa e::send(void*) and Net_Interfa e::deliver(void*msg). These methods intera t dire tly with the network simulator in the PiCSE_Core, andit is via these methods that the PiCSE framework, both sends and delivers STEAM eventsbetween appli ations built upon the STEAM middleware.By way of example, �gure 5.6 shows the methods invoked when an appli ation sendsan event via the STEAM middleware. Part a) tra es the method alls through the RTE,132

Chapter 5. Evaluation#ifndef STEAM_EXEC_ENV#define STEAM_EXEC_ENV#in lude "exe Env.h" lass SteamExe utionEnvironment:publi Exe utionEnvironment{publi :SteamExe utionEnvironment(Lo ation l);~SteamExe utionEnvironment();// RTE - Fun tions alled from RTE_Proximity libraryint init_rte_publish_lo al();int init_rte_subs ribe_lo al(); hannel_id announ e_lo al(subje t sub, proximity* prox,laten y lat, period per,adaptation adapt);void unannoun e_lo al( hannel_id h);int send_event_lo al(int hannel_id, event* event);subs ription_id subs ribe_lo al(subje t sub, re eive_event b);void unsubs ribe_lo al(subs ription_id h);void register_update_lo ation_ b_lo al(update_lo ation_ b b);void make_ allba ks_for_lo al(steam_event* st_ev);void free_steam_event_lo al(steam_event* ev);// DUMMY-NETIF - Fun tions alled from DUMMY2-SEAR fun tionsvoid send(void*);void deliver(void*);// DUMMY2-SEAR - Variables needed for DUMMY2-SEAR fun tionsint send_so ket;int re v_so ket;};#endifFigure 5.5: Extra ts from the emulated STEAM library, as de�ned in steamExe Env.h. Thefull de�nition of this program may be found in the Appendix.

133

5.3. The STEAM Emulation S enario

Figure 5.6: Original STEAM library and emulated STEAM libraryand DUMMY-SEAR libraries respe tively before the event is passed to the underlyingoperating system. In part b), the DUMMY_SEAR library has been repla ed with theDUMMY-SEAR library whi h was implemented in the SteamExe utionEnvironment lass.The emulated send_on_ hannel method sends the event to the network simulator via theNet_Interfa e::send method. Beyond that method, the network simulation omponent of thePiCSE framework al ulates the potential re eivers of that message based on proximity anddelivers that message to those re eivers at a s heduled point in the future. The deliver ofmessages at a time in the future is enabled to allow developers to simulate pa ket delays, butthis is not a feature of this parti ular s enario.Figure 5.7 shows the modi� ations required to ea h of these fun tions in order to redire tthese fun tions from making alls to the underlying operating system to the PiCSE ore.The left olumn shows the original fun tionality provided within the DUMMY-SEAR library,and the right hand olumn shows the fun tionality provided by the emulated library, namedDUMMY2-SEAR library, and the alls that are made to the PiCSE libraries in order toa hieve that emulation.Modelling the S enario's Appli ationsThere are two appli ations, CommandSensor and TestDevi e, in this s enario. Bothare supported by their respe tive Appli ationWrapper instantiations, Command_Wrap and134

Chapter 5. Evaluation

Figure 5.7: Comparing original behaviour of the Dummy-SEAR and the emulatedDUMMY2-SEAR omponents. 135

5.3. The STEAM Emulation S enarioCommandSensor::CommandSensor(){if(init_rte_publish() == -1){printf("Init-rte-publish failed.\n");exit(1);}my_proximity = allo _proximity();my_proximity->proximity_hull.type = CIRCLE;// non-rt laten ylat.min = 0; lat.max = 0;//period is in millise ondsper = 1000;str py(newMissionSubje t, "NewMission"); hannel_id newMissionChannel;newMissionChannel = announ e(newMissionSubje t, my_proximity, lat, per, ommandSensor_adapt)newMission_event = allo _event();newMission_event->sub = newMissionSubje t;int xv = 0 ;while (xv < 10){sleep(7);if(send_event(newMissionChannel, newMission_event) == -1){printf("Error in send_event\n");exit(1);}xv++;}}Figure 5.8: Extra ts from the CommandSensor program, whi h is de�ned in CommandSen-sor. ppTest_Wrap and these instantiations initialise the CommandSensor, and TestDevi e programsrespe tively. The CommandSensor program is a simple program that exer ises the STEAMevent produ tion API. In this s enario, this program initialises itself by alling the appropriateRTE library methods, and then sends two separate events on the reated STEAM event han-nel. As an be seen in �gure 5.8 , these messages are raised periodi ally every seven se ondsand are sent ten times in total. The TestDevi e program, an abbreviated version of whi h isshown in �gure 5.9 , is a simple STEAM event onsumer, that listens for �NewMission� eventsby registering a allba k fun tion shown in �gure 5.10 . It is the STEAM middleware that in-136

Chapter 5. EvaluationTestDevi e::TestDevi e(){if(init_rte_subs ribe() == -1){printf("Init-rte-subs ribe failed.\n");exit(1);}if(init_rte_publish() == -1){printf("Init-rte-publish failed.\n");exit(1);}testDevi e_ ur_lo .lat = 0;testDevi e_ ur_lo .lon = 0;subs ribe("NewMission", testDevi e_re vev);printf("End\n");}Figure 5.9: Extra ts from the TestDevi e program, whi h is de�ned in TestDevi e. ppvoid testDevi e_re vev(event* ev){printf("THIS IS THE TEST DEVICE RECEIVING AN EVENT\n");printf("¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬\n");printf("Re eived event of subje t \"%s\", with ontent:\n[%s℄\n", ev->sub, ev-> ont);printf("¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬\n");}Figure 5.10: The TestDevi e event allba k fun tion, whi h is de�ned in TestDevi e. pp

137

5.3. The STEAM Emulation S enarioSteamExe utionEnvironment* testDevi eSee =new SteamExe utionEnvironment(Lo ation(0,0));Figure 5.11: Modelling of a stati obje t an be a hieve by passing a lo ation parameterduring the instantiation of an Exe utionEnvironment obje t.vokes that allba k, whi h is triggered by the delivery of a �NewMission� Event from the PiCSEnetwork simulator to the middleware instan e through its Net_Interfa e::deliver(void*)method. The full de�nition of both the TestDevi e and CommandSensor programs an befound in the Appendix.Modelling the S enario's Hardware ComponentsModelling Stati Obje tsThere are two physi al omponents in this s enario: the stati physi al devi e upon theTestDevi e program is running, and the mobile physi al devi e on whi h the CommandSensorprogram is running. The �rst physi al devi e is spe i�ed in the s enario to be a stati obje t,initiated at a �xed lo ation, whi h remains at that lo ation throughout the duration of theexperiment. This an be done in PiCSE using two methods. The �rst method is to usea Mobility_Obje t lass, whi h may be parameterised at instantiation with the STATICenumerator. Alternatively the Exe utionEnvironment an be parameterised with a lo ationat the time of instantiation. In the implementation of the STEAM s enario, the se ondapproa h was utilised as only a single line of ode is required to initialise this, and this anbe additionally a hieved by passing a lo ation parameter during the reation of the s enarioExe utionEnvironment as seen in �gure 5.111 .Modelling Mobile Obje tsAn instan e of a Mobility_Obje t is instantiated and parameterised with the RAN-DOM_WAYPOINT parameter to model the mobility of the devi e hosting the Command-1Variable names may have been renamed in ode extra ts in order to fa ilitate readability and understandingof the s enario. 138

Chapter 5. EvaluationMobility_Obje t* ommandSensorMobObj =new Mobility_Obje t( Lo ation(0,0), RANDOM_WAYPOINT ) ;Figure 5.12: Physi al obje ts an be parameterised with a mobility pattern whi h de�nestheir movement during the s enario experiment.Sensor program. When a Mobility_Obje t is initialised with this parameter, shown in �gure5.12 , its path is determined using the random waypoint algorithm. This is a well known andfrequently used algorithm in network simulation experiments in whi h an obje t's mobilitypattern is guided by a series of waypoints, the next of whi h is determined upon arriving atthe previous waypoint. MOBILITY events are transparently s heduled by the PiCSE simu-lator to move the Mobility_Obje t towards its next waypoint. By default, these two obje tinstan es are added to the default environment, default_entLayer, whi h is managed by theDomain_Manager omponent.Interlinking of Simulated Hardware and Software ComponentsThe �nal step in the modelling of the STEAM s enario is to interlink the individual hardwareand software omponents that have been des ribed and instantiated in se tions 5.3.2 and 5.3.2of this hapter. So far, these omponents have been reated in isolation: that is to say, that the omponents su h as an emulated middleware instan e and a modelled physi al devi e that hasa lo ation are reated but are not yet interlinked in a meaningful way. However, appli ations inPiCSE, handled by their Appli ationWrapper instantiations have to be asso iated with theirrespe tive Exe utionEnvironment instantiations before they an be meaningfully exe uted.In addition to emulating the middleware, the SteamExe utionEnvironment instantiationhas a physi al lo ation within the simulated world. As this s enario ontains mobile nodes,the lo ation of the instantiation, and the impli it lo ation of all appli ations running ontop of that instantiation, have to re�e t the lo ation of the mobile nodes. Therefore aninstantiation must be asso iated with a Mobility_Obje t instan e that models its physi alnode. If that Mobility_Obje t moves within the simulated environment, the lo ation ofthe Exe utionEnvironment instantiation should be orrespondingly updated automati ally.139

5.3. The STEAM Emulation S enarioThis is a hieved within PiCSE by the Lo ation_Manager omponent of the PiCSE ore. TheNetwork_Simulator is also informed of the updated position of the Exe utionEnvironmentinstan e.Figures 5.13 and 5.14 show ode fragments from the initialisation of the s enario exper-iment in whi h the instan es, that been been des ribed in se tions 5.3.2 and 5.3.2, are nowimplemented and interlinked.As the ode fragment in �gure 5.13 shows, the emulated middleware is instantiated in a1. SteamExe utionEnvironment* testDevi eSee =new SteamExe utionEnvironment(Lo ation(0,0));2. thirdprog* testDevi eWrapper = new thirdprog();3. testDevi eSee->addEmulatedAppli ation(testDevi eWrapper);Figure 5.13: Code fragment demonstrating the interlinking of the s enario's TestDevi eappli ation and emulated STEAM middleware instan e.single line, line 1. The appli ation TestDevi e is instantiated through its appli ation wrapper,and is also instantiated in a single line, line 2. The interlinking of these omponents is a hievedin a single line, line 3, whereby the program, mediated by its appli ation wrapper is 'added'to the middleware through the addEmulatedAppli ation method. This method asso iates theprogram and any of its underlying middleware alls to a single emulated STEAM middlewareinstan e, in this ase, named testDevi eSee. This �hook� allows appli ation events that areraised as part of its exe ution to be pushed down into the middleware, and onversely allowsevents to be delivered from the middleware to the appli ation.Figure 5.14 shows how the interlinking of software and hardware omponents is a hievedfor a mobile appli ation, the CommandSensor program and middleware instan e in this s e-nario. The appli ation and the middleware instan e are reated similarly to the TestDevi einstantiation in lines 1,3 and 4. Two further lines of ode are required to apture the interlink-ing of these omponents. A Mobility_Obje t named ommandSensorMobObj, is instantiatedin line 2 as des ribed in se tion 5.3.2, and the program's exe ution environment, the emulatedmiddleware instan e ommandSensorSee, is now linked to that Mobility_Obje t instan e us-ing the addObje t() method. 140

Chapter 5. Evaluation1. SteamExe utionEnvironment* ommandSensorSee =new SteamExe utionEnvironment(Lo ation(0,0));2. Mobility_Obje t* ommandSensorMobObj =new Mobility_Obje t( Lo ation(0,0), RANDOM_WAYPOINT ) ;3. prog* ommandSensorWrapper = new prog();4. ommandSensorSee->addEmulatedAppli ation( ommandSensorWrapper);5. ommandSensorMobObj->addObje t( ommandSensorSee);Figure 5.14: Code fragment demonstrating the interlinking of the s enario's CommandSen-sor appli ation, emulated STEAM middleware instan e and the modelled mobile devi esThis is a hieved using PiCSE events. The Mobility_Obje t periodi ally s hedules MO-BILITY events. Ea h event o urren e invokes a method that moves the Mobility_Obje ttowards its next waypoint. Upon rea hing the waypoint, the node hooses a waiting period,and its next waypoint, and s hedules another MOBILITY event at the end of the waitingperiod. As the Mobility_Obje t moves, as determined by the parameterised random way-point algorithm, any obje ts o-lo ated with that obje t, in this ase the emulated STEAMmiddleware instan e and the CommandSensor appli ation running on that middleware, alsomove a ording to the same random waypoint algorithm. Simulated obje t mobility is thusa hieved when the experiment is exe uted.5.3.3 Exe uting the S enario SimulationInitialising the Experimental S enarioAs in all of the s enarios des ribed in this hapter, an instantiation of the PiCSE_Core lass ategory must exist and enable the simulation of the s enario. The primary role ofthe PiCSE_Core in this instantiation, is to manage the models of the nodes, exe utings heduled events when required, and to manage the exe ution of the two appli ations, theCommandSensor and TestDevi e programs. The PiCSE_Core's network manager also modelsthe wireless network ommuni ations between the appli ations whi h is mediated by theSTEAM middleware.The PiCSE_Core is the �rst set of omponents to be instantiated, and the follow-141

5.3. The STEAM Emulation S enarioint main( int arg , har **argv ){..// Create a simulation enginenew Future(LINKED); // event list, lo k, et Simulator::Instan e();// Instantiate the networkNetwork::Instan e();// Create a worldWorld::Instan e();..}Figure 5.15: Code fragment showing the initialisation of the PiCSE_Core aspe ts of theSTEAM s enario environment.ing omponents are reated by the ode snippets shown in �gure 5.15 . The key om-ponents are the Domain_Manager, the Network_Simulator and the Event_List_Manager.The Domain_Manager initialises a world model, instantiating an empty EntityLayer,default_entLayer, by whi h all Obje t instantiations an be referen ed. TheNetwork_Simulator reates an EntityLayer that maintains the position of all Net_Interfa einstantiations, that is instantiations that an send and re eive messages. Finally,the Event_List_Manager instantiates two event lists, the S heduled_Event list andS heduled_Appli ation list. These lists are also empty by default.In addition to the PiCSE ore omponents, a range of s enario spe i� parameters have tobe de�ned. Figure 5.16 shows an ex erpt from the main. pp, whi h de�nes the experiment'sinitialisation main method. The experiment's duration is spe i�ed in millise onds; the physi alsize of the experimental spa e is de�ned as a Cartesian spa e of one square kilometre, andthe experiment is de�ned to run over a single iteration.The s heduling of the exe ution of the simulated appli ations at a spe i�ed period after thebeginning of the simulation, �nally ompletes the de�nition and initialisation of the STEAMs enario and the s enario experiment is now ready to be exe uted. In this s enario, the twoappli ations are s heduled to start at staggered intervals in order to highlight behaviour whenone of the appli ations is not running. 142

Chapter 5. Evaluationint main( int arg , har **argv ){ int simDuration = 1000*60*2.5;int iterations = 1;int worldXSize = 1000, worldYSize = 1000;// Set the size of that worldWorld::setXSize(worldXSize); World::setYSize(worldYSize);// Set simulation durationSimulator::setDuration(simDuration);// S hedule the exe ution of emulated appli ationstestDevi eWrapper->s heduleExe ution(1970); ommandSensorWrapper->s heduleExe ution(1980);Figure 5.16: Code fragment showing the initialisation of the STEAM s enario environment.Exe ution of the SimulationThe experiment was performed on an o�-the-shelf Dell Latitude C400 laptop, equipped witha minimal 512 MB of RAM and running on Ubuntu 6.10, Edgy Eft, an open sour e operatingsystem built around the Linux kernel.The experiment was exe uted within a terminal and �gure 5.17 shows an ex erpt of thelogged output of the experiment. A more omplete ex erpt of the logged output is availablein the appendix. The ex erpt in �gure 5.17 shows the two programs simulated ex hange anddelivery of events via the STEAM middleware after the initialisation of the experiment, andthe initialisation of the programs, and the �gure is annotated with a series of pop-up notes,whi h explain the outputs of the experiment.The CommandSensor program, logi ally exe uting on the Mobility_Obje t raises twoevents, �NewMission� and �HaltMission� every seven se onds. The TestDevi e program, exe- uting in a stati environment, onsumes �NewMission� events only. A number of events ofinterest should be noted in �gures 5.17 and 5.3.3 .In notes 4 and 5 of �gure 5.17, the TestDevi e program re eives two messages: a �HaltMis-sion� announ ement and a �NewMission� event. The �HaltMission� is re eived and pro essedby the middleware. The middleware he ks its subs ription lists for subs ribed appli ations,but none are found for events of this type so no allba ks are made to the TestDevi e appli-143

5.3. The STEAM Emulation S enario

Figure 5.17: A s reenshot showing the logged output from the STEAM emulation evaluation. ation. In ontrast, the �NewMission� event is an event type for whi h a allba k has beenregistered, so when the middleware he ks its subs ription lists for subs ribed appli ations, it�nds the registered allba k method within the TestDevi e appli ation, whi h in this s enarioprints the output seen in note 5.Notes 6 and 7 demonstrate another feature of the STEAM middleware. In note 6, theCommandSensor raises another �NewMission� event and transmits it from the lo ation (108,50). Note 7 shows what happens at the TestDevi e's STEAM middleware instan e uponre eiving that event. Although the program has subs ribed to these event types, no allba kis made and the event is e�e tively dis arded as the CommandSensor has de�ned that themessage is only to be delivered if the re eiver is within a ertain proximity. In this parti ular ase, the CommandSensor has de�ned the proximity to be 100 metres and the distan e fromthe sender to the re eiver is approximately 119 metres. The proximity is de�ned within theCommandSensor as:my_proximity->proximity_ ir le.radius = 100;144

Chapter 5. Evaluation

Figure 5.18: A se ondary s reenshot showing the logged output from the STEAM emulationevaluation.

145

5.3. The STEAM Emulation S enarioFinally, note 8 of �gure demonstrates the range transmission aspe t of the network simulator omponent of the PiCSE simulator. The CommandSensor transmits a �NewMission� eventat the lo ation (209,98), but the event is not re eived by the TestDevi e middleware asthe sender in this ase is approximately 231 metres from the only potential re eiver. Thedefault transmission range within the simulator is 200 metres, and therefore the message isnot delivered.5.3.4 S enario AnalysisSeveral of PiCSE's abstra tions have been exer ised in this s enario. In the modellingof the lo ation of the Exe utionEnvironment instantiation, a physi al dependen y was reated using the underlying Obje t abstra tion. Mobility_Obje t omponents, andExe utionEnvironment instantiations are both derivations of the Obje t abstra tion. Themodelling of the o-lo ation of a middleware instan e and a physi al mobile node in thiss enario, demonstrates the abstra tion's support for modelling physi al dependen ies. Thisdependen y is independent of the a tual Obje t instantiations, thus validating the abstra tapproa h and the apturing of this dependen y ontributes to a urately ful�lling the mod-elling of one of the s enario's key features, that of mobility.The Net_Interfa e abstra tion is implemented by default for all Exe utionEnvironmentinstantiations. The API allows a range of message types to be passed through the simulator,irrespe tive of the appli ation or middleware that is sending and re eiving those messages. Inthis s enario, the SteamExe utionEnvironment instantiation uses the abstra tions interfa eto send and re eive STEAM events. The outputs of the s enario simulation demonstrate therudimentary fun tionality of a network simulator, and show how a event-based messagingmiddleware may be integrated into that network simulation omponent.In the ase of the STEAM middleware, the event subs ription and publi ation APIs,in addition to the supporting methods required were deemed to be entral to the a uratemodelling of the STEAM s enario. The Dummy-SEAR aspe t of the library was not entralto the appli ation s enario, so the emulation point was hosen appropriately. The lo ation ofthe emulation point at this point preserves the key middleware fun tionality, and this is the146

Chapter 5. Evaluationse ond feature of the STEAM s enario that must be supported.Overall, from a domain perspe tive, the simulation of this s enario was a su ess. TheSTEAM s enario's two most important features, the apturing of mobility and its e�e ts onthe behaviour of the appli ations, and the retention of the key fun tionality of the middle-ware have both been ful�lled. In both ases, this has been a hieved using features of thePiCSE framework. Physi al dependen ies have been demonstrated to work as a methodologyfor modelling o-lo ation, enabling the simulation of realisti mobility-based s enarios. Sim-ilarly, the Exe utionEnvironment abstra tion has been demonstrated that it an be used toe�e tively emulate middleware, at least of the event-based ommuni ation variety.InsightsThe primary e�ort in this s enario was in the implementation of the emulation of the STEAMmiddleware, and this is where the most relevant and important observations are to be made.The most important learning is around how mu h e�ort is required to provide the emulatedmiddleware. Con eivably, almost any of the layers, shown in part a) of �gure 5.19 ould have

Figure 5.19: Original STEAM library and emulated STEAM librarybeen hosen as the point at whi h to emulate. Consider the sele tion of the emulation point byexamining the API from top to bottom. A trade-o� o urs as the emulation point des endsinto the lower levels of the middleware implementation. As the emulation point lowers, agreater amount of the existing middleware fun tionality is maintained, however there are also147

5.3. The STEAM Emulation S enariomore likely to be operating system alls invoked above the emulation point. These system alls must additionally be emulated if they remain in the middleware implementation.In the ase of this experiment, the emulation point hosen removed the need for pthreads tobe implemented as part of the emulation. In ontrast, one system all, extern unsigned intsleep (unsigned int __se onds) remained above the emulation point, and this system allwas emulated in order to preserve the fun tionality of the middleware. The hoosing of theemulation point for any emulated appli ations or middlewares should be onsidered as partof a domain spe i� ost-bene�t analysis that should be addressed by any user of the PiCSEframework.Some restri tions were noted in the overall approa h taken to in orporating appli ationsdeveloped by third parties. At present, only programs whi h are developed in ++ are in- orporated. Bindings ould theoreti ally be made available in alternative languages su h asjava, and python, but this has not yet been tested. This would be a signi� ant amount ofwork involved in su h an undertaking, and a re-ar hite ting of the PiCSE ore to representa more distributed simulation environment would be required. In su h an ar hite ture, emu-lated programs would likely be exe uting within a lightweight lo al PiCSE instantiation andthe management of these instantiations ould be oordinated and syn hronised through a entralised instantiation.As PiCSE does not provide a sand-box, or a virtual environment based approa h, some hanges have to be made to appli ations before they an be implemented. Within the s opeof appli ations that are developed in ++, several hanges had to be made to the appli ationsbefore they ould be embedded into a PiCSE simulation. In ++, the program is invokedthrough a single main() method. As an instantiation of the PiCSE framework already ontainsthe only available main() method, the main() method of any emulated appli ations must berenamed.In a similar vein, some ++ keywords that are used within a program may have to berenamed. For example, stati variables should be renamed, for example pre-pended with anamespa e su h as the appli ationWrapper instan e, in order to ensure there are no on�i tswith other emulated programs. 148

Chapter 5. Evaluation De�nition (.h) Implementation (. pp)steamExe Env 67 477testDevi e 34 91 ommandSensor 36 199main 61Table 5.5: Lines of ode required to implement the STEAM emulation s enarioIn analysing the e�ort required to implement this s enario, the odebase is onsidered inthree parts.1. The lines of ode required to emulate the ore aspe ts of the middleware.2. The lines of ode required to implement the two appli ations, TestDevi e and Com-mandSensor, that exer ise that middleware.3. The lines of ode that are required to onstru t and initialise the s enario.The lines of ode methodology is hosen over determining the time taken to implement thes enario as that methodology an be subje tive and skewed by fa tors su h as the knowledgeof a user of a system, their level of domain expertise, and their overall skill as a developer. Thenumber of lines of ode is in itself a subje tive approa h for measuring e�ort, but arguablyless so than the time taken. Table 5.5 shows the lines of ode required to implement thes enario as onsidered when broken into the three parts. It an be seen that the greateste�ort, at least as measured by the total lines of ode written, is in the implementation ofthe emulated middleware. Figure 5.20 examines the breakdown of the salient aspe ts of thatimplementation. By omparing the lines of ode in the original implementation and in theemulated implementation, it an be seen where the fo us of attempting to a urately emu-late the middleware was pla ed. The implementation of methods su h as get_re v_so ket()and get_send_so ket() were forfeited, whilst free_ hannel() and send_on_ hannel() werereimplemented. These re�e t the point at whi h the middleware was emulated at. Simulat-ing network behaviour is forfeited whilst the modelling of the hannel-based ommuni ationbehaviour of the middleware is maintained. 149

5.3. The STEAM Emulation S enario

Figure 5.20: Table showing the number of modi�ed lines of ode with the emulated DUMMY-SEAR library.

150

Chapter 5. EvaluationOverall, the number of lines of ode required to implement those hanges is demonstratedin this s enario at least to be relatively small and in most ases in line with the originalimplementation of the relevant aspe ts of the middleware. This is broadly positive as itdemonstrates that in these ases, a like-by-like substitution an be made when repla ing theoriginal line of ode with a line of ode that invokes the simulated fun tionality within PiCSE.Furthermore, the e�ort required to implement the emulated STEAM middleware is a singleup-front e�ort that needs to be theoreti ally implemented on e and then emulated middleware an then be used in other s enarios without modi� ation.The a tual behaviour within the s enario is de�ned through a ombination of the TestDe-vi e and CommandSensor appli ations, implemented in 125 and 235 lines of ode respe tively.The experiment was initialised and the world and models reated in the main. pp �le andare implemented in 61 lines of ode. The number of lines of ode to de�ne the experimentalbehaviour and to initialise and onstru t the s enario is relatively small in this parti ulars enario as its fo us was to demonstrate the feasibility of the middleware emulation aspe tof the PiCSE ore. In this s enario, existing omponents were used to exer ise the mobilitymodels for example, and no ustom hardware omponents were de�ned. As su h, the smallnumber of lines of ode is more a re�e tion of the non- omplexity of the s enario rather thana statement suggesting that any s enario an be onstru ted in a similarly small number oflines of ode.This s enario has not been repli ated in the real world setting so no omparison an bemade between the simulated behaviour and observed real behaviour. However some observa-tions and insights an be drawn based on the running of the simulation alone.Overall the emulated appli ations and the STEAM middleware instan es have behavedas expe ted. Within the middleware, a full range of its fun tionality was observed, fromwithin the middleware and up to the appli ations that were running on that middleware.Within the physi al environment that was onstru ted within this s enario, the models forthe physi al aspe ts of the simulator have moved and intera ted as expe ted. Finally, thenetwork simulation omponent has been seen to deliver messages as expe ted whilst respe tingexpe ted s enario hara teristi s su h as mobility traits and transmission ranges.151

5.3. The STEAM Emulation S enarioHowever, there are several features that are missing from this experiment that an observerwould expe t to see had the experiment been ondu ted in a real world setting. For example,by removing the part of the library that was built upon the pthread library, some non-deterministi aspe ts of the middleware's behaviour have been removed. In a more omplexs enario with greater intera tion of its omponents, in reased demand for resour es withina middleware instan e would have a�e ted the exe ution and behaviour of that middleware.In a real world setting, one would also �nd that all pa kets sent by the ommuni ationmiddleware a ross the network would not have been delivered due to interferen e or otherissues not aptured by our PiCSE's basi network simulation omponent. For example, thetransmission range of a wireless network is not an absolute �xed number and is in�uen edby a number of fa tors su h as the mobility of the obje ts and o lusion reated by buildingsand users arrying devi es.Finally s enario spe i� behaviour that o urs in the real world su h as the positioningof external omponents su h as buildings, and me hani al aspe ts of omponents that arerepresented in this s enario as mobility obje ts are also missing. Similarly, the s enariopresumes that the appli ations are the sole running appli ations on their host devi e, andtherefore the s enario does not take into a ount some features su h as demand from otherappli ations for omputing resour es of that host devi e.Although the STEAM emulation s enario as des ribed does not a ount for these �real-world� on erns, the s enario ould have been extended to take these aspe ts into a ount.The s heduling omponent of the PiCSE ore has a fa ility for delaying the exe ution of anappli ation, allowing for some rudimentary simulation of the delayed or even failed exe utionof an appli ation. The network simulation omponent an drop pa kets probabilisti ally, and an be integrated into a third party network simulator to take advantage of existing provennetwork simulation models. Finally, all physi al artefa ts within this s enario an be extendedto take into a ount aspe ts of physi al omponents su h as failure and human behaviour.Indeed, the next two s enarios that are presented examine some of these aspe ts.152

Chapter 5. EvaluationMetri s STEAM Emulations enarioThe number of diverse instan es of all hardware omponents.1 1 obje t type, 1environment typeThe number of instan es of emulated omponents, bothappli ations and middlewares.1 2 appli ations, 1middleware instan eThe number of instan es of omponentinter-relationships, whi h is de�ned as an intera tionbetween two separately reated instan es of PiCSEabstra tions.2 1 obje t-environmentrelationship, 1appli ation-middlewarerelationship, 1appli ation-obje trelationshipThe number of instan es of inherited reusableabstra tions. 1 middleware instan eMeasure the proportion of the simulation that is omprised of re-usable domain spe i� elements. 53.1% of 898 LOCThe proportion of the simulation that is provided bythe PiCSE frameworks ore lasses.3 79.7% of 4429 LOCDemonstration of network fun tionality in appli ations enarios. TRUEDemonstration of eviden e of evaluation supportfun tionality. FALSETable 5.6: Requirements analysis for the STEAM emulation s enarioEvaluating the PiCSE requirementsThe out omes of this s enario and its subsequent analysis are summarised in table 5.6 . Therequirements are measured with respe t to their asso iated metri s whi h were identi�edin se tion 5.2 of this hapter. This s enario provides a demonstration of almost all of thebasi fun tionalities provided by the PiCSE framework. Instan es of almost all of the mainsoftware and hardware abstra tions were reated and some heterogeneous intera tions betweensome of these instantiations were also demonstrated. Note 3 of this requirements analysishighlights that the framework an provide up to 80% of the e�ort required in reating thebasi omponents that this typi al pervasive omputing s enario requires.A �nal over-ar hing analysis of the requirement satisfa tion a ross all three s enarios is ompleted in the �nal se tion of this hapter.153

5.4. The Car Hardware S enario

Figure 5.21: Photograph of the hardware being emulated.5.4 The Car Hardware S enarioThe ar hardware s enario is the se ond s enario used to validate the PiCSE framework. Thereal-world equivalent of this s enario was �rst des ribed in (Senart 06) and was presentedas a potential appli ation for the MoCoA framework, a software framework for supportingthe development of ontext aware appli ations. This appli ation s enario envisages a sentientrobot, an autonomous mobile robot with onboard sensors, whi h is ontrolled by an appli ationdeveloped using the MoCoA framework, with the ability to read sensor data from those sensorsand then reason and a t upon that sensor data.A prototype of this s enario was onstru ted using the hardware shown in �gure 5.21. Two sensors, a ompass and a sonar sensor are atta hed to a PIC mi ro- ontroller boardwhi h is physi ally atta hed to a re-purposed remote- ontrol ar. These sensors periodi allymeasure the distan e to, and the relative orientation of the lo ation of any dete ted obsta- les. An appli ation hosted on an IPAQ PDA devi e, running a slim-line Linux distribution,implements low-level fun tionality that reads the raw sensor data from the abstra t Linux�le-system.The embedded nature of this s enario, albeit in the ontext of a mobile robot is typi al of154

Chapter 5. Evaluationpervasive omputing s enarios. Sensor data samples real world phenomenon and is onsumedand reasoned upon, until some a tionable de ision is rea hed and some hanges are a�e ted,sometimes with the appli ation itself as is the ase in ontext-aware omputing, but oftenin the environment. This is more typi ally seen in ambient assisted living or smart spa es enarios. In ontrast to the STEAM s enario presented in se tion 5.3, this s enario was hosen as it re�e ted the sometimes embedded nature of pervasive omputing appli ations.In these s enarios, appli ations are typi ally no longer written upon middleware frameworksbut dire tly upon appli ation programming interfa es provided by an operating system.5.4.1 S enario Modelling requirementsThe high level set up of this s enario is shown in �gure 5.22 . The modelling of the emulatedFigure 5.22: The hardware setup of the Car Hardware S enario. The program running onthe IPAQ, onsumes sensor data via the PIC board.intera tion between the hardware and software omponents, whi h is mediated by an emulatedLinux operating system is aptured and is the primary fo us of this s enario. By modellingthis intera tion, it will be demonstrated that PiCSE an emulate ertain pervasive omputingappli ations that are built dire tly upon API's of an operating system as well as emulatingappli ations that are built upon pervasive omputing middlewares.Two features of this s enario must be modelled by the PiCSE instantiation in order forthe evaluation s enario to be validated.Emulation of system all based programming interfa es. This s enario shouldvalidate the framework's ability to emulate at the level of system alls. The s enario should155

5.4. The Car Hardware S enariotherefore in lude an appli ation that is built upon a representative sample of these types ofsystem alls.Realisti modelling of the intera tion between simulated and emulated hardware omponents. The realisti modelling of the intera tion and behaviour between the sensorsand the appli ation is riti al to this s enario. In order to be able to state that the PiCSEframework an emulate these hardware omponents, the appli ation in this s enario shouldbehave as if it was intera ting with real sensor devi es and do so without modi� ation.The s enario's modelling requirements are ompleted by imagining a third party viewerwho wishes to observe and apture aspe ts of the s enario for o�ine post-experimental analy-sis. The s enario should demonstrate the fun tionality required to support su h a viewer andre ord his events of interest.5.4.2 Building the S enarioThere are three physi al and two software modelling aspe ts to this s enario. The two sen-sors are implemented as instantiations of the Sensor abstra tion. An instantiation of anEntityLayer abstra tion models the lo ation of obsta les that the sonar sensor an de-te t. A Mobility_Obje t is used to model the remote- ontrolled vehi le. The Linux op-erating system, on whi h the IPAQ appli ation runs, is aptured as an instantiation of theExe utionEnvironment abstra tion, while the IPAQ appli ation itself, is in orporated usingan instantiation of the Appli ationWrapper abstra tion.Modelling the s enario's software omponentsThe IPAQ appli ationThe program that is running on the IPAQ is implemented as a single lass that in ludes anin�nite while-loop whi h is an a suspended state until a sensor reading is reated and theappli ation is noti�ed. The appli ation then reads and validates the sensor reading and raisesan event whi h ould then be onsumed by a separate navigation module. In the simulation of156

Chapter 5. Evaluation27. fd = open(DEVICE, O_RDWR | O_NOCTTY | O_NDELAY);84. rv = sele t(fd+1, &read_fds, NULL, NULL, NULL);87. res = read(fd, buffer, 1);249. lose(fd);Figure 5.23: System alls made by the IPAQ appli ationthis s enario, the fo us is on the realisti emulation and intera tion between the sensors andthe appli ation so the navigation module and its logi is not in luded as part of this s enario.Within PiCSE, this appli ation is handled in the normal way. An instantiation of theAppli ationWrapper lass, Chs_Wrap, initialises the IPAQ appli ation by invoking the ap-propriate method of the appli ation lass, in this ase, its onstru tor, CarHardwareSensor().The appli ation's while-loop is implemented as a single thread that is waiting on hara terevents to o ur on an open �lestream. The thread is blo ked while no new hara ters areavailable at that �le-des riptor and is only awakened when a sensor pushs a hara ter tothat des riptor. The appli ation makes referen es to four di�erent system alls within itsimplementation and these are listed in �gure 5.23 . These system alls are the bridge betweenthe appli ation and its sensors, via all used to intera t with the underlying �le-system. In orderfor the emulated version of this appli ation to behave without modi� ation, these system allsshould be implemented and emulated by some aspe t of the PiCSE framework. Fortunately,this is handled by a new instantiation of the Exe utionEnvironment lass.The Linux_Exe utionEnvironment InstantiationAn instantiation lass of the Exe utionEnvironment abstra tion,LinuxExe utionEnvironment, is implemented to emulate the Linux operating system.This instantiation lass provides the emulated equivalent of the system alls that are madeby the IPAQ appli ation. The mapping between these system alls and their emulatedequivalent is listed in table 5.7 . For example, the appli ation invokes the system allint open (__ onst har* __file, int __oflag, ...)157

5.4. The Car Hardware S enarioLinux System Call Emulated System Callint open (__ onst har* __�le, int__o�ag, ...); int open (__ onst har* __�le, int__o�ag, ...);ssize_t read (int __fd, void *__buf,size_t __nbytes) __wur; ssize_t read (int __fd, void *__buf,size_t __nbytes) __wur;int lose (int __fd); int lose (int __fd);int sele t (int __nfds, fd_set *__restri t__readfds, fd_set *__restri t__writefds, fd_set *__restri t__ex eptfds, stru t timeval *__restri t__timeout); int sele t (int __nfds, fd_set *__restri t__readfds, fd_set *__restri t__writefds, fd_set *__restri t__ex eptfds, stru t timeval *__restri t__timeout);Table 5.7: Mapping from system alls to their emulated equivalentThis fun tion tries to open the �le __�le, and returns a �le des riptor, an integer,used as a handle subsequently by the appli ation to read data from that �le. TheExe utionEnvironment abstra tion provides an abstra tion of a single �le, PFile, and a olle tion of these PFiles, analagous to a �lesystem, an be addressed by a har* key string.When the program running on the IPAQ, invokes the open(...) fun tion, it is transparentlyredire ted to the LinuxExe utionEnvironment equivalentint LinuxExe utionEnvironment::open_lo al(__ onst har* __file,int __oflag, ...)This method sear hes the Exe utionEnvironment's abstra tion of the �le-system, and returnsa �le des riptor, linked to a PFile instan e, for the parameterised �le. Subsequent alls by theappli ation to system alls su h as read(...), and write(...), that use that �le des riptor,will intera t with the asso iated PFile instan e.This redire tion is a hieved using the ompile-and-link approa h, whereby alls to thesystem API are inter epted when the program is being ompiled and are linked to the equiv-alent API of the LinuxExe utionEnvironment. At the time of the program ompilation, theIPAQ's all to in lude the appropriate de�nition �les, listed in �gure 5.24 for their respe -tive system alls are inter epted. PiCSE-spe i� versions of these header �les implement themapping that are listed in table 5.7 and that were just des ribed.158

Chapter 5. Evaluation#in lude <stdio.h> /* Standard input/output de�nitions */#in lude <unistd.h> /* UNIX standard fun tion de�nitions */#in lude <f ntl.h> /* File ontrol de�nitions */#in lude <errno.h> /* Error number de�nitions */#in lude <termios.h> /* POSIX terminal ontrol de�nitions */Figure 5.24: System all de�nition �les for the invoked system allsModelling the s enario's hardware omponentsThis s enario is omprised of four physi al omponents: an environment, �the room� in whi hthe s enario takes pla e is de�ned. There are three s enario obje ts present with that room:the vehi le, its sonar sensor and a dete table obsta le.The Room_Layer Instantiation and a Dete table Obsta leThe room is aptured as a Room_Layer whi h is an instantiation of the EntityLayer abstra -tion. It models a physi al spa e with a granularity of one metre, and that ontains a singledete table Obje t instantiations at a �xed Cartesian lo ation (10,10). This layer is queryableby a sensor instantiation.The Vehi le InstantiationThe vehi le is modelled using a ustom extended Obje t lass. This approa h was hosento demonstrate how a spe i� mobility pattern ould be implemented, thus a ommodatingmore mobility-based s enarios in addition to the frequently used random waypoint mobilitypatterns. In this instan e, the vehi le is de�ned to move from a �xed lo ation in a spe i�eddire tion and at a �xed speed.The Sonar_Sensor InstantiationThe Sonar_Sensor lass is an sub- lass instantiation of both the Sensor and Emulated ab-stra tions. The Sensor aspe t of the instantiation queries the Room_Layer for sensor data. Atthe time of onstru tion, the sensor obje t is parameterised with its data sour e, an instan eof the EnvironmentLayer abstra tion, that models the lo ation of obsta les within a physi al159

5.4. The Car Hardware S enariospa e.A sensor reading o urs when a sensor obje t takes a single reading and manipulates somedata value returned, obje t present, into the format required by the emulated interfa e. Inthe ase of this physi al sensor, the a tual sensor reading is eleven hara ters long: the �rstfour hara ters identifying the sensor; the next six hara ters provide the reading and the�nal hara ter, �/n� delineates the sequen e.In order to potentially apture some of the timing hara teristi s of an a tual sensor,this sensor model produ es two types of events: CHS_SENSE events and CHAR_ events.Creating a s heduling di�eren e between the time a sensor reading takes pla e (CHS_SENSE)and when the reading is pushed to the PIC board (CHAR_EVENT) allows a user to modela hara teristi of an a tual sensor su h as a delay. The sensor is additionally parameterisedwith the frequen y of the sensor events, in this ase, every 0.5 se onds.The Obje tLogger InstantiationFinally, an Obje tLogger is introdu ed to monitor the sonar_sensor and re ord the eventsof interest for a viewer. The Obje tLogger omponent is parameterised with an instan e ofan Obje t abstra tion and with the �le name to whi h it logs events. By default, no eventsare logged, so the Obje tLogger subs ribes to all events by invoking the Sensor abstra tion'smethod, ::Atta h(this).Interlinking of simulated hardware and software omponentsLogi al Co-lo ation of Exe utionEnvironment and Sensor Abstra tionsThe s enario requires that the urrently separated instan es of the sensor, the appli ation andits exe ution environment be inter onne ted in order to a hieve its modelling obje tive. Theappli ation should run on the exe ution environment, and should onsume sensor events thatare delivered to that exe ution environment via an emulated PIC board.Figure 5.25 shows the now familiar instantiation and o-lo ation of an appli ation withits Exe utionEnvironment. More interestingly, �gure 5.26 shows the me hanism by whi h thesensor is atta hed to its Exe utionEnvironment instan e. An instantiation of an Emulated160

Chapter 5. EvaluationLinuxExe utionEnvironment* IPAQ = new LinuxExe utionEnvironment();ChsApp* a = new ChsApp(5,LAPTOP);Figure 5.25: Co-lo ation of Exe utionEnvironment and the IPAQ appli ationSonar* sonar_sensor = new Sonar(rl,IPAQ);LAPTOP->addEmulatedHardware(sonar_sensor, "/dev/ttyS0");Figure 5.26: Co-lo ation of Exe utionEnvironment and Sensor Obje tsabstra tion, the sensor in this s enario, must be added to an Exe utionEnvironment abstra -tion in order for any potential intera tion between a Sensor and an appli ation an o ur.This binds the Emulated instantiation to a logi al point, in this ase a PFile addressed atthe lo ation "/dev/ttyS0" , within an Exe utionEnvironment. With this instru tion, anyevents raised by the sensor are pushed to the Exe utionEnvironment's emulated �le-system,whereupon the IPAQ appli ation an read and utilise them.Logi al Dependen y between Obje tLogger and the Sonar_SensorA logi al dependen y is reated automati ally between the Obje tLogger and the Obje tinstantiation, whi h is the Sonar_Sensor in this ase. The Obje tLogger is noti�ed ofall events in the ase that no parti ular event type is subs ribed to. In the ase of theSonar_Sensor instan e in this s enario, it raises TRANSFORM events, whi h are the eventsraised when a sensor takes a periodi reading. It also raises CHAR_EVENT events, whi h aregenerated when a hara ter is pushed to its Emulated instantiation. When these events o ur,all subs ribers, the Obje tLogger in this s enario, that are asso iated with the Sonar_Sensorare noti�ed. On noti� ation, the Obje tLogger re ords the event, and its timestamp withinits log�le. 161

5.4. The Car Hardware S enario5.4.3 Exe ution of the modelled domainInitialising the experimental s enarioThe reader should refer to sub-se tion 5.3.3 of the earlier STEAM s enario for a des riptionof the initialisation of the standard PiCSE omponents whi h are reated and initialised forevery simulation. A single appli ation, exe utionEnvironment and sensor are instantiated asdes ribed in se tion 5.4.2 and the s enario is now ready to be exe uted.Exe ution of the simulationThe experiment was performed on an o�-the-shelf Dell Latitude C400 laptop, equipped witha minimal 512 MB of RAM and running on Ubuntu 6.10, Edgy Eft, an open sour e operatingsystem built around the Linux kernel.The experiment was exe uted within a terminal and �gure 5.27 shows an ex erpt of thelogged output of the experiment. The output lists some s enario parameters at the outset,su h as the size of the world and the duration of the experiment. The timestamps denote thedi�erent times, in millise onds, that the listed events o urred at.1. The �rst TB_event (Thread Begin) o urs at 5 millise onds. At this timestamp, theIPAQ program has now begun, and will enter into it's paused state, waiting for a sensorevent to awaken it.2. At 500, the �rst M and Sonar events o ur. This is �rst s heduled sensor event. Thesensor takes a reading at this time and s hedules a series of serialisation events, wherebyea h hara ter of the sensor reading is written to the PFile �le-system individually. Asthere are eleven hara ters in the sensor reading, eleven E_ events are s heduled at thetimestamps 501ms, 502ms, 503ms, et up to 511ms.3. At ea h of the s heduled times, 501ms and 502ms for example, an E_ and a TS_ evento urs. An E_ event is an event of an emulated obje t, the sensor in this ase. The TSevent denotes a Thread Swit h event. This o urs when the s enario exe ution swit hesfrom the master simulation thread, whi h drives the entire experiment, to an emulated162

Chapter 5. Evaluation

Figure 5.27: A s reenshot showing the logged output from the Car Hardware S enarioevaluation.

163

5.4. The Car Hardware S enarioappli ation thread, in this ase the IPAQ appli ation whi h is reading ea h individualsensor hara ter.4. After the �nal hara ter arrives at 511ms, the appli ation outputs2 the sensor readingwhi h was been read by the appli ation. In this s enario, the sensor reading is an eleven hara ter sequen e of '0', '0', '0', '3', '0', '0', '0', '0', '0', '0', '/n'. The �rst four hara tersare to be interpreted as the sensor id, the value 3, and the �nal six hara ters denotethe a tual sensor reading, in this ase, the value 0. The appli ation outputs the sensorreading when it has read the de-limiter hara ter whi h it interprets as the end of thesequen e.5.4.4 S enario AnalysisValidation of the s enarios requirements.The s enario introdu tion outlined two requirements in order for the parti ular s enariorequirements to be validated in addition to the PiCSE evaluation requirements. The �rstrequirement, �Emulation of system all based programming interfa es�, is a hieved by theprovision of the IPAQ appli ation whi h is built upon �ve system alls whi h have been listedin table 5.7.The se ond requirement, that the intera tion between the simulated and emulated om-ponents is aptured realisti ally. By realisti ally, it is meant that the emulated omponentsprodu e the same outputs as a real sensor, and that any intera tion with an independentappli ation is the same as the original sensor upon whi h it is modelled.The outputs of the sensor have been su essfully repli ated in the simulation of this s e-nario. Eviden e of this is provided by the unmodi�ed appli ation ode implemented by theIPAQ appli ation. The ompile-and-link approa h utilised by the PiCSE framework meansthat no modi� ations are required to run the IPAQ appli ation within the framework. Theappli ations invo ations of the underlying system alls are transparently redire ted into the2The original IPAQ appli ation did not produ e this output but the program was slightly modi�ed in orderfor the logged experimental output to have some meaningful data and provide some insight into the internalworkings of the appli ation. 164

Chapter 5. EvaluationPiCSE framework where the expe ted behaviour is simulated using the analogous fun tionalityprovided by the PiCSE ore.InsightsAlthough this s enario is rather simple in terms of the number of the omponents that havebeen modelled, the modelling of the intera tion between the sensor and the appli ation isrealisti . The s enario does not pla e mu h emphasis on realisti modelling of the physi alaspe ts of the sensors a tual sensing hara teristi s, so no on lusions an be drawn regardingthe frameworks modelling of hardware omponents.The ompile-and-link approa h utilised again in this s enario has again worked su ess-fully as a se ond lass of appli ation has been su essfully emulated. The integration ofthe LinuxEmulated interfa e, and the LinuxExe utionEnvironment lass enable the emu-lated intera tion between modelled hardware and software omponents. If, theoreti ally, theSonar_Sensor was to simulate a hardware failure, and fail to send any further hara ters tothe Exe utionEnvironment, the orre t appli ation behaviour would still o ur: the programwould wait inde�nitely until the next hara ter arrives! The simulation of the sensor's be-haviour is a hieved at a high level of granularity. Individual hara ter events are simulatedand the s enario an even simulate a delay on the writing to the emulated �le-system. Thea urate modelling of the intera tion is the key feature of this s enario, and in this respe t,the framework meets the modelling requirement.Finally, one logi al dependen y was used in this s enario. The Obje tLogger omponentused PiCSE's built-in support for logi al dependen ies, to subs ribe to events generated by anObje t, in this s enario, the Sonar sensor. This lass of logi al dependen y is independent ofthe instantiations of this s enario, and this independen e o�ers further validity to the PiCSEframework's laim of �exibility and omposability.Evaluating the PiCSE requirementsThe thesis's requirements are measured for this s enario with respe t to their asso iatedmetri s and presented in table 5.8 . 165

5.4. The Car Hardware S enario

Metri s Car Hardware s enarioThe number of diverse instan es of all hardware omponents 1 environment (room), 2obje ts ( ar,sensor)The number of instan es of emulated omponents, bothappli ations and middlewares. 1 appli ation (IPAQ), 1Exe utionEnvironment(Linux)The number of instan es of omponentinter-relationships, whi h is de�ned as an intera tionbetween two separately reated instan es of PiCSEabstra tions. 1 obje t-environmentrelationship, 1 appli ation-exe utionEnvironmentrelationship, 2appli ation-obje trelationship (IPAQ-sensor,IPAQ- ar)The number of instan es of inherited reusableabstra tions. 1 exe utionEnvironment(Linux)Measure the proportion of the simulation that is omprised of re-usable domain spe i� elements. 31.6%1The proportion of the simulation that is provided bythe PiCSE frameworks ore lasses. 65.5%Demonstration of network fun tionality in appli ations enarios. n/aDemonstration of eviden e of evaluation supportfun tionality. TRUE (1 Obje tLogger)Table 5.8: Requirements analysis for the Car Hardware s enario

166

Chapter 5. Evaluation

Figure 5.28: The Dublin City road tra� networkThe Car Hardware S enario provides a se ond demonstration of the fun tionality providedby the PiCSE framework. A se ond lass of appli ation, those built upon low-level system allshave been emulated su essfully, while the ommon pervasive intera tions between hardware,A �nal over-ar hing analysis of the requirement satisfa tion a ross all three s enariosis ompleted in the �nal se tion of this hapter. software and environmental omponentshave been demonstrated again. It is noted in the table however, that the omparatively lowper entage, 31.6%, of the proportion of simulation omprised of re-usable domain spe i� elements is a ounted for by the implementation of the emulated Linux environment. A highproportion of this implementation is related to low-level fun tionality su h as thread ontroland read-write operations and a lot of this fun tionality is provided from within the PiCSE ore and not from within the a tual emulated environment whi h was reated for this s enario.5.5 The Intelligent Transportation Systems S enarioThe third and �nal instantiation of the PiCSE framework is a simulation of an IntelligentTransportation Systems (ITS) s enario. The ITS s enario is a large-s ale simulation of aportion of the Dublin City road network, shown in �gure 5.8 that is approximately 5 km2 inarea and the number of vehi les being simulated at any one time is in the order of thousands.ITS s enario's are parti ularly suited to simulation be ause of the inherent di� ulty, ost and167

5.5. The Intelligent Transportation Systems S enariorisk in evaluating the s enarios in the real world.ITS s enarios are onsidered to be part of the pervasive omputing domain, and ontainmany of the hara teristi s of typi al pervasive omputing s enarios su h as handling mobilityfor users and rea tive intelligent physi al spa es and artefa ts. The s enario has ertainproperties that exer ise elements of the PiCSE framework. There are a large number ofdependen ies, su h as the relationship of vehi les with ea h other and with other features ofthe environment su h as the tra� lights. The ITS s enario is both inherently dynami andlarge s ale and so this s enario tests those aspe ts of the framework as well. Although thereare no emulated appli ations within this s enario, there is ontrol logi in pla e that modelsthe behaviour of the tra� lights.5.5.1 S enario Modelling RequirementsThe primary motivation for hoosing the ITS s enario was both its s ale and its omplexity.A working simulation of thousands of intera ting instantiations would provide an ex ellentindi ator of the frameworks apa ity to simulate large s ale pervasive omputing s enario,whilst the variety and omplexity of the features of an ITS s enario will test the abstra tionsthat the framework provides.The s enario is omprised of a road network of 270 jun tions (nodes) and 459 roads(edges) linking those jun tions. Over a simulated two hour period, over 10,000 simulatedvehi les traverse that road network, ea h travelling a ording to its own pre-de�ned pathsand at any one time, there is approximately 1000 simulated vehi les within the road tra� network. In omparison to the �rst two s enarios evaluated for this thesis and and to otherpervasive omputing appli ation domains this is undeniably a large s ale s enario.The omplexity of the s enario is re�e ted not just in the types of omponents required tomake up the s enario but also in their internal omplexity and dependen e on other instan etypes for both their implementation and behaviour. A ri h environment model must beinstantiated apturing both stati and dynami aspe ts of the environment. A model of theroad topology is required that re�e ts the normal onstraints of what we onsider to be atra� system, su h as the number of lanes, and any speed limit that may exist on that road.168

Chapter 5. EvaluationA dynami aspe t of the environment is the modelling of the lo ation of all of the vehi les.For example, indu tive loop sensors that report the dete tion of vehi les within the lo alroad network. Tra� light a tuators are present at the in oming road at a jun tions withinthe system. They a tuate indire tly on the environment, by in�uen ing a vehi le's behaviour.Finally, the movement pattern of the vehi les (users) must also be modelled, taking intoa ount fa tors su h as lo al �rules of the road� and the position and behaviour of othervehi les amongst others.Finally, messages are ex hanged wirelessly between the tra� light ontrollers, so theinstantiation must tra k the lo ation of thousands of both mobile and stati , senders andre eivers. Although there is internal omplexity and a large amount of ontrol logi withinthe behavioural aspe t of a simulated aspe t, the s enario does not ontain any emulatedappli ations.5.5.2 Building the ModelModelling the S enario's Software ComponentsThere are no emulated appli ations or middlewares within this s enario. Any ontrol logi that governs behaviour within any of the s enario's physi al omponents su h as the vehi lesor the tra� lights are des ribed inline as part of the next se tion.Modelling the s enario's Hardware ComponentsModelling of Road Network EnvironmentThe road topology is initially des ribed in a ustom XML �le format, whi h is parsed andthen instantiated to reate the lass obje ts that are used in the simulation. In the exampleof the topology de�nition that is shown in �gure 5.29 , a jun tion with the unique ID 1526 isde�ned as a jun tion ontaining a tra� light (TL), and is lo ated at the Cartesian lo ation[379278.0, 266013.0℄. An �in omingJun tion� is de�ned, whi h is the de�nition of an road (anedge) that an arry tra� from that jun tion (1525) into the jun tion 1526. The numberof lanes (2), the length of the road (141.7m), and the max speed on the road (30 km/h)169

5.5. The Intelligent Transportation Systems S enario

<jun tionRe ><id>1526</id><type>TL</type><lo ation><xCoordinate>379278.0</xCoordinate><yCoordinate>266013.0</yCoordinate></lo ation><in omingJun tion><id>1525</id><numLanes>2</numLanes><linkDistan e>141.69333082400175</linkDistan e><maxVelo ity>30.0</maxVelo ity><outgoingJun tionRef><id>1527</id><a tionType>R</a tionType></outgoingJun tionRef><outgoingJun tionRef><id>850</id><a tionType>S</a tionType></outgoingJun tionRef></in omingJun tion>...Figure 5.29: A snippet from the ity entre.xml �le des ribing the road network topologyand onstraints.

170

Chapter 5. Evaluationare all de�ned for the in oming road. The �nal part of the in oming road de�nition is thelist of �outgoingJun tionRef�s. These are the legitimate exits that a vehi le an make whenapproa hing the jun tion 1526 while approa hing from jun tion 1525. There are two possibleexits for the 1525-1526 road segment: a right (R) turn onto the road segment 1526-1527, anda straight turn onto the road segment 1526-850. The omplete XML de�nition of jun tion1526 an be found in the appendix.An XML parser is used to parse and instantiate a series of Jun tion_Obje ts that modelthe orresponding Jun tionRe ord from the XML �le. An extension of the PiCSE Obje t lass, ea h jun tion an potentially s hedule and reate events, but in this s enario, theyare simple on eptual obje ts that have a physi al lo ation, a unique jun tion identi�er andreferen es to other onne ted jun tions.Ea h instan e of the Jun tionObje t lass is instantiated and stored in an instantiation ofan EntityLayer extension alled the RoadNetwork_EntityLayer that aptures the modellingof the stati topology of the road network. The RoadNetwork_EntityLayer lass's key-basedAPI is used by other models to query aspe ts of the road network. For example, a vehi lethat has to explore the path ahead, an use the urrent jun tion ID as the key, and an usethe returned Jun tion_Obje t to explore onne ted jun tions and hen e determine availablepaths.Modelling of Car BehaviourEa h vehi le within the s enario is modelled as an instan e of the Vehi le_Obje t lass, anextension of the Mobility_Obje t lass. Ea h Vehi le_Obje t is responsible for updating itsown position. A detailed des ription of the algorithm employed here is outside of the s opeof this thesis, but the inputs on whi h the algorithm makes it ontrol de isions are based ons enario variables that are modelled so these are dis ussed.Based on a ar-following model, the algorithm takes the following fa tors into a ount:• Status of tra� lights on the urrent road• The lo ation and status of other vehi les on that road and up oming adjoining roads171

5.5. The Intelligent Transportation Systems S enario10519,1,1,16,1169,1153,1442,984,1590,702,1589,1586,1266z,1444,1636,1483,1701,1622,1623,610Figure 5.30: A sample entry from the path de�nition �le• The topology of the road itself and its lo al onstraints• The vehi les own pre-de�ned path.Tra� Light Status The status of a tra� light obje t is determined by querying theTra� LightEntityLayer obje t using the road segment id. This returns a tra� Light obje twhi h ontains the tra� light data. Tra� light timing information is available, but only theenumerated values of red, green, and amber are used by the vehi les behavioural algorithm.Lo ation of other vehi les The modelling of the entirety of the vehi les within the networkis aptured by another instantiation of the EntityLayer abstra tion, the Vehi leEntityLayer lass. Its key-based API is used to query the EntityLayer for all vehi les on a parti ular roadsegment identi�ed by the on atenated string of two jun tion IDs. The returned vehi leOb-je ts are iterated over by the vehi le's behaviour algorithm to determine the vehi les that arenearby and theirRoad Topology Variables relating to a road segment that a vehi le is travelling on, su h asthe number of lanes, any lo al speed restri tions, and its length are all taken into onsiderationin the vehi les behavioural algorithm. The same fa tors for any outgoing roads beyond theend of the urrent road segment are also taken into a ount.Vehi le Paths Finally, the behavioural algorithm onsiders the vehi les pre-determinedpath. The vehi le path is de�ned as a series of jun tions that the vehi le must traversethrough the road network and the path begins and ends at a leaf node within the roadnetwork. Figure 5.30 shows the path de�nition for a single vehi le.1. The �rst value, 10519, is the timestamp(ms), that the vehi le will begin its journey.172

Chapter 5. Evaluation2. The se ond value, 1, indi ates the vehi le type. A �1� denotes a ar.3. The third value denotes the driver type, allowing for future types of driver behaviourto parameterised.4. The values from position four until the end are a series of jun tion IDs that the vehi lemust pass through to omplete its path. The �rst road segment will then have the ID�16-1169�, and will then turn onto the road segment �1169-1153�.In addition to the urrent road segment, the behavioural algorithm takes into a ount theup oming road segment that a vehi le will enter and uses that path information to determinethe orre t lane position for exe uting a turn onto that road segment.Modelling of Tra� Light BehaviourThe tra� light model is implemented as ombination of a ontroller and a tuators. TheTraffi LightController implements a �xed-phase y le algorithm in order to ontrol thea tions of the Approa hLights_A tuator that exists on ea h jun tion. A �xed-phase y lealgorithm is the tra� light ontrol algorithm widely used today, whereby a �xed time periodis de�ned for ea h of the tra� lights three possible states, red, green or amber.The Approa hLights_A tuator instan es are added to Traffi LightController at thestart of the framework's instantiation. The A tuators have an enumerated state, that isqueried by vehi les and is of the governing fa tors in the vehi le's behavioural algorithm.5.5.3 Exe ution of the modelled domainInitialising the Experimental S enarioBefore the simulated s enario is exe uted, two external data sour es are parsed and loadedinto the experiment.The de�nition of the vehi le's paths is ontained in a �le �data/Tra eFile_wholemap_0�,whi h ontains 10,008 vehi le tra epaths for a simulated two hour period. Figure 5.31 displaysa ode snippet demonstrating how the simulator handles so many potential event generators.173

5.5. The Intelligent Transportation Systems S enario// define the tra e sour e filestring sour es[noOfSour es℄ = { "data/Tra eFile_wholemap_0" };// Create Parsers for the tra e files and s hedule their first events.for (int s=0; s<noOfSour es; s++) {// parse the file and get the first row-entryLineParser* a = new LineParser(sour es[s℄,&network_map);long int t = a->getNextTime();if (t!=-1) {// s hedule the next ar load eventSimulator::s hedule(&generate_ ars,GENERATE_CARS,t,a);}}Figure 5.31: A se tion of ode demonstrating how the ar path �le is parsed.RoadNetworkEntityLayer network_map;jun tionParser jP(argv[ARG_JUNCTION_FILE℄, &network_map);jP.pro essXML() ;Figure 5.32: Parsing the CityCentre.xml map �leEvents are s heduled and reated for the next vehi le and path only that are ontained withinthe �le. When that timestamp is omplete and that event has been exe uted, the following en-try is read and the appropriate event is s heduled. Hen e, the number of GENERATE_CARevents that are s heduled is never more than one, and not 10,008.The de�nition of the road topology is de�ned in �data/mapFiles/ ity entre.xml� andparsed and loaded into the EntityLayer as shown in �gure 5.32 . The jun tion parser ex-tra ts the jun tion ID, and the jun tions outgoing and in oming jun tions, and from those onstru ts the appropriate road segment instan es and the vehi leEntityLayers that will storevehi le obje ts that are on those segments. The experiment is now ready to exe ute.Exe ution of the simulationFigure 5.33 show the outputs from the experiments that have been loaded into a viewer madefor this parti ular s enario. The framework logs the lo ations of the vehi les and the status174

Chapter 5. Evaluation

Figure 5.33: Two s reenshots from a visualisation of the Dublin tra� s enarioof tra� lights at ea h timestep. The �rst s reenshot shows a zoomed out partial of the mapde�ned by the ity entre.xml �le. Irish readers will note that the map entred around the ity entre of Dublin. The se ond s reenshot is a lose up from the upper left quadrant areaof the map and represents and approximate 750m long se tion of road3.The vehi les are denoted as yellow re tangles, whilst the tra� lights whi h are lo atedand interse tions between road segments are shown as small ir les with either read, green oramber.5.5.4 S enario AnalysisInsightsObserved Vehi le BehaviourVehi les follow a rather re ognisable pattern of starting slowly and respe t the distan e andspeed of vehi les in front of them and even demonstrate some ex ellent lane- hanging be-haviour in anti ipation of up oming jun tion traversals. At a ma ro level, the vehi les areseen to bun h up at tra� lights and at times of tra� ongestion. Simulated a idents anbe s heduled within the s enario. However, as the vehi les behavioural algorithm does nottake a idents and path re-routing into a ount, a rather predi table blo kage and redu edthroughput inevitably o urs.3From O'Connell Bridge at the bottom up along O'Connell St!175

5.5. The Intelligent Transportation Systems S enarioHandling The S enario ComplexityThe most di� ult aspe t of the ITS s enario was to model the omplexity of the s enarioand its omponents. Figure 5.34 shows a sequen e diagram showing the key intera tionsbetween the Vehi le_Obje t, and other simulated Obje t and Layer instan es. All of theseintera tions are supported by the underlying abstra tions, EntityLayer and A tuator. TheITS environment is a omplex layered model where EntityLayer instantiations, representingtra� , the road network itself, and tra� light a tuators intera t, sometimes expli itly tomodel a omplex s enario.The stati topology of the road network does not lend itself to the lo ation-based modelprovided by the EnvironmentLayer abstra tion. A lo ation, in this instan e would only referto a point on the road, whereas a logi al identi�er, su h as roadID an refer dire tly to the roaditself. For this reason, the EntityLayer abstra tion and its key-based API are better suitedto the modelling of the road network. For similar reasons, a key-based API is better suitedto modelling the lo ation of the vehi les themselves. In this s enario, the only intera tionbetween vehi les was the impli it intera tion that governed the vehi le's behaviour. Thisparti ular s enario did not use the lo ation-based API of the EntityLayer, but a simplehypotheti al extension of the s enario validates the EntityLayer's support for both a key-and lo ation-based API.In total, over ten thousand additional lines of ode were required to apture the s enario's omplexity. A large proportion of this was in the modelling the ars behavioural algorithm, aparti ularly omplex algorithm that had to take a number of input variables from other partsof the s enario as well as al ulating a large number of inline variables before de iding on theoptimum ar behaviour. The model of the Vehi le_Obje t's behaviour was underpinned bythe availability of the detailed model of the physi al ITS environment and its omponents.Therefore, the �exibility of the framework's abstra tions, and the support for building omplexinter-dependent abstra tions is validated. 176

Chapter 5. Evaluation

Figure 5.34: A vehi le intera ts with its environment to inform its next movement177

5.5. The Intelligent Transportation Systems S enarioHandling Large S ale S enariosAddressing the requirement identi�ed that was to support large-s ale appli ations, the ITS s e-nario su essfully modelled a large number of vehi les intera ting, and a large, albeit simpli�edmodel of an ITS wireless network. This is due in part to the physi al and logi al partitioningemployed with the EntityLayer abstra tion. The physi ally partitioned EntityLayer, wherenearby Vehi le_Obje ts are grouped together, and an be addressed by lo ation, redu esthe e�ort required by the network simulator to al ulate the number of wireless re eivers.The logi al partitioning of the spa e groups Vehi le_Obje ts into sets based on theirlo ation within the road network. This ensures that Vehi le_Obje ts only intera t withthose on the same road, and not those that are physi ally lose by but on separate roads.However, the framework's support for modelling large s ale s enarios, and this s enarioin parti ular, has not been measured. Therefore, there is no quantitative analysis of PiCSE'ssupport for large-s ale s enarios, other than to state that in this s enario, up to 1000 inter-a ting vehi les and other simulated omponents were present at any time with the s enario'ssimulated duration.Evaluating the PiCSE requirementsTable 5.9 presents the requirements analysis of this ITS s enario and measures the frameworksseven requirements against the identi�ed metri s. Of note in this s enario are the number ofinstan es of diverse instan es, 8, and the number of inter-relationships, over 20, identi�ed intable 5.9. These numbers strongly support the argument that this s enarios omplexity is avalidation of the framework's apa ity to model heterogeneous pervasive omputing s enarios.A large e�ort was required to implement this s enario. Over ten thousand ITS spe i� lines of ode were required to implement the behavioural algorithms and modelling omplexitythat formed this s enario, however a large part of that of that odebase is made of re-usable omponents that an be used in future ITS simulations and is now in the form of an ITSPiCSE sub-framework. The omplexity required to model the s enario's behaviour again isre�e ted in the relatively low ratio (24%) between the PiCSE ore lasses and the overall s e-nario implementation. The impli ations of this are now dis ussed in the overall requirements178

Chapter 5. EvaluationMetri s ITS s enarioThe number of diverse instan es of all hardware omponents 3*obje ts instan es ( ar,tra� light, jun tion),4*entityLayers(Jun tionLayer,Vehi leEntity-Layer,Tra� LightEntityLayer,1* a tuator (TL_a tuator)The number of instan es of emulated omponents, bothappli ations and middlewares. n/aThe number of instan es of omponentinter-relationships, whi h is de�ned as an intera tionbetween two separately reated instan es of PiCSEabstra tions. 20+The number of instan es of inherited reusableabstra tions. 4 primary (Car_Obje t,TL_Obje t,Jun tion_Obje t,RoadEnvironmentLayer)Measure the proportion of the simulation that is omprised of re-usable domain spe i� elements. 57.7% of 11,128 LOCThe proportion of the simulation that is provided bythe PiCSE frameworks ore lasses. 24% of 14,659 LOCDemonstration of network fun tionality in appli ations enarios. n/aDemonstration of eviden e of evaluation supportfun tionality. ITS s enarioTable 5.9: Requirements analysis for the ITS s enario

179

5.6. Requirements Validation and Con lusionvalidation and the hapter's on lusion.5.6 Requirements Validation and Con lusionThis hapter presented three distin t instantiations of the PiCSE framework. Overall, theseinstantiations exer ised the framework's �exibility and extensibility through the implementa-tion of a diverse range of simulation and emulation modelling requirements that were drivenby the s enario's requirements. Although the requirements were met by the ar hite turaldesign and implementation of the framework, the purpose of these three s enarios was tovalidate the approa h and hypothesis of the thesis.5.6.1 Requirements R1, R2, and R3The modelling of both hardware and software omponents is provided by the high-level lasses, Sensor, A tuation, EnvironmentLayer, EntityLayer, Appli ationWrapper andExe utionEnvironment and their respe tive inherited lasses. PiCSE's support for mod-elling multiple simulated heterogeneous hardware and software elements and the framework's�exible implementation allows the potential intera tion, ombination and inter-dependen e ofthese omponents without restri tion. The frameworks support for this is demonstrably learin table 5.10 whi h outlines the many s enario instan es that were reated using the PiCSEframeworkTable 5.11 , summarises the implementations of the key abstra tions that were identi�ed.The three s enarios ne essitated a diverse number of instantiations of the abstra tions, bothsoftware and hardware, that are supported by the PiCSE framework. In addition, as seenin the s enario des riptions there were many dependen ies aptured as intera tions betweenthese instantiations.Overall, the �exible instantiation of multiple abstra tions, of both software and hardwareelements, veri�es the framework's meeting of requirements R1, R2, and R3 and these havebeen met by the ar hite ture, design and implementation of the framework.180

Chapter5.EvaluationMetri s STEAM Emulations enario Car Hardware s enario ITS s enarioThe number of diverse instan es ofall hardware omponents 1 obje t type, 1environment type 1 environment (room), 2obje ts ( ar,sensor) 3*obje ts instan es ( ar,tra� light, jun tion),4*entityLayers(Jun tionLayer,Vehi leEntity-Layer,Tra� LightEntityLayer,1* a tuator(TL_a tuator)The number of instan es of emulated omponents, both appli ations andmiddlewares. 2 appli ations, 1middleware instan e 1 appli ation (IPAQ), 1Exe utionEnvironment(Linux) n/aThe number of instan es of omponent inter-relationships, whi his de�ned as an intera tion betweentwo separately reated instan es ofPiCSE abstra tions. 1 obje t-environmentrelationship, 1appli ation-middlewarerelationship, 1appli ation-obje trelationship1 obje t-environmentrelationship, 1appli ation-exe utionEnvironmentrelationship, 2appli ation-obje trelationship(IPAQ-sensor,IPAQ- ar)20+

Table 5.10: Overall requirements analysis for R1, R2 and R3

181

5.6. Requirements Validation and Con lusionSTEAMEmulation

CarHardwareEmulation

DublinTra� Simulation

Sensors n/a • •Hardware A tuators n/a n/a •Flexibility Environment ◦ • •Mobile nodes ◦ ◦ •Software Middleware • n/a n/aFlexibility HW Component n/a • n/aTable 5.11: The hardware and software models required by the three evaluation s enarios5.6.2 Requirement R4The support of the PiCSE framework's ar hite ture to address the requirement of extensi-bility is met by two aspe ts of its design. An instantiation of the PiCSE framework anitself be a domain-spe i� sub-frameworks, omposed of extensions of the software and hard-ware abstra tions provided by the PC_Abstra tions lass ategory. Additionally, the Ab-stra t_Interfa es lass ategory provides a set of interfa es that allow the development ofnew abstra tions that are not urrently modelled within the existing framework implemen-tation. These extensions an intera t and interoperate with the existing PiCSE_Core andthe existing abstra tions. Additionally, the split-level design of the framework's emulation omponent allows new emulation appli ation APIs to be added when in the future when newplatforms or middlewares emerge.Table 5.12 demonstrates the number of lines of ode and the instan es from the three s e-narios that ould be re-used in future simulations. Only one of the s enarios, the Dublin traf-� s enario, was implemented as an intelligent transportation systems (ITS) sub-framework,although all three instantiations ould be extended if required. The tra� simulator hassubsequently been extended to implement a range of tra� light ontroller algorithms, andevaluate vehi le oordination and planning algorithms. As there is only one instan e of a182

Chapter 5. EvaluationMetri s STEAMEmulations enario Car Hardwares enario ITS s enarioThe number of instan es ofinherited reusableabstra tions. 1 middlewareinstan e 1 exe utionEnvi-ronment(Linux) 4 primary(Car_Obje t,TL_Obje t,Jun tion_Obje t,RoadEnviron-mentLayer)Measure the proportion ofthe simulation that is omprised of re-usabledomain spe i� elements. 53.1% of 898 LOC 31.6%1of 1856LOC 57.7% of 11,128LOCTable 5.12: Overall requirements analysis for R4Metri s STEAMEmulations enario Car Hardwares enario ITS s enarioThe proportion of thesimulation that is providedby the PiCSE frameworks ore lasses. 79.7% of 4429LOC 65.5% of 5387LOC 24% of 14,659LOCTable 5.13: Overall requirements analysis for Requirement 5.sub-framework, this requirement is only partially validated. These fun tionalities and designfeatures meet the framework's extensibility requirement, R4.5.6.3 Requirement R5The PiCSE_Core framework engine omprises of a set of omponents that are ommon toall PiCSE simulations. The PiCSE_Core engine was re-used without modi� ation a ross allthree s enarios and table 5.13 lists the per entage of the s enario simulation that was providedby the PiCSE ore. The wide varian e in the per entages listed is in inverse proportion to the omplexity of the s enario, but what the �gures learly show is that for small s ale s enar-ios with a limited numbers of modelled omponents, PiCSE arguably provides a signi� antproportion of the foundations for the development of those simulations.This reusable engine, and the identifying of re urring software patterns that are aptured183

5.6. Requirements Validation and Con lusionMetri s STEAMEmulations enario Car Hardwares enario ITS s enarioDemonstration of eviden eof evaluation supportfun tionality. FALSE TRUE (1Obje tLogger) Yes. Logging ands enario logviewer.Table 5.14: Overall requirements analysis for Requirement 7.within the lasses for the hardware and software elements, and their inter-dependen ies meetsthe framework's reusability requirement, R5.5.6.4 Requirement R6The PiCSE framework provides two feature that address the aspe t of network simulationwithin pervasive omputing s enarios. The Net_Interfa e lass and the underlying NetworkManager omponent provide a rudimentary API for the simulation of network behaviour.The STEAM emulation s enario and the Dublin tra� s enario both utilise the basi networksimulation omponent. Both s enario's are omprised of both stati and mobile nodes, and thetra� s enario has implemented but not demonstrated both wired and wireless ommuni ation hannels.Networked ommuni ation between ITS omponents is frequently posited as a means ofaugmenting and improving a drivers experien e whilst driving, and as a means of maximisingvehi le throughput through a road network. The ITS PiCSE s enario a ommodates theses enarios by extending the s enario's omponents with the Net_Interfa e lass enabling theex hange of messages a ross simulated wired and wireless networks.These aspe ts of the s enario verify the framework's basi network simulation fun tionality.and this requirement, R6, has been validated.5.6.5 Requirement R7The PiCSE framework's provides a �exible API that allows a developer to spe ify time win-dows, where the the behaviour and state of obje ts of interest within a simulation is re orded.As shown in table 5.13 , two of the three s enarios utilised experimental logging during184

Chapter 5. Evaluationtheir exe ution, whether to verify the orre t fun tioning of the STEAM event middleware,or to log and subsequently view the orre t vehi le behaviour. The implementation of thislogging using PiCSE's API validate the framework's requirement R7.5.6.6 Con lusionAll requirements whi h address the ore hallenges identi�ed in hapter 1 have been fullymet in the design of the ar hite ture and implementation of the PiCSE framework. Thes enarios presented in this hapter are drawn from a broad spread of pervasive omputingappli ation domains, and present a wide range of individual requirements that the frameworkdemonstrably meets.The framework's elegan e in handling the diversity of these s enarios will still providing ameaningful and extensible odebase from whi h to develop future simulations in other domainsis validation of its approa h, ar hite ture and implementation. Furthermore it is a validationof the hypothesis of this thesis that it is possible to reate su h a framework for the simulationof pervasive omputing s enarios.

185

Chapter 6Con lusionsThis thesis presented the ar hite ture, implementation and evaluation of PiCSE, a frameworkwhose abstra tions an be instantiated to reate simulations of, and simulators for, pervasive omputing appli ations. This hapter on ludes the thesis by restating the hallenges in reating a generi approa h to this task, and presents the main ontributions of this thesis inaddressing those hallenges. The ontribution of the thesis is positioned with respe t to thestate of the art, and �nally, potential future work is explored.6.1 The Challenge RestatedSimulation an provide a qui k and ost-e�e tive evaluation tool, that addresses some ofthe di� ulties in evaluating pervasive omputing appli ations. There have been several at-tempts to provide a generi tool supporting the simulation of this domain; however, they haveonly met with limited su ess. Previous work in this area has largely fo used on develop-ing models of the physi al environment, and emulating appli ations that exist within thatenvironment. The modelling of hardware devi es, su h as sensors and a tuators, that existwithin those environments, and are an integral part of those environments, has been largelyisolated. Approa hes to building these generi tools have been entred around the extensionof existing established simulators of sub-domains of pervasive omputing su h as wireless sen-sor networking, or graphi al environmental simulators. However, these approa hes have been187

6.2. The Contributiondemonstrated to be insu� iently �exible in being able to integrate aspe ts of other pervasive omputing sub-domains in a generi manner. The open resear h hallenge in this �eld is toinvestigate whether a generi simulator an be developed that an model a broad range ofexisting pervasive omputing appli ations as well as new appli ations that may emerge in thefuture.6.2 The ContributionThe multi-dis iplinary and evolving nature of the domain has ne essitated the developmentof a more �exible and extensible approa h to the building of these tools, an approa h that aptures and re�e ts re urring features and patterns of pervasive omputing appli ations. The ontribution of this thesis is the validated de�nition and ar hite ture of a framework-basedmethodology for the modelling of pervasive omputing s enarios.The PiCSE framework adopts a bottom-up approa h to addressing the modelling of per-vasive omputing s enarios whereby �exibility, extensibility, and reusability are prioritisedas ore features of the framework's ar hite ture. In the examination of the state of the art,re urring themes were identi�ed that were ommon to many pervasive omputing s enarios.These re urring themes, su h as ommon devi es, re urring intera tion patterns were sim-pli�ed from their implementations, and fundamental abstra tions were derived and apturedwithin the framework to implement these themes. The ontribution of the framework hasbeen implemented as three lass ategories, ea h of whi h addresses one of the ore hallengesidenti�ed. The PC_Abstra tion lass ategory aptures a re urring set of abstra tions, su has sensors, a tuators, the environment, and appli ations, that may be freely ombined in a�exible and heterogeneous manner to reate simulations of omplex appli ation s enarios. TheAbstra t_Interfa es lass ategory provides the de�nition of a set of fundamental abstra tionsthat an be extended to a ommodate new appli ation areas that may emerge in the pervasive omputing domain. Finally, the PiCSE_Core lass ategory provides a ommon base uponwhi h all instan es of the framework are built and its generi ar hite ture and implementationaddresses the hallenge of reusability.This approa h ontrasts dire tly with the work of many of the simulators presented in188

Chapter 6. Con lusions hapter 2. For example, with the ex eption of UbiREAL, the simulators that hoose toimplement models of the physi al environment have all done so using 3-d modelling tools.PiCSE's approa h, whi h is similar to that of UbiREAL, begins at the bottom, enabling themodelling of the most simple and basi measurable phenomena. If more omplex environmentsare required, then arbitrarily omplex environments an be built from the abstra tions that apture these phenomena. In ontrast to UbiREAL, PiCSE adopts this philosophy in theimplementation of all of its abstra tions, whereas UbiREAL only implements its environmentin this manner.Three instantiations of the framework were presented in hapter 5, that were representa-tive of the diverse range of typi al pervasive omputing appli ations. These s enarios variedin their requirements, s ale and omplexity. From simple obje ts moving in pre-de�ned mo-bility patterns, to vehi les that implement omplex behavioural patterns, and from emulatingmessage-oriented middlewares to sensor-driven embedded appli ations, the abstra tions sup-porting these models have proven to be su� ient in enabling the modelling of many pervasive omputing domains. It is therefore reasonable to on lude that using a framework is a suit-able approa h that meets the requirements of modelling a wide range of pervasive omputingdomains.6.3 Lessons LearnedSome limitations to the approa h hosen have been identi�ed and exposed through the eval-uation s enarios. The limitations of using a single ma hine are perhaps not so importantthese days with heaper hardware and pay as you go solutions in the loud now growing inpopularity but the approa h utilised in this thesis has pla ed limitations on the number and omplexity of appli ations that an be simulated at any one time. Whilst, the ompile-and-link approa h to emulating appli ations proved feasible for the evaluation of this thesis, amore robust ar hite ture utilising virtual ma hines would be required to provide a really �ex-ible approa h to appli ation emulation. This is arguably a limitation of the implementationof the framework rather than a material �aw within the approa h of using a framework itself.With respe t to the evaluation and validation of the thesis, it has been observed that189

6.4. Future Workas the omplexity of a simulated s enario grows, the more domain spe i� knowledge andmodelling is required. As the ITS s enario demonstrates, the PiCSE framework an simplifythe modelling of the omponents, it an provide a skeleton around whi h a developer an bringdepth and omplexity, but it is up to that user to provide that domain spe i� knowledge. ThePiCSE framework only promises a framework and an give a user with the inputs, however,domain-spe i� behavioural logi and omplexity an require a lot of additional work to bringa s enario to life. There is only so mu h a framework an provide!6.4 Future WorkThere are numerous potential dire tions that this work ould take in the future. At present,there are limitations within the urrent implementation that ould be addressed in the shortterm.The a urate modelling of failure has been an integral part of simulation for wireless sensornetworks for a long time, however this feature has yet to ross over into the pervasive om-puting simulator domain. None of the seven simulators explored in hapter 2 have addressedthis issue, but its su essful integration is an important requirement for the future. Buildingrobust algorithms, for example inferen e engines, that are fault tolerant and robust in thepresen e of both error-prone and ina urate hardware, is an ongoing area of resear h withinthe pervasive omputing ommunity. At present, there is no support for modelling the failurethat is often present in pervasive omputing domains. Modelling failure at the software levelwould be a wel ome development. PiCSE's thread manager omponent provides rudimen-tary support for �killing� an appli ation, however, in order to ontinue with the framework'stheme of �exibility, the Exe utionEnvironment and Appli ationWrapper abstra tions shouldbe extended to supporting the varying degrees of failure. The se ond short-term goal is theextension of the framework's emulation apabilities to support multi-threaded appli ationsand to provide bindings for other programming languages beyond C++ so that appli ation ode from other appli ations might be integrated.The PiCSE ITS sub-framework has been used a simulation tool for a variety of appli ationdomains within the intelligent transportation systems resear h �eld. Resear h investigating190

Chapter 6. Con lusionsinter-tra� light ommuni ation as a means of maximising vehi le throughput by oordinatingtra� light behaviour has been arried out by several authors in luding (Salkham, 2010) and(Duspari 2009).It ould be argued that in these heady days of loud omputing, and the relatively heapvirtualisable hardware providers su h as Amazon, that the days of having a simulator or asimulator framework that an run in your lo al desktop ma hine or a server are numbered.Whilst there will always be a ase for outsour ing omputing power and and frameworks thatmay run upon them, there still exists a ni he requirement for a simulation tool that is resear hfo used and allows the rapid prototyping of experiments and s enarios. A ess to testbeds isalso in reasing but again doesn't o�er the immedia y of a lo al ma hine, that doesn't requires heduled a ess. For how long this remains the ase is open to debate.In the longer term, the future work that will emerge will depend on the dire tion thatpervasive omputing moves in. Five years ago, many pervasive omputing systems were basedupon embedded sensors ommuni ating using wireless te hnologies, yet right now, new avenuesof resear h within pervasive omputing su h as so ial-sensing, and pervasive health- are areemerging due to the proliferation of smart phones su h as the Apple IPhone. The de reasing ost of these devi es and wider network onne tivity are ushering in a new aspe t of pervasive omputing where the power and ontrol of these sensing devi es rests with the user and notjust in the physi al spa es o upied by those users. The smart phone's in reased ability to ontextualise and understand its environment and its ability to integrate with servi es bothlo ally and on the web make it is di� ult to predi t what new appli ation areas will emerge inthe future within pervasive omputing, however the PiCSE framework's �exible and extensiblear hite ture will be at the entre of evaluating those appli ation areas.

191

Appendix AAppendixA.1 PiCSE Ar hite ture Header FilesFigureA.1 gives an overview of the PiCSE ar hite ture and an be used when onsideringthe sour e header �les in luded below. The sour e �les in luded below are drawn from thear hite ture's three lass ategories, whi h are des ribed in hapters 3 and 4. FigureA.2outlines the distribution of the header �les a ross the three lass ategories.

Figure A.1: Ar hite ture Diagram for typi al instantiation193

A.1. PiCSE Ar hite ture Header Files

Figure A.2: Class Category distribution of header �les.PC_Abstra tion lass ategoryThese �les are the header �les for the lass de�nitions ontained with the PC_Abstra tion lass ategory. For an explanation of the lasses and their ar hite ture, please refer to hapter3 of this thesis.environmentalLayer.h#ifndef RPS_LAYER#define RPS_LAYER#in lude "simulator.h"#in lude "layer.h"#in lude <ve tor>#in lude <list>///// TO DO//implement dtors properly and deallo ate memory./*** EnvironmentLayer's are used to model an aspe t of the physi al* environment. Perhaps they would be better refa tored to be* environmental layers.*/ 194

Appendix A. Appendix lass EnvironmentLayer: publi Layer{publi :EnvironmentLayer(long double granularity=100,long int period=0);/*** Abstra t populate fun tion alled to instantiate values* Not sure why this is needed. Clarify!*/virtual void populate() = 0;/// S hedule initial events. Again not sure why this is required.virtual void setInitialEvents() = 0;/*** Default is to not subs ribe to any events so this is an empty method.* Note that this is virtual so inheriting lasses an over-write as appropriate.*/virtual void Update(Observable* sr ){}/*** Default is to not subs ribe to any events so this is an empty method.* Note that this is virtual so inheriting lasses an over-write as appropriate.*/virtual void Update(Observable* sr , int event){}prote ted:private:void registerSelf();};/*** Extends the EnvironmentLayer to add a grid of doubles.* Also in ludes double-based set'ers and get'ers*/ lass DOUBLE_EnvironmentLayer: publi EnvironmentLayer{publi :DOUBLE_EnvironmentLayer(long double granularity=100,long int period=0); 195

A.1. PiCSE Ar hite ture Header Files~DOUBLE_EnvironmentLayer(){}void setState(Lo ation, double);double queryState(Lo ation);double getStateAverage();double** getGrid();prote ted:double** grid;private:};/*** Extends the EnvironmentLayer to add a grid of Int's.* Also in ludes int-based set'ers and get'ers*/ lass INT_EnvironmentLayer: publi EnvironmentLayer{publi :INT_EnvironmentLayer(long double granularity=100,long int period=0);~INT_EnvironmentLayer(){}void setState(Lo ation, int);int queryState(Lo ation);int getStateAverage();//need to make this prote ted or somethingint** getGrid();prote ted:int** grid;private:};/*** Extends the EnvironmentLayer to add a grid of Float's.* Also in ludes float-based set'ers and get'ers*/ lass FLOAT_EnvironmentLayer: publi EnvironmentLayer{publi :FLOAT_EnvironmentLayer(long double granularity=100,196

Appendix A. Appendixlong int period=0);~FLOAT_EnvironmentLayer(){}void setState(Lo ation, float);float queryState(Lo ation);float getStateAverage();float** getGrid();prote ted:float** grid;private:};ostream& operator<<(ostream&, DOUBLE_EnvironmentLayer&);ostream& operator<<(ostream&, INT_EnvironmentLayer&);ostream& operator<<(ostream&, FLOAT_EnvironmentLayer&);#endifentityLayer.h#ifndef REF_LAYER#define REF_LAYER#in lude "simulator.h"#in lude "layer.h"#in lude <ve tor>#in lude <list>#in lude <map>///// TO DO// Implement dtors properly, deallo ate memorytypedef std::list<Obje t*> GROUP_OF_OBJECTS;typedef std::map<string, Obje t*> FLAT_LIST_OF_OBJECTS;/// Indi ates whether obje ts update themselves or if layer updates them as a whole.197

A.1. PiCSE Ar hite ture Header Filesenum UPDATE_TYPE {SELF, AUTO_T};/// Types of events generatedenum ENT_LAYER_EVENT_ID {ENT_LAYER_TRANSFORM_EVENT = 0, // Layer has updatedOBJECT_TRANSFORM_EVENT }; // Obje t has joined or left/*** A lass that ontains referen es to entities.* Provides fun tionality for managing groups of similar types of polymorphi obje ts.* These are grouped into lists of obje ts whi h are maintained in a grid.* See user do umentation for greater detail.*/ lass EntityLayer: publi Layer{publi :EntityLayer(long double granularity = 100,long int period = 0,UPDATE_TYPE = SELF); /// default is for obje ts to update themselves~EntityLayer();void addObje t(Lo ation,Obje t*);// adds it to a flat list a essed by key stringvoid addObje t(string, Obje t*);// why not pass in lo ation parameter here?void removeObje t(Obje t*);// remove obje t from flat_listvoid removeObje t(string);// retrieve a pointer to an Obje t based on string key// returns NULL, if no Obje t found.Obje t* getObje t(string);/// Updates the grid lo ation of an obje t.void updateObje tsGridLo ation(Obje t* o);/// Updates the grid lo ation of an obje t. This version used after a transfer of ownership has o urred.void updateObje tsGridLo ation(Obje t* o, Lo ation previousLo ation);GROUP_OF_OBJECTS* getObje tsWithinRange(Lo ation, long double);GROUP_OF_OBJECTS* getObje tsWithinBoundingRe tangle(Lo ation, Lo ation);void transform(); 198

Appendix A. AppendixGROUP_OF_OBJECTS** getGrid();FLAT_LIST_OF_OBJECTS* getList();/*** Default is to not sus ribe to in oming events.* EntityLayers an be inherited from if a user wishes to subs ribe to be notified of published events.*/virtual void Update(Observable* sr ){}virtual void Update(Observable* sr , int event){}virtual void doEvent(int eid);bool loseEnoughToRe eive(Lo ation, Obje t*, long double);prote ted:private:/// Registers itself with the world as part of the modelvoid registerSelf(){World::registerEntityLayer(this);}void addUpdatedObje t(Lo ation,Obje t*);gridLo ation sear h(Obje t*);GROUP_OF_OBJECTS** grid;FLAT_LIST_OF_OBJECTS* flat_list;UPDATE_TYPE updateType;};ostream& operator<<(ostream&, EntityLayer&);#endif

sensor.h 199

A.1. PiCSE Ar hite ture Header Files#ifndef SENSOR#define SENSOR#in lude "environmentLayer.h"#in lude "obje t.h"enum SENSOR_EVENTS {SENSE=0};/*** A generi lass for a sensor whi h doesn't really do mu h.*/ lass Sensor: publi Obje t{publi :Sensor(long int t2s,long int p);Sensor(long int p=0);~Sensor(){}virtual void doEvent(int l);private:prote ted:};/*** A float sensor*/ lass F_Sensor: publi Sensor{publi :/// Default sensor is sporadi F_Sensor(FLOAT_EnvironmentLayer* sr , long int p=0);~F_Sensor(){}/// Returns a reading from the sour e layer using the sensors lo ationfloat getReading();virtual void transform();private:FLOAT_EnvironmentLayer* sensedLayer;};/*** A double sensor*/ lass D_Sensor: publi Sensor{publi :/// Default sensor is sporadi D_Sensor(DOUBLE_EnvironmentLayer* sr , long int p=0);~D_Sensor(){}/// Returns a reading from the sour e layer using the sensors lo ationdouble getReading();virtual void transform();private:DOUBLE_EnvironmentLayer* sensedLayer;};/*** An int sensor*/ lass I_Sensor: publi Sensor{publi :/// Default sensor is sporadi I_Sensor(INT_EnvironmentLayer* sr , long int p=0);~I_Sensor(){}/// Returns a reading from the sour e layer using the sensors lo ationint getReading();virtual void transform();private:prote ted:INT_EnvironmentLayer* sensedLayer;};#endif

200

Appendix A. Appendixa tuator.h#ifndef ACTUATOR#define ACTUATOR#in lude "environmentLayer.h"#in lude "entityLayer.h"#in lude "obje t.h"enum ACTUATOR_EVENTS {ACTUATE=0};/*** A generi lass for an a tuator whi h doesn't really do mu h.* Provides periodi /sporadi fun tionality.*/ lass A tuator: publi Obje t{publi :A tuator(long int p=0);~A tuator(){}virtual void doEvent(int l);virtual void transform(){ a tuate(); }virtual void a tuate() = 0;private:};/// An obje t a tuator lass Obje t_A tuator: publi A tuator{publi :Obje t_A tuator(Obje t* s, long int p = 0);~Obje t_A tuator(){}virtual void a tuate(){}private:prote ted:Obje t* sr ;};/// An a tuator for a ting on entity layers 201

A.1. PiCSE Ar hite ture Header Files lass EntityLayer_A tuator: publi A tuator{publi :EntityLayer_A tuator(EntityLayer* s, long int p = 0);~EntityLayer_A tuator(){}virtual void a tuate(){}private:prote ted:EntityLayer* sr ;};/// An a tuator for a ting on FLOAT based environmental layers lass Float_EnvironmentLayer_A tuator: publi A tuator{publi :Float_EnvironmentLayer_A tuator(FLOAT_EnvironmentLayer* s, long int p = 0);~Float_EnvironmentLayer_A tuator(){}virtual void a tuate(){}private:prote ted:FLOAT_EnvironmentLayer* sr ;};/// An a tuator for a ting on DOUBLE based environmental layers lass Double_EnvironmentLayer_A tuator: publi A tuator{publi :Double_EnvironmentLayer_A tuator(DOUBLE_EnvironmentLayer* s, long int p = 0);~Double_EnvironmentLayer_A tuator(){}virtual void a tuate(){}private:prote ted:DOUBLE_EnvironmentLayer* sr ;};/// An a tuator for a ting on INT based environmental layers lass Int_EnvironmentLayer_A tuator: publi A tuator{publi : 202

Appendix A. AppendixInt_EnvironmentLayer_A tuator(INT_EnvironmentLayer* s, long int p = 0);~Int_EnvironmentLayer_A tuator(){}virtual void a tuate(){}private:prote ted:INT_EnvironmentLayer* sr ;};#endifemulated.h#ifndef _EMULATED_IF_#define _EMULATED_IF_#in lude <string>using namespa e std;#in lude "exe Env.h" lass Emulated{publi :/// Set the the exe ution environmentvoid setExe utionEnvironment(Exe utionEnvironment* e);/// A pointer to the exe ution environment layer_ onor working_ba kups;Exe utionEnvironment* exe utionEnvironment;/// Set atta h point for a sensor, or a tuator.void setAtta hPoint(string);string getAtta hPoint();string atta hPoint;};#endifexe utionEnvironment.h 203

A.1. PiCSE Ar hite ture Header Files#ifndef EXECUTION_ENVIRONMENT#define EXECUTION_ENVIRONMENT//#in lude "f ntl.h"#in lude <map>#in lude <string>#in lude "obje t.h"#in lude "netif.h"using namespa e std; lass p_file; lass Emulated;typedef std::map<std::string, p_file*> dev2pfile;typedef std::map<int,p_file*> fd2pfile; lass Exe utionEnvironment:publi virtual Obje t, publi Net_interfa e{publi :Exe utionEnvironment();void addEmulatedAppli ation(Emulated* e);void addEmulatedHardware(Emulated*,string);virtual void transform(){}virtual void doEvent(int i ){}prote ted:void reateFSpa e(std::string __file);dev2pfile* d2p;fd2pfile* f2p;private:// int fd ount;};#endif 204

Appendix A. Appendixappli ationWrapper.h#ifndef APPLICATION_WRAPPER_H#define APPLICATION_WRAPPER_H#in lude <pthread.h>#in lude "simulated.h"#in lude "emulated.h"#in lude "observer.h"enum APP_EVENTS {START_APP=0};// An program emulation wrapper. lass Appli ationW :publi Simulated,publi Observable, publi Emulated{publi :/// Ctor, s hedules appli ation start time, provided exe ution env is setAppli ationW(long int t,Exe utionEnvironment*);/// Plain tor, instantiates variables.Appli ationW();/// Dtor, needs to be implemented~Appli ationW(){}/// S hedules exe ution t ms into the futurevoid s heduleExe ution(long int t);/// Returns true if exe ution env is set, false otherwisebool isExe EnvSet();/// Obtains mutexvoid getLo k();/// Invokes program. To be implemented by hild lassvirtual void run() = 0;/// Kills the urrentThread after notifying the base thread to restart it.void killThisThread();private:/// Used for thread signallingpthread_ ond_t thread_ ond; 205

A.1. PiCSE Ar hite ture Header Files/// The thread.pthread_t thread;/// s hedules start eventvoid doEvent(int);/// Starts the threadvirtual void exe ();/// Returns true if program already s heduled to start.bool started;};// Have to all a -style fun for pthread// This is a dummy oneextern void* fun (void*);#endif

206

Appendix A. AppendixCore_Components Class Category Header FilesThese �les are the header �les for the lass de�nitions ontained with the Core_Components lass ategory. For an explanation of the lasses and their ar hite ture, please refer to hapter3 of this thesis.pi se.h#ifndef _PICSE_HEADERS#define _PICSE_HEADERS/// The basi headers required.#in lude "queuing.h"#in lude "world.h"#in lude "network.h"#in lude "simulator.h"////////////////////////// Modify this to in lude all the basi headers.#in lude "obje t.h"#in lude "entityLayer.h"#in lude "environmentLayer.h"#in lude "obje tLogger.h"#in lude "environmentLayerLogger.h"#in lude "entityLayerLogger.h"#in lude "mobilityObj.h"#in lude "sensor.h"207

A.1. PiCSE Ar hite ture Header Files#endifsimulator.h#ifndef SIMULATED#define SIMULATED/*** An interfa e whi h all event generating events must inherit from.*/ lass Simulated{publi :/*** Abstra t method alled when an event is performed* �param int event id spe ifies the event to perform*/virtual ~Simulated(){}virtual void doEvent(int eventid)=0;};#endifworld.h#ifndef WORLD#define WORLD#in lude <iostream>#in lude <ve tor>#in lude <list>#in lude "message.h" lass Net_interfa e; lass EntityLayer; lass EnvironmentLayer; 208

Appendix A. Appendix lass Obje t; lass Lo ation;typedef std::list<EntityLayer*> ENTITY_LAYER_STACK;typedef std::list<EnvironmentLayer*> ENVIRONMENT_LAYER_STACK;enum DIMENSIONS{TWO_D =0, THREE_D};// singleton lass. lass World{publi :stati World* Instan e();/// Registers a layer in the worldstati void registerEntityLayer(EntityLayer*);stati void registerEnvironmentLayer(EnvironmentLayer*);/// Returns the origin of the 'world'// stati Lo ation getOrigin(){ return *origin;}stati long double getXSize(){return xSize;}stati long double getYSize(){return ySize;}stati long double getZSize(){return zSize;}stati long double getModelXSize(){return xSize + xOffset;}stati long double getModelYSize(){return ySize + yOffset;}stati long double getModelZSize(){return zSize + zOffset;}stati long double getXOffset(){return xOffset;}stati long double getYOffset(){return yOffset;}stati long double getZOffset(){return zOffset;}stati void setXSize(long double x, long double tX = 0){xSize = x-tX; xOffset = tX;}stati void setYSize(long double y, long double tY = 0){ySize = y-tY; yOffset = tY;}stati void setZSize(long double z, long double tZ = 0){zSize = z-tZ; zOffset = tZ;}// stati void setOrigin(Lo ation* l){origin = l;}/// Gets a random lo ation within the worldstati Lo ation getRandomLo ation(DIMENSIONS=TWO_D);209

A.1. PiCSE Ar hite ture Header Filesstati void registerObje t(Obje t*);/// Should be in a omms layer, delivers a message to all obje ts// stati void deliverMsg(Lo ation,Msg*);//////////////Networkingstati void registerNetIF(Net_interfa e*);prote ted:/// Default torWorld();~World();private:stati World* worldInstan e;/// Lo ation of origin ( artesian system)// stati Lo ation* origin;/// S ale of the worldstati long double xSize, ySize, zSize, xOffset, yOffset,zOffset,TRANSMISSION_RANGE, PROB_DROP_MESSAGE ;/// Layer sta kstati ENTITY_LAYER_STACK* EntityLayerSta k;stati ENVIRONMENT_LAYER_STACK* EnvironmentLayerSta k;// stati void probabilisti Deliver(Msg*, Obje t*);};//ostream& operator<<(ostream&, Lo ation&);//////////////////////////////////////// lass Lo ation{publi :Lo ation(long double xa=0, long double ya=0, long double za=0)210

Appendix A. Appendix: x(xa), y(ya), z(za){}long double x; // metreslong double y;long double z;void applyOffset(){x -= World::getXOffset(); y -= World::getYOffset();}void removeOffset(){x += World::getXOffset(); y += World::getYOffset();}};#endifnetwork.h#ifndef NETWORK_SIM#define NETWORK_SIM#in lude <string>#in lude <map>#in lude "entityLayer.h"using namespa e std; lass Net_interfa e;typedef std::map<string, Net_interfa e*> FLAT_LIST;/**Class representing wireless network. Re eivers, represented by Net_interfa e obje ts an register with the network, at a given lo ation, and are allowed to send and re eivemessages. The sending and re eiving of messages is mediated by the Network lass. Two fa torsare taken into onsideration when delivering messages. The TRANSMISSION_RANGEand PROB_DROP_MESSAGE*/ lass Network{publi :stati Network* Instan e(); 211

A.1. PiCSE Ar hite ture Header Files//////// WIRELESS/// Registers a Net_interfa e obje t for sending and re eiving messagesstati void registerNetIF(Net_interfa e*);/// Broad ast a msg void* to all re eivers within distan estati void broad astMsg(void*, Net_interfa e* );/// Broad ast a msg string to all re eivers within distan estati void broad astMsg(string, Net_interfa e* );/// Send a msg void* to a re eiver spe ified by string adrstati void uni astMsg(void*, string adr, Net_interfa e* );/// Send a msg string to a re eiver spe ified by string adrstati void uni astMsg(string, string adr, Net_interfa e* );/// Set the transmission rangestati void setTX(long double t){TRANSMISSION_RANGE = t;}/// Set the probability of dropping a messagestati void setProbDrop(long double pd){PROB_DROP_MESSAGE = pd;}///////// WIREDstati void registerLan_NetIF(Net_interfa e*);/// Send a msg void* to a re eiver spe ified by string adrstati void uni astLanMsg(void*, string adr, Net_interfa e* );/// Send a msg string to a re eiver spe ified by string adrstati void uni astLanMsg(string, string adr, Net_interfa e* );/////////// Delivers an event whi h has been s heduled in a past. This method spawns a thread.stati void deliverS heduledEvent(NetworkVoidTuple*);stati void* deliver(void*);stati void getLo k();prote ted:Network();~Network();private:/// Tra ks re eiversstati EntityLayer* wirelessLayer_Channel1;212

Appendix A. Appendix/// Flat list of wireless re eivers indexed by addressstati FLAT_LIST* all_wireless_r vrs;/// Flat list of wired re eivers indexed by addressstati FLAT_LIST* all_wired_r vrs;/// Maximum Transmission_range. Defaulpt 200mstati long double TRANSMISSION_RANGE;/// Probability of dropping message. Default .05stati long double PROB_DROP_MESSAGE;/// Deliver message void* using PROB_DROP_MESSAGE, delay timeunits into the futurestati void probabilisti Deliver(void*, Net_interfa e*, int delay = 1);/// Deliver message string using PROB_DROP_MESSAGEstati void probabilisti Deliver(string, Net_interfa e*, int delay = 1);stati Network* networkInstan e;};enum TUPLE_TYPE{STRING=0,VOIDPTR};// lass to represent a network message event// instan es deleted upon returning from delivery allba k lass NetworkVoidTuple{publi :// the intended re eiverNet_interfa e* re ;// pointer message || string message indi ated by tupleType.void* message;string messageS;//TUPLE_TYPE tupleType;};#endifmessage.h 213

A.1. PiCSE Ar hite ture Header Files#ifndef ENVIRONMENT#define ENVIRONMENT#in lude <string> lass Msg{publi :Msg(){}virtual ~Msg(){}};#endifnetif.h#ifndef NET_IF#define NET_IF#in lude <string>#in lude "obje t.h"using namespa e std;/*** Extends Obje t be ause it has an impli it lo ation*/ lass Net_interfa e: publi virtual Obje t{publi :/// Default// Net_interfa e();/// Ctor, with addressNet_interfa e(/*string a,*/bool=false);~Net_interfa e();/// Send void* parameter to everyonevirtual void send(void*); 214

Appendix A. Appendix/// Send void* parameter to parti ular addressvirtual void send(void*, string);/// Send string to everyonevirtual void send(string);/// Send string to parti ular addressvirtual void send(string, string);/// Abstra t deliver API for obje t deliveryvirtual void deliver(void*)=0;/// Abstra t deliver API for string deliveryvirtual void deliver(string)=0;/// Required for doEventvirtual void transform(){}/// Returns address if set, "" otherwisestring getAddress();Exe utionEnvironment* getExe utionEnvironment(){return asso iatedExe Env;}private:// string address;Exe utionEnvironment* asso iatedExe Env;prote ted:void setExe utionEnvironment(Exe utionEnvironment* e){asso iatedExe Env = e;}};#endiflogger.h#ifndef LOGGER#define LOGGER#in lude "observer.h"#in lude "simulated.h"#in lude "simulator.h" 215

A.1. PiCSE Ar hite ture Header Filesenum LOGGER_EVENT { LOG_EVENT = 0};/*** Logger is a lass whi h utilises event subsription servi es provided in lass Logable.* Logger is the 'observer' part of observer/observable.*/ lass Logger: publi Observer, publi Simulated{publi :Logger(){};/// Ctor takes a string and opens a file for outputLogger(string);/// Flushs the output stream and then loses it.virtual ~Logger();/*** Sets a period of time within the experiment that is to be logged.* �param time2begin is the RELATIVE time in the future that the logging is to begin at.* �param duration is the length of time to log for*/void setLoggingWindow(long int t, long int d=Simulator::getDuration()-Simulator:: urrentTime());/*** Che ks if time for one more event before end of run.* To be removed. This is an unne essary he k. Just s hedule it, and if run ends, so what.* This is more effi ient than he king every time*/bool timeForOneMoreEvent();/*** Set the logging period* �param p is the period*/void setLoggingPeriod(long int p);prote ted:/*** Che ks to see if time is within the loggingWindow set in setLoggingWindow()* �return true if in window or no window set*/ 216

Appendix A. Appendixbool he kValidLogWindow();/// Default log event to be implemented by inheritorsvirtual void log() = 0;/// Calls default log() method on s heduled log eventsvirtual void doEvent(int id);/// The output fileofstream output;/// Time to start logging.long int loggingWindowOpening;/// Time to stop logging.long int loggingWindowClose;/// The period of this logger( default is 0)long int LOGGING_PERIOD;/// Bool indi ating whether window set or notbool window_set;};#endifutilities.h#ifndef UTILITIES_H#define UTILITIES_H#in lude "world.h"#in lude <string>#in lude <iomanip>#in lude <sstream>#in lude < math>using std::string;using std::ostringstream; lass UTILITIES{publi :stati long double distan eP2P(Lo ation, Lo ation, DIMENSIONS=TWO_D);stati long int max(long int, long int); 217

A.1. PiCSE Ar hite ture Header Filesstati long int min(long int, long int);stati string generateUniqueIDFromPrefix(string);private:stati long int id ount;};#endifsimulatorVariables.h#ifndef SIM_VARIABLES#define SIM_VARIABLES onst long int SIMULATION_DURATION = 1000*60*60*1; // 12 hours#endifThe Abstra t_Interfa es Class Category Header FilesThese �les are the header �les for the lass de�nitions ontained with the PC_Abstra tion lass ategory. For an explanation of the lasses and their ar hite ture, please refer to hapter4 of this thesis.layer.h#ifndef LAYER#define LAYER#in lude "world.h"#in lude "utilities.h"#in lude "simulated.h"#in lude "observer.h"/*** Simple lass to represent a lo ation in a grid.218

Appendix A. Appendix*/ lass gridLo ation{publi :gridLo ation():x(0),y(0){}gridLo ation(int a, int b):x(a),y(b){}int x, y;};/// Event's generate by a Layerenum LAYER_EVENT_ID{LAYER_TRANSFORM_EVENT};/*** A simple abstra tion used to model or en apsulate* one aspe t of the simulation. In lass Layer, the notion of the* grid is no more than size and granularity. Only in derived* layers does this be ome more on rete.*/ lass Layer: publi Simulated,// performs eventspubli Observable, // for logging and also forpubli Observer{publi :Layer(long int period=0, //update periodlong double gran = 10, // granularitylong double = World::getXSize(),// default size is that of the worldlong double = World::getYSize()//,// long double = World::getXSize(),// default size is that of the world// long double = World::getYSize(),/* Lo ation = World::getOrigin()*/); // default origin of worldvirtual ~Layer(){}/// Abstra t fun tion to be ompleted by sub lassesvirtual void transform()=0;/*** Returns the x size of the grid*/long int getGridXSize(){return gridXSize;}/** 219

A.1. PiCSE Ar hite ture Header Files* Returns the y size of the grid*/long int getGridYSize(){return gridYSize;}virtual void doEvent(int id);prote ted:/// How often the layer is updated. Can be 0long int updatePeriod;/// The size of an individual pie e of the gridlong double granularity;/// Size of spa e represented in layer in real terms. mtrslong double xSize, ySize;/// Dimensions of the grid used in the layerlong int gridXSize, gridYSize;/// The artesian origin of the grid// Lo ation origin;private:};#endifnetif.h#ifndef NET_IF#define NET_IF#in lude <string>#in lude "obje t.h"using namespa e std;/*** Extends Obje t be ause it has an impli it lo ation*/ 220

Appendix A. Appendix lass Net_interfa e: publi virtual Obje t{publi :/// Default// Net_interfa e();/// Ctor, with addressNet_interfa e(/*string a,*/bool=false);~Net_interfa e();/// Send void* parameter to everyonevirtual void send(void*);/// Send void* parameter to parti ular addressvirtual void send(void*, string);/// Send string to everyonevirtual void send(string);/// Send string to parti ular addressvirtual void send(string, string);/// Abstra t deliver API for obje t deliveryvirtual void deliver(void*)=0;/// Abstra t deliver API for string deliveryvirtual void deliver(string)=0;/// Required for doEventvirtual void transform(){}/// Returns address if set, "" otherwisestring getAddress();Exe utionEnvironment* getExe utionEnvironment(){return asso iatedExe Env;}private:// string address;Exe utionEnvironment* asso iatedExe Env;prote ted:void setExe utionEnvironment(Exe utionEnvironment* e){asso iatedExe Env = e;}};#endif221

A.1. PiCSE Ar hite ture Header Filesobje t.h#ifndef OBJECT#define OBJECT#in lude <iostream>#in lude <string>#in lude <list>#in lude <map>#in lude "world.h"#in lude "message.h"#in lude "layer.h"#in lude "simulated.h"using std:: out;using std::endl;using std::list;using std::map;typedef std::map<string,Obje t*> att;enum OBJECT_EVENT{MOVEMENT=0};/*** Obje t lass. Obje ts an be "owned" & "atta hed". Define what these mean modelwise..* Atta h probably shouldn't be in here..? These is really part of an emulated abstra tion...*/ lass Obje t:publi Simulated, publi Observable{publi :///Default torObje t();virtual ~Obje t();///Preferred torObje t(Lo ation,string = UTILITIES::generateUniqueIDFromPrefix("D_Obje t"));///A polymorphi fun tion for updating.virtual void transform()=0; 222

Appendix A. Appendix/// Return string idstring getID(){ return id; }/// Return lo ationvirtual Lo ation getLo ation();/// Set lo ation, only valid if owner set to NULLvoid setLo ation(Lo ation l);/// Return previous lo ationvirtual Lo ation getPreviousLo ation();/// Set the previous lo ationvirtual void setPreviousLo ation(Lo ation l){previousLo ation = l;}/// Set a layer whi h this obje t is ref'd in. Can be multiple ownersvoid setOwner(EntityLayer*);/// Set the updatePeriod, in ase you don't want to set it at the onstru torvoid setUpdatePeriod( long int i){updatePeriod = i;}/// Set the obje t owner. Used in ollo ated obje tsvoid setObje tOwner(Obje t*);/// Add an obje t to this one. Used in ollo ated obje ts s enariosvoid addObje t(Obje t*);/// Atta h an obje t to this one physi allyvoid atta hObje t(Obje t*, string);/// Update the lo ation of ollo ated obje tsvoid updateCollo atedObje ts();/// Called to instantiateObjs. This should be 'friendly' and not publi void instantiateObjs();/// Return instan e of atta hed devi e if it exists.Obje t* findDevi e(string);/// Adds a layer to a list of referersvoid addReferer(EntityLayer*);/// Removes a later from the list of referers.void removeReferer(EntityLayer*);prote ted:/// Layer whi h this obje t belongs to, what it this used for?EntityLayer* owner;/// Layers whi h this obje t belongs to. These have to be updated as an obje t moves.std::list<EntityLayer*>* layer_referen es; 223

A.1. PiCSE Ar hite ture Header Files/// The owner obje t if this obje t is ollo atedObje t* obje tOwner;/// String identifierstring id;/// Makes a all to the owning layer to update a grid lo ationvoid updateLayerLo ation();/// update period of this obje tlong int updatePeriod;private:/// Register obje t with worldvoid registerSelf();/// Lo ation of this obje t.Lo ation lo ation;/// The previous lo ation of this obje tLo ation previousLo ation;/// A ontainer for ollo ated obje tsstd::list<Obje t*>* ollo atedObje ts;/// A ontainer for atta hed obje ts;att* atta hedObje ts;bool COLLOCATED_INST;};ostream& operator<<(ostream&, Obje t&);#endifobserver.h#ifndef OBSERVER_H#define OBSERVER_H#in lude <iostream>#in lude <ve tor>#in lude <fstream>#in lude <string> 224

Appendix A. Appendix#in lude "simulator.h"#in lude "simulated.h"using namespa e std ;using std::ofstream;using std::ios;using std::string;enum ausality_type{LOOSE=0, STRICT}; lass Observable;///////////////////////////////////////////////////////*** Observer*/ lass Observer{publi :Observer( ausality_type=STRICT);virtual ~Observer(){}/// Called when any event o urs at a logable to whi h the logger has subsribed to.virtual void Update(Observable* ) = 0;/// Called when an event, whi h the logger has subsribed to, o urs at the logable sour e.virtual void Update(Observable*, int)= 0; ausality_type ausalityType;int lastEventType;int lastEventTime;Observable* eventSour e;private:};///////////////////////////////////////////////////////*** Observable is a lass whi h is provides event subs ription and notifi ation servi es.* Basi ally it's the 'observable' part of observer/observable.225

A.1. PiCSE Ar hite ture Header Files*/ lass Observable {publi :Observable();~Observable(){};void Atta h(Observer*);void Atta h(Observer*, int);void Deta h(Observer*);void Deta h(Observer*, int);void Notify();void Notify(int);private:ve tor<Observer*> generalObservers;ve tor< ve tor<Observer*>* > eventSpe ifi Observers;};#endifsimulated.h#ifndef SIMULATED#define SIMULATED/*** An interfa e whi h all event generating events must inherit from.*/ lass Simulated{publi :/*** Abstra t method alled when an event is performed* �param int event id spe ifies the event to perform*/virtual ~Simulated(){}virtual void doEvent(int eventid)=0;}; 226

Appendix A. Appendix#endifmobilityObje t.h#ifndef MOBILITY_OBJECT#define MOBILITY_OBJECT#in lude "obje t.h"#in lude "simulator.h"#in lude "observer.h"#in lude <string> onst long int MOVER_PERIOD = 1000; onst double MIN_SPEED = 0; // m/s onst double MAX_SPEED = 10; onst double MAX_PAUSE = 30000;/* RANDOM_WALK NOT IMPLEMENTED YET*/enum MOBILITY_MODEL{RANDOM_WAYPOINT=0, RANDOM_WALK, STATIONARY};enum MOB_EVENT_ID {MOBILITY_EVENT, REACHPOINT_EVENT}; lass Ref_Layer; lass Mobility_Obje t: publi virtual Obje t{publi :///Default torMobility_Obje t(){}~Mobility_Obje t(){}///Preferred torMobility_Obje t(Lo ation, MOBILITY_MODEL=RANDOM_WAYPOINT);void deliver(Msg*);/// Implement your own transform() and doEvent()/// if you want to reate your own mobility modelvirtual void transform();virtual void doEvent(int); 227

A.1. PiCSE Ar hite ture Header Filesvoid rea hWayPt();private:/// Implements the random waypoint algorithmvoid randomWayPoint();void newRandWayPt();bool rea hWayPtInNextIteration();void newRandWayPtParams();/// Stationary obje t movement algorithmvoid stationary();/// Random walk movement algorithmvoid randomWalk();double urrentSpeed;double urrentAngle;Lo ation destination;long double lastUpdate;long double prevDist2pt;long double pauseTime;MOBILITY_MODEL mobilityModel;void (Mobility_Obje t::*mobilityFun Ptr)();};ostream& operator<<( ostream&, Mobility_Obje t&);#endifp�le.h#ifndef PICSE_PFILE#define PICSE_PFILE#in lude <string> 228

Appendix A. Appendix#in lude <queue> lass Exe utionEnvironment; lass p_file{publi :p_file();~p_file(){}//implement har pullChar();void pushChar( har);std::string _id; har buffer[1024℄;int next har;int fd;pthread_ ond_t* a tiveListener;Exe utionEnvironment* a tiveExe utionEnvironment;std::queue< har>* bufferq;};#endif

229

A.2. Evaluation S enariosA.2 Evaluation S enariosSTEAM Sour e FilesThe following are the primary header �les that are used to de�ne the STEAM evaluations enario. The main. pp �le de�nes the setup and initialization of the experiment. TheSteamExe Env.h header �le de�nes the STEAM emulated environment whi h is the emu-lated middleware omponent. TestDevi e.h and CommandSensor.h are the de�nitions of twoappli ations that run on top of instan es of that STEAM middleware. Finally, Command-SensorProg.h is an example of an Appli ationWrapper lass whi h is used to initialise theTestDevi e and CommandSensor appli ations.main. pp#in lude <iostream>#in lude <sstream>#in lude < stdlib>#in lude "network.h"#in lude "pi se.h"#in lude "steamExe Env.h"#in lude " ommandSensorProg.h"#in lude "soProg.h"#in lude "testDevi eProg.h"#in lude "mobilityObj.h"int main( int arg , har **argv ){ int simDuration = 1000*60*2.5; 230

Appendix A. Appendixint iterations = 1;int worldXSize = 1000, worldYSize = 1000;// Create a simulation enginenew Future(LINKED); // event list, lo k, et // Create worldSimulator::Instan e();// Set simulation duration//Simulator::setDuration(1000*60*2.5);Simulator::setDuration(simDuration);// Create a worldWorld::Instan e();// Set the size of that worldWorld::setXSize(worldXSize); World::setYSize(worldYSize);// Intantiate the networkNetwork::Instan e();SteamExe utionEnvironment* FIRST_SO[iterations℄;SteamExe utionEnvironment* SECOND_SO[iterations℄;SteamExe utionEnvironment* MOVING_SENSOR[iterations℄;Mobility_Obje t* mob[iterations℄;for(int xk =0 ; xk < iterations ; xk++){SECOND_SO[xk℄ = new SteamExe utionEnvironment(Lo ation(0,0));thirdprog* r = new thirdprog();SECOND_SO[xk℄->addEmulatedAppli ation(r);r->s heduleExe ution(1970);231

A.2. Evaluation S enarios// if you want to demo fun tionality, use fixed lo ations.MOVING_SENSOR[xk℄ = new SteamExe utionEnvironment(Lo ation(0,0));mob[xk℄ = new Mobility_Obje t( Lo ation(0,0), RANDOM_WAYPOINT ) ;prog* p = new prog();MOVING_SENSOR[xk℄->addEmulatedAppli ation(p);p->s heduleExe ution(1980);mob[xk℄->addObje t(MOVING_SENSOR[xk℄);}// Exe ute the simulationSimulator::run();exit(1);///////////////////////////////////////////////////////////////////////}steamExe Env.h#ifndef STEAM_EXEC_ENV#define STEAM_EXEC_ENV#in lude "exe Env.h"#in lude "rte-impl.h"#in lude "rte-mem.h"#in lude "simulator.h"//#in lude "netif.h" lass p_file; lass SteamExe utionEnvironment:publi Exe utionEnvironment/*, publi Net_interfa e*/{publi :SteamExe utionEnvironment(Lo ation l);~SteamExe utionEnvironment();// RTE - Fun tions alled from RTE_Proximity library232

Appendix A. Appendixint init_rte_publish_lo al();int init_rte_subs ribe_lo al(); hannel_id announ e_lo al(subje t sub, proximity* prox, laten y lat, period per,adaptation adapt);void unannoun e_lo al( hannel_id h);int send_event_lo al(int hannel_id, event* event);subs ription_id subs ribe_lo al(subje t sub, re eive_event b);void unsubs ribe_lo al(subs ription_id h);void register_update_lo ation_ b_lo al(update_lo ation_ b b);void make_ allba ks_for_lo al(steam_event* st_ev);void free_steam_event_lo al(steam_event* ev);private:// RTE - Fun tions alled from lo al RTEvoid send_lo al_event(steam_event* st_ev);void* make_announ ement(event_ hannel* our_ hannel);// DUMMY2-SEAR - Fun tions alled from lo al RTEint init_dummy_sear_subs ribe();int init_dummy_sear_publish();event_ hannel* reserve_ hannel(laten y lat, float requested_period, proximity* prox, adaptation adapt, subje t event_name);event_ hannel* reserve_ hannel_for_subs ribe(subje t sub);void free_ hannel(event_ hannel* handle);int send_on_ hannel(void* msg, event_ hannel* to);// DUMMY-NETIF - Fun tions alled from DUMMY2-SEAR fun tionsvoid send(void*);void deliver(void*);// RTE - Variables needed for lo al RTEint publish_initialised;int subs ribe_initialised; 233

A.2. Evaluation S enarios hannel_table publish_ hannels; hannel_table subs ribe_ hannels;int max_ hannel_id;update_lo ation_ b update_lo ation;// DUMMY2-SEAR - Variables needed for DUMMY2-SEAR fun tionsint send_so ket;int re v_so ket;// Ne essary to inherit from Net_interfa evoid send(string) {}void deliver(string) {}virtual void transform() {}};#endiftestDevi e.h#ifndef _TESTDEVICE_H_#define _TESTDEVICE_H_#in lude "rte.h"#in lude "rte-publish.h"#in lude "rte-mem.h"#in lude <iostream>using std:: out;using std::endl;#in lude <string>using std::string; 234

Appendix A. Appendix/*** �warning Copyright Trinity College Dublin* � lass CommandSensor* �brief Gives ommands to the ar.* �author Aline Senart* �date 05-08-19*/ lass TestDevi e{publi :/** Constru tor. */TestDevi e();/** Destru tor. */virtual ~TestDevi e();};#endif //_TESTDEVICE_H_ ommandSensor.h#ifndef _COMMANDSENSOR_H_#define _COMMANDSENSOR_H_#in lude <unistd.h>#in lude "rte.h"#in lude "rte-publish.h" 235

A.2. Evaluation S enarios#in lude "rte-mem.h"#in lude <iostream>using std:: out;using std::endl;#in lude <string>using std::string;/*** �warning Copyright Trinity College Dublin* � lass CommandSensor* �brief Gives ommands to the ar.* �author Aline Senart* �date 05-08-19*/ lass CommandSensor{publi :/** Constru tor. */CommandSensor();/** Destru tor. */virtual ~CommandSensor();};#endif //_COMMANDSENSOR_H_236

Appendix A. Appendix ommandSensorProg.h (Appli ationWrapper)#ifndef NEW_PROG#define NEW_PROG#in lude "app.h" // from /libs/pi se lass prog: publi Appli ationW{publi :prog();void run();};#endifITS Map De�nition File Ex erptBelow is a sample omplete Jun tion Re ord taken from ity entre.xml, the xml map �le thatwas used to de�ne the road network topology and onstraints in the ITS evaluation s enario.<jun tionRe ><id>1526</id><type>TL</type><lo ation><xCoordinate>379278.0</xCoordinate><yCoordinate>266013.0</yCoordinate></lo ation><in omingJun tion><id>1525</id><numLanes>2</numLanes><linkDistan e>141.69333082400175</linkDistan e>237

A.2. Evaluation S enarios<maxVelo ity>30.0</maxVelo ity><outgoingJun tionRef><id>1527</id><a tionType>R</a tionType></outgoingJun tionRef><outgoingJun tionRef><id>850</id><a tionType>S</a tionType></outgoingJun tionRef></in omingJun tion><in omingJun tion><id>1527</id><numLanes>2</numLanes><linkDistan e>73.16419889536138</linkDistan e><maxVelo ity>30.0</maxVelo ity><outgoingJun tionRef><id>1525</id><a tionType>L</a tionType></outgoingJun tionRef><outgoingJun tionRef><id>850</id><a tionType>R</a tionType></outgoingJun tionRef></in omingJun tion><in omingJun tion><id>850</id><numLanes>2</numLanes><linkDistan e>82.87339742040264</linkDistan e><maxVelo ity>30.0</maxVelo ity>238

Appendix A. Appendix<outgoingJun tionRef><id>1525</id><a tionType>S</a tionType></outgoingJun tionRef><outgoingJun tionRef><id>1527</id><a tionType>L</a tionType></outgoingJun tionRef></in omingJun tion><outgoingJun tion><id>1525</id><numLanes>1</numLanes><linkDistan e>141.69333082400175</linkDistan e><maxVelo ity>30.0</maxVelo ity></outgoingJun tion><outgoingJun tion><id>1527</id><numLanes>1</numLanes><linkDistan e>73.16419889536138</linkDistan e><maxVelo ity>30.0</maxVelo ity></outgoingJun tion><outgoingJun tion><id>850</id><numLanes>2</numLanes><linkDistan e>82.87339742040264</linkDistan e><maxVelo ity>30.0</maxVelo ity></outgoingJun tion></jun tionRe ><jun tionRe > 239

A.2. Evaluation S enarios<id>810</id><type>null</type><lo ation><xCoordinate>379486.0</xCoordinate><yCoordinate>265683.0</yCoordinate></lo ation><in omingJun tion><id>801</id><numLanes>1</numLanes><linkDistan e>44.384682042344295</linkDistan e><maxVelo ity>30.0</maxVelo ity></in omingJun tion></jun tionRe >

240

Bibliography[Benere etti 01℄ Massimo Benere etti, Paolo Bouquet & Matteo Bonifa io. DistributedContext-Aware Systems. Human-Computer Intera tion, vol. 16, 2001.[Boo h 93℄ Grady Boo h. Obje t-Oriented Analysis and Design with Appli a-tions. Benjamin-Cummings Publishing Co. In ., 1993.[Bres iani 04℄ Paolo Bres iani, Loris Penserini, Paola Busetta & Tsvi Ku�ik. AgentPatterns for Ambient Intelligen e. In Pro eedings of 23rd Interna-tional onferen e on Con eptual Modelling, November 2004.[Camp 02℄ Tra y Camp, Je� Boleng & Vanessa Davies. A survey of mobilitymodels for ad ho network resear h. Wireless Communi ations andMobile Computing, 2002.[Campbell 91℄ Roy H. Campbell, Nayeem Islam, Ralph Johnson, Panos Kougiouris& Peter Madany. Choi es, Frameworks and Re�nement. In 1991International Workshop on Obje t Orientation in Operating Systems,pages 9�15, 1991.[Campbell 08℄ A.T. Campbell, S.B. Eisenman, N.D. Lane, E. Miluzzo, R.A. Peterson,Hong Lu, Xiao Zheng, M. Musolesi, K. Fodor & Gahng-Seop Ahn. TheRise of People-Centri Sensing. Internet Computing, IEEE, vol. 12,no. 4, pages 12 �21, july-aug. 2008.[Chen 98℄ F.Z. Chen & X.Z. Wang. Software Sensor Design Using Bayesian241

BibliographyAutomati Classi� ation and Ba k-Propagation Neural Networks. In-dustrial and Engineering Chemistry Resear h, vol. 37, no. 10, pages3985�3991, 1998.[Dearle 03℄ Alan Dearle, Graham Kirby & Ron Morrison et al. Ar hite tural Sup-port for Global Smart Spa es. In Pro eedings of 4th InternationalConferen e on Mobile Data Management, 2003.[Dey 00℄ Anind K. Dey & Gregory D. Abowd. The ontext toolkit: aiding thedevelopment of ontext-enabled appli ations. In Workshop on SoftwareEngineering for Wearable and Pervasive Computing, pages 434�441,New York, NY, USA, 2000. ACM Press.[Esser 97℄ J. Esser & M. S hre kenberg. Mi ros opi Simulation of Urban Tra� Based on Cellular Automata. Journal of Modern Physi s, 1997.[Eugster 06℄ Patri k Eugster, Benoit Garbinato & Adrian Holzer. Pervaho: ADevelopment Test Platform for Mobile Ad ho Appli ations. In Mobileand Ubiquitous Systems: Networking Servi es, 2006 Third AnnualInternational Conferen e on, pages 1 �5, july 2006.[Fall 01℄ K Fall & K. Varadhan, editeurs. The ns Manual (formerlyns Notes and Do umentation). http://www.isi.edu/nsnam/ns/ns-do umentation.html (last visited 13 May 2011), 2001.[Fishwi k 95℄ Paul Fishwi k. Simulation Model Design and Exe ution: BuildingDigital Worlds. Prenti e Hall, 1 edition, 27 January 1995.[Fleury 07℄ Pas al Fleury, Jan Curin & Jan Kleindienst. SitCom - DevelopmentPlatform for Multimodal Per eptual Servi es. In V. Marik, V Vyatkin& A.W. Colombo, editeurs, Pro eedings of Internation Conferen e onIndustrial Appli ations of Holoni and Multi-Agent Systems, pages104�113. Springer-Verlad Berlin Heidelberg, 2007.242

Bibliography[Fujimoto 00℄ Ri hard M. Fujimoto. Parallel and Distributed Simulation Systems.2000.[Gamma 95℄ Eri h Gamma, Ri hard Helm, Ralph Johnson & John Vlissides.Design Patterns:Elements of reusable Obje t-Oriented Software.Addison-Wesley, 1995.[Girod 04a℄ Lewis Girod, Jeremy Elson, Alberto Cerpa, Thanos Stathopoulos,Nithya Ramanathan & Deborah Estrin. EmStar: a Software Envi-ronment for Developing and Deploying Wireless Sensor Networks. InPro eedings of the 2004 USENIX Te hni al Conferen e, 2004.[Girod 04b℄ Lewis Girod, Thanos Stathopoulos, Nithya Ramanathan, Jeremy El-son, Deborah Estrin, Eri Osterewil & Tom S hoellhammer. A Systemfor Simulation, Emulation, and Deployment of Heterogenous SensorNetworks. In Pro eedings of the 2nd ACM Conferen e on EmbeddedNetworked Sensor Systems (SenSys 04), 2004.[Guinard 10℄ Dominique Guinard, Vlad Trifa, Stamatis Karnouskos, Patrik Spiess& Domni Savio. Intera ting with the SOA-Based Internet of Things:Dis overy, Query, Sele tion, and On-Demand Provisioning of WebServi es. IEEE Trans. Serv. Comput., vol. 3, pages 223�235, July2010.[Handte 09℄ Mar us Handte, Wolfgang Apolinarski, Pedro Marron, VinnyReynolds, Danh Le Phuo & Manfred Hauswirth. PECES MiddlewareChallenges: On Building the Bridge Between Islands of Integration. InPaul Cunningham, editeur, eChallenges 2009 Conferen e Pro eedings.Le ture Notes in Computer S ien e, 2009.[Handziski 06℄ Vlado Handziski, Andreas Köpke, Andreas Willig & Adam Wolisz.TWIST: a s alable and re on�gurable testbed for wireless indoor ex-periments with sensor networks. In Pro eedings of the 2nd interna-243

Bibliographytional workshop on Multi-hop ad ho networks: from theory to reality,REALMAN '06, pages 63�70, New York, NY, USA, 2006. ACM.[He 04℄ Tian He & Sudha Krishnamurthy et al. Energy-E� ient Surveillan eSystem Using Wireless Sensor Networks. In 2nd International Con-feren e on Mobile Systems, Appli ations and Servi es (MobiSys '04),June 2004.[He kmann 03℄ Dominik He kmann. A Spe ialised Representation for UbiquitousComputing and User Modelling. In Workshop on User Modelling forUbiquitous Computing at User Modelling 2003 (UM'03), 2003.[Hill 00℄ Jason Hill, Robert Szew zyk, Ale Woo, Seth Hollar, David Culler &Kristofer Pister. System ar hite ture dire tions for networked sensors.SIGARCH Comput. Ar hit. News, vol. 28, pages 93�104, November2000.[Hynes 09℄ Gearoid Hynes, Vinny Reynolds & Manfred Hauswirth. A ContextLife y le for Web-based Context Management Servi es. In Pro eed-ings of the 4th European Conferen e on Smart Sensing and Context(EuroSSC), 2009.[Ji 04℄ Xiang Ji & Hongyuan Zha. Sensor positioning in Wireless Ad-ho Sensor Networks Using Multidimensional S aling. In Pro eedings ofIEEE INFOCOM, pages 2652�2661, 2004.[Jiang 09℄ Mingxing Jiang, Zhongwen Guo, Feng Hong, Yutao Ma & HanjiangLuo. O eanSense: A pra ti al wireless sensor network on the sur-fa e of the sea. In Pervasive Computing and Communi ations, 2009.PerCom 2009. IEEE International Conferen e on, pages 1 �5, mar h2009.[John J. Barton 03℄ Vikram Vijayaraghavan John J. Barton. UBIWISE, A Simulatorfor Ubiquitous Computing Systems Design. Rapport te hnique, HP244

Bibliography Labs, http://www.hpl.hp. om/te hreports/2003/HPL-2003-93.html,29 April 2003.[Johnson 88℄ Ralph E. Johnson & Brian Foote. Designing Reusable Classes. JOOP,vol. 1, no. 2, pages 22�35, 1988.[Jouve 09℄ W. Jouve, J. Bruneau & C. Consel. DiaSim: A parameterized simula-tor for pervasive omputing appli ations. In Pervasive Computing andCommuni ations, 2009. PerCom 2009. IEEE International Conferen eon, pages 1 �3, mar h 2009.[Klein 01℄ Lawren e A. Klein. Sensor Te hnologies and Data Requirements forITS. Arte h House, 2001.[Kranz 06℄ Matthias Kranz, Radu Bogdan Rusu & Alexis Maldonado. A Play-er/Stage System for Context-Aware Intelligent Environments. In Sys-tem Support for Ubiquitous Computing Workshop (UbiSys 2006),2006.[Kranz 07℄ Matthias Kranz, Wolfgang Spiessl & Albre ht S hmidt. DesigningUbiquitous Computing Systems for Sports Equipment. In PervasiveComputing and Communi ations, 2007. PerCom '07. Fifth AnnualIEEE International Conferen e on, pages 79 �86, mar h 2007.[Kru hten 95℄ P. B. Kru hten. The 4+1 View Model of ar hite ture. IEEE Software,1995.[Kuhl 99℄ Frederi k Kuhl, Ri hard Weatherly & Judith Dahmann. CreatingComputer Simulation Systems: An Introdu tion to the High LevelAr hite ture. Prenti e Hall, 1 edition, 18 O tober 1999.[Labella 06℄ Thomas Halva Labella, Gerhard Fu hs & Falko Dressler. A SimulationModel for Self-organised Management of Sensor/A tuator Networks.245

Bibliographyhttp://www7.informatik.uni-erlangen.de/ dressler/publi ations/fg-selbstorganisation-2006.pdf, 2006.[Law 00℄ Averill M. Law & W. David Kelton. Simulation Modelling and Anal-ysis. M Graw-Hill Higher Edu ation, 3rd edition, 2000.[Levis 03℄ Philip Levis, Nelson Lee, Matt Welsh & David Culler. TOSSIM:A urate and S alable Simulation of Entire TinyOS Appli ations. InPro eedings of 1st ACM Conferen e on Embedded Networked SensorSystems (SenSys 03), 2003.[Li 06℄ Ting Li, Freek Hofker & Fred Jansma. Passenger Travel BehaviousModel in Railway Network Simulation. 2006 Winter Simulation Con-feren e, 2006.[Lu 09℄ Hong Lu, Wei Pan, Ni holas D. Lane, Tanzeem Choudhury & An-drew T. Campbell. SoundSense: s alable sound sensing for people- entri appli ations on mobile phones. In Pro eedings of the 7th in-ternational onferen e on Mobile systems, appli ations, and servi es,MobiSys '09, pages 165�178, New York, NY, USA, 2009. ACM.[Mangharam 06℄ Rahul Mangharam, Daniel Weller, Raj Rajkumar, Priyantha Mu-dalige & Fan Bai. GrooveNet: A Hybrid Simulator for Vehi le-to-Vehi le Networks. In Mobile and Ubiquitous Systems: NetworkingServi es, 2006 Third Annual International Conferen e on, pages 1 �8,july 2006.[Martin 06a℄ Miquel Martin & Petteri Nurmi. A Generi Large S ale Simulator forUbiquitous Computing. In Third Annual International Conferen e onMobile and Ubiquitous Systems: Networking & Servi es, 2006 (Mo-biQuitous 2006), San Jose, California, USA, July 2006. IEEE Com-puter So iety. 246

Bibliography[Martin 06b℄ Miquel Martin & Petteri Nurmi. A Generi Large S ale Simulatorfor Ubiquitous Computing. Third Annual International Conferen e onMobile and Ubiquitous Systems: Networking and Servi es, pages 1�3,July 2006.[Masson ℄ M. H. Masson, S. Canu & Y. Grandvalet. Soft-ware Sensor Design Based on Empiri al Data.http://www.hds.ut .fr/ em2s/sym/Toulouse/intronew.ps.[Medagliani 10℄ P. Medagliani, J. Leguay, V. Gay, M. Lopez-Ramos & G. Ferrari.Engineering energy-e� ient target dete tion appli ations in WirelessSensor Networks. In Pervasive Computing and Communi ations (Per-Com), 2010 IEEE International Conferen e on, pages 31 �39, 29 2010-april 2 2010.[Meier 03℄ Rene Meier & Vinny Cahill. Exploiting Proximity in Event-BasedMiddleware for Collaborative Mobile Appli ations. In 4th IFIP In-ternational Conferen e on Distributed Appli ations and InteroperableSystems (DAIS '03), volume 2893, pages 285�296. LNCS, 2003.[Morla 04℄ Ri ardo Morla & Nigel Davies. Evaluating a Lo ation-Based Appli a-tion: A Hybrid Test and Simulation Environment. In Pro eedings of2nd International Conferen e on Pervasive Computing, 2004.[Nakata 07℄ Junya Nakata, Satoshi Uda, Toshiyuki Miya hi, Kenji Masui, RazvanBeuran, Yasuo Tan, Ken-i hi Chinen & Yoi hi Shinoda. StarBED2:Large-s ale, Realisti and Real-time Testbed for Ubiquitous Networks.In 3rd International Conferen e on Testbeds and Resear h Infrastru -ture for the Development of Networks and Communities (TRIDENT-COM), 2007.[Narendra 05℄ Nanjangud C Narendra. Large S ale Testing of Pervasive ComputingSystems Using Multi-Agent Simulation. In Pro eedings of Third IEEE247

BibliographyInternational Workshop on Intelligent Solutions in Embedded Systems(WISES2005), 2005.[Naumov 03℄ Valery Naumov & Thomas Gross. Simulation of Large Ad Ho Net-works. In In Pro eedings of The Sixth ACM International Workshopon Modeling, Analysis and Simulation of Wireless and Mobile Systems(MSWiM 2003), 2003.[Nishikawa 06℄ Hiroshi Nishikawa, Shinya Yamamoto, Morihiko Tamai, Kouji Nishi-gaki, Tomoya Kitana, Naoki Shibata, Keii hi Yasumoto & Minoru Ito.UbiREAL: Realisti Smartspa e Simulator for Systemati Testing. In8th Int'l Conf. on Ubiquitous Computing (UbiComp2006). LNCS4206,September 2006.[North 06℄ M.J. North, N.T. Collier & J.R. Vos. Experien es Creating ThreeImplementations of the Repast Agent Modeling Toolkit. ACM Trans-a tions on Modeling and Computer Simulation, vol. 16, no. 1, pages1�25, January 2006.[O'Neill 05℄ Eleanor O'Neill & Martin Klepal. A Testbed for evaluating HumanIntera tion with Ubiquitous Computing Environments. In Pro eedingsof 1st International Conferen e on Testbeds and Resear h Infrastru -tures for the DEvelopment of NeTworks & COMmunities (TRIDENT-COM), 2005.[Park 00℄ Sung Park, Andreas Savvides & Mani B. Srivastava. A SimulationFramework for Sensor Networks. In Pro eedings of the 3rd ACM In-ternational Workshop on Modeling, Analysis and Simulation of Wire-less and Mobile Systems (MSWiM 2000), 2000.[Parker 04℄ E.L. Parker. Current Resear h in Multi-Robot Systems. Journal ofArti� ial Life and Roboti s, 2004.248

Bibliography[Raza�ndralambo 10℄ T. Raza�ndralambo, N. Mitton, A.C. Viana, M.D. de Amorim &K. Obra zka. Adaptive deployment for pervasive data gathering in onne tivity- hallenged environments. In Pervasive Computing andCommuni ations (PerCom), 2010 IEEE International Conferen e on,pages 51 �59, 29 2010-april 2 2010.[Salim 08℄ F.D. Salim, Li heng Cai, M. Indrawan & Seng Wai Loke. Road In-terse tions as Pervasive Computing Environments: Towards a Multi-agent Real-Time Collision Warning System. In Pervasive Computingand Communi ations, 2008. PerCom 2008. Sixth Annual IEEE Inter-national Conferen e on, pages 621 �626, mar h 2008.[S hmidt 97℄ Douglas C. S hmidt. Guest Editorial: Obje t-Oriented Appli ationFrameworks. Communi ations of the ACM, Spe ial Issue on Obje t-Oriented Appli ation Frameworks, vol. 40, no. 10, 1997.[Selvarajah 10℄ K. Selvarajah & N. Speirs. Integrating Smart Spa es into the PEr-vasive Computing in Embedded Systems (PECES) Proje t. In Con-sumer Communi ations and Networking Conferen e (CCNC), 20107th IEEE, pages 1 �2, jan. 2010.[Senart 06℄ Aline Senart, Raymond Cunningham, Melanie Bouro he, NeilO'Connor, Vinny Reynolds & Vinny Cahill. MoCoA:CustomisableMiddleware for Context-aware Mobile Appli ations. 8th InternationalSymposium on Distributed Obje ts and Appli ations (DOA 2006),2006.[Seo 05℄ Jinseok Seo, Gwanghoon Goh & Gerard J. Kim. Creating ubiquitous omputing simulators using P-VoT. In MUM '05: Pro eedings of the4th international onferen e on Mobile and ubiquitous multimedia,pages 123�126, New York, NY, USA, 2005. ACM.[Shibuya 04℄ Kazuhiko Shibuya. A Framework of Multi-Agent-Based Modeling,249

BibliographySimulation, and Computational Assistan e in a Ubiquitous Environ-ment. SCS Journal of Simulation, 2004.[Soanes 05℄ Catherine Soanes & Angus Stevenson. Oxford English Di tionary.Oxford University Press, 2005.[Sobeih 05℄ Ahmed Sobeih, Wei-Peng Chen, Jennifer C. Hou, Lu-Chuan Kung,Ning Li, Hyuk Lim, Hung-Ying Tyan & Honghai Zhang. J-Sim: ASimulation and Emulation Environment for Wirelesss Sensor Net-works. In Pro eedings of the 38th Annual Simulation Symposium(ANSS 2005), 2005.[Stroustrup 98℄ Bjarne Stroustrup. An Overview of the C++ Programming Language,1998.[Sun Mi rosystems 96℄ Sun Mi rosystems. Wabi 2.2 Users Guide. Rapport te hnique, SunMi rosystems, 1996.[Sundresh 04℄ Sameer Sundresh, Wooyoung Kim & Gul Agha. SENS: A Sensor,Environment and Network Simulator. In Pro eedings of IEEE/ACMAnnual Simulation Symposium, 2004.[Tapia 04℄ Emmanuel Munguia Tapia, Stephen S. Intille & Kent Larson. A tivityRe ognition in the Home using Simple and Ubiquitous Sensors. InPro eedings of 2nd International Conferen e on Pervasive Computing,2004.[Tropper 02℄ Carl Tropper. Parallel dis rete-event simulation appli ations. J. Par-allel Distrib. Comput., vol. 62, no. 3, pages 327�335, 2002.[Verdone 07℄ Roberto Verdone, Davide Dardari, Gianlu a Mazzini & Andrea Conti.Wireless Sensor and A tuator Networks. A ademi Press, 21 De em-ber 2007. 250

Bibliography [Vyas 10℄ Dhaval Vyas, Anton Nijholt, Dirk Heylen, Alexander Kröner & Ger-rit van der Veer. Remarkable obje ts: supporting ollaboration in a reative environment. In Pro eedings of the 12th ACM international onferen e on Ubiquitous omputing, Ubi omp '10, pages 37�40, NewYork, NY, USA, 2010. ACM.[Weiser 91℄ MarkWeiser. The Computer for the 21st Century. S ienti� Ameri an,vol. 265, no. 3, pages 94�104, September 1991.[Weiser 93℄ Mark Weiser. Some Computer S ien e Issues in Ubiquitous Comput-ing. Communi ations of the ACM, vol. 36, no. 7, pages 74�84, 1993.[Werner-Allen 05℄ G. Werner-Allen, P. Swieskowski & M. Welsh. MoteLab: a wirelesssensor network testbed. In Information Pro essing in Sensor Networks,2005. IPSN 2005. Fourth International Symposium on, pages 483 �488, april 2005.[Win 07℄ Wine: Windows Emulator for x86 Unixes. http://www.winehq.org/,2007.[Xu 10℄ Xunteng Xu, Lin Gu, Jianping Wang & Guoliang Xing. Negotiatepower and performan e in the reality of RFID systems. In PervasiveComputing and Communi ations (PerCom), 2010 IEEE InternationalConferen e on, pages 88 �97, 29 2010-april 2 2010.[Yu 05℄ Liyang Yu, Neng Wang & Xiaoqiao Meng. Real-time forest �re de-te tion with wireless sensor networks. In Pro eedings of Interna-tional Conferen e on Wireless Communi ations, Networking and Mo-bile Computing, 2005., volume 2, pages 1214�1217, September 2005.[Zeigler 00℄ Bernard P. Zeigler, Herbert Praehofer & Tag Gon Kim. Theory ofModelling and Simulation. A ademi Press, 2nd edition, 2000.251

Bibliography[Zomaya 96℄ Albert Y. H. Zomaya. Parallel and Distributed Computing Handbook.M Graw-Hill Professional, 1996.

252