Page 68 - Fister jr., Iztok, Andrej Brodnik, Matjaž Krnc and Iztok Fister (eds.). StuCoSReC. Proceedings of the 2019 6th Student Computer Science Research Conference. Koper: University of Primorska Press, 2019
P. 68
em Flash storage Schedule and period descriptor
OTE Flash Week Hour Repetitions / period
Module
Priority OS priority
Bootstrap
Operating System Run Report
Meta-scheduler 00 - off 01 - when free 00 - off 01 - pad
10 - n/a 11 - always
10 - force pad 11 - force
SD storage Power Can override power
Needs bettery mutex % of power per run
Can run on battery
Can run on solar
Scenario Settings pointer
Task handler
Battery
Reporter Logger Last run Repeats
Task Task
Queue Queue Timestamp
Figure 1: Overview of main logical software compo- Figure 2: Scenario configuration (read-only vari-
nents and example hardware modules ables in gray and runtime variables in white blocks)
only read from the scenario it belongs to. The settings are budgets. The power budget for a task is defined in the per-
stored in the microcontroller flash and are accessed when a centage of the total power available to the probe.
task requires them. The action of writing settings is done
only via server commands. 2.1.5 Task Notifications
2.1.2 Schedule and period A task is based on the FreeRTOS task [1] and its notification
variable that has, by default 4 bytes. The first 3 bytes are
The basis for the schedule is time intervals in which the sce- used for custom messages send to the task, and the last byte
nario runs and repetitions that happen in those defined in- is used as flags to set repeats (timeouts) that the task should
tervals. The Meta-Scheduler uses the configuration to wake run. Zero repeats mean the task will only run once in that
up the tasks at the specified hours and gives the task a time- time-frame and put themselves into infinite sleep mode after
out that co-responds with the set period. In this way, we can that. One or more repeats places the task into a timeout
run the meta-scheduler in periods not more than one hour. of 60 minutes divided by the repeat rate, at a minimum
The meta-scheduler is idempotent, so running it multiple of 5-minute interval. More granular repeats can be made
consecutive times will not affect the running tasks. within the task itself and are not registered with the Meta-
Scheduler. Any task with an interval will run until the next
2.1.3 Priorities time the Meta-Scheduler is run, and it stops the execution.
Priorities are the way the Meta-Scheduler decides if a task 2.1.6 Logger
should run at all, or if it should only run when there is
enough power in the budget or always in the case of critical The Logger is a special scenario, available to all tasks for
tasks. The report priority is used for reporting and is there logging purposes. It runs in a best-effort manner, using mul-
to keep a budget on power availability and network traffic. tiple queues with messages grouped by severity. The logs are
handled with the notification variable of the header.
2.1.4 Power
The logs can be optionally saved on the SD card and only if
The power setting is a way to tell the Meta-Scheduler how there is enough power and enough time has passed since the
much power a task needs to be able to run so that significant last write. Since the queue could have been filled up since
power-consuming tasks will only run when there is enough the last write, the queue is cycled with the oldest messages
energy available. Specific scenarios can execute depending being reused. In the event of a hardware failure, the Logger
on power status. Configuration assumes the following condi- is disabled.
tions: the battery is full, the solar array produces power, the
battery is charging, or when the battery is almost drained, Each entry has a timestamp, a scenario id, and a fixed size
but we still want the task to run regardless of any power data blob to store the log message or data.
StuCoSReC Proceedings of the 2019 6th Student Computer Science Research Conference 68
Koper, Slovenia, 10 October
OTE Flash Week Hour Repetitions / period
Module
Priority OS priority
Bootstrap
Operating System Run Report
Meta-scheduler 00 - off 01 - when free 00 - off 01 - pad
10 - n/a 11 - always
10 - force pad 11 - force
SD storage Power Can override power
Needs bettery mutex % of power per run
Can run on battery
Can run on solar
Scenario Settings pointer
Task handler
Battery
Reporter Logger Last run Repeats
Task Task
Queue Queue Timestamp
Figure 1: Overview of main logical software compo- Figure 2: Scenario configuration (read-only vari-
nents and example hardware modules ables in gray and runtime variables in white blocks)
only read from the scenario it belongs to. The settings are budgets. The power budget for a task is defined in the per-
stored in the microcontroller flash and are accessed when a centage of the total power available to the probe.
task requires them. The action of writing settings is done
only via server commands. 2.1.5 Task Notifications
2.1.2 Schedule and period A task is based on the FreeRTOS task [1] and its notification
variable that has, by default 4 bytes. The first 3 bytes are
The basis for the schedule is time intervals in which the sce- used for custom messages send to the task, and the last byte
nario runs and repetitions that happen in those defined in- is used as flags to set repeats (timeouts) that the task should
tervals. The Meta-Scheduler uses the configuration to wake run. Zero repeats mean the task will only run once in that
up the tasks at the specified hours and gives the task a time- time-frame and put themselves into infinite sleep mode after
out that co-responds with the set period. In this way, we can that. One or more repeats places the task into a timeout
run the meta-scheduler in periods not more than one hour. of 60 minutes divided by the repeat rate, at a minimum
The meta-scheduler is idempotent, so running it multiple of 5-minute interval. More granular repeats can be made
consecutive times will not affect the running tasks. within the task itself and are not registered with the Meta-
Scheduler. Any task with an interval will run until the next
2.1.3 Priorities time the Meta-Scheduler is run, and it stops the execution.
Priorities are the way the Meta-Scheduler decides if a task 2.1.6 Logger
should run at all, or if it should only run when there is
enough power in the budget or always in the case of critical The Logger is a special scenario, available to all tasks for
tasks. The report priority is used for reporting and is there logging purposes. It runs in a best-effort manner, using mul-
to keep a budget on power availability and network traffic. tiple queues with messages grouped by severity. The logs are
handled with the notification variable of the header.
2.1.4 Power
The logs can be optionally saved on the SD card and only if
The power setting is a way to tell the Meta-Scheduler how there is enough power and enough time has passed since the
much power a task needs to be able to run so that significant last write. Since the queue could have been filled up since
power-consuming tasks will only run when there is enough the last write, the queue is cycled with the oldest messages
energy available. Specific scenarios can execute depending being reused. In the event of a hardware failure, the Logger
on power status. Configuration assumes the following condi- is disabled.
tions: the battery is full, the solar array produces power, the
battery is charging, or when the battery is almost drained, Each entry has a timestamp, a scenario id, and a fixed size
but we still want the task to run regardless of any power data blob to store the log message or data.
StuCoSReC Proceedings of the 2019 6th Student Computer Science Research Conference 68
Koper, Slovenia, 10 October
