SIMULATIONBASED TESTING

1
SIMULATION-BASED TESTING OF SHIP SELF DEFENSE
Richard A. Reading VisiTech Ltd. Ronald J.
Sawyer Program Executive Office Theater Surface
Combatants
2002 Spring Simulation Interoperability Workshop
2
Outline

• PRA OVERVIEW
• Ship Defense Operational Context
• Combat System Assessment the PRA MOE
• PRA Simulation Testbed
• Common Architecture
• Testbed Demonstration
• Build 1 Lessons Learned
• Way Ahead

3
Context Ship Self Defense
Ship Self Defense System-of-Systems

• THREATS
• Low-slow
• Mach 1
• Low-fast
• Mach 1-3
• High diver

DETECT Mk 23 TAS SPQ-9B SPS-48 SPS-49 SPS-67 SLQ-3
2 IRST TISS MFR
CONTROL ACDS SSDS SWY 1/2/3
ENGAGE CIWS RAM NSSMS ESSM SLQ-32 CHAFF DECOYS NUL
KA
CEC

• In less than 50 seconds for a Mach 1 threat the
  defenses must
• Detect the target
• Establish the track
• Classify the target
• Decide to engage
• Assign weapons
• Activate engagement spt
• Fire/launch
• Fly out intercept
• Re-engage, if needed

Ship Self Defense Reaction Timeline

• Mach 3 threat Ship will have 20 seconds to
  respond
• Mach 2 threat Ship will have 35 seconds to
  respond
• Mach 1 threat Ship will have 50 seconds to
  respond

4
Layered Ship Defense

• At any point on the battle timeline multiple
  systems are employed
• Sensor and EA performance occur over a span of
  the battle timelinecant be characterized by a
  single discrete event
• Multiple systems generate multiple interactions
  between environment, threat, and ships combat
  system

V-G018.psd
5
PRA Genesis
Probability of Raid Annihilation is the ability
of a particular stand-alone ship as a system to
detect, control, engage, and defeat a specified
raid of threats within a specified level of
probability in an operational environment
In 1991, Conventional Systems Committee study
was initiated to determine the combat system
performance of shipboard weapon
systems Probability of escaping a significant
hit (PESH) was the measure of effectiveness to
clearly measure weapon system performance By
1996 PESH evolved into PRA ambiguity was
associated with defining how to judge
significant hit
PRA was first used in the POM 94 analysis
and then became a firm requirement in the new CRD
(Feb 96) ORDs begin to incorporate PRA but
TEMPs continue to break PRA down into track,
react, engage
LPD 17 is first ship class TEMP to include a
measure of PRA
6
PRA Assessment Process Objectives

• Provide PRA ship class results to meet OPEVAL
  requirements across ship classes in a consistent
  and adequate manner
• Provide CS insight to the Program Offices and the
  Ship Defense CSE
• Provide system capabilities and limitations as
  inputs for Fleet tactics development

The PRA score is not important without the why
7
Navy PRA Assessment Process
Previous Ship Class MS and Federation Products
Ship Class PM Managed Process
ü
Create Ship Class Combat System Simulation
Products And Infrastructure Applied To Next Ship
Class
New Ship Class Specific Requirements PARM Models

• PEO TSC
• Infrastructure Support
• Process Configuration Management
• Consistent Threat
• Continuity
• Expertise, Corporate
• Experience

Validation Process (SDTS, At-Sea Testing,
LBTS, DEP, Lab, etc.)
PRA Assessment
8
PRA Federation of Models Target Architecture
Ownership
Sensor Federates
Electronic Attack Federates
Ship Class PMs
Control System Federate
Ship Federate
Emissions
Product PMs
Emissions
Signature Data
Sensor Integration
Signature Data
Emissions
Infrastructure
Ship Config. Data
Ship Motion
Command Decision
Motion
Signature Data
Time Domain Interface
Hardkill Missile Federates
Threat Raid Federates
Seeker
Warhead
Scenario Generator (platforms, emitters, etc.)
Seeker
Warhead
Integrated Natural Environment Services
Airframe Motion
Emissions
Airframe Motion
Emissions
Endgame Assessment
Event Logger Data Collection Displays
Autopilot
Signature Data
Autopilot
Signature Data
9
Framework Foundation

• Interoperable simulations on a single runtime
  infrastructure
• Common threat and natural environment
• Unified modeling, distributed execution
• System-to-system communications should be
  IDS-compliant
• System-to-system interactions physics-based
  through the common environment

Process implementation requires a defined
architecture and set of standards
10
PRA Simulation Testbed

• An important tool to support Ship Class PM
  execution of PRA assessment
• Standards for use by element PMs in developing
  system models
• Common services to eliminate redundant
  development and enable consistency across ship
  classes
• Infrastructure for PMs to test models in a SoS
  setting
• Common simulation infrastructure to improve
  validation confidence and efficiency
• A tangible product of the Navy PRA Assessment
  Process that reduces risk increases SoS
  representation fidelity

11
Outline

• PRA OVERVIEW
• Ship Defense Operational Context
• Combat System Assessment the PRA MOE
• PRA SIMULATION TESTBED
• Common Architecture
• Testbed Demonstration
• Build 1 Lessons Learned
• Way Ahead

12
PRA Testbed Build 1 Scope and Purpose

• Initial implementation of interoperable
  simulation architecture
• Proof-of-concept tool for Navy PRA Process
  approach
• Rapid prototype that can be built upon
• LPD-17 configuration is first use case
• Highlights process importance for achieving
  consistent, credible threat and environment
  representations
• Ideal platform for risk reduction
• System component model testing prior to delivery
  to Ship Class PM
• Testbed for retiring simulation risks in PRA
  assessment

13
Testbed Build 1 Configuration
SPQ-9B Federate
SPS-48E Federate
SPQ-9B sensor/scene interface
SPS-48E sensor/scene interface
Threat/EA Federate
Ship motion
Lo-slow seeker
SLQ-32(V)2
SPQ-9B signal processing
SPS-48E signal processing
representative ES receiver
Ship RF signature
Lo-slow airframe
Threat/Target RCS
Threat/Target RCS
IDS compliant system interface
Lo-slow autopilot
Nulka
IDS compliant system interface
IDS compliant system interface
RTI Interface Layer
RTI Interface Layer
RTI Interface Layer
RTI Interface Layer
DMSO RTI v1.3NG
Data Collection Display
RTI Interface Layer
Scenario Control Federate
RTI Interface Layer
RTI Interface Layer
RTI Interface Layer
RTI Interface Layer
RAM Federate
Sensor Fusion Federate
Control System Federate
IDS compliant system interface
SIMDIS
Threat, ship tactics
CEP 2.1A
SSDS Mk-2
Simple seeker
conditions of the day environment data
RAM 3DOF airframe
14
Testbed Data Flow
SPQ-9B Federate
SPS-48E Federate
Ship signature fluctuates with threat-ship
geometry, ship motion, multipath
SPQ-9B sensor/scene interface
SPS-48E sensor/scene interface
Threat processes ship, Nulka, clutter returns
Threat/EA Federate
Ship motion
Lo-slow seeker
SLQ-32(V)2
SPQ-9B signal processing
SPS-48E signal processing
representative ES receiver
Threat profile changes reflected in radar
processing
Ship RF signature
Lo-slow airframe
Threat reacts to dynamic signal environment.
Antenna/body orientation flight profile change
accordingly.
Threat/Target RCS
Threat/Target RCS
IDS compliant system interface
Competing Nulka signal includes Beam pattern
effects
IDS compliant system interface
Lo-slow autopilot
Nulka
IDS compliant system interface
RTI Interface Layer
RTI Interface Layer
RTI Interface Layer
RTI Interface Layer
DMSO RTI v1.3NG
Single source of threatflight profile data
yields common battle timeline, integrated HK/SK
engagements
IDS-compliant system-to-system communications
Data Collection Display
RTI Interface Layer
Scenario Control Federate
RTI Interface Layer
RTI Interface Layer
RTI Interface Layer
RTI Interface Layer
RAM Federate
Control System Federate
Sensor Fusion Federate
IDS compliant system interface
SIMDIS
Threat, ship tactics
CEP 2.1A
SSDS Mk-2
Simple seeker
conditions of the day environment data
Threat profile data sent to RAM seeker inherently
includes EA effects
RAM 3DOF airframe
15
Scenario Progression in Testbed Build 1
Threat/EA Federate
SLQ-32(V)2 Federate
Threat 1
SPS-48E Federate
Raid data
Threat/EA Federate
Threat 1
CEP Federate
Contacts
Ship
Launch Orders
SPQ-9B Federate
Ship
Designations
Nulka
Tracks
SSDS Federate
SLQ-32(V)2 Federate
Detections
Threat 2
Threat 2
RAM Federate
RAM 1
Designations
RAM 2
Playback Testbed Data Log
16
Testbed Build 1 Lessons Learned

• Reactive threat representation is viable in
  integrated HK/SK scenarios
• Essential for PRA Assessment
• Integration of models dependent on well-defined
  modeling standards
• Sensitivity analysis should ensure adequate
  requirements without gold-plating
• Experience is essential
• Pilot work enabled our development
• LAN to WAN transition needs to be explored

17
Environment Modeling Process
18
Data Collection and VVA

• VV conducted to understand how well MS data
  compares to live data
• Building confidence for accreditation
• PRA decomposed to metrics then to data to permit
  deliberate decisions and enable tracing of
  decisions to their impact on results

Measured
Live TE
Calculated
Assumed
Data Types
MS
19
Outline

• PRA Overview
• Ship Defense Operational Context
• Combat System Assessment the PRA MOE
• PRA Simulation Testbed
• Common Architecture
• Testbed Demonstration
• Build 1 Lessons Learned
• WAY AHEAD

20
PRA Tools Development POAM
FY01
FY02
FY03
Q3
Q4
Q1
Q2
Q3
Q4
Q1
Q2
Q3
Q4
Build 1 - demo
Build 2
Build 3 - FOC
PRA Simulation Testbed Development
PRA FOM v3, IRD/SSRD v3
PRA FOM v1, IRD/SSRD inputs
Use Case Platform(s) Plan
PRA FOM v2
IRD/SSRD v2
Systems Engineering - FEDEP
mature simulation infrastructure, interface
standards

• requirements development
• software design
• - platform plans/long lead challenges

Platform-specific articulation of risk reduction,
fidelity increase, cost advantage
initial capability, threat, ship, D-C-E
Testbed Build 1

• Development startup
• Pre-integration prep
• Integration sys. testing
• Demonstration

improved threat and INE, improved HK, data
collection visualization tools integration
Testbed Build 2

• Planning/Design
• Federate developments
• Integration execution
• Critical Experiments

multi-HK, multi-mode threat, full HK/SK
experiments vs. raids
Testbed Build 3

• Critical Experiments
• functional allocation (e.g., bandwidth),
• LAN-WAN transition
• integrated natural environment implementation
• common threat representation
• HK/SK integration

• Planning/Design
• Federate developments
• Integration execution
• Critical Experiments

21
Summary

• Interoperable simulations being applied to
  support Navy combat systems TE in unprecedented
  fashion
• Navy PRA Assessment Process allows combat system
  end-to-end testing not otherwise possible via
  live test events
• Sim-centric process absolutely dependent on
  rigorous VV
• PRA Testbed providing foundation for evolving
  Navy PRA assessment process standards and
  architecture
• Common framework is critical to long-term success