This document describes the modules of the simulation. The modules prefixed by
s1 ~ s7 are the main modules. The module run.m executes them in
order, and display the result of the simulation (Fix-Con, Fix-Opt, RT-IFTTT).
Other modules are helper functions which are used across modules.
Main modules generate data to be used in the simulation, and run the simulation of fixed polling interval and RT-IFTTT's flexible polling interval.
We made the modules from s1 to s7 as functions in order to avoid conflicts
among variables. The shared variables are explicit in config.m,
and generated data (.mat files) will be stored in data directory.
The run.m script controls whole module and execute the simulation.
The sX (X = 1 ~ 7) modules may need the .mat file(s), generated by
previous module(s). Therefore, each module may not run independently. The input
and output files of each module are explained below.
run.m runs all modules in order, and simulates RT-IFTTT and others.
If a .mat file exists, run.m does not execute the correspond
module. (e.g. if data/sample_low_pass_XXX.mat exists,
s2_low_pass_filter.m won't be executed with
wsize=XXX.) If you want to clear all the .mat files and run a new
simulation, set clear_matrix = 1 in config.m.
config.m defines global constants among the modules. Well, it
would be expressive that all the global constants be arguments of each module.
:thinking_face: However, all the modules use many constants sharing with other
modules. So we designed config.m as a common header file, and
define the configurable variables and the global constants. The constants which
must not be changed is all capitalized (e.g. LEFT_SENSOR).
The configurable variables are explained in here.
s1_sensor_data.m gets sensor data tables as .csv
formats, and convert them into data/sample.mat and data/rawdata.mat files.
The format of input is explained in here.
data/sample.mat stands for the training data, and data/rawdata.mat stands
for the evaluation data of the paper.
In order to indicate the time when a value is measured, the Date column should
be located at the first column of each sensor data file. Also, the Date format
should follow DD-MMM-YYYY hh:mm:ss. You can change the index of Date column
with date_col variable, and the Date format by giving options to
datetime.
Other modules assume that the time ticks by every second, but (y)our sensor
data might loss data during some seconds. So
s1_sensor_data.m fills the missed gap with the mean. For
example, if the data is lost at T=30 s, the module calculates the average of
the data of T=29 s and T=31 s, and fills it with the average.
s1_sensor_data.m needs two configurable variables in
config.m: sample_csv and rawdata_csv. sample_csv is a path
of training data, and rawdata_csv is a path of evaluation data. Two should be
types of string, and valid paths.
- Input file:
[path/to/your/sample_csv].csv,[path/to/your/rawdata_csv].csv - Output file:
data/sample.mat,data/rawdata.mat
s2_low_pass_filter.m is a low-pass filter for sensor
data. This simulation assumes that sensors have a low-pass filter and the data
is 'purified' from noises by calculating average of data. So
s2_low_pass_filter.m calculates average of data in a
time window. data/sample.mat and data/rawdata.mat pass this module, and it
generates low-pass-filtered data data/sample_low_pass_XXX.mat and
data/rawdata_low_pass_XXX.mat each. (XXX stands for the window size
wsize.)
s2_low_pass_filter.m needs a configurable variable in
config.m: wsize. wsize is a window size of average; the
module calculates the average of data in a time window, the size of which is
wsize seconds.
- Input file:
data/sample.mat,data/rawdata.mat - Output file:
data/sample_low_pass_XXX.mat,data/rawdata_low_pass_XXX.mat
s3_mnsvg_model.m builds a MNSVG prediction model with the
training data data/sample_low_pass_XXX.mat. The maximum normalized sensor
value gradient model (MNSVG model) calculates a probability of a maximum
normalized sensor value gradient after a given time gradient using the training
data.
Because the MNSVG prediction model does not handle the case when a sensor value
becomes zero, s3_mnsvg_model.m has no choice but skip it.
We are working on how to improve our prediction model.
RT-IFTTT uses the MNSVG model as a prediction model. To find the probability
when ∆s is smaller than given value easily,
cumulate_model.m accumulates probability. See
cumulate_model.m for details.
s3_mnsvg_model.m needs a configurable variable in
config.m: delta_t; a set of ∆t. Due to a huge size of the
model, the module takes some ∆t for prediction, not all the possible ∆t.
WARNING: It takes a lot of time and space. We are working on how to minimize the MNSVG model.
- Input file:
data/sample_low_pass_XXX.mat - Output file:
data/sample_mnsvg_XXX.mat
s4_applet_generator.m generates random applets which
consist of two sub-conditions with one logical operator. Because the simulation
focuses on the detection of events (the time when conditions of an applet
evaluates to true), applets do not have actions. We will work on the middle-ware
implementation of RT-IFTTT, including expansion of conditions and communication
with actuators.
s4_applet_generator.m needs configurable variables in
config.m: num_applets, deadline, rand_max and rand_min.
num_applets stands for the number of applets to be generated and tested.
deadline is a set of deadlines which is chosen randomly by the applet
generator. rand_max and rand_min is the maximum and the minimum value of
each sensor. The size of rand_max and rand_min should be equal to
num_sensors.
- Output file:
data/applet_YYY.mat(YYY stands for the number of applets.)
s5_event_detector.m checks the time when an event of
an applet occurs in given evaluation data. To calculate the miss ratio and the
average response time of each sensor polling algorithms, the simulation should
check when the event occurs. (You can see the time when an Event occurs in
Physical World in Fig. 6. (a) in the paper.)
Since sensor data values change rapidly in a short time, the result of evaluation of an applet (=is_occurred) can flip in a very short time. We might think an event occurs when the result becomes true, but it would overestimate the number of events to count every transition of the result from 0(=false) to 1(=true). To detect events precisely, the module counts events with "endurance".
This module adopts the concept of occurrence and endurance. occurrence
saves the state whether an event occurs or not. When occurrence is 0
and is_occurred() is 1, occurrence becomes 1 and marks it as an event.
However, when occurrence is 1 and is_occurred() now becomes 0, occurrence
will not change to 0 until the deadline ends; instead, endurance counts the
time how long the is_occurred() remains 0. If is_occurred() becomes 1 again
within the deadline, the module will not count it as an event but resets
endurance to zero. If is_occurred() lasts 0 after the deadline ends,
occurrence becomes 0.
s5_event_detector.m needs configurable variables in
config.m: num_sensors, num_applets, wsize,
fix_opt_interval, fix_con_interval.
- Input file:
data/rawdata_low_pass_XXX.mat,data/applet_YYY.mat - Output file:
data/event_XXX_YYY.mat
s6_eval_fixed.m simulates two baseline algorithms:
Optimistic Fixed Interval (Fix-Opt) and Conservative Fixed Interval
(Fix-Con). Two algorithms are basically identical but have difference with the
length of interval. Therefore, s6_eval_fixed.m gets
interval as an argument. The result will be displayed in the command window.
- Input argument:
fix_interval- interval to test - Input file:
data/rawdata_low_pass_XXX.mat,data/applet_YYY.mat,data/event_XXX_YYY.mat
s7_eval_rt_ifttt.m simulates the RT-IFTTT algorithm.
The architecture of the module is described in Fig. 5 of the paper. To simplify
the simulation, Applet Manager which analyzes dependencies of applets, and
Actuator Manager which manages actuators are excluded. Hence, Sensor Polling
Scheduler handles all applets rather than 'active' applets only.
Sensor Manager and Sensor Polling Scheduler are the main role of RT-IFTTT. Sensor Manager polls data from sensors. As written in the paper, "to correctly find the occurrence of an event, the framework should evaluate all the conditions while all the sensing data are fresh, so the framework polls all the sensors in an applet condition together." Therefore, Sensor Manager calculates relevant applets of the sensor which is going to be polled now, and polls all the sensors in the applets' condition.
Sensor Polling Scheduler calculates the polling time of each sensor.
eval_time indicates the evaluation time of each applet, and polling_time
indicates the polling time of each sensor. We implemented CEI function and SPI
function as independent functions.
s7_eval_rt_ifttt.m needs global constants in
config.m: num_sensors, num_applets, wsize,
modeling_interval - maximum polling interval to maintain the prediction model,
e - constant miss ratio for all applets.
- Input file:
data/rawdata_low_pass_XXX.mat,data/applet_YYY.mat,data/event_XXX_YYY.mat,data/sample_cum_mnsvg_XXX.mat
Submodules are helper functions to utilize the main modules.
cumulate_model.m accumulates the probability of MNSVG
model. The CEI function of RT-IFTTT finds the maximum ∆t*, which makes the
probability of ∆s < |x-s|/|s| to be larger than 1-e. To find the
probability from MNSVG model easily, cumulate_model.m calculates the
cumulated probability of ∆s < |x-s|/|s| with given |x-s|/|s|.
dispstat.m prints a time stamp and progress. This function is
from
here.
draw_sensor_data_graph.m draws a sensor data
graph like Fig. 2.
-
Input arguments:
filename- the path of.csvfile to draw,varargin- the name(s) of column(s) to print (maximum: 2) -
Output file:
graph.eps
eval_applet.m evaluates the applet with given evaluation
sensor data.
-
Input arguments:
lfunc- logical operator,cfunc- comparator,applet,rawdata- evaluation data -
Return value:
result-resultis true when the conditions are met; otherwise,resultis false.