From aa32b75bd7a6248fad478bc634e8126ee9981db7 Mon Sep 17 00:00:00 2001
From: mjkwiatkowski <mati.rewa@gmail.com>
Date: Thu, 16 Jul 2026 01:27:14 +0200
Subject: feat: completed all feedback from Dante as to Chapter 3

---
 content/design.tex | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 55 insertions(+), 2 deletions(-)

(limited to 'content/design.tex')

diff --git a/content/design.tex b/content/design.tex
index 8ae83e6..7d4a73a 100644
--- a/content/design.tex
+++ b/content/design.tex
@@ -131,7 +131,7 @@ As a result of the \emph{AtLarge Design Process}~\cite{DBLP:conf/icdcs/IosupVTET
 \end{enumerate*}
 
 \subsection{The Physical Datacenter}\label{sss:physical_datacenter}
-The physical datacenter (I) encompasses 3 core elements important to digital twinning.
+The Physical Datacenter (I) encompasses 3 core elements important to digital twinning.
 Workloads (\myCircled{1a}) include the hardware requirements of each datacenter job and the submission time.
 They are executed on the datacenter compute (\myCircled{1b}), which is controlled partly by the Datacenter Operators (\myCircled{1c}).
 Component (\myCircled{1c}), while seemingly unimportant, is crucial to the digital twin design.
@@ -219,9 +219,62 @@ Any discrepancies are communicated to the Analytics Engine (\myCircled{4b}) for
 \section{Requirement Validation}\label{ss:requirement_validation}
 %How does this model satisfy the requirements? 
 %How did you arrive at this specific model?
+In this section we describe the rationale behind the different design decisions of \mysystem.
+To show that our model satisfies the functional and non-functional requirements, we map each component of \mysystem onto the requirements it fulfills.
+\input{sources/requirements_validation.tex}
 
+The Interactive Dashboard (\myCircled{2a}) supports (\textbf{FR2}), as it allows to display the failures detected to datacenter operators; it is the core of (\textbf{FR4}) because descriptive analytics are synonymous to visualizations.
+It enables (\textbf{FR5}) because the predictive insights can be displayed directly through the dashboard to the datacenter operators.
+Operators can then overwrite the autonomous decisions performed by the \gls{dt}.
+Dashboards are the current industry practice for clear data visualization (\textbf{FR7}).
+For our implementation, we ensure (\textbf{NFR1}) is met by including a state-of-the-art dashboard.
+(\textbf{NFR2}) and (\textbf{NFR3}) are met by including in the system implementation a dashboard that enables logging of metrics.
 
+The Message Broker (\myCircled{2b}) indirectly fulfills (\textbf{FR1}).
+A good and robust message broker alleviates potential bottlenecks that might stem from large data transfer.
+My including a dedicated message broker, we ensure the bottle neck when twinning is not \mysystem.
+As the Message Broker (\myCircled{2b}) is a vital component in the communication between the datacenter operators and the physical twin, it indirectly enables (\textbf{FR2}), (\textbf{FR3}), (\textbf{FR4}), (\textbf{FR5}).
+In the other direction, to ensure that the \gls{dcdt} can ingest any amount of data, the Message Broker (\myCircled{2b}) is needed for (\textbf{FR6}).
+The non-functional requirements are met by including a state-of-the-art message broker from either academia or the industry in the implementation.
 
+The inclusion of System Knobs (\myCircled{2c}) in the reference architecture fulfills (\textbf{FR2}).
+With autonomous actions, the \gls{dt} can alter the operation of the datacenter based on the detected failures.
+Failure detection must support datacenter operators in meeting \gls{sla}s.
+Autonomous actions, enabled by System Knobs (\myCircled{2c}) help achieve that.
+(\textbf{FR4}) and (\textbf{FR5}) are met by ensuring the insights that come from the \gls{dt} can be automated with the system knobs.
+Supporting both predictive and descriptive analytics is core to the system knobs.
+(\textbf{NFR4}) is met as the existing digital twin deployments often contain (indirectly) the System Knobs (\myCircled{2c}) element.
+Including it in our design adheres to best design practice.
+Importantly, (\textbf{NFR5}) is fulfilled together by creating a predictive analytics engine that is capable of intelligent insights and system knobs.
+In order for the predictive insights to be realized, systems knobs are needed.
 
+The Database (\myCircled{2c}) meets (\textbf{FR3}), (\textbf{FR4}), (\textbf{FR5}), (\textbf{FR6}) and (\textbf{NFR2}).
+Trivially, including a simple \gls{dbms} in the architecture fulfills (\textbf{FR3}).
+For the different types of analytics (\textbf{FR4}), (\textbf{FR5}), the Database (\myCircled{2c}) enables insights from historical patterns.
+Database are the current state-of-the-art in storing telemetry (\textbf{FR6}).
+They are designed to hold arbitrary volume of data.
+Lastly, (\textbf{NFR2}) is met by storing in the database the logs from both the \gls{dcdt} and the physical datacenter.
 
-\section{Discussion}\label{ss:discussion_archi}
+The API Server (\myCircled{3c}) ensures (\textbf{FR4}), (\textbf{FR5}), (\textbf{FR2}) and (\textbf{NFR3}).
+The server, which facilitates the insights that come into the System Knobs (\myCircled{2c}), by proxy enables (\textbf{FR4}) and (\textbf{FR5}).
+To detect failures, some sort of notification daemon is needed for the datacenter operators, not just the dashboard.
+The API Server (\myCircled{3c}) fulfills that role, ensuring (\textbf{FR2}).
+The API server (\myCircled{3c}), specifically a server using the \gls{http} protocol is a state-of-the-art approach to existing digital twin communication (\textbf{NFR3}).
+
+The Cache (\myCircled{3b}) ensures the same requirements as the Database (\myCircled{3a}), with a couple of exceptions.
+Namely, it also ensures (\textbf{NFR1}) and (\textbf{NFR3}).
+Caching is needed for sub 1-second visualizations, and the inclusion of a cache for in-band data analytics is the current community practice.
+
+In our design, we include an Event-driven Simulator (\myCircled{4a}).
+This ensures (\textbf{FR1}), (\textbf{FR2}), (\textbf{FR4}), (\textbf{FR5}) and all non-functional requirements except (\textbf{NFR2}).
+Using a discrete-event simulator ensures that our system can handle workloads that are representative of the simulator at use.
+Simulation, a method that is widely accepted by the scientific community, is one way \mysystem can ensure (\textbf{FR1}).
+Detecting failures, enabling both descriptive and predictive analytics depends on how good of a simulator (\myCircled{4a}) is.
+In principle, a robust, holistic simulator incorporated into the predictive engine is capable of meeting (\textbf{FR4}), (\textbf{FR2}) and (\textbf{FR5}).
+Simulation also allows to model large workloads and to interact with the simulation in real-time (\textbf{NFR1}), it is considered a state-of-the-art approach to datacenter modelling (\textbf{NFR3}) and, with good data analytics provides enough data for insights at varying levels of confidence (\textbf{NFR4}).
+
+The Analytics Engine component (\myCircled{4b}) and the Monitoring Service (\myCircled{4c}) fulfill the same set of requirements, namely (\textbf{FR1}), (\textbf{FR2}), (\textbf{FR4}) and (\textbf{FR5}).
+Additionally the Analytics Engine (\myCircled{4b}) also fulfills (\textbf{NFR4}), as it provides the capability to differentiate between different levels of confidence.
+Both components are working together in unison, closely watching and reacting to the metrics from the real datacenter.
+Hence, they fulfill (\textbf{FR2}), (\textbf{FR4}) and (\textbf{FR5}) and are crucial to the \gls{dcdt} operation.
+(\textbf{FR1}) is fulfilled by ensuring both the Analytics Engine and the Monitoring Service are not the source of any bottlenecks during the system implementation.
-- 
cgit v1.2.3

