MSG039TG027 Briefing

1
NMSG TG-039 Preliminary Analysis of Tactical Data
Link Representation in Extended Air Defense
Simulation Federations

• MSG-039/TG-027 Briefing
• Wim Huiskamp (TNO), Kirsten Kvernsveen (FFI)
• David Taylor (Lockheed Martin), Clive Wood (NC3A)

2
Outline

• Background
• Objective and Status
• Findings
• Way-Ahead

Phase II Planning Demonstration
MSG-039/TG-027
RELEASABLE FOR INTERNET
3
Background to MSG-039

• Threat of Tactical Ballistic Missiles
• Development of TBM Vision by NATO
• Interoperability Is Vital Aspect of EAD
  Architecture
• Command Control Elements
• Tactical and Procedural Co-ordination Between
  Combined and Joint EAD Forces
• Deployment and Contribution of Future Elements
• Simulation Expected to Play an Important Role in
  Analysing Future EAD Architectures

4
Phase I Exploratory Study Research

• Recommend approaches for a distributed simulation
  architecture across NATO that enables analysis of
  EAD C2 interoperability
• Reference FOM
• Process (FEDEP tailoring)
• Assess the feasibility of reusing existing
  simulation elements and testbeds across NATO
  nations in this architecture

5
Phase 2 Planning Demonstration

• Develop FOM Supporting EAD
• RPRFOM as baseline (draft 2 version 12)
• SISO TDL BOM (and other extensions)
• Limited Integration Test (verification)
• Process
• Integration
• Tools
• Publish Final Report and Brief on Results

6
Phase 3 Implementation

• NATO Active Layered Theater Ballistic Missile
  Defense (ALTBMD) Integration Test Bed
• PO set up at NC3A (The Hague/Brussels)
• RFP expected 2nd Quarter 2007

7
Phase 2 Status

• FEDEP Design Document development
• Initial Integration Demonstration
• 6-10 February 2006 at TNO labs (The Hague, The
  Netherlands)
• Final Test Preparations
• June 2006 at TNO labs (The Hague, The
  Netherlands)

8
Operational Context and Command Structure
Assumptions (1 of 2)

• No Higher Echelon Unit
• No R2 Swapping

9
Operational Context and Command Structure
Assumptions (2 of 2)
10
Initial Integration Test Objectives

• Conformance Testing
• Verify message formats
• TDL BOM test capability
• NSCD, Analysis
• Integration Testing
• Verify proper interactions in one-on-one tests
• Interoperability Testing
• Verify proper interactions in complex
  multi-platform environment

NC3A Compliance Tester (OANT)
NC3A Federate Tool
February Demo Objective
Most test objectives were met.
11
Initial Test Setup
12
Notional Network TopologyInitial Integration
Event February 06
HLA Network (RPR-FOM V2 D14 Ext)
TRS GW
HLA/HLA

• SMDC/TUB
• EADSIM

• TRS
• POSEIDON

• NC3A
• SEW
• LSID

• TNO/FFI
• JROADS

• BAE
• HLA Logger

• TNO
• STK
• Viewer

Federates
MTDS
MTDS
HLA
MBDASIMPLE /TDL BOM
NCSD
NCSD
TRS GW
SIMPLE Link-16 Messages
BAE Analysis

• J-Series Messages Encapsulated using
• SIMPLE
• MTDS
• TDL BOM (SISO)
• TDL BOM (Thales)

Database
Post Processor
13
Implementation
14
Network Topology Topics

• Many Gateways
• HLA-HLA Bridge (TRS)
• DLGU-SIMPLE (TRS)
• HLA-DIS (EADSIM)
• SIMPLE-DIS (TRS)
• NACT-SIMPLE (NC3A)
• MTDS-NACT (NC3A)
• Network/federate latencies not measured

15
Initial Test Results

• Succeeded in getting the federation to operate
• Did not examine latency issues necessary for
  future injection of time delays
• Sub-nets
• Engagement coordination task is very important
  for June event
• Need to analyze log data!

Overall a successful event. Integration requires
close cooperation and flexibility and the team
worked together well
16
Tactical Data Link Observations

• Engagement Status Messages
• LRR to RPC Missile Track reporting
• Space track LPP/IPP dissemination via RPC

17
Simulation Architecture Observations

• Entity Type Fields inconsistent
• These agreements have to be made explicitly, but
  also some tools do not have the flexibility  to
  be modified during the test
• Analysis and logging tools can place additional
  requirements on the Federation
• UDP vs. TCP/IP
• see implementation of the SIMPLE router and the
  NATO SIMPLE Compliant Device

18
ACC Command Engagement
19
LRR to RPC
LRR
RPC
HLA
J2.5 PPLI
Needs verification
PhysicalEntity.Munition
J3.6 Space Track (creation)
J3.6 Space Track (update)
J3.6 Space Track (cueing request)
J3.6 Space Track (udpate)
Platform.Aircraft
J3.6 Air Track (creation)
J3.6 Air Track (update)
20
Space Track LPP/IPP
RPC
ACC
HLA
PhysicalEntity.Munition
J3.6 Space Track (creation)
J3.6 Space Track (update)
J7.1 Data Update Request (IPP LPP request)
J3.0 Reference Point (launch point)
J7.7 association (launch point track link)
Not Observed
J3.0 Reference Point (launch point)
J7.7 association (launch point track link)
21
Space Track Update Maintaining R2
RPC
WS
HLA
BM launch
WeaponFire
PhysicalEntity.Munition
J3.6 Space Track (creation)
J3.6 Space Track (update)
Merge 2 tracks
J7.2 Correlation
BM hits ground
J3.6 Space Track (update)
Not Observed
MunitionDetonation
J7.0 Track Management (drop track)
22
Space Track Update Swapping R2
Not Tested
RPC
WS
HLA
LRR
HLA
BM launch
BM launch
WeaponFire
WeaponFire
PhysicalEntity.Munition
PhysicalEntity.Munition
J3.6 Space Track (creation)
J3.6 Space Track (update)
J3.6 Space Track (update)
J3.6 Space Track (update)
BM hits ground
MunitionDetonation
23
Summary

• We were able to run the entire federation!
• Limited data reduction and analysis indicates
• Simulation data exchanged
• Detonation interactions needs investigation
• Question of full exchange of entity data
• Observed the following J-series messages
• J2.5 PPLI
• J3.6 Space Track (creation, update, cueing
  request)
• J7.0 Track Management
• J10.2 Engagement Status (weapon assign,
  interceptor launch, kill assessment)
• J13.5 Platform Status
• Did Not Test
• J9.0 Command (engagement order, acknowledgement)
• J7.1 Data Update Request

24
Observations (1 of 3)

• The simulation architecture was overly complex
• Gateways
• Different interpretations of standards.
• Gateways unavoidable (initially)
• This is due to nature of bringing together many
  (legacy) systems from many companies and many
  countries.
• Data Collection requires standard naming
  conventions
• Standard naming conventions need to be defined
  early and disseminated to participating federates.

25
Observations (2 of 3)

• The integration activity went well in a short
  amount of time
• Helped by the co-location.
• Recommendation that early integration activities
  of new federations are co-located and not
  attempted over distributed networks.
• Recommendation to provide test federate
  files/applications for distributing to individual
  participants prior to integration activities

26
Observations (3 of 3)

• Tine Synchronization is critical.
• Not all systems could see the time server.
• Timestamping 1.3 vs 1516
• Ensure early on in the design of the federation
  that all systems can see a common time server.
• Ensure the FEDEP process is followed through
  properly, a number of issues could have been
  avoided if the preparation was completed.
• i.e more detail is required than is specified in
  the FOM
• Central test manager ensures all individual
  systems are tested in a structured way prior to
  connection to the federation
• A lot of time was spent investigating issues that
  were not actually issues
• Recommendation to ensure progressive integration
  testing process
• During integration periods it is important to
  establish an open and no blame culture to
  ensure problems are resolved efficiently.

27
Objectives for June Final Demonstration

• Implement one or more systems with the TDL BOM,
  to allow comparison against bespoke gateways
• Run experiments to demonstrate that these
  environments allow analysis of complex system of
  systems
• Provide results to TMD PO

28
MSG039 Current Status (Q1 2006)

• Members
• Chairman Wim Huiskamp (TNO, NL),
• Participants FR, NC3A, NL, NO, UK, US, TU
• Liaison NIAG

29
Questions?