Page 67 - 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. 67
tem for remote configuration and over the air updates
in restricted environments
Marko Zabreznik Jernej Kranjec
University of Maribor University of Maribor
Faculty of Electrical Engineering Faculty of Electrical Engineering
and Computer Science and Computer Science
Koroška cesta 46, Maribor Koroška cesta 46, Maribor
marko.zabreznik@student.um.si jernej.kranjec@um.si
ABSTRACT over task execution based on external parameters (e.g., avail-
able power or sensor activity), remote configuration, and
This paper illustrates a system for configuring, updating, software updates. Presented solution would provide for more
command execution, and data retrieval via limited com- straightforward creation of such systems as it would allow
munication links of restricted embedded real-time operating for modular hardware components to be assembled into var-
system. A custom domain-specific language design and ref- ious configurations while only require to produce missing
erence implementation are proposed, which would simplify software from module templates, the behavior of which is
the creation of custom program tasks while keeping data controlled by a known set of parameters. To accomplish
transfers low and facilitating differential updates to any soft- this, we propose a domain-specific language extension for
ware component. The proposed implementation extends the a widely supported real-time operating system FreeRTOS
FreeRTOS real-time operating system running on an ARM- to define scenarios that have associated tasks, conditions,
based microcontroller and connects to a remote command and priorities. The same scenario definition is also used to
server via a limited network connection. External factors partition the software into blocks, allowing for over-the-air
such as power shortage, component failure, and connection updates and the addition of new scenarios remotely. Fur-
loss are anticipated and handled by preset priority-based thermore, the scenario definition is also used to prioritize
scenarios. the limited connection and system resources, and to allow
for direct control.
Keywords
2. PROPOSED DESIGN
real time operating system, remote control, domain specific
language for remote task execution, data structures, remote The proposed design incorporates many dynamic compo-
sensing nents and thus vulnerable to corrupt, misconfigured, or buggy
software. For that reason, the software is divided into a safe,
1. INTRODUCTION minimal system (Bootstrap), and the schedule based con-
figurable (Operating System) with the Meta-Scheduler (see
In recent years, the cost and accessibility of world-wide com- Figure 1).
munication channels, low cost of sensor equipment, and ac-
cessible computer modules have given researchers new sources Both the Bootstrap and the Operating System can under-
of data acquisition. Systems used for such applications need stand the basic programming instructions that work in all
to operate autonomously, are remote or completely inacces- cases. Once an error in execution or corruption of the soft-
sible while also potentially under limited power, intermit- ware is detected and can not be recovered from, the micro-
tent network connection, harsh or unpredictable weather, controller reboots into the safe Bootstrap mode sends out a
and other environmental hazards. Depending on those con- distress signal and waits for commands.
ditions, the objective or priorities might change during the
lifetime of the mission. 2.1 Scenario
The goal of this paper is to introduce a solution for embed- A Scenario (see Figure 1) is the basic unit of the design that
ded systems that require executing multiple different tasks is independent of any other generic task, carries its configu-
(e.g., collecting data from various sensors, data processing, ration, and takes up any predefined blocks on the flash. The
information storage and transmission), autonomous control scenario can define a schedule and period of execution, the
priority it needs, and the power it requires. We use those
parameters to decide when and if the task is to run. The
parameters are defined using a domain-specific language at
compile-time but can change in the runtime with configura-
tion stored in the microcontroller flash for each scenario.
2.1.1 Settings
The settings parameter defines the size of the binary blob
the scenario can use for configuration data and is generally
StuCoSReC Proceedings of the 2019 6th Student Computer Science Research Conference DOI: https://doi.org/10.26493/978-961-7055-82-5.67-70 67
Koper, Slovenia, 10 October
in restricted environments
Marko Zabreznik Jernej Kranjec
University of Maribor University of Maribor
Faculty of Electrical Engineering Faculty of Electrical Engineering
and Computer Science and Computer Science
Koroška cesta 46, Maribor Koroška cesta 46, Maribor
marko.zabreznik@student.um.si jernej.kranjec@um.si
ABSTRACT over task execution based on external parameters (e.g., avail-
able power or sensor activity), remote configuration, and
This paper illustrates a system for configuring, updating, software updates. Presented solution would provide for more
command execution, and data retrieval via limited com- straightforward creation of such systems as it would allow
munication links of restricted embedded real-time operating for modular hardware components to be assembled into var-
system. A custom domain-specific language design and ref- ious configurations while only require to produce missing
erence implementation are proposed, which would simplify software from module templates, the behavior of which is
the creation of custom program tasks while keeping data controlled by a known set of parameters. To accomplish
transfers low and facilitating differential updates to any soft- this, we propose a domain-specific language extension for
ware component. The proposed implementation extends the a widely supported real-time operating system FreeRTOS
FreeRTOS real-time operating system running on an ARM- to define scenarios that have associated tasks, conditions,
based microcontroller and connects to a remote command and priorities. The same scenario definition is also used to
server via a limited network connection. External factors partition the software into blocks, allowing for over-the-air
such as power shortage, component failure, and connection updates and the addition of new scenarios remotely. Fur-
loss are anticipated and handled by preset priority-based thermore, the scenario definition is also used to prioritize
scenarios. the limited connection and system resources, and to allow
for direct control.
Keywords
2. PROPOSED DESIGN
real time operating system, remote control, domain specific
language for remote task execution, data structures, remote The proposed design incorporates many dynamic compo-
sensing nents and thus vulnerable to corrupt, misconfigured, or buggy
software. For that reason, the software is divided into a safe,
1. INTRODUCTION minimal system (Bootstrap), and the schedule based con-
figurable (Operating System) with the Meta-Scheduler (see
In recent years, the cost and accessibility of world-wide com- Figure 1).
munication channels, low cost of sensor equipment, and ac-
cessible computer modules have given researchers new sources Both the Bootstrap and the Operating System can under-
of data acquisition. Systems used for such applications need stand the basic programming instructions that work in all
to operate autonomously, are remote or completely inacces- cases. Once an error in execution or corruption of the soft-
sible while also potentially under limited power, intermit- ware is detected and can not be recovered from, the micro-
tent network connection, harsh or unpredictable weather, controller reboots into the safe Bootstrap mode sends out a
and other environmental hazards. Depending on those con- distress signal and waits for commands.
ditions, the objective or priorities might change during the
lifetime of the mission. 2.1 Scenario
The goal of this paper is to introduce a solution for embed- A Scenario (see Figure 1) is the basic unit of the design that
ded systems that require executing multiple different tasks is independent of any other generic task, carries its configu-
(e.g., collecting data from various sensors, data processing, ration, and takes up any predefined blocks on the flash. The
information storage and transmission), autonomous control scenario can define a schedule and period of execution, the
priority it needs, and the power it requires. We use those
parameters to decide when and if the task is to run. The
parameters are defined using a domain-specific language at
compile-time but can change in the runtime with configura-
tion stored in the microcontroller flash for each scenario.
2.1.1 Settings
The settings parameter defines the size of the binary blob
the scenario can use for configuration data and is generally
StuCoSReC Proceedings of the 2019 6th Student Computer Science Research Conference DOI: https://doi.org/10.26493/978-961-7055-82-5.67-70 67
Koper, Slovenia, 10 October
