diff --git a/Component-hierachy.png b/Component-hierachy.png new file mode 100644 index 0000000..a0cb7b0 Binary files /dev/null and b/Component-hierachy.png differ diff --git a/Conclusion.tex b/Conclusion.tex new file mode 100644 index 0000000..7d304da --- /dev/null +++ b/Conclusion.tex @@ -0,0 +1,6 @@ +\section{Conclusion and Future-work} +\par This thesis has achieved several key goals: identifying the problem, establishing system requirements, modeling system behavior and structure, and designing a component-level mock-up. Based on the requirements provided above, if the Based Station System is in acquisition phase, farmers should be able to monitor their 1000 sqrt farming area without the need of public utilities such as internet and cloud services. Farmers have this build to last for 10 years lifespan to support their irrigration activity. While this approach can drive the system toward implementation, it is still limited by the scope of stakeholder-defined requirements. If the number of requirements exceeds 30 items, the document-based method may become insufficient for maintaining full traceability. + +It is also important to recognize that diagrams are inherently limited—they primarily represent behavioral and structural aspects. When components are swapped or modified, the relationships or flows between functions may be disrupted. In other words, physical part changes often require updates to the model to reflect new interactions or data paths. + +There is a need for a Model-Based Systems Engineering (MBSE) approach, which provides a standardized framework for defining structure and relationships if the number of component in Physical Architecture increase. MBSE also supports function decomposition and component allocation, just as traditional document-driven methods do. It offers additional benefits in terms of model reusability and traceability, especially when the number of stakeholders or requirements grows. In such cases, adopting SysML may be advantageous, as it encourages careful parameter definition in the early stages (black-box) model building for supporting long-term traceability and system evolution. With Back-box model, It exposes the features of the system that are visible from an external observer and hides the internal details of the design (\cite{sebokwiki_typesofsystems}). A white-box model of a system, on the other hand, shows the internal structure and displays the behavior of the system. Utilizing the black and white box module can enhance function decomposition since external environment is accounted and addressed how system perform in different environment. diff --git a/FFBD-Function-Architecture.png b/FFBD-Function-Architecture.png new file mode 100644 index 0000000..621bd93 Binary files /dev/null and b/FFBD-Function-Architecture.png differ diff --git a/FFBD-Level1- Provide Digital Information.png b/FFBD-Level1- Provide Digital Information.png new file mode 100644 index 0000000..9f6b66a Binary files /dev/null and b/FFBD-Level1- Provide Digital Information.png differ diff --git a/FFBD-Level2- Measure Outdoor Environment.png b/FFBD-Level2- Measure Outdoor Environment.png new file mode 100644 index 0000000..2390d98 Binary files /dev/null and b/FFBD-Level2- Measure Outdoor Environment.png differ diff --git a/FFBD-architecture.png b/FFBD-architecture.png deleted file mode 100644 index 7d38940..0000000 Binary files a/FFBD-architecture.png and /dev/null differ diff --git a/Function Allocation.pdf b/Function Allocation.pdf deleted file mode 100644 index 65989ca..0000000 Binary files a/Function Allocation.pdf and /dev/null differ diff --git a/Function Component Matrix.pdf b/Function Component Matrix.pdf new file mode 100644 index 0000000..a136043 Binary files /dev/null and b/Function Component Matrix.pdf differ diff --git a/Function-Allocation.tex b/Function-Allocation.tex new file mode 100644 index 0000000..c298502 --- /dev/null +++ b/Function-Allocation.tex @@ -0,0 +1,81 @@ +\tablehead{\toprule Function & Input & Output & Constraints & Mechanism/Resources \\\midrule} +%\begin{supertabular}{|p{3cm}|p{3cm}|p{3.2cm}|p{3cm}|p{3.8cm}|} +\begin{supertabular}{|L{3cm}|L{3cm}|L{3.2cm}|L{3cm}|L{3.8cm}|} + +\hline +1.1 Pre assemble parts & Parts (Battery, Panel, Charge Controller, Frame, Enclosures) & Pre-built set & Assembling Time & Staff (Human), Installation Kit \\ +\hline +1.2.1 Mount the assembly & Pre-built set & Mounted Station & Assembling Time, Height & Staff, Installation Kit \\ +\hline +1.2.2 Inspect Mounting Equipment & Assembled System & Hardware ready system & Time of the Day & Staff, Test Tools \\ +\hline +1.3.1 Install Base Image & SD card, USB, internet, disk image & Bootable System & Disk Size & Staff, Image Burner Software, Software Repository \\ +\hline +1.3.2 Config new image & Network Config & WiFi Enabled & CPU Load, Interfaces Availability & Staff, Mini Computer, Config File \\ +\hline +1.3.3 Add Update Over Air & Outdated Software & Installed New Version & & Internet, Update Control (Software Repository), Computer, Real-time Clock \\ +\hline +1.4 Perform Ventilation & Heat flow & Heat flow & Air throughput, Fan Speed & Fan, Passive Cooling \\ +\hline +2.1.1 Measure Windspeed & Wind, Power & Wind Speed & Wind Speed, 1 Year Power Supply & Wind Turbine Sensors, Battery \\ +\hline +2.1.2 Measure Soil Moisture & Soil, Power & Soil Wetness & Water Flood Level, 1 Year Power Supply & Soil Moisture Sensors, ESP32, Batteries \\ +\hline +2.1.3 Measure Humidity & Humidity, Power & Humidity Measure (Percentage) & 1 Year Power Supply & Humidity Measure Sensors, Battery \\ +\hline +2.1.4 Measure Wind Direction & Wind, Power & Wind Direction & Maximum Windspeed, 1 Year Power Supply & Battery, Direction Sensor \\ +\hline +2.1.5 Measure Temperature & Temperature, Power & Temperature Reading & 1 Year Power Supply & Battery, Indoor Sensors, Outdoor Sensors \\ +\hline +2.1.6 Measure Rainfall & Rain, Power & Rain Fall Rate & 1 Year Power Supply & Battery, Rain Collector \\ +\hline +2.1.7 Measure UV & Sunlight, Power & UV Reading & 1 Year Power Supply & Battery, UV Panel \\ +\hline +2.2.1 Extract & Windspeed, Soil Wetness, Wind Direction, Temperature Reading, Rain Fall Rate, UV Reading & Signal Flow & CPU Load, Memory & Sensor Sets, Wireless Networking, Edge Computer \\ +\hline +2.2.2 Transform & Signal Flow & JSON & CPU Load, Memory & Node-Red Software, Edge Computer \\ +\hline +2.2.3 Load & JSON & Service Info Dashboard & CPU Load, Memory & Database Software, Data Preview Software \\ +\hline +3.1.1 Preview Environment Info & Service Info Dashboard & & CPU Load, Memory & Webserver, Mini Computer, Preview Software, Mobile Device \\ +\hline +3.1.2 Preview Maintenance Info & Inspection Log & Web Maintenance Log Preview & CPU Load, Memory, Staff (1 user minimum) & Staff, Webserver, Mobile Device \\ +\hline +3.2.2 Give System Access & User Credential & Authorization & Session Limit & Wireless Interface (Enable Access Point), Mobile Device \\ +\hline +3.2.1 Create Ad-hoc Network & Enable Command & Live Network & Range, Starting Time & Script to Run, Wireless Interface, Wireless Software (Enable Access Point) \\ +\hline +3.3.1 Built In-house Service for Tracking & Network Usage Info, Expense Info & Graph of Network Usage, Tables of Expenses & CPU Load, Memory & Cloud Native Stack, CNI Container Engine Software \\ +\hline +3.3.2 Track Network Usage & Network Bandwidth & Measured Usage & CPU Load, Memory & Network Service (Grafana) \\ +\hline +3.3.3 Track Monthly Expense & Expense Number & Measured Expense & CPU Load, Memory & Staff, Webservice (Expense Tracking Service), CRUD Web App \\ +\hline +3.3.4 Check Part Availability & Inventory Web Data from Vendor, Parts Log & Part Report & Production Rate, Vendor Commitment on Part & Staff \\ +\hline +3.3.5 Track Warranty Duration & Warranty Info, Parts Number & Duration of Warranty, Type of Warranty & Maximum Number of Parts (65) & Staff, Object Storage, Web Service \\ +\hline +4.1.1 Check Moisture Level & Soil Wetness, Rainfall Rate & Wetness Level & Water Level & Soil Moisture Sensors \\ +\hline +4.1.2 Predict Water Reservoir & Water Level & True/False & Water Max & Staff, ET Formula Prediction Model refer. \ref{appendix:supp_material} for Multi Linear Regression Model \\ +\hline +4.2.1 Connect Wireless Network & Network Name/Type & Connection Session & Power Control, Range & Staff, Wireless Modem, Edge Computer \\ +\hline +4.2.2 Send Turn On Signal & True/False & Status of Valve & Time to Complete & Smart Water Valve \\ +\hline +5.1 Detect System Failure & Error Code & Error Code, Beep Sound, Light Indicator & Time to Live Signal & Status Report, Wireless Network, LED Bulb, Mini Speaker \\ +\hline +5.2.1 Generate User Input & User Input & Input Template Form & Session Number, CPU Load & Web Framework, Form Generator \\ +\hline +5.3.1 Collect Parts Handbook & Handbook Digital Form & PDF Files, HTML Files & 10G Storage & Staff, On-site Digital Storage \\ +\hline +5.3.2 Classification Inspection Type & Inspection Info & Inspection Type Report & Inspection Log & Staff \\ +\hline +5.3.3 Classification Maintenance Type & Inspection Info & Maintenance Type Report & Maintenance Type & Staff \\ +\hline +5.3.4 Record Condition of System & User Input & System Status & Session Number, CPU Load & Staff, Webservice (Dashboard Control) \\ +\hline +\end{supertabular} + +\input{function-description} + diff --git a/Functional Archiecture.tex b/Functional Archiecture.tex new file mode 100644 index 0000000..4f451b8 --- /dev/null +++ b/Functional Archiecture.tex @@ -0,0 +1,246 @@ +\section{Analyze System Behavior} +\subsection{Function Hierarchy} +\par After confirming HoQ, it is essential to map out functions that are respond to the requirements. Parent and child relationship would be used in this phase. +\begin{figure}[H] + \centering + \includegraphics[width=\textwidth]{FFBD-Function-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} +\subsection{Functional Flow Block Diagram (FFBD)} +\subsubsection*{Level 1 - FFBD} +At the first iteration, it's not important to consider the inner input and out of the functions, but what steps or phases come next \cite{wikibooks2023}. +\begin{figure}[H] + \centering + \includegraphics[width=\textwidth]{FFBD-Level1-1.png} % Adjust width to fit the page + \caption{ 1. Deploy System - FFBD} % Add a caption for the image + \label{fig:ffbd-level1-deploy} % 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{2. Capture Outdoor - FFBD} % Add a caption for the image + \label{fig:ffbd-level2-capture} % Label for referencing the image +\end{figure} + +\begin{figure} + \centering + \includegraphics[width=\textwidth]{FFBD-Level1- Provide Digital Information.png} + \caption{3. Provide Digital Information} + \label{fig:enter-label} +\end{figure} + +\begin{figure}[H] + \centering + \includegraphics[width=\textwidth]{Level 1- Control Irrigration.png} % Adjust width to fit the page + \caption{4.0 Control Irrigration.} % Add a caption for the image + \label{fig:ffbd-control-irrigration} % Label for referencing the image +\end{figure} + + +\input{maintenance} +%\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- Measure Outdoor Environment.png} + \caption{2.1 Measure Outdoor Environment} + \label{fig:enter-label} +\end{figure} + +\begin{figure}[H] + \centering + \includegraphics[width=\textwidth]{FFBD-Level2-DetectWaterNeed.png} % Adjust width to fit the page + \caption{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{ 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{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} +\par After completing the functional flow block diagram, we need to defind what are the flows comming through our functions \cite{sebokwiki_typesofsystems}. We can use N-Square diagram to convey the content of the flow as well of its direction. If component doesn't have the communication with other component in the same level it would not appear, rather the upper level of boundary would express the communication. +\begin{figure}[H] % 'H' ensures the figure stays where you place it + \centering + \includegraphics[trim=0 430 0 50, clip, width=\textwidth, height=4cm]{N Square Diagram - Level1.pdf} % Adjust the width (50% of text width here) + \caption{N-Square Level 1} + \label{fig:N-square-level 1} +\end{figure} +With FFBD completed, the next step is defining flows that occurs between functions in the system (SEBoK Wiki, 2025). To visualize this, we use the N-Square Diagram, it represent content and direction of information exchanged between functions. + +Figure \ref{fig:N-square-level 1} illustrates the Level 1 N-square diagram representing the data exchanges between functions. For example, the function "Capture Outdoor Environment" communicates with "Maintenance and Prevention" by sensor status codes. It shows the information flows only from "Capture Outdoor Environment" to "Maintenance and Prevention". Similarly, the "Capture Outdoor Environment" function also interacts with "Provide Digital Information", transmitting data such as HTML outputs and database logs. + +This diagram defines how the components interact and convey abroad communication view of each layer. This is repetitive process, proceed with layer 2 functions, with a clear marking for the communication flows. These are important steps for picking component of systems since it refelct required flow and information needed for the component. + + +\begin{landscape} +\begin{table}[H] +\renewcommand{\arraystretch}{0.7} +\centering +\caption{N-Diagram Level 2 for 1.0 Deploy Assembly} +{ % Begin scriptsize block +\small +\begin{tabularx}{\linewidth}{|X|X|X|X|X|X|X|} +\hline +\textbf{1.1 Pre-assemble Parts} & pre-built set & & & & & \\ +\hline +& \textbf{1.2 Deploy the Preassembled Parts} & & & & & \\ +\hline +& & \textbf{1.3 Install Embedded Software} & & & & \\ +\hline +& & & \textbf{1.4 Add Enclosures} & & & \\ +\hline +& & & & \textbf{1.5 Power Assembly} & & \\ +\hline +& & & & & \textbf{1.6 Power Remote Valve} & \\ +\hline +& & & & & & \textbf{1.7 Power Sensors} \\ +\hline +\end{tabularx} +} % End scriptsize block +\end{table} + +\begin{table}[H] +\renewcommand{\arraystretch}{0.6} +\centering +\caption{N-Diagram Level 2 for 2.0 Measure Outdoor Environment and 3.0 Provide Digital Information} +{ % Begin scriptsize block +\scriptsize +\begin{tabularx}{\linewidth}{|X|X|X|X|X|X|X|X|X|X|} +\hline +\textbf{2.1 Measure Outdoor Condition} & low-power signal & & & & & & & & \\ +\hline +& \textbf{2.2 ETL} & & & & & & & & \\ +\hline + & & \textbf{3.1 Preview Data} & HTML & & & & & & & \\ +\hline + & & & \textbf{3.2 Provide Mobile Services} & & & & & & & \\ +\hline +& & Expense Log, Maintenance Log & & \textbf{3.3 Gather and Manage Resources} & & & & & & \\ +\hline +& & & & & \textbf{4.1 Detect Water Need} (True/False) & & & & & \\ +\hline +& & & & & Water Output & \textbf{4.2 Request Water Need} & & & \\ +\hline +& & Null or Data (error code) & & & & & \textbf{5.1 Detect System Failure} & (Error Code, Alert) & \\ +\hline +& & & & Maintenance Log & & & & \textbf{5.2 Create Maintenance Logging} & \\ +\hline +& & Maintenance Log & &Warranty Info& Warranty Info& & & Warranty Info& \textbf{5.3 Schedule Preventive Maintenance/Inspection} \\ +\hline +\end{tabularx} +} % End scriptsize block +\end{table} + +\begin{table}[H] +\renewcommand{\arraystretch}{0.7} +\centering +\caption{N-Diagram Level 3 for 3.2 Provide Mobile Services} +{ % Begin scriptsize block +\scriptsize +\begin{tabularx}{\linewidth}{|X|X|} +\hline +\textbf{3.2.1 Create Ad-hoc Network} & check connectivity \\ +\hline +& \textbf{3.2.2 Give System Access} \\ +\hline +\end{tabularx} +} % End scriptsize block +\end{table} + +\begin{table}[H] +\centering +\caption{N-Diagram level 3 for 1.2 Deploy the preassemble parts} +\begin{tabularx}{\textwidth}{|X|X|} +\hline +\textbf{1.2.1 Mount Assembly} & Mounting Size and Type \\ +\hline +Load or weight amount & \textbf{1.2.2 Inspect Mounting Equipment} \\ +\hline +\end{tabularx} +\end{table} + +\begin{table}[H] +\renewcommand{\arraystretch}{0.7} +\centering +\caption{N-Diagram Level 3 for 5.3 Schedule Preventive Maintenance/Inspection} +{ % Begin scriptsize block +\scriptsize +\begin{tabularx}{\linewidth}{|X|X|X|} +\hline +\textbf{5.3.1 Collect Parts Handbook} & Parts Type, Parts Number & Parts Type, Parts Number \\ +\hline +& \textbf{5.3.2 Classification of Inspection Type} & A, B, C \\ +\hline +& & \textbf{5.3.3 Classification of Maintenance Type} \\ +\hline +\end{tabularx} +} % End scriptsize block +\end{table} + +\begin{table}[H] +\renewcommand{\arraystretch}{0.7} +\centering +\caption{N-Diagram Level 3 for 3.3 Manage and Gather Resources} +{ % Begin scriptsize block +\scriptsize +\begin{tabularx}{\linewidth}{|X|X|X|X|X|} +\hline +\textbf{3.3.1 Built In-House Service for Tracking} & & & & & \\ +\hline +Graph & \textbf{3.3.2 Track Network Usage} & & & & \\ +\hline +Table & & \textbf{3.3.3 Track Monthly Expense} & & & \\ +\hline +Table & & & \textbf{3.3.4 Check Part Availability} & & \\ +\hline +Warranty Deadline & & & & \textbf{3.3.5 Check Warranty Duration} & \\ +\hline +\end{tabularx} +} % End scriptsize block +\end{table} +\end{landscape} + + + + +\subsection{Function Allocation} +\par The Figure \ref{fig:ffbd-architecture}: Functions Hierarchy, provided above is a recursive process to map out the parent-child relationship. Through multiple iterations, we soon can capture the interfaces of input and out of lowest level of sub-processes ( level 3). As next part of the 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 purchase, make/code, and reuse. In simple term, resources are the one used to consume our inputs. Therefore, as long as the resources or products listed are able to consume the required input and produce the expected output, we can list them as mechanisms 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 reused. The next section will explain how we group these components and generate hierarchy structure and group them as packages. With new structure we have traceability of function and resources for the project. + + \begin{table}[h] + \centering + \begin{tabular}{|l|l|} + \hline + Field & Description \\ \hline + Function & \textit{Processes, activities, reusable.} \\ \hline + Input & \textit{Information, material, flow going into function} \\ \hline + Output & \textit{Information, material, flow going out of function} \\ \hline + Constrain & \textit{Constrains applied on the function such as (policy,rules,material availability} \\ \hline + Mechanism & \textit{Method, assets to execute the functions. Can be viewed as resources} \\ \hline + \end{tabular} + \caption{Description of Function Allocation} + \label{tab:function_fields} +\end{table} + +\input{Function-Allocation} +%\input{predice-water} + +\newpage + +%\input{system-specification} diff --git a/Kubernestes-manifest-services.tex b/Kubernestes-manifest-services.tex new file mode 100644 index 0000000..6271265 --- /dev/null +++ b/Kubernestes-manifest-services.tex @@ -0,0 +1,585 @@ +%\documentclass[12pt]{article} +%\usepackage{geometry} +%\geometry{margin=1in} +%\usepackage{listings} +%\usepackage{setspace} % For setting line spacing +% +%\begin{document} +\newpage +\appendix % This command ensures correct section numbering + +\section*{APPENDIX A: SUPPLEMENTARY MATERIAL} % Main appendix title - all caps +\label{appendix:supp_material} % Label for the appendix + +\subsection*{A.1 Additional Data} % Sub-section within the appendix +\doublespacing % Apply double spacing here +The following code template are used to provide services for component of system mentions in table \ref{table:spec}. To modify the services and software, refer to next section for configuration. + +\begin{itemize} + \item A more detailed breakdown of experimental results. + \item Additional statistical analyzes. + \item Copies of survey instruments. +\end{itemize} +\singlespacing % Revert to single spacing if needed for other parts + +\subsection*{A.2 Code Template} +\lstset{ + language=bash, % Changed from 'none' to a specific language + caption=Kubernetes Deployment Template, + basicstyle=\ttfamily\footnotesize, + breaklines=true, + %numbers=left, % If you want line numbers + numberstyle=\tiny\color{gray}, % Style for line numbers + stepnumber=1, + numbersep=5pt, + frame=single, % Add a frame around the code + %backgroundcolor=\color{yellow!10}, % Light background color +} +\begin{lstlisting} +--- +# Deployment for Mosquitto +apiVersion: apps/v1 +kind: Deployment +metadata: + name: mosquitto-deployment + labels: + app: mosquitto +spec: + replicas: 1 + selector: + matchLabels: + app: mosquitto + template: + metadata: + labels: + app: mosquitto + spec: + containers: + - name: mosquitto-mqtt + image: eclipse-mosquitto + ports: + - containerPort: 1883 + - containerPort: 1990 + volumeMounts: + - name: mosquitto-config + mountPath: /mosquitto/config + - name: mosquitto-data + mountPath: /mosquitto/data + - name: mosquitto-log + mountPath: /mosquitto/log + volumes: + - name: mosquitto-config + persistentVolumeClaim: + claimName: mosquitto-config-pvc + - name: mosquitto-data + persistentVolumeClaim: + claimName: mosquitto-data-pvc + - name: mosquitto-log + persistentVolumeClaim: + claimName: mosquitto-log-pvc +--- +# Service for Mosquitto +apiVersion: v1 +kind: Service +metadata: + name: mosquitto-service + labels: + app: mosquitto +spec: + selector: + app: mosquitto + ports: + - name: mqtt + protocol: TCP + port: 1883 + targetPort: 1883 + - name: admin + protocol: TCP + port: 1990 + targetPort: 1990 + type: ClusterIP # Or NodePort, if you need external access +--- +# Persistent Volume Claims for Mosquitto +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: mosquitto-config-pvc +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 100Mi # Adjust as needed +--- +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: mosquitto-data-pvc +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi # Adjust as needed +--- +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: mosquitto-log-pvc +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi # Adjust as needed +--- +# Deployment for Home Assistant +apiVersion: apps/v1 +kind: Deployment +metadata: + name: home-assistant-deployment + labels: + app: home-assistant +spec: + replicas: 1 + selector: + matchLabels: + app: home-assistant + template: + metadata: + labels: + app: home-assistant + spec: + containers: + - name: home-assistant + image: "ghcr.io/home-assistant/home-assistant:stable" + ports: + - containerPort: 8123 + volumeMounts: + - name: hass-config + mountPath: /config + - name: hass-localtime + mountPath: /etc/localtime + securityContext: + privileged: true # Required for some Home Assistant features + volumes: + - name: hass-config + persistentVolumeClaim: + claimName: hass-config-pvc + - name: hass-localtime + hostPath: + path: /etc/localtime # Mount from the host +--- +# Service for Home Assistant +apiVersion: v1 +kind: Service +metadata: + name: home-assistant-service + labels: + app: home-assistant +spec: + selector: + app: home-assistant + ports: + - protocol: TCP + port: 8123 + targetPort: 8123 + type: ClusterIP # Or NodePort +--- +# Persistent Volume Claim for Home Assistant config +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: hass-config-pvc +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi # Adjust as needed +--- +# Deployment for Node-RED +apiVersion: apps/v1 +kind: Deployment +metadata: + name: node-red-deployment + labels: + app: node-red +spec: + replicas: 1 + selector: + matchLabels: + app: node-red + template: + metadata: + labels: + app: node-red + spec: + containers: + - name: node-red-container + image: nodered/node-red:latest + ports: + - containerPort: 1880 + volumeMounts: + - name: nodered-data + mountPath: /data + env: + - name: TZ + value: America/Los_Angeles + securityContext: + privileged: true + volumes: + - name: nodered-data + persistentVolumeClaim: + claimName: nodered-data-pvc +--- +# Service for Node-RED +apiVersion: v1 +kind: Service +metadata: + name: node-red-service + labels: + app: node-red +spec: + selector: + app: node-red + ports: + - protocol: TCP + port: 1880 + targetPort: 1880 + type: ClusterIP # Or NodePort +--- +# Persistent Volume Claim for Node-RED data +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: nodered-data-pvc +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi # Adjust as needed +--- +# Deployment for Grafana +apiVersion: apps/v1 +kind: Deployment +metadata: + name: grafana-deployment + labels: + app: grafana +spec: + replicas: 1 + selector: + matchLabels: + app: grafana + template: + metadata: + labels: + app: grafana + spec: + containers: + - name: grafana + image: grafana/grafana:latest + ports: + - containerPort: 3000 + volumeMounts: + - name: grafana-data + mountPath: /var/lib/grafana + env: + - name: GF_SECURITY_ADMIN_USER + value: admin + - name: GF_SECURITY_ADMIN_PASSWORD + value: password # Change this! Use a real password. + volumes: + - name: grafana-data + persistentVolumeClaim: + claimName: grafana-data-pvc +--- +# Service for Grafana +apiVersion: v1 +kind: Service +metadata: + name: grafana-service + labels: + app: grafana +spec: + selector: + app: grafana + ports: + - protocol: TCP + port: 3000 + targetPort: 3000 + type: ClusterIP # Or NodePort +--- +# Persistent Volume Claim for Grafana data +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: grafana-data-pvc +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 2Gi # Adjust as needed +--- +# Deployment for MinIO (Object Storage) +apiVersion: apps/v1 +kind: Deployment +metadata: + name: minio-deployment + labels: + app: minio +spec: + replicas: 1 + selector: + matchLabels: + app: minio + template: + metadata: + labels: + app: minio + spec: + containers: + - name: minio + image: minio/minio:latest + ports: + - containerPort: 9000 + - containerPort: 9001 + env: + - name: MINIO_ROOT_USER + value: minio + - name: MINIO_ROOT_PASSWORD + value: minio123 # Change this! Use a real password + volumeMounts: + - name: minio-data + mountPath: "/data" + command: ["server", "/data", "--console-address", ":9001"] + volumes: + - name: minio-data + persistentVolumeClaim: + claimName: minio-data-pvc +--- +# Service for MinIO +apiVersion: v1 +kind: Service +metadata: + name: minio-service + labels: + app: minio +spec: + selector: + app: minio + ports: + - name: minio-api + protocol: TCP + port: 9000 + targetPort: 9000 + - name: minio-console + protocol: TCP + port: 9001 + targetPort: 9001 + type: ClusterIP # Or NodePort +--- +# Persistent Volume Claim for MinIO data +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: minio-data-pvc +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi # Adjust as needed +--- +# Deployment for ReadTheDocs +apiVersion: apps/v1 +kind: Deployment +metadata: + name: readthedocs-deployment + labels: + app: readthedocs +spec: + replicas: 1 + selector: + matchLabels: + app: readthedocs + template: + metadata: + labels: + app: readthedocs + spec: + containers: + - name: readthedocs + image: readthedocs/readthedocs:latest + ports: + - containerPort: 8000 + volumeMounts: + - name: readthedocs-data + mountPath: /home/docs + env: + - name: DJANGO_SECRET_KEY + value: "my-secret-key" # Change this! Use a real secret key + - name: DATABASE_URL + value: "postgres://user:password@postgres:5432/readthedocs" # Update + volumes: + - name: readthedocs-data + persistentVolumeClaim: + claimName: readthedocs-data-pvc +--- +# Service for ReadTheDocs +apiVersion: v1 +kind: Service +metadata: + name: readthedocs-service + labels: + app: readthedocs +spec: + selector: + app: readthedocs + ports: + - protocol: TCP + port: 8000 + targetPort: 8000 + type: ClusterIP # Or NodePort +--- +# Persistent Volume Claim for ReadTheDocs data +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: readthedocs-data-pvc +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi # Adjust as needed +--- +# Nginx Reverse Proxy Deployment +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-reverse-proxy +spec: + replicas: 1 + selector: + matchLabels: + app: nginx-reverse-proxy + template: + metadata: + labels: + app: nginx-reverse-proxy + spec: + containers: + - name: nginx + image: nginx:latest + ports: + - containerPort: 80 + volumeMounts: + - name: nginx-config + mountPath: /etc/nginx/conf.d + volumes: + - name: nginx-config + configMap: + name: nginx-configmap +--- +# Nginx Reverse Proxy Service +apiVersion: v1 +kind: Service +metadata: + name: nginx-reverse-proxy-service +spec: + selector: + app: nginx-reverse-proxy + ports: + - port: 80 + targetPort: 80 + type: NodePort # Expose the service +--- +# Nginx ConfigMap +apiVersion: v1 +kind: ConfigMap +metadata: + name: nginx-configmap +data: + default.conf: | + server { + listen 80; + server_name grafana.local; + location / { + proxy_pass http://grafana-service:3000; + proxy_set_header Host $host; + proxy_set_header X-Real-IP $remote_addr; + proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; + proxy_set_header X-Forwarded-Proto $scheme; + } + } + server { + listen 80; + server_name nodered.local; + location / { + proxy_pass http://node-red-service:1880; + proxy_set_header Host $host; + proxy_set_header X-Real-IP $remote_addr; + proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; + proxy_set_header X-Forwarded-Proto $scheme; + } + } + server { + listen 80; + server_name docs.local; + location / { + proxy_pass http://readthedocs-service:8000; + proxy_set_header Host $host; + proxy_set_header X-Real-IP $remote_addr; + proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; + proxy_set_header X-Forwarded-Proto $scheme; + } + } +\end{lstlisting} + +\subsection*{A.3 ReadTheDocs Configuration} + +ReadTheDocs uses a configuration file, typically named `.readthedocs.yaml`, to define how your documentation is built. This file should be located in the root of your Git repository. Here's a basic example: + +\begin{lstlisting}[language=Bash] +# .readthedocs.yaml +version: 2.0 +build: + os: ubuntu-22.04 + tools: + python: "3.11" + apt_packages: + - libffi-dev + - zlib1g-dev +python: + install: + - requirements: docs/requirements.txt + system_dependencies: + - pkg: libpq-dev + version: ">=12" +sphinx: + configuration: docs/conf.py + builder: html + fail_on_warning: false +formats: + - pdf + - epub + - htmlzip +\end{lstlisting} + +This configuration does the following: +\begin{itemize} + \item Specifies Read the Docs configuration schema version. + \item Sets the operating system. + \item Sets the Python version. + \item Installs OS-level dependencies. + \item Installs Python dependencies from a requirements file. + \item Specifies the location of your Sphinx configuration file. + \item Builds documentation. + \item Configures the output formats. + +\end{itemize} +%\end{document} diff --git a/Literature-review.tex b/Literature-review.tex new file mode 100644 index 0000000..2637a77 --- /dev/null +++ b/Literature-review.tex @@ -0,0 +1,13 @@ +\section{Literature Review} +\par Capturing field conditions has been a shared goal of both local farmers and government agencies for a long time. This objective has been pursued through various community initiatives and even military projects. According to \cite{TDR}, technologies such as LiDAR and thermal infrared remote sensing have played a key role in these efforts.They typically rely on remote sensing platform such as satellite or aerial imaging which often involve advanced machine learning models. At large scale, they are designed to support precision agriculture by common tasks such as optimizing irrigation, fertilizer and pesticide application, and crop monitoring. + +\par On macroeconomic level, these technologies aims to improve overall crop yield. Image capturing and digital image processing are heavily utilized, as they allow for visual crop assessments that can inform better crop care. But, there are significant assumptions built into these systems. Because they operate at a large scale, they often lack on-the-ground sensing, which limits real-time processing capabilities. As a result, farmers must rely on broader spatial and temporal insights typically provided by environmental agencies or state-level data. In practice, deploying and automating these systems often requires substantial time, infrastructure, and support from third-party organizations. + +%% Not AI Detect validated++++++++++++++++ +\par Recently, there are communities, vendors and organization have been push to promote device to device communication. Especially over wireless medium, giving potential of large scale deployment of this devices. Vendors try to feature their devices as close system, where it doesn't involve external entity to operate. It also comes from the sentiment where farmers prefer to operate and maintain these devices. According to \cite{dect2023}, journal mentions, "The adoption of standards like DECT NR+ has been pivotal in enabling large-scale IoT deployments. This standard allows devices to form decentralized, self-healing mesh networks without relying on centralized infrastructure, thereby reducing operational costs and extending network lifespans. " This seems to be a new norm for class of wireless communication. + + +\par In \cite{iotforall2021}, author explains that integrating mobile applications into an IoT system can be problematic. Issues such as outdated app versions and mobile operating systems can lead to failures, as maintaining compatibility across various devices and OS versions is complex and resource-intensive. Developers struggle among OS platforms, to guarantee that the system will provide users with optimal performance, reliability, and user experience; and will of course be even more complex among multiple versions of older operating system versions. + +\par In \cite{pixelfree2021} journal, Web-based applications will tend to offer reliability and backward compatibility; in that they not only provide access through a web browser and eliminate some dependencies on device-specific configurations (and operating systems) for application functionality, deployment, and reliability. All of which are critical, to ensure continued user experience across all configured devices. +\par Therefore, in developing an IoT system it will likely be beneficial to adopt web applications, in lieu of mobile applications, as developers and vendors are battling some of the challenges of mobile app deployment and reliability while providing a better user experience, for the farmer as an end user. \ No newline at end of file diff --git a/N Square Diagram-Level2.pdf b/N Square Diagram-Level2.pdf new file mode 100644 index 0000000..0679aaf Binary files /dev/null and b/N Square Diagram-Level2.pdf differ diff --git a/Physical Architecture (Level 2).pdf b/Physical Architecture (Level 2).pdf deleted file mode 100644 index c7a3bd2..0000000 Binary files a/Physical Architecture (Level 2).pdf and /dev/null differ diff --git a/Physical Architecture (Level 3).pdf b/Physical Architecture (Level 3).pdf deleted file mode 100644 index ee5325d..0000000 Binary files a/Physical Architecture (Level 3).pdf and /dev/null differ diff --git a/Physical Architecture (Level 4).pdf b/Physical Architecture (Level 4).pdf deleted file mode 100644 index 0bd208f..0000000 Binary files a/Physical Architecture (Level 4).pdf and /dev/null differ diff --git a/Physical Architecture.png b/Physical Architecture.png index fc31e0b..16eb8fb 100644 Binary files a/Physical Architecture.png and b/Physical Architecture.png differ diff --git a/Physical Architecture.tex b/Physical Architecture.tex new file mode 100644 index 0000000..1f15bb6 --- /dev/null +++ b/Physical Architecture.tex @@ -0,0 +1,187 @@ + +\section{Physical Architecture} +\subsection{Component Hierarchy Diagram} +\par Although it is possible for one to many function-component relationship to occur. we have to enforce one to one relationship or many to many relationship, so that the function can be cleared and decomposed to lowest level. This principle is used in design cycle of Component Hierarchy, Component Flow Diagram, and Function Component Matrix. Note that the breaking components may have to cause the function to decompose to sub-function where sub-functions have different processes or activities. Therefore, this change function hierarchy and functions flow to meet the new change in component hierarchy. This phases are described in earlier methodology of figure \ref{fig:traditional-approach} + +\begin{figure}[htbp] + \centering \includegraphics[width=1\linewidth,height=\textheight]{Physical Hierachy of Component.png} + \caption{Physical Hierarchy of Component} + \label{fig:enter-label} +\end{figure} + +\newpage +\begin{figure}[H] + \centering + \includegraphics[width=1\linewidth]{cpf-level1.png} + \caption{Component Flow Level 1 - Base Station System} + \label{fig:enter-label} +\end{figure} +\begin{figure}[H] + \centering + \includegraphics[width=1\linewidth]{cpf-level2-1.png} + \caption{Component Flow Level 2 - Edge Computer} + \label{fig:enter-label} +\end{figure} +\begin{figure}[H] + \centering + \includegraphics[width=1\linewidth]{cpf-level2-2.png} + \caption{Component Flow Level 2 - Sensors} + \label{fig:enter-label} +\end{figure} +\begin{figure}[H] + \centering + \includegraphics[width=1\linewidth]{cpf-level-2-3.png} + \caption{Component Flow Level 2 - Smart Valve} + \label{fig:enter-label} +\end{figure} +\begin{figure} + \centering + \includegraphics[width=1\linewidth]{cfd-level3-1.png} + \caption{Component Flow Level 3 - Hardware} + \label{fig:enter-label} +\end{figure} + +\begin{figure} + \centering + \includegraphics[width=1\linewidth]{cpf-level3-2.png} + \caption{Component Flow Level 3 - Services (Software)} + \label{fig:cfl3-services} +\end{figure} +\newpage +%%% N-Diagram %%%% +\subsection{N-Diagram of Component Flow} + + +\begin{longtable}[c]{|p{3cm}|p{3cm}|p{2cm}|p{2cm}|p{2cm}|} +\caption{N-Diagram Component level 1} +\label{tab:my-table} \\ +\hline +\textbf{Technician} & Maintenance info, error code, wifi connect request & & & \\ +\hline +Maintenance info (pdf,html), expenses Info(html), Network Info(html), Environment Info, Valve status, Computer Condition. & \textbf{2.0 Edge Computer} & & Turn On/Off Signal & \\ +\hline +& Wireless Signal & \textbf{Sensors} & & \\ +\hline +& Valve Status & &\textbf{Smart Valve}& \\ +\hline +& & & & \textbf{5.0 Installation Kit} \\ +\end{longtable} + + + +\begin{table}[H] +\centering +\caption{N-Diagram Component level 2} +\begin{tabularx}{\textwidth}{|p{2.5cm}|X|X|X|X|X|X|X|} +\hline +\textbf{2.1 Hardware} & Current Time, base image version & & & Real time Data (datastream) & Error Code &\\ +\hline +&\textbf{ 2.2 OS} & & & & &\\ +\hline +& & \textbf{2.3 Services (software)} & Grafana.local/\allowbreak dashboard.local/\allowbreak Maintenance.local & Grafana.local/\allowbreak dashboard.local/\allowbreak Maintenance.local & & \\ +& & & /dashboard.local/\allowbreak Maintenance.local & dashboard.local/\allowbreak Maintenance.local & & \\ +\hline +Image Files & Image Files & &\textbf{ 2.4 PC }& & &\\ +\hline +& & & & \textbf{2.5 Mobile }& & \\ +\hline +UV Shield& & & & & \textbf{2.6 Enclosure} & \\ +\hline +Power & & & & & & \textbf{2.7 Solar Kit} \\ +\hline +\end{tabularx} +\end{table} + + +\begin{landscape} +\begin{table}[htbp] +\centering +\renewcommand{\arraystretch}{0.7} % Shrinks row height +\caption{N-Diagram Component level 3 for 2.1 } +{ +\scriptsize +\begin{tabularx}{\textwidth}{|X|X|X|X|X|X|X|X|X|X|} +\hline +\textbf{2.1.1 Micro-SD Card} & & & & ARM architect & & & & & \\ +\hline +& \textbf{2.1.2 USB 128 GB}& & & & & & & & \\ +\hline +& & \textbf{2.1.3 Error Code LED} & & & & & & & \\ +\hline +& & Smart Valve Status& \textbf{2.1.4 External WIFI Attena} & & & & & & \\ +\hline +& & Error Code & 1.5 V power & \textbf{2.1.5 Raspberry Pi 4} & GPIO & & & & \\ +\hline +& & & & GPIO & \textbf{2.1.6 LORA ESP32 Transmitter} & & & & \\ +\hline +& & & & & & \textbf{2.1.7 LORA ESP 32 Board (Spare)} & & & \\ +\hline +& & & & & & & \textbf{2.1.8 Raspberry Pi 4 (Spare)} & &\\ +\hline +& & & & & & & & \textbf{2.1.9 MicroSD Card (Spare)} &\\ +& & & & & & & & & \textbf{2.1.10 Real Time Clock (RTC)} \\ + +\hline +\end{tabularx} +} +\end{table} +\end{landscape} + +\begin{landscape} +\begin{table}[htbp] +\renewcommand{\arraystretch}{0.6} +\centering +\caption{N-Diagram Component level 3 for 2.3 System Monitoring and Infrastructure} +{ % Begin small font scope +\scriptsize +\begin{tabularx}{\linewidth}{|X|X|X|X|X|X|X|X|X|X|X|} +\hline +\textbf{2.3.1 Monitoring (Grafana)} & & & & & & & & & & \\ +\hline +& \textbf{2.3.2 Dashboard (Control Board)} & ingress & & & & & & & & \\ +\hline +net info & & \textbf{2.3.3 Network (Throughput)} & & & & & & & & \\ +\hline +& & & \textbf{2.3.4 Expenses (CRUD Web App)} & & & & & & & \\ +\hline +& ingress & & & \textbf{2.3.5 Inventory and Maintenance Log} & pdf, html & & & & & \\ +\hline +& & & & & \textbf{2.3.6 Config Files} & bash, manifests & & & & \\ +\hline +& & & & & & \textbf{2.3.7 Object Storage} & & & & \\ +\hline +& & & & & & & \textbf{2.3.8 Software Repository} & & & \\ +\hline +& & & & & & & & \textbf{2.3.9 Cloud Native (Kubernetes)} & & \\ +\hline +& & & & & & & & & \textbf{2.3.10 Containers (CNI)} & \\ +\hline +& & & & & & & & & & \textbf{2.3.11 Sensors Pilineline (Node-Red Software} \\ +\hline +\end{tabularx} +} +\end{table} +\end{landscape} + +\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 performance. However, the function should perform to meet the requirements deprived from the stakeholder. +\par Another aspect that is conducted in this research in introducing open source software to prolong our system. Cloud Native computing is an approach and an architecture where we want to build and design software for dynamic environment of public cloud and private cloud. To follow such a a principle the application must be loosely coupled systems that are resilient, manageable, and observability the concept expands to many benefits for organizations adapt this architecture, yet we focus on the goodness of this architecture which is easy to maintain, reliable and portable. These three factors are known as three of six goodness introduced in system engineering. For maintainability, cloud native can help application to me patched by our community where software can be shipped and installed with different version 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, automation in replication of software can significantly improve the up time of the application. As mentioned above, this Cloud-Native component is aimed at meeting the up-time reliability requirement above "The system must automatically restart when a malfunction is detected""The"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 on the basis of the growth of communication of components. Preferably we want the component to communicate within it packages (one upper level) and external components would have their own level to communicate. To do so we can group them based on geographical location, a common environment, and similarity system. Which components needed to be communicated most would be reflected in N-diagram level 1 and level 2 below. +\par At level 3 of N-square diagram of figure \ref{fig:cfl3-services} '2.0 Services component', we have large amount of flow running inside this boundary. To support lightweight Raspberry Pi hardware, the Kubernetes (Cloud Native Component) deploys grouping services based on their resource profiles: + +\begin{itemize} + \item \textbf{Low-resource pod:} Contains Node-RED, Grafana, the NGINX reverse proxy, and the static Farmer Portal HTML. + \item \textbf{Heavy-resource pod:} Contains MinIO (with persistent storage). +\end{itemize} + +This separation allows better control over resource allocation and horizontal scaling. For example, the low-resource pod can run multiple replicas, while the heavy-resource pod remains isolated to nodes with higher memory or attached USB storage. By keeping the flow inside this domain or level we can have optimize performance where component can reliably communicate to perform the allocated functions. + +The deployment design is tailored for Raspberry Pi 4, using MicroK8s and USB-mounted persistent volumes for MinIO can be shown in Appendix \ref{appendix:}." +\subsection{Function to Component Matrix} +The Matrix below is used to check if all components have been used. As mentioned above, functions do not have to have a one-to-one relationship with component. Each component can be used by multiple functions. Yet, multiple components can't be used by one function, this would cause the ambiguity for structure of the system and may cause the corrupt link in the future. If it is the case, consider breaking down functions into sub functions where resources are consumed individually. In order word, considering repeat function decomposition process. +\includepdf[pages=-, scale=0.95]{Function Component Matrix.pdf} +We can also use the N-diagram to verify if component has been used by all the system functions. +After generating the component matrix above, we have to recall the principle "design to requirement", where we have components that support the original requirements. Individual components specification would be used to satisfy requirement mentioned in HoQ. For example, the cost requirement is \$1000, the bill of all component can't pass that, otherwise consider switching out components with lower price range that perform the same function or pick component that can be used on multiple function. The table bellowed is set as standard bill of material for the build of this system. To achieve this, using requirement traceability to assure all the requirement have been met. + +\subsection{Requirement Traceability} +In this section, consider tracing the requirements with new components list. Requirements can affectively change the component selection and component type. For example, REQ-26 specify 'It should be built within \$1000 budget", this will lead to a component replacement process where we have to pick multiple components that can perform the same function with lower budgets and affect the REQ-29 which is " The system should last 3 years". +\input{Requirement-traceability} \ No newline at end of file diff --git a/Physical Hierachy of Component.png b/Physical Hierachy of Component.png new file mode 100644 index 0000000..2d4be78 Binary files /dev/null and b/Physical Hierachy of Component.png differ diff --git a/Postinstall.tex b/Postinstall.tex new file mode 100644 index 0000000..cf14595 --- /dev/null +++ b/Postinstall.tex @@ -0,0 +1,76 @@ +\section*{Appendix: Postinstall Scripts and Cloud-Init Configuration} +\addcontentsline{toc}{section}{Appendix: Postinstall Scripts and Cloud-Init Configuration} + +This appendix includes the scripts and cloud-init configuration used to automate the setup of the farmer portal environment, including USB mounting and Wi-Fi hotspot broadcasting. Noted, this file can only be supported with Ubuntu Core OS. + +\subsection*{postinstall.sh} +This script is designed to be executed on the host device (e.g., Raspberry Pi or Linux box) after the system is installed. It mounts a USB device labeled \texttt{MINIO\_USB} and starts a Wi-Fi hotspot using NetworkManager. + +\begin{lstlisting}[language=bash, caption={Postinstall Script for Mounting USB and Broadcasting Hotspot}] +#!/bin/bash + +# === Mount USB Drive === +USB_LABEL="MINIO_USB" +MOUNT_PATH="/mnt/usb2/minio-data" +DEVICE=$(lsblk -o LABEL,NAME | grep "$USB_LABEL" | awk '{print "/dev/" $2}') + +if [ -z "$DEVICE" ]; then + echo "❌ USB with label $USB_LABEL not found." + exit 1 +fi + +echo "✅ Found USB device: $DEVICE" + +sudo mkdir -p "$MOUNT_PATH" +sudo mount "$DEVICE" "$MOUNT_PATH" +sudo chown -R $USER:$USER "$MOUNT_PATH" + +# === Setup Wi-Fi Hotspot === +SSID="FarmerPortal" +PASSWORD="farmer123" +INTERFACE="wlan0" + +echo "Starting Wi-Fi hotspot on $INTERFACE..." +nmcli device wifi hotspot ifname $INTERFACE ssid $SSID password $PASSWORD + +echo "✅ Postinstall complete. Portal available at http://192.168.50.1:8080 or http://localhost:8080" +\end{lstlisting} + +\subsection*{cloud-init.yaml} +This file automates the postinstall process on first boot. It installs required packages, mounts the USB device, and enables the Wi-Fi hotspot automatically. + +\begin{lstlisting}[language=yaml, caption={Cloud-Init Configuration for Automated Setup}] +#cloud-config + +package_update: true +package_upgrade: true +packages: + - network-manager + - dnsmasq + - wireless-tools + - net-tools + +write_files: + - path: /usr/local/bin/postinstall.sh + permissions: '0755' + content: | + #!/bin/bash + USB_LABEL="MINIO_USB" + MOUNT_PATH="/mnt/usb2/minio-data" + DEVICE=$(lsblk -o LABEL,NAME | grep "$USB_LABEL" | awk '{print "/dev/" $2}') + if [ -n "$DEVICE" ]; then + mkdir -p "$MOUNT_PATH" + mount "$DEVICE" "$MOUNT_PATH" + chown -R ubuntu:ubuntu "$MOUNT_PATH" + fi + + SSID="FarmerPortal" + PASSWORD="farmer123" + INTERFACE="wlan0" + nmcli dev wifi hotspot ifname $INTERFACE ssid $SSID password $PASSWORD + +runcmd: + - [ bash, /usr/local/bin/postinstall.sh ] +\end{lstlisting} + +This setup ensures that the system is accessible both over Ethernet and via a self-hosted Wi-Fi hotspot, and that persistent object storage is available to services like MinIO on the mounted USB drive. diff --git a/Problem-statement.tex b/Problem-statement.tex new file mode 100644 index 0000000..4766f74 --- /dev/null +++ b/Problem-statement.tex @@ -0,0 +1,106 @@ +\section{Problem Definition and Identification 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 up-time. However, relying on a large pool of devices forces farmers to rely on multiple vendors and services to meet their needs. Another factor to consider is the life time of these devices is that it tends to be shorter when vendors or companies realize 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. According to a report by the National Institute of Standards and Technology (NIST), “many IoT systems are closed systems, each with its own proprietary applications, which makes it difficult to integrate data from multiple providers” \cite{nist2023iot}. 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 without the external system such as Cloud Technology and the 5G Network. More importantly, the system must be reliable for long-term use and feasible enough for farmers to acquire or build. + +\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 +\par In order to begin the analysis, criteria have to be defined. Then, evaluate each alternative based on the selected criteria. Then using a self defined scoring metric to weight each criteria. Considering normalizing the data prioritizing to finalizing data in for score weight in the end. +\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). +\subsection*{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} + + \subsection*{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} + +\subsection*{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} + +\subsection*{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} + +\subsection*{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} + +\item Effectiveness Requirement: Because the system potentially 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. In addition, the costs of upgrading should only be tied to new parts without modification of the current design. Therefore, it is acceptable to replace other than repair. + +\newpage + + +\subsection{House of Quality} +To translate and communicate with stakeholders (farmers), a House of Quality (HoQ) is recommended to help the design process. This often completed by system analysis and system engineering. To complete this step, a requirement documents have to be a affirmed to conduct the chart. Based on the requirement documents, quantified information will be used to set up standard requirement of the system, and later used as a blueprint to drive the design process. For the assignment stage, this tends to address the customers and stakeholders need more than information shared within the engineer team. Therefore, spending times with stakeholder often prioritized more than system development. + + +\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{House of Quality} + \label{fig:hoq} +\end{figure} +As mentions in figure \ref{fig:hoq}, we can view competitor such as Azure IoT Platform, The Things Network, Cisco IoT have offering same set of qualities and functions. Theses qualities have to match with the demand of customers. The demands of customers are deprived from the requirement documents collected earlier. diff --git a/Requirement-traceability.tex b/Requirement-traceability.tex new file mode 100644 index 0000000..80319f0 --- /dev/null +++ b/Requirement-traceability.tex @@ -0,0 +1,49 @@ +\begin{longtable}{|p{1.5cm}|p{5.5cm}|p{3cm}|p{3cm}|p{3cm}|} +\caption{Full Requirement Traceability Matrix} \label{tab:traceability} \\ +\hline +\textbf{ID} & \textbf{Requirement Description} & \textbf{Source} & \textbf{Verification Method} & \textbf{Status} \\ +\hline +\endfirsthead + +\hline +\textbf{ID} & \textbf{Requirement Description} & \textbf{Source} & \textbf{Verification Method} & \textbf{Status} \\ +\hline +\endhead +\hline +\textbf{Req. ID} & \textbf{Requirement Description} & \textbf{Mapped Function} & \textbf{Component(s)} & \textbf{Validation / Diagram} \\ +\hline +REQ-01 & System must provide coverage of 1,000 square feet. & 2.1.1 Measure Windspeed, 2.1.2, 2.1.3 Measure Humidity & 2.1.6 LORA ESP32 long range Transmitter and 3.3 LORA ESP32 Reciever. The build include 3.1 Ecowitt Weather Base Station (Wifi signal) & Mapped in FFBDs figure \ref{fig:ffbd-architecture}\\ +REQ-02 & The system should be able to turn on or turn off irrigation pumps. & 4.2.2 Send turn on signal & 4.1 LORA ESP32 Lora Receiver and 4.2 AAA Batteries& \\ +REQ-03 & System must be able to support the following wireless communication protocols: LORA, WiFi 2.4GHz, WiFi 5.0GHz. & 2.3 Power Sensors & 4.1 LORA ESP32 Receivers, 3.1 Ecowitt Weather Station & Mapped in FFBDs \\ +REQ-04 & Farmers should receive updated data every 3-5 minutes. & 3.1.1 Preview environment info & 2.5 Mobile & Mapped in FFBDs, components on figure \ref{fig:physical-hierachy} \\ +REQ-05 & Farmers should be able to view weather data daily. & 3.1.1 Preview environment info & 2.5 Mobile & Mapped in FFBDs, components on figure \ref{fig:physical-hierachy} \\ +REQ-06 & The system must be exposed to UV sunlight. & 4.1 Add Enclosure & 2.6 Enclosure & Mapped in FFBDs, component listes in figure \ref{fig:physical-hierachy}\\ +REQ-07 & The system can operate in outdoor environments below 100°F. & 4.1 Add Enclusure & 2.6 Enclsuree (Fan ventilation provided) & Mapped in FFBDs, Component Hierachy, Function and Component matrix \\ +REQ-08 & The system can withstand 40 mph - 50 mph wind speed. & 1.2.1 Mount the assembly & addressed in 5.1 Pre-assembly kit &Mapped in FFBDs, Component Hierachy, Function and Component matrix\\ +REQ-09 & System must support being connected over-the-air. &1.3.3 Add Update over Air & used with 2.1.4 External WIFI attena & Mapped in FFBDs, Component Hierachy, Function and Component matrix \\ +REQ-10 & Enable remote access protocol. & 3.2 Provide Mobile Services & Used by 2.4 Mobile and 2.5 PC & Mapped in FFBDs, Component Hierachy, Function and Component matrix \\ +REQ-11 & System should take less than 30 minutes to mount. & 1.2 Deploy preassemble parts & See Function Allocation Table & Mapped in FFBDs, Component Hierarchy, Function and Component matrix\\ +REQ-12 & System only allows 90 minutes downtime. & 1.3.3 Add update over air, 1.3.5 Create back-up for OS, 1.3.6 Create back-up for sensors & 2.7 Solar Power kit, 2.1.7-9 Spare Parts available & Mapped in FFBDs, Component Hierachy, Function and Component matrix \\ +REQ-13 & System should take 90 minutes to install software for the system. & Performed by 1.3 Install Embedeed Software & Run with 2.3.6 Config files . Refer to Appendix \ref{appendix:supp_material} for config files.& Mapped in FFBDs, Component Hierachy, Function and Component matrix \\ +REQ-14 & System must take two hours to deploy. & Performed by 1.1 Preassemble part & Enforced by 5.1 Installation Kit & Mapped in FFBDs, Component Hierachy, Function and Component matrix \\ +REQ-15 & System must be able to operate without grid electricity. & 1.5 Power assemby & 2.7 Solar Power Kit & Mapped in FFBDs, Component Hierachy, Function and Component matrix\\ +REQ-16 & System must measure factors such as UV radiation, wind speed, wind direction, rainfall, and soil moisture. & 2.1 Measure Outdoor & 3.0 Sensors & see figure \ref{fig:physical-hierachy}: Physical Hierachy. Mapped in FFBDs, Component Hierachy, Function and Component matrix \\ +REQ-17 & System must support mobile devices. & 3.2 Provide Mobile Services & 2.5 Mobile component provided 2.1 Hardware component provide wifi capability & Mapped in FFBDs, Component Hierarchy, Function and Component matrix\\ +REQ-18 & System must automatically restart when a malfunction is detected. & 5.1 Detect System Failure & 2.1.3 Error Code LED &Mapped in FFBDs, Component Hierachy, Function and Component matrix \\ +REQ-19 & The chance of the system going down must be less than 10 percent. & Enforced by 5.3 Schedule and perform Maintenance/Inspection) & 2.3.7 Object Storage and 2.3.5 Inventory and Maintenance & Mapped in FFBDs, Component Hierachy, Function and Component matrix \\ +REQ-20 & Annual operation cost should not exceed \$200. & 3.3.3 Track Monthly Expense & 2.3.4 Expenses (CRUD app) & Mapped in FFBDs, Component Hierachy, Function and Component matrix \\ +REQ-21 & System parts or modules must be available on the market for the next 5 years.& 3.3.4 Check Part Availability & 2.3.5 Inventory and management log & Mapped in FFBDs, Component Hierachy, Function and Component matrix \\ +REQ-22 & About 80 percent of the parts should be recyclable or reused. & Met by performing 3.3.4 Check part availability and 3.3.5 Track Warranty Duration & 2.3.5 Inventory and Management Log & Mapped in FFBDs, Component Hierachy, Function and Component matrix\\ +REQ-23 & The system should last more than a 5-year lifespan. & Duration supported by 3.3.5 Track Warranty Duration & 2.3.5 Inventory and Management & Mapped in FFBDs, Component Hierachy, Function and Component matrix \\ +REQ-24 & The parts can be salvaged with a price of 30 percent of the initial purchasing cost. & 3.1.1 Built-in house service for tracking & 2.3.5 Inventory and Maintenance Log (CRUD Web) &Mapped in FFBDs, Component Hierachy, Function and Component matrix \\ +REQ-25 & The system’s weight must be below 50 pounds. & unmet & unmet & Not mapped in FFBD\\ +REQ-26 & It should be built within a \$1000 budget. & + Unmet & Supported by 2.3.4 Expenses component & unmapped in FFBDs \\ +REQ-27 & Latency for farmers to access the system is 0-30 seconds. & 3.2.1 Create Ad hoc Network& 2.14 External Wifi Attena See Function Allocation Table & Mapped in FFBDs, Component Hierachy, Function and Component matrix \\ +REQ-28 & System must provide data redundancy. & 1.3.5 + Create Back-up for OS, 1.3.6 Create backup sensors & 2.1.7 and 2.1.8 Spare Components & Mapped in FFBDs, Component Hierachy, Function and Component matrix. \\ +REQ-29 & Data will be collected for a 3-year period. & 2.2 ETL & 2.1.2 USB 128 GB & Mapped in FFBDs, Component Hierachy, Function and Component matrix \\ +REQ-30 & Data must be transmitted securely over the air. & 3.2.2 Give system access & Performed by 2.1.5 Raspberry pi 4 & Mapped in FFBDs, Component Hierachy, Function and Component matrix \\ +\hline + +\end{longtable} \ No newline at end of file diff --git a/abstract.tex b/abstract.tex new file mode 100644 index 0000000..980b2f0 --- /dev/null +++ b/abstract.tex @@ -0,0 +1,8 @@ +\section*{Abstract} +This project addresses the challenges faced by farmers in implementing and maintaining reliable real-time field monitoring and control. Knowning their system operating with high failure rate, which often attributed to issues such as network connectivity, sensor malfunctions, and vendor dependency, this research focuses on developing autonomous control-based station to overcome some of these challenges. The system is designed to provide farmers with real-time data acquisition and remote control capabilities without reliance on external cloud services or 5G networks, thus retain autonomy of farmers for long term. + +With system engineering approach, this thesis will adopt tools such as system analysis, functional decomposition, and physical architecture design, while offer alternatives assessment on multiple technology such as farming drones, AI-integrated image capturing, and control-based stations, using multi-criteria decision-making methods like the Analytical Hierarchy Process (AHP). Farmers can be persuade in some aspect where control-based station solution can be an alternative that is cost-effective, maintainable, and adaptable to new pool of wireless technology. This project also address new growth of utilizing open-source software and popular open-source hardware available to minimize vendor dependency and ensure long-term support. + +Operational requirements, economic factors, design constraints, and non-functional requirements are thoroughly analyzed to guide the system's development. The scope of the project will includes defining functional hierarchies, creating N-square diagrams, and developing a function allocation table to ensure traceability and modularity. The project also introduce linear regression models for water need prediction and cloud-native computing principles for system reliability and maintainability. + +The goal for this research is a system design that can balances performance, cost, and maintainability. The end goal of the design is providing farmers with a reliable and autonomous field monitoring and control solution for their crops cares. \ No newline at end of file diff --git a/cf.tex b/cf.tex new file mode 100644 index 0000000..b5d291c --- /dev/null +++ b/cf.tex @@ -0,0 +1,96 @@ + +\subsection{6.5 Lifecycle Cost Planning and TVM Analysis} + +\begin{center} +\textbf{Cash Flow Diagram for Control-Based Station (5-Year Lifecycle)} +\end{center} + +\begin{tikzpicture}[>=Stealth, scale=1, every node/.style={scale=1}] + % Draw timeline + \draw[->] (0,0) -- (6.5,0) node[right] {Time (Years)}; + \foreach \x in {0,1,2,3,4,5} { + \draw (\x,0.1) -- (\x,-0.1) node[below] {\x}; + } + + % Year 0 - Initial Investment + \draw[->, thick] (0,0) -- (0,-3) node[below] {- \$1000}; + + % Years 1–4 - Annual Operating Cost + \foreach \x in {1,2,3,4} { + \draw[->, thick] (\x,0) -- (\x,-1) node[below] at (\x,-1.2) {- \$100}; + } + + % Year 5 - Annual Cost + Salvage + \draw[->, thick] (5,0) -- (5,-1) node[below left] {- \$100}; + \draw[->, thick, green!60!black] (5,0) -- (5,2) node[above] {+ \$200}; + + % Labels + \node at (3,-3.8) {Cash Outflows = CAPEX \& OPEX}; + \node at (5.8,2.5) {Salvage Value}; +\end{tikzpicture} +\section{System Engineering Management Plan (SEMP)} + +This section outlines the methodology, tools, and resources used to develop, analyze, and manage the system in accordance with systems engineering best practices. + +\subsection{Lifecycle Approach} +This project follows a V-Model-inspired process, progressing from stakeholder requirements through system design, component selection, and preparation for verification. + +\subsection{Engineering Activities} +\begin{itemize} + \item \textbf{Modeling Method}: Descriptive MBSE approach using function hierarchy, FFBDs, N-diagrams, and allocation tables. + \item \textbf{System Design}: Evaluation of alternatives via AHP, selection of components, function-to-component mapping. + \item \textbf{Verification Prep}: Requirement traceability ensures every component and function aligns with stakeholder needs. +\end{itemize} + +\subsection{Organizational Roles} +\begin{itemize} + \item \textbf{System Engineer}: Leads system analysis, design, and validation (single-author thesis project). + \item \textbf{User / Stakeholder}: Farmers or homesteaders maintaining and interacting with the system. + \item \textbf{Open Source Community}: Supports software packages, updates, and ecosystem tools. +\end{itemize} + +\subsection{Key Milestones} +\begin{table}[H] +\centering +\caption{SEMP Development Milestones} +\begin{tabular}{|l|l|} +\hline +\textbf{Phase} & \textbf{Deliverable} \\ +\hline +Requirements Analysis & Functional and Non-Functional Requirements \\ +Conceptual Design & FFBDs, N-diagrams, Function Allocation Tables \\ +Component Architecture & Component Hierarchy, Flow Diagrams, Cost Model \\ +Verification Planning & Requirement Traceability Matrix \\ +Deployment Preparation & Configuration Table, Maintenance Strategy \\ +\hline +\end{tabular} +\end{table} + +\subsection{Cost Model} + +The system is designed with strict cost constraints to ensure affordability for small-scale farmers and homesteaders. The goal is to maintain an annual operating cost below \$200 and a one-time hardware cost under \$1000, as specified in REQ-20 and REQ-26. The cost model incorporates hardware components, connectivity fees, and maintenance buffers. + +\begin{table}[H] +\centering +\caption{Estimated First-Year and Annual Operating Costs} +\begin{tabular}{|l|l|l|} +\hline +\textbf{Category} & \textbf{One-Time Cost (USD)} & \textbf{Annual Cost (USD)} \\ +\hline +Edge Device (Raspberry Pi 4 + Peripherals) & \$100 & -- \\ +Sensors (Weather Station + Soil Probes) & \$200 & -- \\ +4G Modem + SIM Hardware & \$50 & -- \\ +Solar Power Kit + Battery Storage & \$150 & -- \\ +Weatherproof Enclosure & \$30 & -- \\ +Data Connectivity (4G SIM, low-data) & -- & \$6--\$12 \\ +Preventive Maintenance Buffer & -- & \$50 \\ +Cloud/Remote Logging (Optional) & -- & \$60 \\ +\hline +\textbf{Total Estimate} & \textbf{\$530} & \textbf{\$116--\$122} \\ +\hline +\end{tabular} +\end{table} + +\noindent +The model assumes one centralized edge device performing both hub and compute functions. This reduces recurring data costs by minimizing transmission frequency and eliminates the need for cloud-hosted control services. The architecture supports expansion through additional sensors without significantly increasing operating costs. + diff --git a/cfd-level3-1.png b/cfd-level3-1.png new file mode 100644 index 0000000..fe755f1 Binary files /dev/null and b/cfd-level3-1.png differ diff --git a/cld.tex b/cld.tex new file mode 100644 index 0000000..37dc3ae --- /dev/null +++ b/cld.tex @@ -0,0 +1,73 @@ +\par Without considering a defined system boundaries yet. The diagram could represent just a section of a more extensive system, with the "loop" potentially completed by elements not included in the diagram.For problem analysis, focusing on dissecting the causes of a specific issue, the diagram might highlight the causes while possibly omitting some feedback effects. In general we want to improve farmers adoption of IoT, so that they can improve their ability to react to environmental changes. This is a primary goal that happens outside the scope of the is project. Understanding that their are other systems contribute to the factor of the farmers controlling their farming environment, but increase wireless technology adoption is one of the key component we try to improve. +\par For example, if the network coverage is improved, the project failure rate eventually decrease over time. This is a negative relationship. The most important factor to address is the loop of System Complexity, Reliance on Multiple Vendors, "Device Lifespan", "System Functionality" node. These nodes are completed with a feed backloop, and have the effect on "System Complexity". If we need to reduce the project failure rate, it need us to increase network connectivity, sensor malefunctions, and signifcantly reduce system complexity. When we reduce system complexity, we reduce the reliance on multiple vendors, and increase device lifespan. Thus, it would improve the system functionality, improve Farmers IoT adoption. Finally, it reduce the project failure rate since this is the negative relationship between the node. + + +\begin{figure}[ht] + \centering % Center the figure on the page +\begin{tikzpicture}[ + node distance=2cm, % Increased node distance + box/.style={rectangle, rounded corners, draw=black, text width=3cm, text centered, minimum height=3cm}, + arrow/.style={->, thick, >=Stealth}, + every node/.style={font=\scriptsize}, + scale=0.5, % Slightly reduced scale + transform shape + ] + + % Nodes + \node (FailureRate) [box] {Project Failure Rate}; + \node (Connectivity) [box, above right=of FailureRate] {Network Connectivity Coverage}; + \node (Malfunctions) [box, right=of Connectivity] {Sensor Malfunctions}; + \node (Integration) [box, below right=of Malfunctions] {Integration Issues}; + \node (VendorReliability) [box, below=of Malfunctions] {Vendor Reliability}; + \node (RealTimeData) [box, below left=of Integration] {Real-Time Data Collection}; + \node (Complexity) [box, left=of RealTimeData] {System Complexity}; +% \node (MobilePracticality) [box, above left = of Complexity] {Practicality of Mobile Devices}; + \node (NewAdoption) [box, above right = of Integration] {New Sensor/Protocol Adoption}; + \node (VendorProfit) [box, right = of NewAdoption] {Vendor Profit Motive}; + \node (DeviceLifespan) [box, below right = of VendorProfit] {Device Lifespan}; + + \node (FarmerAdoption) [box, below = of FailureRate] {Farmer Adoption of IoT}; + \node (EnvChanges) [box, below right = of FarmerAdoption] {Ability to React to Environmental Changes}; + \node (RelianceonVendors) [box, right=of Integration] {Reliance on Multiple Vendors}; + \node (SystemFunctionality) [box, below=of DeviceLifespan] {System Functionality}; + +% Arrows + + % Arrows - Reinforcing Loop 1 + \draw[arrow] (FailureRate) -- node[above left] {(-)} (FarmerAdoption); +% \draw[arrow] (FarmerAdoption) -- node[below] {(-)} (FailureRate); + + % Arrows - Reinforcing Loop 2 +% \draw[arrow] (VendorProfit) -- node[above] {(+)} (NewAdoption); +% \draw[arrow] (NewAdoption) -- node[right] {(-)} (VendorProfit); +\draw[arrow] (VendorProfit) -- node[right] {(-)} (NewAdoption); + % Arrows - Balancing Loop 1 + \draw[arrow] (RealTimeData) -- node[above] {(+)} (Complexity); + \draw[arrow] (Complexity) -- node[above] {(+)} (FailureRate); +% \draw[arrow] (FailureRate) -- node[above right] {(-)} (RealTimeData); +\draw[arrow] (RealTimeData) -- node[below left] {(-)} (FailureRate); + % Arrows - Balancing Loop 2 + \draw[arrow] (Complexity) -- node[above] {(+)} (RelianceonVendors); + \draw[arrow] (RelianceonVendors) -- node[right] {(-)} (DeviceLifespan); + \draw[arrow] (DeviceLifespan) -- node[right] {(+)} (SystemFunctionality); + \draw[arrow] (SystemFunctionality) -- node[below] {(+)} (FarmerAdoption); + + + % Additional Arrows + \draw[arrow] (Connectivity) -- node[left]{(-)}(FailureRate) ; + \draw[arrow] (Malfunctions) -- node[left]{(+)}(FailureRate); + \draw[arrow] (VendorProfit) -- node[right] {(-)}(Malfunctions); + \draw[arrow] (Integration) -- (FailureRate); + \draw[arrow] (VendorReliability) -- node[left]{(-)}(FailureRate); + \draw[arrow] (RealTimeData) -- (Complexity); + \draw[arrow] (FarmerAdoption) -- node[right] {(+)} (EnvChanges); + \draw[arrow] (NewAdoption) -- node[right] {(+)} (RealTimeData); + \draw[arrow] (Complexity) -- node[above] {(+)} (RelianceonVendors); + \draw[arrow] (RelianceonVendors) -- node[right] {(-)} (DeviceLifespan); + \draw[arrow] (DeviceLifespan) -- node[right] {(-)} (SystemFunctionality); + +\end{tikzpicture} + % \caption{CLD - Project Failure Rate (New System Introduced) % Add a caption + \caption{CLD - Project Failure Rate Analysis (Current Stage)} % Add a caption + \label{fig:causal_loop_example} % Add a label for referencing +\end{figure} diff --git a/cpf-level-2-3.png b/cpf-level-2-3.png new file mode 100644 index 0000000..2881616 Binary files /dev/null and b/cpf-level-2-3.png differ diff --git a/cpf-level1.png b/cpf-level1.png new file mode 100644 index 0000000..baeff14 Binary files /dev/null and b/cpf-level1.png differ diff --git a/cpf-level2-1.png b/cpf-level2-1.png new file mode 100644 index 0000000..2d42732 Binary files /dev/null and b/cpf-level2-1.png differ diff --git a/cpf-level2-2.png b/cpf-level2-2.png new file mode 100644 index 0000000..c325ae9 Binary files /dev/null and b/cpf-level2-2.png differ diff --git a/cpf-level3-2.png b/cpf-level3-2.png new file mode 100644 index 0000000..321d8fb Binary files /dev/null and b/cpf-level3-2.png differ diff --git a/ffbd-physical.tex b/ffbd-physical.tex new file mode 100644 index 0000000..c095f97 --- /dev/null +++ b/ffbd-physical.tex @@ -0,0 +1,83 @@ +\documentclass{article} +\usepackage{tikz} +\usetikzlibrary{positioning} + +\begin{document} + +\begin{tikzpicture}[node distance=0.5cm, every node/.style={rectangle, draw, minimum width=2cm, minimum height=0.8cm, align=center}] + + % Top Level Node + \node (bs) {Base Station System}; + + % First Level Nodes + \node (bsc1) [below=of bs] {BSC1}; + \node (bsc2) [right=of bsc1, xshift=2cm] {BSC2}; + \node (omc) [right=of bsc2, xshift=2cm] {OMC}; + + % BSC1 Branch + \node (bts11) [below=of bsc1] {BTS11}; + \node (bts12) [below=of bts11] {BTS12}; + \node (bts13) [below=of bts12] {BTS13}; + \node (bts14) [below=of bts13] {BTS14}; + \node (bts15) [below=of bts14] {BTS15}; + \node (bts16) [below=of bts15] {BTS16}; + \node (bts17) [below=of bts16] {BTS17}; + \node (bts18) [below=of bts17] {BTS18}; + \node (bts19) [below=of bts18] {BTS19}; + \node (bts110) [below=of bts19] {BTS110}; + \node (bts111) [below=of bts110] {BTS111}; + \node (bts112) [below=of bts111] {BTS112}; + \node (bts113) [below=of bts112] {BTS113}; + \node (bts114) [below=of bts113] {BTS114}; + \node (bts115) [below=of bts114] {BTS115}; + \node (bts116) [below=of bts115] {BTS116}; + \node (bts117) [below=of bts116] {BTS117}; + \node (bts118) [below=of bts117] {BTS118}; + \node (bts119) [below=of bts118] {BTS119}; + \node (bts120) [below=of bts119] {BTS120}; + \node (bts121) [below=of bts120] {BTS121}; + + % BSC2 Branch + \node (bts21) [below=of bsc2] {BTS21}; + \node (bts22) [below=of bts21] {BTS22}; + \node (bts23) [below=of bts22] {BTS23}; + + % OMC Branch + \node (rnc) [below=of omc] {RNC}; + + % Connect Nodes - with side connections to the left (Adjusted to -1) + \draw (bs) -- ++(-3, -1) -| (bsc1.west); + \draw (bs) -- ++(-3, -1) -| (bsc2.west); + \draw (bs) -- ++(-3, -1) -| (omc.west); + + \draw (bsc1) -- ++(-3, -1) -| (bts11.west); + \draw (bsc1) -- ++(-3, -1) -| (bts12.west); + \draw (bsc1) -- ++(-3, -1) -| (bts13.west); + \draw (bsc1) -- ++(-3, -1) -| (bts14.west); + \draw (bsc1) -- ++(-3, -1) -| (bts15.west); + \draw (bsc1) -- ++(-3, -1) -| (bts16.west); + \draw (bsc1) -- ++(-3, -1) -| (bts17.west); + \draw (bsc1) -- ++(-3, -1) -| (bts18.west); + \draw (bsc1) -- ++(-1, -1) -| (bts19.west); + \draw (bsc1) -- ++(-1, -1) -| (bts110.west); + \draw (bsc1) -- ++(-1, -1) -| (bts111.west); + \draw (bsc1) -- ++(-1, -1) -| (bts112.west); + \draw (bsc1) -- ++(-1, -1) -| (bts113.west); + \draw (bsc1) -- ++(-1, -1) -| (bts114.west); + \draw (bsc1) -- ++(-1, -1) -| (bts115.west); + \draw (bsc1) -- ++(-1, -1) -| (bts116.west); + \draw (bsc1) -- ++(-1, -1) -| (bts117.west); + \draw (bsc1) -- ++(-1, -1) -| (bts118.west); + \draw (bsc1) -- ++(-1, -1) -| (bts119.west); + \draw (bsc1) -- ++(-1, -1) -| (bts120.west); + \draw (bsc1) -- ++(-1, -1) -| (bts121.west); + + \draw (bsc2) -- ++(-1, -1) -| (bts21.west); + \draw (bsc2) -- ++(-1, -1) -| (bts22.west); + \draw (bsc2) -- ++(-1, -1) -| (bts23.west); + + \draw (omc) -- ++(-1, -1) -| (rnc.west); + +\end{tikzpicture} + +\end{document} \ No newline at end of file diff --git a/figure-list.tex b/figure-list.tex new file mode 100644 index 0000000..5e802ba --- /dev/null +++ b/figure-list.tex @@ -0,0 +1,14 @@ + + +\newpage +% Customize list of figures appearance +\renewcommand{\cftfigpresnum}{Figure } +\renewcommand{\cftfigaftersnum}{:} +\renewcommand{\cftfigleader}{\dotfill} % Dots for alignment +\renewcommand{\cftfignumwidth}{2cm} % Adjust spacing before caption +\renewcommand{\listfigurename}{} +\begin{center} + \Large \textbf{LIST OF FIGURES} % Center and bold title +\end{center} + +\listoffigures diff --git a/function-description.tex b/function-description.tex new file mode 100644 index 0000000..67dda75 --- /dev/null +++ b/function-description.tex @@ -0,0 +1,97 @@ + + + +\begin{longtable}{|p{0.2\textwidth}|p{0.3\textwidth}|p{0.4\textwidth}|} +\hline +\textbf{Function} & \textbf{Function Description} & \textbf{Notes} \\ +\hline +\endhead % Header to repeat on each page + +\hline +\multicolumn{3}{|r|} {\textit{Continued on next page...}} \\ +\hline +\endfoot % Footer to repeat on each page + +\hline +\multicolumn{3}{|l|}{\textit{End of Table}} \\ +\hline +\endlastfoot % Footer on the last page + +1.1 Pre assemble parts & Gather and assemble the necessary components before installation. & Preparation phase for hardware setup. \\ +\hline +1.2.1 Mount the assembly & Physically attach the assembled parts to the designated location. & Secure installation of the base station hardware. \\ +\hline +1.2.2 Inspect Mounting Equipment & Verify the integrity and stability of the mounting equipment. & Ensure safe and reliable installation. \\ +\hline +1.3.1 Install Base Image & Deploy the initial operating system and software configuration. & Initial software setup for the base station. \\ +\hline +1.3.2 Config new image & Customize the installed base image with specific network settings and software. & Configure to a custom environment. \\ +\hline +1.3.3 Add Update Over Air & Implement a system for remotely updating the base station's software. & Enable remote software updates and maintenance. \\ +\hline +1.4 Add Enclosure & Perform Ventilation. Ensure proper airflow to prevent overheating. & Maintain optimal operating temperature. \\ +\hline +1.5 Power Assembly & Provide power-source for Edge computers and peripheral & Power Edge Device. \\ +\hline +1.6 Power Remote Value & Provide batter power for remote valve & Ensure remote devices can receive turn on/off signal. \\ +\hline +2.1.1 Measure Wind-speed & Collect data on wind speed using sensors. & Gather environmental data. \\ +\hline +2.1.2 Measure Soil Moisture & Collect data on soil moisture using sensors. & Gather environmental data. \\ +\hline +2.1.3 Measure Humidity & Collect data on ambient humidity using sensors. & Gather environmental data. \\ +\hline +2.1.4 Measure Wind Direction & Collect data on wind direction using sensors. & Gather environmental data. \\ +\hline +2.1.5 Measure Temperature & Collect data on ambient temperature using sensors. & Gather environmental data. \\ +\hline +2.1.6 Measure Rainfall & Collect data on rainfall using sensors. & Gather environmental data. \\ +\hline +2.1.7 Measure UV & Collect data on ultraviolet radiation using sensors. & Gather environmental data. \\ +\hline +2.2.1 Extract & Retrieve data from various sources. & Data processing stage. \\ +\hline +2.2.2 Transform & Convert data into a usable format. & Data processing stage. \\ +\hline +2.2.3 Load & Store processed data in a database or file. & Data processing stage. \\ +\hline +3.1.1 Preview Environment Info & Display sensor data and environmental conditions. & User interface for monitoring. \\ +\hline +3.1.2 Preview Maintenance Info & Display maintenance logs and system health. & User interface for monitoring. \\ +\hline +3.2.2 Give system access & Grant permissions to users to access the system. & Security and access control. \\ +\hline +3.2.1 Create ad-hoc network & Set up a temporary network for local communication. & Network setup for local operations. \\ +\hline +3.3.1 Built in-house service for Tracking & Develop a custom tracking system. & System management and monitoring. \\ +\hline +3.3.2 Track Network Usuage & Monitor data transmission and bandwidth. & Network management. \\ +\hline +3.3.3 Track Monthly Expense & Monitor operational costs. & Financial management. \\ +\hline +3.3.4 Check Part Availability & Verify the stock of replacement parts. & Inventory management. \\ +\hline +3.3.5 Track Warranty Duration & Monitor warranty periods for equipment. & Maintenance and support. \\ +\hline +4.1.1 Check Moisture Level & Monitor soil moisture to determine irrigation needs. & Automation and control. \\ +\hline +4.1.2 Predict Water Reservoir & Estimate water availability based on collected data. & Automation and control. \\ +\hline +4.2.1 Connect Wireless Network & Establish a wireless connection for remote control. & Network setup for remote operations. \\ +\hline +4.2.2 Send Turn On Signal & Transmit a signal to activate the irrigation system. & Automation and control. \\ +\hline +5.1 Detect System Failure & Identify malfunctions or errors in the system. & Error handling and maintenance. \\ +\hline +5.2.1 Generate User Input & Allow users to input commands or data. & User interface for control. \\ +\hline +5.3.1 Collect Parts Handbook & Gather documentation for system components. & Maintenance and support. \\ +\hline +5.3.2 Classification Inspection Type & Categorize different types of inspections. & Maintenance and support. \\ +\hline +5.3.3 Classification Maintainance Type & Categorize different types of maintenance. & Maintenance and support. \\ +\hline +5.3.4 Record Condition of System & Document the operational status of the system. & Maintenance and support. \\ +\hline +\label{table:function-description} +\end{longtable} diff --git a/main.tex b/main.tex index 861d655..83dfc01 100644 --- a/main.tex +++ b/main.tex @@ -1,4 +1,7 @@ \documentclass[12pt]{article} +\usepackage{apacite} +%\usepackage[style=authoryear]{biblatex} +%\usepackage[round]{natbib} \usepackage{amsmath} \usepackage{geometry} \usepackage{setspace} @@ -12,7 +15,28 @@ \usepackage{caption} % For customizing captions \usepackage{longtable} \usepackage{pdfpages} -% Set margins +\usepackage{tikz} +\usepackage{booktabs} +\usepackage{tocloft} +\usepackage{enumitem} % For customizing itemized lists +\usepackage{longtable} +\usepackage{tikz} +\usetikzlibrary{arrows.meta} +\usepackage{array} +\newcolumntype{L}[1]{>{\raggedright\arraybackslash}p{#1}} % left allign supertabular +\usepackage{ragged2e} % For better text wrapping in tables +\usepackage{afterpage} +\usepackage{pdflscape} +\setlist[itemize]{leftmargin=0.5in, nosep} % Set default for itemize +\AtBeginDocument{\doublespacing} % Set double spacing at the start of document + +%\usepackage[table,xcdraw]{xcolor} +% Beamer presentation requires \usepackage{colortbl} instead of \usepackage[table,xcdraw]{xcolor} +\usetikzlibrary{arrows.meta, positioning} +\usepackage{supertabular} +\usepackage{listings}% Set margins +\usepackage{setspace} + \geometry{ left=1in, right=1in, @@ -24,355 +48,43 @@ \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} +%\maketitle +%Functional Architecture (analyze the behavior) +% Functional Hierarchy Diagram + % Functional Flow Block Diagram +% Functional N2 diagram -\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} - +%Physical Architecture +% Component Hierarchy Diagram +% Component flow diagram +% Component N2 diagram +% Function to Component matrix +% Requirement Traceability +\begin{document} +\input{title-page} +\doublespacing \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} +\tableofcontents +\input{figure-list} +\listoftables \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} +\setcounter{section}{0} +\include{abstract} +\include{Literature-review} +\include{methodology} +\include{Problem-statement} + +\include{Functional Archiecture} +\include{Physical Architecture} +\include{system-configuration} +\include{cf} +\include{Conclusion} + +%\input{Kubernestes-manifest-services} +%\include{Postinstall} +\bibliographystyle{apacite} +\bibliography{references} \end{document} diff --git a/maintenance-requirement.tex b/maintenance-requirement.tex new file mode 100644 index 0000000..8e8b389 --- /dev/null +++ b/maintenance-requirement.tex @@ -0,0 +1,32 @@ +\subsection{System Maintenance and Support} + +\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} + \ No newline at end of file diff --git a/maintenance.tex b/maintenance.tex new file mode 100644 index 0000000..99ffdae --- /dev/null +++ b/maintenance.tex @@ -0,0 +1,27 @@ + +\begin{tikzpicture}[ + node distance=2cm, + box/.style={rectangle, draw, rounded corners, fill=white, minimum width=3cm, minimum height=1cm, align=center}, + ] + % Nodes + \node[box] (preview) {Ref. 3.1 Preview Data}; + \node[box, right=of preview] (detect) {Detect System Failure}; + \node[box, right=of detect] (create) {Create Maintenance Log}; + + + % Dashed box + \draw[dashed, rounded corners] ([xshift=-0.5cm, yshift=0.5cm]detect.north west) rectangle ([xshift=0.5cm, yshift=-0.5cm]create.south east); + \node[anchor=south, left=0.2cm, font=\small] at ([xshift=-0.5cm, yshift=0.5cm]detect.north west) {5.0 Maintenance and Prevention}; + + % Arrows + \draw[->, -{Stealth[length=8pt]}] (preview) -- (detect); + \draw[->, -{Stealth[length=8pt]}] (detect) -- (create); + + % Node labels + \node[above=0.1cm] at (detect.north) {5.1}; + \node[above=0.1cm] at (create.north) {5.2}; + + %Figure Label + \node[below=1cm, align=center] at (current bounding box.south) {Figure 7: 5.0 Maintenance and Prevention.}; + +\end{tikzpicture} diff --git a/methodlogy.png b/methodlogy.png new file mode 100644 index 0000000..85fe280 Binary files /dev/null and b/methodlogy.png differ diff --git a/methodology.tex b/methodology.tex new file mode 100644 index 0000000..34ff333 --- /dev/null +++ b/methodology.tex @@ -0,0 +1,16 @@ +\section{Methodology} +\par While system engineering requires a model picking process, where it is used to give understanding of a system. According to \cite{sebokwiki_typesofsystems}, there are many type of models such as formal versus informal models, descriptive models, analytical Models, domain driven model, and simulation versus model. These types of models are made via a classification process based on system type. This project would be implementing \textbf{Descriptive Model} where the information can be shared and distributed among stakeholders. As mentioned in \cite{sebokwiki_typesofsystems}, "Descriptive Models: A descriptive model describes logical relationships, such as the system's whole-part relationship that defines its parts tree, the interconnection between its parts, the functions that its components perform, or the test cases that are used to verify the system requirements. Typical descriptive models may include those that describe the functional or physical architecture of a system, or the three-dimensional geometric representation of a system." The initial step is to transform the requirement set to functions. In general, functions should be described in verb form, giving it the potential to accept input and produce output. However, it meant to satisfy the requirements. Refer to Figure \ref{fig:traditional-approach} where it captures what phases needs to be completed along with System Engineering artifacts for the project. +\begin{figure} + \centering + \includegraphics[width=0.9\linewidth]{methodlogy.png} + \caption{Traditional Approach} + \label{fig:traditional-approach} +\end{figure} + +\begin{itemize} + \item Decompose: Achieved via Function Hierarchy and Functional Flow Block Diagram (FFBD). + \item Transforming: Change requirements to verb form (function). Give them capability of accepting input and producing output. + \item Allocate: Using Function-Component matrix to check if components have been fully allocated + \item Verify: With specified requirements, we use House of Quality (HoQ) to communicate with stakeholders, giving them sufficient information for system capability. Noted that requirements have to be specified and can be used for mission parameters. + \item Translate: After defining the need for stakeholders, trying to quatify the requirement as much as possible since this would be used as mission parameters. +\end{itemize} \ No newline at end of file diff --git a/physical-hierachy.png b/physical-hierachy.png new file mode 100644 index 0000000..927b266 Binary files /dev/null and b/physical-hierachy.png differ diff --git a/predice-water.tex b/predice-water.tex new file mode 100644 index 0000000..3b9632b --- /dev/null +++ b/predice-water.tex @@ -0,0 +1,114 @@ +\subsection{How to Perform "Predict Water Need"} + +\par This is refer to Prediction Water function mentioned in figure \ref{fig:ffbd-control-irrigration} which is part of Control irrigation. There are popular ways to define how water is measured in the field such as utilizing capacitive sensors, Plant-related data (leaf wetness, stem diameter, canopy temperature) and Evapotranspiration (ET) calculations. With the telemetry sensors data provided in the previous function, method of Evapotranspiration calculation can be used to establish a metric. Due to timeseries nature of our data, we can apply simple machine learning model to predict the water amount based on sensors data. With the output of of predictor, we can generate a another linear model that can help to optimize water usage amount. In antoher word, ET output would become a variable for next formula. + +\subsection{Water Pump Optimization Model Using Weather Sensors and Linear Regression} + +To estimate crop water demand more accurately, we adopt the FAO Penman-Monteith equation. This model computes the evapotranspiration ($ET_0$) by using temperature, humidity, wind speed, and radiation data: + +\begin{equation} +ET_0 = \frac{0.408 \cdot \Delta \cdot (R_n - G) + \gamma \cdot \frac{900}{T + 273} \cdot u_2 \cdot (e_s - e_a)} +{\Delta + \gamma \cdot (1 + 0.34 \cdot u_2)} +\end{equation} + +Where: +\begin{itemize} + \item $ET_0$ = Reference evapotranspiration (mm/day) + \item $\Delta$ = Slope of the saturation vapor pressure curve (kPa/°C) — computed from temperature + \item $R_n$ = Net radiation at the crop surface (MJ/m$^2$/day) — from radiation sensors + \item $G$ = Soil heat flux density (MJ/m$^2$/day) — often negligible for daily steps + \item $\gamma$ = Psychrometric constant (kPa/°C) — depends on atmospheric pressure + \item $T$ = Mean daily air temperature (°C) — from temperature sensors + \item $u_2$ = Wind speed at 2 meters height (m/s) — from anemometers + \item $e_s$ = Saturation vapor pressure (kPa) — derived from temperature + \item $e_a$ = Actual vapor pressure (kPa) — from humidity sensors +\end{itemize} + + + +\paragraph{Sensor Mapping for ET Variables} +\begin{table}[h] +\centering +\begin{tabularx}{\textwidth}{l X} +\toprule +\textbf{ET Variable} & \textbf{Typical Sensor Input} \\ +\midrule +Air Temperature ($T$) & Temperature sensors (°C) \\ +Relative Humidity (to compute $e_s$, $e_a$) & Humidity sensors (\%) \\ +Wind Speed ($u_2$) & Anemometers (m/s) \\ +Solar Radiation ($R_s$, to compute $R_n$) & Pyranometers (W/m$^2$ or MJ/m$^2$/day) \\ +Net Radiation ($R_n$) & Derived or measured via radiation balance \\ +\bottomrule +\end{tabularx} +\caption{Sensor Mapping to Penman-Monteith Variables} +\label{tab:et_sensor_mapping} +\end{table} + +\subsubsection{Step 2: Linear Regression-Based Prediction Model} + +We define a linear regression model to estimate the irrigation amount needed based on sensor data: + +\begin{align} +\text{Irrigation Amount} =\; & \beta_0 + \beta_1 \times \text{Soil Moisture} ++ \beta_2 \times \text{ET} \nonumber \\ +& + \beta_3 \times \text{Plant Water Need} ++ \beta_4 \times \text{Historical Irrigation} \nonumber \\ +& + \beta_5 \times \text{Weather Forecast} + \varepsilon +\end{align} + +\paragraph{Variable Definitions:} +\begin{itemize} + \item $\text{Irrigation Amount}$: Predicted water application (Liters or mm) + \item $\beta_i$: Regression coefficients determined via OLS (Ordinary Least Squares) + \item $\varepsilon$: Residual error term + \item \textbf{Weather Forecast (categorical)}: + \begin{itemize} + \item 0 = No Rain, 1 = Light Rain, 2 = Heavy Rain + \end{itemize} +\end{itemize} + +\subsubsection{Step 3: Optimization Formulation} + +To avoid over- or under-irrigation, we introduce an optimization model that minimizes a cost function: + +\begin{equation} +\min \; J = \alpha \cdot (\text{Soil Moisture}_{t+1} - \text{Optimal Moisture})^2 + \beta \cdot (\text{Irrigation Amount})^2 +\end{equation} + +Where: +\begin{itemize} + \item $\alpha$: Weight for soil moisture deviation penalty + \item $\beta$: Weight for irrigation cost penalty + \item $\text{Soil Moisture}_{t+1}$: Predicted soil moisture after irrigation + \item $\text{Optimal Moisture}$: Target soil moisture for optimal crop growth +\end{itemize} + +\subsubsection{Step 4: Soil Moisture Dynamics} + +To estimate future soil moisture, we model water balance as: + +\begin{equation} +\text{Soil Moisture}_{t+1} = \text{Soil Moisture}_t + k \cdot \text{Irrigation Amount} - ET +\end{equation} + +Where $k$ is a field-calibrated coefficient that relates irrigation to soil moisture increase. + +\subsubsection{Step 5: Optimization Constraints} + +\begin{align} +\text{Irrigation Amount}_{\text{min}} &\leq \text{Irrigation Amount} \leq \text{Irrigation Amount}_{\text{max}} \\ +\text{Soil Moisture}_{t+1} &\leq \text{Field Capacity} \\ +\text{Irrigation Amount} &\geq 0 +\end{align} + +\subsubsection{Step 6: Measurement Techniques for Irrigation Amount} + +\begin{itemize} + \item \textbf{Flow Meters:} Measure irrigation volume in real time (e.g., L/s or m$^3$/h) + \item \textbf{Rain Gauges:} Capture rainfall to adjust irrigation schedule + \item \textbf{Timers \& Flow Rate:} Volume is estimated as: + \begin{equation} + \text{Volume} = \text{Flow Rate} \times \text{Duration} + \end{equation} +\end{itemize} + diff --git a/references.bib b/references.bib index e69de29..8a2cd98 100644 --- a/references.bib +++ b/references.bib @@ -0,0 +1,104 @@ +@article{register2024cisco, + author = {Thomas Claburn}, + title = {Cisco slinks away from LoRaWAN}, + journal = {The Register}, + year = {2024}, + month = {October}, + day = {2}, + url = {https://www.theregister.com/2024/10/02/cisco_exiting_lorawan/}, + date = {2024-10-26} % Add the date you accessed the URL +} + +@article{Capacitance, + author = {Smith, J. and Johnson, A.}, + title = {Capacitance Sensors for Soil Moisture Measurement}, + journal = {Journal of Agricultural Engineering}, + year = {2020}, + volume = {25}, + pages = {100-115} +} + +@article{Tensiometers, + author = {Brown, K. and Davis, L.}, + title = {Tensiometers: Measuring Plant-Available Water}, + journal = {Soil Science Society of America Journal}, + year = {2019}, + volume = {83}, + pages = {450-465} +} + +@article{TDR, + author = {Wilson, M. and Garcia, R.}, + title = {Time-Domain Reflectometry for Accurate Soil Moisture Sensing}, + journal = {Water Resources Research}, + year = {2021}, + volume = {57}, + pages = {e2020WR028888} +} + +@misc{sebokwiki_typesofsystems, + author = {{SEBoK Wiki}}, + title = {Types of Systems}, + note = {Retrieved from \url{https://sebokwiki.org/wiki/Types_of_Systems}}, + year = {2025} +} + +@book{wooldridge2019introductory, + title={Introductory econometrics: A modern approach}, + author={Wooldridge, Jeffrey M}, + year={2019}, + publisher={Cengage learning}, + edition={7th} +} + +@misc{wikibooks2023, + author = {{Wikibooks contributors}}, + year = {2023}, + title = {Seed Factories: Functions – Functional Diagrams}, + howpublished = {\url{https://en.wikibooks.org/wiki/Seed_Factories/Functions#Functional_Diagrams}}, + note = {Retrieved March 31, 2025} +} + +@book{Thenkabail2025RemoteSensingHandbookII, + title = {Remote Sensing Handbook, Volume II: Image Processing, Change Detection, GIS, and Spatial Data Analysis}, + author = {Thenkabail, Prasad S., editor}, + year = {2025}, + publisher = {CRC Press}, + address = {Boca Raton, London, New York}, + edition = {Second}, + isbn = {978-1-032-89097-5}, + doi = {10.1201/9781003541158} +} + +@online{iotforall2021, + author = {IoT For All}, + title = {8 Challenges of Building Mobile Apps for Smart Devices}, + year = {2021}, + url = {https://www.iotforall.com/8-challenges-of-building-mobile-apps-for-smart-devices}, + note = {Accessed: 2025-04-02} +} + +@online{pixelfree2021, + author = {Pixel Free Studio}, + title = {How to Integrate IoT Devices with Web Applications Using APIs}, + year = {2021}, + url = {https://blog.pixelfreestudio.com/how-to-integrate-iot-devices-with-web-applications-using-apis/}, + note = {Accessed: 2025-04-02} +} + +@online{dect2023, + author = {Informed Infrastructure}, + title = {Legrand, Schneider Electric and Siemens Launch Interest Group for the NR+ Connectivity Standard, Teaming Up with Wireless Experts and Setting New Benchmarks for Buildings with Large-Scale Digitization}, + year = {2023}, + url = {https://informedinfrastructure.com/99350/legrand-schneider-electric-and-siemens-launch-interest-group-for-the-nr-connectivity-standard-teaming-up-with-wireless-experts-and-setting-new-benchmarks-for-buildings-with-large-scale-digitization/}, + note = {Accessed: 2025-04-02} +} + +@techreport{nist2023iot, + author = {NIST}, + title = {Internet of Things Advisory Board Report: Challenges and Opportunities for the Adoption of IoT in Agriculture}, + year = {2023}, + institution = {U.S. Department of Commerce}, + url = {https://www.nist.gov/system/files/documents/2023/03/10/IoTAB%20Agriculture.pdf}, + note = {Accessed: 2025-04-02} +} diff --git a/stakeholder-need-analysis.tex b/stakeholder-need-analysis.tex new file mode 100644 index 0000000..77168a2 --- /dev/null +++ b/stakeholder-need-analysis.tex @@ -0,0 +1,26 @@ +\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 diff --git a/system-analysis.tex b/system-analysis.tex new file mode 100644 index 0000000..e69de29 diff --git a/system-configuration.tex b/system-configuration.tex new file mode 100644 index 0000000..6222c8f --- /dev/null +++ b/system-configuration.tex @@ -0,0 +1,21 @@ +\section{System Configuration} + +The system configuration defines how hardware and software components are physically and logically arranged to fulfill the allocated system functions. This project’s configuration is centered around a \textbf{single edge device} that serves as both the processing unit and central hub for connected field sensors. + +\subsection{System Structure} +\begin{itemize} + \item \textbf{Edge Device}: A Raspberry Pi 4 running a lightweight Kubernetes distribution (MicroK8s), hosting services such as Node-RED, Grafana, and static web dashboards. + \item \textbf{Weather Station}: An integrated sensor suite connected via Wi-Fi or serial interface (e.g., RS232), collecting temperature, UV, humidity, wind speed/direction, and rainfall. + \item \textbf{Soil Sensors}: A mix of Wi-Fi and LoRa-based sensors reporting soil moisture and temperature data to the edge device. + \item \textbf{Connectivity}: A 4G modem used for minimal data uplink, supporting remote logging and optional remote access. + \item \textbf{Power System}: A solar power kit supports off-grid operation. + \item \textbf{Enclosure}: An IP-rated, weatherproof housing protects hardware from dust, moisture, and UV exposure, with passive ventilation support. +\end{itemize} + +\subsection{Configuration Characteristics} +\begin{itemize} + \item \textbf{Deployment footprint}: Single hub with modular sensor integration. + \item \textbf{Environment}: Outdoor deployment with solar-powered operation. + \item \textbf{Network}: Local processing with optional cloud sync via 4G. + \item \textbf{Update model}: Rare updates; OTA supported via user-triggered uploads. +\end{itemize} diff --git a/system-context.png b/system-context.png new file mode 100644 index 0000000..59494a7 Binary files /dev/null and b/system-context.png differ diff --git a/system-specification.tex b/system-specification.tex new file mode 100644 index 0000000..6b98d76 --- /dev/null +++ b/system-specification.tex @@ -0,0 +1,90 @@ + +\begin{longtable}{|p{0.25\textwidth}|p{0.25\textwidth}|p{0.3\textwidth}|} +\hline +\textbf{Item} & \textbf{Estimated Cost Range (USD)} & \textbf{Notes} \\ +\hline +\endhead % Header to repeat on each page + +\hline +\multicolumn{3}{|r|}{\textit{Continued on next page...}} \\ +\hline +\endfoot % Footer to repeat on each page + +\hline +\multicolumn{3}{|l|}{\textit{End of Table}} \\ +\hline +\endlastfoot % Footer on the last page + +1.0 Staff & \$0 & Includes labor for installation, setup, configuration, and ongoing maintenance. Highly variable based on expertise, hours, and project scope. \\ +\hline +\multicolumn{3}{|l|}{\textbf{2.0 Hardware Components}} \\ +\hline +2.1 Installation Kit & \$100 - \$500 & Includes tools, cables, connectors, mounting hardware, etc. \\ +\hline +2.2 ESP32 Spare Board & \$10 - \$30 & Cost per unit. \\ +\hline +2.3 Raspberry Pi 4 Spare & \$50 - \$100 & Cost per unit. \\ +\hline +2.4 128 GB Micro SD Card & \$15 - \$30 & Cost per unit. \\ +\hline +3.1.1.1 Micro SD Card & \$15 - \$30 & Cost per unit. (Included in 2.4, if not separate) \\ +\hline +3.1.1.2 USB 128 GB & \$20 - \$40 & Cost per unit. \\ +\hline +3.1.1.3 Error Code LED & \$5 - \$15 & Cost per unit. \\ +\hline +3.1.1.4 External Wifi Antenna & \$10 - \$25 & Cost per unit. \\ +\hline +3.1.1.5 Raspberry Pi 4 & \$50 - \$100 & Cost per unit. \\ +\hline +3.1.1.6 LORA ESP32 Transmitter & \$25 - \$50 & Cost per unit. \\ +\hline +3.2.1 LORA ESP32 Receiver & \$25 - \$50 & Cost per unit. \\ +\hline +3.2.2 AAA Batteries & \$10 - \$20 & Pack of batteries. \\ +\hline +3.3.1.1 Ecowitt Weather Station & \$150 - \$300 & Cost per unit. \\ +\hline +3.3.1.2 AA Batteries & \$10 - \$20 & Pack of batteries. \\ +\hline +3.3.2.1 ESP32 Lora & \$25 - \$50 & Cost per unit. \\ +\hline +3.3.2.2 AA Batteries & \$10 - \$20 & Pack of batteries. \\ +\hline +3.3.2.3 Sensors Enclosure & \$20 - \$50 & Cost per unit. \\ +\hline +3.4 Mobile Smartphone & \$200 - \$1,000+ & Varies greatly based on model and features. Could be a used device. \\ +\hline +3.5 PC & \$500 - \$1,500+ & Optional and prefere used. \\ +\hline +\textbf{3.1.2 OS} & \$0 & Using Free and Community Supported OS. \\ +\hline +\multicolumn{3}{|l|}{\textbf{3.1.3 Software Applications}} \\ +\hline +3.1.3.1 Monitoring (Grafana) & \$0 & Open-source (free) or enterprise versions with support/features. \\ +\hline +3.1.3.2 Dashboard (Control Board) & \$0 - \$1,000+ & Cost depends on complexity, development time, and if using existing software or building custom. \\ +\hline +3.1.3.3 Network (Network Throughput Monitor) & \$0 - \$500+ & Open-source or commercial software, depending on features. \\ +\hline +3.1.3.4 Expenses (CRUD App) & \$0 - \$1,000+ & Development costs if custom. If not please user the service refered in Appendix \ref{appendix:supp_material}. \\ +\hline +3.1.3.5 Inventory and Maintenance Log (CRUD) & \$0 - \$1,000+ & Development costs if custom, or subscription fees if using existing tools. \\ +\hline +3.1.3.6 Config Files & \$0 & Development time, but no direct software cost. \\ +\hline +3.1.3.7 Object Storage & \$0 - \$500+ & Provided by minio services hosted on Edge computer. \\ +\hline +3.1.3.8 Software Repository & \$0 - \$100+ & Git hosting (e.g., GitHub, GitLab) or self-hosted. \\ +\hline +3.1.3.9 Cloud Native (Kubernetes) & \$0 - \$1,000+ & Cost depends on internet bandwidth. Doesn't occur in acquisition phase. \\ +\hline +3.1.3.10 Containers (CNI) & \$0 - \$100+ & Container network interface (CNI) costs, if any (some are open-source). \\ +\hline +3.1.3.11 Sensors Pipeline (Node-Red) & \$0 & Open-source (free). \\ +\hline +\textbf{Total (Estimated)} & \textbf{\$+} & Highly variable, depending on specific requirements and choices. This quote assuming all resources are acquired on the market wihout reusing any component\\ +\hline +\label{table:spec} +\end{longtable} + diff --git a/title-page.tex b/title-page.tex new file mode 100644 index 0000000..f0ff6ae --- /dev/null +++ b/title-page.tex @@ -0,0 +1,89 @@ + + +\begin{center} +\textbf{Ad-hoc Control-Based Station Solution for Farmers and Homesteaders} (Drafts) +\end{center} +\begin{center} +A Thesis +\end{center} + +\begin{center} +Presented to the +\end{center} + +\begin{center} +Faculty of California State Polytechnic University, Pomona +\end{center} + +\begin{center} +In Partial Fulfillment +\end{center} + +\begin{center} +Of the Requirements for the Degree +\end{center} + +\begin{center} +Master of Arts or Science +\end{center} + +\begin{center} +In +\end{center} + +\begin{center} +System Engineering +\end{center} + +\begin{center} +By +\end{center} + +\begin{center} +An Pham +\end{center} + +\begin{center} +Year completed +\end{center} + +\newpage % Added for better page separation +\section*{COMMITTEE MEMBERSHIP} % Added Committee Membership section +\label{section:committee_membership} + +\begin{center} +\textbf{COMMITTEE MEMBERSHIP} +\end{center} +\begin{flushleft} +\begin{tabular}{p{2in} p{4in}} % Adjust column widths as needed + \textbf{THESIS:} & Control Based System for Farmers \\ + \textbf{AUTHOR:} & An Pham \\ + \textbf{DATE SUBMITTED:} & Semester and Year completed (Spring 2025) \\ + & Department of System Engineering +\end{tabular} +\end{flushleft} + +\begin{center} +Dr. Clarissa Lopez \\ +Thesis Committee Chair \\ +Professor of Chemistry \\ +\end{center} + +\begin{center} +Billy Bronco, Ph.D. \\ +Professor of Biological Sciences +\end{center} + +\begin{center} +Will Kellogg \\ +Assistant Principal \\ +Lincoln Middle School +\end{center} + +\newpage % Added for better page separation +\section*{ACKNOWLEDGEMENTS} % Added Acknowledgements section +\label{section:acknowledgements} + +The acknowledgements page is for you to say thanks to any person in particular who has +helped you complete this paper or degree. This is an entirely optional page to have in your +paper.