From d019cc79f5c5486f79e672b7f6cb31749a69d3f8 Mon Sep 17 00:00:00 2001 From: Dustin Frisch Date: Mon, 12 Jun 2017 12:55:25 +0200 Subject: [PATCH] Formatting --- 1-introduction.tex | 1 - 2-related-work.tex | 1 - 3-environment.tex | 1 - 4-requirements.tex | 21 ++++++++++++++------- 5-concept.tex | 5 ----- 6-1-multidevice_build_structure.tex | 5 +---- 6-3-update_mechanism.tex | 5 ----- 7-conclusion.tex | 1 - 8 files changed, 15 insertions(+), 25 deletions(-) diff --git a/1-introduction.tex b/1-introduction.tex index a877e0b..da79fd8 100644 --- a/1-introduction.tex +++ b/1-introduction.tex @@ -1,5 +1,4 @@ \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. diff --git a/2-related-work.tex b/2-related-work.tex index 90e545c..9ca3208 100644 --- a/2-related-work.tex +++ b/2-related-work.tex @@ -1,3 +1,2 @@ \section{Related Work} - Wireless sensor and actor networks are a crucial elements of today's effort to support and implement \textit{Industry 4.0} architectures and modern manufacturing processes. Small programmable logic controllers (PLC) and cloud computing are enabler but also drivers of these new manufacturing paradigms\cite{Nigappa:2016eb}. Thus, the networked interconnection of everyday objects, the automation of home appliances and environmental metering and monitoring based on sensor and actor networks controlled by ESP-based chipsets are subject of current research. In \cite{DiNisio:2015fg} a low-cost multipurpose wireless sensor network using \textit{ESP8266} PLCs is introduced. The usage of \textit{ESP8266} PLCs in combination with Raspberry PI acting as base station for the sensors is discussed in \cite{Thaker:2016fi}. The article \cite{Kodali:2016hc} presents a home automation solution based on a \textit{MQTT} message queue with \textit{ESP8266}-based sensors and actors. The control of smart bulbs with PLCs is summarized in \cite{Walia:2016bj}. Unfortunately, software update mechanisms are not addressed in these publications. Generic approaches of decentralized software updates in IoT environments are introduced in \cite{Weisbach:2016bs} and \cite{Ruckebusch:2016vo}. The \textit{Over the Air} programming capabilities of the \textit{ESP8266} PLCs are described in \cite{Gore:2016ue}. \ No newline at end of file diff --git a/3-environment.tex b/3-environment.tex index f5adca5..b401006 100644 --- a/3-environment.tex +++ b/3-environment.tex @@ -1,5 +1,4 @@ \section{Environment} - The research presented in this paper was mainly driven by \textit{Magrathea Laboratories e.V.}\cite{maglab}, the local hackerspace in Fulda, in cooperation with researchers at the department for computer science at Fulda University. Requirements were clearly defined by Magrathea Laboratories demands to provide local and remote control over various sensors and actors in the foundations rooms to visitors and members. Such components include door sensors, power sockets, temperature sensors, projectors and screens who are all managed by a home-automation controller, which is driven by the software \textit{home-assistant}\cite{HASS}. diff --git a/4-requirements.tex b/4-requirements.tex index a32c3ff..2d9784d 100644 --- a/4-requirements.tex +++ b/4-requirements.tex @@ -4,27 +4,34 @@ \makeatother For the implementation of an OTA update mechanism, the following requirements were defined. -\subsubsection{}\label{req1}The systems should be able to perform updates on the release of new software without manual interaction. +\subsubsection{}\label{req1} +The systems should be able to perform updates on the release of new software without manual interaction. If a new firmware version is published, it should be prepared automatically for installation on the target devices. All these devices should then fetch and install the new software version and start using it subsequently, if no errors have occurred during the update. -\subsubsection{}\label{req2}To ensure minimal maintenance effort, the update process should be insusceptible to errors as much as possible. +\subsubsection{}\label{req2} +To ensure minimal maintenance effort, the update process should be insusceptible to errors as much as possible. Even if the installation of an update fails in the middle of reprogramming the device, the system should continue to work fully functional immediately and after reboot. -\subsubsection{}\label{req3}Firmware downloads should be performed over the same WiFi connection as used during normal operation. +\subsubsection{}\label{req3} +Firmware downloads should be performed over the same WiFi connection as used during normal operation. Fetching the firmware should be done side-by-side with operational traffic. -\subsubsection{}\label{req4}The update process can happen over any untrusted wireless network or Internet connection and therefor must not being vulnerable to attackers. +\subsubsection{}\label{req4} +The update process can happen over any untrusted wireless network or Internet connection and therefor must not being vulnerable to attackers. To prevent possible attackers from injecting malicious software into the embedded devices, a cryptographic signature mechanism must be implemented. New firmware only gets accepted by the device, iff the cryptographic signature of the downloaded firmware image can be verified. -\subsubsection{}\label{req5}To reduce network load and aim for the maximum possible uptime of the device, the update process should only be done if a new firmware version is available. +\subsubsection{}\label{req5} +To reduce network load and aim for the maximum possible uptime of the device, the update process should only be done if a new firmware version is available. In contrast, on the release of new firmware, the roll-out to all devices should be performed as fast as possible. %While checking for available updates and downloading such an update, the device should continue to work as usual. -\subsubsection{}\label{req6}For easy maintenance and monitoring, each device should provide detailed information about the currently installed firmware version and other details relevant for the update process. +\subsubsection{}\label{req6} +For easy maintenance and monitoring, each device should provide detailed information about the currently installed firmware version and other details relevant for the update process. -\subsubsection{}\label{req7}Devices are categorized by types. +\subsubsection{}\label{req7} +Devices are categorized by types. Each type runs the same software and therefore provides the same functionality. As the device type is hardly coupled to the hardware and the software interacts with it on a specific way, the update process must ensure that the correct firmware is used while reprogramming. diff --git a/5-concept.tex b/5-concept.tex index 092aacd..5f6e6ac 100644 --- a/5-concept.tex +++ b/5-concept.tex @@ -1,5 +1,4 @@ \section{Concept for implementing OTA updates} - The firmware for all \textit{ESP8266} based devices in the hackerspace are all based on the same framework. \textit{Sming} provides the base library for this \textit{ESPer} framework, which provides components and functionality shared by all devices. This allows to reuse code providing functionality which is common in multiple devices. @@ -26,7 +25,6 @@ Beside data like device type, chip and flash ID, the published data includes det This allows administrators to find devices with outdated bootloaders and helps to find missing or failed updates. \subsection{Common framework and build infrastructure} - The framework includes a build system, which allows to configure basic parameters for all devices, including, but not limited to, the Wi-Fi access parameters, the \textit{MQTT} connection settings and the updater URLs. By sharing the same code, all devices ensure to have a common behavior when it comes to reporting the device status or interacting with the home-automation controller. This eases configuration and allows to collect information about all devices at a central location. @@ -43,16 +41,13 @@ To build the software, a \textit{Makefile} \cite{make} is used, which provides a When a new build process is started, the build system scans for all device specific folders and calls the original build process for each of them. After the build of the firmware has finished, the build system also creates a fail for each device containing the build version and the firmware signatures. - To avoid interferences between different build environments on developers computers and roll out new versions as early as possible, the code has been integrated into a continuous integration (CI) system. The CI, which is based on \textit{drone} \cite{drone} and provided as part of the hackerspace infrastructure, allows to execute commands on each version published into the \textit{Git} repository. In the specific case, whenever a new version gets checked-in into the release branch, the \textit{Makefile} is used to build the binary firmware files and publish them to the firmware repository server. Therefore, a \textit{drone} configuration file as shown in Listing~\ref{lst:drone} has been added to the source code as \texttt{.drone.yml}. - \subsection{Device setup and flash layout}\label{flashlayout} - Microcontroller boards based on the \textit{ESP8266} MCU are mostly following the same layout: the MCU is attached to a flash chip which contains the bootloader, firmware and other application data. The memory mapping mechanism of the MCU allows only a single page of 1 MB of flash to be mapped at the same time \cite{ESP8266_Memory_Map} and the selected range must be aligned to 1 MB blocks. diff --git a/6-1-multidevice_build_structure.tex b/6-1-multidevice_build_structure.tex index 5536e59..e2570b7 100644 --- a/6-1-multidevice_build_structure.tex +++ b/6-1-multidevice_build_structure.tex @@ -1,9 +1,7 @@ \subsection{Multi-Device build infrastructure} - \subsubsection{Framework integration} - The framework is build to keep control over the application life-cycle. It ensures that the device unspecific code is executed at the right time and provides an API for device specific functionality. @@ -32,8 +30,7 @@ Device* getDevice() { \subsubsection{Build system} - -The existing \textit{Makefile} has been refactored to accept a parameter for device type identifiers called \texttt{DEVICE} and to create its whole output inside a subdirectory specific to the device type. +The \textit{Makefile} is build to accept a parameter for device type identifiers called \texttt{DEVICE} and to create its whole output inside a subdirectory specific to the device type. Another \textit{Makefile} has been created which scans a project subdirectory and uses each directory in there as container for device specific code. For each of these directories, the other \textit{Makefile} is called and the subdirectories name is used as \texttt{DEVICE} parameter. By splitting the build and recompiling the framework each time before intermixing it with the device specific code, the device type identifier can be used inside the shared framework code. diff --git a/6-3-update_mechanism.tex b/6-3-update_mechanism.tex index f6e5ed6..d6b15a2 100644 --- a/6-3-update_mechanism.tex +++ b/6-3-update_mechanism.tex @@ -1,5 +1,4 @@ \subsection{The update mechanism} - The implementation of the update mechanism consists of four parts which interact closely: checking for updates, reprogramming the device, calculating and verifying the firmware signature and reconfiguring the boot process. This sections describes all four of these parts in detail. @@ -7,9 +6,7 @@ The build-time configuration was extended to include a new option called \texttt Each device requires to have this option set to make the update work. Skipping the option results in the exclusion of the code for update management during the build. - \subsubsection{Checking for updates} - Each device queries the update server regularly for the current firmware version and initializes the update process if remote and local versions differ. To do so, the update server provides a file for each device type containing meta-information about the available firmware which consists of the version identifier and the signatures of both of the firmware binaries. These meta-information files are provided by the update server using \textit{HTTP 1.1}\cite{HTTP_1.1} under the following path pattern: \texttt{\$\{DEVICE\}.version} (whereas \texttt{\$\{DEVICE\}} is the device type name). @@ -26,9 +23,7 @@ In addition to the interval, a special \textit{MQTT} topic shared by all devices Every time a message is received on this topic, a fetch attempt for the meta-information file is triggered and the process restarts. This allows faster roll-outs of updates and finer control for manual maintenance. - \subsubsection{Reprogramming the device} - As the \textit{ESP-01s} is only equipped with 1 MB of flash, this means that the whole memory is mapped to a contiguous address space. Therefore, the second ROM can not be re-mapped to have the same start address as the first ROM. While the firmware is executed without any dynamic linking mechanism and the chip does not support position independent code, the addresses used in the ROMs are dependent to the offset at which the firmware is stored. diff --git a/7-conclusion.tex b/7-conclusion.tex index d9ceb8d..18506f3 100644 --- a/7-conclusion.tex +++ b/7-conclusion.tex @@ -1,5 +1,4 @@ \section{Conclusion} - The project has been successfully deployed in the hackerspace and is now an essential part of home-automation development and deployment. The update infrastructure has been the crucial point for decisions towards the framework for most members.