Single Integrated Air Picture E2C HWIL Federationa JDEP Pilot

1
Single Integrated Air Picture E-2C HWIL
Federationa JDEP Pilot

• Jayne Talbot
• Virtual Technologies Corporation
• Mary Rock
• Veridian Engineering

2
Outline

• SIAP-SE Mission
• Analysis Approach
• HWIL Federation Overview
• Federation Development Process
• Observations and Lessons Learned
• Next Steps

3
SIAP-Systems Engineer Mission

• Increase warfighting performance by ensuring that
  all participating systems produce and maintain a
  single integrated air picture (SIAP)
• Analysis supports fielded system assessment,
  Block I upgrades to Link 16, and eventually new
  system development assessments
• Identified 12 critical issue areas that effect
  SIAP and need resolution.
• time synchronization, data registration, track
  quality and management, PPLI issues, database
  consistency, IFF, Combat ID

4
Analysis Approach

• Relies on a variety of methods and data sources
  including live test events, hardware/software/
  operator-in-the-loop (HWIL/SWIL/OITL) events, and
  digital models and simulations analyses
• Makes use of a standard set of performance
  attributes, metrics and data analysis tools, a
  common reference scenario (CRS) and the
  application of a standard technical framework,
  the Joint Distributed Engineering Plant (JDEP)
• Federation of firsts

5
So Just What is JDEP?

• Technical support team (JITC/contractor support)
• To assist developers, testers, and warfighters to
  create federations of systems to support systems
  integration and interoperability throughout the
  development and deployments process
• An open standards-based process and runtime
  framework
• Structured process for creating federations to
  address specific user requirements based on IEEE
  Federation Development and Execution Process
• Standards profile for runtime environment based
  on IEEE 1516 (HLA)
• Growing set of reusable capabilities to support
  federations
• Network nodes,software and hardware, knowledge
  base on available systems representations and
  supporting simulations
• Business model based on combination of core and
  user funding
• JDEP core supports up front first order
  federation planning, common tools, and technical
  support
• User drives event content and supports cost of
  conduct

6
Time Synchronization and Data Registration
Analyses

• In the near term, SIAP-SE is characterizing each
  participating system to determine their response
  to and affect on the SIAP through Link 16
• Effects on the participating systems (E-2C)
  ability to perform data registration and maintain
  time synchronization by systematically inserting
  geodetic positional biases, local sensor biases,
  and time biases and measuring its ability to
  correlate its local tracks with perfect remote
  tracks

Radar/IFF Simulation System (RISS)
Radar video and trigger Antenna synchro
Antenna azimuth Target data Control
msgs Simulated CP-gtDP msgs
Radar Rpts
Target data (TDIP) E-2C Position IFF
Response Control and Status data
Tactical System Interface Unit (TSIU)
E-2C Tactical Driver (E2CTD)
E-2C HLA GW
Radar Rpts IFF Rpts Nav Rpts GPS Time
Nav Rpts Radar Rpts Nav Rpts GPS Time
Target Position Target IFF Sim Management E2C
position and IFF Mode Codes
Mission Computer and Display System (MC/ACIS)
E-2C GTE
1553/J-Messages
DX
DX
HLA
Control and Status data
7
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
E2Cs ability to perform data registration
functions to correlate its local tracks with
perfect tracks received through Link 16 network.
8
Time Synchronization Experiment
Link 16 Utility Player
SPAWAR GTE
SPAWAR GTE
Link 16 Network
J3.2 Msgs Remote Tracks (TQ 14, ID UNK EVAL)
Time Bias
Uncorrelated
Correlated
Nav
Mission Computer (Corr/Decorr Functions)
Tracks
IFF
Radar
Sensor Reports
Time
Hypothesis Because JTIDS J3.2 messages do not
employ time stamps, the delta in time both
positive and negative will make no difference in
the ability of the E2C to correlate tracks.
Time
9
Federation Overview
Scenario Driver (CRS)
Utilities 1 Test Control 2 Data
Logger 3/4 2D/3D Viewers
E-2C HWIL
Utility Player
IFF Response Server
SPAWAR Link16 GTE
1
2
3
4
Sim Stim (RISS)
RTI

• Subscribe to attributes for
• Federation Management
• Data Logging
• Viewing

Publishes attributes of all platforms Publishes
E-2C initial location and flight path
Subscribes to blue platform updates Publishes
IFF mode codes
Subscribes to position updates Sends
perfect PPLI track messages via the
GTE
Subscribes to position and IFF updates, E-2C
initialization info Send and receives PPLI
track messages via the GTE
10
Federation Development Process

• Large group looking for guidance
• Objectives that required refinement

11
Federation Development Process

• Targeted expertise towards the rights steps
• Promoted refinement of objectives and sort out
  fidelity requirements

12
Federation Development Process
Depict User Problem Space
13
Level 1 Depiction
Thread 1 of 3 sharing of remote tracks on
Link 16
14
Level 2 Depiction Sequence Diagram
Thread 1 of 3 sharing of remote tracks on
Link 16
15
Level 2 Depiction Data Exchange Requirements
Thread 1 of 3 sharing of remote tracks on
Link 16
16
Level 2 Depiction Mapping Sequence and Data
Exchange to logical processes
17
Federation System Engineering

• With understanding of detailed objectives,
  federation developer worked with E-2C HWIL, CRSD,
  IFF Response Server and Utility Player developers
  to
• Develop FOM using the JDEP reference FOM
• Chose federates to be used, modified or developed
• Put initial federation agreements in place

18
Reference FOM at the time of E-2C event
Other experiences i.e., JVB, JSB, Sweden
Other experiences
Other experiences
SISE Reference FOM 1.0 (aka JDEP Reference
FOM) December 2002
SISE/CISE Reference FOM August 2002
SISE Reference FOM 2.0 December 2003
SIAP E-2C Digital FOM September 2002
SIAP Patriot Digital FOM September 2002
SIAP Infrastructure Build FOM March 2003
SIAP Aegis FOM April 2003
Reference FOM Derived FOM Planned
FOMs Derive Feedback
SIAP Joint Event FOM August 2003
19
Federation Development, Execution and Analysis

• Federates were developed
• Integration completed where VV was a focus
  during the integration event
• E-2C VVd prior to integration revalidated
  during integration period
• One week Dry Run for federation data collection
  and analysis was conducted prior to test
• Test and data collection took 3 weeks

20
Data Collection to Support VV
SPAWAR Gateways
UP GTE
E2C GTE
Position (ECI), Time Position (ECR), Time,
(HLA) IFF Response, (HLA) Position (ECR), Time,
(TDIP) Position (ECR), Time, (DIS) JTIDS
TIMs/TOMs (1553) JTIDS Messages (SIMPLE)
Time, Geodetic And Sensor Biases
Tactical Data Collection Points Network Data
Collection Points
PET Input
MC
Utility Player (DLS)
MC RISS TD
CRS
IFF Mode Codes
PET Input
Scenario Server CRSD
IFF Response Server
HLA/DIS Converter
hlaResults
E2C Gateway
PET Input
21
Observations and Lessons Learned

• FEDEP
• Structure was added to early steps of FEDEP
• To gain necessary detail to develop federation
• To focus expertise toward most appropriate steps
• JDEP reference FOM was used successfully and
  experience drove evolution of reference FOM
• FOM refinement/development process needed
  maturation
• FOM description and detailed federation
  agreements need to be captured in formal
  document, ICD

22
Observations and Lessons Learned

• Federation Implementation
• Time synchronization using combination of Network
  Time Protocol (NTP) and Global Positioning System
  (GPS) time cards was successful
• Driven by HWIL requirements
• eXternal Data Representation (XDR) standard
  provided excellent method to insure
  interoperability of messages across platforms
• Piece-wise integration was effective approach but
  considerable development was conducted during
  integration that affected timeliness
• Significant VV of the CRS, CRSD, IFF server was
  accomplished during integration that need not be
  repeated in future

23
Observations and Lessons Learned

• Common Tools
• SPAWAR Gateway Terminal Emulator (GTE) issues
  discovered during integration that prevented the
  DR testing from being done. Fall back testing
  without DR proved to be valuable and necessary to
  understanding DR implementation.
• Utility Player concept worked successfully with
  noted, resolvable issues
• CRS met analysis needs with improvements
  identified for future
• CRSD fulfilled needs but key to federation
  performance performance enhancements planned

24
Summary

• Even as a pilot event, valuable data was
  collected on E-2Cs contribution to SIAP
• Time synchronization debate was resolvedtime
  bias does not affect SIAP or E-2C
• Additional testing required to fully characterize
  E-2C with DR working however, testing
  characterized correlation/decorrelation affects
  with biases which constitutes significant number
  of fielded E-2C systems
• Federation approach was viable in analyzing SIAP
  critical issues
• Reuse planned for tools and processes
• Utility Player, CRSD, hlaResults, Test Control
  Federate
• FEDEP process, FOM, federation agreements
• CRS, Attributes, metrics

25
Next Steps

• SIAP-SE continues to characterize participating
  Link 16 systems to determine how to improve them
• SIAP-SE has embarked on second federation to
  characterize the Armys Patriot system in the
  same way with the same CRS, same attributes, same
  FOM
• Planning is underway to do the same for the
  Navys Aegis system in late FY03
• Planning is also underway to conduct an analysis
  with E-2C, Patriot and Aegis in early FY04
• SIAP-SE is also developing a mission computer
  reference implementation and supporting digital
  environment to support system development goals

26
Backup Slides
27
SIAP JDEP Strategy Depicted
Hardware-In-The-Loop Representations
SIAP Producing Systems
AWACS AEGIS AN/TPS-75
F15-E CRC
Environment for Sensitivity and Root Cause
Analysis
Digital (Simulated) Representations
JDEP leave behind capabilities Scenario
server Federation utilities System
representations Network nodes Event planning
processes Plan and report templates
Environment for Validation of Upgrades and
Architecture

28
Backup SlidesFederation Agreements

• RTI1.3NGv6 was used. Standard RTI Initialization
  Data (RID) file was used.
• The coordinate system is WGS-84. Positional
  updates for the aircrafts were published in an
  Earth Centered Earth Fixed (ECEF) format
• All attributes for the Platform class must be
  updated at the same time so that the timestamp
  value is valid for all the updates. For example,
  one can not update velocity in one time step and
  then orientation in the next. All must be
  updated each time step.
• Time Representation
• Each object class and interaction class has an
  attribute/parameter named TimeStamp that will
  carry the value that corresponds with the time
  the object update or interaction values are
  valid. Each simulation must provide the
  TimeStamp value with each object update and each
  interaction that is sent.
• TimeStamp is represented as a long (32 bit
  integral value). Units for TimeStamp are
  milliseconds.
• Epoch is Midnight of the previous day so that the
  starting value of 0 refers to first millisecond
  of the current day.
• Each federate must use the received time value
  with each reflected object and received
  interaction for processing of the state as
  appropriate. This includes the need to perform
  dead-reckoning on values where calculation of
  physical interactions between entities and/or the
  environment is appropriate.
• Time Synchonization
• The ESTEL facility will employ Network Time
  Protocol (NTP) to synchronize the system clocks
  of each machine or where timing is critical
  timecard with validated time sources will be
  used.
• Radar Cross-section data will be simulated using
  lookup tables implemented in E-2C radar model.
• Initial conditions for E-2C position will be
  published by the driver in an interaction.
• Management of the federation such as federation
  start and stop were implemented with a set of
  interactions in the FOM.
• Data Marshalling
• All FOM data elements will be encoded using
  eXternal Data Representation (XDR) standard prior
  to being sent to the federation and must decode
  the XDR represented data elements prior to
  processing their values.

29
ESTEL Simulation Suite Data Flow
30
ESTEL Internal Network Supporting SIAP E-2C HWIL
JDEP Pilot
TSIU
Mission Computer (MC) SN TCV00004
200.0.0.1
192.168.0.22
E-2C RISS TD NTP
HLA GW IRIG (TCF)
RISS IFF
192.168.0.21
RISS Radar
192.168.0.20
192.168.0.23
ACIS 1 SN 002
192.168.0.02
200.0.0.12
192.168.0.24
SPAWAR E-2C GTE IRIG
192.168.0.100
GPS Time Server
ESTE LAN B HUB SN 140000506
192.168.0.200
ACIS 2 SN 744
SPAWAR UP GTE IRIG
200.0.0.13
Common Tools PC CRS-D (IRIG) IFF Server
(NTP) hlaResults (NTP) (2D Viewer 3D
Viewer hlaControl)
192.168.0.101
192.168.0.102
192.168.0.03
192.168.0.104
Utility Player (DLS)
TIAC
192.168.0.103
Ethernet
1553
YAG NTP
Tactical Serial
31
Backup Federation Components
32
E-2C HWIL Federation Data Flows
SPAWAR UP GTE
SPAWAR E-2C GTE
Position (ECI), Time Position (ECR), Time,
(HLA) IFF Response, (HLA) Position (ECR), Time,
(TDIP) Position (ECR), Time, (DIS) JTIDS
TIMs/TOMs (1553) JTIDS Messages (SIMPLE)
Data Collection
MC (HWIL)
Utility Player (DLS)
MC RISS TD
CRS
IFF Mode Codes
DS3
Scenario Server CRSD
IFF Response Server
HLA/DIS Converter
hlaResults
E-2C Gateway
33
For example Data Registration Analyses