Update on Overleaf.

Conclusion.tex

@@ -1,6 +1,49 @@
 \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.
+\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 irrigation activity. Although 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 to maintain 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.
+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.
+
+
+% non AI readproof check
+Although the overall framework leans toward a Waterfall-like progression, the integration of verification planning and traceability enhances the rigor and alignment with V-Model principles. However, it is important to note that actual testing and validation procedures are outside the scope of this current phase. These steps—such as test case execution, performance validation, and operational scenario walkthrough—must be carried out in the system deployment phase to confirm that the system satisfies stakeholder needs and performs reliably under field conditions. The transition to V model as extension of Waterfall development life cycle requires  extending the interaction phase between stakeholders and requirements forming as mentioned in figure \ref{fig:sikorsky-vmodel}. While the requirements are verifiable, they also have to be considered in the well defined test cases which have constraints along with it. The extension can be described in figure \ref{fig:sikorsky-vmodel}bellowed. 
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=\textwidth]{requirement-testcase.png}
+    \caption{Sikorsky’s development and verification workflow adapted from Nick Kefalas, Sikorsky Aircraft / Lockheed Martin, presented at the EASA Rotorcraft \& VTOL Symposium 2019 \cite{easa2019kefalas}.}
+    \label{fig:sikorsky-vmodel}
+\end{figure}
+
+\begin{figure}
+    \centering
+    \includegraphics[width=0.75\linewidth]{vee-model.png}
+    \caption{Left Side of the Sequential Vee Model (INCOSE 2015, adapted from Forsberg, Mooz, and Cotterman 2005, Reprinted with permission of John Wiley \& Sons Inc. All other rights are reserved by the copyright owner.}
+    \label{fig:v-model}
+\end{figure}
+
+Roles and responsibilities were defined: the system engineer (the author) conducted system modeling, design, and traceability; the users—primarily farmers and homesteaders—are intended to handle installation, maintenance, and usage; and the open-source community plays an ongoing role in system support, particularly in software updates and extension modules.
+
+Key development milestones were guided by a Systems Engineering Management Plan (SEMP). The requirements analysis phase established the functional and non-functional needs. The conceptual design phase produced FFBDs, N-Diagrams, and function allocation tables. The component architecture phase defined the physical structure and cost estimates. The verification planning phase focused on mapping requirements for future testing. However, the deployment preparation which needs to be updated, factors such as strategies and configuration management not yet considered. In addition, the actual testing, validation, and iterative refinement phases (right side of V model figure \ref{fig:v-model})are essential next steps that must be addressed in future work or a follow-up implementation project.
+
+\begin{table}[H]
+\centering
+\caption{SEMP - Current Development Milestones}
+\renewcommand{\arraystretch}{1.2}
+\begin{tabular}{|p{0.3\textwidth}|p{0.6\textwidth}|}
+\hline
+\textbf{Phase} & \textbf{Deliverables} \\
+\hline
+Requirements Analysis & Functional and Non-Functional Requirements Documented \\
+\hline
+Conceptual Design & FFBDs, N-Diagrams, and Function Allocation Tables \\
+\hline
+Component Architecture & Component Hierarchy, Physical Flow Diagrams, and Cost Model \\
+\hline
+Verification Planning & Requirement Traceability Matrix and Test Preparation \\
+\hline
+Deployment Preparation & Configuration Table, Maintenance and Update Strategy (future work) \\
+\hline
+\end{tabular}
+\end{table}

Function-Allocation.tex

@@ -1,3 +1,4 @@
+\subsection{Function Allocation}
 \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}|}

Functional Archiecture.tex

@@ -1,5 +1,5 @@
-\section{Analyze System Behavior}
-\subsection{Function Hierarchy}
+\section{Functional Architecture}
+\subsection{Function Hierarchy Diagram}
 \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
@@ -74,26 +74,26 @@ At the first iteration, it's not important to consider the inner input and out o
 \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.
+\subsection{Functional N-Square Diagram}
+\par After completing the functional flow block diagram, we need to define what are the flows coming 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}
+    \caption{Functional 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.
+This diagram defines how the components interact and convey a broad 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 reflect 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}
+\caption{Functional N-Square Diagram Level 2 for 1.0 Deploy Assembly}
 { % Begin scriptsize block
 \small
 \begin{tabularx}{\linewidth}{|X|X|X|X|X|X|X|}
@@ -119,7 +119,7 @@ This diagram defines how the components interact and convey abroad communication
 \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}
+\caption{Functional N-Square 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|}
@@ -151,7 +151,7 @@ This diagram defines how the components interact and convey abroad communication
 \begin{table}[H]
 \renewcommand{\arraystretch}{0.7}
 \centering
-\caption{N-Diagram Level 3 for 3.2 Provide Mobile Services}
+\caption{Functional N-Square Diagram Level 3 for 3.2 Provide Mobile Services}
 { % Begin scriptsize block
 \scriptsize
 \begin{tabularx}{\linewidth}{|X|X|}
@@ -166,7 +166,7 @@ This diagram defines how the components interact and convey abroad communication
 
 \begin{table}[H]
 \centering
-\caption{N-Diagram level 3 for 1.2 Deploy the preassemble parts}
+\caption{Functional N-Square 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 \\
@@ -179,7 +179,7 @@ Load or weight amount & \textbf{1.2.2 Inspect Mounting Equipment}   \\
 \begin{table}[H]
 \renewcommand{\arraystretch}{0.7}
 \centering
-\caption{N-Diagram Level 3 for 5.3 Schedule Preventive Maintenance/Inspection}
+\caption{Functional N-Square Diagram Level 3 for 5.3 Schedule Preventive Maintenance/Inspection}
 { % Begin scriptsize block
 \scriptsize
 \begin{tabularx}{\linewidth}{|X|X|X|}
@@ -197,20 +197,20 @@ Load or weight amount & \textbf{1.2.2 Inspect Mounting Equipment}   \\
 \begin{table}[H]
 \renewcommand{\arraystretch}{0.7}
 \centering
-\caption{N-Diagram Level 3 for 3.3 Manage and Gather Resources}
+\caption{Functional N Square 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} & & & & & \\
+\textbf{3.3.1 Built In-House Service for Tracking} & & & &   \\
 \hline
-Graph & \textbf{3.3.2 Track Network Usage} & & & & \\
+Graph & \textbf{3.3.2 Track Network Usage} & & &  \\
 \hline
-Table & & \textbf{3.3.3 Track Monthly Expense} & & & \\
+Table & & \textbf{3.3.3 Track Monthly Expense} & &  \\
 \hline
-Table & & & \textbf{3.3.4 Check Part Availability} & & \\
+Table & & & \textbf{3.3.4 Check Part Availability} &  \\
 \hline
-Warranty Deadline & & & & \textbf{3.3.5 Check Warranty Duration} & \\
+Warranty Deadline & & & & \textbf{3.3.5 Check Warranty Duration}  \\
 \hline
 \end{tabularx}
 } % End scriptsize block
@@ -220,27 +220,9 @@ Warranty Deadline & & & & \textbf{3.3.5 Check Warranty Duration} & \\
 
 
 
-\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}
-\input{function-component-matrix}
+
 \newpage
 
 %\input{system-specification}

Physical Architecture.tex

@@ -1,7 +1,9 @@
 
 \section{Physical Architecture}
+\input{Function-Allocation}
+\newpage
 \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}
@@ -9,19 +11,22 @@
     \label{fig:enter-label}
 \end{figure}
 
+\input{function-description}
 \newpage
+\subsection{Component Flow Diagram}
 \begin{figure}[H]
     \centering
     \includegraphics[width=1\linewidth]{cpf-level1.png}
-    \caption{Component Flow Level 1 - Base Station System}
+    \caption{Component Flow Diagram 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}
+    \caption{Component Flow Diagram Level 2 - Edge Computer}
+    \label{fig:cfdl2}
 \end{figure}
+In figure \ref{fig:cfdl2}, the power will be provided to the hardware, then the hardware would power on to os. After that, the bi-directional communication between the os and the services is established. Both PC and Mobile Devices have the access to the OS. They also able to communicate with services via OS component.
 \begin{figure}[H]
     \centering
     \includegraphics[width=1\linewidth]{cpf-level2-2.png}
@@ -38,8 +43,9 @@
     \centering
     \includegraphics[width=1\linewidth]{cfd-level3-1.png}
     \caption{Component Flow Level 3 - Hardware}
-    \label{fig:enter-label}
+    \label{fig:cfl3}
 \end{figure}
+\par In Figure~\ref{fig:clf3}, the Raspberry Pi 4 is used as a central device to accept multiple inputs from transmitters and peripherals. Spare parts are provided in case the central unit fails or if essential components, such as the USB 128 GB used for storing sensor data or the transmitter, become non-functional.
 
 \begin{figure}
     \centering
@@ -49,8 +55,7 @@
 \end{figure}
 \newpage
 %%% N-Diagram %%%%
-\subsection{N-Diagram of Component Flow}
-
+\subsection{Component N- Square Diagram}
 
 \begin{longtable}[c]{|p{3cm}|p{3cm}|p{2cm}|p{2cm}|p{2cm}|}
 \caption{N-Diagram Component level 1}
@@ -163,7 +168,7 @@ net info & & \textbf{2.3.3 Network (Throughput)} & & & & & & & & \\
 \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 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 be performed to meet the requirements deprived of 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:
@@ -178,10 +183,9 @@ This separation allows better control over resource allocation and horizontal sc
 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.
-
+\input{function-component-matrix}
 \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}

Problem-statement.tex

@@ -33,63 +33,70 @@ The second approach, the Remote Image Capture System (RICS), uses a camera stati
 \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.
+The design of the control base system should meet 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.
-
+\begin{longtable}{|p{2cm}|p{13cm}|}
+\caption{Requirement List Grouped by Requirement Type} \label{tab:requirement-list} \\
+\hline
+\textbf{Req. ID} & \textbf{Requirement Description} \\
+\hline
+\endfirsthead
+
+\hline
+\textbf{Req. ID} & \textbf{Requirement Description} \\
+\hline
+\endhead
+
+\multicolumn{2}{|l|}{\textbf{Functional Requirements}} \\
+\hline
+REQ-01 & System must provide coverage of 1,000 square feet. \\
+REQ-02 & The system should be able to turn on or turn off irrigation pumps. \\
+REQ-03 & System must be able to support the following wireless communication protocols: LORA, WiFi 2.4GHz, WiFi 5.0GHz. \\
+REQ-04 & Farmers should receive updated data every 3-5 minutes. \\
+REQ-05 & Farmers should be able to view weather data daily. \\
+REQ-06 & The system must be exposed to UV sunlight. \\
+REQ-07 & The system can operate in outdoor environments below 100°F. \\
+REQ-08 & The system can withstand 40 mph - 50 mph wind speed. \\
+REQ-09 & System must support being connected over-the-air. \\
+REQ-10 & Enable remote access protocol. \\
+REQ-11 & System should take less than 30 minutes to mount. \\
+REQ-12 & System only allows 90 minutes downtime. \\
+REQ-13 & System should take 90 minutes to install software for the system. \\
+REQ-14 & System must take two hours to deploy. \\
+REQ-15 & System must be able to operate without grid electricity. \\
+REQ-16 & System must measure factors such as UV radiation, wind speed, wind direction, rainfall, and soil moisture. \\
+REQ-17 & System must support mobile devices. \\
+REQ-18 & System must automatically restart when a malfunction is detected. \\
+REQ-19 & The chance of the system going down must be less than 10 percent. \\
+\hline
+\multicolumn{2}{|l|}{\textbf{Economic Factors}} \\
+\hline
+REQ-20 & Annual operation cost should not exceed \$200. \\
+REQ-21 & System parts or modules must be available on the market for the next 5 years. \\
+REQ-22 & About 80 percent of the parts should be recyclable or reused. \\
+REQ-23 & The system should last more than a 5-year lifespan. \\
+REQ-24 & The parts can be salvaged with a price of 30 percent of the initial purchasing cost. \\
+\hline
+\multicolumn{2}{|l|}{\textbf{Design Constraints}} \\
+\hline
+REQ-25 & The system’s weight must be below 50 pounds. \\
+REQ-26 & It should be built within a \$1000 budget. \\
+\hline
+\multicolumn{2}{|l|}{\textbf{Operational Life Cycle}} \\
+\hline
+REQ-21 & System parts or modules must be available on the market for replacement. \\
+REQ-22 & About 80 percent of the parts should be recyclable or reused. \\
+\hline
+\multicolumn{2}{|l|}{\textbf{Non-Functional Requirements}} \\
+\hline
+REQ-27 & Latency for farmers to access the system is 0-30 seconds. \\
+REQ-28 & System must provide data redundancy. \\
+REQ-29 & Data will be collected for a 3-year period. \\
+REQ-30 & Data must be transmitted securely over the air. \\
+\hline
+\end{longtable}
 \newpage
 
 

Requirement-traceability.tex

@@ -1,4 +1,9 @@
-\begin{longtable}{|p{1.5cm}|p{5.5cm}|p{3cm}|p{3cm}|p{3cm}|}
+\begin{longtable}{|>{\raggedright\arraybackslash}p{1.5cm}|
+                  >{\raggedright\arraybackslash}p{5.5cm}|
+                  >{\raggedright\arraybackslash}p{3cm}|
+                  >{\raggedright\arraybackslash}p{3cm}|
+                  >{\raggedright\arraybackslash}p{3cm}|}
+
 \caption{Full Requirement Traceability Matrix} \label{tab:traceability} \\
 \hline
 \textbf{ID} & \textbf{Requirement Description} & \textbf{Source} & \textbf{Verification Method} & \textbf{Status} \\

cf.tex

@@ -1,8 +1,8 @@
 
-\subsection{6.5 Lifecycle Cost Planning and TVM Analysis}
+\subsection{Lifecycle Cost Planning and Time Value Money (TVM) Analysis}
 
 \begin{center}
-\textbf{Cash Flow Diagram for Control-Based Station (5-Year Lifecycle)}
+\textbf{Updated Cash Flow Diagram for Control-Based Station (5-Year Lifecycle)}
 \end{center}
 
 \begin{tikzpicture}[>=Stealth, scale=1, every node/.style={scale=1}]
@@ -13,72 +13,33 @@
   }
 
   % Year 0 - Initial Investment
-  \draw[->, thick] (0,0) -- (0,-3) node[below] {- \$1000};
+  \draw[->, thick] (0,0) -- (0,-2.65) node[below] {- \$530};
 
   % 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};
+    \draw[->, thick] (\x,0) -- (\x,-1.2) node[below] at (\x,-1.4) {- \$120};
   }
 
   % Year 5 - Annual Cost + Salvage
-  \draw[->, thick] (5,0) -- (5,-1) node[below left] {- \$100};
+  \draw[->, thick] (5,0) -- (5,-1.2) node[below left] {- \$120};
   \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};
+  \node at (3,-4.2) {Cash Outflows = CAPEX \& OPEX};
+  \node at (5.8,2.4) {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.
+\par \textbf{Cost Constrain:} 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}
+\caption{Estimated First-Year and Annual Operating Costs for Current System}
 \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 & -- \\
+Sensors (Weather Station + Soil Moisture Sensor)    & \$200 & -- \\
 4G Modem + SIM Hardware                    & \$50  & -- \\
 Solar Power Kit + Battery Storage          & \$150 & -- \\
 Weatherproof Enclosure                     & \$30  & -- \\
@@ -94,3 +55,98 @@ Cloud/Remote Logging (Optional)            & --    & \$60 \\
 \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.
 
+Performing Trade-off study for not using alternatives as mentioned in House of Quality (figure \ref{fig:hoq})
+\begin{table}[H]
+\centering
+\caption{10-Year Cost Comparison: Control-Based vs. Azure IoT System}
+\begin{tabular}{|p{0.3\textwidth}|l|l|}
+\hline
+\textbf{Item} & \textbf{Control-Based System (USD)} & \textbf{Azure IoT System (USD)} \\
+\hline
+Initial Hardware Cost & \$530 & \$300 \\
+10-Year Subscription Cost & \$0 & \$1,800 \\
+10-Year Operating Cost & \$1,200 & \$1,200 \\
+Salvage Value (End of Year 10) & -\$200 & \$0 \\
+\hline
+\textbf{Total Lifecycle Cost} & \textbf{\$1,530} & \textbf{\$3,300} \\
+\hline
+\end{tabular}
+\label{tab:10year-cost-comparison}
+\end{table}
+
+\begin{table}[H]
+\centering
+\caption{Detailed Annual Operating Cost Estimate}
+\renewcommand{\arraystretch}{1.2}
+\begin{tabular}{lll}
+\hline
+Cost Item                          & Annual Estimate   & Notes \\
+\hline
+Replacement batteries \& parts      & \$40               & Rechargeables for sensors, valve batteries \\
+Occasional sensor replacement      & \$50               & 1–2 sensors/year \\
+Manual maintenance time (labor)    & \$50–\$70           & Self-service \\
+Data storage backup (USB rotation) & \$20               & Flash drives \\
+Cloud Services (avoided)           & \$0                & Azure IoT Central typically charges \$5–10 per device/month ⇒ saved \$60–\$120/year \\
+Total Annual Cost                  & \textasciitilde{}\$160             & Under target \$ 200\\
+\hline
+\end{tabular}
+\end{table}
+
+\begin{table}[H]
+\centering
+\caption{Financial Model Input Parameters}
+\renewcommand{\arraystretch}{1.2}
+\begin{tabular}{lr}
+\hline
+Category                &     Value \\
+\hline
+Initial Cost (B)        &    625    \\
+Annual Income (Benefit) & 180000    \\
+Annual Operating Cost   &    160    \\
+Net Annual Cash Flow    & 179840    \\
+Discount Rate (MARR)    &      0.12 \\
+\hline
+\end{tabular}
+\end{table}
+
+\newpage
+\begin{landscape}
+\begin{table}[H]
+\centering
+\caption{6-Year Financial Model with MACRS 5-Year Depreciation (Landscape)}
+\resizebox{\linewidth}{!}{%
+\begin{tabular}{rrrrrrrr}
+\hline
+Year & BTCF & MACRS Dep Rate & MACRS Dep Deduction & Book Value & Taxable Income & Income Taxes & ATCF \\
+\hline
+0 & -625   & 0       & 0    & 625  & -125  & 0 & -625   \\
+1 & 179840 & 0.20    & 125  & 500  & -200  & 0 & 179840 \\
+2 & 179840 & 0.32    & 200  & 300  & -120  & 0 & 179840 \\
+3 & 179840 & 0.192   & 120  & 180  & -72   & 0 & 179840 \\
+4 & 179840 & 0.1152  & 72   & 108  & -72   & 0 & 179840 \\
+5 & 179840 & 0.1152  & 72   & 36   & -36   & 0 & 179840 \\
+6 & 179840 & 0.0576  & 36   & 0    & 0     & 0 & 179840 \\
+\hline
+\end{tabular}%
+}
+\end{table}
+
+\begin{table}[H]
+\centering
+\caption{NPV and IRR Computation for 6-Year Financial Model}
+\renewcommand{\arraystretch}{1.2}
+\begin{tabular}{ll}
+\hline
+Metric & Value \\
+\hline
+Initial Investment (Year 0) & \(-\$625\) \\
+Net Annual Cash Flow (Years 1–6) & \$179,840 \\
+Discount Rate (MARR) & 12\% \\
+Net Present Value (NPV) & \$851,222.79 \\
+Internal Rate of Return (IRR) & 2882.7\% \\
+\hline
+\end{tabular}
+\end{table}
+
+\end{landscape}
+

function-component-matrix.tex

@@ -1,3 +1,4 @@
+\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}
 % Function to Component Matrix (Split Landscape)
 
 \begin{landscape}

function-description.tex

@@ -1,7 +1,8 @@
 
+\begin{longtable}{|>{\raggedright\arraybackslash}p{0.2\textwidth}|
+                    >{\raggedright\arraybackslash}p{0.3\textwidth}|
+                    >{\raggedright\arraybackslash}p{0.4\textwidth}|}
 
-
-\begin{longtable}{|p{0.2\textwidth}|p{0.3\textwidth}|p{0.4\textwidth}|}
 \hline
 \textbf{Function} & \textbf{Function Description} & \textbf{Notes} \\
 \hline

references.bib

@@ -102,3 +102,11 @@
   url          = {https://www.nist.gov/system/files/documents/2023/03/10/IoTAB%20Agriculture.pdf},
   note         = {Accessed: 2025-04-02}
 }
+@misc{easa2019kefalas,
+  author = {Nick Kefalas},
+  title = {Sikorsky's Approach to Rotorcraft Safety and Innovation},
+  year = {2019},
+  note = {Presented at the EASA Rotorcraft \& VTOL Symposium},
+  organization = {Sikorsky Aircraft / Lockheed Martin},
+  url = {https://www.easa.europa.eu/newsroom-and-events/events/easa-rotorcraft-and-vtol-symposium-2019}
+}