IARIA-Paper-2017
/
esper-ota
4
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
Browse Source

more restructuring

master
Sven Reissmann 8 years ago
parent
64d9ea2ead
commit
4582f01606
2 changed files with 50 additions and 51 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 23
      4-requirements.tex
  2. 78
      foo.tex

23
4-requirements.tex
View File

@ -1,30 +1,33 @@
\section{Requirements}
\makeatletter
\renewcommand{\@IEEEsectpunct}{\,}% Modified from {:\ \,}
\makeatother
For the implementation of an OTA update mechanism, the following requirements were defined.
\begin{itemize}
\item 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.
\item 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.
\item 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.
\item The update process can happen over any untrusted wireless network or Internet connection without being vulnerable to attackers.
\subsubsection{}\label{req4}The update process can happen over any untrusted wireless network or Internet connection without 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, if the cryptographic signature of the downloaded firmware image can be verified.
\item 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.
\item 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.
\item 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.
\end{itemize}
\makeatletter
\renewcommand{\@IEEEsectpunct}{:\ \,}
\makeatother

78
foo.tex
View File

@ -1,39 +1,22 @@
\section{Concept for implementing OTA updates}
Implementing \textit{OTA} updates under the given requirements involves three different components, which interact closely.
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 the \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.
\subsection{flash layout and concept}
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.
To implement \textit{OTA} updates under the given requirements, we define a topology, which integrates our build infrastructure, firmware repository and MQTT-broker with the IoT wifi network the devices are connected to.
The base topology used is shown in Figure \ref{fig:topology}.
\begin{figure}[htbp]
\centering\includegraphics[scale=0.6]{flash_layout.pdf}
\caption{The flash layout used for two ROMs.}
\label{fig:memory_layout}
\centering\fbox{\includegraphics[width=.98\linewidth]{topology.pdf}}
\caption{The base network topology.}
\label{fig:topology}
\end{figure}
As the binary to download and flash possibly exceeds the size of free memory heap space, the received data must be written to the flash directly.
In contrasts, executing the code from the memory mapped flash while writing the same area with the downloaded update leads to errors, as the executed code changes immediately to the updated one.
To avoid this, we chose the memory layout shown in Figure~\ref{fig:memory_layout}.
The flash is split into half to contain two firmware ROMs with different versions, one being executed and one which is being downloaded.
This standby firmware also acts as a safety mechanism if the download fails or is interrupted as the previous version stays intact and can still be used.
In case of an error the old firmware is kept unchanged and will be used until the successful download of a newer firmware succeeds.
In addition to the two firmware ROMs, the flash must provide room for the bootloader and its configuration.
\subsection{Common framework and build infrastructure}
\subsection{Common framework and Multidevice support}
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 framework.
In addition, components and functionality shared by all devices has been identified and are providing a framework for the existing and possible further devices.
This framework provides a functional base for all devices and allows to reuse code providing functionality which is common in multiple devices.
The framework also includes a build system, which allows to configure some basic parameters for all devices.
The framework also 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.
@ -44,30 +27,43 @@ Updating the framework version and rebuilding the firmware would often result in
More problems will arise if the application programming interface (API) of the framework changes.
In this situation, the device firmware must be updated to use the changed API, which can be an unpleasant and complex task and leads to higher latency for firmware updates.
To prevent these problems the device firmware of all devices in the hackerspace is now integrated with the framework into a larger project.
To prevent these problems the device firmware of all devices in the hackerspace is integrated with the framework into a larger project.
By doing so, each device specific code is always linked to the latest version of the framework.
Device specific code is now organized as a folder for each device type.
The build system has been modified to scan for all device specific folders and call the original build process for each of them.
The according device type is provided as a string through a global constant at compile time and it must never be changed during operation.
Device specific code is organized as a folder for each device type.
To build the software, a \textit{Makefile} \cite{make} is used, which provides a simple way for reproducible builds.
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.
The according device type is provided as a string through a global constant at compile time and it must never be changed during operation.
The source code of the \textit{ESPer} project is published into a \textit{Git} source code repository which is provided by the hackerspace.
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.
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{Automatic deployment process}
The source code of the \textit{ESPer} project is published into a \textit{GIT} source code repository which is provided by the hackerspace.
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.
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}
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.
The base topology used is shown in Figure \ref{fig:topology}.
\begin{figure}[htbp]
\centering\fbox{\includegraphics[width=.98\linewidth]{topology.pdf}}
\caption{The base network topology.}
\label{fig:topology}
\centering\includegraphics[scale=0.6]{flash_layout.pdf}
\caption{The flash layout used for two ROMs.}
\label{fig:memory_layout}
\end{figure}
As the binary to download and flash possibly exceeds the size of free memory heap space, the received data must be written to flash directly.
In contrast, executing the code from the memory mapped flash while writing the same area with the downloaded update leads to errors, as the executed code changes immediately to the updated one.
To avoid this, we chose the memory layout shown in Figure~\ref{fig:memory_layout}.
The flash is split into half to contain two firmware ROMs with different versions, one being executed and one which is being downloaded.
This standby firmware also acts as a safety mechanism if the download fails or is interrupted as the previous version stays intact and can still be used (refer to requirement \ref{req2}).
In case of an error the old firmware is kept unchanged and will be used until the successful download of a newer firmware succeeds.
In addition to the two firmware ROMs, the flash must provide room for the bootloader and its configuration.
\subsection{Publish device information}

Write Preview
Loading…
Cancel
Save