Reference Document for: USV Payloads for Single Sortie Detect to Engage (SS-DTE) Mine Countermeasures (MCM) Broad Agency Announcement (BAA)

Transcription

1 Reference Document for: USV Payloads for Single Sortie Detect to Engage (SS-DTE) Mine Countermeasures (MCM) Broad Agency Announcement (BAA) PURPOSE - The BAA describes related technology product areas that together support the SS-DTE mission concept. This document provides supporting information and further clarification for the Modular Open System Approach, Payload Manager, Deploy & Retrieve System, and Sustainment tasks. While dependent on Unmanned Surface Vehicle (USV) and Unmanned Underwater vehicle (UUV) capabilities for the mission execution, this effort is assuming future UUV and USV performance will meet necessary requirements and will not expend resources towards any focused development for UUVs or USVs. Following is a more detailed discussion of the above cited four technology development tasks, and the development approach sought. It is assumed that the reader is thoroughly familiar with the BAA content, and a majority of that information will not be repeated in this document. 1 Task (1) Modular Open Systems Approach (MOSA) The Open Architecture (OA) approach of the overall effort should functionally separate system integration from the discrete module or component development efforts. An explicit software engineering process should be employed that supports this approach. The final integrated product shall preclude long term dependence on closed or proprietary interface standards, technologies, products, or architectures. The use of existing standards, where possible, is encouraged. The design shall provide sufficient growth and open interface standards to allow future reconfiguration and addition of new capabilities without large-scale redesign of the system. The government web site, provides a good reference to MOSA to include rationale and trade-offs to consider when designing a system. The following sections provide additional clarity on MOSA requirements and definition of the system integration task. It is not intended to impose bounds on how the integrator should proceed, but introduces some of the areas that should be addressed. The Government will work with the contractors to define module functions, and interfaces as the system design matures. 1.1 Language Specification If required, the system integrator will be responsible for selecting an appropriate programming language with which to glue discrete modules together. This selection should not impose restrictions as to which programming languages developers use to build their discrete modules. However, the system integrator should be prepared to work with developers to define how these modules will interact with the backbone, such as a network communication protocol or shared memory. 1

2 1.2 Module Guidelines In this document, the term module refers to a discrete behavior or functionality required to fulfill the requirements of this program (e.g. a path planning module). The term component is a more generic reference to software processes performing tasks to achieve the above stated functionality. It is desired that a modular approach be implemented at the component level whenever possible. Figure 1 below depicts an example of interaction between components, modules, and the payload manager Figure 1 - Example of interaction between components, modules, and the payload manager Software Design Principles Well established software design patterns should be employed to help achieve an effective modular design Components Component based designs allow for a great deal of flexibility within a system. When discrete components are tied together using network communications, a leading industry standard protocol should be used Libraries Major module functional blocks and key components should be compiled as linked libraries whenever possible. This will allow for the insertion of new behaviors or the substitution of outdated ones as new methodologies become available. The configuration file approach mentioned below will allow the module or component to load appropriate libraries at runtime and execute them. If certain modules require the functionality of others, an iterative load, initialize, finalize protocol could be employed to ensure counterparts are active. In the event of failure, notices should be highly verbose. 1.3 Configuration Files Each component should utilize a configuration file to initialize key functionality. For example, required input file locations, output log file locations, and p values for a low pass filter could be placed here. This will allow future modifications to module performance without recompilation. In the event of a missing or corrupt file the module should create a new default configuration file and alert the user. These files should contain a commented explanation for every setting. Figure 2 below shows an example configuration file. 2

3 <?xml version="1.0" encoding="utf-8"?> <Configuration> <!--This setting sets a property--> <Setting1>1</Setting1> <!--This setting sets another property--> <Setting2>2</Setting2> </Configuration> Figure 2 - Example configuration file 1.4 Log Files Each component should keep a log of pertinent activity performed while active. This will aid in troubleshooting unexplained behavior. These files should also indicate specific times that important events occur. 1.5 Functional Block Diagrams The integrator should maintain a highly detailed functional block diagram of the overall system and work with developers on interfacing standards for the lower level modules. These block diagrams should include communication directionality and the associated standard that was chosen. 1.6 User Guides Every module developer should provide a user guide that specifically outlines, at a minimum, the concerns laid out in this section Key components Modules can potentially contain many discrete components to fulfill their responsibilities. For example, an adaptive path planner might have a component monitoring weather conditions and another component measuring sea state. A third component with decision making authority might subscribe to their data to optimize its path. The user guide should include detailed descriptions of these components as well as if and how they can be substituted with other components Interface requirements Key components should be modular and follow the interfacing design principle. These interfaces or abstract base classes should be thoroughly described and be accompanied by diagrams showing their members/methods/properties. Figure 3 below shows a C# interface and the associated visual studio class diagram. public interface IModule { string Name { get; } string SettingsFileName { get; } void Go(IHelpModules modhelper, string inputargs); } Figure 3 - C# interface and the associated visual studio class diagram 3

4 1.6.3 Compilation requirements User guides should include step by step instructions for compiling code into libraries or executable programs Configuration settings The configuration file should be described in sufficient detail so that the user can easily find and modify values to suit their needs. Every available setting, acceptable ranges, default settings, and expected behavioral changes due to modifications should be discussed. 1.7 Communication Specification A well-documented and accepted communication standard or standards, if appropriate, should be chosen for communication among modules and components. For example, the SAE-AS4 standard could be imposed between unmanned vehicles and XML over TCP between discrete components. In figure 4 below, a notional communication path between two components (top) and a component and a UUV (bottom) is depicted. The component to component communication method is a TCP connection using XML messages. The component to vehicle communication method is a TCP connection using XML messages. The component to vehicle communication method is a TCP connection using the JAUS format. Figure 2 - Notional communication path between two components (top) and a component and a UUV (bottom). 4

5 2 Task (2) Payload Manager (PM) The PM architecture must be such that it supports both the inclusion of additional functionality as well as the upgrade of hardware and firmware. The PM (to be developed in accordance with MOSA principles) is a compilation of multiple functional blocks / modules that support, execute, and manage all actions necessary for the SS-DTE mission. The PM and its functional components reside on computing resources that are on the USV. The USV will have its own command and control architecture, and details of PM / USV interoperability will be addressed as the development process evolves. The PM component of the SS-DTE system will also perform, as a minimum, the following functions: Coordinates/manages all on-board USV payload activities o Off-board system (UUV or towed body) sortie planning and coordination o Off-board system deploy and retrieve and related USV actions o Off-board system sustainment functions (energy replenishment) o data flow to & from the Automated Target Recognition (ATR) algorithms o packaging/handling of data to the USV comms system (that is sent to LCS) o neutralization actions (based on target information sent from LCS) Ensures UUVs and USV are at safe positions when performing Target Neutralization missions. Plans USV track/position for status monitoring of underway UUVs. 2.1 High-Level Overview Figure 5 below shows a high level overview of the UUV planning and execution tasks performed by the SS-DTE system for a notional UUV-based Mine Countermeasures (MCM) payload. Figure 5 UUV Planning and Execution Task. 5

6 The following sections briefly describe the above functions, as well as some (not necessarily all) of the additional functional components (or modules) that reside in the PM and comprise SS-DTE High Level Operation Planning A MCM operation is typically scheduled over multiple days. As such, a single sortie for the SS-DTE system is really part of a larger MCM operation, which defines the search mission for the SS-DTE system. Therefore, this MCM operation must be planned using estimates of the SS-DTE system s performance, and the SS-DTE must perform its sortie while satisfying the goals and schedule of the high level operation Bottom Search/Planning The SS-DTE will include MCM off-board assets capable of performing a bottom search. Initially, it is assumed that these will be UUVs using side scan sonar systems, with navigation capabilities and performance estimates based on environmental and vehicle factors. These bottom searches must be planned and scheduled to cover the search area in the allotted time, satisfying the performance thresholds defined for the mission. This search generates sonar data that must be processed with Automated Target recognition (ATR) to determine the presence and location of potential mines Volume Search/Planning The SS-DTE will also include MCM assets capable of searching for volume mines. The SS-DTE MCM assets could be heterogeneous, where only specific, proper subsets of assets can perform volume search, and these may be distinct from the assets capable of bottom search. These volume searches must be planned and scheduled to cover the search area in the allotted time, satisfying the performance thresholds defined for the mission Near Surface Drifter Search/Planning The SS-DTE system is also tasked with locating and neutralizing near surface and drifting mines. This will most likely be accomplished using coordinated air assets, such as Unmanned Air Vehicles (UAV) or manned aircraft to locate these mines and assist the USV in neutralizing them. Since the presence of such mines threatens the SS-DTE system itself, this task may be performed first, before any other tasks take place. Furthermore, in the event that a surface or drifting mine is detected during other tasks, it is highly likely that this will result in aborting those tasks, and switching to a near surface drifter neutralization mission. As such, it is assumed that, during other tasks, that there are no known surface or drifting mines present Automatic Target Recognition (ATR) The Bottom mine search mission produces sonar data that must be processed to determine the possible presence and location of mines in the search area. This will be performed using ATR algorithms (not a development component of these BAA tasks). Currently, ATR is a computation-intensive process, and current MCM UUV assets are 6

7 not capable of performing ATR while sustaining adequate sortie endurance. However, future advances in ATR may impact the time required to perform ATR, as well as the ability to distribute ATR across the SS-DTE MCM assets. Therefore, the planner must be capable of determining asset allocation and scheduling based on ATR results during the MCM mission as needed, for a variety of potential SS-DTE MCM asset capabilities. For this initial development effort however, the PM will take the ATR products (sonar snippets of potential targets) that are compiled on servers on-board the USV, and package them for transmission to LCS via the USV comms system. Human operators on-board LCS will designate them as mine like or not and send targets back to USV for the Re-Acquisition and Identification (RID) mission Target Identification/Planning The detection and classification process produces a list of likely mine contacts, along with their corresponding locations in the search area. These contacts must be identified as either mines or false targets. The SS-DTE system will include MCM assets capable of performing mine identification. This mine identification task must be planned and scheduled by the PM. Current and future mine identification tasks may involve different levels of human supervision, which the PM must take into account. The initial development effort will support a process in which an operator aboard LCS makes the mine/non-mine determination Mine Neutralization/Planning The RID mission produces a list of confirmed mines and their locations in the search area. The PM must plan and schedule the neutralization of these mines using its onboard neutralization assets. While these assets and their availability are to be determined, it is assumed that these will be similar to the Navy s Common Neutralizer. Mine neutralization must take into account the proximity of all MCM assets to any potential mines, in order to prevent damage or loss of MCM assets due to mine detonations. 2.2 UUV Autonomy Behaviors The following behaviors must be supported by UUVs for the SS-DTE system: 1. Deploy from USV 2. Recovery to USV 3. Bottom Search 4. Volume Search 5. Target Identification 6. Status Updates to USV during the sortie Deploy from USV The UUV will transition from a docked state on board the USV to a detached, independent state. At this point, the UUV must navigate safely in the vicinity of the USV and begin executing its mission. It must avoid collision with the USV during these maneuvers. This may or may not require communication or cooperation with the USV. 7

8 Effective launch may also require maneuvering relative to current environmental conditions, including sea states, currents, and winds Recovery to USV The UUV will transition from a detached, independent state, to a docked state, on board the USV. This requires the UUV and USV to rendezvous at a location safely, while avoiding collision with each other. Once the UUV and USV are sufficiently close to each other, the necessary autonomy for accomplishing this recovery is heavily dependent on the Deployment and Retrieval System (DRS) and Sustainment modules used for recovery and the docked configuration in connecting the UUV and USV for data and power transfer. For example, this may require the UUV to drive into some sort of docking station, or submersed portion of the USV. It could also require a crane on board the USV to grab the UUV. Each possibility implies a different navigation approach for the UUV relative to the USV, and vice versa, in order to achieve the correct initial and final conditions for recovery. Effective recovery may also require maneuvering relative to current environmental conditions, including sea states, currents, and winds Bottom Search UUVs equipped with side scan sonar will conduct bottom searches of a defined search area. A set of parallel search tracks will be calculated by a planner such that they achieve a desired level of clearance level over the search area. Planning will be described in a following section. This bottom search produces sonar data, which must be processed by ATR to determine the location of potential mines Volume Search It is assumed that a volume search is constrained in the same manner as a bottom search. However, since a volume searcher is using forward look sonar, it is assumed that its clearance rate is much higher than bottom search. This volume search produces a set of mine contacts in the water volume. In some cases, it may be acceptable to immediately assume that any stationary volume contact is a mine Target Identification The bottom search mission generates sonar data that, when processed using ATR, produces a set of possible mine contacts. Each of these must be visited by a UUV capable of generating target identification sensor data. It is assumed that forward looking sonar and/or magnetometer will be used for this purpose. The UUV may be required to visit each mine like contact, and perform a maneuver (for example, perhaps a star pattern) over the contact, while generating data Status Updates During operation, each UUV will be required to periodically broadcast through acoustic communication its status to the USV. This status information will/may include vehicle status information (such as vehicle health, battery power, etc.) along with mission status information (such as waypoint ETAs, navigation performance estimates, in-situ sensor 8

9 performance estimates, etc.). This information will enable the USV to adapt and plan in response to events that occur during the mission. The frequency of this status update must be configurable and controllable by the PM. 2.3 USV Autonomy Behaviors The following behaviors must be supported by the USV for the SS-DTE system: 1. UUV Deployment 2. UUV Recovery 3. UUV Status Monitoring 4. Mine Neutralization UUV Deploy The UUV will transition from a docked state on board the USV to a detached, independent state. This will require the USV(under PM control) to initiate this deployment, and to manipulate the UUV as it transitions from a docked state to an independent state. At this point, the USV must navigate safely in the vicinity of the UUV as it continues its mission. It must avoid collision with the UUV during these maneuvers. This may or may not require communication or cooperation with the USV. Effective deployment may also require maneuvering relative to current environmental conditions, including sea states, currents, and winds UUV Recovery The UUV will transition from a detached, independent state, to a docked state, on board the USV. This requires the UUV and USV to rendezvous at a location safely, while avoiding collision with each other. Once the UUV and USV are sufficiently close to each other, the necessary autonomy for accomplishing this recovery is heavily dependent on the hardware and mechanisms used in connecting the UUV and USV for data and power transfer (DRS and Sustainment modules). For example, this may require the UUV to drive into some sort of docking station, or submersed portion of the USV. It could also require a crane on board the USV to grab the UUV. Each possibility implies a different navigation approach for the USV relative to the UUV, and vice versa, in order to achieve the correct initial and final conditions for recovery. Effective recovery may also require maneuvering relative to current environmental conditions, including sea states, currents, and winds UUV Status Monitoring While the UUVs are executing their various missions, the USV is required to monitor status updates which are periodically provided by the UUVs. These status updates (or their absence) inform the USV of vehicle status and mission status, including important events such as UUV failure, power anomalies, inability to complete missions, and sensor/search performance/results during the mission. This allows for the PM to change the mission plan during execution as necessary. Since the acoustic communication hardware may have limited range, and since this limit may depend upon time-varying and environment-varying factors, the PM may be 9

10 required to predict the locations of the UUVs during their missions and navigate the USV accordingly, estimating the acoustic communication range and effectiveness, as well as UUV positions, in order to receive their status updates Mine Neutralization Target identification will provide the USV with a set of mines to neutralize and their locations. The USV is equipped with a specified number of mine neutralizers and shall not define a set of mines to neutralize larger than its number of neutralizers. The USV is required to deploy these neutralizers in a manner consistent with the neutralizer itself, while also making sure that all friendly forces and assets are sufficiently far enough away from any mine to avoid damage from detonation of the mine being neutralized, as well as sympathetic detonations. These details must be addressed by a mine neutralization planner. 2.4 SS-DTE MCM Support Functions In addition to these capabilities, the SS-DTE system must perform the following support functions: 1. MCM Asset Deployment/Retrieval Planning 2. In-Situ Adaptive Planning and estimation 3. LCS Data Flow MCM Asset Deployment/Retrieval Planning/Scheduling To support all planned and scheduled search, identification, and neutralization tasks, MCM asset deployment and retrievals must be planned and scheduled. Autonomous MCM asset deployment and retrieval behaviors are to be determined, as well as their requirements on initial conditions for asset retrieval, their final conditions for asset deployment, the expected durations, and the required environmental conditions (i.e., sea states, depths, etc.), which facilitate planning. MCM asset deployments and retrievals must be scheduled to facilitate mine searches, identification tasks, and neutralization, as well as replenishing MCM assets (i.e., refueling/recharging UUVs), exchanging data after MCM asset retrievals, performing ATR, and changes in mission, such as operator-initiated mission scrubs and system faults and failures. MCM asset deployments and retrievals require safe, collision-free navigation, and potentially require coordinated navigation between USVs and MCM assets (i.e., UUVs). Effective deployments and retrievals may also require specific environmental conditions, such as sea states, currents, and winds. These factors must all be taken into account during deployment and retrieval planning and scheduling In-Situ Adaptive Planning and Estimation In-situ performance estimation will occur during mission execution. This will provide the planner with sensor performance estimates based on environmental factors, as well as updated estimates of Enemy Course of Action (ECOA). ECOA estimate determinations are not part of this BAA development, but may be a functionality that resides on the onboard USV servers, or comes from LCS. These estimates affect the overall estimates of 10

11 search performance, as well as the potential outcomes of future searches, the required mine identifications for the mission, and the required mine neutralizations. Each of these tasks, therefore, requires in-situ adaptive planning, changing the overall asset allocations, times, locations, and navigation required for each task. In-situ adaptive planning is also required to handle system faults and failures, such as inoperable sensors, navigation errors, unexpected deviations, and possible MCM asset failures. Furthermore, SS-DTE system operators may decide to change or scrub the search mission during execution. Note that future capabilities may allow for in-situ performance estimation across multiple MCM assets. Therefore, each autonomous asset may be required to support in-situ adaptive planning, with assets potentially coordinating and/or cooperating to adaptively plan the rest of the MCM mission. In-situ adaptive planning must allow for adapting SS-DTE system performance with this information collected during the mission. It will allow for improved estimates on the performance of the search conducted so far, while also projecting and estimating the schedule and duration of future MCM tasks, as well as the overall system performance in searching and clearing the mission area Littoral Combat Ship (LCS) Data Flow Human operators on board the LCS will monitor the USV and UUVs during the mission via the existing USV-to-LCS Comms system. Such information may be crucial towards scheduling, or permitting the rescheduling, of USV launch and recovery with the LCS. The PM is responsible for packaging data and providing to the Multi-Vehicle Communications System (MVCS) in accordance with an existing interface control document. UUV status will be acquired via acoustic communication during missions, and directly from UUV when docked on USV. This information could include, but not limited to, vehicle and mission status, UUV/USV health, endurance, estimations of search effectiveness and time to complete the mission, and UUV charging status. Additionally, the ATR products will be passed to LCS and mine like targets to ID and subsequently neutralize will be passed back to USV. During the Neutralization evolution (for tethered neutralizer) real time sensor data will be passed to operators on LCS that will execute the fire command. 3 Task (3) Automated Deploy and Retrieval of UUVs from a USV The BAA indicates interest in design concepts for a Deploy and Retrieve System (DRS) for a range of UUVs as well as scalability (as appropriate) of designs. It is not assumed that one configuration of a system will be suitable for all UUV classes, although such flexibility is desirable. The multiple classes of UUVs under consideration are: Man Portable (MP) 7 ½ - 9 dia, 5-6 ft long, 125 lb estimated wt. Light Weight (LW) 12 ¾ dia, ft long, 800 lb estimated wt. 11

12 Heavy Weight (HW) 21 dia, 9-19 ft long, lb estimated wt. Tethered Tow Fish or Powered Tow Body (PTB) dia, 7-12 ft long, lb estimated wt. While scalability for the various UUV classes noted above is desirable for concept evaluation, the system configuration chosen for demonstration (and that will be addressed in greater detail if a proposal is requested) will consist of four - 12 ¾ in REMUS 600 variants. The notional UUV configurations will be two Search-Classify-Map vehicles, and two volume-search vehicles that can also perform Re-acquire/ID missions. The potential D&R configurations for this baseline system include: One system that allows on-board USV handling/movement of the four UUVs Two systems/2 UUVs each - with associated handling Four separate systems (1 UUV each) The UUVs will need to be able to be aligned adequately in their recovery cradles to support an interface for the data transfer and charging (sustainment) component discussed in Task 4. Optical & inductive data transfer options as well as stab and standard connector and inductive and resonant-inductive energy transfer options are currently under consideration for the sustainment portion of cycle (and are discussed in separate section of this document). The DRS will have the requirement to incorporate the sustainment function (and subsequent mechanism) into design. The following (as a minimum) are attributes and categories/metrics that should be addressed in presenting DRS approaches: - nominal deck (on USV) footprint - overall envelope dimensions (with & without UUV) - in 'stowed/recovered' configuration - overall envelope dimensions for the D&R process - UUV design/interface requirements - ability to accommodate forward tri-fins on UUV - ability to accommodate forward looking sonar - estimated UUV D&R system weight - required USV interface - to include electric power/hydraulics, etc. - allowable trade space for sustainment function - UUV alignment in cradle to support sustainment activity - ability to access engine compartments while aboard host (LCS) platform Minimum sea state for DRS operation is SS3. Underway recovery speed (for UUV & USV) is not set at this time. Final USV platform configuration for the potential fielded system is not determined at this time, but it will be ft in length with 9 ½-11 ½ ft beam and compatible with launch and recovery from the Littoral Combat Ship (LCS). 12

13 The Navy is in the process of identifying possible USV surrogate candidates to use for work up development and final demo of the DRS and SS-DTE system. It is not certain that a USV will be the actual demonstration platform. One of the components of this development is to ID USV requirements that will be 'pushed up' to help define what the actual fielded SS-DTE USV will need to be. As initial design options evolve for the DRS, appropriate interface accommodations for USV surrogate integration will be addressed. The Government will work with potential vendor(s) to indentify critical interfaces and address the necessary trade-offs in using a surrogate USV. Additionally, it is anticipated that minor modifications/adaptations to the UUV to accommodate required DRS interfaces may be required. 4 Task (4) Sustainment: Automated Energy and Data Transfer. The short hull section that is anticipated to be added to the REMUS 600 is the trade space for the sustainment function. The data transfer component of the system will be demonstrated by accessing an approximately one terabyte hard drive of actual vehicle and sonar data that will be included inside the added hull section. The data shall be passed to the on-board (USV) computing suite that executes data processing, management, and the Payload Manager function. The battery charge component of system will be implemented based on the selected replenishment scheme. It will incorporate whatever physical interface is required to support the selected charging approach. Offerors are responsible for constructing/providing the hull section that contains their sustainment element. 13