LRAUV  revA
Architectural Requirements

Use a state-configured layered control architecture

  • This requirement is based on favorable experience with layered control in the past, combined with its capability to working in conjunction with out-of-process planners and schedulers, as demonstrated on the MBARI Dorado AUV.

Limit the interconnectedness of code to minimize full-system recompiles.

  • The intent of this requirement is to:
    1. allow users to add functionality to the code base, without having access to the entire code base – only to those headers required for building a module. This may be intellectual property issue for the party that licenses the Tethys/LRAUV for production.
    2. reduce the need for full recompilation as part of the vehicle reconfiguration process
    3. allow the distribution of new vehicle functionality as software modules
    4. allow a faulty module to be swapped out, potentially at sea, without swapping out the entire executable.
    5. enforce a "clean" interface between software components.
    6. provide a flexible API that can accommodate scripted code as well as compiled code.
  • The classes under the modules Module and Component provide this functionality.

Channel communications between software units through a single “slate”

  • The intent is to provide asynchronous communication between software elements, and provide a single-point view on the state of the vehicle and the software at any point in time. The state table also provides a common location and mechanism for data logging.

Use "Universal" Data Values

  • In some cases, there will be multiple sources of information for a given measurement. For example, there will likely be a primary pressure sensor, but possibly also auxiliary pressure sensors on other instrumentation, as well as a dead-reckoned pressure estimate. What if the primary pressure sensor fails? If a controller is expecting pressure from the primary pressure sensor, it too will fail. However, if it is just expecting "pressure", an intelligent agent could give it the "best available" pressure at the time of request.
  • The intent of this requirement is to provide such a strategy for the LRAUV.

Simplify code execution to simplify debugging

  • The intent of this requirement is to ensure that if the code hits a breakpoint, the programmer has a high degree of confidence that the other parts of the code will also stop.
  • This requirement does not preclude using multiple threads or multiple processes.
  • Our approach to meeting this requirement is to use sequential nested threads, described under Sequential Nested threads

Isolate, log, and tolerate software faults

Track dependencies of code segments upon each other

  • Intent is to be able to see how failures propagate through the system, automating and internalizing a portion of the vehicle's failure mode effects analysis.
  • Information for tracking dependencies is provided by having components declare to the slate what their inputs and outputs are, by name. This allows the system to create a forward and backward dependency tree for each variable. It allows one to see what failures may affect a computation unit, and to see how the failure of a sensor (for example) may affect the capability of the system to execute mission commands and behaviors.
  • Todo:
    Automatically generate failure effects analyses in the event of failures, and use these analyses to avoid unachievable mission states.

Allow future integration of on-vehicle mission planning and scheduling.