future-work.tex 3.92 KB
 Markus Klinik committed Feb 07, 2019 1 2 3 \section{Future Work} \label{sec:future-work}  Markus Klinik committed May 07, 2019 4 5 6 7 8 9 10 11 12 13 14 15 16 As this paper focuses on a small problem in the large area of command and control, there are many ways in which our work can be continued. \paragraph{Re-planning} We envision our algorithm to be used during missions, when some resources are already busy executing tasks. If new tasks must be executed, for example due to an incident that requires damage control, the running tasks should be taken into consideration. Depending on the severity of the incident it might be better to pause some of the running tasks to free their resources, let them work on the incident, and then resume their previous tasks. These task switches could have their own associated costs that the algorithm should try to minimize. One way to implement this could be a measure for the distance between two schedules. If we could calculate some sort of \emph{degree of similarity} between two schedules, it would be possible to let the algorithm compare each candidate with the currently running schedule. Candidates that are more similar to the running schedule should be preferred. As with all other objectives, this similarity measure should be weighted so that users can influence the algorithm to either calculate a faster but disruptive new schedule, or one that does not disrupt the current activities but takes longer, or has lower quality.  Markus Klinik committed May 08, 2019 17 18 19 20 21 22 23 \paragraph{Human in the loop} The long-term goal for this work is the development of interactive decision support, which is integrated into a mission management tool. The decision maker should always have the last word, and the tool should allow all decisions to be manually overridden, even if that violates constraints. It is always possible that the constraints are erroneous, for example that a resource can actually be assigned to a task, even if that is not known to the tool. In such a case, humans should not be restricted by the design of the software. This is called \emph{human in the loop}. Future work in this direction should first identify requirements in which ways humans should be able to change the outcome of the scheduler, and then implement it in a user-friendly and intuitive manner.  Markus Klinik committed May 24, 2019 24 This could include visualization of the consequences of manual overrides to resources and running tasks.  Markus Klinik committed May 08, 2019 25   Markus Klinik committed May 08, 2019 26 27 28 29 30 31 32 33 \paragraph{Influence schedule task ordering} In the current implementation, the evolutionary algorithm calculates an assignment, from which a schedule is built in a greedy manner, where tasks first in the instance definition get scheduled first. This way, task priorities can be modelled by putting tasks with higher priority earlier in the instance definition. The downside is that the scheduler and the quality functions have no influence on the task ordering. It would be nice to be able to let the quality functions evaluate the task ordering. That would make it possible for example to encode dynamic blanket search routes as a scheduling problem. This is a difficult extension to the algorithm however, as the chromosomes need to encode a task ordering that should be guaranteed to respect the ordering imposed by the ordering constraints of the instance.  Markus Klinik committed May 08, 2019 34 35 36 37 38 39 40 \paragraph{Other population-based methods} We argued in \cref{sec:evolutionary-algorithms} that evolutionary algorithms are a natural fit for our problem, because they are population-based metaheuristics. We chose an evolutionary algorithm for our proof-of-concept implementation because it is easy to implement and extend. There are other population-based metaheuristics in the literature that could be explored as well, like particle swarm optimization or ant colony optimization. This line of work would require developing a set of example instances that covers many of our intended scenarios and takes our implementation to the computational limit. Then, the other methods have to be implemented as solvers to the C2 scheduling problem. In this way, it would be possible to experimentally compare which metaheuristics is faster and delivers better results.