142 lines
11 KiB
TeX
142 lines
11 KiB
TeX
\chapter{Adaptation}\label{ch:adaptation}
|
|
|
|
In this chapter, we outline the considerations made during the development of the IoT testbed, \iottbsc.
|
|
Starting from first principles, we derive the requirements for our testbed and finally establish the scope for \iottbsc.
|
|
The implemented testbed which results from this analysis, the software package \iottb, is discussed in \cref{ch4}.\\
|
|
|
|
\section{Principal Objectives}\label{sec:principles-and-objectives}
|
|
The stated goal for this bachelor project (see \cref{sec:goal}), is to create a testbed for \iot devices, which automates aspects of the involved workflow, with the aim of increasing reproducibility, standardization, and compatibility of tools and data across project boundaries.
|
|
We specify two key objectives supporting this goal:
|
|
\begin{enumerate}[label=\textit{Objective \arabic*}]
|
|
\item \textbf{Automation Recipes:}\label{obj:recipies} The testbed should support specification and repeated execution of important aspects of experiments with IoT devices, such as data collection and analysis (see \citep{fursinckorg2021})
|
|
\item \textbf{FAIR Data Storage:}\label{obj:fair} The testbed should store data in accordance with the FAIR \citep{go-fair} principles.
|
|
\end{enumerate}
|
|
|
|
\section{Requirements Analysis}\label{sec:requirements}
|
|
In this section, we present the results of the requirements analysis based on the principal objectives.
|
|
The requirements derived for \ref{obj:recipies} are presented in \cref{table:auto_recipe_requirements}.
|
|
\cref{table:fair_data_storage_requirements} we present requirements based on \ref{obj:fair}.
|
|
|
|
\begin{table}[H]
|
|
\centering
|
|
\caption{Automation Recipes Requirements}
|
|
\label{table:auto_recipe_requirements}
|
|
\begin{minipage}{\textwidth}
|
|
\begin{enumerate}[label=\textit{R1.\arabic*}]
|
|
\item \label{req:auto_install_tools} \textbf{Installation of Tools}: Support installation of necessary tools like \textit{mitmproxy} \cite{mitmproxy}, \textit{Wireshark} \cite{wiresharkorg} or \textit{tcpdump} \cite{tcpdump}).
|
|
|
|
\textit{Reasoning:}
|
|
There are various tools used for data collection and specifically packet capture.
|
|
Automating the installation of necessary tools ensures that all required software is available and configured correctly without manual intervention. This reduces the risk of human error during setup and guarantees that the testbed environment is consistently prepared for use. Many platforms, notably most common Linux distributions, come with package managers which provide a simple command-line interface for installing software while automatically handling dependencies. This allows tools to be quickly installed, making it a \textit{lower priority} requirement for \iottbsc.
|
|
|
|
\item \label{req:auto_config_start} \textbf{Configuration and Start of Data Collection}: Automate the configuration and start of data collection processes. Specific subtasks include:
|
|
\begin{enumerate}
|
|
\item Automate wireless hotspot management on capture device.
|
|
\item Automatic handling of network capture, including the collection of relevant metadata.
|
|
\end{enumerate}
|
|
|
|
\textit{Reasoning:}
|
|
Data collection is a central step in the experimentation workflow. Configuration is time-consuming and prone to error, suggesting automating this process is useful.As mentioned in \cref{sec:motivation}, current practices lead to incompatible data and difficult to reuse scripts.
|
|
Automating the configuration and start of data collection processes ensures a standardized approach, reducing the potential for user error
|
|
and thereby increasing data compatibility and efficient use of tools. Automating this process must be a central aspect of \iottbsc.
|
|
|
|
\item \label{req:auto_data_processing} \textbf{Data Processing}: Automate data processing tasks.
|
|
|
|
\textit{Reasoning:} Some network capture tools produce output in a binary format. To make the data available to other processes, often the data must be transformed in some way.
|
|
Data processing automation ensures that the collected data is processed uniformly and efficiently, enhancing it reusability and interoperability. Processing steps may include cleaning, transforming, and analyzing the data, which are essential steps to derive meaningful insights. Automated data processing saves time and reduces the potential for human error. It ensures that data handling procedures are consistent, which is crucial for comparing results across different experiments and ensuring the validity of findings.
|
|
|
|
|
|
\item \label{req:auto_reproducibility} \textbf{Reproducibility}: Ensure that experiments can be repeated with the same setup and configuration.
|
|
|
|
\textit{Reasoning:} A precondition to reproducible scientific results is the ability to run experiments repeatedly with all relevant aspects are set up and configured identically.
|
|
\item \label{req:auto_execution_control} \textbf{Execution Control}: Provide mechanisms for controlling the execution of automation recipes (e.g., start, stop, status checks).
|
|
|
|
\textit{Reasoning:} Control mechanisms are essential for managing the execution of automated tasks. This includes starting, stopping, and monitoring the status of these tasks to ensure they are completed successfully.
|
|
|
|
\item \label{req:auto_error_logging} \textbf{Error Handling and Logging}: Include robust error handling and logging to facilitate debugging to enhance reusability.
|
|
|
|
\textit{Reasoning:} Effective error handling and logging improve the robustness and reliability of the testbed.Automation recipes may contain software with incompatible logging mechanisms.
|
|
To facilitate development and troubleshooting, a unified and principled logging important for \iottbsc.
|
|
\item \label{req:auto_documentation} \textbf{Documentation}: Provide clear documentation and examples for creating and running automation recipes.
|
|
\end{enumerate}
|
|
\end{minipage}
|
|
\end{table}
|
|
|
|
\begin{table}[H]
|
|
\centering
|
|
\caption{FAIR Data Storage Requirements}
|
|
\label{table:fair_data_storage_requirements}
|
|
\begin{minipage}{\textwidth}
|
|
\begin{enumerate}[label=\textit{R2.\arabic*}]
|
|
\item \label{req:fair_data_meta_inventory} \textbf{Data and Metadata Inventory}: \iottbsc should provide an inventory of data and metadata that typically need to be recorded (e.g., raw traffic, timestamps, device identifiers).
|
|
|
|
\textit{Reasoning:} Providing a comprehensive inventory of data and metadata ensures that data remains findable after collection. Including metadata increases interpretability and gives context necessary for extracting reproducible results.
|
|
|
|
\item \label{req:fair_data_formats} \textbf{Data Formats and Schemas}: Define standardized data formats and schemas.
|
|
|
|
\textit{Reasoning:} Standardized data formats and schemas ensure consistency and interoperability.
|
|
|
|
\item \label{req:fair_file_naming} \textbf{File Naming and Directory Hierarchy}: Establish clear file naming conventions and directory hierarchies. for organized data storage.
|
|
|
|
\textit{Reasoning:} This enhances findability and accessibility.
|
|
\item \label{req:fair_preservation} \textbf{Data Preservation Practices}: Implement best practices for data preservation, including recommendations from authoritative sources like the Library of Congress \citep{recommendedformatrsLOC}.
|
|
|
|
\textit{Reasoning:} Implementing best practices for data preservation can mitigate data degradation and ensures integrity of data over time. This ensures long-term accessibility and reusability.
|
|
\item \label{req:fair_accessibility} \textbf{Accessibility Controls}: Ensure data accessibility with appropriate permissions and access controls.
|
|
\item \label{req:fair_interoperability} \textbf{Interoperability Standards}: Use widely supported formats and protocols to facilitate data exchange and interoperability.
|
|
\item \label{req:fair_reusability} \textbf{Reusability Documentation}: Provide detailed metadata to support data reuse by other researchers.
|
|
\end{enumerate}
|
|
\end{minipage}
|
|
\end{table}
|
|
|
|
We return to these when we evaluate \iottbsc in \cref{ch:5-eval}.
|
|
|
|
\section{Scope}\label{sec:scope}
|
|
This section defines the scope of the testbed \iottbsc.
|
|
To guide the implementation of the software component of this bachelor project, \iottb,
|
|
we focus on a specific set of requirements that align with the scope of a bachelor project.
|
|
While the identified requirements encompass a broad range of considerations, we have prioritized those that are most critical to achieving the primary objectives of the project.
|
|
|
|
For this project, we delineate our scope regarding the principal objectives as follows:
|
|
\begin{itemize}
|
|
\item \ref{obj:recipies}: \iottb focuses on complying with \ref{req:auto_config_start}, \ref{req:auto_reproducibility}.
|
|
\item \ref{obj:fair}: \iottb ensures FAIR data storage implicitly, with the main focus lying on \ref{req:fair_data_formats}, \ref{req:fair_data_meta_inventory}, \ref{req:fair_file_naming}.
|
|
\end{itemize}
|
|
|
|
|
|
\subsection{Model Environment}\label{sec:assumed-setup}
|
|
In this section, we describe the environment model assumed as the basis for conduction \iot device experiments.
|
|
This mainly involves delineating the network topology. Considerations are taken to make this environment, over which the \iottb testbed software has no control, easy reproducible \citep{vacuumpie2023}.\\
|
|
|
|
We assume that the \iot device generally requires a Wi-Fi connection.
|
|
This implies that the environment is configured to reliably capture network traffic without disrupting the \iot device's connectivity. This involves setting up a machine with internet access (wired or wireless) and possibly one Wi-Fi card supporting AP mode to act as the \ap for the \iot device under test \citep{surveytestingmethods2022}.
|
|
Additionally, the setup must enable bridging the IoT-AP network to the internet to ensure \iot device.\\
|
|
|
|
Specifically, the assumed setup for network traffic capture includes the following components:
|
|
\begin{enumerate}
|
|
\item \textbf{IoT Device:} The device under investigation, connected to a network.
|
|
\item \textbf{Capture Device:} A computer or dedicated hardware device configured to intercept and record network traffic. This is where \iottb runs.
|
|
\item \textbf{Wi-Fi \ap:} The \ap through which the \iot device gets network access.
|
|
\item \textbf{Router/ Internet gateway:} The network must provide internet access.
|
|
\item \textbf{Switch or software bridge:} At least either a switch or an \os with software bridge support must be available to be able to implement one of the setups described in \cref{fig:cap-setup1} and \cref{fig:cap-setup2}.
|
|
\item \textbf{Software:} tcpdump is needed for network capture.
|
|
\end{enumerate}
|
|
\newpage
|
|
\begin{figure}[!ht]
|
|
\centering
|
|
\includegraphics[width=0.75\linewidth]{Figures/network-setup1.png}
|
|
\caption{Capture setup with separate Capture Device and AP}
|
|
\label{fig:cap-setup1}
|
|
\end{figure}
|
|
|
|
\begin{figure}[!ht]
|
|
\centering
|
|
\includegraphics[width=0.75\linewidth]{Figures/setup2.png}
|
|
\caption{Capture setup where the capture device doubles as the \ap for the \iot device.}
|
|
\label{fig:cap-setup2}
|
|
\end{figure}
|
|
\newpage
|
|
|
|
|
|
|