The fielding of independently deployed unmanned surface vessels designed from the ground up for no person to step aboard at any point in their operating cycles under sparse remote supervisory control is the next necessary technology leap if we are to drastically reduce the number of personnel required to support our warfighting missions and platforms. The Defense Advanced Research Projects Agency (DARPA) undertook the challenge of developing an autonomy suite and building a ship to accomplish this goal with its vision and invitation in early 2010 for industry to design and build the Anti-Submarine Warfare Continuous Trail Unmanned Vessel (ACTUV). This revolutionary concept for a maritime vessel, currently being built by an industry team led by Leidos, constitutes the first step in developing a ship with autonomous behaviors capable of extended at-sea operations. In order to meet all of the DARPA requirements for ACTUV, the Leidos team had to formulate and implement a robust risk-reduction plan.
Don’t Reinvent the Wheel
Building the first ship of a class carries numerous inherent risks. Construction of the vessel aside, the real science, and hence the majority of the program risk, is in developing an autonomy system that can (1) sense its environment and the health of its own systems, (2) make intelligent decisions to optimize machinery lineups and sensor employment, (3) avoid other ships and obstacles, and (4) execute the intended mission. So, when tasked with developing this maritime autonomy suite for ACTUV, where do you start, and how do you limit the risk in designing the autonomy architecture to meet such complex requirements?
The Leidos team’s first step in risk reduction for ACTUV was to leverage code already written for less complex autonomous systems. In the 1990s, the NASA Jet Propulsion Laboratory (JPL) developed the Control Architecture for Robotic Agent Command and Sensing (CARACaS) for the Mars Rover Project. CARACaS already has been successfully adapted for several unmanned surface vessel programs — e.g., for the work done by DARPA in developing Grand Challenge I and II and for the Urban Challenge architecture for an autonomous ground vehicle. Leidos leveraged the work done by JPL in developing CARACaS and by DARPA in developing Urban Challenge (NREC Engine) to develop a maritime autonomy capability that uses open standards, libraries and tools.
Employ a Truly Open Architecture
The ACTUV autonomy suite contains decision algorithms embedded as software modules using an object-oriented framework in which key interface definitions isolate algorithm implementations. It supports multiple, simultaneously executing decision engines and the arbitration logic to choose the best decisions for future actions. It implements a true open systems architecture (OSA) approach that allows for the autonomy capability to be modularly connected to other subsystems — within the same platform and external to the platform. This “plug-and-play” modularity minimizes life-cycle costs, enables reuse, and promotes healthy competition among capability vendors. It also reduces overall risk to the program. In addition, the autonomy capability implements the Service Availability Forum industry standards to achieve a high-availability solution that results in near-continuous uptime when the system is fully integrated.
The OSA uses the Society of Automotive Engineers (SAE) AS4 Joint Architecture for Unmanned Systems (JAUS) messaging between major segments and the OMG Data Distribution Service (DDS) message protocol layer to achieve advanced quality of service. The autonomy engine is a set of algorithm-level specifications for the behaviors and capabilities of the autonomy platform. It lists all the important, high-level, mission-oriented tasks either planned or implemented in the context of the vehicle scenario. It employs a modular approach that supports a Distributed Hierarchical Autonomy (DHA) model and uses replaceable, modular and standard interfaces.
Putting all of the components and modules together, we end up with an autonomous ship control system that is based on a DHA employing new advances such as self-learning and multi-model arbitration. However, before we take this system to sea, we must demonstrate that our ship can safely navigate and comply with the Convention on the International Regulations for Preventing Collisions at Sea (COLREGS) — basically, we must show that our vessel can operate safely at sea and not collide with another vessel or run aground with only sparse remote supervision. As the system and capability matures, we must also demonstrate that the ship can simultaneously execute that desired mission and comply with COLREGS.
Maximize Modeling and Simulation
To cost-effectively mitigate the risk in our autonomy system performance at sea, we must verify quantitatively that the autonomy path-planner engines can navigate safely on the water. Our systematic approach to this quantitative verification is shown in the following assertions:
Assertion 1: Simulations
If the simulation can be demonstrated to correlate highly with on-water testing results in all relevant qualitative senses, we can be confident further simulation results are likely to reflect actual on-water behavior.
Assertion 2: Metrics
If metrics can be demonstrated to correlate highly with subject-matter experts’ understanding of safe navigation, we can be confident those metrics can be used for evaluation of the path planners.
Assertion 3: Scenarios
If the set of scenarios can be demonstrated to provide good coverage of on-water situations, we can be confident that performing well in that set of scenarios will correlate with performing well in any on-water situation.
Assertion 4: Effective evaluation tools and methodology
If we have a good simulation (as per Assertion 1), good metrics (as per Assertion 2), and a good set of scenarios (as per Assertion 3) along with a path planner that performs well in that environment, we can be confident that the path planner really is capable of doing safe navigation.
These assertions resulted in three distinct categories of products being developed to support the safe navigation requirement analysis for the maritime autonomy program:
- Simulations (Archivist Simulation Integration Framework, Distributed Simulation Environment)
- Metrics (Real-time Autonomy COLREGS Evaluator [RACE])
- Scenarios
Prior to at-sea testing, Leidos conducted more than 26,000 simulation runs modeling more than 750 different meeting, crossing and overtaking scenarios in its System Integration Laboratory (SIL) to demonstrate that the autonomy suite would direct actions in accordance with the COLREGS for avoiding collision. Scenarios were developed with the assistance of former U.S. Naval officers with Officer of the Deck and/or Command at Sea certifications, who used a design-of-experiments approach (levels and factors, bounded by the Taguchi method) and included stand-on and give-way behaviors. The approach used to generate and test scenarios is shown in Figure 2.
Employ a Surrogate Vessel Early
After satisfactory completion of SIL testing, the autonomy suite was installed on a 42-foot test vessel (see photo on page 22), where frequency-modulated continuous-wave and “X”-band radars provided the sensor input to the autonomy suite, and commands from the autonomy suite were forwarded to the vessel’s autopilot for control of the rudder and engines. The test vessel acted as an ACTUV surrogate and allowed for testing of all the autonomy software and ACTUV sensor systems in parallel with the ACTUV ship construction. Before ACTUV ever goes to sea, the autonomy system and sensors will be proven at sea on the surrogate vessel, thereby reducing overall program risk and duration.
To date, more than 100 different scenarios have been executed at sea with the surrogate vessel. During these test scenarios, the autonomy system directed course and speed changes of the surrogate vessel to stay safely outside a 1-kilometer standoff distance from the interfering vessels. The test program clearly demonstrated the ability of the surrogate to maneuver and avoid collision with another vessel and paved the way for follow-on testing involving multiple interfering contacts and adversarial behaviors of interfering vessels.
In addition to the structured test events, the surrogate vessel recently completed a voyage between Biloxi and Pascagoula, Mississippi, with only a navigational chart of the area loaded into its memory and inputs from its commercial off-the-shelf radars. The surrogate vessel sailed the complicated, inshore environment of the Gulf Intracoastal Waterway, avoiding shoal water, aids and hazards to navigation, and other vessels in the area — all without preplanned waypoints or human direction or intervention. During the 35-nautical-mile voyage, the maritime autonomy system functioned flawlessly, avoiding all obstacles, buoys, land, and interfering vessels.
The Leidos team commenced construction of the first ACTUV vessel in 2014. Named Sea Hunter, this prototype vessel is to launch in early 2016 and embark on a 2-year test program co-sponsored by DARPA and the Office of Naval Research. While problems and issues undoubtedly will surface during this test program (they always do for the first vessel of a class), it is hoped that the number and severity of the issues will be minimized by the work, testing and risk-reduction efforts in the design and execution of the program.
In a program as complex and software-intensive as ACTUV, you have to look beyond the “build a little, test a little” approach and find innovative ways to mitigate as much of the program risk as possible, as early as possible. Ultimately, the success of the ACTUV program will have its roots in the risk-reduction efforts employed in building and testing the autonomy system in parallel with the construction of the vessel. Fielding a revolutionary concept such as ACTUV requires a blend of innovative program management, breakthrough technical skill and a tuned test program.