Technology Requirements Model

A key player in SAS activities is the Technology Requirements Model (TRM). TRM is an integrated, selectable-fidelity underwater warfare digital simulation that is physics-based, and empirically validated. TRM models a wide variety of underwater vehicles (torpedoes, countermeasures, anti-torpedo torpedoes); submarine and surface-ship targets; high-frequency sonars for submarines (chin, sail and bow conformal array); torpedo detection, classification, and localization (TDCL) systems; signal-processing techniques; vehicle control systems; environments; and dynamic interactions among objects.

TRM has been used extensively by ARL in its technology assessment and technology development efforts. It has been used to determine the feasibility of a particular technology or to assess the viability of a conceptual system; and also used in a simulation-assisted design mode to develop the initial point design for vehicle systems; and used to assess the design as it evolves, to do the pre-run planning for the test of the design, and to conduct the post-run analyses.

From its inception, TRM made modularity a primary goal. This goal was driven by a desire to have available in TRM multiple models of physical phenomena at varying levels of fidelity. At the foundation of TRM is a library of software modules that can be incorporated into a specific system simulation, along with new modules, as required. This library, known as CARLEE, includes: algorithmic models of technologies that might be incorporated into a vehicle system, environmental and object models that make up elements of the synthetic operations space, dynamics models, and target models. Each module has well-defined and rigorously controlled interfaces, allowing for interchangeable modules for a particular function. Thus, for example, a signal processor module developed at a Navy laboratory can be plugged into a vehicle simulation and its absolute and relative effectiveness can be quickly measured.

With TRM, the user can select the fidelity required for the application, and can “verify” the appropriateness of a selected fidelity by comparing the results from runs made using reduced-fidelity models to results from runs made using higher-fidelity models. As an example, a person developing terminal-homing tactics may start with a four-highlight target model while evaluating a terminal homing concept, and then increase the fidelity of the highlight model as the concept evolves. As another example, the primary acoustic sensor can have a module that describes its response function as merely a field of view, or one that computes the pattern using array theory, element responses, and a physical description of the array.

The modular structure of the TRM architecture and its associated library, CARLEE, enables the rapid prototyping of notional systems; the conduct of effective tradeoff studies as discussed above, by matching the fidelity of the simulation components to the needs of the study; the comparison of system alternatives in a common environment; and the execution of multi-object scenarios with full accountability of acoustic, magnetic, and dynamic interactions among all objects.

A major strength of TRM is that it is a Monte Carlo simulation. The Monte Carlo capability provides a measure of the subsystem or system simulation’s performance stability. The Monte Carlo mode is required to account for the stochastic nature of sound propagation in the ocean environment and the variability of target strengths, and to reflect the subsequent effect on received signal levels. For threshold-driven systems, variations of a fraction of a decibel in received levels can cause performance to vary substantially. Multiple replications provide a measure of this variability. If a statistically significant fraction of the simulation runs produce agreement with the in-water performance, reasonable levels of confidence can be placed on its validity as a representation of the weapon system. It should be noted that in-water runs, when performed in sufficient numbers, display significant levels of performance variability.

The primary metric used in the design of TRM is performance. The performance metric is quantified in terms of simulation throughput (how fast the simulation runs), fidelity of the models, and cost to develop new features. As TRM evolved, the software engineering practices used in TRM have also evolved, provided that these new practices did not adversely affect throughput performance.

A Configuration Management (CM) Plan has been developed for TRM, and is rigorously followed. The CM Plan is a protocol for controlling and tracking the evolution of all TRM components. The plan describes the duties of various individuals associated with configuration management, and covers CM for TRM library stabilization, models and data from outside sources, input files, and supporting codes and utilities.

TRM has been installed and is being used by the Naval Undersea Warfare Center (NUWC), Newport Rhode Island; NUWC Keyport, Washington State; Naval Surface Warfare Center (NSWC)/DD/CSS, Panama City, Florida; Submarine Development Squadron 12, Groton, Connecticut; and several other departments within ARL.

TRM Simulation Components

The TRM simulator is an aggregate collection of TRM system-specific simulations, all based on the Common ARL Engagement Evaluator (CARLEE), which are used to simulate a complex underwater engagement.

A TRM simulation is a simulation of a specific system. For example, TRM has simulations of specific torpedoes, countermeasures, and sonar systems. Each simulation consists of three basic components: the simulation shell, the simulation-specific routines, and the common code, described below.

The simulation shell consists of a generic Main Program, initialization and termination routines tailored to the specific system, a time-step controller, and two interface routines that allow the simulation to participate in the aggregate TRM simulator.

As TRM evolved, and was used for non-torpedo simulations, it became quite apparent that certain portions of a simulation were common to all simulations. At that point an effort was made to extract the common portions from each simulation and put them into a common library, called the (CARLEE).

CARLEE provides a common set of compatible and interchangeable acoustics and dynamics properties for targets (surface and submarine), countermeasures, and the environment. CARLEE provides a venue for making direct comparisons among different acoustic, dynamics, and environment models. The reason for making such comparisons is not to make judgments regarding the absolute worth of a model, but to allow the user to select the most appropriate model for a particular study. For example, when designing fundamental tactics for a torpedo, one could specify that lower-fidelity environmental models from CARLEE be used. By specifying increased-fidelity models, one could then quantify environmental effects on system performance.

A common library also allows comparison and evaluation of different weapons systems against the same scenario.

CARLEE provides a single mechanism for incorporating new features and enhancing existing features for all simulations. Once CARLEE is updated, all simulations are updated when they are re-linked.

The consolidation of all system-independent code minimizes the code related to model maintenance.

Capabilities resident in CARLEE are shown in the list below:

• Acoustic models
  • Ambient noise
  • Acoustic propagation
  • Reverberation
  • Countermeasures
  • Radiated noise
  • Surface ship and torpedo wakes
• Environmental false targets
• Magnetic models
• Generic ship sonar models
• Generic countermeasures
• Specific countermeasures
• Generic torpedoes
• Object dynamics models
• Acoustic infrastructure
• Generic signal processing models
• Ship hit models
• Object controllers
• Output
• Data recording
• Initialization
• Mathematical functions
• Various utilities

Each TRM simulation operates by taking a collection of input files and generating a number of output files. A collection of generic routines exists for creating the input files, connecting the input files to other TRM simulations, and processing the output files. Some ancillary programs are used to access simulation subsystems without exercising the entire simulation. Others allow for direct access to the models in CARLEE.