\chapter{Proposed System}
\label{chap-proposed-system}
\glsresetall

The proposed system is a SmartCGMS concept that can be compiled for low-power devices and general-purpose computers with minimal modifications. The project requirements specify two low-power platforms: Raspberry Pi Zero W and ESP32. However, additional platforms might be required in the future. Therefore, the SmartCGMS concept should be easily portable. As suggested by Otta in \parencite{otta}, one of the supported platforms will be \gls{wasm}. Then, any platform implementing the \gls{wasm} virtual stack machine will be able to execute the SmartCGMS concept \gls{wasm} module. The scenario of compiling the proposed SmartCGMS concept application is displayed in figure \ref{fig:concept_arch}. The SmartCGMS concept application comprises three parts: the SmartCGMS framework source code, a SmartCGMS filter chain, and a platform environment (e.g., FreeRTOS source code, drivers). Throughout this thesis, the \texttt{SmartCGMS concept application} will refer to the executable for a specific platform or its source code. The \texttt{SmartCGMS concept} will refer to the whole proposed system used to compile SmartCGMS concept applications. The current state of the SmartCGMS framework will be referred to as the \texttt{original SmartCGMS} or just \texttt{SmartCGMS}. 

\begin{figure}[htpb]
  \centering
  \includegraphics[width=0.8\textwidth]{figures/concept.PNG}
  \caption{Steps to deploy the SmartCGMS concept to different platforms} \label{fig:concept_arch}
\end{figure}

\newpage
This chapter describes the proposed SmartCGMS concept, the design choices, and the platforms on which the SmartCGMS concept applications will be tested.

\section{System Design}

SmartCGMS is written in C++ using the C++17 standard. It relies heavily on the C++17 features, namely the C++17 standard filesystem library. Although C++ is considered portable, many low-power devices still lack the support for some C++17 features, such as the C++17 standard filesystem library. The SmartCGMS framework requires the filesystem library to load its components (the SmartCGMS core and common libraries) and to manage entities (e.g., filters) as each entity is implemented as a dynamic library.

\subsection{Static Linking}

Given the lack of support for the C++ standard filesystem library on low-power devices, it would be necessary to implement a way to manage dynamic libraries for each low-power device. This would complicate the introduction of new platforms that are compatible with the concept. Therefore, the SmartCGMS concept applications will be linked statically at compile time instead. 

\subsection{Filter Preprocessor}

SmartCGMS uses functions exported by the filters to construct the filter chain. The exported function names of different filters in the original SmartCGMS are identical (\texttt{do\_create\_filter} and \texttt{do\_get\_filter\_descriptors}). When linking the SmartCGMS concept applications statically, identical function names would lead to linker conflicts. To avoid this, each filter in the SmartCGMS concept applications is required to export functions with unique names. 

This approach is not compatible with the original SmartCGMS. To prevent the need to develop separate filters for the SmartCGMS concept and the original SmartCGMS, a filter preprocessor tool is proposed. The purpose of the preprocessor is to modify the source code of the filters developed for the original SmartCGMS to avoid linker conflicts.

Conflicting function names are appended with a suffix to ensure each function has a unique signature. To minimize modifications to the SmartCGMS codebase, the preprocessor generates additional source code files. These files replace parts of the original SmartCGMS that manage the filters' dynamic libraries. Instead, the filter functions with modified names are called directly.

This tool ensures that SmartCGMS filters do not need to be implemented specifically for the SmartCGMS concept. A filter can be developed as a dynamic library satisfying the requirements of the original SmartCGMS. It is then modified by the preprocessor and used in the SmartCGMS concept without any modifications done by the developer.  


\subsection{Preserving Modularity}
\label{subsec:modularity}

It is important to keep the SmartCGMS concepts modular. To achieve this, the separation between the SmartCGMS codebase and the filter chain is maintained. The proposed system can be split into three main components:

\begin{itemize}
    \item SmartCGMS codebase
    \item Platform environment
    \item Filter chain
\end{itemize}

The SmartCGMS codebase includes the original SmartCGMS codebase (the core and common libraries). SmartCGMS offers a simple interface that allows using the SmartCGMS framework from other programming languages. It is a C-style \gls{api}. The simple \gls{api} functions are: create a filter chain specified by a configuration file, shut the filter chain down, and inject events into the filter chain. This interface can be used for the SmartCGMS concept as it offers a basic set of functions to interact with SmartCGMS. Missing functionality can be implemented. The SmartCGMS codebase might remain unchanged for each platform except for one file. SmartCGMS uses a WinAPI mapping file to provide access to system resources. This file needs to be updated when a new platform is introduced. 

The platform environment code defines the behavior of the SmartCGMS concept application. From the environment source code, the SmartCGMS \gls{api} is called.
Additionally, the FreeRTOS source code, drivers, and other necessary software components belong to the platform environment. Build scripts can also be provided to simplify the compilation process of the SmartCGMS concept application. CMake will be used to generate build files for all platforms.

When creating filters for the SmartCGMS concept, many can be implemented as platform-independent, such as filters computing a signal value. Whereas some filters are, by design, platform-dependent. This includes input filters, such as a filter listening on a peripheral device for incoming events, and output filters generating output. The reason for their platform dependency can be, for example, a display driver specific to a target platform. Any filter that requires asynchronous processing of information and needs to create a new thread will also need to be developed with a specific platform in mind (e.g., using FreeRTOS tasks in low-power devices running FreeRTOS versus using standard thread library from C++ in platforms that support it).

\subsection{WebAssembly}

In addition to targeting traditional \glspl{isa} like AMD64/x86-64, ARMv6, and Xtensa, the goal is to support \gls{wasm} for maximum portability. There are no obstacles that would limit compiling a SmartCGMS concept application to \gls{wasm}. The issue with \gls{wasm} lies in preparing the platform environment to support \gls{wasm}. A \gls{wasm} standalone runtime must be ported to the platform to be able to execute \gls{wasm} modules.  Although \gls{wasm} is not yet widely supported by many embedded platforms, there is a growing effort to standardize \gls{wasm} interaction with the underlying platform (\gls{wasi} - described in section \ref{sub:wasi}) and bring it to new platforms. 

Compiling the SmartCGMS concept application to \gls{wasm} offers two main advantages. Firstly, it allows the software to be compiled just once and then transmitted in the \gls{wasm} binary format to other platforms. This eliminates the need for platform-specific compilation. Secondly, it brings SmartCGMS to the web. The ability to use SmartCGMS from the web browser makes it more accessible to users and potentially speeds up its adoption. A drawback of \gls{wasm} is the complex process of porting \gls{wasm} runtimes to new platforms.


\section{Target Architectures}

This section describes the specific platforms representing each \gls{isa} specified by the project requirements.

\subsection{Low-Power Devices}

The ARMv6 and Xtensa \gls{isa} devices represent low-power devices that could be used in the field (e.g., worn by a diabetic patient). Raspberry Pi Zero W and ESP32 chips have been selected for this project.

\subsubsection{ESP32}

ESP32 is a microcontroller unit with ultra-low power consumption, robust design, and connectivity (Wi-Fi and Bluetooth) \parencite{esp32_docs}. It is widely adopted in the Internet of Things applications due to its price and performance \parencite{esp32-analysis}. The board has an Xtensa LX6 Dual-Core 240 MHz CPU, 520 KB of SRAM, and 2 MB of FLASH (with support up to 64 MB) with an operating current of 80 mA. The development for the board is simple, thanks to the \gls{espidf} - ESP32 official development framework. It provides an easy way to build and flash ESP32 projects to the board. \gls{espidf} is based on FreeRTOS, thus FreeRTOS API is available when developing applications for ESP32. \gls{espidf} build system is based on CMake. It offers additional syntax to reduce boilerplate, but pure CMake can also be used to configure projects. \gls{espidf}'s build system uses a concept called components. Components are static libraries linked to the ESP32 application that are defined using CMake files. There are official components offered by \gls{espidf} (e.g., FreeRTOS), but one can also implement their own components. The ease of use and availability make the ESP32 a good candidate for this project. Additionally, it has been selected by Otta in \parencite{otta} as the hardware of choice. \parencite{esp32_docs}\parencite{espidf}


\subsubsection{Raspberry Pi Zero W}

Raspberry Pi Zero W is a compact and cheaper alternative to the Raspberry Pi microcontroller board. The 'W' represents connectivity, namely Wi-Fi and Bluetooth. It has a BCM2835 ARMv6 1Ghz single-core CPU, 512 KB of SDRAM, and support for a microSD card. Its operating current is 100 mA \parencite{rpi}. An official port of FreeRTOS \parencite{freertos} is not available for the board. The Raspberry Pi Zero W offers more computing power and memory than the ESP32 at the cost of increased energy usage. It has been selected for this project due to its availability and similarity to the ESP32.

Raspberry Pi Foundation offers an operating system for the Raspberry Pi Zero W - the Raspberry Pi OS (previously called Raspbian). It is based on Debian, and it provides a desktop environment called PIXEL (Pi Improved Xwindows Environment, Lightweight)  \parencite{rpi}. It is not an \gls{rtos}. Therefore, FreeRTOS has been ported to Raspberry Pi Zero W and used instead. 

\subsection{High Performance Computing}

The AMD64/x86-64 \gls{isa} represents computers with high processing power compared to the Raspberry Pi and ESP32. The reason why SmartCGMS is targeted at these platforms is to run computationally intensive simulations. 

The SmartCGMS console application was developed to preserve system resources and can be used for computationally extensive tasks \parencite{diabetes_zcu}. The SmartCGMS concept does not aim to offer better processing performance than the existing SmartCGMS solutions. The reason the proposed SmartCGMS concept is compatible with general-purpose computers (e.g., x86-64 running GNU/Linux) is to be able to verify the correct functionality of a filter chain before deployment to a low-power device.
