mirror of
https://github.com/smyalygames/checklist-tester.git
synced 2025-05-18 14:34:12 +02:00
118 lines
4.9 KiB
TeX
118 lines
4.9 KiB
TeX
\documentclass[../dissertation.tex]{subfiles}
|
|
|
|
\begin{document}
|
|
% What changes were made?
|
|
\section{Changes}
|
|
\begin{itemize}
|
|
\item Added the checklist manager which was not a part of the original
|
|
objectives
|
|
\begin{itemize}
|
|
\item Helped more to visualize the project
|
|
\item Aided in gathering statistics for how well the checklist performed
|
|
\item Using Kotlin helped speed up development, it simplifies parts
|
|
of Java and omitted a lot of boilerplate code that is required in Java,
|
|
such as setters and getters
|
|
\end{itemize}
|
|
\item How the Formal Model would interact was modified
|
|
\begin{itemize}
|
|
\item Initially was designed so that the formal model would complete
|
|
the entirety of the checklist, however, it was not useful for interacting
|
|
with the flight simulator
|
|
\item Modified the model to provide it would be similar to actions pilots can
|
|
do in the cockpit
|
|
\item Therefore acts like Read Checklist → Pilot Logic (VDM) → Do Action (XPC)
|
|
\end{itemize}
|
|
\item Originally was supposed to write an original plugin to connect to the flight simulator
|
|
\begin{itemize}
|
|
\item Whilst creating the plugin, sockets were confusing and accidentally stumbled
|
|
on the X-Plane Connect GitHub repository
|
|
\item This could have been prevented if a design document was created and
|
|
time was spent researching for tools in obscure places
|
|
\end{itemize}
|
|
\end{itemize}
|
|
|
|
% What objectives were met?
|
|
\section{Objectives}
|
|
\begin{itemize}
|
|
\item Most of the objectives were met
|
|
\item One of the original objectives was to research pilot
|
|
reaction times and how long it takes pilots to complete an action
|
|
\begin{itemize}
|
|
\item However, not able to do that as there are too many factors
|
|
that can affect a pilot's reaction time, such as age,
|
|
experience on an aircraft, total experience, how far a button is
|
|
from the pilot, etc.
|
|
\end{itemize}
|
|
\item Objective 2.a. was met to an extent
|
|
\begin{itemize}
|
|
\item Currently, the states of the aircraft monitored are only
|
|
the actions specified in the test, in the checklist tester
|
|
\item There could be more variables that could be monitored. Such
|
|
as engine fire, could monitor the engine temperature or thrust
|
|
produced by engine
|
|
\item This would have required a substantial amount of planning
|
|
as checklists do have conditional statements,
|
|
for example \enquote{If APU is available, then do Step 3 else do Step 4}
|
|
\end{itemize}
|
|
\item Objective 2.b. was also met to an extent
|
|
\begin{itemize}
|
|
\item Currently, this can be met by re-running the test multiple
|
|
times manually
|
|
\item However, it is manual at this stage due to limitations of XPC
|
|
and setting up the aircraft
|
|
\item The test data is stored on the database, hence test results
|
|
can be analysed to see the consistency between each test
|
|
\end{itemize}
|
|
\item The Checklist Tester does not currently run actions from the
|
|
Formal Model due to implementing the functions from VDMJ being
|
|
laborious
|
|
\item Hence focus was put on XPC first, as it would produce direct results
|
|
\end{itemize}
|
|
|
|
|
|
\section{What Next}
|
|
The most important next steps to implement would be
|
|
linking the formal mode, adding options of what parts of the aircraft
|
|
to monitor
|
|
|
|
\begin{itemize}
|
|
\item Formal Model
|
|
\begin{itemize}
|
|
\item Implemented either by creating an automatic wrapper.
|
|
Done by either potentially linking the VDMJ LSP, or creating a
|
|
plugin for VDMJ
|
|
\item Or doing string manipulation on the VDM results for each of the
|
|
functions as a lot of it is copy and paste - can be bad practice as
|
|
it requires a lot of hard-coded code
|
|
\end{itemize}
|
|
\item Monitoring more of the aircraft
|
|
\begin{itemize}
|
|
\item Done by adding options in the Checklist Tester for extra
|
|
Datarefs to monitor
|
|
\item Modifying the \lstinline|Aircraft| record type to include a
|
|
states type that checks multiple times throughout the procedure
|
|
if this state has violated a constraint or if the goal of the
|
|
state has been achieved (e.g. Engine is no longer on fire)
|
|
\end{itemize}
|
|
\item Expanding out of the scope of the objectives,
|
|
conditional logic, such as if statements, to the checklist
|
|
would be the next logical step
|
|
\begin{itemize}
|
|
\item VDM-SL would be really helpful for this, as can be used to
|
|
design logic to be used outside of Kotlin
|
|
\item This would allow for further automation of checklists,
|
|
rather than only testing linearly, which at this current state
|
|
would require writing the test multiple times
|
|
\end{itemize}
|
|
\item Adding more detailed test results
|
|
\begin{itemize}
|
|
\item Use analysis of previous test results to gain an understanding
|
|
of the reproducibility of the procedure
|
|
\item Keep track of aircraft state, such as speed or altitude
|
|
aiding in understanding if the procedure may impose a safety risk
|
|
\end{itemize}
|
|
\end{itemize}
|
|
|
|
|
|
\end{document}
|