Simulation Interoperability Standards Organization (SISO) Standard for: Distributed Debrief Control Architecture (DDCA)

Transcription

1 Simulation Interoperability Standards Organization (SISO) Standard for: Distributed Debrief Control Architecture (DDCA) 0 SISO-STD-XXX-DDCA DRAFT_VERSION Prepared by: 0 Distributed Debrief Control Architecture Product Development Group

2 0 Copyright 0 by the Simulation Interoperability Standards Organization (SISO), Inc. P.O. Box Orlando, FL -, USA All rights reserved. Permission is hereby granted for SISO developing committee participants to reproduce this document for purposes of SISO product development activities only. Prior to submitting this document to another standards development organization for standardization activities, permission must first be obtained from the SISO Standards Activity Committee (SAC). Other entities seeking permission to reproduce this document, in whole or in part, must obtain permission from the SISO Executive Committee (EXCOM). SISO EXCOM P.O. Box Orlando, FL -, USA Copyright 0 SISO. All rights reserved. Page of

3 Revision History Version Section Date Description All //0 NEW //0 //0 All 0//0 Added DDCA state diagram Added UML sequence diagram(s) Reformatted document, cleanup for presentation to SISO. Copyright 0 SISO. All rights reserved. Page of

4 INTRODUCTION.... Purpose.... Scope.... Objectives.... Intended Audiences.... Acknowledgements... 0 REFERENCES.... SISO References:.... Other References:.... Bibliography:... DEFINITIONS... 0 ACRONYMS AND ABBREVIATIONS... 0 DISTRIBUTED DEBRIEF CONTROL ARCHITECTURE (DDCA).... DDCA Concepts.... DDCA Master and Client Roles.... DDCA Capabilities..... Tier Capabilities.... DDCA Transport Mechanism.... DDCA States.... Joining a DDCA event.... Example Playback Sequence... DDCA MESSAGE HEADER.... Unique Identifiers.... Time Windows... Copyright 0 SISO. All rights reserved. Page of

5 0 DDCA MASTER MESSAGES Replay Control Messages Load Close List..... Sync.... Remote Participant Status Messages..... Request Status..... Join..... Leave..... JoinResponse..... LeaveResponse.... Compatibility Level Messages..... DDCACompatibility... 0 DDCA CLIENT MESSAGES.... Error.... Acknowledge.... ListResponse.... StatusResponse.... JoinRequest.... LeaveRequest.... DDCACompatibility.... DDCA-X... Copyright 0 SISO. All rights reserved. Page of

6 LIST OF FIGURES FIGURE TIER CAPABILITIES FIGURE DDCA STATE DIAGRAM FIGURE DDCA PLAYBACK SEQUENCE Copyright 0 SISO. All rights reserved. Page of

7 Introduction The Distributed Debrief Control Architecture is an object model that is designed to specify the states and behaviors required for multiple discrete after action review (AAR) systems to interoperate during a distributed after action review event.. Purpose DDCA is defined as an object model that specifies the messages, states, and behaviors that a simulation tool should adopt during a distributed after action review event. 0. Scope This standard defines the DDCA in terms of an object model, messages, and state definitions. The DDCA standard is expected to grow and evolve over time as new use cases are incorporated into the standard. This standard has roots from The Boeing Company s Distributed Debrief Control Protocol (DDCP) and Combat Air Force Distributed Mission Operation (CAF DMO) s DDCP tailoring. 0. Objectives The primary objective of this standard is develop an interoperable architecture for distributed debrief that will enhance existing debrief capabilities while reducing integration and operating costs. It is imperative for SISO to develop this standard, as the simulation community is already deploying distributive debrief systems.. Intended Audiences The primary audience for this document is the Modeling & Simulation community. Other communities of interest, although not the intended primary audience, are encouraged to leverage the standard military scenario description language described here for use in their domains. 0. Acknowledgements This document was created as a community effort by the Distributed Debrief Control Architecture (DDCA) Product Development Group (PDG). This PDG was chartered by the Simulation Interoperability Standards Organization (SISO) Standards Activity Committee (SAC) in March 00. This document would not have been possible without the hard work and dedicated efforts of the following individuals: Product Development Group Officers Mike Frenchy France (Chair) Copyright 0 SISO. All rights reserved. Page of

8 Randy Pitz (Vice Chair) John Jinkerson (Secretary) Jeff Abbott (SAC TAD) 0 Drafting Group Team Eric Fitty Watz (Editor) John Jinkerson (Co-Editor) Randy Pitz Nick Tallyn Scott Flood Jordan Clare Darrell Howard Copyright 0 SISO. All rights reserved. Page of

9 References. SISO References: Document Number SISO-ADM SISO-ADM SISO-ADM SISO-REF-0-0 Title SISO Policies and Procedures (P&P) SISO Balloted Products Development Process (BPDP) Policy for: The Style and Format of SISO documents DDCA Study Group Final Report. Other References: Document Number XML World Wide Web Consortium (WC) web site Title XML Schema Bibliography: 0 Document Number Title Copyright 0 SISO. All rights reserved. Page of

10 Definitions DDCA Master DDCA Client The DDCA Master has control of the replay session, meaning it is the device or application responsible for issuing commands such as Start, Stop, Play, etc. to any connected Clients. The DDCA Client listens to a DDCA Master device, and executes the commands issued from the Master device. Clients do not control the debrief event. Copyright 0 SISO. All rights reserved. Page 0 of

11 Acronyms and Abbreviations AAR DDCA DDCP DIS DMO EXCOM HLA IEEE OSF TENA UUID After Action Review Distributed Debrief Control Architecture Distributed Debrief Control Protocol Distributed Interactive Simulation Distributed Mission Operations Executive Committee High Level Architecture Institute of Electrical and Electronics Engineers Open Software Foundation Test and Training Enabling Architecture Universally Unique Identifier Copyright 0 SISO. All rights reserved. Page of

12 0 0 0 Distributed Debrief Control Architecture (DDCA). DDCA Concepts DDCA is designed as a system-agnostic state diagram which represents the concept of operations for conducting a distributed debriefing event. DDCA operates on the principle that a single application, known as the DDCA Master, has control of the replay session while one or more Client applications are listening; meaning, the Master application is responsible for sending out commands to all Clients and instructing the Clients in such tasks as: which replay time window to load, exactly where in the replay time window to point, and when to play, stop play, etc.. There can only be a single Master application present in a DDCA event at any one time. Any number of Client applications may join into or leave a DDCA event at any time. Multiple recordings (a.k.a. log files) may be replayed during a single DDCA event. DDCA represents the desired end-states of DDCA clients and Master devices during and throughout a distributed debrief event. The individual Modeling and Simulation (M&S) architectures such as DIS, HLA, and TENA will each contain an implementation of DDCA in accordance with the objects, messages, and data types for that architecture. DDCA is designed as an Object Model, complete with associated state diagrams, in order to: Maximize adoption of the standard Allow for adoption of DDCA using any protocol Illustrate the expected [ required ] behavior of DDCA master and client devices The DDCA shall consist of an object model that defines: Messages used in DDCA States of Master and Client applications Behaviors when transitioning between various states Interoperability between DDCA implementations across the M&S architectures shall be enabled through consistent use of these messages, states and behaviors. Guidance documents will be created to describe the recommended practices for specific simulation protocols such as DIS, HLA and TENA.. DDCA Master and Client Roles Within the DDCA there are two types of messages: Control messages: primarily sent from a Master to one or more Client applications. Request messages: sent from a Client(s) to the Master in response to a Control message. The Distributed Debrief Control Architecture includes two types of applications: Master and Client applications. The role of DDCA Master and Client devices will be explained in detail below. In DDCA, the Master is the main, or controlling, application. The Master is responsible for all control messages sent during a DDCA recording or playback session. There can be only one DDCA Master application in any given DDCA event. Master applications within DDCA: Copyright 0 SISO. All rights reserved. Page of

13 0 Do not respond to Control messages sent from Clients. Responds to Request messages sent from Clients. Sends Control messages to any / all Client applications. A DDCA Client application is a listener for commands from the DDCA Master application. Client applications within DDCA: Do not actively control other Clients Are responsible for processing and executing commands received from the Master application. Responds to Control messages from the Master application. Do not respond to Request messages from other Clients.. DDCA Capabilities.. Tier Capabilities The main features of DDCA are illustrated in Figure. The set of Tier capabilities, as highlighted in blue, are considered to be essential to the core functionality of the Distributed Debrief Control Architecture. The objectives of DDCA Tier are to enable the basic replay control features necessary to control a distributed debrief session. 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 0 Figure Tier Capabilities Copyright 0 SISO. All rights reserved. Page of

14 The DDCA Tier capabilities, shown in as the grayed-out boxes, are future capabilities for the DDCA standard. Tier capabilities will evolve as the standard continues to evolve.... Time Synchronization The critical enabling feature for distributed debrief. This is the capability of managing a common timeline for playback across all distributed systems. 0 The DDCA will rely on external implementations such as NTP servers to provide a means of synchronizing individual system clocks across all participants in an exercise. The ability to precisely synchronize system clocks is paramount to the time synchronization capability of DDCA.... Replay Control Replay control is another critical enabling feature for distributed debrief. This is the ability to control the playback of recorded simulation data using Play, Pause, Fast Forward, and Rewind. DDCA Messages covering this functionality will be discussed later in this document. 0. DDCA Transport Mechanism The DDCA standard does not specify a particular mechanism to be used in the sending and receiving of DDCA messages. Specific implementations of DDCA will be covered in Annexes to the standard. These Annexes shall provide a reference implementation of DDCA for the following simulation and training architectures: DIS, HLA, and TENA. DDCA messages can be transported over any supported protocol. The specific method used to transport and receive a DDCA message is independent of the DDCA Object Model itself; applications may receive and process DDCA messages received by any means. An application that is actively participating in a distributed debrief, and is capable of receiving and processing DDCA messages shall adhere to the desired state after receiving and processing a DDCA message. 0. DDCA States The DDCA state diagram is illustrated at a high level in Figure. Copyright 0 SISO. All rights reserved. Page of

15 0 0 Figure DDCA State Diagram The state diagram shown in Figure illustrates the possible Client application states during a DDCA event. There can be multiple transitions between the Play, Seek, and Pause states. Each of the Play, Seek, and Pause states can also transition to the Stop state.. Joining a DDCA event This section describes how a DDCA Client application joins a DDCA event. Beginning from the Unjoined state, a DDCA Client must transition into the Ready state. This is done by sending a request to join message to the master, and receiving a satisfactory response from the Master device. When a DDCA device joins a DDCA event the device shall transition to the Ready state. From the Ready state, the Client can then transition into the Stop state. Stop is where a mission is loaded but not yet playing. From Stop, the Client can transition into one of the three possible replay states: Play, Seek, or Pause. It is possible for a Client to transition directly from the Stop state into a Seek state; for example, if a recording is opened and the first command is to seek to a point 0 minutes into the recording, a Client would transition from Stop directly into Seek. Likewise it is possible for the Client to transition directly into a Pause state; for example, if a recording is opened and the first command is to Pause, a Client would transition from Stop directly into Pause. Copyright 0 SISO. All rights reserved. Page of

16 0. Example Playback Sequence An example of DDCA playback, illustrated as a UML sequence diagram, is shown in Figure. UML sequence diagrams allow the specification of various runtime scenarios by showing an object s lifeline (as a vertical line) and the messages exchanged with other object(s). In this example, there are two object lifelines: the DDCA Master (named Master Controller in the diagram) and the DDCA Client (/Client in the sequence diagram). The messages exchanged between the Master and Client during a typical playback sequence are illustrated in the order in which they occur. Copyright 0 SISO. All rights reserved. Page of

17 Copyright 0 SISO. All rights reserved. Page of

18 Figure DDCA Playback Sequence The example playback sequence presented in Figure assumes minimal network latency, no lost messages, and no errors. Throughout a DDCA event, the Master application will broadcast regular Sync messages. Sync messages are used to ensure that all clients of the controller are in the same time and state as the controller and each other. As the contents of the Sync message change, they will be noted in the sequence description below. Sync messages sent by the Master application are responded to with an Acknowledge by DDCA Clients that are currently joined to the controller issuing the Sync. A DDCA Master begins the playback sequence with no clients and issues a RequestStatus message to the network. Potential Clients respond with a StatusResponse message indicating their UUID, current state (which should be UNJOINED), and human-readable name. Sync messages at this time indicate the STOP state and a NODATA time. As Clients are not currently joined, no Acknowledge responses are expected. The Master application then issues Join messages to the clients which are to be joined to the playback. The Clients respond with Acknowledge messages. Sync messages still indicate a STOP state and NODATA time. Clients will respond to the Sync messages with Acknowledge messages confirming a READY state. The Master application will then issue a List message, asking all DDCA Clients to respond with a list of available recordings. All Clients shall respond to the List message with ListResponse messages, showing the session ID and session name of each playback file that is available. Once the Master application has chosen the session to play back, the Master issues a Load message. This message identifies to the clients which file to load for playback. Sync messages after the load should now indicate the simulation start time of the playback file, but otherwise not change. Acknowledge responses from the DDCA Client(s) now indicate a STOP state. When the playback is to begin, the Master s Sync messages will change to indicate a PLAY state, the simulation Zulu time, and the playback speed of (real-time). Acknowledge responses from the DDCA Client(s) confirm the PLAY state. As needed for discussion, the Master may issue Sync messages with a speed of 0 (PAUSE), (PLAY), other positive integer value (SEEK [fast-forward]), or negative integer value (SEEK [rewind]). Acknowledge messages from the DDCA Client(s) confirm the PLAY, PAUSE, or SEEK state as indicated. When the playback is finished, the Master application shall issue Sync messages with the state of STOP, the simulation Zulu time at the time of the stop, and a speed of 0. Acknowledge responses from the DDCA Client(s) confirm the STOP state. The Master then issues a Close message, indicating that all connected DDCA Clients may free up any committed resources. The Clients Acknowledge responses now indicate a state of READY. At this point, the Master application may issue Leave messages, informing the Clients that the session has ended. Clients do not issue Acknowledge responses to this message, but instead shall transition to the UNJOINED state. The Master application may now issue List or Load commands to repeat the playback sequence as necessary. DDCA Message Header All DDCA messages will incorporate a common message header with the following information: Copyright 0 SISO. All rights reserved. Page of

19 Sender Address Unsigned - IP address of the sender Originating ID UUID UUID of the sending application 0 Receiver Address Unsigned - IP address of the receiver (could be broadcast address) Message Type Unsigned -bit Enumeration of message types (some protocols/interfaces may require this in order to process) integer Message Size - Length of the message (some protocols/interfaces may require this in order to process) Message ID Unsigned - Time Z Unsigned -. Unique Identifiers Unique (by sender) message id Wall clock Zulu time of message creation, in milliseconds since January 0, 0. Table DDCA Message header DDCA uses UUIDs to uniquely identify the Master and Client applications in a DDCA event. When a Client joins a DDCA event, the Client is assigned a UUID by the Master. For subsequent communications between Master and Client, the Master will refer to the Client using the Client s UUID. A Universally Unique Identifier (UUID) is an identifier standard used in software construction, standardized by the Open Software Foundation (OSF). A UUID is a -octet (-bit) number. In its canonical form, a UUID is represented by hexadecimal digits, displayed in five groups separated by hyphens, in the form ---- for a total of characters ( alphanumeric characters and four hyphens). For example: 0e00-eb-d-a-0000 There are 0,,,0,,,,,0,,,, possible UUIDs ( to the nd power or to the th power), or about. 0. Generating a UUID is supported in nearly all major programming languages along with a number of database systems including MySQL, Oracle, PostgreSQL and SQL Server. 0. Time Windows DDCA will use a Time Window object in the Load command. The Time Window object represents a window of time that is desired for playback. DDCA Clients will be responsible for searching their inventory of recordings, and replaying the recording or log file that corresponds to the time window. starttimez Unsigned - endtimez Unsigned - Zulu time corresponding to the beginning of the playback window. In milliseconds since January 0, 0. Zulu time corresponding to the end of the playback window. In milliseconds since January 0, 0. Table TimeWindow object Copyright 0 SISO. All rights reserved. Page of

20 DDCA Master Messages The following table details messages sent from, and received by, a DDCA Master application. Message Name Load Close List Sync Description Instructs Client(s) to load a recording for replay. Instruct Client(s) to closes the file(s) being replayed. Instructs Client(s) to list all available recordings. Covers Play, Stop, Seek operations. Also acts as a heartbeat. Request Status Join Leave JoinResponse LeaveResponse DDCACompatibility DDCA-X Requests status of objects on the network. Requests that a particular Client or Clients join a DDCA event. Requests that a particular Client or Clients leave a DDCA event. Process a Client s request to join a DDCA event. Process a Client s request to leave a DDCA event. Requests Client(s) to report compatibility level for DDCA interoperability. A generic message structure which supports extensible content Table DDCA Master messages 0 0. Replay Control Messages The following commands are issued by the Master for Replay control... Load The Load command is used to load recordings for playback. Recordings are identified by Session Identifier, which is a universal unique identifier (UUID). The Load command can only occur from the Ready state and enables entry into the Stop state. timewindow TimeWindow A TimeWindow object (see Table ) representing the start and end times for the DDCA event. Table Load message.. Close The Close command closes the files being recorded or played back. The close command also references the UUID for the Session Identifier. The close command can occur from the Stop state and enables DDCA Client(s) to leave the Stop state and enter into the Ready state. No additional fields, outside of the DDCA message header, are defined for the DDCA Close message. Copyright 0 SISO. All rights reserved. Page 0 of

21 .. List The List command requests all recording devices to list their available recordings. See List response description...). The List command can occur from the Ready state and keeps the Client in the Ready state. The List command contains a single parameter, timewindow, which represents the window of time in which the Client application should constrain its search for available recordings. If the Master desires that its Clients return a list of all available recordings, the fields within the timewindow parameter should be set to timewindow TimeWindow A TimeWindow object (see Table ) representing the start and end times for the DDCA event. searchtype Unsigned -bit integer Specifies the search type Table List message The searchtype field indicates what recordings should be searched and returned by the Client. The field must be one of the following values:. All available recordings. a. Client should list all available recordings. Starts at, or later than a. Client should list all recordings that start at, or later than, the starttimez parameter.. Starts at, or earlier than a. Client should list all recordings that start at, or earlier than, the starttimez parameter.. Ends at, or later than a. Client should list all recordings that end at, or later than, then endtimez parameter. Ends at, or earlier than. Inclusive.. Sync a. Client should list all recordings that end at, or earlier than, the endtimez parameter a. Client should list all recordings that start a, or later than the starttimez parameter AND which end at, or earlier than the endtimez parameter. The Sync command enables Play, Stop, Seek, and Record operations by way of an enumerated type variable. Simulation Zulu time and the speed of the sync are also passed with this command. The Sync command allows Client state changes between the Record, Stop, Play, Pause, and Seek states. Copyright 0 SISO. All rights reserved. Page of

22 0 0 Purpose - Purpose of the sync operation Sim Time Z - Simulation Zulu time of the sync operation Speed - The requested playback speed Table List message. Remote Participant Status Messages The following commands are issued by the Master for additional Client control... Request Status Request Status enables the Master to request the status of Clients. The Request Status command may occur in any state, and enables no state transitions. Client applications that receive a Request Status message should respond to the message sender with their current status. Master ID UUID Unique identifier of the Master Table RequestStatus message.. Join Join enables the Master to request a Client to join a DDCA event by referencing its ClientID. A Client that accepts a Join command transitions from the Unjoined state to the Ready state. Client ID UUID Unique identifier of the participant Table Join message.. Leave Leave enables the Master to request a Client to leave the exercise by referencing its Client ID. Upon receipt of a Leave command, a Client transitions to the Unjoined state. Client ID UUID Unique identifier of the participant Table Leave message.. JoinResponse The JoinResponse command is issued by the Master, in response to the Master receiving a Join request from a Client. Master ID UUID Unique identifier of the Master Response - Enumerated join status response Name Length Unsigned - Length of character array for Client Name Copyright 0 SISO. All rights reserved. Page of

23 0 Client Name Character Participant s name array Client ID UUID Unique identifier issued to the participant.. LeaveResponse Table 0 JoinResponse message The Leave response command is issued by the Master, in response to the Master receiving a Leave request from a Client. Master ID UUID Unique identifier of the Master Response - Enumerated leave status response Client ID UUID Unique identifier issued to the participant. Compatibility Level Messages Table LeaveResponse message The following messages are issued by the Master to enable scalable compatibility... DDCACompatibility The DDCACompatibility message is issued by the Master to request a Client to report its compatibility level for DDCA interoperability. Compatibility Level - Enumerated value representing DDCA compatibility level Table DDCACompatibility message DDCA Client Messages The following table details messages sent from, and received by, a DDCA Client application. Message Name Error Acknowledge ListResponse StatusResponse Description Sent anytime a Client experiences an error condition Sent in response to a number of messages from the DDCA Master Lists the Client s available recording sessions Indicates the Client s current Status JoinRequest Request to join a DDCA event LeaveRequest DDCACompatibility Response Request to leave a DDCA event Indicates the Client s DDCA compatibility level Copyright 0 SISO. All rights reserved. Page of

24 DDCA-X. Error SISO-STD-XXX-DDCA A generic message structure which supports extensible content Table Client messages 0 The Error message is sent anytime a Client experiences an error condition. Information in this message includes error code, error level, and a description of the error. ErrorCode Unsigned - ErrorLevel Unsigned -bit integer DataLength Unsigned - ErrorData Character array Client-defined error code Level of error. See Table for error descriptions. Length of error data Description of the error condition Table Error message DDCA shall support error levels as described in Table. Client applications are encouraged to use best practices when determining the appropriate error level for a given message; i.e., avoid using Critical or Error level for engineering-level debugging messages. Error Level Value Description Verbose May contain any content. Information Contains useful information when the system is functioning normally. Warning Indicates something is wrong, and the system is able to continue functioning in a normal or degraded state. Error Indicates something is wrong, and the system requires technical assistance to resolve the issue. The system is unable to continue. Table Error levels. Acknowledge Many of the messages sent by the Master are acknowledged by the Client. Examples include: Sync, Join, Leave, Close, and Load. The components of an Acknowledge message sent by the client include the message ID being responded to (message ID) and the client s current state (CurrentState). 0 Message ID - Unique identifier of the Client application (as assigned by the Master) Current State - Current state (see Table for state descriptions). ListResponse Table Acknowledge message This message is sent when a participant has received the List message from the DDCA master. Upon receipt of this message, the participant shall send their list of all available sessions to the master. Copyright 0 SISO. All rights reserved. Page of

25 0 Number of UUID Unique identifier of the Client application (as assigned by the Sessions Master) Session Data variable The fields below are repeated for Number of Sessions id UUID Unique identifier of the Client session starttime - Session start time in GMT seconds endtime - Session end time in GMT seconds namelength Unsigned - sessionname Character array. StatusResponse Length of the sessionname field in bytes Name of the Client session Table ListResponse message This message is sent when a Client is reporting its status to the DDCA Master. If in the Unjoined state, the Client will respond to any Status Request command received. If in any other state, the Client will respond only to Status Request commands from the Master it is joined to. A StatusResponse message may be issued in any state, and results in no state transitions. ClientID UUID Unique identifier of the Client application (as assigned by the Master) CurrentState Unsigned - Current state (see Table for state descriptions) SupportedStates Unsigned - Bit-masked value indicating states supported by the Client (see Table for state descriptions) NameLength Unsigned - Indicates the length of the Name field Name Character array Name of the Client application Table StatusResponse message A Client application shall use the enumerated values found in Table to indicate the Client s current state as well as the Client s supported states. All Clients must support at least the Unjoined and Ready states. A DDCA Client application may be in exactly one state at any instance in time. When indicating more than one supported state, a Client shall use a bitwise-or operation to compute the Client s supported state value. The DDCA Client state enumerations are as follows: State Unjoined Ready Stop Play Seek Pause Error Enumeration Value 0x x x x x x x Table Client Supported States Copyright 0 SISO. All rights reserved. Page of

26 0 0. JoinRequest This message is sent when a Client is requesting to join a DDCA event. If accepted, the Client will transition from the Unjoined state to the Ready state. ClientID UUID Unique identifier of the Client application (as assigned by the Master) SupportedStates Unsigned - Bit-masked value indicating states supported by the Client (see Table for state descriptions) NameLength Unsigned - Indicates the length of the Name field Name Character array Name of the Client application Table 0 JoinRequest message. LeaveRequest This message is sent when a Client is requesting to leave a DDCA event. Upon acknowledgement, the Client will transition into the Unjoined state and is free to join other DDCA events. ClientID UUID Unique identifier of the Client application (as assigned by the Master) Table LeaveRequest message. DDCACompatibility The DDCACompatibility message is sent when the Client is reporting its compatibility level for DDCA interoperability to the Master. Compatibility Level. DDCA-X - Enumerated value representing DDCA compatibility level Table DDCACompatibility message The DDCA-X message can be sent by either a Master or a Client application. DDCA-X messages are designed to provide a variable payload section, similar to that of a DIS Set Data Pdu. The variable payload section may contain any content as specified by the sender of the message. Senders and recipients of DDCA-X message(s) should have a shared understanding of the DDCA-X payload prior to using the message. The DataID, DataLength, and Data fields may be repeated as necessary within the DDCA-X message. If repeated, all fields {id, length, and data} must be included. The complete length of the DDCA-X message, including all payload contents, shall be reflected in the MessageSize field within the message header. DataID Unsigned - Identifier for the data field Copyright 0 SISO. All rights reserved. Page of

27 DataLength Unsigned - Data Unsigned -bit integer array Length of the data field Contents of the data field Table DDCA-X message Copyright 0 SISO. All rights reserved. Page of