data编程代写、代做Java/Python程序语言

日期：2023-11-06 10:37

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%