281 lines
12 KiB
Plaintext
281 lines
12 KiB
Plaintext
\documentclass[10pt, draftclsnofoot,onecolumn]{IEEEtran}
|
|
\usepackage{todonotes}
|
|
\usepackage{caption}
|
|
\usepackage{pgfgantt}
|
|
\linespread{1}
|
|
\begin{document}
|
|
|
|
\title{Fenceless Grazing Requirements}
|
|
\author{Danila Fedorin \and Matthew Sessions \and Ryan Alder}
|
|
|
|
\maketitle
|
|
\tableofcontents
|
|
\pagebreak
|
|
|
|
% From: ISO/IEC/IEEE 29148:2011, page 44
|
|
% 1. Introduction
|
|
% 1.1 System purpose
|
|
% 1.2 System scope
|
|
% 1.3 System overview
|
|
% 1.3.1 System context
|
|
% 1.3.2 System functions
|
|
% 1.3.3 User characteristics
|
|
% 1.4 Definitions
|
|
% 2. References
|
|
% 3. System requirements
|
|
% 3.1 Functional requirements
|
|
% 3.2 Usability requirements
|
|
% 3.3 Performance requirements
|
|
% 3.4 System interface
|
|
% 3.5 System operations
|
|
% 3.6 System modes and states
|
|
% 3.7 Physical characteristics
|
|
% 3.8 Environmental conditions
|
|
% 3.9 System security
|
|
% 3.10 Information management
|
|
% 3.11 Policies and regulations
|
|
% 3.12 System life cycle sustainment
|
|
% 3.13 Packaging, handling, shipping and transportation
|
|
% 4. Verification (parallel to subsections in Section 3)
|
|
|
|
\section{Introduction}
|
|
\subsection{System purpose}
|
|
The purpose of the Fenceless Grazing Collar (FGC) system is to reduce the
|
|
need for human supervision in farming through the tracking and automated
|
|
management of individual farm animals, controlled by humans through
|
|
a remote digital system.
|
|
\todo{This probably needs to be expanded on}
|
|
|
|
\subsection{System scope}
|
|
A table containing systems which the FGC project is seeking to replace
|
|
or influence, as well as a description of the intended interaction
|
|
between the FGC project and the system, are shown in Figure \ref{fig:system_scope}.
|
|
\todo{More rows + header}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\captionsetup{justification=centering}
|
|
|
|
\begin{tabular}{c p{12cm}}
|
|
Animal herding & The FGC system will be used replace humans and trained animals that currently
|
|
manage and control farm animals. \\
|
|
Data collection & Among the goals for the FGC sytem is to collect data from the animals being herded,
|
|
in order to help farmers make informed decisions. The FGC system can either serve as the first
|
|
means of data collection, a replacement for an existing data collection mechanism, or as a
|
|
complement to such a mechanism. \\
|
|
\end{tabular}
|
|
|
|
\caption{Fenceless Grazing System Scope}
|
|
\label{fig:system_scope}
|
|
\end{figure}
|
|
|
|
\subsection{System overview}
|
|
\subsubsection{System context}
|
|
At present, despite the continued industrialization in numerious other indestries, animal
|
|
farming replies on human labor to manage and herd farm animals. This requires significant
|
|
time and effort, which could be more effectively spent elsewhere. The GFC system intends
|
|
to automate the various human involvement in animal farming.
|
|
|
|
\subsubsection{System functions}
|
|
Primarily, the FGC system serves as a tracking and management device. Through
|
|
the use of GPS tracking and LoRa long-range communication tehcnology, a collar
|
|
is to provide information regarding the present location of the farm
|
|
animal equipped with said collar. Furthermore, the collar is to be
|
|
able to discourage undesired behavior such as leaving a designated area
|
|
from the animal through the use of loud and unpleasant sounds and electrical chock.
|
|
|
|
The collar is also to collect data regarding the behavior of various animals,
|
|
for use in making decision regarding the livestock or otherwise.
|
|
|
|
Additionally, a component of the system is a piece of software that allows
|
|
for the remote management of collars. Users should be able to adjust "allowed"
|
|
locations for the animals through this software, observe the current locations
|
|
of the animals, and read the data collected by the collars.
|
|
|
|
\subsubsection{User characteristics}
|
|
?? \todo{Finish this}
|
|
\subsection{Definitions}
|
|
?? \todo{Finish this}
|
|
\section{References}
|
|
\section{System requirements}
|
|
\subsection{Functional requirements}
|
|
\subsubsection{GPS}
|
|
It is imperative that the FGC system precisely tracks the locations of
|
|
animals that are equipped with a collar. As the name of the system
|
|
suggests, the system may be deployed in replacement of fenced-off
|
|
areas. As such, failure to correctly identify the location
|
|
of an animal may lead to the animal moving outside the desired area.
|
|
Since many farms border wooded areas, highways or roads, it is then possible
|
|
that an animal whose location was not properly reported will wonder
|
|
into traffic or another dangerous location. We specify
|
|
the maximum uncertainty in the location of an animal to be
|
|
3 feet.
|
|
|
|
In addition to being precise with the GPS coordinates, the system
|
|
must be tolerant of the aforementioned uncertainty. The analysis
|
|
of the reported location should prevent the possibility of a collar
|
|
not producing a negative stimulus due to a fluctuation of measurement.
|
|
|
|
\subsubsection{Sound and Electrical Shock}
|
|
Simply being aware of the animal's location is insufficient
|
|
to properly control its behavior without human intervention.
|
|
As such, the collars must be able to create stimuli
|
|
that farm animals find unpleasant, effectively training
|
|
them to avoid performing actions that are undesirable. The sound
|
|
and shock must not only be sufficient to infuence the animals,
|
|
but also safe: they should not cause harm or excessive discomfort
|
|
to the animal.
|
|
|
|
\todo{investigate legal guidelines?}
|
|
|
|
\subsubsection{Control Application}
|
|
The project must contain a functional mobile application for
|
|
the Android platform, capable of interfacing with the collars
|
|
in the field. This application should, at minimum, be usable
|
|
to adjust the boundaries of the prescribed region and visualize
|
|
the locations of individual animals on a map.
|
|
|
|
\subsubsection{Data Collection}
|
|
@ryan you know more about this than I care to research. \todo{finish this}
|
|
|
|
\subsubsection{Effective Area}
|
|
Because many farms have significant numbers of livestock, and consequently
|
|
a large grazing area, it's necessary that the FGC system is functional
|
|
at large distances. We require that the sysem is functional at distances
|
|
as large as 5 kilometers, which is half of the maximum range of the
|
|
LoRa technology. A consequence of this requirement is also that the system
|
|
is entirely wireless, since it is not feasible to provide cables or wires
|
|
that span the maximum area of 5 kilometers.
|
|
|
|
\subsection{Usability requirements}
|
|
\subsubsection{Accessibility of Application}
|
|
Because the FGC system is intended to be used by farmers as a replacement
|
|
for manual labor, it must be accessible to farmers with knowledge
|
|
of the domain, but not necessarily of the inner workings of the FGC implementation.
|
|
Thus, the final Android application must be usable, without significant prior training,
|
|
by non-technical people from the agricultural industry. On the other hand,
|
|
if necessary, the Android application \emph{should} assume domain specific knowledge
|
|
in the area of agriculture, since its intended audience is from this field.
|
|
|
|
\subsubsection{Servicability of Collars}
|
|
Because the collars are intended to be battery-based, they will need to be serviced,
|
|
with the minimum goal of replacing or recharging the on-board batteries. This
|
|
must be possible to people with no prior technical experience, as the presence
|
|
of such experience is not guaranteed the expected client base. Other common
|
|
servicing goals, such as cleaning the device, should also be easy to accomplish
|
|
without an understanding of the architecture or implementation of the FGC system.
|
|
|
|
\subsection{Performance requirements}
|
|
\subsubsection{Battery Efficiency}
|
|
Since the FGC device is battery powered and will require maintenance upon
|
|
reaching low battery levels, it's important that the device is able to
|
|
maintain an operational level of charge for long periods of time. That
|
|
is, the number and duration of servicing actions should be low, in alignment
|
|
with the original goal of reducing human labor. At minimum, the device
|
|
should remain operational for 7 days (1 week).
|
|
|
|
\subsubsection{Support for Multiple Collars}
|
|
As mentioned above, the goal for hte FGC system is to support large herds of animals,
|
|
which normally require significant portions of time to be dedicated by humans.
|
|
In order to properly support large herds, it must be possible for the system
|
|
to support as many as 100 concurrently active collars without issue. This
|
|
requirement applies to the collars themselves and the Android application:
|
|
\begin{itemize}
|
|
\item The collars themselves should not experience difficulties when concentrated
|
|
in large groups (farm animals instinctively tend towards proximity).
|
|
\item The Android application, given hardware that is not greatly outdated,
|
|
should be able to display and manage this number of collars without
|
|
additional delays.
|
|
\end{itemize}
|
|
|
|
\subsection{System interface}
|
|
\subsubsection{LoRa}
|
|
@ryan \todo{write this}
|
|
|
|
\subsection{System operations}
|
|
\subsection{System modes and states}
|
|
Besides the "standard" operational mode for the collar, it
|
|
is useful to envision other modes that help in troubleshooting
|
|
and setting up the FGC system. We define the following modes:
|
|
|
|
\subsubsection{Standard}
|
|
In this mode, the device uses the defined
|
|
"out of bounds" area to determine whether or not to emit a negative
|
|
stimulus. The produced negative stimuli are as defined in the
|
|
sounds and electrical shock section of the functional requirements.
|
|
|
|
\subsubsection{Electric Shock Test}
|
|
In this mode, the device operates identically to the standard mode
|
|
described above, with the exception of not generating electrical
|
|
shocks. Instead, the device should emit a different sound (or
|
|
a visual signal) to indicate when the shock would have been delivered.
|
|
This allows for safe testing of the device's behavior around area boundaries.
|
|
|
|
\subsection{Physical characteristics}
|
|
\subsubsection{Weight}
|
|
It's necessary for the device to be physically bearable by livestock for indefinite
|
|
periods of time. If the resulting collar is a constant and noticable weight on the
|
|
farm animal, it would serve as an unnecessary and permanent source of stress. Besides
|
|
the ethical considerations of subjecting an animal to a constant level of stress through
|
|
unnecessary physical labor (i.e. carrying a collar that is too heavy), this goes against
|
|
the purpose of the project, since it will likely reduce the quality of the resulting animal
|
|
management below the level that can be provided by humans.
|
|
|
|
\subsubsection{Form Factor}
|
|
In order to be able to effectively use the collar, it must fit comfortably on target farm
|
|
animals. In our initial prototype, these animals will be cows, and thus, a requirement
|
|
for the project is that the collar can be put onto, and stay on a farm cow.
|
|
|
|
\subsection{Environmental conditions}
|
|
\subsubsection{Water Resistance}
|
|
The product will be tested in collaboration with Oregon State University's College of Animal
|
|
Science, and therefore, will be tested in Oregon's climate. Since rain is very common
|
|
during the winter months in Western Oregon, the device must be readily able to withstand
|
|
such conditions, without sustaining any damage.
|
|
|
|
\todo{Anything else?}
|
|
|
|
\subsection{System security}
|
|
\todo{Do we need this?}
|
|
\subsection{Information management}
|
|
\todo{Do we need this?}
|
|
\subsection{Policies and regulations}
|
|
\todo{Do we need this?}
|
|
\subsection{System life cycle sustainment}
|
|
\todo{Do we need this?}
|
|
\subsection{Packaging, handling, shipping and transportation}
|
|
\todo{Do we need this?}
|
|
\section{Verification}
|
|
\todo{Someone else please}
|
|
|
|
\section{Gantt Chart}
|
|
\begin{ganttchart}[
|
|
x unit=.55mm,
|
|
time slot format=isodate
|
|
]{2019-10-01}{2020-06-30}
|
|
\gantttitlecalendar{year, month=name} \\
|
|
|
|
\ganttgroup{Collar}{2019-10-01}{2020-03-01} \\
|
|
\ganttbar{Design}{2019-10-20}{2020-01-01} \\
|
|
\ganttmilestone{Purchase Parts}{2020-01-03} \\
|
|
\ganttbar{Assemble}{2020-01-05}{2020-02-01} \\
|
|
\ganttbar{Test}{2020-02-01}{2020-03-01} \\
|
|
\ganttgroup{Server}{2019-10-01}{2020-05-01} \\
|
|
\ganttbar{Design}{2019-10-20}{2020-01-01} \\
|
|
\ganttbar{Implement}{2020-01-01}{2020-04-01} \\
|
|
\ganttbar{Test}{2020-04-01}{2020-05-01} \\
|
|
\ganttgroup{Application}{2019-10-01}{2020-05-01} \\
|
|
\ganttbar{Design}{2019-10-20}{2020-01-01} \\
|
|
\ganttbar{Implement}{2020-01-01}{2020-04-01} \\
|
|
\ganttbar{Test}{2020-04-01}{2020-05-01} \\
|
|
\ganttgroup{Project}{2019-10-01}{2020-06-30} \\
|
|
\ganttbar{Finalize}{2020-05-01}{2020-06-15}
|
|
\ganttlink{elem1}{elem2}
|
|
\ganttlink{elem2}{elem3}
|
|
\ganttlink{elem3}{elem4}
|
|
\ganttlink{elem6}{elem7}
|
|
\ganttlink{elem7}{elem8}
|
|
\ganttlink{elem10}{elem11}
|
|
\ganttlink{elem11}{elem12}
|
|
\end{ganttchart}
|
|
\end{document}
|