Module: Internet of Things 2023/2024
Assignment: Aggregation Algorithm
Disclaimer: These notes have not been subjected to the usual scrutiny reserved for formal
publications. They may be distributed outside this class only with the permission of the
instructors.
1.1 Introduction
In this assignment you need to implement an aggregation algorithm to aggregate the sensor
data based on the changes in the data (i.e. activity).
In other words, in times of high activity (i.e. more frequent changes in the data), the data should
be less aggregated to capture the changes that has occurred in the data.
In times of low activity, more samples should be aggregated into one value to save
communication bandwidth and save more energy on battery powered nodes.
1.2 Specification of Basic Features
There are three main parts:
• Storage
o Read and store the meaningful light sensor data of a node continuously in a
buffer at a rate of 2 readings per second.
o The buffer size is set to 12. The buffer can be implemented as a First-In-FirstOut (FIFO) Buffer.
• Activity Measurement
o Measure changes of the data in the buffer using the standard deviation.
Assume that a low deviation implies no interesting activities, and high deviation
implies high level of activity (e.g. human movement causing changing of light
levels).
o Use reasonable threshold settings to classify activity levels. Discuss your
setting in the report.
o The measurement may happen after collecting k readings. Set k=1 if you want
to perform measurement for every reading for fast reaction. Set k=12 if you
want to perform measurement after collecting all 12 readings. You may choose
your own k setting. Note that the implementation of FIFO buffer will be
necessary if k<12.
• Aggregation and Reporting
o After the activity measurement, an appropriate data aggregation is performed
before the reporting.
o If there no interesting activity, you can aggregate the entire buffer of 12 data
into a single average value.
o In case there is some level of activity, aggregation of every 4 data into 1 should
be used.
o For high activity, no aggregation should be used.
o The program reports the outcome by showing the buffers on the terminal.
You must follow the above specification.
For example, say we have collected integer readings to fill the entire buffer, B:
B = [0, 0, 3, 0, 2, 0, 0, 4, 0, 0, 3, 2]
The standard deviation is about 1.5 which is deemed no interesting activity. Therefore we
produce the following output buffer, X, using 12-into-1 aggregation:
X = [1.1]
With some activity, we may get the following buffer:
B = [10, 2, 12, 2, 19, 1, 19, 100, 6, 4, 66, 33]
The standard deviation is about 29 which indicates some activity. Therefore we perform 4-
into-1 aggregation to produce the following output buffer:
X = [6.5, 34.75, 27.25]
1.3 Screen snapshot of your program
When producing output to the screen, you should format the output as follows (assuming
sensor readings are integer):
B = [10, 2, 12, 2, 19, 1, 19, 100, 6, 4, 66, 33]
StdDev = 29.17
Aggregation = 4-into-1
X = [6.5, 34.75, 27.25]
See below for some samples from the terminal (if you are using a mote) or Cooja (if you are
using Cooja simulation):
1.4 Advanced Features on Data Processing
The advanced features should not replace the basic features. If needed, you can maintain
multiple source files, one for the basic feature implementation, and one for the advanced
feature implementation. You should then combine & print them in a single PDF file for
submission.
While you must strictly follow the specified format to present your output for your basic feature
implementation, you can choose your own output format for your advanced feature
implementation. However, you must provide a description so that your output presented in
your screenshots can be clearly interpreted and checked for correctness.
1.4.1 For EEEM048
In the advanced feature, you need to get readings from the light sensor and save them into a
buffer (which can be viewed as vector 𝑿 with 𝑋𝑖
representing the i-th measurement from the
light sensor). Then, you need to implement the following features.
• An estimator for the normalized autocorrelation function of X, i.e.,
𝑅̂(𝑘) =
1
(𝑛 − 𝑘)σ
2 ∑(𝑋𝑡 − μx
)(𝑋𝑡+𝑘 − μx
)
𝑛−𝑘
𝑡=1
for all 𝑘 ∈ {0,1,2, … , 𝑛 − 1}
where 𝑛 is the size of the vector 𝑿, 𝜇𝒙 is the arithmetic mean of 𝑿, and 𝜎𝑥 is the estimated
standard deviation of 𝑿.
• The discrete cosine transform of the autocorrelation vectorDCT{𝑹̂}.
S(𝑙) =
1
𝑛
∑𝑅̂(𝑘)
𝑛−1
𝑘=0
cos (
𝜋
𝑛
(𝑘 +
1
2
) (𝑙 +
1
2
)) , for all 𝑙 ∈ {0,1,2, … , 𝑛 − 1}.
1.4.2 For COM3023
In the advanced feature, you need to get readings from the light sensor and save them into a
buffer (which can be viewed as vector 𝑿 with 𝑋𝑖
representing the i-th measurement from the
light sensor. Then, you need to implement the following features.
• An estimator for the normalized autocorrelation function of X, i.e.,
𝑅̂(𝑘) =
1
(𝑛 − 𝑘)σ
2 ∑(𝑋𝑡 − μx
)(𝑋𝑡+𝑘 − μx
)
𝑛−𝑘
𝑡=1
for all 𝑘 ∈ {0,1,2, … , 𝑛 − 1}
where 𝑛 is the size of the vector 𝑿, 𝜇𝒙 is the arithmetic mean of 𝑿, and 𝜎𝑥 is the estimated
standard deviation of 𝑿.
• An estimator for the discrete power spectral density as the discrete Fourier transform of the
autocorrelation vector DFT{𝑹̂}.
S(𝑙) =
1
𝑛
∑𝑅̂(𝑘)
𝑛−1
𝑘=0
𝑒
𝑗 2𝜋 𝑘 𝑙/𝑛
, for all 𝑙 ∈ {0,1,2, … , 𝑛 −1}
where 𝑒
𝑗 = cos + 𝑗 sin (Euler's formula with 𝑗 being the imaginary unit).
1.5 Submission Materials (on Week 9)
You must submit the following materials:
• Your source code in a single PDF file.
o We will read your source code (rather than running it).
o If you split your code into several files, you must print them into a single PDF
file.
o If you submit multiple files, we'll randomly pick one to read and ignore others.
o If your file is not in PDF format, we'll open with our default application and read
from the application. The formatting may look ugly which will affect the quality
of the code presentation and readability.
o You may use color or add line numbers, they can improve readability.
o Make your code readable. Some good practices are: use of meaningful variable
names, adequate but not excessive commenting, consistent indentation, apply
don't repeat yourself (DRY) principle, etc.
• A 4-page report including a cover page. Your report must include the following contents:
o Abstract and Introduction
o Your implementation of the basic features and settings
o The results with screenshots showing the following:
▪ One screenshot for no aggregation (I.e. high activity)
▪ One screenshot for 4-into-1 aggregation (i.e. some activity)
▪ One screenshot for 12-into-1 aggregation (i.e. low activity)
o Your implementation of the advanced feature and results
o Conclusion
o References (if any)
Do not zip your submission. We expect 2 files from you.
1.6 Code Demonstration (on Week 10)
Additional to your submission, we also ask you to demonstrate the running of your code. This
will happen in Week 10 during the 2-hour lab session.
On Week 10, you should:
• Attend the lab on time as usual (or work remotely during the session if you can’t attend)
• Bring your lab materials (mote if you have collected one earlier and your submitted
source code). You are not allowed to participate without the materials
• Download the instructions from SurreyLearn
o It will become visible at the beginning of the lab session
o It contains a few additional tasks asking you to modify your code to produce
some additional outputs
• Complete the tasks within the 2-hour session by extending your submitted source code
• Submit the modified code and screen snapshots to SurreyLearn by the end of the
session
• You may seek clarification during the session (via Teams if you work remotely)
• You must apply for EC if you cannot participate
You must complete the code demonstration individually using your submitted code.
Demonstrators can help to clarify the instruction, but they cannot assist you with coding or
debugging.
1.7 Marking Scheme
The assignment accounts for 20%. The following is the breakdown:
• #1 Quality of the report......4%
o 4%: Your report is professionally presented. It is well structured, descriptions
are purposeful and easy to follow, paragraphs and sections are well connected,
concluding statements are adequately justified.
o 3%: Your report quality is generally good. However, there are minor
shortcomings found in your report which do not significantly affect the
understanding of the description (e.g. typos, unclear statements, missing
justification, unjustified conclusions, etc.)
o 2%-1%: Your report is adequately presented, but there are major weaknesses
found in your report where you can improve (e.g. report content not accurately
captured in the abstract, misleading statements, messy flow, etc.)
o 0%: You did not submit your report, or the submitted report contains no relevant
information.
• #2 Code Presentation......3%
o 3%: Your code is professionally presented and easy to follow.
o 2%-1%: Your code is adequately presented and somewhat readable. However,
certain aspects are weak and can be further improved (e.g. use of meaningful
variables/functions, provide comments to complex logic, follow DRY principles,
etc).
o 0%: You did not submit your code, or the submitted code is not related to this
coursework.
• #3 Result presentation and discussion......2%
o 2%: The presented screenshots clearly show accurate implementation of the
basic features. The results are adequately discussed in the report.
o 1%: Some outputs are missing from the presented screenshots, and/or the
format of the outputs are wrong, and/or the results are not adequately
discussed in the report.
o 0%: You did not provide your screenshots in the report or your screenshots
contain no valid information.
• #4 Advanced feature implementation and result presentation......3%
o 3%: Strong evidence of correct implementation based on the source code and
the screenshot, and clear description of the output screenshot.
o 2%-1%: Good attempt of the advanced feature implementation, however some
flaws in the implementation, and/or some errors in the outputs shown in the
screenshot, and/or unclear description of the output screenshot.
o 0%: No valid implementation of the advanced feature.
• #5 Two-Hour Code Demonstration......8%