Eric Watz Lumir Research Institute, Inc

 Introduction (what is this?)  History of DDCA (how we got here)  DDCA PDG (who we are now) ◦ Status ◦ Objectives

 What is DDCA? ◦ Distributed Debrief Control Architecture  PDG Mission: Develop an interoperable architecture for distributed debrief that will enhance existing debrief capabilities while reducing integration and operating costs

 Problem Concept ◦ Exercise replay is a common element of training and debriefing systems.  Many proprietary implementations exist, often with unique capabilities tailored to their program ◦ Problems arise when integrated into larger, distributed debriefings ◦ Lack of an interoperable standard for distributed debriefings

 DDCP Study Group ◦ SISO formed DDCP Study Group at 2007 Fall SIW ◦ Final Report released 2010 Spring SIW  SISO-REF

 Several SISO workshops (2007 – 2008) ◦ Mak Technologies ◦ Boeing ◦ SRI ◦ U.S. Navy ◦ U.S. Air Force ◦ NLR ◦ QinetiQ ◦ Other international participants

 Review current activities (gov’t, industry) to identify potential stakeholders to support a standard.  Survey benefactors, integrators, implementers to establish need (or not!) for new standard.  Evaluate ongoing activities to identify requirements for new standard.  Evaluate methods to establish compliance to new standard.

Time Synchronization View Synchronization Scalable Compatibility VCR-Type Controls Annotation Tools Display of Tactical Areas Remote Bookmarks Remote Participant Status Use of Existing Protocols Transfer Replay Control Extension and Experimentation

 Purpose: manage a common timeline for exercise replay  Discussion of options: ◦ Internal (supplied by standard) ◦ External (supplied by NTP and/or GPS hardware)  Results ◦ 75% favor external implementation ◦ 50% favor internal implementation

 Purpose: maintain a synchronized “point of view” across distributed debrief participants  Discussion of options: ◦ 2-dimensional (2D) or 3-dimensional (3D)?  Results ◦ 75% support for 2D sync ◦ 87% support for 3D sync ◦ 62% support for both 2D, 3D sync

 Purpose: Define how DDCP data is transported  Discussion of options: ◦ Create a new, unique application protocol  Cons: Time consuming, security concerns, accreditation can be time consuming  Pros: Complete control over DDCP protocol, DDCP packets not processed by non-DDCP simulations

 Discussion of options (cont): ◦ Route DDCP data within established protocol  Pros: HLA, DIS, TENA are established TCP/IP protocols; encourages interoperability; existing security approval  Cons: requires revision of existing protocol standard; non-DDCP devices require DDCP support; choice of a protocol would leave out other protocol users  necessitates gateways  Results ◦ Community interest in using either approach ◦ Desired: play nice with existing architectures ◦ No conclusive results from SG

 Purpose: control the playback of a simulation using standard commands  Discussion of options: ◦ 4 commands identified: Play, Pause, FF, REW  Results ◦ Key element for the new standard ◦ PDG to determine any additional commands req’d

 Purpose: annotate a playback of a simulation event  Discussion of options: ◦ Pen, text box, shapes, import annotations file ◦ Not all viewers have annotation requirements  Results ◦ There exists a desire to use/include annotation tools in the standard ◦ PDG tasks: determine annotation requirements, design them into the standard

 Purpose: presentation of planning and intelligence data as a main display overlay  Discussion of options: ◦ Limited discussion on this topic, possible lack of understanding of topic ◦ Develop support in phases  Results ◦ 88% favorable to displaying tactical areas

 Purpose: facilitate marking of specific contexts and events during an exercise, for the purpose of quickly revisiting during AAR  Discussion of options: ◦ How to convey the “context” of a bookmark? ◦ Do we force remote viewers to update to a bookmark? ◦ Need to convert local into remote bookmarks  Results ◦ 50% favorable to remote bookmarking ◦ PDG to solicit community inputs to clarify usage/benefits of this feature

 Purpose: indicate status of remote participants  Discussion of options: ◦ Separate window for names of participants? ◦ Select / view participants for chat  Results ◦ 88% favorable to remote participant status

 Purpose: support varying levels of capability  Discussion of options: ◦ Don’t want to force features on those who do not need them ◦ Some tools may not support the full DDCP features set ◦ Basic set of capabilities required for all, levels of advanced capability as needs increase  Results ◦ 60% favor scalable compatibility; additional support gained in follow-on discussions ◦ PDG to determine base requirements

 Purpose: assign control of a distributed debrief  Discussion of options: ◦ Informal (P2P) with manual coordination ◦ Formal transfer of control built into the protocol  Results ◦ 88% favorable to transfer of replay control

 Purpose: support extensibility and perform experimentation within distributed debrief context  Discussion of options: ◦ Required as training requirements and/or doctrine changes  Results ◦ 75% favorable to extensibility & experimentation

 Membership by Organization (prior to Euro SIW): ◦ AFRL 711 HPW ◦ Boeing ◦ Lumir Research Institute ◦ CAE  Kickoff meeting at 2011 Spring SIW

 The DDCA shall consist of an object model that defines: ◦ Messages ◦ States ◦ Behaviors  Interoperability between different implementations shall be enabled through consistent use of these messages, states and behaviors.  Guidance documents will be created to describe recommended practices for specific simulation protocols.

 DDCA is an architecture, NOT a protocol ◦ Object model approach ◦ Maximize adoption of the standard ◦ Allows for adoption by any protocol, separate annexes ◦ DDCA messages should adhere to protocol rules  Components represent the first set of requirements needed to enable other ideas for distributed debriefing

Time Synchronization View Synchronization Scalable Compatibility VCR-Type Controls Annotation Tools Display of Tactical Areas Remote Bookmarks Remote Participant Status Transfer Replay Control Extension and Experimentation

Time Synchronization View Synchronization Scalable Compatibility VCR-Type Controls Annotation Tools Display of Tactical Areas Remote Bookmarks Remote Participant Status Transfer Replay Control Extension and Experimentation

 Follow up on recommendations from SG ◦ Core features for basic interoperability identified ◦ Identify advanced features (Tier2, Tier3, …)  Looking for inputs from M&S community ◦ Please consider joining the PDG

Time Sync Architecture

 Time Sync ◦ NTP time server as consistent means to represent time. ◦ Other considerations?  Control ◦ Should we allow opt- in / opt-out feature? ◦ This would enable / disable DDCA synchronization. ◦ Other considerations?

 SISO DDCA PDG site: ◦  SISO Discussion Forum: DDCA PDG