22   The TestFailure Behavior


22.1 Configuration Parameters


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.

    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. 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. 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 assert(0) statement, and the hang is implemented with a long for-loop.

22.1   Configuration Parameters    [top]


Listing 22.1 - Configuration Parameters Common to All Behaviors.

activeflag:A MOOS variable-value pair posted when the behavior is in the active state. Section 6.5.4.
condition:Specifies a condition that must be met for the behavior to be running. Section 6.5.1.
duration:Time in behavior will remain running before declaring completion. Section 7.2.6.
duration_idle_decay:When true, duration clock is running even when in the idle state. Section 7.2.6.
duration_reset:A variable-pair such as MY_RESET=true, that will trigger a duration reset. See Section 7.2.6.
duration_status:The name of a MOOS variable to which the vehicle duration status is published. Section 7.2.6.
endflag:A MOOS variable-value pair posted when the behavior has completed. Section 6.5.4.
idleflag:A MOOS variable-value pair posted when the behavior is in the idle state. Section 6.5.4.
inactiveflag:A MOOS variable-value posted when the behavior is not in the active state. Section 6.5.4.
name:The (unique) name of the behavior. Section 7.2.2.
nostarve:Allows a behavior to assert a maximum staleness for a MOOS variable Section 7.2.9.
perpetual:If true allows the behavior to to run even after it has completed. Section 7.2.7.
post_mapping:Re-direct behavior output normally to one MOOS variable to another instead. Section 7.2.4.
priority:The priority weight of the behavior. Section 7.2.3.
pwt:Same as priority.
runflag:A MOOS variable and a value posted when a behavior has met its conditions. Section 6.5.4.
spawnflag:A MOOS variable and a value posted when a behavior is spawned. Section 6.5.4.
templating:Turns a behavior into a template for spawning behaviors dynamically. Section 7.7.
updates:A MOOS variable from which behavior parameter updates are read dynamically. Section 7.2.5.

Listing 22.2 - Configuration Parameters for the TestFail Behavior.

ParameterDescription
failure_type:Fail by crash, or fail by hang.

    Choosing to fail with a crash will result in behavior executing an assert(0) as soon as the behavior enters the running state. Configuring for a 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.

    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 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.

Listing 22.3 - Example Configuration Block.

 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
 }

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 failure_type is left unspecified since crash is the default failure type.

Listing 22.4 - Example Configuration Block.

 Behavior = BHV_TestFailure
 {
   // General Behavior Parameters
   // ---------------------------
   condition = MUD_HITS_THE_FAN = true    
 }

Page built from LaTeX source using the texwiki program.