Project topics and materials
Get Complete Project Material File(s) Now! »
Energy Constraint of the BoWI BAN Nodess
The main constraint of our BAN system is the energy. In our study we consider that the system is energy autonomous. Ideally this means the use of ultra small battery or no battery at all. Is such cases, the system should scavenge its own energy using harvesting method from the environment. We show here the possibility and limitation of the energy harvesting system and comparison with energy reservoir.
There are two strategies: 1) produce the needed energy with energy harvesting or 2) supply the system with batteries to achieve long-life operating of the devices. In this thesis, we mainly focus on supplying nodes with energy harvesting.
Energy harvesting includes methods that generate or collect energy from the environ-ment of the circuit. There are many sources to generate energy from the environment: solar, vibrations, acoustic noise, temperature gradient, radio, etc. Many studies on energy harvest-ing exist. An interesting, but not exhaustive, summary is presented in [6]. This study gives a comparison of di erent power sources and energy capacities for Wireless Sensor Network applications. Considering a system operating with a given lifetime of 1 or 10 years, we com-pare the mean power provided with a normalized volume of 1cm3 from di erent harvesting sources and energy reservoirs. Table 1.1 from [6] summarizes these results. If we consider realistic solutions that can be used in case of BAN, we have vibrations, temperature and shoe inserts. The power delivered is around few hundreds of W .
From Table 1.1 we need to add the recently developed RF-harvesting that uses ambient radio as Wi-Fi, a good example can be found in [12]. The power generated depends on the number of ambient Wi-Fi communication and the size of the antenna. In [12], an antenna of dimension 9cm 9cm 1cm provides 18 W for typical ambient RF and 1:37mW with a dedicated radio energy source. For system with dimension of 1cm 1cm 1cm, considering the energy scales to dimensions, the harvester should provide 222nW for typical ambient RF and 17 W with a dedicated radio energy source.
In this thesis, we do not consider WSN but BAN applications. In this case, the usage of the system is daily-based, thus lifetime target is about a day. Dimensions of the system have also to be kept low to respect integration perspective. Considering these constraints, we set as a constraint that our system must not exceed the mean power budget of 100 W .
In another point of view, if we consider a system working for a day (e.g. a daily use of 16 hours of activity) with this power budget, this gives a daily energy budget of 5:76J. This is equivalent to the energy of 500 Ah of a 3:3V battery. If we consider an energy density of 300W h=L [13] this makes a battery of 5:3mm3. This shows that a BAN system, which can operate at the power budget of an energy harvesting, could be supplied by an equivalent battery as small as the system itself.
Comparison between Radio and Computation
In this section we give an overview of the tradeo between radio and computation. We saw in previous section that the energy cost of an operation is way lower than the energy to transmit a bit. The idea is to add computation to reduce the amount of data to transmit. The rst parameter to estimate is the limit from which it is equivalent to send all data or to compute to reduce this amount. We consider for this estimation that the data to be sent are the MEMs sensor values. These data are coded in 9 values of 15 bits resulting in a frame of 135 bits to send all data. In this study we consider that our algorithm is able to reduce data to be sent by 50% with one iteration equivalent to 1000 MAC operations. These values are not necessary exact, it is a rough estimate to get a rst overview of the tradeo between radio and computation.
Figure 2.1 presents the possible con gurations as function of the cost of one bit to be transmitted and the cost of one iteration of data fusion. The blue dashed line represents the limit where it is equivalent to sent all data by radio or to compute a data fusion and send the resulting data. Under this line, the system has no energy advantage to make any computation and it is therefore better to send all data directly through radio. Above this line, the data fusion achieved using local computation provides an energy gain. We reported values of technology on this gure for radio and computation considering 1000 MAC operations for the iterations. Radio values are those presented in Table 2.2. Computing values are those presented in Table 2.3 for a Cortex M3 processor and dedicated processing in 65nm and 28nm technologies. We added a red dashed line that represents the budget of 100 W for a frame rate of 50Hz. This line considers that the budget is only dedicated to radio and computation. However, in real scenario, sensors power consumption needs to be considered. Therefore, we also added purple and black dashed lines that represent 50% and 10% of the 100 W budget at 50Hz respectively.
We can see that, in this con guration Zigbee and Zyggie radio platform consume too much energy to match our objective. We need a more e cient radio transceiver or a better data fusion compression rate. We also see that for the IR-UWB radio [17], the data fusion would not be e cient at all in these conditions. But the system could easily meet our power budget if the fusion is made on a central node like a smartphone that has not the same energy constraint. For the computation, all solutions seem to be able to meet the budget but we will see later that it is not the case. In chapter 3, which provides a study of the algorithms, we will re-conduct this study with more realistic values for our system.
Integration of Algorithm in simulator
The developed simulator is similar to a toolbox. Several functions are used to generate sensors data and scenario parameters. These data are collected in structures, which are used by the algorithms to compute scenario results. Additional scripts have been written to help simulate typical application cases such as posture recognition or gesture recognition. This simulator has a statistical approach, which means some scripts produce data in les and other scripts process results for interpretation. The user chooses which parameters to x and which to monitor. In case of motion capture, methods also exist to visualize the results of algorithm.
Algorithm complexity monitoring
An interesting feature added in our simulator is the possibility to estimate the computing load of an algorithm. This computing load is estimated at runtime, which gives accurate results on the real complexity involved. The idea is to include counters in critical point of algorithm as loops. In this case the user has to estimate only core loop operations and to store it into a Comma-Separated Values (CSV) le. The simulator automatically sums up all operations for each nodes. With the add of an energetic model for each operation, it is then possible to estimate computing energy consumed at each frame. The advantage of this method is that granularity of this estimation can be controlled by the user. Figure 2.4 is a capture of the interface that summarizes the computing load of a given simulation, it is composed of 6 panels. During a run, the number of calls of the core loop that the user wants to monitor is incremented and stored in a le that represents the current scenario. These values are in the Scenario Pro le Panel of the interface. Each core loop is associated with a le that contains its computation load in terms arithmetic operations (e.g. addition, multiplication). This is represented in the Algorithm Pro le Panel. So, we can summarize the total number of operations of each node at each frame and for the whole run as described in the Operation Cost Panel. Then, with an energy model of each of these operations, as in the Energy Model Panel, the energy consumption at each frame can be estimated. We can see in the upper right corner the energy consumption of the node number 13, which is di erent depending on the mode of computation at each frame. A summary of the energy and then the global power consumption for each node is given in the Node Energy Budget Panel.
Table of contents :
1 Introduction
1.1 Wireless Sensor Network and Body Area Network
1.2 BAN Applications
1.2.1 Interest in BAN
1.2.2 Considered usages of the BoWI project
1.3 Energy Constraint of the BoWI BAN Nodess
1.4 Issues and solutions
1.5 Contributions and Document Organization
2 Preliminary Study and Realization of a Test and Simulation Environment
2.1 Energy prole of technology
2.1.1 Sensors
2.1.2 Radio transceiver
2.1.3 Computation
2.1.4 Comparison between Radio and Computation
2.2 Simulator
2.2.1 State of the art simulators
2.2.2 Simulation environment
2.2.2.1 Data synthesis scenario based
2.2.2.2 Node position and orientation
2.2.2.3 Sensors data
2.2.3 Integration of Algorithm in simulator
2.2.4 Algorithm complexity monitoring
2.3 Conclusion
3 Posture/Gesture Recogn. and MoCap Algorithms for LP Implementation
3.1 State of the Art Algorithms
3.1.1 Attitude and Heading Reference System
3.1.2 Localization
3.1.2.1 Step detection algorithm
3.1.2.2 Network localization algorithm
3.1.3 Classication
3.2 Application Solutions
3.2.1 Handling Posture and Gesture with Principal Component Analysis .
3.2.2 Posture Recognition
3.2.3 Gesture Recognition
3.2.4 Motion capture
3.3 Proposed Algorithm Solution
3.3.1 Static Orientation
3.3.2 Extended Kalman Filter
3.3.3 Iterative Position Estimation
3.3.4 Classication
3.4 Results
3.4.1 Extended Kalman Filter
3.4.2 Posture Recognition
3.4.3 Gesture recognition
3.4.4 Update of Comparison Between Radio and Computation
3.5 Conclusion
4 Design and Implementation of the Architecture of an EKF
4.1 Introduction
4.2 Design Flow Strategy
4.2.1 Exploration strategy
4.2.2 Exploration Steps
4.2.2.1 Application study
4.2.2.2 Approximate computing
4.2.2.3 Architecture Exploration using HLS
4.2.2.4 Technological dierentiation
4.3 Application Level Exploration
4.4 Approximate computing
4.4.1 Parameter denition
4.4.2 Conguration selection
4.5 Architecture Exploration using HLS
4.5.1 HLS Tool
4.5.2 Hierarchical choices
4.5.2.1 No-Reuse Architecture
4.5.2.2 Reuse Architecture
4.5.3 Matrix Product
4.5.4 Early EKF Implementation Results
4.6 Gate-level EKF Implementation Results
4.6.1 Architecture selection
4.6.2 Technology exploration
4.6.2.1 CMOS65nm
4.6.2.2 FD-SOI28nm
4.7 Conclusion
5 Adaptive system driven by motion activity
5.1 System-Level management of the node
5.1.1 The System-Level Finite State Machine
5.1.2 Computing management
5.1.3 Energy management
5.1.4 Memory, data storage
5.2 Activity detection
5.2.1 Motion estimator
5.2.2 Computing Mode selection
5.2.2.1 Method
5.2.2.2 Determining threshold
5.2.3 Results of real time adaptation
5.2.3.1 Activity reduction benets of using dynamic rates .
5.2.3.2 Accuracy reduction cost of using dynamic rates
5.3 Conclusion
6 Conclusion and perspectives
6.1 Synthesis
6.1.1 Preliminary study
6.1.2 Simulation environment
6.1.3 Algorithm Study
6.1.4 Architecture Implementation
6.1.5 Top management
6.1.6 Publication
6.2 Perspectives
Bibliography
