\documentclass[12pt]{article}
\usepackage{amsmath}
\usepackage{geometry}
\usepackage{setspace}
\usepackage{titlesec}
\usepackage{tabularx}
\usepackage{forest}
\usepackage{enumitem}
\usepackage{graphicx}  % Required for including images
\usepackage{float}     % Allows placement options like 
\usepackage{multirow} % tabular
\usepackage{caption}   % For customizing captions
\usepackage{longtable}
\usepackage{pdfpages}
% Set margins
\geometry{
  left=1in,
  right=1in,
  top=1in,
  bottom=1in
}

% Set line spacing
\doublespacing

% Set section formatting
\titleformat{\section}{\normalfont\Large\bfseries}{\thesection}{1em}{}
\titleformat{\subsection}{\normalfont\large\bfseries}{\thesubsection}{1em}{}
\begin{document}
\title{System Engineering Project: IoT Farming Challenges and Solutions v1.0 Draft}
\author{An Pham}
\date{Oct 1}

\maketitle
\tableofcontents
\newpage
\setcounter{section}{0}

\section{Problem Definition and Identification of Need}
\subsection{Problem Definition and Definition of Need}

Farmers are struggling to monitor the condition of their fields in real-time due to the high failure rate of IoT farming projects. Challenges such as network connectivity, sensor malfunctions, and integration issues have not yet been fully overcome. Reports also suggest a 30 percent setback due to the reliability of vendors' hardware and software in IoT projects. 

Farmers primarily want a real-time data collection system that meets their needs and provides an interface where they can interact with the data. However, a 'real-time' data-driven system introduces complexity due to technical debt and the cost of deploying many devices or sensors in the field. Due to software failures and connectivity issues, having equipment deployed and running apps via mobile devices is not always practical in many use cases. Mobile apps that access real-time data and perform assessments require a connection to the cloud and compatibility with current mobile operating systems. Without ignoring this limitation of current system, new approaches have to be introduced to satisfy the need of farmers.

Recently, many new sensors and network protocols have been introduced that achieve longer ranges, improving the ability to gather data over wider areas. In addition, these new sensors offer improvements in range and power consumption, creating opportunities to build new systems at lower costs with long-term community support. Investing in such a system that supports real-time data gathering and extended range has become more feasible. However, most IoT farming vendors are reluctant to upgrade old systems to support new wireless communication interfaces without vendors releasing a new model, which requires costly new installations. Vendors' profits tend to rely on selling sensors, IoT devices, and software support, making it less feasible for them to develop systems with maximized range. Another way in which vendors sustain operations is through software support platforms that rely on the Internet to provide services to customers. This approach is called "Data-Driven Agriculture," which uses data analytics and digital tools to improve farming techniques. While these platforms maximize the utilization of data gathered from the field, they introduce a new technology stack, increasing complexity and impacting system functionality. One critical aspect of "Data-Driven Agriculture" is the increase in the number of devices and their uptime. However, relying on a large pool of devices forces farmers to depend on multiple vendors and services to meet their needs.   Another factor to consider is the life time of these devices is that it's tend to be shorten when vendors or companies relize a slow growth in the market. According to the Register journal, Cisco planned to Abaddon support for long range IoT devices by 2026. This will leave their customer having no support after 2026 in both software and hardware. The company also quoted that it is infeasible to stay in this long range technology that can't help the growth of the company due to slow sell of devices. The company also disclosed that long range technology lead to smaller number of gateway deployed compared to wifi which slow down the sells of the devices. In short, even though new long range wireless technology is introduced, for profit  companies would not have incentives to develop this technology. 

As mentioned earlier, a system that depends on multiple vendors, with their short lifespans, introduces the risk of having a non-functional or outdated system. This research considers the needs of farmers, including how data is accessed and presented, how often data should be updated, and the level of reliance farmers place on the system. Most stakeholders for this project are homesteaders or farmers who prefer a certain level of self-reliance. If technology is introduced to their environment, they prefer it to offer the highest level of autonomy, which is one of the most important factors driving this project. These farmers are responsible for installing, maintaining, and operating the system. We aim to assemble or acquire a design for hardware requirements and create a basic software version to help farmers quickly start their system and reach the acquisition phase. Additionally, one of the key motivators for farmers to adopt smart IoT technology is to react to environmental changes that may harm or benefit their crops. At the same time, we focus on estimating water resources for farming activities, which in turn determines whether farmers need to invest further in their fields, such as installing a new irrigation system.

To address farmers' needs, this project aims to provide a system capable of gathering information from multiple sources and offering remote control of certain devices in the field. More importantly, the system must be reliable for long-term use and feasible enough for farmers to acquire or build.

\section{System Design and Feasibility Analysis}
\subsection{Stakeholder Need Analysis}
    \begin{table}[h]
    \centering
    \begin{tabular}{|p{5cm}|p{10cm}|}
         \hline
         \textbf{Title} &  \textbf{Description} \\
         \hline
         Desired UV Level & The system should be able to withstand exposure to sunlight. \\
         Heating and Cooling & The system should be able to endure high temperatures. \\
         Number of Peripherals (Peripheral Types) & I prefer not to use any additional peripherals or devices to connect to the system. \\
         Number of People Required & I want to install and maintain the system by myself. \\
         Number of Tools Required (Tools Supported) & I want to install it with basic tools, such as a power drill and Phillips screws. \\
         Maximum Wind Speed Supported & The system should be stable and not be knocked over by the wind. \\
         Auto-Restart Mechanism (Emergency or Fail-Safe Mode) & The system should be able to reboot automatically in case of a malfunction. \\
         Number of Vendors (Parts Availability) & If a part fails, I want to be able to replace it with something readily available on the market. \\
         Number of Sensors Offered (Sensor Types) & The system should measure wind, sunlight, rain, and soil moisture levels in the field. \\
         Budget & I have a budget of \$1000 for this project. \\ 
         & I do not want to pay any monthly subscription fees for using or operating the system. This should be a one-time investment. \\
         Parts Recycling & I want to reuse some of the parts I already have on the farm, such as solar equipment or electrical wiring. \\
         \hline
    \end{tabular}
    \caption{Stakeholder Needs Capture}
    \label{tab:my_label}
\end{table}
\newpage


\subsection{Feasibility Analysis}
\subsubsection{Operating and Deploying Farming Drones}

With this solution, farmers only need to focus on specific fields and their crops. Purchasing drones can assist with multiple farming activities such as remote imaging, crop watering, and seeding. In short, the drone would use aerial imaging to capture crop health and monitor water usage. When acquiring a farming drone, users are often expected to use the images to identify unhealthy spots, such as areas with water shortages or fertilization issues. This is part of precision farming, which involves using images and mapping to create a farm's topology, crop types, and drainage patterns. A management platform supported by the vendor's software is typically included at no extra charge, along with training via software simulations and an analytics platform. However, maintaining and repairing the drone requires vendor experts, leaving farmers unable to maintain it themselves. The risk of system downtime is high due to crashes or hardware and software malfunctions. According to some drone experts, drones require stable weather conditions to safely take off and land. Additionally, operating a drone may require farmers to obtain permits in some regions. Finally, the initial investment costs are high, which may be prohibitive for many farmers.

\subsubsection{Control-Based Station}

This solution connects users to control irrigation systems and notifies them when crops need care. Farmers can verify the situation by logging into a monitoring system and predicting if water is needed in the field. Manual labor is still required to work in parallel with the system. Using time series metrics along with image snapshot to observe changes in the field. Tasks such as installing sensors, updating the system for new sensor types, and self-diagnosis in case of malfunction will be needed. The skills required to operate the system can vary depending on the system's complexity as designed. The result would be a central hub where data is processed, and the system should accept user inputs to send actions to the field.

\subsubsection{Image Capturing with AI Integration}

Using AI to monitor field conditions is being developed alongside IoT solutions. Two approaches are available: deploying a robot to scan the programmed field or installing a camera station pole. With the first approach, users need to acquire a robotic product from a company to deploy in the field. Although this solution is meant to reduce manual labor, features such as scanning the soil and crops via computer vision can determine necessary actions and provide live updates for farmers. However, the mechanical parts of the robot depend heavily on the vendor. Most robot parts are custom-made for improved productivity and efficiency, making them expensive and difficult to replace. Skill gaps would pose a significant challenge, as farmers would require specialized training to operate the robots, which involves knowledge from a different field.

The second approach, the Remote Image Capture System (RICS), uses a camera station where images are captured and stored over time. Data is then sent and transformed to fit into a data pipeline—a process known as "ETL" (Extract, Transform, Load). The issue here is that although data extraction can happen on-site, the transformation and loading for analytics often require cloud services, as they are CPU-intensive and energy-demanding. AI tasks such as computer vision are also typically processed in the cloud rather than on-site. If cloud services are utilized, users should expect monthly operational costs. Worse still, this system cannot achieve bidirectional communication. While this system helps predict field conditions, it lacks an interface for remote environmental control. Research suggests that AI-capable IoT devices are not yet widespread due to the lack of popularity of AI hardware for such devices. Therefore, the term "EDGE AI" could be misleading, as it suggests that AI can be easily deployed in a farming environment. In reality, devices on the farm primarily collect data, which is processed at remote locations where more energy is available and communication latency is lower.

\par When comparing alternatives, key evaluation criteria could include \textbf{initial acquisition cost, required skills, maintenance, and the ability to modify}. The next section will be using the multi-criteria decision-making method to find a feasible solution of the alternatives.

\subsection{Multi Criteria Decision making (AHP method).}
\includepdf[pages=-]{AHP.pdf}  % Include all pages of the PDF

\newpage

\subsection{Operational Requirement}
The design of the control base system should follow the following requirements to meet the customer's needs.

\textbf{Mission Definition:} Deliver a system that is capable of providing an observatory and accepting control input from users (farmers, homesteaders).
\section*{Functional Requirements}
\begin{itemize}
    \item \textbf{Req}: System must provide coverage of 1,000 square feet.
    \item \textbf{Req}: The system should be able to turn on or turn off irrigation pumps.
    \item \textbf{Req}: System must be able to support the following wireless communication protocols: LORA, WiFi 2.4GHz, WiFi 5.0GHz.
    \item \textbf{Req}: Farmers should receive updated data every 3-5 minutes.
    \item \textbf{Req}: Farmers should be able to view weather data daily.
    \item \textbf{Req}: The system must be exposed to UV sunlight.
    \item \textbf{Req}: The system can operate in outdoor environments below 100°F.
    \item \textbf{Req}: The system can withstand 40 mph - 50 mph wind speed.
    \item \textbf{Req}: System must support being connected over-the-air.
    \item Enable remote access protocol.
    \item \textbf{Req}: System should take less than 30 minutes to mount.
    \item \textbf{Req}: System only allows 90 minutes downtime.
    \item \textbf{Req}: System should take 90 minutes to install software for the system.
    \item \textbf{Req}: System must take two hours to deploy.
    \item \textbf{Req}: System must be able to operate without grid electricity.
    \item \textbf{Req}: The system must measure factors such as UV radiation, wind speed, wind direction, rainfall, and soil moisture.
    \item \textbf{Req}: System must support mobile devices.
    \item \textbf{Req}: The system must automatically restart when a malfunction is detected.
    \item \textbf{Req}: The chance of the system going down must be less than 10 percent.
\end{itemize}

 \section*{Economic Factors}
    \begin{itemize}
    \item \textbf{Req}: Annual operation cost should not exceed \$200.
    \item \textbf{Req}: System parts or modules must be available on the market for the next 5 years.
    \item \textbf{Req}: About 80 percent of the parts should be recyclable or reused.
    \item \textbf{Req}: The system should last more than a 5-year lifespan.
    \item \textbf{Req}: The parts can be salvaged with a price of 30 percent of the initial purchasing cost.
\end{itemize}

\section*{Design Constraints}
\begin{itemize}
    \item The system’s weight must be below 50 pounds.
    \item \textbf{Req}: It should be built within a \$1000 budget.
\end{itemize}

\section*{Operational Life Cycle}
\begin{itemize}
    \item \textbf{Req}: System parts or modules must be available on the market for replacement.
    \item \textbf{Req}: About 80 percent of the parts should be recyclable or reused.
\end{itemize}

\section*{Non-Functional Requirements}
\begin{itemize}
    \item Latency for farmers to access the system is 0-30 seconds.
    \item System must provide data redundancy.
    \item Data will be collected for a 3-year period.
    \item Data must be transmitted securely over the air.
\end{itemize}


\subsection{System Maintenance and Support - WIP} 

\begin{itemize}
\item Organizational Responsibility:
\begin{itemize}
    \item During the interaction with the system, farmers or users should not be exposed to more than 12 V or face potential hazards. 
    \item Record the vendor insurance information on the system so users can access them anytime.
    \item The User is responsible for the upkeep of the software stack of the system. There are two stacks of software which are system software and community software. The system software is rarely updated, is used to power the system, and connects all external systems such as sensor nodes and power systems. Community software is supported and provided by an open-source community. At the time this system is built, it only performs the features expected as in the requirement mentioned above. If users prefer the newer version of community software, they have to provide an internet connection and perform the update manually. Refer maintenance level level for further guidelines.
    \end{itemize}
    \item Maintenance level: To maintain and sustain the system the following procedures are required.
    \begin{itemize}
        \item For corrective maintenance: Calibrate the interval of sensors to produce data when missing data is found over months. 
        \item For preventive maintenance: System is exposed to UV environment, apply weatherproof coating paint every 5 years. Inspect potential leaks that can damage the electrical system. Because the system is mounted 4ft from the ground, inspect the foundation to know if it can be safe from falling.
        \item For predictive maintenance: Although this is introduced a new level of complexity, if the changes in of component of system rapidly, consider establish a guideline. "A supervised method to detect faults was proposed by [20]. The approach assumes that the correlation between the variables of the system changes due to equipment’s failure." 
        \item If the system is damaged by collision with the environment check the deformation that makes the system not waterproof or rainproof.       
        \item System should have an indicator to describe the level of error such as LED blinking, beeping signal, and display of error on devices.
        \item If the power system fails to support the system 24/7, inspect the equipment. 
            \begin{itemize}
                \item For the solar system, adjust the angle of sunlight or consider moving the system to a new location, avoiding shade level. Inspect if the system can produce enough energy to support computer components.
             \item For the wind system, check the charge controller voltage to see if the turbine can produce enough electricity.
                \item Revise the system, routinely to make sure the battery is operating in a safe environment to ensure charging and discharging.
            \end{itemize}
        \item There are software updates for computer systems. Users are responsible for providing an internet connection to provide over-air updates. There is a potential risk that new updates can brick the system and may require the user to re-install the system at the bare-bone level. While a fall-back mechanism might be provided, consider backing up the system if the new update fails to operate. A backup utility would be provided for the backup system. Please note that the utility would be built into with system therefore, the system must be in operation to perform backup.
        
    \end{itemize}
  \item Repair Policy: 
  \begin{itemize}
  \item The following parts can be repaired:  soil sensors, computer system, and system enclosure.
  \item The following parts should be replaced: the weather station system, the battery for the solar system, LED bulb.

  \end{itemize}
 
\item Effectiveness Requirement: Because the system uses sensors with WiFi communication, it allows the system to be built and assembled easily, as farmers can purchase these parts at a low price. Additionally, the availability of various models is not a concern, as WiFi-based sensor systems are among the most popular on the market. This off-the-shelf solution helps reduce the cost of specialized weather-related sensors and the pool of devices is large to pick. Since this is an off-grid system, a portable power station should be provided to perform installation and troubleshooting while in the field. This should act as a temporary data source to assist the installation and maintenance process.  Also,  Costs for upgrading should only be tied to new parts without modification of the current design.
\end{itemize}
\newpage


\section{Analyze System Behavior}
\subsection{House of Quality}
To translate and communicate with stakeholders (farmers), a House of Quality (HoQ) is recommended to aid the design process. 

\begin{figure}[H] % 'H' ensures the figure stays where you place it
    \centering
    \includegraphics[trim=0 0 0 0, clip, width=\textwidth]{QFA-House of Quality.pdf} % Adjust the width (50% of text width here)
    \caption{N-Square Level 2}
    \label{fig:your-label}
\end{figure}
\subsection{Function Hierarchy}


\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{FFBD-architecture.png} % Adjust width to fit the page
    \caption{Functional Architecture} % Add a caption for the image
    \label{fig:ffbd-architecture} % Label for referencing the image
\end{figure}
\subsubsection{Functional Flow Block Diagram (FFBD)}
\subsubsection*{Level 1 - FFBD}
\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{FFBD-Level1-1.png} % Adjust width to fit the page
    \caption{ \textbf{1. Deploy System - FFBD}} % Add a caption for the image
    \label{fig:ffbd-architecture} % Label for referencing the image
\end{figure}
\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{FFBD-Level1-2.png} % Adjust width to fit the page
    \caption{ \textbf{2. Capture Outdoor  - FFBD}} % Add a caption for the image
    \label{fig:ffbd-architecture} % Label for referencing the image
\end{figure}
\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{FFBD-Level1-3.png} % Adjust width to fit the page
    \caption{ \textbf{3. Provide Digital Information - FFBD}} % Add a caption for the image
    \label{fig:ffbd-architecture} % Label for referencing the image
\end{figure}

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{Level 1- Control Irrigration.png} % Adjust width to fit the page
    \caption{ \textbf{4.0 Control Irrigration.}} % Add a caption for the image
    \label{fig:ffbd-architecture} % Label for referencing the image
\end{figure}

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{Level 1-Maintenance and Prevention.png} % Adjust width to fit the page
    \caption{ \textbf{5.0 Maintenance and Prevention.}} % Add a caption for the image
    \label{fig:ffbd-architecture} % Label for referencing the image
\end{figure}

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{FFBD-Level2-CaptureOutdoor.png} % Adjust width to fit the page
    \caption{ \textbf{2.1 Measure Outdoor - FFBD}} % Add a caption for the image
    \label{fig:ffbd-architecture} % Label for referencing the image
\end{figure}

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{FFBD-Level2-DetectWaterNeed.png} % Adjust width to fit the page
    \caption{ \textbf{4.1 Detect Water Need - FFBD}} % Add a caption for the image
    \label{fig:ffbd-architecture} % Label for referencing the image
\end{figure}

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{FFBD-Level2-SystemFailureDetection.png} % Adjust width to fit the page
    \caption{ \textbf{1.3 Detect System Failure - FFBD}} % Add a caption for the image
    \label{fig:ffbd-architecture} % Label for referencing the image
\end{figure}
\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{FFBD-Level2-ETL.png} % Adjust width to fit the page
    \caption{ \textbf{2.2 ETL - FFBD}} % Add a caption for the image
    \label{fig:ffbd-architecture} % Label for referencing the image
\end{figure}
\newpage
\subsection{N-Square Diagram}

\begin{figure}[H] % 'H' ensures the figure stays where you place it
    \centering
    \includegraphics[trim=0 430 0 50, clip, width=\textwidth, height=6cm]{N Square Diagram - Level1.pdf} % Adjust the width (50% of text width here)
    \caption{N-Square Level 1}
    \label{fig:your-label}
\end{figure}


\begin{figure}[H] % 'H' ensures the figure stays where you place it
    \centering
    \includegraphics[trim=0 400 0 40, clip, width=\textwidth,height=12cm]{N Square Diagram - Level2.pdf} % Adjust the width (50% of text width here)
    \caption{N-Square Level 2}
    \label{fig:your-label}
\end{figure}
\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth, page=1]{N Square Diagram - Level 3.pdf}
 
\end{figure}

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth, page=2]{N Square Diagram - Level 3.pdf}
\end{figure}

\begin{figure}[H]
    \centering
    \includegraphics[trim=0 100 0 0 , clip, width=\textwidth, page=3]{N Square Diagram - Level 3.pdf}
 \caption{N-Square Level 3}
    \label{fig:your-label}
\end{figure}

\newpage
\subsection{Function Allocation}

\begin{figure}[H] % 'H' ensures the figure stays where you place it
    \centering
      \caption{Function Allocation}
    \includegraphics[trim=0 10 0 40, clip, width=1\textwidth]{Function Allocation.pdf} % Adjust the width (50% of text width here)
  
    \label{fig:your-label}
\end{figure}
\subsection{Functions Description}

\par The Figure provided above is a recursive processes to map out the parent and child relationship. Through mutiple iteration, we soon ables to capture the interfaces of input and out of lowest level of sub processes ( level 4). To further the decomposition process, and with tools we can focus on and input and output of these processes or function. For such task we can use Function Allocation table to break down the input and output between functions, and more importantly, constraints and mechanism of them. At this phase, in order to conclude such table, we have to adapt the "Product Realization phases", which include three optional process activities which are purches, make/code, and reuse. In simple term, resources are the one used to consume our inputs. Therefore, as long as the resources or product listed able to consume required input and produced expected output, we can list them as mechanism and resources  needed for that process. Ideally this resources soon will be components should perform multiple function. If new function requirement added this component should be resued. Next section would be explained how we group these components and generate hierarchy structure and group them as packages. With new structure we have tracebility of life cycle of the project.

\section{Analyze Physical Architecture - Components extracted from Function Allocation}
\subsection{Physical Component Hierarchy}
\begin{figure}[p]
    \centering
    \includegraphics[trim=0 10 0 40, clip,width=0.8\textwidth,height=\textheight]{Physical Architecture.png} % Adjust width to fit the page
    \caption{ \textbf{Physical Hierarchy of Components}} % Add a caption for the image
    \label{fig:ffbd-architecture} % Label for referencing the image
\end{figure}
\newpage
\susection{Researching the Components}
\par As we research the components to meet the functions requirement, there are multiple parts or components that were picked and tested to assure the function performence. However, the function should perform to meet the requirments deprived from the stakeholder. In general, this control based station relies on moisture sensors to conclude the water need. 
\par Another aspect that is conducted in this research in indtroducing open source software to prolong our system. Cloud Native computing  is a approach and an architecture where we want to build and design software for dynamic environment of public cloud and private cloud. To follow such priciple the application have to be  loosely coupled systems that are resilient, manageable, and observables. Why the concept expands to many benefits for organizations adapt this arhictecture, yet me focus on the goodness of this architecture which is easy to maintain, reliable and portable. These three factors are known of as three of six goodness introduced in system engineering. For maintainability, cloud native can help application to me patched by me community where softwared can be shipped and installed with different verion pulled from reliable source of software. As for reliability, self healing feature that can detect software or application failure to restart and recreate. Not only that, automantion in replication of software can significantly improve the uptime of the application. The last part is . As mention above this component is aimed to meet the uptime and reliabiilty requirment above "The system must automatically restart when a malfunction is detected" and " The chance of the system going down must be less than 10 percent".
\par Just like functions, there are flows in components as well. More precisely, components communicate with each other and therefore we should structure them in term of internal and external structure. The physical component hierach above is not one time activities. It is structured based on the growth of communication of components. Preferably we want the component to communicate within it packages (one uppper level) and external compoents would have their own level to communicate. To do so we can group them based on geographicaly location, a common environment, and similiarity system. 
\subsection{N-Diagram of Component Flow}
 \begin{figure}[H] % 'H' ensures the figure stays where you place it
    \centering
      \caption{Physical Component Flow - Level 2}
    \includegraphics[trim=0 400 0 40, clip, width=1\textwidth]{Physical Architecture (Level 2).pdf} % Adjust the width (50% of text width here)
  
    \label{fig:your-label}
\end{figure}
 \begin{figure}[H] % 'H' ensures the figure stays where you place it
    \centering
      \caption{Physical Component Flow - Level 3}
    \includegraphics[trim=0 600 0 40, clip, width=1\textwidth]{Physical Architecture (Level 3).pdf} % Adjust the width (50% of text width here)
  
    \label{fig:your-label}
\end{figure}

 \begin{figure}[H] % 'H' ensures the figure stays where you place it
    \centering
      \caption{Physical Architecture Flow - Level 4}
    \includegraphics[trim=0 10 0 40, clip, width=1\textwidth]{Physical Architecture (Level 4).pdf} % Adjust the width (50% of text width here)
  
    \label{fig:your-label}
\end{figure}
\subsection{Shipping components for Functions}
After generating the compoents matrix above, we have to recall the principle "design to requirement", therefore
\subsubsection{System Component Analysis for  Wireless Communication}
\begin{table}[h]
    \centering
    \begin{tabularx}{\textwidth}{|p{3cm}|p{3cm}|p{2cm}|p{3cm}|p{4cm}|}
        \hline
        \textbf{Technology} & \textbf{Frequency Bands}                                   & \textbf{Latency}               & \textbf{Power Consumption (mW)} & \textbf{Data Size (Max)} \\ \hline
        LoRa                & 433 MHz (Asia), 868 MHz (Europe), 915 MHz (North America) & 10s to 1min (depending on range) & 10 - 50                            & 250 - 10,000 bytes (per message) \\ \hline
        ESP-NOW             & 2.4 GHz ISM band (same as Wi-Fi 2.4 GHz)                  & ~100 ms                         & 80 - 150                           & Up to 250 bytes (per message)       \\ \hline
        Wi-Fi 2.4 GHz       & 2.4 GHz (2.412 GHz to 2.472 GHz)                          & ~1-50 ms                        & 100 - 300                          & Up to 2,000,000 bytes (per packet)    \\ \hline
        Wi-Fi 5.0 GHz       & 5 GHz (5.150 GHz to 5.825 GHz)                            & ~1-20 ms                        & 150 - 500                          & Up to 2,000,000 bytes (per packet)    \\ \hline
    \end{tabularx}
    \caption{Frequencies, Latency, Power Consumption, and Data Size of Various Wireless Communication Technologies}
    \label{tab:wifi_frequencies}
\end{table}
\end{document}

