You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
187 lines
11 KiB
187 lines
11 KiB
|
|
\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}
|