daapr the dapper way to debrief together
play

DAAPR: The Dapper Way to Debrief Together Alexander Streit 1 1 - PDF document

IT 2 EC 2020 IT 2 EC Extended Abstract Template Presentation/Panel DAAPR: The Dapper Way to Debrief Together Alexander Streit 1 1 Director of Advanced Technologies, PLEXSYS Interface Products, Orlando, USA Abstract Simulation events are


  1. IT 2 EC 2020 IT 2 EC Extended Abstract Template Presentation/Panel DAAPR: The Dapper Way to Debrief Together Alexander Streit 1 1 Director of Advanced Technologies, PLEXSYS Interface Products, Orlando, USA Abstract — Simulation events are increasingly taking place across multiple platforms, sites, and organisations. The Distributed Debrief Control Architecture (DDCA) is the industry standard for distributed debriefing. However, it has a number of issues. We describe the issues and their workarounds in the paper. We have designed Distributed After Action Playback and Review (DAAPR) as a fault-tolerant, easy to implement, and extensible alternative to DDCA. We have produced a prototype implementation and conducted numerous experiments. This paper presents observations and results from our experience developing and testing DAAPR. We invite others to join in implementing and standardising DAAPR for global simulation use. 1 Introduction - Transfer of replay control is a required feature that is not part of the specification. The UK Land Forces are designing their training - Playback speeds are specified using Integers. system to enable a “Train, Reflect, Learn, and Train Again (TRLTA)” cycle [1]. Debriefing is a critical part of this 1.2 DDCA Benefits cycle by allowing participants in an exercise to reflect on what occurred, so as to learn from it. Simulation exercises There are several aspects of the DDCA design that are are increasingly taking part across multiple sites and across useful in distributed and interconnected use cases. These different training systems. This poses a challenge when include: debriefing sessions, as the tools available between systems - Zulu timestamping of message generation time vary and often do not coordinate with one another. This is enables dead-reckoning and provides a helpful a simulation and training challenge for commercial and sanity check. defence users alike. - The use of 64-bit milliseconds from Epoch at Zulu One solution is the Distributed Debrief Control time is an appropriate mechanism for time Architecture (DDCA), an architecture for coordinating a exchange. A 64-bit signed Integer provides an distributed debrief [2]. DDCA does not specify a network almost 585 million year time range with specificity protocol and messages can be transported inside to the millisecond. Distributed Interactive Simulation (DIS), High-Level - The SYNC message includes enough information Architecture (HLA), or Test and Training Enabling for a client to establish the correct playback point Architecture (TENA) envelopes. The Boeing Company and speed in the presence of lag through dead and others developed DDCA with inspiration drawn from reckoning. Distributed Debrief Control Protocol (DDCP), an earlier - DDCA is an architecture and can be embedded protocol defined by Boeing [3]. DDCP has been adapted inside another protocol, such as DIS or HLA. to work on the US Air Force’s Combat Air Force Distributed Mission Operations Network (CAF DMON) 2 Approach [4]. We initially pursued DDCA to solve our needs to Our initial approach was to adapt DDCA to our needs. debrief across heterogeneous environments. However, we This included the following workarounds: encountered several issues, which we describe below. - Response to LIST commands with a single infinite recording with no description, to maintain privacy controls. 1.1 Issues with DDCA - Ignore LOAD commands, as the data file would There are several issues with the DDCA specification: always be the single infinite file. The work-around - Network instability has a strongly adverse effect on is to perform on-demand loading of data files using the ability to conduct a debriefing. For example, the playback time from commands such as SEEK or dropped packets can cause the master application to SYNC. wait on response messages to seek requests before - Ignore ACKNOWLEDGE messages, allowing state transitioning to a play state. to transition directly between PAUSE, SYNC, and - Excess (non-critical) information is transferred, SEEK. Devices would be responsible for catching making it problematic for sensitive environments or up using dead-reckoning. This reduces the effect of where multiple levels of security are involved. network lag and instability.

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend