spec.tex: Added Use Case Desc

Author: nakoeppen

documentation/spec.tex

@@ -9,7 +9,8 @@
 \tableofcontents
 
 \section{Acknowledgements}
-Our work for an automated SatNOGS scheduler would not have been possible without the vast guidance and assitance from Professor Nicholas S. Rosasco, DS.c., of the Valparaiso University Computer Science Department, and Professor Dan White Ph.D., of the Valparaiso University Electical Engineering Department. We would like to acknoweledge and thank them for their time and contribution of knowledge.
+
+Our work for an automated SatNOGS scheduler would not have been possible without the vast guidance and assitance from Professor Nicholas S. Rosasco, D.Sc., of the Valparaiso University Computer Science Department, and Professor Dan White Ph.D., of the Valparaiso University Electical Engineering Department. We would like to acknoweledge and thank them for their time and contribution of knowledge.
 
 
 \section{General Information}
@@ -33,28 +34,23 @@ \section{Quality Objectives}
 
 To evaluate quality, the documentation should provide any future implementers
 and SatNOGS community members enough information, as well as coherent enough
-information to pick up where we left off. Particularly with regards to the
+information, to pick up where we left off. Particularly with regards to the
 implementation of this software system.
 
 
 \section{Future Plans}
 
 \subsection{Job Distributor as Abstract Entity}
+
 Our current implementation entails a proof-of-concept, exemplifying an automated platform for ground stations to schedule satellites via sigmoid-compiled preferences. However, when implemented, we would recommend to seperate the job scheduler role from the ground station. By having the job distributor as a more abstract entity, a bigger picture of ground station accessibility can be seen and scheduled for. For example, if a satellite cluster is hovering over Europe, which has numerous groundstations, it can be more efficiently scheduled for one-on-one communication by an abstract entity as opposed to a scheduler led by a ground station, because the seperate entity can better account for the mass of satellites and ground stations and can schedule for what relationships work best, instead of what works best for a certain ground station. Subsequently, when explaining the roles working within our scheduler in this document, we will define the system in-terms of this abstract entity.
 
 \subsection{Currency to Allow for Decision Override}
+
 With the current implementation that SatNOGS provides, satellites have absolutely no say in how or when they are scheduled. It is entirely up to the ground station in how the satellite is manually scheduled. In our current concept, the satellite could sacrifice the quantity of communication it gets for the quality, perhaps by being not scheduled once hourly with Software-Defined-Radio equipped Raspberry Pi's and instead being scheduled once daily with high-power antenna setups. This enables the satellite to have its own say in how and when it is scheduled, even though it is not the final voice in the matter. We would recommend retaining this model, but would encourage the implementation of a 'currency' which would enable the satellite to further influence a scheduling decision, perhaps because the satellite owner requires data from the satellite in a timely fashion.
 
 \section{Use Case Description}
 
-\section{Definitions}
-
-\begin{itemize}
-  \item \textbf{Job} - A satellite pass over a particular groundstation
-\end{itemize}
-
-\subsection{Data Layout}
-
+Through this scheduling program, users of the SatNOGS database could eventually (if implemented into the SatNOGS website) be able to automate the processes in which their communications are scheduled. Furthermore, both ground stations and satellites would be enabled to declare preferences, which can influence the outcome of how they are scheduled as well. This, in our rendition of the scheduler, would occur via weights towards certain biases. For example, if a satellite sees that a ground station has undesirable reliability ratings in its communications, it could sacrifice less communication on the network for higher reliability. The same could also work on behalf of ground stations judging satellites. Another potential way in which preferences could affect scheduling would be if there is a congruence between the interests of the satellite and the interests of the ground station. For example, potentially higher academia, such as Valparaiso University's own SatNOGS ground stations, wish to primarily use their communication time for satellites who are interested in research. Subsequently, satellites with more research-centric goals would be far more likely (not to be confused with 'guaranteed', however) to be scheduled than those with other intents.  
 
 \section{Scheduler Description}
 
@@ -93,7 +89,9 @@ \subsection{Ground Station Job Evaluator}
 deny. It is simply a peice of software that reads in potential jobs, and
 decides what jobs to take based off of the groundstation owners preferences.
 
-\section{Test Plan}
+\subsection{Data Layout}
+
+Data is input through the program via an SQL database file, and the provided 2018 example database from SatNOGS was used for testing. As it stands, output is created and organized through a CSV, which makes it very accessible and easy to parse through if needed.