diff --git a/GPS_pw_modeling.mo b/GPS_pw_modeling.mo
index 7c053129340f9a47e3c78f1345e8a6124cf70090..f89b0141dc73b6a591448f7366edef86fb9b8160 100644
--- a/GPS_pw_modeling.mo
+++ b/GPS_pw_modeling.mo
@@ -1,5 +1,7 @@
package GPS_pw_modeling
- model GPS_pw_simulator
+ model GPS_pw_simulator_old
+ //prima versione - obsoleta
+ //
//parameters
parameter Integer required_satellites = 4;
//number of satellites required for sufficient accuracy
@@ -28,8 +30,9 @@ package GPS_pw_modeling
Modelica.Blocks.Interfaces.IntegerInput visible_satellites annotation(
Placement(visible = true, transformation(origin = {-167, 101}, extent = {{-11, -11}, {11, 11}}, rotation = 0), iconTransformation(origin = {-94, 2}, extent = {{-26, -26}, {26, 26}}, rotation = 0)));
Modelica.Blocks.Interfaces.BooleanInput on_signal annotation(
- Placement(visible = true, transformation(origin = {-133, 93}, extent = {{-11, -11}, {11, 11}}, rotation = 0), iconTransformation(origin = {-40, 100}, extent = {{-20, -20}, {20, 20}}, rotation = -90)));
- Modelica.Blocks.Interfaces.BooleanOutput position_out annotation( Placement(visible = true, transformation(origin = {176, 0}, extent = {{10, -10}, {-10, 10}}, rotation = 0), iconTransformation(origin = {95, -15}, extent = {{25, -25}, {-25, 25}}, rotation = 0)));
+ Placement(visible = true, transformation(origin = {-132, 118}, extent = {{-12, -12}, {12, 12}}, rotation = 0), iconTransformation(origin = {-40, 100}, extent = {{-20, -20}, {20, 20}}, rotation = -90)));
+ Modelica.Blocks.Interfaces.BooleanOutput position_out annotation(
+ Placement(visible = true, transformation(origin = {176, 0}, extent = {{10, -10}, {-10, 10}}, rotation = 0), iconTransformation(origin = {95, -15}, extent = {{25, -25}, {-25, 25}}, rotation = 0)));
Modelica.Blocks.Interfaces.RealOutput power_consumption annotation(
Placement(visible = true, transformation(origin = {-160, 84}, extent = {{-8, -8}, {8, 8}}, rotation = 0), iconTransformation(origin = {95, 41}, extent = {{-25, -25}, {25, 25}}, rotation = 180)));
//States
@@ -39,17 +42,17 @@ package GPS_pw_modeling
Placement(visible = true, transformation(origin = {-150, 58}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
Modelica.StateGraph.Step warm_start(nOut = 3) annotation(
Placement(visible = true, transformation(origin = {34, -12}, extent = {{10, -10}, {-10, 10}}, rotation = -90)));
- Modelica.StateGraph.Step hot_start(nOut = 3) annotation(
+ Modelica.StateGraph.Step hot_start(nIn = 2, nOut = 3) annotation(
Placement(visible = true, transformation(origin = {72, -20}, extent = {{10, -10}, {-10, 10}}, rotation = -90)));
Modelica.StateGraph.Step warm_start_available(nIn = 2, nOut = 2) annotation(
Placement(visible = true, transformation(origin = {80, -90}, extent = {{-10, -10}, {10, 10}}, rotation = 180)));
Modelica.StateGraph.Step hot_start_available(nIn = 2, nOut = 3) annotation(
Placement(visible = true, transformation(origin = {130, -20}, extent = {{-10, -10}, {10, 10}}, rotation = -90)));
- Modelica.StateGraph.Step position_available(nIn = 4, nOut = 2) annotation(
+ Modelica.StateGraph.Step position_available(nIn = 4, nOut = 3) annotation(
Placement(visible = true, transformation(origin = {100, 58}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
Modelica.StateGraph.Step freq_and_phase(nIn = 3, nOut = 2) annotation(
Placement(visible = true, transformation(origin = {-4, 58}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
- Modelica.StateGraph.Step cold_start(nOut = 2) annotation(
+ Modelica.StateGraph.Step cold_start(nIn = 2, nOut = 2) annotation(
Placement(visible = true, transformation(origin = {-82, 58}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
//Transitions
Modelica.StateGraph.Transition lock_freq_and_phase(enableTimer = true, waitTime = freq_and_phase_acquisition_time) annotation(
@@ -83,7 +86,7 @@ package GPS_pw_modeling
Modelica.StateGraph.TransitionWithSignal turn_off_antenna annotation(
Placement(visible = true, transformation(origin = {130, 18}, extent = {{-10, 10}, {10, -10}}, rotation = -90)));
Modelica.Blocks.MathBoolean.Not not1 annotation(
- Placement(visible = true, transformation(origin = {22, 94}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
+ Placement(visible = true, transformation(origin = {22, 118}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
Modelica.StateGraph.TransitionWithSignal turn_off_antenna2 annotation(
Placement(visible = true, transformation(origin = {-126, 14}, extent = {{10, -10}, {-10, 10}}, rotation = 0)));
Modelica.StateGraph.TransitionWithSignal turn_off_antenna3 annotation(
@@ -92,21 +95,39 @@ package GPS_pw_modeling
Placement(visible = true, transformation(origin = {104, 2}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
Modelica.StateGraph.TransitionWithSignal turn_off_antenna5 annotation(
Placement(visible = true, transformation(origin = {66, -60}, extent = {{-10, 10}, {10, -10}}, rotation = -90)));
+ Modelica.StateGraph.Transition satellite_outage annotation(
+ Placement(visible = true, transformation(origin = {158, 100}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
equation
+ connect(satellite_outage.outPort, hot_start.inPort[2]) annotation(
+ Line(points = {{160, 100}, {212, 100}, {212, -40}, {72, -40}, {72, -30}, {72, -30}}));
+ connect(position_available.outPort[3], satellite_outage.inPort) annotation(
+ Line(points = {{110, 58}, {130, 58}, {130, 100}, {154, 100}}, thickness = 0.5));
+ connect(on_signal, turn_on.condition) annotation(
+ Line(points = {{-132, 118}, {-116, 118}, {-116, 70}}, color = {255, 0, 255}));
+ connect(not1.u, on_signal) annotation(
+ Line(points = {{8, 118}, {-132, 118}}, color = {255, 0, 255}));
+ connect(turn_on_hot_start.condition, on_signal) annotation(
+ Line(points = {{100, -34}, {100, 22}, {-106, 22}, {-106, 118}, {-132, 118}}, color = {255, 0, 255}));
+ connect(turn_on_warm_start.condition, on_signal) annotation(
+ Line(points = {{44, -60}, {50.75, -60}, {50.75, -50}, {-106, -50}, {-106, 118}, {-132, 118}}, color = {255, 0, 255}));
+ connect(not1.y, turn_off_antenna.condition) annotation(
+ Line(points = {{34, 116}, {190, 116}, {190, 18}, {142, 18}}, color = {255, 0, 255}));
+ connect(not1.y, turn_off_antenna2.condition) annotation(
+ Line(points = {{34, 116}, {56, 116}, {56, 130}, {-190, 130}, {-190, -6}, {-126, -6}, {-126, 2}}, color = {255, 0, 255}));
+ connect(turn_off_antenna3.condition, not1.y) annotation(
+ Line(points = {{-126, -42}, {-126, -48}, {-190, -48}, {-190, 130}, {56, 130}, {56, 116}, {34, 116}}, color = {255, 0, 255}));
+ connect(not1.y, turn_off_antenna4.condition) annotation(
+ Line(points = {{34, 116}, {200, 116}, {200, -16}, {104, -16}, {104, -10}}, color = {255, 0, 255}));
+ connect(turn_off_antenna5.condition, not1.y) annotation(
+ Line(points = {{78, -60}, {200, -60}, {200, 116}, {34, 116}}, color = {255, 0, 255}));
connect(update_ephemeris_data.inPort, position_available.outPort[2]) annotation(
Line(points = {{150, 58}, {131.25, 58}, {131.25, 56}, {110.5, 56}}));
connect(update_ephemeris_data.outPort, position_available.inPort[2]) annotation(
Line(points = {{155.5, 58}, {185.5, 58}, {185.5, 88}, {75.5, 88}, {75.5, 56}, {89, 56}}));
- connect(turn_off_antenna5.condition, not1.y) annotation(
- Line(points = {{78, -60}, {200, -60}, {200, 98}, {34, 98}, {34, 94}, {34, 94}}, color = {255, 0, 255}));
connect(turn_off_antenna5.outPort, warm_start_available.inPort[2]) annotation(
Line(points = {{66, -62}, {66, -62}, {66, -70}, {102, -70}, {102, -90}, {92, -90}, {92, -90}}));
connect(turn_off_antenna5.inPort, warm_start.outPort[3]) annotation(
Line(points = {{66, -56}, {52, -56}, {52, 4}, {34, 4}, {34, -2}, {34, -2}}));
- connect(turn_on_warm_start.condition, on_signal) annotation(
- Line(points = {{44, -60}, {50.75, -60}, {50.75, -50}, {-106, -50}, {-106, 93}, {-133, 93}}, color = {255, 0, 255}));
- connect(not1.y, turn_off_antenna4.condition) annotation(
- Line(points = {{34, 94}, {200, 94}, {200, -16}, {104, -16}, {104, -10}, {104, -10}}, color = {255, 0, 255}));
connect(turn_off_antenna4.outPort, hot_start_available.inPort[2]) annotation(
Line(points = {{106, 2}, {130, 2}, {130, -8}, {130, -8}}));
connect(turn_off_antenna4.inPort, hot_start.outPort[3]) annotation(
@@ -125,8 +146,6 @@ package GPS_pw_modeling
Line(points = {{72, -9.5}, {72, 8}, {-2, 8}, {-2, 14}}, thickness = 0.5));
connect(hot_start.outPort[1], lock_freq_and_phase_2.inPort) annotation(
Line(points = {{72, -9.5}, {70, -9.5}, {70, 20}}, thickness = 0.5));
- connect(turn_on_hot_start.condition, on_signal) annotation(
- Line(points = {{100, -34}, {100, 22}, {-106, 22}, {-106, 93}, {-133, 93}}, color = {255, 0, 255}));
connect(warm_start_available.inPort[1], lose_hot_start.outPort) annotation(
Line(points = {{91, -90}, {91, -90.125}, {105, -90.125}, {105, -90.25}, {128, -90.25}, {128, -79.5}}, thickness = 0.5));
connect(turn_on_warm_start.inPort, warm_start_available.outPort[2]) annotation(
@@ -139,22 +158,14 @@ package GPS_pw_modeling
Line(points = {{-125.5, -104}, {-172, -104}, {-172, 58}, {-161, 58}}));
connect(warm_start.inPort[1], turn_on_warm_start.outPort) annotation(
Line(points = {{34, -23}, {34, -40.75}, {30, -40.75}, {30, -58.5}}, thickness = 0.5));
- connect(turn_off_antenna3.condition, not1.y) annotation(
- Line(points = {{-126, -42}, {-126, -42}, {-126, -48}, {-190, -48}, {-190, 130}, {56, 130}, {56, 94}, {34, 94}, {34, 94}}, color = {255, 0, 255}));
connect(turn_off_antenna3.outPort, GPS_off.inPort[4]) annotation(
Line(points = {{-128, -30}, {-172, -30}, {-172, 58}, {-160, 58}, {-160, 58}}));
connect(freq_and_phase.outPort[2], turn_off_antenna3.inPort) annotation(
Line(points = {{6, 58}, {14, 58}, {14, -30}, {-122, -30}, {-122, -30}}, thickness = 0.5));
- connect(not1.y, turn_off_antenna2.condition) annotation(
- Line(points = {{34, 94}, {56, 94}, {56, 130}, {-190, 130}, {-190, -6}, {-126, -6}, {-126, 2}, {-126, 2}}, color = {255, 0, 255}));
connect(turn_off_antenna2.inPort, cold_start.outPort[2]) annotation(
Line(points = {{-122, 14}, {-60, 14}, {-60, 58}, {-72, 58}, {-72, 58}, {-72, 58}}));
connect(turn_off_antenna2.outPort, GPS_off.inPort[3]) annotation(
Line(points = {{-128, 14}, {-172, 14}, {-172, 58}, {-160, 58}, {-160, 58}}));
- connect(not1.y, turn_off_antenna.condition) annotation(
- Line(points = {{34, 92}, {190, 92}, {190, 18}, {142, 18}}, color = {255, 0, 255}));
- connect(not1.u, on_signal) annotation(
- Line(points = {{8, 92}, {-66, 92}, {-66, 93}, {-133, 93}}, color = {255, 0, 255}));
connect(lock_freq_and_phase_2.outPort, position_available.inPort[3]) annotation(
Line(points = {{70, 26}, {70, 26}, {70, 58}, {90, 58}, {90, 58}}));
connect(get_ephemeris_data.outPort, position_available.inPort[1]) annotation(
@@ -171,8 +182,6 @@ package GPS_pw_modeling
Line(points = {{-2, 20}, {-2, 38}, {-24, 38}, {-24, 58}, {-15, 58}}));
connect(lock_freq_and_Phase_3.outPort, freq_and_phase.inPort[2]) annotation(
Line(points = {{-32, 20}, {-32, 38}, {-24, 38}, {-24, 58}, {-15, 58}}));
- connect(on_signal, turn_on.condition) annotation(
- Line(points = {{-133, 93}, {-116, 93}, {-116, 70}}, color = {255, 0, 255}));
connect(warm_start.outPort[2], lock_freq_and_Phase_3.inPort) annotation(
Line(points = {{34, -2}, {34, -2}, {34, 4}, {-32, 4}, {-32, 14}, {-32, 14}}, thickness = 0.5));
connect(warm_start.outPort[1], lock_freq_and_phase_1.inPort) annotation(
@@ -186,7 +195,7 @@ package GPS_pw_modeling
//power consumption OUTPUT
power_consumption = if on_signal then power_consumption_over_time else 0;
//is position available OUTPUT
- position_out = min(sv_tracked_freq_phase, sv_ephemeris) > required_satellites;
+ position_out = position_available.active;
algorithm
when {pre(lock_freq_and_phase.fire), pre(lock_freq_and_phase_1.fire), pre(lock_freq_and_phase_2.fire)} then
sv_tracked_freq_phase := pre(visible_satellites);
@@ -212,39 +221,228 @@ package GPS_pw_modeling
Icon(graphics = {Rectangle(fillColor = {0, 201, 223}, fillPattern = FillPattern.Solid, extent = {{-100, 100}, {100, -100}}), Text(origin = {-40, 66}, extent = {{-14, 12}, {14, -12}}, textString = "ON"), Text(origin = {-13, -58}, lineColor = {30, 33, 177}, extent = {{-75, 66}, {109, -94}}, textString = "GPS device"), Text(origin = {-97, 45}, extent = {{59, -43}, {9, -5}}, textString = "Visible SV"), Text(origin = {26, -24}, extent = {{-22, 12}, {60, -32}}, textString = "Position available"), Text(origin = {34, 30}, extent = {{-32, 0}, {54, -12}}, textString = "pw consumption")}, coordinateSystem(initialScale = 0.1)),
experiment(StartTime = 0, StopTime = 1000, Tolerance = 1e-6, Interval = 0.002),
__OpenModelica_simulationFlags(lv = "LOG_STATS", s = "dassl"));
- end GPS_pw_simulator;
+ end GPS_pw_simulator_old;
-model test_GPS
- GPS_pw_modeling.GPS_pw_simulator gps annotation(
- Placement(visible = true, transformation(origin = {32, -60}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
- Modelica.Blocks.Sources.IntegerTable visible_satellites(table = [0, 8; 100, 7; 500, 12]) annotation(
- Placement(visible = true, transformation(origin = {-90, 50}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
-Modelica.Blocks.Sources.BooleanTable slow_and_fast(table = {20, 85, 90, 91, 100, 101, 110, 111, 120, 121, 1850, 1851, 1860, 1861, 1870, 1871, 1880, 1881, 1890, 1891, 1900, 1901, 1910, 1971, 1980, 1981, 1990, 1991, 2000, 2001}) annotation(
- Placement(visible = true, transformation(origin = {50, 80}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
-Modelica.Blocks.Sources.IntegerTable constant_number(table = [0, 8]) annotation(
- Placement(visible = true, transformation(origin = {52, 48}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
-Modelica.Blocks.Sources.BooleanTable general_example annotation(
- Placement(visible = true, transformation(origin = {-90, 88}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
-Modelica.Blocks.Sources.BooleanTable const_on(table = {10}) annotation(
- Placement(visible = true, transformation(origin = {-30, -20}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
- Modelica.Blocks.Sources.IntegerTable satellite_outage(table = [0, 8; 110, 3; 120, 12]) annotation(
- Placement(visible = true, transformation(origin = {-30, -60}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
+ model test_GPS
+ GPS_pw_modeling.GPS_pw_simulator GPS_pw_simulator1 annotation(
+ Placement(visible = true, transformation(origin = {90, 50}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
+ Modelica.Blocks.Sources.BooleanTable const_on(table = {5, 71, 80, 81, 90, 91, 100, 101, 110, 111, 120, 261, 270, 271, 280, 281, 290, 291}) annotation(
+ Placement(visible = true, transformation(origin = {50, 80}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
+ Modelica.Blocks.Sources.IntegerConstant stellites_constant(k = 5) annotation(
+ Placement(visible = true, transformation(origin = {-10, 50}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
+ Modelica.Blocks.Sources.BooleanTable slow_and_fast(table = {10, 70, 90, 91, 110, 111, 130, 131, 150, 151, 1840, 1841, 1850, 1851, 1860, 1861, 1870, 1871, 1880, 1881, 1890, 1891, 1900, 1971, 1980, 1981, 1990, 1991, 2000, 2001}) annotation(
+ Placement(visible = true, transformation(origin = {-10, 80}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
+ Modelica.Blocks.Sources.IntegerTable satellites(table=[0,5;100,3; 200,4]) annotation(
+ Placement(visible = true, transformation(origin = {50, 50}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
+ equation
+ connect(const_on.y, GPS_pw_simulator1.on_signal) annotation(
+ Line(points = {{62, 80}, {86, 80}, {86, 60}, {86, 60}}, color = {255, 0, 255}));
+ connect(satellites.y, GPS_pw_simulator1.visible_satellites) annotation(
+ Line(points = {{62, 50}, {80, 50}, {80, 50}, {80, 50}}, color = {255, 127, 0}));
+ annotation(
+ experiment(StartTime = 0, StopTime = 300, Tolerance = 1e-6, Interval = 0.0006),
+ __OpenModelica_simulationFlags(lv = "LOG_STATS", s = "dassl"));
+ end test_GPS;
+
+
-equation
- connect(const_on.y, gps.on_signal) annotation(
- Line(points = {{-19, -20}, {28, -20}, {28, -50}}, color = {255, 0, 255}));
- connect(satellite_outage.y, gps.visible_satellites) annotation(
- Line(points = {{-19, -60}, {22, -60}}, color = {255, 127, 0}));
- annotation(
- experiment(StartTime = 0, StopTime = 400, Tolerance = 1e-6, Interval = 0.0008),
- __OpenModelica_simulationFlags(lv = "LOG_STATS", s = "dassl"));
-end test_GPS;
-
+
+
+
+
+ model GPS_pw_simulator
+ // not modeled hot start
+ /////////////////
+ // parameters //
+ /////////////////
+ //number of satellites required for sufficient accuracy
+ parameter Integer required_satellites = 4;
+ //power consumed when antenna is on (assumed constant) [mW]
+ parameter Real power_consumption = 387.2;
+ //time to get ephemeris data after freq&phase are locked (wrost case default)
+ parameter Real time_to_get_ephemeris = 59;
+ //frequency and phase acquisition time when exaustive search is required (random)
+ parameter Real freq_and_phase_acquisition_time = 0.01;
+ //how long the eohemeris data will be reliable
+ parameter Real ephemeris_duration = 1800;
+ ///////////////////////
+ //Inputs and outputs //
+ ///////////////////////
+ Modelica.Blocks.Interfaces.IntegerInput visible_satellites annotation(
+ Placement(visible = true, transformation(origin = {-101, 101}, extent = {{-11, -11}, {11, 11}}, rotation = 0), iconTransformation(origin = {-94, 2}, extent = {{-26, -26}, {26, 26}}, rotation = 0)));
+ Modelica.Blocks.Interfaces.BooleanInput on_signal annotation(
+ Placement(visible = true, transformation(origin = {-158, 92}, extent = {{-12, -12}, {12, 12}}, rotation = 0), iconTransformation(origin = {-40, 100}, extent = {{-20, -20}, {20, 20}}, rotation = -90)));
+ Modelica.Blocks.Interfaces.RealOutput power annotation(
+ Placement(visible = true, transformation(origin = {54, 104}, extent = {{8, -8}, {-8, 8}}, rotation = 0), iconTransformation(origin = {95, 43}, extent = {{-25, -25}, {25, 25}}, rotation = 180)));
+ //not really an input signal but just the negation of the on signal, still used as an input
+ Modelica.Blocks.Logical.Not off_signal annotation(
+ Placement(visible = true, transformation(origin = {162, -24}, extent = {{8, -8}, {-8, 8}}, rotation = 0)));
+ /////////////
+ // states //
+ /////////////
+ //number of satellites of which frequency and phase are available
+ Integer sv_freq_phase(start = 0);
+ //number of satellites of which ephemeris data are available;
+ Integer sv_ephemeris(start = 0);
+ //time at which ephemeris data will expire
+ Real expiration_time(start = -1.0);
+ //states of the state machine
+ inner Modelica.StateGraph.StateGraphRoot stateGraphRoot annotation(
+ Placement(visible = false, transformation(origin = {-90, -90}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
+ Modelica.StateGraph.InitialStep no_info(nIn = 3) annotation(
+ Placement(visible = true, transformation(origin = {-110, 48}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
+ Modelica.StateGraph.Step cold_start(nIn = 4, nOut = 2) annotation(
+ Placement(visible = true, transformation(origin = {-40, 48}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
+ Modelica.StateGraph.Step read_ephemeris(nIn = 2, nOut = 3) annotation(
+ Placement(visible = true, transformation(origin = {38, 48}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
+ Modelica.StateGraph.StepWithSignal position_available(nIn = 3, nOut = 4) annotation(
+ Placement(visible = true, transformation(origin = {112, 48}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
+ Modelica.StateGraph.Step warm_start_available(nIn = 2, nOut = 2) annotation(
+ Placement(visible = true, transformation(origin = {70, -90}, extent = {{-10, -10}, {10, 10}}, rotation = 180)));
+ Modelica.StateGraph.Step warm_start(nIn = 3, nOut = 3) annotation(
+ Placement(visible = true, transformation(origin = {50, -38}, extent = {{10, -10}, {-10, 10}}, rotation = -90)));
+ /////////////////
+ // transitions //
+ /////////////////
+ Modelica.StateGraph.TransitionWithSignal turn_on1 annotation(
+ Placement(visible = true, transformation(origin = {-76, 48}, extent = {{-10, 10}, {10, -10}}, rotation = 0)));
+ Modelica.StateGraph.TransitionWithSignal turn_on2 annotation(
+ Placement(visible = true, transformation(origin = {50, -66}, extent = {{10, -10}, {-10, 10}}, rotation = -90)));
+ Modelica.StateGraph.Transition fetch_signal1(enableTimer = true, waitTime = freq_and_phase_acquisition_time) annotation(
+ Placement(visible = true, transformation(origin = {-4, 48}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
+ Modelica.StateGraph.Transition get_ephemeris1(enableTimer = true, waitTime = time_to_get_ephemeris) annotation(
+ Placement(visible = true, transformation(origin = {74, 48}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
+ Modelica.StateGraph.TransitionWithSignal turn_off1 annotation(
+ Placement(visible = true, transformation(origin = {130, -24}, extent = {{-10, 10}, {10, -10}}, rotation = -90)));
+ Modelica.StateGraph.TransitionWithSignal turn_off2 annotation(
+ Placement(visible = true, transformation(origin = {90, -38}, extent = {{10, -10}, {-10, 10}}, rotation = 90)));
+ Modelica.StateGraph.Transition fetch_signal2 annotation(
+ Placement(visible = true, transformation(origin = {74, 18}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
+ Modelica.StateGraph.TransitionWithSignal turn_off3 annotation(
+ Placement(visible = true, transformation(origin = {-52, 84}, extent = {{10, 10}, {-10, -10}}, rotation = 0)));
+ Modelica.StateGraph.TransitionWithSignal turn_off4 annotation(
+ Placement(visible = true, transformation(origin = {-10, 88}, extent = {{10, 10}, {-10, -10}}, rotation = 0)));
+ Modelica.StateGraph.Transition get_ephemeris2(enableTimer = true, waitTime = time_to_get_ephemeris) annotation(
+ Placement(visible = true, transformation(origin = {126, 78}, extent = {{10, -10}, {-10, 10}}, rotation = 0)));
+ Modelica.StateGraph.Transition ephemeris_expire1(condition = time > expiration_time or sv_ephemeris < required_satellites) annotation(
+ Placement(visible = true, transformation(origin = {-18, -90}, extent = {{10, -10}, {-10, 10}}, rotation = 0)));
+ Modelica.StateGraph.Transition ephemeris_expire2(condition = time > expiration_time or sv_ephemeris < required_satellites) annotation(
+ Placement(visible = true, transformation(origin = {0, -10}, extent = {{10, -10}, {-10, 10}}, rotation = 0)));
+ Modelica.StateGraph.Transition ephemeris_expire3(condition = time > expiration_time or sv_ephemeris < required_satellites) annotation(
+ Placement(visible = true, transformation(origin = {72, 86}, extent = {{10, -10}, {-10, 10}}, rotation = 0)));
+ Modelica.StateGraph.Transition lose_visibility1(condition = sv_freq_phase < required_satellites) annotation(
+ Placement(visible = true, transformation(origin = {-4, 18}, extent = {{10, -10}, {-10, 10}}, rotation = 0)));
+ Modelica.StateGraph.Transition lose_visibility2(condition = sv_freq_phase < required_satellites) annotation(
+ Placement(visible = true, transformation(origin = {110, -6}, extent = {{10, -10}, {-10, 10}}, rotation = 90)));
+ Modelica.Blocks.Interfaces.BooleanOutput position annotation(
+ Placement(visible = true, transformation(origin = {162, 30}, extent = {{10, -10}, {-10, 10}}, rotation = 0), iconTransformation(origin = {95, -43}, extent = {{25, -25}, {-25, 25}}, rotation = 0)));
+ equation
+ connect(lose_visibility2.outPort, warm_start.inPort[2]) annotation(
+ Line(points = {{110, -8}, {110, -8}, {110, -58}, {50, -58}, {50, -48}, {50, -48}}));
+ connect(lose_visibility2.inPort, position_available.outPort[4]) annotation(
+ Line(points = {{110, -2}, {110, -2}, {110, 10}, {130, 10}, {130, 48}, {122, 48}, {122, 48}}));
+ connect(turn_off2.outPort, warm_start_available.inPort[2]) annotation(
+ Line(points = {{90, -39.5}, {90, -88}, {81, -88}}));
+ connect(turn_off1.outPort, warm_start_available.inPort[1]) annotation(
+ Line(points = {{130, -25.5}, {130, -88}, {81, -88}}));
+ connect(turn_on2.inPort, warm_start_available.outPort[1]) annotation(
+ Line(points = {{50, -70}, {50, -88}, {59.5, -88}}));
+ connect(ephemeris_expire1.inPort, warm_start_available.outPort[2]) annotation(
+ Line(points = {{-14, -90}, {23, -90}, {23, -88}, {59.5, -88}}));
+ connect(turn_off1.inPort, position_available.outPort[1]) annotation(
+ Line(points = {{130, -18}, {130, 50}, {122.5, 50}}));
+ connect(fetch_signal2.outPort, position_available.inPort[2]) annotation(
+ Line(points = {{75.5, 20}, {93.5, 20}, {93.5, 50}, {101, 50}}));
+ connect(get_ephemeris1.outPort, position_available.inPort[1]) annotation(
+ Line(points = {{75.5, 48}, {88.5, 48}, {88.5, 50}, {101, 50}}));
+ connect(ephemeris_expire3.inPort, position_available.outPort[3]) annotation(
+ Line(points = {{76, 86}, {140, 86}, {140, 50}, {122.5, 50}}));
+ connect(get_ephemeris2.inPort, position_available.outPort[2]) annotation(
+ Line(points = {{130, 78}, {140, 78}, {140, 50}, {122.5, 50}}));
+ connect(get_ephemeris2.outPort, position_available.inPort[3]) annotation(
+ Line(points = {{124.5, 78}, {94.5, 78}, {94.5, 50}, {101, 50}}));
+ connect(get_ephemeris1.inPort, read_ephemeris.outPort[1]) annotation(
+ Line(points = {{70, 50}, {59.25, 50}, {59.25, 48}, {48.5, 48}}));
+ connect(lose_visibility1.inPort, read_ephemeris.outPort[3]) annotation(
+ Line(points = {{0, 18}, {56, 18}, {56, 50}, {48.5, 50}}));
+ connect(fetch_signal1.outPort, read_ephemeris.inPort[1]) annotation(
+ Line(points = {{-2.5, 48}, {12.5, 48}, {12.5, 50}, {27, 50}}));
+ connect(turn_off4.inPort, read_ephemeris.outPort[2]) annotation(
+ Line(points = {{-6, 88}, {54, 88}, {54, 50}, {48.5, 50}}));
+ connect(ephemeris_expire3.outPort, read_ephemeris.inPort[2]) annotation(
+ Line(points = {{70, 86}, {20, 86}, {20, 50}, {27, 50}}));
+ connect(lose_visibility1.outPort, cold_start.inPort[3]) annotation(
+ Line(points = {{-6, 18}, {-60, 18}, {-60, 50}, {-51, 50}}));
+ connect(fetch_signal1.inPort, cold_start.outPort[1]) annotation(
+ Line(points = {{-8, 48}, {-27.25, 48}, {-27.25, 50}, {-29.5, 50}}));
+ connect(turn_on1.outPort, cold_start.inPort[1]) annotation(
+ Line(points = {{-74.5, 48}, {-52.4375, 48}, {-52.4375, 50}, {-51, 50}}));
+ connect(turn_off3.inPort, cold_start.outPort[2]) annotation(
+ Line(points = {{-48, 84}, {-22, 84}, {-22, 50}, {-29.5, 50}}));
+ connect(ephemeris_expire2.outPort, cold_start.inPort[2]) annotation(
+ Line(points = {{-2, -10}, {-60, -10}, {-60, 50}, {-51, 50}}));
+ connect(ephemeris_expire2.inPort, warm_start.outPort[3]) annotation(
+ Line(points = {{4, -10}, {50, -10}, {50, -28}, {50, -28}}));
+ connect(fetch_signal2.inPort, warm_start.outPort[2]) annotation(
+ Line(points = {{70, 20}, {50, 20}, {50, -26}}));
+ connect(ephemeris_expire1.outPort, no_info.inPort[3]) annotation(
+ Line(points = {{-20, -90}, {-128, -90}, {-128, 48}, {-120, 48}, {-120, 48}}));
+ connect(on_signal, off_signal.u) annotation(
+ Line);
+ connect(turn_off1.condition, off_signal.y) annotation(
+ Line(points = {{142, -24}, {153, -24}}, color = {255, 0, 255}));
+ connect(turn_off2.condition, off_signal.y) annotation(
+ Line(points = {{102, -38}, {150, -38}, {150, -24}, {154, -24}, {154, -24}, {154, -24}}, color = {255, 0, 255}));
+ connect(turn_off3.condition, off_signal.y) annotation(
+ Line(points = {{-52, 96}, {-52, 114}, {150, 114}, {150, -24}, {154, -24}}, color = {255, 0, 255}));
+ connect(turn_off4.condition, off_signal.y) annotation(
+ Line(points = {{-10, 100}, {-10, 114}, {150, 114}, {150, -24}, {154, -24}}, color = {255, 0, 255}));
+ connect(turn_off2.inPort, warm_start.outPort[1]) annotation(
+ Line(points = {{90, -32}, {90, -32}, {90, -20}, {50, -20}, {50, -26}, {50, -26}}));
+ connect(turn_on2.outPort, warm_start.inPort[1]) annotation(
+ Line(points = {{50, -64.5}, {50, -47.5}}));
+ connect(on_signal, turn_on2.condition) annotation(
+ Line(points = {{-158, 92}, {-140, 92}, {-140, -66}, {38, -66}}, color = {255, 0, 255}));
+ connect(turn_off4.outPort, no_info.inPort[2]) annotation(
+ Line(points = {{-11.5, 90}, {-127.5, 90}, {-127.5, 50}, {-119.5, 50}, {-119.5, 50}}));
+ connect(turn_off3.outPort, no_info.inPort[1]) annotation(
+ Line(points = {{-53.5, 86}, {-127.5, 86}, {-127.5, 50}, {-119.5, 50}, {-119.5, 50}}));
+ connect(turn_on1.inPort, no_info.outPort[1]) annotation(
+ Line(points = {{-80, 50}, {-100, 50}, {-100, 50}, {-100, 50}}));
+ connect(on_signal, turn_on1.condition) annotation(
+ Line(points = {{-158, 92}, {-74, 92}, {-74, 60}}, color = {255, 0, 255}));
+//power consumption OUTPUT
+ power = if on_signal then power_consumption else 0;
+ position = min(sv_ephemeris, sv_freq_phase) > required_satellites;
+ algorithm
+ when {pre(fetch_signal1.fire), pre(fetch_signal2.fire)} then
+ sv_freq_phase := pre(visible_satellites);
+ end when;
+ when {pre(off_signal.y) == false} then
+ sv_freq_phase := 0;
+ end when;
+ when {pre(visible_satellites) < pre(sv_freq_phase)} then
+ sv_freq_phase := pre(visible_satellites);
+ end when;
+ when {pre(visible_satellites) < pre(sv_ephemeris)} then
+ sv_ephemeris := pre(visible_satellites);
+ end when;
+ when {pre(get_ephemeris1.fire), pre(get_ephemeris2.fire)} then
+ sv_ephemeris := visible_satellites;
+ expiration_time := pre(time + ephemeris_duration);
+ end when;
+ when {time > pre(expiration_time)} then
+ sv_ephemeris := 0;
+ end when;
+ annotation(
+ Icon(graphics = {Rectangle(fillColor = {115, 210, 22}, fillPattern = FillPattern.Solid, extent = {{-96, 96}, {96, -96}}), Text(origin = {-40, 70}, extent = {{-20, 8}, {20, -8}}, textString = "turn_on"), Text(origin = {-51, 7}, extent = {{-17, 9}, {91, -15}}, textString = "visible_satellites"), Text(origin = {50, 41}, extent = {{-72, 15}, {22, -9}}, textString = "power_consumption"), Text(origin = {22, -41}, extent = {{-50, 11}, {50, -11}}, textString = "position_avaialble")}),
+ experiment(StartTime = 0, StopTime = 400, Tolerance = 1e-6, Interval = 0.0008));
+ end GPS_pw_simulator;
annotation(
uses(Modelica(version = "3.2.1")));
-end GPS_pw_modeling;
\ No newline at end of file
+end GPS_pw_modeling;
diff --git a/paper/main.tex b/paper/main.tex
index 01336f3930c062b68108e9bbc7efa8480c220bf1..95fe7607ca01862f83638f70356c464eaf7ba4f4 100644
--- a/paper/main.tex
+++ b/paper/main.tex
@@ -3,17 +3,21 @@
\IEEEoverridecommandlockouts
\overrideIEEEmargins
+\usepackage{xcolor}
+
+\newcommand{\todo}[1]{\textcolor{red}{(\textbf{TODO:} #1)}}
+
\title{PAN: Power-Aware Navigation with Sensor Fusion}
\author{%
% --------------------------------------------------------------------
-Claudio Mandrioli$^\dagger$,%
-Alberto Leva$^\ddagger$,%
-Bo Bernhardsson$^\dagger$,%
+Claudio Mandrioli$^\dagger$, %
+Alberto Leva$^\ddagger$, %
+Bo Bernhardsson$^\dagger$, %
and Martina Maggio$^\dagger$\\
% --------------------------------------------------------------------
-$^\dagger$Department of Automatic Control;%
+$^\dagger$Department of Automatic Control; %
Lund University, Sweden\\
-$^\ddagger$Dipartimento di Elettronica, Informazione e Bioingegneria;%
+$^\ddagger$Dipartimento di Elettronica, Informazione e Bioingegneria; %
Politecnico di Milano, Italy%
% --------------------------------------------------------------------
}
@@ -26,4 +30,48 @@ Politecnico di Milano, Italy%
\section{Introduction}
+\begin{itemize}
+
+\item GPS navigation consumes a lot of battery
+ \todo{Find references that back up this information}.
+
+\item This is part of the reason why GPS is often used in conjunction
+ with other sensors \todo{Find references that back up this
+ information and discuss sensor fusion}. In fact, GPS tracking
+ systems provide very precise information, that could be used when
+ the uncertainty of the measurements of other (less power-hungry)
+ types of sensors becomes too big.
+
+\item We have studied and modeled the GPS protocol to aid the sensor
+ fusion process, and optimize for battery consumption (which is
+ crucial in some circumstances, for example if the tracking system is
+ mounted on drones).
+
+\item This paper makes the following contributions: (1) it provides a
+ model of the GPS stack behavior, identifying how it is possible to
+ optimize it to save battery; (2) it complements the model with other
+ sensors and shows how the GPS can enhance the accuracy of the
+ provided data; (3) it develops an open-loop control strategy to
+ manage the GPS receiver and evaluates its potential battery savings.
+
+\end{itemize}
+
+\section{Related Work}
+\label{sec:related}
+
+\section{GPS receiver model}
+\label{sec:gps}
+
+\section{Sensor fusion}
+\label{sec:fusion}
+
+\section{Control Strategy}
+\label{sec:control}
+
+\section{Evaluation}
+\label{sec:experiments}
+
+\section{Conclusion}
+\label{sec:concl}
+
\end{document}
diff --git a/report/img/control1.png b/report/img/control1.png
new file mode 100644
index 0000000000000000000000000000000000000000..a9d3ecdcd885db943e776a7c672f4592ddd7e5f4
Binary files /dev/null and b/report/img/control1.png differ
diff --git a/report/img/control2.png b/report/img/control2.png
new file mode 100644
index 0000000000000000000000000000000000000000..4da875aaaa934be616eb71351016a684d1288461
Binary files /dev/null and b/report/img/control2.png differ
diff --git a/report/img/control3.png b/report/img/control3.png
new file mode 100644
index 0000000000000000000000000000000000000000..15e586c2d209991e4903c952fe7bb23c25758735
Binary files /dev/null and b/report/img/control3.png differ
diff --git a/report/img/position1.png b/report/img/position1.png
new file mode 100644
index 0000000000000000000000000000000000000000..5e8d9d47fa1802f7cb01358522f508e9b012a40a
Binary files /dev/null and b/report/img/position1.png differ
diff --git a/report/img/position2.png b/report/img/position2.png
new file mode 100644
index 0000000000000000000000000000000000000000..7d3088e0ce73f37be66655b580529bfc56a6ce45
Binary files /dev/null and b/report/img/position2.png differ
diff --git a/report/img/position3.png b/report/img/position3.png
new file mode 100644
index 0000000000000000000000000000000000000000..29a3efc26e0781fc0e851bb754cf9b964f30a63b
Binary files /dev/null and b/report/img/position3.png differ
diff --git a/report/main.tex b/report/main.tex
index d778060ddc4cb8440915dde8fa66ff51aaa0a89a..876e554bcef7cac0850f828048b687836d378fb5 100644
--- a/report/main.tex
+++ b/report/main.tex
@@ -34,10 +34,10 @@
\begin{document}
-\title{The ``GPS'' project}
+\title{Dynamical modeling of power consumpion in GPS sensors}
\author{
- \IEEEauthorblockN{Your names}
- \IEEEauthorblockA{Your affiliations}
+ \IEEEauthorblockN{Claudio Mandrioli}
+ \IEEEauthorblockA{Feedback control in computing systems - phd course, november 2017}
}
\maketitle
@@ -45,7 +45,7 @@
\begin{abstract}
~This is a stub paper on the ``GPS'' subject as discussed in the last lecture of the PhD course in Lund, November 2017. Your task is to carry out the activities sketched out in the introduction, applying the notions and methods treated in the course wherever applicable, and to document your work by turning this stub into a 6--8 pages paper (indicative length). Needless to say, the title is just a placeholder, and you can change everything---including the introduction, that is a stub as well. For any question, just drop me a line.
-\vspace{5mm}\textit{Keywords---} You choose.
+\vspace{5mm}\textit{Keywords---} GPS, cyber-physical systems, energy consumption.
\end{abstract}
\section{Introduction}
diff --git a/report/sections/02-How_it_works.tex b/report/sections/02-How_it_works.tex
index 16a76a5cff2d31ae1ed027da22baa56fb09f5975..84c34957eca22b5f8fe6187a7709b41a3bbed00e 100644
--- a/report/sections/02-How_it_works.tex
+++ b/report/sections/02-How_it_works.tex
@@ -8,21 +8,12 @@ All reported in this section (unless stated differently) is referenced by the bo
The Global Positioning System (GPS) is the only positioning system that provides an absolute measure and is available worldwide. This is achieved using a constellation of space vehicles (SV) whose position is known with an high grade of accuracy and that is designed in such a way that at least five of them are visible at any time in every point over the world.
-Any device able to listen to the signals broadcasted by the satellites can retrieve (i) their position and (ii) its distance from those: performing specific computations over this information it will be able to locate itself. We call such device a \textbf{GPS receiver}. The cited computation is called \emph{trilateration}, and it requires to listen to at least three satellites at the same time since the spatial coordinates to be determied are three.
+Any device able to listen to the signals broadcasted by the satellites can retrieve (i) their position and (ii) its distance from those: performing specific computations over this information it will be able to locate itself. We call such device a \textbf{GPS receiver}. The cited computation is called \emph{trilateration}, and it theoretically requires to listen to at least three satellites at the same time since the spatial coordinates to be determied are three.
-From a technological perspective the measure of the distance from the satellites is based on a time difference, and it assumes that the time reference is the same for the SV and the receiver. Since this is apparently not true for devices that do not contain atomic clocks -- i.e. most of the commonly used GPS receivers -- another constraint must be introduced. This is done in order to be able to treat also the receiver time offset as an unknown variable. For this reason at least four satellites must be visible to be able to position the receiver. In case the receiver can listen to more than four satellites those can still be used to improve accuracy.
+From a technological perspective the measure of the distance from the satellites is based on a time difference, and it assumes that the time reference is the same for the SV and the receiver. Since this is apparently not true for devices that do not contain atomic clocks -- i.e. most of the commonly used GPS receivers -- another constraint must be introduced. This is done in order to be able to treat also the receiver time offset as an unknown variable. For this reason at least four satellites must be visible to be able to position the receiver. In case the receiver can listen to more than four satellites those can also be used to improve accuracy.
It shall be underlined moreover that the receiver only needs to listen to the SVs and it doesn't need to send any message.
-\subsection{Positioning the satellites}
-The position of the SVs can be retrieved from a set of parameters that describe their orbit around the earth. Since the orbits are not fixed in time due to trajectory corrections, collision avoidance or other uncertainties and disturbances such parameters need to be continuously updated. To make those parameters always available the satellites broadcast them toward the earth surface.
-
-Two kind of data are broadcast and can be used for SV positioning: \emph{almanac data} or \emph{ephemeris data}. The former are a subset of the latter (7 parameters out of 15) and are valid for several months while the latter are valid for 30 minutes after they are broadcast. Being apparently less precise the achivable precision with only the almanac data is around one order of magnitude less when used for positioning. The difference in time validity allows on the other side that satellites are able to share such information betwen each other and therefore each of them transmits the almanac data for every satellite. The ephemeris data of each satellite are instead transmitted only by the SV itself. In practice almanac data are mainly used by the receiving devices to know which SVs will be visible at a certain point in time and speed up the tracking phase, the ephemeris data are instead the ones actually used for the positioning.
-
-The ephemeris data are fully repeated every 30 seconds by each SV. They are exact at the beginning of each of those half-minute cycles and are considered to be valid for 30 minutes. With those the receiver is able to achieve a precision of the order of meters in the positioning.
-
-Since there are stations around the world that listen at the satellites and make the ephemeris data available in the internet devices that are also connected to the internet, instead of listening to the satellites can retrieve the ephemeris data from the web. This avoids the bottleneck of the GPS transmission channel which has a capacity of 50bit/s and is at the basis of the 30 seconds that are necessary for retrieving them. Such intenet-connected implementation of the GPS positioning system is called \textbf{Assisted-GPS}.
-
\subsection{GPS signal modulation and multiplexing}
The GPS signal sent by the satellites is modulated using the Binary Phase Shift Key (BPSK) technique that includes the bit information in a $180^0$ phase shift of the carrier wave. This means that the carrier is transmitted ``as is'' or in counter-phase according to whether a 0 or 1 is being transmitted, an example is shown in figure~\ref{fig:bpsk}.
@@ -35,9 +26,9 @@ The GPS signal sent by the satellites is modulated using the Binary Phase Shift
\end{center}
\end{figure}
-The signals from the different satellites are multiplexed on the same carrier frequency using Code Division Multiple Access (CDMA), more precisely Direct Sequence Spread Spectrum (DSSS) technique is used. In this methodology the data (in our case the ephemeris and almanac data) are trasmitted overlapped with another signal at much higher simbol rate. Therefore the data are considered a \emph{baseband} signal while the latter is referred to as a \emph{spreading} waveform, meaning that the former can be considered at almost zero frequency with respect to the other signals (the carrier and the spreading sequence). The spreading sequence is a periodic signal and is completely known by the receivers, it is the ``key'' that the receivers will use for distinguishing the signals from the different sources. In the GPS system sequences of PseudoRandom Noise called \emph{golden codes} are used as spreading signals: those deterministic codes have the property of looking like white noises (so to have null correlation with themself) and are not correlated with each other. As we will see in section~\ref{sec:receiverSegment} both those properties are crucial for the GPS system to actually work.
+The signals from the different satellites are multiplexed on the same carrier frequency using Code Division Multiple Access (CDMA), more precisely Direct Sequence Spread Spectrum (DSSS) technique is used. In this methodology the data (in our case the ephemeris and almanac data) are trasmitted overlapped with another signal at much higher simbol rate. The data are therefore considered a \emph{baseband} signal while the latter is referred to as a \emph{spreading} waveform, meaning that the former can be considered at almost zero frequency with respect to the other signals (the carrier and the spreading sequence). The spreading sequence is a periodic signal and is completely known by the receivers, it is the ``key'' that the receivers will use for distinguishing the signals from the different sources. In the GPS system sequences of PseudoRandom Noise called \emph{golden codes} are used as spreading signals: those deterministic codes have the property of looking like white noises (so to have null correlation with themself) and are not correlated with each other. As we will see in section~\ref{sec:receiverSegment} both those properties are crucial for the GPS system to actually work.
-The GPS signal sent by each satellite has therefore three components: the carrier, the localization data and the PRN sequence. As we can see in figure~\ref{fig:dsss}. The signal is broadcast in parallel on different band frequencies L1 (1575.42 MHz) and L2 (1227.60 MHz).
+The GPS signal sent by each satellite has therefore three components: the carrier, the localization data and the PRN sequence, a grsficsl example of this is shown in figure~\ref{fig:dsss}. The signal is broadcast in parallel on different band frequencies L1 (1575.42 MHz) and L2 (1227.60 MHz).
\begin{figure}[htb]
\begin{center}
@@ -48,9 +39,18 @@ The GPS signal sent by each satellite has therefore three components: the carrie
\end{center}
\end{figure}
+\subsection{Positioning the satellites}
+The position of the SVs can be retrieved from a set of parameters that describe their orbit around the earth. Since the orbits are not fixed in time due to trajectory corrections, collision avoidance or other uncertainties and disturbances, such parameters need to be continuously updated. To make those parameters always available the satellites broadcast them toward the earth surface.
+
+Two kind of data are broadcast and can be used for SV positioning: \emph{almanac data} or \emph{ephemeris data}. The former are a subset of the latter (7 parameters out of 15) and are valid for several months while the latter are valid for 30 minutes after they are broadcast. Being apparently less precise the achivable precision with only the almanac data is around one order of magnitude less when used for positioning. The difference in time validity allows on the other side that satellites are able to share such information betwen each other and therefore each of them transmits the almanac data for every satellite. The ephemeris data of each satellite are instead transmitted only by the SV itself. In practice almanac data are mainly used by the receiving devices to know which SVs will be visible at a certain point in time and speed up the tracking phase, the ephemeris data are instead the ones actually used for the positioning.
+
+The ephemeris data are fully repeated every 30 seconds by each SV. They are exact at the beginning of each of those half-minute cycles and are considered to be valid for 30 minutes. With those the receiver is able to achieve a precision of the order of meters in the positioning.
+
+Since there are stations around the world that listen at the satellites and make the ephemeris data available in the internet devices that are also connected to the internet, instead of listening to the satellites can retrieve the ephemeris data from the web. This avoids the bottleneck of the GPS transmission channel which has a capacity of 50bit/s and is at the basis of the 30 seconds that are necessary for retrieving them. Such intenet-connected implementation of the GPS positioning system is called \textbf{Assisted-GPS}.
+
\subsection{Measuring the distance from the satellites}
\label{measuring_distance}
-The distance between the receiving device and the satellites is determined measuring the time it takes for the microwave signal generated by the satellite to reach the receiver. Since both the SVs and the receivers know exactly the PRN code this can be done measuring the phase shift with which such signal is received by the device. The sender and the receiver generate the same signal with the same time reference: assumming that the clocks of the receiver and of the SV are synchronized the phase delay of the signal received by the GPS device will be equivalent to the distance divided by the speed of light. This way the receiver only needs to measure how much it has to delay the PRN code (generating the so-called \emph{replica code}) in order to measure the distance from the SV, a graphical representaiton of this is shown in figure~\ref{fig:phase_delay}. As a consequence the bit rate of the PRN code defines the maximum resolution achivable with this technology.
+The distance between the receiving device and the satellites is determined measuring the time it takes for the microwave signal generated by the satellite to reach the receiver. Since both the SVs and the receivers know exactly the PRN code this can be done measuring the phase shift (i.e. the delay) with which such signal is received by the device. The sender and the receiver generate the same signal with the same time reference: assumming that the clocks of the receiver and of the SV are synchronized the phase delay of the signal received by the GPS device will be equivalent to the distance divided by the speed of light. This way the receiver only needs to measure how much it has to delay the PRN code (generating the so-called \emph{replica code}) in order to measure the distance from the SV, a graphical representaiton of this is shown in figure~\ref{fig:phase_delay}. As a consequence the bit rate of the PRN code defines the maximum resolution achivable with this technology.
Since the atomic clocks of the different satellites are deisgned to be extremely stable and precise they can be considered synchronized (they are also corrected on a regulard basis), this way the only one extra variable as to be introduced to compensate for the non-synchronization is the receiver's clock.
@@ -67,12 +67,12 @@ Since the atomic clocks of the different satellites are deisgned to be extremely
\label{sec:receiverSegment}
A GPS receiver listens to the satellite signals through an antenna. The device must then decode the signal to identify the visible satellites, locate them and retrieve the distance from those. Since the satellites and the receivers are moving with respect to each other there will also be a distortion in the signal frequencies due to the doppler effect. This implies that for decoding the GPS signal for a given satellite the receiver must perform a two-dimensional search: in frequency and phase. The device will generate the replica code and distorce it in both frequency and phase shift it until it correlates with the GPS signal received from the antenna. This is why the correlation properties of the golden codes are so critical. First since they look like white-noises they will not correlate to themselfes unless they have the same phase shift. Second they do not correlate with each other avoiding the risk of not distinguishing the signal from different satellites.
-Once frequency and phase are tracked two information are directly accessible: (i) the phase as described in section~\ref{measuring_distance} allows to retrieve the ranging data (i.e. the distance) from the satellite, (ii) the frequency instead since its shift is directly related to the relative speed betwen the receiver and the satellite and the satellite's speed is known from the ephemeris data can be used to directly measure the speed.
+Once frequency and phase are tracked two information are directly accessible: the ranging data and the speed of the receiver. The ranging data are computed from the phase as described in section~\ref{measuring_distance} from the phase shift. The speed instead can be computed from the relative speed measured with the doppler frequency and the satellite speed that is known from the ephemeris data.
-It must be recalled that also the location data are sent by the satellite and those, according to whether a 0 or 1 is being trasmitted, can turn the PRN code into its complement (in the sense of logical negation) or leave it as it is. Depending on whether the replica code or its complement correlates with the signal itself the receiver is able to tell if a 0 or 1 is being transmitted. This relies on the fact that the location data are transmitted at much lower frequency (a baseband signal) with respect the spreading waveform and therefore don't interfere.
+It must be recalled that also the location data are sent by the satellite and those, according to whether a 0 or 1 is being trasmitted, can turn the PRN code into its complement (in the sense of logical negation) or leave it as it is. Depending on whether the replica code or its complement correlates with the signal itself the receiver is able to tell if a 0 or 1 is being transmitted. This exploits the fact that the location data are transmitted at much lower frequency (a baseband signal) with respect the spreading waveform and therefore don't interfere.
\subsection{The receiver technologies}
-Until some years ago due to performance limitations of processors the processing of the GPS signal was performed with embedded circuits, hence not programmable: a GPS receiver was just a set of circuits that would listen to the satellites and provide the position as output. Nowadays it is possible to digitalize the GPS signal (after downconverting it to lower frequencies) and decode it with programs written in high level languages, allowing for more degrees of freedom when implementing a GPS receiver. This is called software-based GPS receiver, as opposed to the previous hardware-based ones. According to this the components of a software-based GPS receiver are: the antenna, a down-converter\footnote{The down converter lowers the frequency spectrum of the signal making it managable by the A/D converter.}, an A/D converter and a sufficiently performing processor programmable in high-level language.
+Until some years ago due to performance limitations of processors the processing of the GPS signal was performed with embedded circuits, hence not programmable: a GPS receiver was just a set of circuits that would listen to the satellites and provide the position as output. Nowadays it is possible to digitalize the GPS signal (after downconverting it to lower frequencies) and decode it with programs written in high level languages, allowing for more degrees of freedom when implementing a GPS receiver. This technology is called software-based GPS receiver, as opposed to the previous hardware-based ones. According to this the components of a software-based GPS receiver are: the antenna, a down-converter\footnote{The down converter lowers the frequency spectrum of the signal making it managable by the A/D converter.}, an A/D converter and a sufficiently performing processor programmable in high-level language.
%\subsection{Other aspects taken into account in GPS devices}
%\textcolor{red}{NOT SURE IF TO INCLUDE THIS}
diff --git a/report/sections/03-Modeling.tex b/report/sections/03-Modeling.tex
index 2f0a43bb856c42842b19b7fca7a2858f73f64677..57a7b9c30b8580cc8f8c98540ba58a2cabe00c27 100644
--- a/report/sections/03-Modeling.tex
+++ b/report/sections/03-Modeling.tex
@@ -13,52 +13,50 @@ The following sections discuss the choices for the inputs and outputs for the mo
\subsection{Input definition}
\label{sec:input-def}
-The sensor interacts with the user (in obth the cases that it is a human or an application running on the same device) receiving ON/OFF control signals. This signal must therefore be considered when modeling a GPS sensor.
+The sensor interacts with the user (in both the cases that it is a human or an application running on the same device) receiving ON/OFF control signals. This signal must therefore be considered when modeling a GPS sensor.
Once turned on the sensor listens to the signals broadcasted by the different satellites. If we neglect distinguishing the different satellites this can be captured by an integer representing the number of visible satellites.
%Another modeling approach could be to capture instead whether each of the satellites is visible or not.
-Modeling indepentendtly the different satellites would increase the complexity of the model but provide quite marginal improvement in the descriptive power. This because the dynamics with which the device listens to the different SVs are strongly synchronized. Whenever the sensor is fetching the frequency, phase or ephemeris data it can be done in parallel for all of the visible satellites. Not distinguishing between the different satellites doesn't allow to simulate precisely how long it will take to get those information since the dynamics of fetching of each of the satellites cannot be captured\footnote{Also other corner cases will not be captured by the model because of this simplifying assumption: such cases are mainly related to the fact that the loss of connection with some satellite is not coordinated instead.\textcolor{red}{AN EXAMPLE OF THIS SHOULD BE MADE AFTER THE MODEL IS PRESENTED: the problem arises when the same satellte disappears and come back fast enough that the device should still have ephemeris data available. Another case is when a extra satellite is seen but not tracked, if after that another satellite is no more visible then the ephemeris data are of the previous satellite but this is not recognized by the model since the number of visible satellites is the same as before.}}. On the other side this can be replaced with rigorous worst-case analysis or probabilistic modeling with bounded errors with respect to a precise model. Also it should be considered that we are interested in the behavior of the overall device, not in the tracking of the single satellite.
+Modeling indepentendtly the different satellites would increase the complexity of the model but provide quite marginal improvement in the descriptive power. This because the dynamics with which the device listens to the different SVs are strongly synchronized. Whenever the sensor is fetching the frequency, phase or ephemeris data it can do it in parallel for all of the visible satellites. Not distinguishing between the different satellites doesn't allow to simulate precisely how long it will take to get this information since the dynamics of fetching of each of the satellite's signal cannot be captured. On the other side this can be replaced with rigorous worst-case analysis or probabilistic modeling with bounded errors with respect to a precise model. Also the loss of connection with the different satellites, which is apparently not synchronized, cannot be represented becxause of not distinguishing the different satellites. Since the interest here is modelling the behavior of the overall device, it is sufficient to detect when not enough satellites are tracked and it can be neglected which of the satellites is actually tracked.
+
+%\textcolor{red}{AN EXAMPLE OF THIS SHOULD BE MADE AFTER THE MODEL IS PRESENTED: the problem arises when the same satellte disappears and come back fast enough that the device should still have ephemeris data available. Another case is when a extra satellite is seen but not tracked, if after that another satellite is no more visible then the ephemeris data are of the previous satellite but this is not recognized by the model since the number of visible satellites is the same as before.}
All of this is apparently arguable and it should be re-considered for the specific use case.
-The input choice for the model here presented are therefore: (i) the control signal that turns ON and OFF the antenna and (ii) the number of visible satellites. Modeling the tracking of each of the satellites individually would instead require to include whether each of the satellites is visible or not and the time reference for the broadcast of the ephemeris data of each of the satellites.
+The inputs choice for the model here presented is therefore: (i) the control signal that turns ON and OFF the antenna and (ii) the number of visible satellites\footnote{Modeling the tracking of each of the satellites individually would instead require including whether each of the satellites is visible or not and also the time reference for the broadcast of the ephemeris data for each of the satellites.}.
\subsection{Output definition}
-What we want to capture with this model are the position measure and the power consumption, here we discuss and define them individually.
+What we want to capture with this model are the position availability and the power consumption, here we discuss and define them individually.
\subsubsection{Modeling the position availability and accuracy}
\label{sec:modelingThePosition}
-As stated before what we want to capture are the availability of the position information and the power consumption. It would be very useful to have a model of the accuracy of the positioning as well, but this is strongly related to the specific use cases. Accuracy of positioning depends on the number of visible satellites and the quality of the signal that is received from those satellites, but defining rigorously the relation between those and the actual accuracy is not straight forward. For instance having two satellites that are very close to each other might not make much difference from having only one of those, or capturing how the clouds (or other structures around the device) might deteriorate the satellite signal is apparently very complex. Those considerations make defining a general model with still a managable complexity rarely (if not ever) feasible.
+As stated before what we want to capture are the availability of the position information and the power consumption. It would be very useful to have a model of the accuracy of the positioning as well, but this is a very complex problem and is strongly related to the specific use cases. Accuracy of positioning depends on the number of visible satellites, their positioning in the sky and the quality of signal transmission. Both modeling those phenomena and defining rigorously they can affect the accuracy is not straight forward. For instance having two satellites that are very close to each other might not make much difference from having only one of those, or capturing how the clouds (or other structures around the device) might deteriorate the satellite signal is apparently very complex. Those considerations make defining a general model with still a managable complexity rarely (if not ever) feasible.
-If we neglect the quality of the signals received and how the satellites are distributed in the visible sky we can define the requirements over accuracy as a minimum number of satellites to be used for positioning --- which as said in section~\ref{sec:how_it_works} cannot be less than 4. The output can then be a boolean defining whether the position is available or not. This is apparently incomplete but valid in general cases with good sky visibility and not degenerate distributions of the SVs (which is avoided in most cases by the constellation design). If this approach is shown to be insufficient further extensions of this model could be investigated: for instance distinguishing the different satellites could allow for probabilistic modeling of the quality of the signal --- still leaving the problem of modeling how does this affect the quality of positioning though.
+If we neglect the quality of the signals received and how the satellites are distributed in the visible sky we can define the accuracy requirements as a minimum number of satellites to be used for positioning --- which as stated in section~\ref{sec:how_it_works} cannot be less than 4. The output can then be defined as a boolean that is true when enough satellites are tracked and therefore the position is available or false otherwise. This is apparently incomplete but valid in general cases with good sky visibility and not degenerate distributions of the SVs (which is avoided in most cases by the constellation design)\footnote{If this approach is shown to be insufficient further extensions of this model could be investigated: for instance distinguishing the different satellites could allow for probabilistic modeling of the quality of the signal --- still leaving the problem of modeling how does this affect the quality of positioning though.}.
\subsubsection{Modeling the power consumption}
-A GPS device consumes power in two ways: (i) powering the antenna in order to listen to the signals from the satellites, (ii) performing the computation for the actual positioning. Experiments~\cite{bib:microsoft-leap} show that the overall power consumption of a GPS sensor is mainly related to the powering of the antenna since the GPS signal sent by the SV is not very strong good amplification of it must be performed, while the consumption due to the computation can with respect to the antenna be neglected.
+A GPS device consumes power in two ways: (i) powering the antenna, (ii) performing the computation for the positioning. Experiments~\cite{bib:microsoft-leap} show that the overall power consumption of a GPS sensor is mainly related to the powering of the antenna. The GPS signal sent by the SV is infact not very strong and good amplification of it must be performed. The power consumption related to the computations can therefore with respect to the antenna be neglected.
-The antenna doesn't present any relevant dynamics and consumes a constant amount of power when it is turned on. According to this the power consumption of the GPS sensor can be modeled as a prescribed constant value when the antenna is turned on or a null value when the antenna is off\footnote{Some power brusts are actually present at the start and stop of the sensor, those are not relevant with respect the overall consumption and can be neglected in a high-level analysis.}.
+The antenna doesn't present any relevant dynamics~\cite{bib:microsoft-leap} and consumes a constant amount of power when it is turned on. According to this the power consumption of the GPS sensor can be modeled as a prescribed constant value when the antenna is turned on or a null value when the antenna is off\footnote{Some power brusts are actually present at the start and stop of the sensor, those are not relevant with respect the overall consumption and can be neglected in a high-level analysis.}.
\subsection{Modeling the Information Dynamics}
\label{sec:info-dynamics}
-%\begin{itemize}
-% \item Discuss the time to first fix and the expiration of ephemeris data and frequency and phase locking
-% \item Discuss whether to model the single satellites or just the aggregated version
-% \item Present the model
-%\end{itemize}
+% per il paper riscrivi definendo gli stati rilevanti (parti da quali informazioni sono necessarie --, acceso/spento, p&f tracciati e dati epfemeri -- e poi scarta le combinazioni non sensate) e poi le transizioni, sii piu' sistematico
-It is now defined when the sensor is consuming power, when it is not and how much it consumes. Now, for what concerns the \emph{cyber} domain we want to describe when the position is available in relation to when the sensor is consuming power.
+It is now defined when the sensor is consuming power, when it is not and how much it consumes. Now, for what concerns the \emph{cyber} domain we want to describe when the position is available in relation to the defined inputs.
-To locate the receiver two information for each satellite are required: (i) the position of the satellite and (ii) the ranging data. Those are respectively included in the ephemeris data and the phase shift of the signal of each satellite. Since to decode the signal and read the ephemeris data the device must first fetch the phase and frequency shift the retrieval of the two is connected, in the sense that the ephemeris data cannot be read without having first fetched frequency and phase. What is not correlated is instead how the different satellites stop being available and therefore the different information stop being useful.
+To locate the receiver two information for each satellite are required: (i) the position of the visible satellites and (ii) the ranging data. Those are respectively encoded in the ephemeris data and the phase shift of the signal of each satellite. Since to decode the signal and read the ephemeris data the device must have fetched the phase and frequency shift the retrieval of the two is connected. This means for example that the ephemeris data cannot be read without having first fetched frequency and phase.
-The phase and frequency are instead lost as soon as the antenna is turned off and the device will have to perform a new search when the antenna is turned on again. In~\cite{bib:microsoft-leap} an algorithm that exploits previous knowledge of frequency and phase shift for improving the speed of fetching the signal has been proposed: this can be done under the assumption that the device has not moved too far away and relative speed has not changed too much from last positioning\footnote{In the discussed work the authors have only simulated what could be the improvement in performance with this method, so there has not been real testing of it.}.
+The phase and frequency are lost as soon as the antenna is turned off or a satellite is no more visible: in those cases the device has to perform a new search when the antenna is turned on again or when the satellite is visible again respectively. In~\cite{bib:microsoft-leap} an algorithm that exploits previous knowledge of frequency and phase shift for improving the speed of fetching the signal has been proposed: this can be done under the assumption that the device has not moved too far away and relative speed has not changed too much from last positioning\footnote{In the discussed work the authors have only simulated what could be the improvement in performance using this method, so there has not been real testing of it.}.
-The ephemeris data are characterized by a well defined expiration time, 30 minutes after being collected they will be no more accurate enough to allow correct positioning and new data must be collected.
+The ephemeris data are characterized by a well defined expiration time, 30 minutes after being collected they won't be accurate enough to allow correct positioning and new data must be collected.
-When ephemeris data are not available -- for instance when it is started -- and the device must fetch the signal and wait to read them the procedure is called \textbf{cold start}. When instead Ephemeris data are available and the device must only fetch the signal in order to get the ranging data it is called \textbf{warm start}. Here, by analogy, we introduce the notation of \textbf{hot start}, to define when the innformation about previous ranging and frequency are exploited for improving the speed of signal fetching.
+When ephemeris data are not available -- for instance at the start up -- and the device must fetch the signal and wait to read them the procedure is called \textbf{cold start}. When instead Ephemeris data are available and the device must only fetch the signal in order to get the ranging data it is called \textbf{warm start}. Here, by analogy, we introduce the notation of \textbf{hot start}, to define when the innformation about previous ranging and frequency are exploited for improving the speed of signal fetching.
-The relation betwen those procedures can be described as a discrete system with states representing what the system is doing and transitions representing either when those information are acquired by the device or when they lose (or have lost) validity, plus of course the input events of turning on and off the antenna.
+The relation betwen those procedures can be described as a discrete system with states representing what the system is doing and which information are available and transitions representing either when those information are acquired by the device or when they lose (or have lost) validity, plus of course the input events of turning on and off the antenna.
-\textcolor{red}{consider putting those in tables with descriptions}
+%\textcolor{red}{consider putting those in tables with descriptions}
The cited transitions are:
\begin{itemize}
@@ -67,10 +65,13 @@ The cited transitions are:
\item fetch frequency and phase,
\item fetch frequency and phase quick (in case of hot start),
\item get ephemeris data,
- \item ephemeris data expired (i.e. any of the scenarios in which the data are not available, both the case that they expired and that they have not been fetched yet) %\footnote{Note that even though the expiration of ephemeris data is expressed as the fact that the data are not valid any more, hence as a condition that lasts in time, not only as an event. It is in fact defiend as \texttt{sv\_ephemeris}<\texttt{required\_satellites}.},
+ \item ephemeris data expired,
+ \item lose visibility,
\item lose hot start.
\end{itemize}
+All the transitions are defined with respect the minimum number of required satellites. This means for example that \emph{lose visibility} will be triggered when the signal is not tracked for the prescribed minimum number of satellites, and not in general when one of the satellites is no more visible.
+
The states instead are:
\begin{itemize}
\item No Info,
@@ -83,9 +84,9 @@ The states instead are:
\item Warm Start Available.
\end{itemize}
-As discussed in section~\ref{sec:modelingThePosition} we also want to include in the model the number of tracked satellites, we must therefore include in the model two integers: \texttt{sv\_tracked\_freq\_phase} and \texttt{sv\_tracked\_ephemeris}. The former describes the number of satellites for which frequency and phase are known and the latter the number of satellites for which ephemeris data are available. The number of tracked satellites (both for frequency and phase and for the ephemeris data) is set equal to the number of visible satellites respectively when the transitions \emph{fetch frequency and phase} and \emph{get ephemeris} are executed.
+The model includes also two integers: \texttt{sv\_tracked\_freq\_phase} and \texttt{sv\_tracked\_ephemeris}. The former describes the number of satellites for which frequency and phase are known and the latter the number of satellites for which ephemeris data are available. The number of tracked satellites (both for frequency and phase and for the ephemeris data) is set equal to the number of visible satellites respectively when the transitions \emph{fetch frequency and phase (quick)} and \emph{get ephemeris data} are executed.
-Due to the fact that we dont distinguis betwen the different satellites the numbers of tracked satellites visible satellites must be bounded by the number of visible sateliltes. This can be expressed with the equations:
+Both those numbers must be bounded by the number of visible sateliltes. While this is apparently always true for the state variable \texttt{sv\_tracked\_freq\_phase}, it is not for \texttt{sv\_tracked\_ephemeris}. A satellite might in fact not be visible for some minutes and the ephemeris data are still valid after the connection interruption. This limit cannot be overcome without distinguishing the different satellites, which, as stated previously, would increase the complexity of the model with marginal improvement in the descriptive power. Those bounds are expressed with the equations:
\begin{equation}
\begin{array}{l}
@@ -101,17 +102,17 @@ Due to the fact that we dont distinguis betwen the different satellites the numb
\end{array}
\end{equation}
-Along with the ephemeris data comes the necessity of representing the expiration time of those: we introduce therefore a real variable called \texttt{expiration\_time}. Since the acquisition is performed in parallel for all the satellites the expiration time will be the same for all the satellites and it is updated when the transition \emph{get ephemeris} is executed. The non-availability of the ephemeris data (expressed by the transition \emph{ephemeris data expired}) can happen in two ways: either the data are not available for enough of the visible satellites, either the expiration time has passed. This can be expressed with the followiong formula (where time represents the actual time):
+Along with the ephemeris data comes the necessity of representing the expiration time of those: we introduce therefore another state variable called \texttt{expiration\_time}. Since the acquisition is performed in parallel for all the satellites the expiration time will be the same for all the satellites currently tracked and it is updated (i.e. increased by 30 minutes) when the transition \emph{get ephemeris} is executed.
-\begin{equation}
-\begin{array}{c}
- (sv\_tracked\_ephemeris < required\_satellites) \\
- \lor \\
- (expiration\_time < time) .
-\end{array}
-\end{equation}
+%\begin{equation}
+%\begin{array}{c}
+% (sv\_tracked\_ephemeris < required\_satellites) \\
+% \lor \\
+% (expiration\_time < time) .
+%\end{array}
+%\end{equation}
-We now need to define how the states and the transitions are connected, a possible representation of this is given in figure~\ref{fig:cyberDynamics}.
+%A possible representation of the states and the transitions are connected is given in figure~\ref{fig:cyberDynamics}.
%\footnote{In this representation it is assumed that after a \texttt{turn\_ON} signal no \texttt{turn\_OFF} signal will be received before the system is able to provide the position. This looks like a non desirable situation. The model could still easily be extended to include this case defining the following transitions (all triggered by the event \texttt{turn\_OFF}):
%\begin{itemize}
@@ -141,12 +142,21 @@ font=\footnotesize]
\node[thick] (wsa) at ( 5, -8) [p_off, label={Warm Start Available}] {8};
\node[thick] (zero) at (-1.5, 1) [circle, draw=black!60, fill=black!60, inner sep=0.75mm] {};
-\draw [arr, bend right] (zero) to (ni); % arrows from beginning node
-\draw [arr] (ni) to node [above] {turn ON} (cs); % arrows from 1
-\draw [arr] (cs) to node [above] {fetch freq and phase} (re); % arrows from 2
+% arrows from beginning node
+\draw [arr, bend right] (zero) to (ni);
+
+% arrows from 1
+\draw [arr] (ni) to node [above] {turn ON} (cs);
+
+% arrows from 2
+\draw [arr] (cs) to node [above] {fetch freq and phase} (re);
\draw [arr, in=60, out=120] (cs) to node [above] {turn OFF} (ni);
-\draw [arr] (re) to node [above] {get ephemeris} (pa); % arrows from 3
+\draw [arr, in=200, out=260] (cs) edge[loop] node [xshift=-10mm] {lose visibility} (cs);
+
+% arrows from 3
+\draw [arr] (re) to node [above] {get ephemeris} (pa);
\draw [arr, in=60, out=120] (re) to node [above] {turn OFF} (ni);
+\draw [arr, in=60, out=120] (re) to node [left] {lose visibility} (cs);
% arrows from 4 - position available
\draw [arr, in=60, out=120] (pa) to node [above]
@@ -154,15 +164,13 @@ font=\footnotesize]
\draw [arr, in=0, out=-45] (pa) to node
[right, at start, yshift=-5mm, xshift=4mm] {turn OFF} (hsa);
\draw [arr] (pa) edge[loop right] node {get ephemeris data} (pa);
+\draw [arr, in=90, out=-90] (pa) to node [right, at start, yshift=-7mm, xshift=-19mm] {lose visibility} (hs);
% arrows from 5 - hot start
-\draw [arr, in=-90, out=45] (hs) to node [right, align=left,
- yshift=-8mm, xshift=-1mm] {fetch freq and phase quick\\
- $\land \neg$ ephemeris data expired} (pa);
-\draw [arr, in=-90, out=135] (hs) to node [right, align=left,
- yshift=11mm, xshift=-8mm] {fetch freq and phase quick\\
- $\land$ ephemeris data expired} (re);
+\draw [arr, in=-75, out=45] (hs) to node [right, align=left, yshift=-0mm, xshift=-0mm] {fetch freq and phase quick} (pa);
+\draw [arr, in=-45, out=135] (hs) to node [right, near end, yshift=0mm, xshift=0mm] {fetch freq and phase quick} (cs);
\draw [arr, in=135, out=225] (hs) to node [right, near start] {turn OFF} (hsa);
+\draw [arr] (hs) to node [below] {lose visibility} (ws);
% arrows from 6 - hot start available
\draw [arr] (hsa) to node [below] {lose hot start} (wsa);
@@ -172,12 +180,10 @@ font=\footnotesize]
% arrows from 7 - warm start
\draw [arr, in=225, out=45] (ws) to node [right, align=left, at start,
- xshift=5mm, yshift=2mm] {fetch freq and phase\\
- $\land \neg$ ephemeris data expired} (pa);
-\draw [arr, in=225, out=90] (ws) to node [left, near end, align=right,
- xshift=-4mm, yshift=-1mm] {fetch freq and phase\\
- $\land$ ephemeris data expired} (re);
+ xshift=5mm, yshift=2mm] {fetch freq and phase} (pa);
+\draw [arr, in=285, out=110] (ws) to node [left, near start, align=right] {ephemeris data expired} (cs);
\draw [arr, in=135, out=225] (ws) to node [right, near start] {turn OFF} (wsa);
+\draw [arr, in=200, out=160] (ws) edge[loop left] node [xshift=0mm] {lose visibility} (ws);
% arrows from 8 - warm start available
\draw [arr, in=-45, out=45] (wsa) to node [right, near end] {turn ON} (ws);
@@ -189,11 +195,14 @@ font=\footnotesize]
}
\end{figure*}
-This state machine models how the signal acquisition and the ephemeris data acquisition are related to each other and how they can happen in different sequences. For instance we can see that at the first start up only a cold start is available and therefore the sensor is forced first to fetch the signal and then to read the ephemeris data before actually providing the position. i.e. path 1-2-3-4. Instead after the first position fix the system is able to go back in the state \emph{Position Available} without aquiring again the position data of the satellites. This is represented by path 6-5-4 in case of hot start and 8-7-4 for the warm start.
+The way the states and the transitions are connected is shown in figure~\ref{fig:cyberDynamics}. This state machine models how the signal acquisition and the ephemeris data acquisition are related to each other and how they can happen in different sequences. For instance we can see that at the first start up only a cold start is available and therefore the sensor is forced first to fetch the signal and then to read the ephemeris data before actually providing the position. i.e. path 1-2-3-4. Instead after the first position fix the system is able to go back in the state \emph{Position Available} without aquiring again the position data of the satellites. This is represented by path 6-5-4 in case of hot start and 8-7-4 for the warm start.
+
+When ephemeris data stop being available (condition \emph{ephemeris data expired}) the sensor can behave in two ways according to whether the antenna is turned on or off. If it is off then the sensor doesn't have either of the required information for positioning itself any more and therefore it goes back to the state \emph{No Info}, transitions 6-1 and 8-1. If instead the antenna is turned on and frequency and phase are fetched the sensor will just go back from state \emph{Position Available} (in the described scenario in fact both the information are available and therefore also the positioning) to the state in which it is reading the ephemeris data, \emph{Read Ephemeris} with the transition 4-3.
+
-When ephemeris data stop being available (condition \emph{ephemeris data expired}) the sensor can behave in two ways according to whether the antenna is turned on or off. If it is off then the sensor doesn't have either of the required information for positioning itself any more and therefore it goes back to the state \emph{No Info}, transitions 6-1 and 8-1. If instead the antenna is turned on and frequency and phase are fetched the sensor will just go back from state \emph{Position Available} (in the described sccenario in fact both the information are available and therefore also the positioning) to the state in which it is reading the ephemeris data, \emph{Read Ephemeris} with the transition 4-3. Different consideration must be done is the antenna is on but has not yet fetched the signal, this is the case in states 5 and 7. In fact in those states moving directly to state 2 would overestimate the time required for fetching the signal since the search for frequency and phase shift would be ``reset'', and instead moving to state 3 would underestimate it skipping directly to the moment when the devivce is able to read the ephemeris data. Therefore what is defined in the model is that the sensor remains in state 5 and 7 until it has fetched the signal and then move to state 4 or 3 depending on whether ephemeris data are respectively available or not.
+%Different consideration must be done if the antenna is on but has not yet fetched the signal, this is the case in states 5 and 7. In fact in those states moving directly to state 2 would overestimate the time required for fetching the signal since the search for frequency and phase shift would be ``reset'', and instead moving to state 3 would underestimate it skipping directly to the moment when the devivce is able to read the ephemeris data. Therefore what is defined in the model is that the sensor remains in state 5 and 7 until it has fetched the signal and then move to state 4 or 3 depending on whether ephemeris data are respectively available or not.
-\textcolor{red}{fai venire fuori che conoscenza otteniamo dal modello (puo' venire dagli esempi)}
+%\textcolor{red}{fai venire fuori che conoscenza otteniamo dal modello (puo' venire dagli esempi)}
diff --git a/report/sections/04-Examples.tex b/report/sections/04-Examples.tex
index a49c01defc3914b849dd64fbe1790d7a549ef929..fbdec2486d085765d9898608059de6f5f877eff2 100644
--- a/report/sections/04-Examples.tex
+++ b/report/sections/04-Examples.tex
@@ -2,7 +2,7 @@
%couple of examples of ways you could use this model
-\textcolor{red}{fai vedere come strategie del controllo possono sfruttare le dinamiche descritte dal modello}
+%\textcolor{red}{fai vedere come strategie del controllo possono sfruttare le dinamiche descritte dal modello}
In this section is discussed an object-oriented implementation of the described model with the modeling language Modelica\footnote{https://www.modelica.org/}.
@@ -10,26 +10,30 @@ In this section is discussed an object-oriented implementation of the described
What is now to be discussed is how to define the firing of the different transitions defined in the model.
\subsubsection{turn ON/OFF}
-Those transitions as defined in section~\ref{sec:input-def} are the controlled inputs of the defined system. Since apparently to have coherency the two must be one the negation of the other they can be defined as a boolean being \emph{true} whe the input is turn ON and \emph{false} when the input is turn OFF.
+Those transitions as defined in section~\ref{sec:input-def} are the controlled inputs of the defined system. Since apparently to have coherency the two must be one the negation of the other they can be defined as a boolean being \emph{true} whe the input is turn ON and \emph{false} when the input is turn OFF. This signal can also be used for defining the output power consumption, since it is equivalent to distinguishing the states in which the antenna is on and off.
\subsubsection{fetch frequency and phase}
-This transition represents when the devices matches the phase shift and frequency distortion of the signal. This procedure takes some time after the antenna has been turned on, usually of the order of milliseconds~\ref{bib:gps-book} from 1mS to 10mS depending on signal strength. Under some assumptions (discussed in section~\ref{sec:info-dynamics}) it has been hypotized that this process can be sped up using the information from previous samplings~\cite{bib:microsoft-leap}. Anyhow this has not been implementes so there is no actual estimation of how much of improvement could be achieved.
+This transition represents when the devices matches the phase shift and frequency distortion of the signal. This procedure takes some time after the antenna has been turned on, usually of the order of milliseconds~\cite{bib:gps-book} from 1mS to 10mS depending on signal strength.
\subsubsection{get ephemeris data}
-The retrieval of the ephemeris data requires the device to listen to one full cycle of the GPS message of each of the visible satellites. One of those cycles lasts 30 seconds this means that in the best case -- i.e. if the device starts to listen exactly at the beginning of the cycle -- this is the amount of time required to fire the transition, in the worst case it will be 59 seconds. It must be also noted that it is the maximum over the all the satellites that matters. Different choices can be done according to the specific use-cases, whether for example the average or worst case must be considered.
+The retrieval of the ephemeris data requires the device to listen to one full cycle of the GPS message of each of the visible satellites. Each of those cycles lasts 30 seconds and this means that in the best case -- i.e. if the device starts to listen exactly at the beginning of the cycle -- this is the amount of time required to acquire the data and fire the transition, in the worst case it will instead be 59 seconds. It must be also noted that it is the maximum over the all the satellites that matters. Different choices can be done according to the specific use-cases, whether for example the average or worst case must be considered.
\subsubsection{ephemeris data expire}
-This event represents the fact that the stored ephemeris data are no more available and the device is not listening to the satellites. Since those data have a prescribed time validity of 30 minutes it is always fireable from 30 minutes after the last update of those.
+This event represents the fact that the stored ephemeris data are no more available and the device is not listening to the satellites. Since those data have a prescribed time validity of 30 minutes it is always fireable from 30 minutes after the last update of those. Formally:
-\subsubsection{lose hot start}
-This event is diffucult to be defined for the same reasons discussed for the event \texttt{fetch frequency and phase} in the case of hot start. For such reason here we only consider a deelay of some milliseconds. When modeling an actual device of the ones available nowadays since the idea of the hot start is not yet available this time should be set to zero.
+\begin{equation}
+ time>expiration\_time .
+\end{equation}
+
+\subsubsection{fetch frequency and phase quick - lose hot start}
+Under some assumptions -- discussed in section~\ref{sec:info-dynamics} -- it has been hypotized that the process of fetching the signal can be sped up using the information from previous samplings~\cite{bib:microsoft-leap}. This possibility is captured by the states \emph{hot start} and \emph{hot start available}. Anyhow this idea has not yet been implemented there is no actual estimation of how much of improvement could be achieved, for his reason what is implemented in modelica is a simplified version of the model that excludes the hot start procedure. The model is very similar to the presented one: the cited states are removed and the two transitions entering them, \texttt{lose\_visibility} and \texttt{turn\_off}, should instead go respectively to \emph{warm start} and \emph{warm start available}.
\subsection{Model execution examples}
In this section will be presented through the simulation of different scenarios which kind of considerations we can make on how GPS sensors work according to the retrieved model. Such considerations are related to (i) the presence of two different dynamcs in the retrieval of the position, one that is slow, the other that is fast, (ii) the different delays the system can present , (iii) the different ways we can duty-cycle the sensor and (iv) how variations on the number of visible satellites can affect the availability of the position.
%first two examples use the boolead table called slow_and_fast with a constant and sufficient number of visible satellites
\subsubsection{Start up of the sensor}
-In the first simulation we want to show the existance of two dynamics in the sensor: a slow one related to the ascquisition and validity of the ephemeris data, and a fast one related to the acquisition of the ranging data. This simulation points also out what is the difference between warm and cold start. To do so we turn on the antenna first for a long time in order to be sure to acuire the ephemeris data of the visible satellies and then start to duty cycle the sensor to acquire the position at different points in time. A example of a turn on signal doing so is given in figure~\ref{fig:control1}.In figure~\ref{fig:position1} instead we can see the availability of the position measure given the input above described. We can see how at the first turn on of the sensor it takes a minute before the position becomes actually available, while afterward the position is available after only milliseconds(recall that the antenna is turned on and consumes powerexactly completely cohordinated to the turn\_on signal).
+In the first simulation we want to show the existance of two dynamics in the sensor: a slow one related to the ascquisition and validity of the ephemeris data, and a fast one related to the acquisition of the ranging data. This simulation points also out what is the difference between warm and cold start. To do so we turn on the antenna first for a long time in order to be sure to acuire the ephemeris data of the visible satellies and then start to duty cycle the sensor to acquire the position at different points in time. A example of a turn on signal doing so is given in figure~\ref{fig:control1}.In figure~\ref{fig:position1} instead we can see the availability of the position measure given the input above described. We can see how at the first turn on of the sensor it takes a minute before the position becomes actually available, while afterward the position is available after only milliseconds(recall that the antenna is turned on and consumes powerexactly completely cohordinated to the turn\_ON signal).
\begin{figure}[h]
\begin{center}
@@ -51,7 +55,7 @@ In the first simulation we want to show the existance of two dynamics in the sen
\subsubsection{Ephemeris data expiration}
-In this second simulation we show an outage of the position measure availability due to the expiration of the ephemeris data. In this scenario the device is duty the cycling sensor until at some point the ephemeris data expire and a prolonged turn\_ON signal is required in order to update the ephemeris data and make available again the position. In figure~\ref{fig:control2} we can see the described turn\_ON signal while in~\ref{fig:position2} we can see the availability of the position measure. In this example the ephemeris data expire around time=1880 , we can see how the sampling suddently becomes uneffective and the position becomes available again only after around a minute in which it is continuously turned on and reads the ephemeris data.
+In this second simulation we show an outage of the position measure availability due to the expiration of the ephemeris data. In this scenario the device is duty cycling the sensor until at some point the ephemeris data expire and a prolonged turn\_ON signal is required in order to update the ephemeris data and make available again the position. In figure~\ref{fig:control2} we can see the described turn\_ON signal while in~\ref{fig:position2} we can see the availability of the position measure. In this example the ephemeris data expire around time=1880 , we can see how the sampling suddently becomes uneffective and the position becomes available again only after around a minute in which it is continuously turned on and reads the ephemeris data.
\begin{figure}[h]
\begin{center}
@@ -72,9 +76,27 @@ In this second simulation we show an outage of the position measure availability
\end{figure}
\subsubsection{Visible satellites}
-In this third scenario it is shown a possible way the number of visible satellites can influence the availability of the position.
+In this third scenario it is shown a possible way the number of visible satellites can impact the availability of the position. In figure~\ref{fig:control3} are shown the number of visible satellites and the control signal that turns on the GPS antenna. We simulate a satellites outage at $time=100$ where the number of visible satellites becomes 3 which is not sufficient for providing any positioning.
+
+The device before the outage tracks the 5 visible satellites and starts sampling the position every 10 seconds for one second. After the satellite outage it instead stays turned on trying to fetch more sateliites. This happens only at the time instant 200 where the number of visible satellites goes up to 4. After having updated again the ephemeris data the device is able to start again sampling the position, as shown in figure~\ref{fig:position3}.
+
+\begin{figure}[h]
+ \begin{center}
+ \includegraphics[width=0.70\columnwidth]{./img/control3.png}
+ \caption{Turn\_ON signal and visible satellites for the antenna in simulation 3.
+ \label{fig:control3}
+ }
+ \end{center}
+\end{figure}
-%thisr example run with
+\begin{figure}[h]
+ \begin{center}
+ \includegraphics[width=0.70\columnwidth]{./img/position3.png}
+ \caption{Availability of the position measure in simulation 3.
+ \label{fig:position3}
+ }
+ \end{center}
+\end{figure}
diff --git a/report/sections/05-Related-Work.tex b/report/sections/05-Related-Work.tex
index 2dc6de8784ec2a74b3ec7417f347a7b38219b338..497a906bf8afa92c9043720665569cf63455fa40 100644
--- a/report/sections/05-Related-Work.tex
+++ b/report/sections/05-Related-Work.tex
@@ -1,6 +1,6 @@
-While many works discuss how to improve power consumption in devices that use the GPS positioning system, only few of those explicitly discuss the problem of modeling how such sensors consume power and even less discuss this modeling problem analyzing how the system actually works. Arguably this is related to the fact that almost all of those solutions are designed for smartphones which can access the internet and therefore run assisted-GPS~\cite{bib:desing-principles-for-energy-efficiency, bib:energy-accuracy-tradeoff, bib:traffic-deelay, bib:modeldriven-pw-consumption-smartphones}. This decouples the retrieval of the ephemeris and ranging data, also allowing a much faster acquisition of the former. This means that the deivce must retrieve only the ranging data using the GPS antenna making the sensor dynamics simpler. Anyway this approach presents some drawbacks like: (i) fetching the GPS data from the internet has as well an impact on the energy consumption, (ii) the use of internet connection might have an economic cost, (iii) this process depends on the underlying OS of the device as it uses funcitonalities external to the sensor and (iv) the device location privacy is compromised reaching the Assisted-GPS servers.
+While many works discuss how to improve power consumption in devices that use the GPS positioning system, only few of those explicitly discuss the problem of modeling how such sensors consume power and even less discuss this problem analyzing how the system actually works. Arguably this is related to the fact that almost all of those solutions are designed for smartphones which can access the internet and therefore run assisted-GPS~\cite{bib:desing-principles-for-energy-efficiency, bib:energy-accuracy-tradeoff, bib:traffic-deelay, bib:modeldriven-pw-consumption-smartphones}. This decouples the retrieval of the ephemeris and ranging data, also allowing a much faster acquisition of the former. This means that the deivce must retrieve only the ranging data using the GPS antenna making the sensor dynamics simpler. Anyway this approach presents some drawbacks like: (i) fetching the GPS data from the internet has as well an impact on the energy consumption, (ii) the use of internet connection might have an economic cost, (iii) this process depends on the underlying OS of the device as it uses funcitonalities external to the sensor and (iv) the device location privacy is compromised reaching the Assisted-GPS servers.
Some works propose frameworks~\cite{bib:framework-for-energy-efficiency} and design principles~\cite{bib:desing-principles-for-energy-efficiency} for energy efficient implementation of smartphone applications. Those mainly focus on how different sensors can be joined in order to acieve more energy efficient positioning--- mainly just minimizing the usage of GPS which is the most enery consuming one\footnote{Other sensors involved are: inertial sensors, giros, wifi trilateration and other internet based methods.}.
-This work~\cite{bib:entracked-datadriven-modeling} explicitly addresses the problem of modeling how the different sensors consume power on mobile devices but presents mainly an high-level data driven approach instead of looking in detail at how the sensors work. The model includes constant power consumption and a deelay in the position availability that depends on for how long the sensor has been turned off. Those characteristics are correct but with a model that looks at how actually the system works it is possible to get better estimation of those.
+One work~\cite{bib:entracked-datadriven-modeling} explicitly addresses the problem of modeling how the different sensors consume power on mobile devices but presents mainly an high-level and data-driven approach instead of looking at how the sensors actually work. The model here introduced includes constant power consumption and a deelay in the position availability that depends on for how long the sensor has been turned off. Those characteristics are correct but with a model that looks at how actually the system works it is possible to get better and rigorous estimation of those.
diff --git a/report/sections/06-Conclusions.tex b/report/sections/06-Conclusions.tex
index 131ff8e8fb3f530bd61808c1215181677f428833..8236f8b40eac795cf17c0fd141e4ee5acc8cd5c6 100644
--- a/report/sections/06-Conclusions.tex
+++ b/report/sections/06-Conclusions.tex
@@ -6,6 +6,6 @@
%in the end: two discrete dynamics, one slow (ephemeris) and one fast (ranging) but what makes the difference is how you use sensor
-In this work a dynamical modeling of how GPS sensors consume power has been presented with respect to how they are able to provide positioning of the device. Such devices are basically characterized by two coupled discrete dynamics: one slow of the ephemeris data and one faster of the ranging data\footnote{Where slow and fast are referred to both the acquisition and validity of the information.}.
+In this work has been presented a dynamical modeling of how GPS sensors consume power with respect to how they are able to provide positioning of the device. Such devices are basically characterized by two coupled discrete dynamics: one slow of the ephemeris data and one faster of the ranging data\footnote{Where slow and fast are referred to both the acquisition and validity of the information.}.
-Another aspect of the modeling problem is how each satellite is tracked and eventually lost as some point: while the former can be done in parallel the latter is decoupled. This decoupling is not captured by the presented model and it results in a underestimation of the sensor performances when a satellite disappears for a short time. The model could be extended to overcome this limitaiton but it would require distinguishing the different satellites which would introduce more complexity in the model: discussion of this is left to specific use-cases for which such level of detail could be necessary.
\ No newline at end of file
+Another aspect of the modeling problem is how each satellite is tracked and eventually lost as some point: while the former can be done in parallel the latter is decoupled. This decoupling is not captured by the presented model and it results in a underestimation of the sensor performances when a satellite disappears for a short time. It also limits the detail at which the time for the acquisition of the ephemeris datacan be modeled. The model could be extended to overcome this limitaiton but it would require distinguishing the different satellites and therefore introduce more complexity: discussion of this is left to specific use-cases for which such level of detail could be required.