feat: finished section 2.4.3

3 files changed, 56 insertions, 3 deletions

diff --git a/content/background.tex b/content/background.tex
index 17d7d47..6e39e6d 100644
--- a/content/background.tex
+++ b/content/background.tex
@@ -158,7 +158,7 @@ We select only the digital twins that adhere closest to the \gls{nasem} definiti
 The aim of this survey is to search and organize the field of \gls{dcdt}s.
 In this subsection, we describe the methods for collecting relevant scientific articles and present the design of the system model for generic \gls{dcdt}s.
 
-\begin{enumerate}[label=\textbf{\arabic*.}, align=left]
+\begin{enumerate}[label=\textbf{\arabic*.}]
 	\item \textbf{Review Strategy}\\
 	      The most common methods for conducting literature surveys are \begin{enumerate*}[label=(\arabic*)]
 		      \item random traversal of the related literature,
@@ -262,6 +262,59 @@ Kalibre takes the best of both \gls{ml} and \gls{cfd} approaches and achieves su
 
 \subsection{System Model for Datacenter Digital Twinning}
 \label{ss:system_model_for_dcdts}
+In \Cref{fig:system_model} we present a holistic model of \gls{dcdt}s from \Cref{sss:advanced_dts}.
+The figure includes the functionality present in the majority of \gls{dcdt}s, combined together into a unified model.
+We distinguish 3 core elements of every \gls{dcdt}:
+\begin{enumerate*}[label=(\arabic*)]
+	\item the virtual world
+	\item digital thread
+	\item the physical world
+\end{enumerate*}.
+\begin{enumerate}[label=\textbf{\arabic*.}]
+	\item \textbf{Virtual World} contains the \gls{dcdt}.
+	      It represents all the components that exist in software.
+	      Every \gls{dcdt} model can be categorized into two sub-categories:
+	      \begin{enumerate*}[label=(\arabic*)]
+		      \item infrastructure model
+		      \item operations model
+	      \end{enumerate*}.
+	      Each \gls{dcdt} from \Cref{sss:advanced_dts} contains a model of the infrastructure within the datacenter.
+	      This includes virtual replicas of the hardware elements (\eg servers, networking, server racks, rooms).
+	      These elements have varying degrees of fidelity.
+	      For example, NetGraph models the datacenter interconnect using purely configuration files.
+	      On the contrary ExaDigiT models the datacenter hardware fully in 3D.
+	      Both offer virtual infrastructure models as a part of the \gls{dcdt}.
+
+	      The operations model is likewise present in all deployments.
+	      It models the \emph{behaviour} of the datacenter, \ie the data flow, the different workloads running on the compute, the amount of data stored in each hosts \etc.
+	      Both the infrastructure model and the operations model are part of all \gls{dcdt} deployments from \Cref{sss:advanced_dts}.
+	      A digital twin that contains only the infrastructure model, cannot enable insights into the real-time operation of the datacenter.
+	      Likewise, a \gls{dcdt} containing just the operations model does not possess a capability to \eg simulate the datacenter.
+	      Only both, combined together enable the insights envisioned by the \gls{nasem} \gls{dt} definition~\cite{DBLP:usdoe/report/AP26894}.
+	\item \textbf{Digital Thread} connects the virtual world to the physical world.
+	      This is a novel contribution of our thesis.
+	      The digital thread is a \emph{conceptual} element that unites the components which do not belong in either of the worlds.
+	      All \gls{dcdt} programs from \Cref{sss:advanced_dts} contain elements that are ``in-between'' the physical and virtual twin.
+	      After comparing and corroborating these components across deployments, we find 4 that prevail the most:
+	      \begin{enumerate*}[label=(\arabic*)]
+		      \item the visualization interface
+		      \item the message broker
+		      \item the monitoring system
+		      \item the system knobs
+	      \end{enumerate*}.
+	      These elements \emph{connect} facilitate the connection between the physical and the virtual.
+	      For example, the visualization interface provides insights from the metrics collected by the \gls{dcdt} (virtual world) to the datacenter operators (physical world).
+	      The message broker transfers the data from the real datacenter (physical world) to the digital twin (virtual world).
+	\item \textbf{Physical World} models the real datacenter.
+	      All deployments in \Cref{sss:advanced_dts} contain this element.
+	      Moreover, within the datacenter, we distinguish between 3 core elements that are necessary to model the datacenter faithfully\begin{enumerate*}[label=(\arabic*)]
+		      \item the \gls{it} equipment
+		      \item cooling subsystem
+		      \item power supply
+	      \end{enumerate*}.
+	      All of the aforementioned systems from \Cref{sss:advanced_dts} model either of the 3 elements.
+	      In order to adhere to the holistic view of \gls{dcdt}s, and to fulfill the \gls{nasem}'s definition, the system must contain all 3 of these elements.
+\end{enumerate}
 
 \begin{figure}[t]
 	\centering
diff --git a/content/conclusion.tex b/content/conclusion.tex
index 1df3d95..86d9f68 100644
--- a/content/conclusion.tex
+++ b/content/conclusion.tex
@@ -37,7 +37,7 @@ We answer the main research question by addressing each sub-research question.
 
 	\item \emph{How to validate and evaluate a datacenter digital twin architecture in relation to system requirements?}\\
 	      To answer the last research question we crated a prototype.
-	      During the prototype design, we used state-of-the-practice software, such as \code{Confluent Kafka}, \code{Redis} and \code{PostgreSQL} (see \Cref{ss:implementation_overview}).
+	      During the prototype design, we used state-of-the-practice software, such as \code{Confluent Kafka}, \code{Redis} and \code{PostgreSQL} (see \Cref{ss:detailed_implementation_overview}).
 	      However, as it turns out, evaluating \gls{dcdt}s is not a trivial task.
 	      Lacking the physical datacenter to experiment with, we came up with a novel digital twin evaluation method.
 	      Our method, relies solely on discrete-event simulation to model the physical datacenter, overcoming the problems of real-world experimentation (\eg sustainability, costliness, reproducibility).
diff --git a/content/design.tex b/content/design.tex
index 2eb195d..4fbb1b4 100644
--- a/content/design.tex
+++ b/content/design.tex
@@ -12,7 +12,7 @@
 \end{mynote}
 \section{Requirements Analysis}\label{ss:requirements_analysis}
 In this section we determine the requirements that should be fulfilled by \mysystem.
-We present here the stakeholders identified by our literature survey (see \Cref{sss:digital_twins_for_datacenters}) and the relevant use-cases.
+We present here the stakeholders identified by our literature survey (see \Cref{ss:digital_twins_for_datacenters}) and the relevant use-cases.
 Afterwards, we list the functional and non-functional requirements for \mysystem.
 
 \subsection{Stakeholders}\label{sss:stakeholders}