From dde454e892e6728d25d9d41a2798f6265227015f Mon Sep 17 00:00:00 2001 From: Markus Klinik Date: Tue, 21 May 2019 14:45:57 +0200 Subject: [PATCH] definition of c2 scheduling problem wip --- c2-scheduling-problem.tex | 47 +++++++++++++++++++++++++++++++++++++-- discussion.tex | 1 + 2 files changed, 46 insertions(+), 2 deletions(-) diff --git a/c2-scheduling-problem.tex b/c2-scheduling-problem.tex index b63f733..7742b6e 100644 --- a/c2-scheduling-problem.tex +++ b/c2-scheduling-problem.tex @@ -1,5 +1,48 @@ -\section{The C2 Scheduling Problem} +\section{Definition of the C2 Scheduling Problem} \label{sec:c2-scheduling-problem} With all the previous considerations in mind, we now define the C2 scheduling problem. -\todo{Look in Myszkowski for how to phrase it.} +In addition to what was said before, we make the following assumptions. +No preemption: +Tasks can not be interrupted once they are started. +Task durations are integer: +Durations are unitless numbers which can stand for days, hours, or minutes. +Fractions are not necessary. +Capability requirements are known in advance and do not change while tasks are being executed. + +Let $C$ be a set of capabilities. +Let $T$ and $R$ be sets of task and resource identifiers, a unique one for every task and every resource. + +\paragraph{Tasks} +A task is a tuple $\tuple{t, d, \vec{c}, \vec{p}}$ where $t$ is a unique task identifier, $d \in \N$ is the task duration, $\vec{c}$ is a list of capability requirements, and $\vec{p}$ is a list of predecessor task identifiers. + +\paragraph{Resources} +A resource is a tuple $\tuple{r, \vec{c}}$, where $r$ is a unique resource identifier, and $\vec{c}$ is the list of capabilities of the resource. + +\paragraph{Resource affinity constraints} +A resource affinity constraint is an equality of the following form. +\begin{IEEEeqnarray*}{c} +\tuple{t,i} = \tuple{u,j} = \ldots +\end{IEEEeqnarray*} +The meaning of such an equality is that the resource assigned to capability requirement $c_i$ of task $t$ must be the same as the one assigned to capability requirement $c_j$ of task $u$, and so on. +We require that all entries in a resource affinity constraint refer to the same capability. + +\paragraph{Assignments} +An assignment is a set of tuples $\tuple{t, i, r}$ that assigns a resource $r$ to every capability requirement $c_i$ of every task $t$. + +\paragraph{Schedules} +A schedule is an assignment together with a set of tuples $\tuple{t, s}$ that assigns a start time $s \in \N$ to every task $t$. +The end time of a task is its start time plus its duration. + +\paragraph{Validity} +We say that an assignment is \emph{valid} iff +\begin{itemize}[noitemsep] +\item all resources assigned to the same task are different +\item the assignment respects the resource affinity constraints. +\end{itemize} +We say that a schedule is \emph{valid} iff +\begin{itemize}[noitemsep] +\item its assignment is valid +\item it respects the task ordering, which means every task's start time $s_t$ is after the end time of all of its predecessors $\vec{p}_t$ +\item no resource is assigned to two tasks that are overlapping in time. +\end{itemize} diff --git a/discussion.tex b/discussion.tex index a93a169..789614c 100644 --- a/discussion.tex +++ b/discussion.tex @@ -9,4 +9,5 @@ \item The decision whether a boat or a helicopter should be used can be seen as a planning problem, not a scheduling problem. \item Planning and scheduling overlap when a resource is a case. \item Stop criterion: keep calculating until convergence instead of fixed number of rounds +\item Feasibility checking. We don't do it. See \citet{CorreiaLS2012} for a method. \end{itemize} -- GitLab