feat: added a project name

1 files changed, 16 insertions, 5 deletions

diff --git a/content/intro.tex b/content/intro.tex
index f221e01..4a5ed81 100644
--- a/content/intro.tex
+++ b/content/intro.tex
@@ -86,7 +86,7 @@ We propose that digital twinning can be enhanced by integrating predictive analy
 \emph{Main Research Question:} How to define, design and evaluate a predictive \gls{dcdt}?\\
 
 \noindent We divide the problem of designing a predictive \gls{dcdt} into three research questions:
-\begin{enumerate}[label=\emph{RQ\textsubscript{\arabic*}}, align=left]
+\begin{enumerate}[label=\emph{RQ\textsubscript{\arabic*}}, align=left, itemsep=0pt]
 	\item \emph{How to define a \gls{dcdt}?}\\
 	      There is currently a lack of a unified definition of what constitutes a \gls{dcdt}, and the differences between a \gls{dcdt} and a generic \gls{dt}.
 	      It is necessary that we establish a common definition of a \gls{dcdt} in the research community.
@@ -105,10 +105,21 @@ We propose that digital twinning can be enhanced by integrating predictive analy
 \end{enumerate}
 
 \section{Research Methodology}\label{s:research-methodology}
-
-To answer the first research question we will conduct a standard literature review proposed by \textit{Kitchenham et al.} \cite{DBLP:journals/infsof/KitchenhamPBBTNL10} along with the guidance of the supervisor. Firstly, we will need to plan the review. This includes specifying the review research questions and determining the right review method. Secondly, we will need to conduct the review and find the 5 potential digital twin use-cases. This includes selecting the articles, reading and reporting the findings. Lastly, we will format the final report and based on the found use-cases, we will formulate the functional and non-functional requirements for the system model.
-
-To answer the second research question we will follow the \textit{AtLarge Design Process} \cite{DBLP:conf/icdcs/IosupVTETBFMT19}. This means, that under the guidance of the supervisor we will adopt the steps from the design process itself. First, after finishing the literature review, we will brainstorm the functional and non-functional requirements. Later, we will specify the pragmatic and innovative design possibilities. A possible outcome might be a digital twin reference architecture. Lastly, we will need to ensure that the design is scientific and testable and can be evaluated with comprehensive experiments.
+% Alternative formulation in case there is no time to format the results as the literature survey, taken from Mastenbroek et al.
+% Toward addressing RQ1 and RQ2 we survey in Chapter 2 the existing state of the art in risk analysis.
+%We conduct a review of literature of closely-related fields as well as separate engineering science such as aerospace engineering.
+% This will aid in identifying the most important use-cases for digital twins and in return, the crucial functional and non-functional requirements.
+% We analyze the found use-cases in the context of datacenters or brainstorm how we can adapt them to datacenters.
+To answer \emph{RQ\textsubscript{1}} we conduct a standard literature review as proposed by \textit{Kitchenham et al.} \cite{DBLP:journals/infsof/KitchenhamPBBTNL10} along with the guidance of the supervisor.
+Firstly, we specify the review research questions and determine the right review method.
+Secondly, we conduct the review and find the potential datacenter digital twin use-cases.
+This includes a selection of relevant articles, the results of reading and reporting the findings.
+Lastly, based on the found use-cases, we formulate the functional and non-functional requirements for the predictive \gls{dcdt} reference architecture.
+
+To answer \emph{RQ\textsubscript{2}} we closely follow the \textit{AtLarge Design Process} \cite{DBLP:conf/icdcs/IosupVTETBFMT19} under the guidance of the supervisor.
+First, after finishing the literature review, we brainstorm the functional and non-functional requirements predictive \gls{dcdt}.
+We specify the pragmatic and innovative design possibilities to include in the reference architecture.
+Lastly, we ensure that the design is scientific and testable and can be evaluated with comprehensive experiments.
 
 \par Afterwards, we will need to implement a prototype of the designed system model. An example approach would start with exporting the collected monitoring data from the ODA time-series database. The ODAbler \cite{DBLP:conf/wosp/SumanCNTMI24} framework enables the interaction between a python client, that acts as a user interface, with a server, that acts as a data centre. Upon creating the request, monitoring data is forwarded through Telegraf and Kafka to InfluxDB.