<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">%=====================================================================
\section{The TestFailure Behavior}
%=====================================================================
%\wikisec{grp=bhvsolo, file=BehaviorTestFail,short=TestFailure Behavior}
\label{bhv_testfailure}
%%\index{IvP Behaviors Implemented!\var{BHV\_TestFailure}}
%\index{TestFailure Behavior}

The TestFailure behavior is used to test the helm in two conceivable
behavior failure modes. First, it may be used to simulate a behavior
that crashes and thereby results in the crash of the helm. Second, it
may be used to simulate a behavior that consumes a sufficiently large
enough amount of time so as cause the helm to be considered "hung"
by consumers of the helm output.

\pskip

Recall that the helm is compiled, with behaviors, into a single MOOS
application. Although some behaviors may be compiled into shared
libraries loaded at run time, thereby not requiring a recompile, all
behaviors do run as part of a single helm process. {\em A crashed
  behavior results in a crashed helm.}  Furthermore the helm, on each
iteration, queries each participating behavior for its input. It does
not do this in separate threads, and there is no timeout with a
default reply should a behavior never answer. {\em A hung behavior
  results in a hung helm.} These are architecture decisions that on
one hand allow a substantial amount of simplicity in the helm
implementation and debugging. Furthermore, it's not clear that a
graceful and safe policy exists to safely handle a rogue behavior
other than to either (a) abort the mission or (b) put the vehicle in
the hands of a much more conservatively configured "standby" instance
of the helm, perhaps just to get the vehicle home. This behavior is
used to simulate both kinds of rogue behaviors, a behavior that
crashes and a behavior the hangs. The crash is implemented simply with
an \var{assert(0)} statement, and the hang is implemented with a long
for-loop.

%=======================================================================
\subsection{Configuration Parameters}
\label{sec_bhv_testfail_params}

\input{includes/bhv_all_properties}


\vspace{0.15in}
\begin{listing}{Configuration Parameters for the TestFail Behavior}
\label{lst_bhv_testfail}
\small
\renewcommand{\arraystretch}{1.15}
\begin{longtable}{rp{0.76\textwidth}} 

  {\bf Parameter} &amp; {\bf Description} \\  
  
  \bvar{failure\_type}:  &amp; Fail by \var{crash}, or fail by 
  \var{hang}. 
\end{longtable}
\end{listing}
\normalsize

Choosing to fail with a {\em crash} will result in behavior executing an 
\var{assert(0)} as soon as the behavior enters the running state. 
Configuring for a {\em hang} will likewise result in the execution of a
long for-loop upon entering the running state. The hang time is by 
default three seconds, but may be altered by specifying a time alongside
the hang parameter as in line 9 below.

\pskip

Below are a couple typical usage configurations. In the first case,
the TestFailure behavior is set with a condition as on line 4, to
remain idle until the vehicle is deployed. The duration parameter on
line 6, defined for all helm behaviors, ensures the behavior will not
run until two minutes into the mission. This is done presumably to
have the failure occur while the vehicle is "in the middle of doing
something". Setting the \bvar{duration\_idle\_decay} parameter to false
indicates the duration countdown is not to proceed while the behavior
is still idle. In this case the failure type is set to hang for two
seconds. This behavior configuration is used in the Kilo example
mission, described in Section XYZ, and can be run to illustrate.

\vspace{0.15in}
\begin{listing}{Example Configuration Block}
\label{lst_bhv_testfail_ex}

\begin{fileverb}
Behavior = BHV_TestFailure
{
  // General Behavior Parameters
  // ---------------------------
  name      = test_failure         // default
  condition = DEPLOY=true          // example
  duration  = 120                  // example
  duration_idle_decay = false      // example (default is true)


  // Parameters specific to this behavior
  // ------------------------------------
  failure_type = hang,2            // example
}
\end{fileverb}
\end{listing}

\noindent
Another configuration style below will result in the behavior
crashing as soon as the behavior meets its run condition. Presumably
the user can simply poke the MOOSDB at any time to invoke the failure,
or another MOOS app may generate the poke at the key desired moment.
The \bvar{failure\_type} is left unspecified since \var{crash} is the
default failure type.

\vspace{0.15in}
\begin{listing}{Example Configuration Block}
\label{lst_bhv_testfail_ex2}

\begin{fileverb}
Behavior = BHV_TestFailure
{
  // General Behavior Parameters
  // ---------------------------
  condition = MUD_HITS_THE_FAN = true    
}
\end{fileverb}
\end{listing}




</pre></body></html>