Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Scalable smart transducers network using Power-over-Ethernet : towards smarter, safer and more controllable… Lobachev, Ivan 2016

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata


24-ubc_2017_february_lobachev_ivan.pdf [ 1.5MB ]
JSON: 24-1.0340638.json
JSON-LD: 24-1.0340638-ld.json
RDF/XML (Pretty): 24-1.0340638-rdf.xml
RDF/JSON: 24-1.0340638-rdf.json
Turtle: 24-1.0340638-turtle.txt
N-Triples: 24-1.0340638-rdf-ntriples.txt
Original Record: 24-1.0340638-source.json
Full Text

Full Text

Scalable Smart Transducers NetworkUsing Power-Over-EthernetTowards smarter, safer and more controllable buildingsbyIvan LobachevB.A.Sc., The University of British Columbia, 2015A THESIS SUBMITTED IN PARTIAL FULFILLMENTOF THE REQUIREMENTS FOR THE DEGREE OFMaster of Applied ScienceinTHE FACULTY OF GRADUATE AND POSTDOCTORALSTUDIES(Electrical and Computer Engineering)The University of British Columbia(Vancouver)December 2016c© Ivan Lobachev, 2016AbstractIn the age of rapid technological advancement, many telecommunication applica-tions are being integrated into our lives, including smart phones and Internet ofThings (IoT). Smart buildings (and houses) use these technologies to reduce en-ergy consumption and increase safety. The need for these buildings is growing asurbanization continues and resources dwindle. According to a report by the UnitedNations, by 2050 66% of the worlds population will live in cities. This will causethe size and number of megacities to expand drastically in the near future. Complexcommunication networks, controls and other services will allow us to build smartcities to manage and improve the publics quality of life. The necessity of smartbuildings and, eventually, cities, have stimulated growth of sensor networks forthese purposes. This thesis discusses the research on creating a smart transducernetwork architecture concept that uses Power over Ethernet (PoE) as a method fortransferring data and power over a single medium, together with principles of de-centralized and remote computing for data processing. The concept prototype hadits power supplied by a Cisco Catalyst 4507R+E switch and utilized cloud com-puting to provide an easily scalable and adaptable architecture, able to easily adaptto a wide array of applications and fit the demands of new trends or integrationinto other systems. The set-up was tested on RaspberryPi and BeagleBone micro-controller boards as sensor hubs, and used DigitalOcean as the cloud computingservice of choice. The server in this implementation acts as user interface, frontend, and as the console unit back end. The architecture has demonstrated the fea-sibility of the concept of uniting PoE and IoT to create a flexible architecture. Thesystem has also demonstrated fast communication times, below 200ms, in a cross-continental setting and the ability to provide fast processing times of under 1s. Thisiishows particular promise for the use of the architecture within the context of greenand smart housing equipped with a low-cost sensor network, where local power ispartially provided via renewable energy harvesting, and the majority of short-rangepower transmission is DC-centered.iiiPrefaceA version of chapters 2-5 is published as part of the IEEE Annual InformationTechnology, Electronics and Mobile Communication Conference 2016 (I. Lobachev,and E.Cretu, ”Smart Sensor Network for Smart Buildings”, IEEE Annual Informa-tion Technology, Electronics and Mobile Communication Conference 2016) [1],where the publication received the Best Paper Award. I was the lead investigatorand responsible for the composition of majority of the manuscript.ivTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiiGlossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xAcknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Motivation of the Research . . . . . . . . . . . . . . . . . . . . . 11.2 Research Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Organization of the Thesis . . . . . . . . . . . . . . . . . . . . . 32 Background and Related Work . . . . . . . . . . . . . . . . . . . . . 42.1 Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . 42.1.1 Smart Sensors for Wireless Sensor Networks . . . . . . . 52.1.2 Semi-wireless Sensor Networks . . . . . . . . . . . . . . 62.1.3 Commonplace Wireless Networks . . . . . . . . . . . . . 72.2 Wired Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 Wired Sensor Networks With Dedicated Cabling . . . . . 12v2.2.2 Power Over Ethernet (PoE) and its Applications . . . . . . 123 Concept and Implementation . . . . . . . . . . . . . . . . . . . . . . 163.1 Design Considerations and Decisions . . . . . . . . . . . . . . . 183.2 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . 223.3 Sensor Hub Classes . . . . . . . . . . . . . . . . . . . . . . . . . 233.4 Configuration of the Hubs . . . . . . . . . . . . . . . . . . . . . 243.5 Requirements and Modes of Operation . . . . . . . . . . . . . . . 263.6 Parameters, Organization and Data Processing . . . . . . . . . . . 273.7 Data Processing and Presentation . . . . . . . . . . . . . . . . . . 313.8 The Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 Testing and Applications . . . . . . . . . . . . . . . . . . . . . . . . 365 Conclusions and Future Work . . . . . . . . . . . . . . . . . . . . . 41Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44A Supporting Materials . . . . . . . . . . . . . . . . . . . . . . . . . . 49A.1 Power over Ethernet - Operation Specifics . . . . . . . . . . . . . 49viList of TablesTable 2.1 Aspects and Attributes of Sensor Networks to be ConsideredDuring the Design and Evaluation Stages . . . . . . . . . . . . 9viiList of FiguresFigure 2.1 A graphic representation of a generic wired sensor . . . . . . 12Figure 2.2 A diagram showing the the cable wiring and pairs within anEthernet Category 5 Enhanced Ethernet Cable (CAT5E)cable[2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Figure 3.1 General architecture view . . . . . . . . . . . . . . . . . . . 17Figure 3.2 A high level diagram of the implemented system set-up . . . 18Figure 3.3 A snipped of the JSON code that is used to store config-uration settings . . . . . . . . . . . . . . . . . . . . . . . . . 23Figure 3.4 A screenshot of the web view of the user interface and config-uration window . . . . . . . . . . . . . . . . . . . . . . . . . 25Figure 3.5 A diagram displaying the high level algorithm of au-tonomous mode of operation . . . . . . . . . . . . . . . . . . 28Figure 3.6 A diagram displaying the high level algorithm of semi-autonomous mode of operation . . . . . . . . . . . . . . . . . 29Figure 3.7 A diagram displaying the structure of the HDF5 data format [3] 32Figure 3.8 A diagram displaying the graph view representation of the data 33Figure 3.9 A diagram displaying the table view representation of the data 34Figure 3.10 A high-level diagram outlining the hierarchy of the system . . 35Figure 3.11 A screenshot of the web view of the hierarchy of the system . 35Figure 4.1 Experimental setup for local testing . . . . . . . . . . . . . . 38Figure 4.2 Latency test results for the two cities where the tests were con-ducted. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39viiiFigure A.1 Power supplied form LAN equipment with end-span powersourcing equipment[4] . . . . . . . . . . . . . . . . . . 50Figure A.2 Power supplied form mid-span power sourcing equipment[4] . 50Figure A.3 Alternatives A and B for the design for use with end-spanpower sourcing equipment according to IEEE 802.3at-2009[4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51ixGlossaryThis glossary contains the acronyms that are used in this work and their definitions.CAT5E Category 5 Enhanced Ethernet CableCAT5 Category 5 Ethernet CableCAT6 Category 6 Ethernet CableDARPA Defense Advanced Research Projects Agency of the United States ofAmericaDC Direct CurrentFTP File Transfer Protocol-used to transfer files that are hosted remotelyHDF5 Hierarchical Data Format - version 5HVAC Heating, Ventilation and Air Conditioning system - a centralized systemused to perform climate control within buildingsISM Industrial, Scientific, and Medical radio bandISP Internet Service ProviderIoT Internet of ThingsJSON JavaScript Object NotationMCB Microcontroller Board - a miniaturized, self sufficient computing deviceable to perform a certain array of actionsxNI National InstrumentsPoE Power over EthernetRF Radio FrequencyRTE Real Time EthernetSDN Software Defined Networking - an approach where a routing scheme ofa network can be implemented by using software rather than hardwareSHF Super High Frequency radio bandSQL Structured Query LanguageSSH Secure Shell ScriptTCL Tool Command LanguageTDMS Technical Data Management and StreamingUHF Ultra High FrequencyUPOE Universal Power Over EthernetXML Extensible Markup Language - a file format used for configuration filesxiAcknowledgmentsI would like to thank my supervisor Edmond Cretu, for his support and guidanceduring my research. The freedom Edmond gave me to explore tangential topicsallowed me to broaden my knowledge of the field as well as come up with inno-vative ways to approach the presented problem. His suggestions to explore greentechnology and nano materials have lead me to discover technology and researchareas I was previously not fully aware of. As a result I believe my broadened viewof the industry and the associated fields as well as the state of the art technologythat is being developed will greatly benefit me in the future, be it in the area of ITsoftware and hardware development or continuing on as a researcher.I would also like to extend a special and heartfelt thank you to my family andmy beloved girlfriend who are a major reason why I am where I am today. Theirsupport and advice throughout my undergraduate and graduate careers has allowedme to come through some fairly difficult situations and accomplish the goals thatI set for myself. I wish to especially thank my father Michael, who has been myteacher and my mentor throughout my life, for his wisdom and counsel, experiencethat he has passed down to me and most importantly for giving me courage andconfidence to set the bar high, and the motivation to surpass my own limits, evenwhen I thought I had reached my wit’s end.In addition I would like to thank Hoschule Augsburg for collaborating withme, in order to test the system in a cross-continental deployment. This partnershipprovided me with a wonderful experience in addition to the well executed tests.Lastly I would like to acknowledge Dr. Paul Lusina who initially with a groupof co-op students worked with my supervisor Dr. Edmond Cretu, to look intosimilar tangents of technology and investigated Power over Ethernet.xiiChapter 1Introduction1.1 Motivation of the ResearchSensors have become indispensable elements in today’s society, being utilized innearly every electronic device that is being used. Due to this situation there hasbeen a great advancement in the field, and today there is an innumerable varietyof sensors for every application imaginable. As technology moves forward, so dothe trends and user demands. One of such trends is smart buildings, Internet ofThings (IoT), as well as the new ”mega buildings” [5] we are seeing more andmore of, along with the need to gather data on the state of the building and its af-fairs. Another trend is ”ecological buildings” or tall wooden buildings which havebeen an object of interest particularly in areas with a high supply of lumber suchas British Columbia. Furthermore as noted in a report by the United Nations, by2050 over 65 percent of the world’s population will live in urban areas according totheir projections [6]. This means that the cities will continue to evolve into smartcities, expressing a need for smart houses and buildings, green and environmen-tally friendly houses which, along with infrastructure operations such as traffic andenvironment control and oversight, will need to be controlled and monitored bya non-disjointed system. Such large scale systems are bound to be infrastructuredependent, and potentially very costly both in instillation and maintenance.By utilizing the technology already available today, it is possible to develop asystem that, by joining the strengths of the individual elements, would be able to1overcome their individual weak points and disadvantages of implementation. Forexample Power over Ethernet (PoE) has the ability to unify data communicationand power transmission, therefore reducing the amount of wiring necessary andreducing power consumption. Devising a system that is able to offer the aforemen-tioned joining of the concepts in order to improve scalability and deployability,among other things, brings large benefits to the field of engineering in general,and to the structural industry in particular. The need to have better control of thebuilding’s resources used, track usage statistics, alert concerned parties in casesof emergency, and the overall need to improve safety and comfort, are all strongmotivators behind the system described in this work.1.2 Research ObjectivesThe main objectives of this work are to develop and implement as a case study aflexible and scalable system architecture that would be able to unify the benefitsprovided by IoT, along with power and installation efficiency of PoE. PoE hasdemonstrated the possibility to reduce installation costs for certain types of appli-cations, such as LAN, IP and VoIP [4]. Furthermore, the necessary infrastructurefor a PoE-enabled system is already in place for any building that has internet ac-cess thorough Ethernet ports, as the same Ethernet connections can be used forboth power and data transmission via PoE standards. The flexibility of the systemarchitecture needs to adapt to the vast variety of sensor types and configurations,to allow various sensors to be connected or disconnected to an existing operatingnetwork. One of objectives includes investigating the applicability and usability ofsome of the off-the-shelf smart sensors applicable to structural monitoring applica-tions. In addition, the research aims to base the new concept on the lessons learnedfrom previous iterations, in order to improve aspects such as scalability, adjustabil-ity, and ease of deployment and exploitation. Once the prototype of the architectureconcept has been developed, it was tested to verify the feasibility of use of such asystem, and its possible deployment schemes. In particular the testing attempted toanswer whether the new design concept is able to adhere to the paradigm of highdegrees of scalability and adjustability. The prototype system passed the testingstage, the details of which can be found in Chapter 4. As a result the developed2concept can be used to later create a commercial system, a hybrid sensor network(as enabled by the designed system architecture), combining the abilities and prop-erties of both wireless sensor networks as well as hard-wired sensor networks andtheir respective sensor modules.1.3 Organization of the ThesisThe thesis is divided into five chapters.Chapter 1 Introduction: The motivation and objectives of the research workare discussed in this chapter.Chapter 2 Background and Related Work: The chapter discusses previouslydeveloped systems with similar goals or functionality, as well as the previous workin our research group that has contributed to shape the current system perspective.Chapter 3 Concept and Implementation: The developed system architectureand an example of its practical implementation are discussed in this chapter. Thechapter also looks closely at the inner workings of the developed algorithms, thevisual representation and user interface.Chapter 4 Testing and Applications: The chapter discusses a testing frame-work, its implementation and the results of the testing, together with their interpre-tation. Overall the design has demonstrated favorable results with regards to scal-ability, as it operated within acceptable margins, and has demonstrated that usinga cloud-computing controller client is a positive improvement over a hard-wiredconnection to a local, physical machine.Chapter 5 Conclusions and Future Work: The conclusions of this work, as wellas recommendations for future work and some proposals on the current design im-provements, are given in this chapter.Some additional representative figures of the system, along with additional in-formation and diagrams regarding the principles of operation of PoE can be foundin the appendix section of this work.3Chapter 2Background and Related WorkSmall scale sensor networks have been previously investigated in various contextsand application areas, along with smart sensors and monitoring systems. This chap-ter will discuss some of the previously conducted work in this field, outline some ofthe shortcomings of the discussed systems and the lessons learned that were usedwhen constructing the currently implemented concept discussed in Chapter 3.2.1 Wireless Sensor NetworksThere is a large number of wireless sensor network configurations that has beenpreviously implemented, which vary by their intended application and architecturedesign. This list includes:• Smart Wireless Sensor Networks - where all or the majority of the datatransfer is done wirelessly. The system utilizes smart sensors for its network- an example from everyday life can be a Wi-Fi (IEEE 802.15.4 standard) orBluetooth network of devices. The primary criteria to assign this label to asystem is that sensors communication needs to occur wirelessly.• Large-scale Sensor Networks - this label can be given to sensor networksthat span large areas. For example the BC Hydro Smart Grid 1 would be anappropriate everyday life representative.1• Mimicking Sensor Networks - sensor networks that try to mimic the behav-ior of a certain system set-up while using a fundamentally different principlecan be placed into this category. An example can be a wireless sensor net-work within a room, which would use the same positioning scheme as wellas routing principles as the wired equivalent.• Small-scale Sensor Networks - Sensor networks which possess only a fewsensors in their network can be placed in this category. An example canbe Bluetooth enabled, small scale wearable devices, such as the FitBit2, orsensors in a small house. Such sensors can be light intensity or air qualitymonitoring sensors, which use wireless communication to transfer the data.Each one of these is constrained by design decisions made for their imple-mentation, and are often limited to the particular application that was originallyintended. A certain architecture may have several attributes, depending on thecomponents used and on the possible or intended applications.2.1.1 Smart Sensors for Wireless Sensor NetworksA good example of a smart sensor that has been previously developed is the Imote2smart sensor platform developed by Jennifer Rice [7]. Their work focused ona wireless sensor network setup, differentiated from other solutions through the ap-proach used. Primarily, they have employed a decentralized computing scheme toreduce the amount of data communication within the network; as a result, the archi-tecture has reduced the amount of power consumed by the system through limitingthe power usage of individual elements. However, while the system does offerbenefits over traditional wireless setups (where the design would attempt to mimica wired configuration using wireless transmission), it still has its flaws - Whilethe group managed to reduce the overall power consumption, the main problembecomes the maintenance of the energy sources, as the sources of power in thesecases are local batteries, regardless of whether they are primary or secondary cells3.Furthermore, the possible issue of interference and lost or deteriorated signals is2 cells are batteries that are non-rechargeable, while Secondary cells are batteries thatcan be recharged, such as the lithium ion batteries in smartphones, for example.5still not fully eliminated, as it is in the nature of wireless transmission. A relatedBluetooth wireless network concept was proposed by Oliver Kasten et. al. in [8],where they have also implemented the idea of on-board data processing and sens-ing. Their primary focus was the development of a concept called Smart-It, whereone could add ”smartness” to an object in an post-hoc4 way. The authors utilizedBluetooth technology for the communication needs of their system.Other attempts at sensor networks in the recent years focus primarily on wire-less sensors and data transmission[9]. Nevertheless, many of the investigatorstackle the issues of power consumption and scalability via routing protocol ma-nipulation and various kinds of scheduling application layers, such as the treestructure architecture proposed in [10] or the approaches in [11]. A number ofrecently developed solutions target more specific applications, such as wirelesssensor networks for home lighting systems[12], industrial wireless sensor networkdata transmission scheme in [13] or the case study on Greenorbs in [14]. Whichlooked into the issues of scalability and system dependence on individual nodes,an issue discussed in Chapter 3 and which our architecture adresses.2.1.2 Semi-wireless Sensor NetworksAnother approach for monitoring a building, in particular for structural health mon-itoring, has been implemented by Xu et. al. with their system named Wisden [15].The system was then later improved and tested again by Chintalapudi et. al. whopublished their results in [16]. However the system cannot be called a truly wire-less one, as there is a certain wiring setup involved in the system. The system useswireless sensors, which send the data to a local hub, or node as titled by the authors,which is then connected to a local PC via serial port, a hard-wired connection. Thecomputer would then handle the bulk of the data processing and can be connectedas a network to other computers employing a similar set-up. This design shows anumber of drawbacks, such as the need for the wiring, which defeats the purposeof using a wireless set up. In addition, the serial communication as implemented inthis work, as well as the semi-centralization of the data processing may, on a larger4Post-hoc in this context would refer to an installation scenario where the installation of theadditional device happens after the manufacturing process, possibly by non-professionals in an”at-home” setting6scale, greatly affect the speed and performance of the system as a whole [17]. Fur-thermore, the wiring that is required for the set up, as well as the need of separatepower supplies for the nodes, in addition to the power required by the sensors,make this a good intermediate step; it is however by far not the optimal solutionfor the purposes of large scale building monitoring with large sensor clusters.One possible approach to resolving the issue of power deficiency in semi-wireless sensor networks is wireless power transmission. Research done by on the use of Radio Frequency (RF) to harvest energy locally and transmitit to low-power wireless sensors [18] makes the idea of using a semi-wireless orhybrid configuration solution a lot more appealing, as it adds another alternativeto supply the necessary power while retaining the flexibility of node placementoffered by wireless data transmission.Lastly none of the solutions that have been previously mentioned provide ahybrid integration of sensor and actuators, for complex control systems, whichwas also pointed out by the authors. This is due to a number of reasons - one ofthem is the fact that the system would not have enough power to actuate anythingof importance, since one of the primary goals highlighted by all of the authors isto minimize power consumption. The other factor that reinforces this fact is that inorder to provide power to the actuating device, a wired connection will be required,which may defeat the purpose of setting up a wireless system in the first place.However the lack of actuation capabilities is understandable as the concept wasoutside of the original scope decided by the authors and not their primary focus.2.1.3 Commonplace Wireless NetworksA certain number of wireless sensor networks have already integrated themselvesinto our everyday life. While we may not realize it consciously, we use wirelesssensor networks for a wide variety of tasks. A Wi-Fi network, for example, is awireless sensor network which monitors and exchanges data with the devices con-nected to it via RF signal transmission5. Another common sensor network, whichmany not immediately come to mind is the GSM communications network, as well5Wi-Fi communicates mainly using the 2.4 gigahertz (12 cm) Ultra High Frequency (UHF) and5 gigahertz (6 cm) Super High Frequency (SHF) Industrial, Scientific, and Medical (ISM) radiobands7as the BC Hydro Smart Grid as mentioned previously. In addition, many of the newgadgets, electronic wrist bands, arm bands, smart bracelets etc. that allow a personto monitor their heart rate, steps taken and calories burned can also be considereda wireless sensor network, typically using Bluetooth communication standard fordata exchange. In the medical field we have for instance pacemakers and bloodsugar meters, which can again provide relevant data when wirelessly communicat-ing with a network. All of these are often centered around a smartphone, whichcompiles all of the data for the user to see, as well as take other actions, such assend alerts to a local hospital or notify the user to alter their current activity in orderto circumvent the risk. A great overview of the state and direction of this technol-ogy is provided by Pantelopoulos et. al [19], which discusses current technologyof wireless sensing for biomedical applications and the trends they believe to bepresent.2.2 Wired Sensor NetworksAs seen previously, there are a number of approaches that can be taken in wirelesssensor network systems. However, it is important to remember their basics andpredecessors when constructing a design, which are the wired sensor networks.Such sensor networks have been used since the early 1950s, as part of the nationalpower grid in the US or the radar network used for air traffic control [20]. Thesensor networks as we see and define them today, have been more intensively re-searched and used during the cold war by the Defense Advanced Research ProjectsAgency (DARPA), as shown in their investigative work of the history of sensornetworks by Chong et. al. [20], and onward by many institutions and enterprises.The primary concept of wired sensor networks is to have an array or cluster ofsensors physically connected to a processing hub, which will output some resultsbased on the data received. A good reference table that can be used when consid-ering the design aspects and requirements of a sensor network can be found belowin Table 2.1. It lists the major aspects that should be considered when making thedesign decisions and classifying the system, it will also be referenced throughoutthis work when consulting certain guidelines.8Table 2.1: Aspects and Attributes of Sensor Networks to be ConsideredDuring the Design and Evaluation StagesAspect Considerations and VariationsSensors Size: small (for example micro electromechanical sys-tems (MEMS), large (for example radar or satellite net-work, city grid))Type: passive (for example strain gauges, piezoelectric,magnetic or acoustic sensors), or active (for exampleradar, sonar, Bluetooth)Composition: homogeneous (where all of the sensors areof the same type) or heterogeneous (where different typesof sensors are employed)Spatial Coverage: Dense (sensors are closely packed to-gether for example on a CPU or a small wearable/portabledevice), sparse (for example temperature sensors scatteredacross a forest or a city)Dynamics: stationary (for example building monitoring)or mobile (for example on a vehicle or a robot)Sensing Entities of Interest Organization: Distributed (for example environmentalmonitoring, building monitoring), localized (for exam-ple target tracking, individual location monitoring ( static, dynamicNature: cooperative (for example air traffic control,HVAC systems), non-cooperative(for example militarytargets, animal tracking etc.)Continued on next page9Table 2.1 – continued from previous pageAspect Considerations and VariationsOperating Environment Benign (for example interior of rooms of a building,within machines that shield them (ex: computers) etc.),adverse (for example aggressive outdoor environmentsuch as a mine, ocean waters, places of military actionetc.)Communication Networking: wired (using wired connections betweennodes and sensors), wireless (using wireless communica-tion between nodes and sensors, for example Bluetooth orRF)Bandwidth Availability: high, lowBandwidth Usage: heavy (constant big loads of datatransferred ex: images, videos etc.), Light (small continu-ous transmission of data ex: text or binary data)Processing Architecture Centralized (all of the data is sent to and processed at onesingle central location), distributed (the processing anddata management is done at the sensor level and is dis-tributed between the different locations), hybrid (a hybridof the previous two approaches)Energy Consumption High (big power drain due to frequent wireless transmis-sions, high density sensor arrays, inefficient power man-agement etc.), low (small scale design, low energy design,small sensor arrays with few sensors, efficient power man-agement)Continued on next page10Table 2.1 – continued from previous pageAspect Considerations and VariationsEnergy Availability Readily available (power sockets, available power lines,relevant infrastructure to be connected to), scarcely avail-able (remote locations or places fare from infrastruc-ture that would require battery and/or renewable energysources for power supply)Deployment Infrastructure Fixed and Planned (for example a factory or a smart housewhere the infrastructure for the sensors is built into the de-sign of the structure) or ad hoc (post-construction installa-tion for example during a building upgrade, or random de-ployment through other means, no designated infrastruc-ture would be present)Ease of Modification High (components can be added or removed with ease,there is no need for a full recompile or reassembly of thesystem or source code, modifications are simple and local-ized), Low (need for additional infrastructural to integratethe modification, major parts or whole assembly needs tobe adjusted and/or recompiled, modifications are spreadacross the whole system due to high tangibility and de-pendencies)The following subsections will discuss the varying approaches to wired sensornetworks. We have briefly analyzed their evolution afterwards focusing on one ofthe primary aspects that is of importance to this work which is Power over Ethernet(PoE) and the technology around it.112.2.1 Wired Sensor Networks With Dedicated CablingA typical approach to physically implement a wired sensor network is to have sep-arate, dedicated cabling for power and data. This sort of setup would be used wheneither AC or DC power is easily attainable locally (without the use of batteries),and where the speed of the data transfer is important and preferred to be real-time,or near real time. Usually, this is accomplished through bus connections6, althoughother wiring approaches, such as completely separated wiring, have also been usedin the past. As seen in Figure 2.1, a generic set up would have a minimum of threewires for power and data transfer. The power can be drawn either from the con-troller board that serves as a node, a central controller or form a separate source.In any of those cases a certain degree of voltage control may be required to fit theneeds of the sensor, the latter case may occur when the sensor will require morecurrent than can be provided by the board. Such setup is often used in thermostatsas well as Heating, Ventilation and Air Conditioning system (HVAC).Figure 2.1: A graphic representation of a generic wired sensor2.2.2 Power Over Ethernet (PoE) and its ApplicationsThe concept of Power over Ethernet (PoE) has evolved from the Ethernet datacable, with the goal to integrate both power and data communication over the samebus wiring. Since the data component is handled by the Ethernet protocol portion ofthe design, the concept was to use some of the wires within the Category 5 Ethernet6 In this context a bus refers to parallel electrical wires with multiple connections12Cable (CAT5) to transmit the power. Cisco had initially developed the technologyfor VoIP applications, with only 13W-15W of power being supplied. However, asthe scope of applications grew and the technology developed, so did the amountof power that could be supplied, with the latest performance achieving 98W ofpower delivery, as will be discussed later. To briefly explain the principle of PoEand how it works with a standard Category 5 Enhanced Ethernet Cable (CAT5E)cable version, a short introduction will be provided here. There are typically eightwires, or four twisted pairs, switches7 make use of some of these pairs to transmitthe power to the connected devices. A diagram showing the pairs on the Ethernetcable can be see in Figure 2.2, where the pairs of cables 4,5 and 7,8 are usedfor power transmission in PoE. The two standards EIA568A and EIA568B areessentially identical in functionality and performance, their major difference beingrather the used color scheme. As the details of the wiring are outside of the mainscope of interest of this work, we will not go into further detail on this topic.Once the switch capable of delivering PoE is available, the other aspect thatneeds to be considered is the array of devices that will be connected to it. Thedevice on the other end of the cable, would need to be able to receive power overEthernet, and communicate back. The common requirements for devices desiringto utilize PoE features are outlined in the Cisco specification documents[21], andfurther details on the specific operations of PoE can also be found at [22] - thispaper goes into more detail on the protocols that can be used with PoE systems,along with some of the history of development and current standards. Currentlythe most widespread used cable is CAT5E, which is often shortened to its dep-recated predecessor CAT5; in the following chapters, when referring to Category5 Enhanced Ethernet Cable the CAT5 acronym will be used, for the purpose ofsimplicity. It is important to note that there is a raising popularity of PoE, as it isnow used for wireless routers, phones, security cameras, and in some cases evenlighting[23][24], all due to the increase of power that can be supplied through asingle port. The new IEEE 802.3bt standard allows to supply up to 60W (level 3)using CAT5E, which is the power supply that was used in this work, and level 47A network switch (also called switching hub, bridging hub, officially MAC bridge) is a computernetworking device that connects devices together on a computer network, by using packetswitching to receive, process and forward data to the destination device.13Figure 2.2: A diagram showing the the cable wiring and pairs within anEthernet CAT5E cable[2]power of 90-100W which can be used with a Category 6 Ethernet Cable (CAT6)cable for higher power application [25][26]. If even more power is required, itcan be delivered by combining some of the ports, therefore doubling or triplingthe power supply; this in turn complicates the setup process and the hardware re-quired, but broadens the possible applications. All of these aspects, as well as theresearch being performed right now for Direct Current (DC) nanogrids [27], andrenewable energy sources, makes PoE an attractive method for delivering and dis-tributing power now, and even more so in the future. In the context of smart houses,the power delivery capabilities through PoE-enabled networks allows an electricalinfrastructure where the DC power and data are physically distributed through the14same physical cables throughout the entire building.15Chapter 3Concept and ImplementationThe concept began with the inception of the system architecture. It needed to havethe ability to be scalable, which means that the system had to have the ability to beexpanded without major changes, alterations or disruptions. The sensor hubs, withthe bigger picture in mind, needed to be easily controlled and configured, and thesystem itself should be reasonably power efficient and deployable. The power effi-ciency and deployability were achieved by using PoE, varying sensor hub classes,with the corresponding varying operation schedules, and semi-distributed data pro-cessing with a heavy emphasis on cloud computing. The general overview of thearchitecture can be seen in Figure 3.1. The inter-system communication and link-age, in addition to providing the possibility of hierarchical and remote control,allows for system to be optimized with regards to power consumption and process-ing cycles, by only powering on the necessary hubs on a per-case basis - the roleof a hub is to act as a local sensor module interface, with some additional configu-ration and local signal processing tasks. Further details on the operation models ofoperation and classes of the hubs will be discussed in the sections below, and theprinciple behind the case-dependent activation can be observed in Figure 3.5 andFigure 3.6. The use of PoE allowed for both the data, power and control commandsto be sent via a single cable, which is already present in almost any building thathas an internet connection infrastructure.The setup of the prototype used to test the validity and feasibility of the conceptproposed in this work has used a Cisco Catalyst 4507R+E switch [28] to handle16Figure 3.1: General architecture viewthe routing and supply the power to the sensor hub network [29]. The Catalystswitches of these series are capable of delivering up to 60W per port using Uni-versal Power Over Ethernet (UPOE), which essentially doubles the per-port poweroutput specified by the PoE standard [30] . In this setup a hub is a Microcon-troller Board (MCB) capable of receiving PoE, either by means of a shield1 or anintegrated adapter, and is capable of housing the Linux kernel. While the currentprototype used an Ubuntu distribution, a lighter operating system, such as PuppyLinux2 or Archive Linux, ArchLinux 3, can be used on MCBs with less resources,as well as scenarios where the size of the hub has higher priority over the amountof local processing that is necessary. A good example of such a scenario would bethe slave class hubs, which will be discussed later in this chapter. Due to their tasks1 non-resource-demanding, the proposed scheme of optimization can be usedto reduce costs. The booting sequence of the operating system on the MCBs usedin the experiment was modified to reduce booting time, by preventing programsand services unnecessary for the functionality of the system from loading. A highlevel overview diagram of the system concept can be found in the Figure 3.2 below.The figure outlines the overall set-up that was assembled, while later a lower leveldescription will be provided to accompany the discussed details.Figure 3.2: A high level diagram of the implemented system set-up3.1 Design Considerations and DecisionsFor the prototype that was used to test the concept, sensors which can give rele-vant data about the state of a building or a room were used. In particular such at-tributes as the temperature, humidity, vibration on the walls as well as illumination18were measured. These attributes were chosen in order to simulate real deployment,where the system may be used either to make a room or building ”smart”, monitorstructural integrity, or both. A strain gauge sensor was considered but not used, asthe one necessary for building monitoring would need to be of wide are of effect, tomeasure things such as settlement of a building. Due to the fact that such a sensoris not currently readily available, within economical constraints that would be fea-sible for a prototype test, this portion of the testing can be conducted at a later stageof development. Hardware components, aside from the Cisco switch and sensors,consisted of a Raspberry Pi microcontroller board, which acted as an MCB, and aCisco UPoE power splitter[30]. The power splitter was used to separate the dataand the power supply, as Raspberry Pi does not natively support PoE, and to lowerthe voltage supplied to the board over the Ethernet cable (48V) down to 12V DC,which is one of the operational voltages of this particular MCB. Raspberry Pi waschosen as the MCB for the project due to its economical benefits, wide range ofcapabilities and features, as well as a large support community and low level ac-cess to the core of the board. The low level access was a very desired attribute, asit allowed to alter and modify performance and operational routines. Overall thisresulted in Raspberry Pi being the optimal choice in terms of price-to-performanceratio.Complementary to the hardware architecture, there were a number of consid-erations and design decisions that needed to be made regarding the software com-ponent; in particular, the following aspects have shaped the project:1. The format to be used for the configuration files - the format had to be adap-tive in terms of operating environment, be able to store metadata4 aboutthe components, and be easily convertible to other formats if necessary, in-cluding manual inspection. Such configuration file formats as the INI5 fileformat, Extensible Markup Language (XML) and JavaScript Object Nota-tion (JSON).2. The database structure and format to be used, as the winning contestantwould need to house large amounts of scientific data, and be able to quickly4Metadata - a set of data that describes and gives information about other data.5INI file format is an informal standard for configuration files for some platforms or software.19and efficiently traverse and possibly process it. The operation would also oc-cur online, as such the constraints imposed with that need to be heeded. Theconsidered options were the Hierarchical Data Format (Hierarchical DataFormat - version 5 (HDF5)), an open standard originally developed at theNational Center for Supercomputing Applications and supported by Math-works, the Technical Data Management and Streaming (TDMS) file format[31] by National Instruments (National Instruments (NI)), an open formatwidely used for LabView applications, and as such could potentially be agood solution. Another open format that was considered was the ROOT fileformat6, developed by CERN7. While a ROOT file is a list of consecutivedata records, labeled TKeys by the developers, ROOT itself is a modular sci-entific software framework, which is written primarily in C++, but certaininstances are also available for Python8 and R9. Lastly, a more traditionalStructured Query Language (SQL) database was considered for storing andprocessing data.3. The last component of the system to be decided is the central processor.According to the concept this processor would be virtual and scalable, aswell as accessible from any internet connected device. As such a number ofcloud computing services were considered, as well as the option of locallyhosted server. For cloud computing services the EC210 provided by AmazonINC as well as DigitalOcean11 were investigated as potential solutions.After careful consideration and investigation, JSON (JavaScript Object Nota-tion) was chosen as the configuration file format. The INI file extension, whileconvenient on some platforms was not as versatile or adaptable, and it did not pro-vide an easy hierarchy between the various fields. As for the XML format, whilepossessing similar properties, its use has deviated to other applications, and be-ing a predecessor to JSON, it was decided that it would not be the best candidate6 - The European Organization for Nuclear Research8A programming language - - a programming language for statistical computing and graphics - the task. As a result the versatility, convertibility and its wide acceptance, itshierarchical properties, along with the fact that its intended use aligned with our ap-plication, have driven the decision to use JSON as file format for the configurationfiles for the transducer nodes in the network. When choosing the database that willbe used for the collected data in this architecture concept, a first candidate was NITDMS; while possessing some good quality regarding hierarchical organization,data control and efficient read-write access of very large scientific data, it was per-ceived as too restricted in its use and integration, and widespread use (its primaryapplication was with NI software). This format was considered non-ideal for theintended design, which aims to increase adaptability and scalability of sensor net-works with minimal restrictions. The ROOT system, on the other hand, has showngreat possibilities, and the tools that come with the platform may make it a suitablecandidate for a future improvement of the design. However, at its current stage, thecomplexity of the data structure as presented by ROOT, along with the associatedintegration difficulties, caused this format to not be the number one choice for thisparticular design. Lastly, SQL database format is very widely used for web ap-plications; however, heavy customization or a design scheme would be needed toadd metadata or hierarchy to the collected data. While it would provide an ease ofdeployment and integration with other systems, which satisfies the adaptability re-quirement, the lack of hierarchy and metadata capabilities caused this variant to bedisregarded as well. As such, the HDF5 format, which posses both the metadata ca-pabilities as well as hierarchical data structure, in addition to being lightweight forfile transfers and easily used with other scientific software for data analysis (suchas MatLab), made it the ideal choice to be used for the data structure. The need forflexible export and import capabilities stems form the fact that many researchersuse a variety of different tools to conduct their research and store and evaluate theirdata. Therefore a file format which can be easily shared between researchers fromdifferent institutions, and that has a wide support from the open source commu-nity, such as the HDF5, would be ideal for the application of a widely deployedsensor network, and hence was chosen. The locally hosted server was ultimatelydisregarded, due to a number of reasons. First of all, it would not allow for the sys-tem to be adequately tested to verify its scalability, in particular the internationaldeployment, as discussed in Chapter 4, as the results would be too skewed to al-21low adequate assessment. Secondly, the limitations of a single piece of hardware,since the server would be set up as a local desktop computer, in addition to possi-ble service disruptions (due to hardware, software or local network failure) madeit an undesirable solution for housing the developed system. When consideringcloud computing, both EC2 and DigitalOcean provided similar services. The pri-mary advantage of EC2 would be the ability of rapid increase in processing powerwhen necessary, which can be very beneficial on a larger scale of deployment, andmay be used in the future. However this service provided economic drawbackswhich, along with the dependability and security of DigitalOcean, caused the latterto be the cloud computing service of choice. These decisions led to the creationof an architecture concept that was implemented in a prototype system, the basicrequirements of which will be discussed below in Section System RequirementsThere is a short list of requirements for the components that can be used to set upthe system. In particular the MCB should have:1. Sufficient processing capabilities - The MCB, which will serve as a sensorhub module needs to be able to run either Linux, or some operation systemthat is capable of connecting to the internet and executing python scripts (inthe current iteration). It also needs to able to process and package the datainto HDF5 format for sending.2. An interface to connect the sensors - The MCB needs the capability toconnect the various types of sensors that are necessary for a given task. Theconnection and corresponding peripherals can be either wired or wirelessby nature, depending on the MCB’s capabilities and other requirements andrestraints of a given application.3. Sufficient storage - This aspect needs to be considered for MCBs that willoperate in semi-autonomous and autonomous modes, as described in Sec-tion 3.5. The storage requirement in this case will be dictated by the amountof information to be processed and stored, which in turn is determined by22the application. In the current set-up the dedicated storage for the data was4Gb.4. PoE capable - last major requirement is the ability to operate with PoE. Thiscan be accomplished either by a built-in circuitry that the MCB has, or bya means of a shield, such as the Pi POE Switch hat for Raspberry Pi, or aCisco Catalyst Power Splitter for many of the other boards.Figure 3.3: A snipped of the JSON code that is used to storeconfiguration settings3.3 Sensor Hub ClassesThere are two general classes of sensor hubs in this system set-up. A master classsensor hub and a slave class sensor hub. The naming convention was used due tothe behavior of the system as described below.1. Master - is a sensor hub class which can operate in either fully autonomousor semi-autonomous modes of operation, which will be discussed in furtherdetail in 3.5. In order for a hub to be assigned in this class, it needs sufficientprocessing power - the amount is dictated by the exact application and per-formance constraints. While in possession of this class label, the hub mayissue commands to the slave class hubs assigned to it, for example to gather23more data. In addition, it will also be capable of bidirectional communica-tion with the server.2. Slave - is a sensor hub class which is capable only of one mode of opera-tion. However, while it is unable to perform complex or resource demandingtasks locally, it provides the benefit of a lighter build. This in turn meansthat the hub may have much smaller physical dimensions and may be moreeconomical, which provides a more financially efficient solution on largerscales.3.4 Configuration of the HubsAs seen in Figure 3.4 the implemented edit menu provides the user with the abilityto configure all of the sensor hub modules via the web interface, remotely. Thechanges made there will be carried over into the master configuration file, which isstored on the server. The configuration file uses JavaScript Object Notation (JSON)format to store all the settings and relay them to the respective modules. Onceany changes have been made the server will issue an update notification to theMCBs that have been affected, once the MCBs receive the notification and haveprepared to receive information the new configuration file for them will be created,sent and applied, upon which the changes will have taken effect. The individualconfiguration file is created by taking a relevant snippet of the JSON master listfile that contains the information of all the MCBs, including the ones that wereaffected. That snippet is then used to create the file that will be sent. An examplesnippet of the JSON code that is used in the system can be found in Figure 3.3.If desired, all of the settings can be altered by directly accessing the back endas well, assuming sufficient access privileges are present. This can be done byestablishing an Secure Shell Script (SSH) connection to the server, using the afore-mentioned credentials with sufficient access privileges, and accessing the masterlist. Following the access and editing, the changes will be propagated throughoutthe system in the same manner as when the changes were made via the online inter-face. A derivative of this method would be to use an File Transfer Protocol (FTP)access program, to gain visual access to the files on the server.24Figure 3.4: A screenshot of the web view of the user interface and configuration windowThe numbers highlighted in the figure are used to reference the fields they are located at, where: 1 is the name of the Master orSlave module, 2 is the mode of operation, 3 is the IP address of the module, 4 is the IP address of the corresponding switch ormaster module, 5 is the name of the cluster, 6 is the pin or port that the cluster is connected to on the board module, 7 is the e-mailaddress of the person to contact in case of anomalies, 8 is the path within the HDF5 file, 9 are the headings in the HDF5 file thatwill be monitored, 10 are the minimum thresholds for the specified parameters, 11 are the maximum thresholds for the specifiedparameters.253.5 Requirements and Modes of OperationWhile the MCB acts a sensor hub, it can house a number of logical clusters ofsensors, for example a sensor that provides multiple types of data, such as an ac-celerometer or a humidity and temperature sensor such as DHT22 [32]. The hier-archy of the system takes into account what is considered a parameter, as is seen inFigure 3.4. The MCB, which, as long as it meets the requirements outlined in Sec-tion 3.2, is non-discriminant of the type and model used, communicates directlywith the server. The server is located on a cloud computing12 service host - in thecase of this implementation DigitalOcean was used. However, depending on theapplication, the server can be both outsourced to a third party or hosted locallydepending on the available resources and performance needs. In addition to thepreviously implemented functionality of a master/slave status of the sensor hubs,which focused more on power consumption control, the system now also has threemodes of operation, designed to allow it to adapt to almost any scenario. Thesemodes are:1. Autonomous The sensor hub functions individually, conducting all of dataprocessing locally, and performing actuation and/or executing scenario scriptsas is dictated by its local code. The hub will periodically send its stored in-formation to the server. When operating in this mode the hub will also pe-riodically probe the server to determine whether it is operational and verifythe presence of an active internet connection. If either one of these tests failsto produce a positive response, an error will be logged, noting the details ofthe discovered failure, and brought to the attention of the person in chargeonce proper operation is restored and confirmed. A diagram outlining theoperational architecture of the algorithm can be seen in Figure 3.5.2. Semi-autonomous The most common mode of operation, typically usedby the master class sensor hubs. When operating in this mode, local pro-cessing of the data will only be applied to sources of information marked astime-critical, once processing is complete the hub will then act based on the12Cloud Computing - the practice of using a network of remote servers hosted on the Internet tostore, manage, and process data, rather than a local server or a personal computer.26results. Data that is categorized as non-time-critical will simply be periodi-cally forwarded to the server by the hub. A diagram outlining the algorithmof this mode of operation can be seen in Figure 3.6.3. Follower The most basic mode in which the hub will simply execute thecommands it was given by either the server or the master class hub. Theprimary function of this class is to continuously forward all of the collecteddata to the server for processing for as long as it was instructed to do so.3.6 Parameters, Organization and Data ProcessingEach parameter has maximum and minimum threshold values, if the current valueof the reading exceeds either of the threshold values an alarm is triggered. A pa-rameter in this context is defined as a data source for a specific hub. The alarmroutine visually highlights the value on the web page for manual inspection, as canbe seen in Figure 3.9 and sends a notification to the corresponding e-mail of theconcerned party. In addition the error is kept in a log of alarms which is present onthe main header tab, as can be seen in Figures 3.4, 3.8 and 3.9. The alarm will alsotrigger an additional data request. This request will wake up all of the slave hubsthat are under the master hub which recorded the anomaly. Once awake the slavehubs will collect an additional set of data to either confirm or deny the presenceof the anomaly that was picked up from the readings provided by the master classhub. This approach shows signs of being very useful for applications in the civilengineering industry, for monitoring civil structures. In particular it can be used tomonitor the health of a bridge as well as a building, especially in cases of emer-gency such as, for example, an earthquake.The original system had a very limited speed and scalability due to the uti-lization of RS23213 for communication with the client/server which was a localUbuntu machine, physically connected to the switch[17]. This set up in turn alsolimited the scalability of the system, as it required there to be a separate, constantlyoperational machine for every switch. These individual machines would in turn13RS-232 is a standard for serial communication transmission of data27Figure 3.5: A diagram displaying the high level algorithm ofautonomous mode of operation28Figure 3.6: A diagram displaying the high level algorithm ofsemi-autonomous mode of operation29need another layer of abstraction or a system to connect them into one single sys-tem. Another issue that was present is the limitation imposed by the Category 5Ethernet Cable (CAT5) and CAT5E cables, which are used by the PoE configura-tion. The aforementioned limitation is the distance that the cable can cover, whichis 90m according to the TIA-EIA-568-A standard [33], before signal degradationrequires for the connection to be terminated or re-amplified. This issue becomesmore apparent when using DC current, which is the method of power transmissionin PoE systems. The reason it becomes apparent is due to power losses as describedin their white paper by CommScope[4], Petrosky [25] as well as by numeroussetup manuals for PoE installations and patents such as the patent described in [26]as well as the Cisco Manuals [28] and [29] to name a few.By unifying the main control under one server, and allowing it to communicatewith any of the switches or hubs from a single location, the scalability becomes atrivial matter. This is linked to the fact that an element can be introduced to thesystem without excessive reworking of the code or a large scale rearrangement ofthe system. As a result, ease of introduction, as well as easily established hierar-chical relationship between the elements, allows the system to grow and expand onany level, assuming the central processing entity possesses the resources needed tohandle the expanded data inflow. This matter is in turn resolved by the utilizationof cloud computing, which allows for prompt and simple resource allocation. Thisgreatly simplifies the task of expansion, as long as the operator planned ahead, inorder to eliminate potential down time of the system. As the new elements can beintroduced without interrupting the operation of the remainder of the system.To facilitate direct access to the switch and its settings, it must first be config-ured to allow SSH [28] [29]. Once that is done the switch can be accessed remotelyby any machine that has access to the internet and the terminal, through the servervirtual machine, assuming it has the access privileges for that level. To further au-tomate the process, a macro can be saved for each switch if necessary by writinga simple script which will pull the necessary credentials from a configuration filecontaining the information on the switches, hubs and sensors [? ][34]. Due to theneed for security, as the switches may potentially have a lot of control within a30building, measures need to be taken to secure the information and access to thehardware as well as control instances. However due to the focus of this work beingthe improvement of scalability, adaptability and responsiveness this aspect will befurther discussed in Chapter 5 as future work and recommendations. One of theprimary uses for automatic SSH scripts in this work is to issue commands to theswitch remotely and autonomously, such as in the case where additional slave hubsneed to be activated. For this purpose Tool Command Language (TCL), is used onthe switch side. It is invoked by the server once an SSH connection is establishedand can be configured to perform a variety of tasks in addition to controlling thepower supply. A CRON job14 is used to perform a series of regular, periodic checkson the non-time-critical data, the server also constantly listens to any alerts fromthe hubs. The script can be activated in two cases, either an alert about an anomalyis received directly from the master hub, which processed the critical data locally,or derived from processing the information on the server. Each hub, if requestingadditional data, will transmit its ID along with the request, which will be used tolook up the required credentials. Once found, a script will be run to issue the com-mand to the corresponding switch and slave hubs. When the data is processed onthe server the IP address of the hub that detected the anomaly will be used to findthe required credentials.3.7 Data Processing and PresentationAs mentioned previously, data is formatted and stored in HDF5 format. The use ofthis format allows to assign meta data to the gathered measurements, which sim-plifies and speeds up the process of parsing the data for further processing[35]. Aswell as cross platform import, in cases where different parties want to use differ-ent software to analyze the data locally[36]. In addition once the data has beenarranged correctly, the new transition times of file transfer become shorter, as thedata files are a lot more compact and light weight. In order to achieve this, theraw data is first gathered from the individual sensors. A preassigned name is usedto label the source of information, the name is obtained from the JSON configu-14CRON is a software utility that acts as a time-based job scheduler in Unix-like computer oper-ating systems31Figure 3.7: A diagram displaying the structure of the HDF5 data format [3]ration file. In addition the type of data that is being gathered, as well as its safetyconstraints are also used as the meta data for the measurement. Once formattedcorrectly, the newly arranged data is stored in its own sub directory of the localdatabase, as seen in Figure 3.7, along with the other measurements. On the serverside the data is the extracted, parsed into arrays and displayed to the user.3.8 The HierarchyHierarchy is a very important aspect in a project that emphasizes scalability suchas the one discussed in this work. As the two are directly linked and it relates to:• Access levels - who should have access to which devices and services?• Control level - how many units do you want to issue a command to or whicharea do you wish to cover?• Error location - What is the location of the device that is causing errors (incase of malfunction)? What is connected to it? What in that chain of com-32Figure 3.8: A diagram displaying the graph view representation of the datamand could be causing it?As such a few approaches are used to introduce the concept of hierarchy intothe system. The database format that is used to send, store and process the datais Hierarchical Data Format - version 5 (HDF5), which is great for fast transfer ofdata due to its ability to keep the file sizes low and well organized. The latter pointalso makes it great for processing, as accessing any piece of information from thedatabase or parsing it becomes simple when using HDF5.Hierarchy is also employed in other aspects of the design, as can be seen inFigure 3.10, the hierarchy determines the amount of control a unit has. For exam-ple a server has full authority, while a single salve hub has none. This ”chain ofcommand” makes propagation of commands rather simple and clean.For the comfort of user experience the web interface also allows the operator tosee the hierarchy of the system visually as can be seen in Figure 3.11. As shown bythe figure the separation can be done on any level that is required by the application.Due to the fact that in this particular case the testing was done internationally bydeploying the system in Canada and in Europe there are two main branches ofinformation. Additional levels can be used for commercial applications, such as33Figure 3.9: A diagram displaying the table view representation of the datafloor numbers, buildings, city blocks etc.34Figure 3.10: A high-level diagram outlining the hierarchy of the systemFigure 3.11: A screenshot of the web view of the hierarchy of the system35Chapter 4Testing and ApplicationsA number of components in this system were tested and the testing was separatedinto two general stages: a local testing stage and a global testing stage. The localtesting examined the system performance and response to such factors as:• Hardware variation• Module integration and alteration• Power transmission and control using PoE• Localized data processing• Local control sequence testing• Slave hub activation and anomaly responseWhereas the globalized part of the testing focused more on the aspects of the scal-ability of the systems. Such as:• Deploying the system in a cross-continental setting IN Canada and Germany• Testing the response speed of the system• Data transfer speed testing• Configuration modification and propagation response testing• Multi-modular deployment testThe experimental setup used for local testing can be seen in Figure 4.1. Theperformed tests examined the closed loop response of the system in a zero-accesssetting, without access to the internet and the main server. In this setting the data36was to be processed locally and the commands were issued by the master classhubs. This test looked at a number of aspects of the system. It examined how local-ized data processing performed, whether commands issued directly by the masterclass hubs would be accepted and followed by the network switch, and whether thepower supply acts in accordance to the issued commands. These are all importantaspects of a system that uses PoE, and ongoing testing was conducted during thedevelopment of the system to ensure correct operation. As a test of adaptabilityand modularity of the system, a different microcontroller board was used, in par-ticular the BeagleBone development board1. After a simple configuration of theoutput pins, no other changes were necessary. Furthermore, the reconfigurationcan be done remotely, using either the online editor interface, or a direct back endconnection using SSH. The sending, receiving and processing schemes as well asthe control modes all performed as expected without any errors, and did not requireany excessive remodeling or re-coding.Once the system proved to be operational, and successfully passed all of thelocal tests a number of aspects necessary for scalability were tested. These testsfocus more on the software portion of the prototype, and were meant to accessthe feasibility of use of such a system rather than claiming certain benchmarks.The first aspect to undergo examination was the aspect of connection speeds be-tween the machine and the server. Due to the fact that the primary limitations ofthe connection speed are the Internet Service Provider imposed limitations and thenumber of hops the transmission has to go through, which usually correlates withthe geographic location of the communicating parties and is decided by the InternetService Provider (ISP). The average time for the European setup was 42ms whilethe average Canadian time was 190ms. Due to the server being located in Ger-many these results are to be expected. For more optimal transfer times a number ofmodifications can be implemented, among which are the use of a cloud computingservice whose servers are geographically close to the site of operations or personalservers which would be housed directly at the project cite, or in relatively closevicinity.1 4.1: Experimental setup for local testingThe general setup for testing the scalability was done by connecting two se-tups from two different continents. The first setup was done in Vancouver, Canada,North America while the second one was done in Augsburg, Germany, Europe.Each system consisted of at least one master class and at least one slave class mod-ule. Each of the modules had a number of sensors connected to them. While someof the sensors that were connected varied between the two setups, an illuminationsensor, a vibration sensor, temperature and humidity sensor as well as power sen-sor were used in different configurations on all of the MCBs. After the initial setupwas complete, to test operational stability and performance, a latency test was per-formed. The test was carried out over the course of 15 days, at approximately thesame local time, the peak demand period of afternoon was used as studies haveshown that around 14:00 is when internet usage is the heaviest according to [37].During the measurement, three samples were taken and recorded. The resultinglatency statistics can be found in Figure 4.2 where sub-figure 4.2a displays the38(a) Augsburg (b) VancouverFigure 4.2: Latency test results for the two cities where the tests were con-ducted.latency measurement results obtained in Augsburg and sub-figure 4.2b shows themeasurement results in Vancouver. Over the course of testing there has been mini-mal package loss (11%), even in cases of long transition routes, such as in case ofthe Vancouver measurement. During the testing there were no errors detected onthe server side with neither the data nor the request handling. The system showedno issues handling the requests from both of the setups and operating with bothsets of MCBs, even in cases where their requests arrived nearly simultaneously.A full scale test of the system will be conducted as part of the Green Campus39Project in Hoschule Augsburg, Germany. There the system will be used to monitorthe energy consumption and generation around a section of the new building thathas been built,as well as its structural integrity and interior climate. For this pur-pose vibration sensors, LDT0-028K was chosen as the sensor of choice as it hasshown to perform well for the purposes of earthquake detection and building vi-bration [38] as well as parasitic power generation as discussed by P. Glynne-Jonesin their work outlined in [39]. Large area of effect strain sensors, such as a long-gage fiber optic sensor, which have been shown to perform well as civil structuremonitoring device as explained in their overview paper by H.N. Li et. al. [40] aswell as in the paper by S. Li et. al. who discussed the feasibility of a distributedsystem of such sensors in [41]. As well as temperature and humidity sensors, suchas the DHT22 and power measuring sensors will be used. The alpha prototypehas tested the correctness of operation of the vibration sensor, temperature and hu-midity sensor and the power measurement sensor by assembling a circuit for eachand calibrating their outputs. Once the obtained readings matched the expectedvalues, which were obtained by performing a control measurement by industrymanufactured devices, the operation level was deemed feasible. During the testingthe feasibility of use of DHT11 temperature and humidity sensor was tested, how-ever high levels of inaccuracy in readings (over 15% deviation) and other hardwarerelated issues made us consider the sensor as unreliable for the purposes of testing.40Chapter 5Conclusions and Future WorkIn conclusion, the developed architecture has improved a number of aspects, asoriginally outlined by the goals. The scalability was improved by simplifying themodification of the element base, by incorporating JSON configuration files andtheir respective control schemes. It was also improved through the incorporationof IoT communication principles, as well the use of PoE and cloud computing,which allows for a more accessible and efficient expansion and larger areas of de-ployment. The design also showed improvements compared to similar systemsin adjustability, as all of the elements can be altered, added or removed withoutinterrupting the operation of the system as a whole. Furthermore any softwarechanges automatically propagate through the affected areas, which also allows fora relatively high degree of plug-and-play ability. Lastly the design introduces im-provement to aspects of reliability and adjustability, by incorporating algorithmsfor self checking, a semi-centralized architecture, and absence of dependence onany single component within the system. Furthermore the use of cloud computingallows for redundancy in terms of processing power and robustness, as well as se-cure remote access and control capability. Whereas the hierarchy that is entwinedinto the organizational structure of the design, allows for a high degree of controla-bility, due to easy localization, isolation, and targeted addressing. Nevertheless, inorder to adapt the design for commercial use there are still a number of improve-ments that could be made that would benefit the performance. The major aspectto be considered is the enhancement of security and, in case of in-house servers,41more elaborate data routing and handling. While a certain level of security it isobtained by securing the server the system can benefit from employing SoftwareDefined Networking, SDN, to improve internal routing, which would in turn im-prove and optimize data handling as well as packet control to ensure no tamperingor unauthorized access occurs. In their work Kapil B. [42] outline how the employ-ment of Software Defined Networking (SDN)s can benefit a network, and quantifythe performance benefits of such a transition form the traditional hardware definednetworks. Furthermore the use of SDNs could also further improve the speed aswell as the type of data that can be available, for example a video feed of a roomor area of interest, which could in turn be used for an array of purposes, such asmotion detection, as well as temperature reading of a room if an Infra Red camerais used as one example.Another improvement that can be made to the system is further segmentationand automation of access to different levels of the system. This includes addingthe capability to select an ”area of effect” which can be defined based on the ap-plication, but in case of buildings it would define what portion of the building isaffected by a certain action.While there has been work done on Real Time Ethernet (RTE) systems, theyprimarily focused on data transfers within small time windows, primarily in anindustrial setting for motion control [43] [44]. With this being the case the questionof power, and PoE has not been considered in that context. A possible course ofdevelopment for this concept can be its integration with RTE for more industrialapplications and even more time efficient operation, however that was outside ofthe scope of this work and has therefore not been investigated in detail.As a result, a system that matches the set goals has been developed. The systemis capable of operating by utilizing Power over Ethernet (PoE), which drasticallysimplifies installation procedures as well as reduces power consumption costs. Byplacing the central client of the system in the cloud, an online processing service,a high degree of scalability has been achieved, as well as a high degree of control-lability, which is are very important aspects of the Internet of Things (IoT), field.The system can be further improved to increase the security of the transmitteddata, as well as to reduce the size of the MCBs used. Nevertheless as it currently42stands it can greatly benefit smart buildings, large buildings that wish to reduce theamount of power consumed by the Heating, Ventilation and Air Conditioning sys-tem (HVAC), as well as buildings that apply new building technology and materialsand need to analyze their performance. The power necessary for actuation can beprovided by using local energy storage units in form of some battery that can betrickle charged using PoE. As can be expected the system function well with thebig data approach and has been tested to be operational in a trans-continental setup, where the gathered data was accessible from any machine that had access to theinternet, and the processing and transfer of the data was completed in a timely andefficient manner, due to high processing capabilities of cloud computing machinesand small size of the files that used HDF5 database format.43Bibliography[1] I. Lobachev and E. Cretu, “Smart sensor network for smart buildings,” inInformation Technology, Electronics and Mobile Communication Conference(IEMCON), 2016 IEEE 7th Annual, pp. 1–7, IEEE, 2016. → pages iv[2] IEB Media GbR, “Cat5e cable wiring schemes and the 568a and 568bwiring standards,” 2010. → pages viii, 14[3] F. G. Osorio, M. Xinran, Y. Liu, P. Lusina, and E. Cretu, “Sensor networkusing power-over-ethernet,” in Computing and Communication (IEMCON),2015 International Conference and Workshop on, pp. 1–7, IEEE, 2015. →pages viii, 32[4] COMMSCOPE INC, Laying the groundwork for a new level of Power overEthernet, 2015. → pages ix, 2, 30, 50, 51[5] R. Goldstein and D. Neuman, “Mega-buildings: Benefits and opportunitiesof renewal and reusethe essential role of existing buildings in a carbonneutral world,” in Proceedings of the American Institute of ArchitectsNational Convention and Design Exposition held in Miami, Florida, USA,10-12 June, 2010. → pages 1[6] United Nations, Department of Economic and Social Affairs, PopulationDivision, World Urbanization Prospects: The 2014 Revision, Highlights(ST/ESA/SER.A/352), 2014. → pages 1[7] J. A. Rice, K. Mechitov, S.-H. Sim, T. Nagayama, S. Jang, R. Kim, B. F.Spencer Jr, G. Agha, and Y. Fujino, “Flexible smart sensor framework forautonomous structural health monitoring,” Smart structures and Systems,vol. 6, no. 5-6, pp. 423–438, 2010. → pages 5[8] O. Kasten and M. Langheinrich, “First experiences with bluetooth in thesmart-its distributed sensor network,” in Workshop on UbiquitousComputing and Communications, PACT, vol. 1, 2001. → pages 644[9] P. Rawat, K. D. Singh, H. Chaouchi, and J. M. Bonnin, “Wireless sensornetworks: a survey on recent developments and potential synergies,” TheJournal of supercomputing, vol. 68, no. 1, pp. 1–48, 2014. → pages 6[10] S. Xie and Y. Wang, “Construction of tree network with limited deliverylatency in homogeneous wireless sensor networks,” Wireless personalcommunications, vol. 78, no. 1, pp. 231–246, 2014. → pages 6[11] M. E. Keskin, I˙. K. Altınel, N. Aras, and C. Ersoy, “Wireless sensor networklifetime maximization by optimal sensor deployment, activity scheduling,data routing and sink mobility,” Ad Hoc Networks, vol. 17, pp. 18–36, 2014.→ pages 6[12] M. Magno, T. Polonelli, L. Benini, and E. Popovici, “A low cost, highlyscalable wireless sensor network solution to achieve smart led light controlfor green buildings,” IEEE Sensors Journal, vol. 15, no. 5, pp. 2963–2973,2015. → pages 6[13] O. Kreibich, J. Neuzil, and R. Smid, “Quality-based multiple-sensor fusionin an industrial wireless sensor network for mcm,” IEEE Transactions onIndustrial Electronics, vol. 61, no. 9, pp. 4903–4911, 2014. → pages 6[14] Y. Liu, Y. He, M. Li, J. Wang, K. Liu, and X. Li, “Does wireless sensornetwork scale? a measurement study on greenorbs,” IEEE Transactions onParallel and Distributed Systems, vol. 24, no. 10, pp. 1983–1993, 2013. →pages 6[15] N. Xu, S. Rangwala, K. K. Chintalapudi, D. Ganesan, A. Broad,R. Govindan, and D. Estrin, “A wireless sensor network for structuralmonitoring,” in Proceedings of the 2nd international conference onEmbedded networked sensor systems, pp. 13–24, ACM, 2004. → pages 6[16] K. Chintalapudi, T. Fu, J. Paek, N. Kothari, S. Rangwala, J. Caffrey,R. Govindan, E. Johnson, and S. Masri, “Monitoring civil structures with awireless sensor network,” Internet Computing, IEEE, vol. 10, no. 2,pp. 26–34, 2006. → pages 6[17] W. Townsend, “The barretthand grasper-programmably flexible parthandling and assembly,” Industrial Robot: an international journal, vol. 27,no. 3, pp. 181–188, 2000. → pages 7, 27[18] H. J. Visser and R. J. Vullers, “Rf energy harvesting and transport forwireless sensor network applications: Principles and requirements,”Proceedings of the IEEE, vol. 101, no. 6, pp. 1410–1423, 2013. → pages 745[19] A. Pantelopoulos and N. G. Bourbakis, “A survey on wearable sensor-basedsystems for health monitoring and prognosis,” IEEE Transactions onSystems, Man, and Cybernetics, Part C (Applications and Reviews), vol. 40,no. 1, pp. 1–12, 2010. → pages 8[20] C.-Y. Chong and S. P. Kumar, “Sensor networks: evolution, opportunities,and challenges,” Proceedings of the IEEE, vol. 91, no. 8, pp. 1247–1256,2003. → pages 8[21] Cisco Systems INC, Cisco Power over Ethernet (PoE) Power Requirements,2015. → pages 13[22] G. Mendelson, “All you need to know about power over ethernet (poe) andthe ieee 802.3 af standard,” Internet Citation,[Online] Jun, 2004. → pages13[23] A. A. Mangiaracina and L. O. Nielson, “Lighting utilizing power over theethernet,” Apr. 23 2008. US Patent App. 12/108,074. → pages 13[24] J. Johnston, J. Counsell, G. Banks, and M. J. Stewart, “Beyond power overethernet: the development of digital energy networks for buildings,” inCIBSE Technical Symposium 2012-Buildings Systems and Services for the21st Century, pp. Session–5, 2012. → pages 13[25] J. Petroski, “Power over ethernet thermal analysis with an engineeringmechanics approach,” in 2016 32nd Thermal Measurement, Modeling &Management Symposium (SEMI-THERM), pp. 50–56, IEEE, 2016. → pages14, 30[26] B. Buckmeier, E. Edralin, and J. M. Hess, “Power over ethernet for10gbase-t ethernet,” Aug. 20 2015. US Patent App. 14/831,102. → pages14, 30[27] B. Nordman and K. Christensen, “Local power distribution with nanogrids,”in Green Computing Conference (IGCC), 2013 International, pp. 1–8, IEEE,2013. → pages 14[28] D. Barnes and B. Sakandar, Cisco LAN switching fundamentals. CiscoPress, 2004. → pages 16, 30[29] Cisco INC, Cisco Catalyst 4500E Supervisor Engine 8-E ConfigurationGuide (Wireless), Cisco IOS XE Release 3.7E. Cisco Press, 2 ed., 2014. →pages 17, 3046[30] Cisco Systems INC, Cisco Catalyst UPOE Power Splitter, 2015. → pages17, 19[31] National Instruments INC, “The NI TDMS File Format,” tech. rep., NationalInstruments INC, 09 2015. → pages 20[32] P. Marian, “Digital-output relative humidity humidity and temperaturesensor/module am2303,” 2016. Note: original document fromAosong(Guangzhou) Electronics Co.,Ltd. → pages 26[33] Panduit Corp., The Evolution of Copper Cabling Systems from Cat5 to Cat5eto Cat6. 2016. → pages 30[34] OpenBSD and u. p. y. IETF Group,url=, “Openssh manual.” → pages 30[35] T. Krijnen and J. Beetz, “Efficient binary serialization of ifc models usinghdf5,” 2016. → pages 31[36] M. Folk, G. Heber, Q. Koziol, E. Pourmal, and D. Robinson, “An overviewof the hdf5 technology suite and its applications,” in Proceedings of theEDBT/ICDT 2011 Workshop on Array Databases, pp. 36–47, ACM, 2011.→ pages 31[37] N. Brownlee and K. C. Claffy, “Understanding internet traffic streams:dragonflies and tortoises,” IEEE Communications magazine, vol. 40, no. 10,pp. 110–117, 2002. → pages 38[38] F. R. d. C. Alves, Low-cost vibration sensors: tendencies and applications incondition monitoring of machines and structures. PhD thesis, INSTITUTOSUPERIOR DE ENGENHARIA DE LISBOA, 2015. → pages 40[39] P. Glynne-Jones, M. Tudor, S. Beeby, and N. White, “An electromagnetic,vibration-powered generator for intelligent sensor systems,” Sensors andActuators A: Physical, vol. 110, no. 13, pp. 344 – 349, 2004. SelectedPapers from Eurosensors {XVI} Prague, Czech Republic. → pages 40[40] H.-N. Li, D.-S. Li, and G.-B. Song, “Recent applications of fiber opticsensors to health monitoring in civil engineering,” Engineering structures,vol. 26, no. 11, pp. 1647–1657, 2004. → pages 40[41] S. Li and Z. Wu, “Development of distributed long-gage fiber optic sensingsystem for structural health monitoring,” Structural Health Monitoring,vol. 6, no. 2, pp. 133–143, 2007. → pages 4047[42] K. Bakshi, “Considerations for software defined networking (sdn):approaches and use cases,” in Aerospace Conference, 2013 IEEE, pp. 1–9,IEEE, 2013. → pages 42[43] M. Felser, “Real-time ethernet - industry prospective,” Proceedings of theIEEE, vol. 93, pp. 1118–1129, June 2005. → pages 42[44] S. Vitturi, L. Peretti, L. Seno, M. Zigliotto, and C. Zunino, “Real-timeethernet networks for motion control,” Computer Standards and Interfaces,vol. 33, no. 5, pp. 465 – 476, 2011. → pages 4248Appendix ASupporting MaterialsA.1 Power over Ethernet - Operation SpecificsOne of the main principles incorporated into the design on PoE is to ensure that theEthernet data along with the power transmitted do not interfere with one anotherduring operations. This has allowed PoE to be used for a variety of applicationswhere the two streams must function simultaneously side by side. General compo-nents of a PoE setup are:• PSE - power sourcing equipment.Usually this function is fulfilled by a LANswitch with power supplying capabilities.• Cabling - The Ethernet cabling that is used to connect the elements in thesystem.• CP - Consolidation Point. Is a zone within a building up to which the cablingthat was installed from the equipment room can be fixed.• TO - Telecommunications Outlet. Can be a port for a telecommunicationconnection, such as a phone jack, or an Ethernet port in a wall.• PD - Powered Device. This is the recipient of the supplied power.As can be seen in Figure A.1 as well as Figure A.2 there are two generic con-figurations that can be utilized when designing a PoE system layout.49The configuration outlined in Figure A.1 shows an approach where the power sup-ply is centralized. As such the patch cord could be used to complete certain con-nections, however the PoE power distribution would be handled by a single unit.This brings on a challenge of positioning the switch in order to optimize its reach.Figure A.1: Power supplied form LAN equipment with end-span powersourcing equipment[4]This challenge, along with the issue of excessive power dissipation is addressedby the configuration concept shown in Figure A.2. A mid-span device that cansupply power, without disrupting the data transmission. For this reason they aretiled power injectors, and can also act as a standalone source for design scenarioswhere that is required.Figure A.2: Power supplied form mid-span power sourcing equipment[4]50Figure A.3 looks more closely at the two alternatives of two-wire set-up forPoE systems. The IEEE 802.3bt standard, allows the use of both pairs of cables,totaling four cables, to transmit the power, systems that utilize this approach refer toit as PoE Plus. This results in an umber of benefits, including more efficient powertransfer due to smaller power dissipation. However the most important benefit,is that by using both of the cables once can use both of the alternatives together,effectively doubling the amount of transmitted power.Figure A.3: Alternatives A and B for the design for use with end-span powersourcing equipment according to IEEE 802.3at-2009[4]51


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items