Integrated Air and Missile Defense Distributed Simulations: - PowerPoint PPT Presentation

1 / 22
About This Presentation
Title:

Integrated Air and Missile Defense Distributed Simulations:

Description:

Reduce development costs and time to field new capability and increase ... Time & Position. Source(s) Communications I/F. Sensor I/F. Weapon I/F. System & Service ... – PowerPoint PPT presentation

Number of Views:649
Avg rating:3.0/5.0
Slides: 23
Provided by: pbur7
Category:

less

Transcript and Presenter's Notes

Title: Integrated Air and Missile Defense Distributed Simulations:


1
Integrated Air and Missile Defense Distributed
Simulations Reaping the Benefits of Lessons
Learned
Jayne Talbot Virtual Technology Corp
Dr. Betty Youmans Systems Planning and Analysis,
Inc
Steve Karoly JSSEO
2
Outline
  • Background
  • Mission/Operational Concept
  • JSSEO Approach
  • Integrated Architecture
  • IABM test strategy
  • JDEP Technical Framework
  • IBuild
  • HWIL spiral
  • Lessons Learned
  • Leave behinds
  • Conclusions

3
Operational problemand underlying cause
  • Engagements constrained by
  • Procedural controls
  • Target ID
  • Sensor limitations
  • Lack of interoperability among
  • Weapon Systems
  • Sensors
  • C4I

4
Operational mandateand enabling solution
  • Single Integrated Air Picture
  • Combat Identification
  • Integrated Fire Control
  • Automated Battle Management Aids
  • Attack Operations
  • Passive Defense / Early Warning

5
Required Joint Tactical BMC2
Joint Tactical BMC2 domain
Displays
Joint Tactical BMC2
Weapons
Sensors
Systemspecific Tactical BMC2
USMC
Army
Communication Network (and Enterprise Services)
Service Combat and Command and Control System
Program Managers domain
Air Force
Navy
Common functionality, implemented and maintained
commonly
6
Integrated Architecture
  • Reduce development costs and time to field new
    capability and increase operational effectiveness
  • Integrated Architecture Behavior Model (IABM)
    unambiguously describes system behavior and
    supports dynamic analysis
  • Model Driven Architecture (MDA) approach focuses
    on functionality and improves communications with
    Industry

Paper Standard(s) and Specification(s)
Integrated Architecture Behavior
Model (Platform Independent Model)
IA Repository
  • Unambiguous
  • Described in context
  • Dynamic
  • Syntax and semantics
  • Strong typing
  • Gaps, overlaps, and conflicts
  • Context-free
  • Static
  • Syntax

7
SIAP Peer Functional Architecture
Peer Computer Program
Time Position Source(s)
  • Joint C2 Applications
  • Situation Threat assessment
  • External C2 display
  • Engagement Support
  • Engagement control status tracking
  • Planning/MS
  • Dynamic deconfliction
  • Alert generation
  • Doctrine Management
  • Tactical Information Management
  • Mission Planning/Execution/Control/Eval
  • Training
  • Track Management
  • Measurement processing
  • Sensor registration
  • Multi-Sensor data association
  • Multi-Sensor data alignment
  • Track processing
  • Correlation/Decorrelation
  • Track Database/User Services
  • Distributed Combat ID
  • Track overlays
  • Intel data integration
  • Distributed Resource Mgmt
  • Sensor/Weapon Resource Status
  • Sensor selection tasking
  • Weapon selection tasking
  • COA Development/Support
  • Distributed Readiness Assessment
  • Distributed Environmental Assessment
  • Health, Status, Configuration Capability
  • Common Services
  • Time services
  • Nav/Position services
  • Math utilities
  • Data recording I/F
  • Track numbering service
  • Map Database services
  • System Mode/State/
  • Status Control
  • Network Management
  • Net-Centric
  • Enterprise
  • Services
  • Enterprise Service
  • Management
  • Messaging
  • Application
  • Discovery
  • Mediation
  • Collaboration
  • Storage
  • Information Assurance /
  • Security
  • User Assistance

.
Data Dissemination Manager (Application I/F)
Channel Manager
  • Sensor
  • Measurement
  • Switch
  • I/F to I/F
  • Information
  • Priority
  • Manager

.
  • Distribution
  • Manager
  • Discovery Svcs (internal)
  • Data Distribution (internal)
  • Bridge
  • Router
  • Link 16
  • IPv6

Data Dissemination Manager (Info I/F)
Communications I/F
Sensor I/F
Weapon I/F
System Service - specific C2 I/F
.

System Service - specific C2 (including
displays)
Comms Terminals (Link/IP)
Sensors
Weapons
DX/DR
Initialization and Test Console
Version 4.0_030926
Note Configuration 05 functions shown in BOLD
BLUE.
8
IABM Test Strategy
Operational Evaluation
Hardware-in-the-Loop
Digital Simulation
Time
9
JDEP Technical Framework
IBuild is an instantiation of JDEP Technical
Framework
10
Conformance Testing and Operational Assessment
  • Objective Demonstrate distributed system
    capability in an operationally representative
    scenario
  • Approach Integrate test BMC2 components with
    IBuild
  • JSSEO-JITC MOA in progress
  • Conformance testing against MIL-STD
    6016B for IABM
  • Coordination with operational testing community
  • Test for Success

JDEP Technical Framework is a key enabler
11
Lessons Learned
12
Current and Past HWIL Tests
  • E-2C HWIL Pilot Analysis
  • PATRIOT HWIL Pilot Analysis
  • AEGIS HWIL Pilot Analysis
  • Combined HWIL Analysis

13
Data Registration Experiment
Link 16 Utility Player
SPAWAR GTE
SPAWAR GTE
Link 16 Network
J3.2 Msgs Remote Tracks (TQ 14, ID UNK EVAL)
Geodetic And Sensor Biases
Uncorrelated
Correlated
Nav
Mission Computer (Corr/Decorr Functions)
Tracks
IFF
Radar
Sensor Reports
Time
Hypothesis The introduction of geodetic and
sensor biases has a measurable effect on the
HWILs ability to perform data registration
functions to correlate its local tracks with
remote tracks received through Link 16 network.
14
Lessons Learned Process
FEDEP Process
15
Tracing Specific Lessons Design the Federation
Federation Object Model
  • JDEP Reference FOM provided initial starting
    point
  • Contains ground truth in the realtime HWIL
    federation
  • FOMs evolved with each event with careful
    consideration of the impact of changes to working
    federates and on performance of the federation
  • Iteration on FOMs was done with small focused
    group under leadership of one responsible
    individual
  • FOM development process became more structured
    with each event
  • IBuild started with SIAP FOM
  • Added sensor reports, tactical datalinks,
    navigation system data and environmental
    representation

16
Tracing Specific Lessons Design the Federation
Federation Agreements
  • Formal federation agreements vital for managing
    federation design decisions
  • Evolved from event to event becoming more formal
    with each event
  • Needs to continue to evolve to include not only
    HLA components but other components of the
    federation
  • IBuild Federation agreements are based on the
    agreements developed for the events

17
Tracing Specific Lessons Design the Federation
Federation Agreements Examples
  • Realtime federations
  • External Data Representation (XDR) standard used
    for data marshalling
  • GPS timecards used to synchronize the simulated
    and HWIL processes no HLA time management
    services are employed
  • Data Distribution Management (DDM) was
    implemented for the first time in the combined
    event to reduce latency
  • IBuild
  • External Data Representation (XDR) standard used
    for data marshalling
  • Time managed federation
  • DDM used to segment data corresponding to the
    systems co-located on each platform.

18
Tracing Specific Lessons Develop the Federation
Federate Development
  • Federate development time varied with each event
  • HLA experience greatly facilitated federate
    development
  • In cases where limited HLA expertise but HLA
    training was embraced, development hurdles were
    mitigated
  • Made use of DIS/HLA translators where feasible
  • IBuild incorporates the model engine which
    supports rapid model integration by providing a
    simplified HLA interface
  • GUI, auto code generator and a flexible FOM
    interface
  • TPS 59 model, environment model, and
    communication server provide examples of rapid
    model development

19
Tracing Specific Lessons Plan, Integrate and
Test Federation
Verification and Validation
  • Multiple levels of VV are conducted
  • Federate developers are responsible for
    standalone federate VV
  • Conducted prior to integration
  • May be conducted as part of the federate
    selection
  • Redone during integration in the context of the
    federation
  • Analysis team and federation manager work
    together to VV the federation during the
    integration
  • Objective group reviews the VV plans and reports
    prior to the
  • VV uncovered significant issues with federation
  • VV process matured with each event

20
JSSEO V VA Process
No
No
Yes
Recommendations for Improving MS (in Test
Report)
No
Yes
Phase 2 Planning
Yes
Phase 3 VV Execution
SAT ESG approves/ Disapproves VV Plan
(becomes Test Plan Appendix)
MSD writes VV Report (added to Test Plan
Appendix
VVA Activity Team and SAT ESG review
VV Results makes Recommendation To AA
Phase 4 Accredidation
MSD writes final Test Report
AA Accreditation Authority MSD MS Developer

21
Leave Behinds
  • Demonstrated significant re-use from computer
    programs to processes
  • FEDEP, Conceptual analysis
  • FOM
  • Common Reference Scenario, CRSD
  • VV process
  • Analysis tools such as PET

22
Conclusions
  • Working towards a vision where the JDEP Technical
    Framework provides the necessary test environment
  • Demonstrated significant re-use , although
    challenges remain
  • Continue to add sophistication with each
    subsequent event
  • DDM to address performance issues
  • Introduction of automated tools for CM and
    integration testing
Write a Comment
User Comments (0)
About PowerShow.com