Author | SHA1 | Message | Date |
---|---|---|---|
|
1a72a41bb2 | add .secret | 1 month ago |
|
cb9c3fea8f | update main.toc | 1 month ago |
|
5cd9bd1559 | Update on Overleaf. | 1 month ago |
|
5f5fa9c3dc | Update on Overleaf. | 1 month ago |
@ -0,0 +1 @@ | |||
.secret |
@ -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} |
@ -0,0 +1,262 @@ | |||
\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} | |||
\begin{scriptsize} | |||
\begin{longtable}{lllllllllllllllllllll} | |||
\caption{Function to Component Matrix (Part 1)} | |||
\label{tab:func-comp-matrix-1}\\ | |||
\toprule | |||
Function ID & C1 & C2 & C3 & C4 & C5 & C6 & C7 & C8 & C9 & C10 & C11 & C12 & C13 & C14 & C15 & C16 & C17 & C18 & C19 & C20 \\ | |||
\midrule | |||
\endfirsthead | |||
\caption[]{Function to Component Matrix (Part 1)} \\ | |||
\toprule | |||
Function ID & C1 & C2 & C3 & C4 & C5 & C6 & C7 & C8 & C9 & C10 & C11 & C12 & C13 & C14 & C15 & C16 & C17 & C18 & C19 & C20 \\ | |||
\midrule | |||
\endhead | |||
\midrule | |||
\multicolumn{21}{r}{{Continued on next page}} \\ | |||
\midrule | |||
\endfoot | |||
\bottomrule | |||
\endlastfoot | |||
F1 & x & & & & & & & & & & & & & & & & & & & \\ | |||
F2 & x & & & & & & & & & & & & & & & & & & & \\ | |||
F3 & x & & & & & & & & & & & & & & & & & & & \\ | |||
F4 & x & x & & & & & & & & & & & & & & & & & & \\ | |||
F5 & x & x & & & & & & & & & & & & & & & & & & \\ | |||
F6 & x & x & & & & & & & & & & & & & & & & & & \\ | |||
F7 & x & & & & & & & & & & & & & & & & & & & \\ | |||
F8 & x & & & & & & & & & & & & & & & & & & & \\ | |||
F9 & x & & & & & & & & & & & & & & & & & & & \\ | |||
F10 & & & & & & & & & & & & & & & & & & & & \\ | |||
F11 & & & & & x & & & & & & & & & & & & & & & \\ | |||
F12 & & & & & & x & & & & & & & & & & & & & & \\ | |||
F13 & & & & & & & x & & & & & & & & & & & & & \\ | |||
F14 & & & & & & & & x & & & & & & & & & & & & \\ | |||
F15 & & & & & & & & & x & & & & & & & & & & & \\ | |||
F16 & & & & & & & & & & x & & & & & & & & & & \\ | |||
F17 & & & & & & & & & & & x & & & & & & & & & \\ | |||
F18 & & & & & & & & & & & & x & & & & & & & & \\ | |||
F19 & & & & & & & & & & & & & x & & & & & & & \\ | |||
F20 & & & & & & & & & & & & & x & & & & & & & \\ | |||
F21 & & & & & & & & & & & & & x & & & & & & & \\ | |||
F22 & & & & & & & & & & & & & & x & & & & & & \\ | |||
F23 & & & & & & & & & & & & & & & x & & & & & \\ | |||
F24 & & & & & & & & & & & & & & & & x & & & & \\ | |||
F25 & & & & & & & & & & & & & & & & x & & & & \\ | |||
F26 & & & & & & & & & & & & & & & & & x & & & \\ | |||
F27 & & & & & & & & & & & & & & & & & & x & & \\ | |||
F28 & & & & & & & & & & & & & & & & & & & x & \\ | |||
F29 & & & & & & & & & & & & & & & & & & & & x \\ | |||
F30 & & & & & & & & & & & & & & & & & & & & \\ | |||
F31 & & & & & & & & & & & & & & & & & & & & \\ | |||
F32 & & & & & & & & & & & & & & & & & & & & \\ | |||
F33 & & & & & & & & & & & & & & & & & & & & \\ | |||
F34 & & & & & & & & & & & & & & & & & & & & \\ | |||
F35 & & & & & & & & & & & & & & & & & & & & \\ | |||
F36 & & & & & & & & & & & & & & & & & & & & \\ | |||
F37 & & & & & & & & & & & & & & & & & & & & \\ | |||
F38 & & & & & & & & & & & & & & & & & & & & \\ | |||
F39 & & & & & & & & & & & & & & & & & & & & \\ | |||
F40 & & & & & & & & & & & & & & & & & & & & \\ | |||
F41 & & & & & & & & & & & & & & & & & & & & \\ | |||
F42 & & & & & & & & & & & & & & & & & & & & \\ | |||
\end{longtable} | |||
\newpage | |||
\begin{longtable}{lllllllllllllllllllll} | |||
\caption{Function to Component Matrix (Part 2)} | |||
\label{tab:func-comp-matrix-2}\\ | |||
\toprule | |||
Function ID & C21 & C22 & C23 & C24 & C25 & C26 & C27 & C28 & C29 & C30 & C31 & C32 & C33 & C34 & C35 & C36 & C37 & C38 & C39 & C40 \\ | |||
\midrule | |||
\endfirsthead | |||
\caption[]{Function to Component Matrix (Part 2)} \\ | |||
\toprule | |||
Function ID & C21 & C22 & C23 & C24 & C25 & C26 & C27 & C28 & C29 & C30 & C31 & C32 & C33 & C34 & C35 & C36 & C37 & C38 & C39 & C40 \\ | |||
\midrule | |||
\endhead | |||
\midrule | |||
\multicolumn{21}{r}{{Continued on next page}} \\ | |||
\midrule | |||
\endfoot | |||
\bottomrule | |||
\endlastfoot | |||
F1 & & & & & & & & & & & & & & & & & & & & \\ | |||
F2 & & & & & & & & & & & & & & & & & & & & \\ | |||
F3 & & & & & & & & & & & & & & & & & & & & \\ | |||
F4 & & & & & & & & & & & & & & & & & & & & \\ | |||
F5 & & & & & & & & & & & & & & & & & & & & \\ | |||
F6 & & & & & & & & & & & & & & & & & & & & \\ | |||
F7 & & & & & & & & & & & & & & & & & & & & \\ | |||
F8 & & & & & & & & & & & & & & & & & & & & \\ | |||
F9 & & & & & & & & & & & & & & & & & & & & \\ | |||
F10 & & & & & & & & & & & & & & & & & & & & \\ | |||
F11 & & & & & & & & & & & & & & & & & & & & \\ | |||
F12 & & & & & & & & & & & & & & & & & & & & \\ | |||
F13 & & & & & & & & & & & & & & & & & & & & \\ | |||
F14 & & & & & & & & & & & & & & & & & & & & \\ | |||
F15 & & & & & & & & & & & & & & & & & & & & \\ | |||
F16 & & & & & & & & & & & & & & & & & & & & \\ | |||
F17 & & & & & & & & & & & & & & & & & & & & \\ | |||
F18 & & & & & & & & & & & & & & & & & & & & \\ | |||
F19 & & & & & & & & & & & & & & & & & & & & \\ | |||
F20 & & & & & & & & & & & & & & & & & & & & \\ | |||
F21 & & & & & & & & & & & & & & & & & & & & \\ | |||
F22 & & & & & & & & & & & & & & & & & & & & \\ | |||
F23 & & & & & & & & & & & & & & & & & & & & \\ | |||
F24 & & & & & & & & & & & & & & & & & & & & \\ | |||
F25 & & & & & & & & & & & & & & & & & & & & \\ | |||
F26 & & & & & & & & & & & & & & & & & & & & \\ | |||
F27 & & & & & & & & & & & & & & & & & & & & \\ | |||
F28 & & & & & & & & & & & & & & & & & & & & \\ | |||
F29 & & & & & & & & & & & & & & & & & & & & \\ | |||
F30 & x & & & & & & & & & & & & & & & & & & & \\ | |||
F31 & & x & & & & & & & & & & & & & & & & & & \\ | |||
F32 & & & x & & & & & & & & & & & & & & & & & \\ | |||
F33 & & & & x & & & & & & & & & & & & & & & & \\ | |||
F34 & & & & x & x & & & & & & & & & & & & & & & \\ | |||
F35 & & & & & & x & & & & & & & & & & & & & & \\ | |||
F36 & & & & & & & x & & & & & & & & & & & & & \\ | |||
F37 & & & & & & & & x & & & & & & & & & & & & \\ | |||
F38 & & & & & & & & & x & & & & & & & & & & & \\ | |||
F39 & & & & & & & & & & x & & & & & & & & & & \\ | |||
F40 & & & & & & & & & & & x & & & & & & & & & \\ | |||
F41 & & & & & & & & & & & & x & & & & & & & & \\ | |||
F42 & & & & & & & & & & & & & x & & & & & & & \\ | |||
\end{longtable} | |||
\end{scriptsize} | |||
\end{landscape} | |||
% Function Dictionary | |||
\begin{longtable}{ll} | |||
\caption{Function Dictionary} | |||
\label{tab:function-dict}\\ | |||
\toprule | |||
Function ID & Function Description \\ | |||
\midrule | |||
\endfirsthead | |||
\caption[]{Function Dictionary} \\ | |||
\toprule | |||
Function ID & Function Description \\ | |||
\midrule | |||
\endhead | |||
\midrule | |||
\multicolumn{2}{r}{{Continued on next page}} \\ | |||
\midrule | |||
\endfoot | |||
\bottomrule | |||
\endlastfoot | |||
F1 & 1.1 Pre assemble \\ | |||
F2 & 1.2.1 Mount assembly \\ | |||
F3 & 1.2.2 Inspect Mounting Equipment \\ | |||
F4 & 1.3.1 Install Base Image \\ | |||
F5 & 1.3.2 Config new image \\ | |||
F6 & 1.3.3 Add Update Over Air \\ | |||
F7 & 1.3.4 Replicate Raspberry pi Images and Storage... \\ | |||
F8 & 1.3.5 Flashing ESP32 for fail-over \\ | |||
F9 & 1.4 Add Enclosure \\ | |||
F10 & 1.5 Power Assembly \\ | |||
F11 & 2.1.1 Measure Windspeed \\ | |||
F12 & 2.1.2 Measure Soil Moisture (wifi based) \\ | |||
F13 & 2.1.3 Measure Humidity \\ | |||
F14 & 2.1.4 Measure Wind Direction \\ | |||
F15 & 2.1.5 Measure Temperature \\ | |||
F16 & 2.1.6 Measure Rainfall \\ | |||
F17 & 2.1.7 Measure UV \\ | |||
F18 & 2.1.8 Measure Moisture (LoRa Based) \\ | |||
F19 & 2.2.1 Extract \\ | |||
F20 & 2.2.2 Transform \\ | |||
F21 & 2.2.3 Load \\ | |||
F22 & 2.3.1 Power Wifi Sensors \\ | |||
F23 & 2.3.2 Power LORA Sensors \\ | |||
F24 & 3.1.1 Preview Environment Info \\ | |||
F25 & 3.1.2 Preview Maintenance Info \\ | |||
F26 & 3.2.2 Give system access. \\ | |||
F27 & 3.2.1 Create ad-hoc network. \\ | |||
F28 & 3.3.1 Built in-house service for Tracking \\ | |||
F29 & 3.3.2 Track Network Usuage \\ | |||
F30 & 3.3.3 Track Monthly Expense \\ | |||
F31 & 3.3.4 Check Part Availability \\ | |||
F32 & 3.3.5 Track Warranty Duration \\ | |||
F33 & 4.1.1 Check Moisture Level \\ | |||
F34 & 4.1.2 Predict Water Reservoir \\ | |||
F35 & 4.2.1 Connect Wireless Network \\ | |||
F36 & 4.2.2 Send Turn On Signal. \\ | |||
F37 & 5.1 Detect System Failure. \\ | |||
F38 & 5.2.1 Generate User Input. \\ | |||
F39 & 5.3.1 Collect Parts Handbook. \\ | |||
F40 & 5.3.2 Classification Inspection Type. \\ | |||
F41 & 5.3.3 Classification Maintainance Type. \\ | |||
F42 & 5.3.4 Record Condition of System. \\ | |||
\end{longtable} | |||
% Component Dictionary | |||
\begin{longtable}{ll} | |||
\caption{Component Dictionary} | |||
\label{tab:component-dict}\\ | |||
\toprule | |||
Component ID & Component Description \\ | |||
\midrule | |||
\endfirsthead | |||
\caption[]{Component Dictionary} \\ | |||
\toprule | |||
Component ID & Component Description \\ | |||
\midrule | |||
\endhead | |||
\midrule | |||
\multicolumn{2}{r}{{Continued on next page}} \\ | |||
\midrule | |||
\endfoot | |||
\bottomrule | |||
\endlastfoot | |||
C1 & 1.0 Technician \\ | |||
C2 & 2.0 Edge Computer \\ | |||
C3 & 2.1 Hardware \\ | |||
C4 & 2.1.1 Micro SD Card \\ | |||
C5 & 2.1.2 USB 128 GB \\ | |||
C6 & 2.1.3 Error Code LED \\ | |||
C7 & 2.1.4 External WIFI attena \\ | |||
C8 & 2.1.5 Raspberry pi4 \\ | |||
C9 & 2.1.6 LORA ESP 32 Transmitter \\ | |||
C10 & 2.1.7 LORA EASP 32 BOARD (SPARE-not installed) \\ | |||
C11 & 2.1.8 Raspberry pi 4 (Spare) \\ | |||
C12 & 2.1.9 Micro SD card (Spare) \\ | |||
C13 & 2.1.10 Real Time Clock \\ | |||
C14 & 2.2 OS \\ | |||
C15 & 2.3 Services \\ | |||
C16 & 2.3.1 Monitoring (grafana) \\ | |||
C17 & 2.3.2 Dashboard (Control Board) \\ | |||
C18 & 2.3.3 Network (Network Throughput) \\ | |||
C19 & 2.3.4 Expenses (CRUD web app) \\ | |||
C20 & 2.3.5 Inventory and Maintenance (CRUD web app) \\ | |||
C21 & 2.3.6 Config Files \\ | |||
C22 & 2.3.7 Object Storage (Minio) \\ | |||
C23 & 2.3.9 Cloud Native (Kubernetes) \\ | |||
C24 & 2.3.10 Containers (CNI) \\ | |||
C25 & 2.3.11 Sersors Pipeline (Node-red Software) \\ | |||
C26 & 2.4 PC \\ | |||
C27 & 2.5 Mobile \\ | |||
C28 & 2.6 Print-out Chart \\ | |||
C29 & 3.0 Sensors \\ | |||
C30 & 3.1 Ecowitth Weather Station \\ | |||
C31 & 3.2 AA Battries \\ | |||
C32 & 3.3 ESP 32 Lora Receiver \\ | |||
C33 & 3.4 AA Batteries \\ | |||
C34 & 3.5 Sensors Enclousure \\ | |||
C35 & 3.6 Flow Meters \\ | |||
C36 & 4.0 Smart Valve \\ | |||
C37 & 4.1 LORA ESP32 Receiver \\ | |||
C38 & 4.2 AAA Batteries \\ | |||
C39 & 5.0 Installation Kit \\ | |||
C40 & 5.1 Pre-assemble Instruction Kit \\ | |||
\end{longtable} |
@ -0,0 +1,23 @@ | |||
\contentsline {section}{\numberline {1}Problem Definition and Identification of Need}{2}{}% | |||
\contentsline {subsection}{\numberline {1.1}Problem Definition and Definition of Need}{2}{}% | |||
\contentsline {section}{\numberline {2}System Design and Feasibility Analysis}{4}{}% | |||
\contentsline {subsection}{\numberline {2.1}Stakeholder Need Analysis}{4}{}% | |||
\contentsline {subsection}{\numberline {2.2}Feasibility Analysis}{5}{}% | |||
\contentsline {subsubsection}{\numberline {2.2.1}Operating and Deploying Farming Drones}{5}{}% | |||
\contentsline {subsubsection}{\numberline {2.2.2}Control-Based Station}{6}{}% | |||
\contentsline {subsubsection}{\numberline {2.2.3}Image Capturing with AI Integration}{6}{}% | |||
\contentsline {subsection}{\numberline {2.3}Multi Criteria Decision making (AHP method).}{7}{}% | |||
\contentsline {subsection}{\numberline {2.4}Operational Requirement}{10}{}% | |||
\contentsline {subsection}{\numberline {2.5}System Maintenance and Support - WIP}{12}{}% | |||
\contentsline {section}{\numberline {3}Analyze System Behavior}{15}{}% | |||
\contentsline {subsection}{\numberline {3.1}House of Quality}{15}{}% | |||
\contentsline {subsection}{\numberline {3.2}Function Hierarchy}{17}{}% | |||
\contentsline {subsubsection}{\numberline {3.2.1}Functional Flow Block Diagram (FFBD)}{18}{}% | |||
\contentsline {subsection}{\numberline {3.3}N-Square Diagram}{24}{}% | |||
\contentsline {subsection}{\numberline {3.4}Function Allocation}{28}{}% | |||
\contentsline {subsection}{\numberline {3.5}Functions Description}{29}{}% | |||
\contentsline {section}{\numberline {4}Analyze Physical Architecture - Components extracted from Function Allocation}{29}{}% | |||
\contentsline {subsection}{\numberline {4.1}Physical Component Hierarchy}{29}{}% | |||
\contentsline {subsection}{\numberline {4.2}N-Diagram of Component Flow}{32}{}% | |||
\contentsline {subsection}{\numberline {4.3}Shipping components for Functions}{34}{}% | |||
\contentsline {subsubsection}{\numberline {4.3.1}System Component Analysis for Wireless Communication}{34}{}% |