You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
31 lines
3.6 KiB
31 lines
3.6 KiB
\section{Introduction}
|
|
In todays marketplace, an explosive growth can be observed in the area of so-called smart devices, often referred to as Internet of Things (IoT).
|
|
On the one hand, conventional devices (i.e., door locks, light bulbs, washing machines) are extended with smart functions for remote control and monitoring.
|
|
At the same time, completely new categories of products evolve, such as the self-driving car.
|
|
To implement the additional smart functions, small embedded computer systems are getting integrated into the devices, allowing them to connect to the local WiFi network.
|
|
|
|
In embedded systems, the software, also known as firmware, is an essential part of the system.
|
|
On one side, it interacts with the hardware in a system specific way by implementing the specifications required by the components used in the system.
|
|
On the other side, it provides use-case dependent functionality in interaction with general purpose hardware components.
|
|
Embedded systems are often thought as systems that never change their requirements or functionality.
|
|
However, practical use shows that the environment in which these systems run does, in fact, change.
|
|
These changes include, but are not limited to, modifications to the expected behavior or additions to it, reconfiguration of parameters related to the communication with other systems or the users, as well as correcting errors, particularly security related issues, that have been reported after deployment and roll-out.
|
|
In almost all cases, the requirements can be accomplished by changing the firmware and do not need any modification to the hardware.
|
|
For updating the firmware on a system being deployed, the system must provide an interface for altering the firmware.
|
|
In addition, such an interface should provide mechanisms to check which firmware is currently installed and which configuration parameters are used.
|
|
|
|
Even if systems are equipped with an interface for applying updates, the maintenance cost can still be enormous if an administrator has to interact with each device physically.
|
|
For systems that are located in areas where reachability is limited the cost increases even more.
|
|
If a system is already able to communicate over a network interface, this can be leveraged to apply updates on these system - this is typically referred to as \textit{Over the Air (OTA)}.
|
|
By reusing the existing communication channels, the dedicated update interface can be omitted which leads to smaller packaging and reduces production cost.
|
|
It also decreases the maintenance cost drastically, because updates can be triggered remotely.
|
|
|
|
\textit{OTA} updates enable administrators to apply automation methods on the update process allowing to roll out new releases and fixes in a controlled fashion.
|
|
As an example, updates can be done on test-devices first, followed by security-critical deployments and subordinate ones can be delayed to times when the device is not utilized.
|
|
Further, a feedback channel which provides information about the update status of a devices allows administrators to apply monitoring techniques ensuring all updates are installed and devices are in the desired state.
|
|
|
|
The remaining part of this paper is laid out as follows.
|
|
Section \ref{related} discusses related work.
|
|
Next, in Section \ref{env} we present the environment, our research is based on, while Section \ref{req} defines the requirements for the implementation of an \textit{OTA} update mechanism in this environment.
|
|
A concept for the implementation is presented in Section \ref{concept} and a reference implementation can be found in Section \ref{implementation}.
|
|
Finally, a conclusion and future work can be found in Section \ref{conclusion}.
|