STANDARDS RELATED DOCUMENT
AEP-84.1
IMPLEMENTATION GUIDELINES FOR
AEP-84
EDITION A VERSION 1
APRIL 2017
NORTH ATLANTIC TREATY ORGANIZATION
Published by the
NATO STANDARDIZATION OFFICE (NSO)
© NATO/OTAN
INTENTIONALLY BLANK
NORTH ATLANTIC TREATY ORGANIZATION (NATO)
NATO STANDARDIZATION OFFICE (NSO)
NATO LETTER OF PROMULGATION
5 April 2017
1.
The enclosed Standards Related Document, AEP-84.1, Edition A,
Version 1, IMPLEMENTATION GUIDELINES FOR AEP-84, which has been
approved in conjunction with AEP-84 by the nations in the NATO NAVAL
ARMAMENTS GROUP, is promulgated herewith.
2.
No part of this publication may be reproduced, stored in a retrieval
system, used commercially, adapted, or transmitted in any form or by any
means, electronic, mechanical, photo-copying, recording or otherwise, without
the prior permission of the publisher. With the exception of commercial sales,
this does not apply to member or partner nations, or NATO commands and
bodies.
3.
This publication shall be handled in accordance with C-M(2002)60.
INTENTIONALLY BLANK
AEP-84.1
Foreword
This Standard Related Document (SRD) Implementation Guidelines document is
based on Standardization Agreement (STANAG) 4586 Edition 4/AEP-84. As additional
changes to AEP-84 are approved and ratified, this document will be updated by the
Custodian, with support of the CST, accordingly.
TABLE OF CONTENTS
1.1 Document Objectives ...................................................................................... 7
1.2 Document Structure ........................................................................................ 8
2 UAS Architecture Overview ............................................................................... 9
2.1 Control Station Architecture ......................................................................... 11
2.2 UAS Level of Interoperability (LOI) .............................................................. 15
3 DLI Implementation Guidelines ....................................................................... 16
3.1 CUCS Interface .............................................................................................. 16
3.2 CUCS DLI Implementation ............................................................................ 21
3.3 VSM Interface................................................................................................. 28
3.4 Control Data Terminal (CDT) Interface ......................................................... 40
3.5 Video Interface............................................................................................... 46
3.6 Audio Interface .............................................................................................. 47
3.7 Use of Referenced Protocols and Standards .............................................. 48
3.8 Network Configuration .................................................................................. 49
3.9 Mission Planning ........................................................................................... 51
ATTACHMENT A: UA Custom Tag Implementation ........................................... 52
ANNEX 1 .................................................................................................................. 1
A1 CCI Implementation Guidelines ...................................................................... 1
A1.1 Interface Implementation.............................................................................. 1
A1.2 Message Implementation ............................................................................. 2
A1.3 Sensor Data Implementation ........................................................................ 3
A1.4 Voice Over IP Implementation...................................................................... 8
A1.5 CCISM Implementation ............................................................................... 10
ATTACHMENT A: CCI IMPLEMENTATION/HCI MAPPING MATRIX ................... 14
ATTACHMENT B: Parsed Field Utilization .......................................................... 18
ANNEX 2 .................................................................................................................. 1
A2 Human Computer Interface Requirements Implementation ......................... 1
A2.1 LOI 1 Information/Control Elements (HCI)................................................... 4
A2.2 HCI Development Process ........................................................................... 9
ANNEX 3 .................................................................................................................. 1
A3 Implementation Guidelines for AEP-84 Volume I .......................................... 1
A3.1 Functional Description ................................................................................. 1
1
Edition A Version 1
AEP-84.1
A3.1.1 1
A3.1.2 1
A3.1.2.3.1 Connection Phase 1: Discovery .......................................................... 4
A3.1.2.3.1.1 Discovering VSMs, UA and Payload Stations ................................. 4
A3.1.2.3.2.1 Stage 1: Initiate Download ................................................................ 9
A3.1.2.3.2.2
Stage 2: Send Configuration Messages ...................................... 10
A3.1.2.3.2.3 Stage 3: Send Configuration Complete ......................................... 10
A3.1.2.3.2.4 Caching Configuration Data ........................................................... 11
A3.1.2.3.3 Connection Phase 3: Establish Connection..................................... 11
A3.1.2.3.3.1 Requesting LOI Connection for VSMs, UA and Payload Stations 11
A3.1.2.3.3.2 Requesting Control of Data Links .................................................. 14
A3.1.2.3.4 Connection Phase 4: Release ........................................................... 15
A3.1.2.3.4.1 Releasing a LOI Connection for VSMs, UA and Payload Stations 15
A3.1.2.3.4.2 Release Control of Data Links........................................................ 16
A3.1.2.4.1
A3.1.2.4.2
A3.1.2.4.3
A3.1.2.4.4
UA Specific Configuration Messages ............................................... 17
Payload Specific Configuration Messages ...................................... 18
Data Terminal Specific Configuration Messages ............................. 18
Generic Configuration Messages ..................................................... 18
A3.1.2.4.5 Declaring That a Message Is Not Supported .................................... 19
A3.1.2.4.6 Declaring that a Field is Not Supported ........................................... 20
A3.1.2.4.7 Declaring that an Enumeration is Not Supported ............................ 20
A3.1.2.4.8 Declaring That a Bit in a Bit Field Is Not Supported ........................ 21
A3.1.2.4.9 Declaring Entity Specific Enumerations........................................... 22
A3.1.2.4.10 Declaring That a Capability is not Available .................................. 22
A3.1.2.4.11 Declaring Entry Values and Availability of Flight Navigation
Enumerations for Each Flight Mode ........................................................ 23
A3.1.2.4.12 Declaring Limits for a Field ............................................................. 24
A3.1.2.4.13 Declaring Alert Zones for a Field .................................................... 25
A3.1.2.4.14 Declaring Help Text for a Field ........................................................ 26
A3.1.2.5.1 Changing Field Availability ............................................................... 26
A3.1.2.5.2 Changing Enumeration Availability .................................................. 27
A3.1.2.5.3 Changing Bit Field Availability .......................................................... 27
A3.1.2.5.4 Changing Entry Values and Availability of Flight Navigation
Enumerations for Each Flight Mode .......................................................... 28
A3.1.2.5.5 Changing Field Limits ........................................................................ 28
A3.1.2.5.6 Changing Warning and Caution Thresholds .................................... 28
A3.1.2.5.7 Changing a Previously Unsupported Capability to be Supported .. 28
A3.1.6.4.1 CBRN Payload Classes ..................................................................... 64
2
Edition A Version 1
AEP-84.1
65
A3.1.6.4.2 CBRN Payload Data and Products .................................................... 65
A3.1.6.4.3 CBRN Payload Configuration and State ........................................... 76
A3.1.6.4.4 CBRN Payload Commands................................................................ 85
A3.2 Description and Implementation of DLI Messages ................................. 120
ANNEX 4 .................................................................................................................. 1
A4 Implementation Guidelines for the AEP-84 Volume II ................................... 1
A4.1 Functional Description ................................................................................. 2
A4.1.2.3.1 Connection Phase 1: Discovery .......................................................... 4
A4.1.2.3.1.1 Discovering VSMs, UA and Payload Stations ................................. 4
A4.1.2.3.2.1 Stage 1: Initiate Download .............................................................. 10
A4.1.2.3.2.2
Stage 2: Send Configuration Messages ...................................... 11
A4.1.2.3.2.3 Stage 3: Send Configuration Complete ......................................... 12
A4.1.2.3.2.4 Caching Configuration Data ........................................................... 13
A4.1.2.3.3 Connection Phase 3: Establish Connection..................................... 13
A4.1.2.3.3.1 Requesting LOI Connection for VSMs, UA and Payload Stations 13
A4.1.2.3.3.2 Requesting Control of Data Links .................................................. 16
A4.1.2.3.4 Connection Phase 4: Release ........................................................... 17
A4.1.2.3.4.1 Releasing a LOI Connection for VSMs, UA and Payload Stations 17
A4.1.2.3.4.2 Release Control of Data Links........................................................ 18
A4.1.2.4.1
A4.1.2.4.2
A4.1.2.4.3
A4.1.2.4.4
UA Specific Configuration Messages ............................................... 20
Payload Specific Configuration Messages ...................................... 20
Data Terminal Specific Configuration Messages ............................. 21
Generic Configuration Messages ..................................................... 21
A4.1.2.4.5 Declaring That a Message Is Not Supported .................................... 22
A4.1.2.4.6 Declaring that a Field is Not Supported ........................................... 23
A4.1.2.4.7 Declaring that an Enumeration is Not Supported ............................ 23
A4.1.2.4.8 Declaring That a Bit in a Bit Field Is Not Supported ........................ 24
A4.1.2.4.9 Declaring Entity Specific Enumerations ........................................... 24
A4.1.2.4.10 Declaring That a Capability is not Available .................................. 25
A4.1.2.4.11 Declaring Limits for a Field ............................................................. 26
A4.1.2.4.12 Declaring Alert Zones for a Field .................................................... 27
A4.1.2.4.13 Declaring Help Text for a Field ........................................................ 28
A4.1.2.5.1
A4.1.2.5.2
A4.1.2.5.3
A4.1.2.5.4
A4.1.2.5.5
Changing Field Availability ............................................................... 29
Changing Enumeration Availability .................................................. 29
Changing Bit Field Availability .......................................................... 30
Changing Field Limits ........................................................................ 30
Changing Warning and Caution Thresholds .................................... 31
3
Edition A Version 1
AEP-84.1
A4.1.2.5.6 Changing a Previously Unsupported Capability to be Supported .. 31
34
A4.2 Description and Implementation of DLI Messages ................................. 115
ANNEX 5 .................................................................................................................. 1
A5 Backward/Forward Compatibility Issues/Recommendations ....................... 1
TABLE OF FIGURES
Figure 1: Overview of a STANAG 4586 UAS Compliant System ......................... 9
Figure 2: The CUCS Relationship within the CS Architecture .......................... 11
Figure 3: DLI-4586 Communication Link ............................................................ 14
Figure 4: Message Wrapper Structure for AEP-84 Vol 1.................................... 19
Figure 5: Message Wrapper Structure for AEP-84 Vol 2.................................... 19
Figure 6: CUCS Message Reception ................................................................... 22
Figure 7: Warning System .................................................................................... 25
Figure 8: Warning Display ................................................................................... 25
Figure 9: CUCS Message Transmission ............................................................. 27
Figure 10: VSM Communication Flow (Configuration One) .............................. 29
Figure 11: Communication Flow (Configuration Two) ....................................... 30
Figure 12: Potential VSM Implementation .......................................................... 31
Figure 13: VSM Message Reception ................................................................... 34
Figure 14: VSM Message Transmission .............................................................. 34
Figure 15: Vehicle Specific Messaging ............................................................... 36
Figure 16: Generic IFF Dialog .............................................................................. 39
Figure 17: VSM IFF Dialog ................................................................................... 40
Figure 18: UA System Configuration .................................................................. 41
Figure 19: UA Message Configuration ................................................................ 41
Figure 20: Data Link Messaging .......................................................................... 43
Figure 21: A Possible Data Link Configuration .................................................. 44
Figure 22: Launch/Recovery System .................................................................. 45
Figure 23: ATC/UCS Communication.................................................................. 48
Figure 24: Networking Configuration Example .................................................. 50
Figure 25: CUCS Multicast ................................................................................... 51
Figure 26: VSM Broadcast ................................................................................... 51
Figure A1 - 1: Principle Structure of VoIP Implementation ................................. 9
Figure A1 - 2: CCISM Functional Architecture ................................................... 11
Figure A2 - 1: HCI Functional Architecture........................................................... 1
Figure A3 - 1: Example Sequence to Setup a CDT and Monitor a UA................. 4
Figure A3 - 2: Alert Zones within a Numerical Field .......................................... 26
Figure A3 - 3: Mission Plan ID ............................................................................. 30
Figure A3 - 4: Mission Waypoint Message Link ................................................. 32
Figure A3 - 5: Mission Message Upload Sequence with VSM ........................... 34
Figure A3 - 6: Waypoint Transitions ................................................................... 38
Figure A3 - 7: Routes with UA Position Waypoint Message Contingencies .... 40
4
Edition A Version 1
AEP-84.1
Figure A3 - 8: Standoff Detection of a Point Threat ........................................... 65
Figure A3 - 9: Standoff Detection of a Cloud Threat .......................................... 65
Figure A3 - 10: Example CBRN Detection Trend Graph ..................................... 75
Figure A3 - 11: Example of Configuring the CBRN Detection Low and
Operational threshold Levels ............................................................. 85
Figure A3 - 12: Payload Scan Window ................................................................ 86
Figure A3 - 13: SMS State Diagram ..................................................................... 90
Figure A3 - 14: Nominal Message Flow to Arm and Fire a Weapon Store ........ 95
Figure A3 - 15: Azimuth Offset .......................................................................... 147
Figure A3 - 16: Example of a VSM Response ................................................... 149
Figure A3 - 17: Data Link Configuration ........................................................... 150
Figure A3 - 18: Potential CUCS/VSM/CDT Configuration ................................ 150
Figure A4 - 1: Example Sequence to Setup a CDT and Monitor a UA................. 4
Figure A4 - 2: Typical Sequence for Downloading Configuration Data ............ 10
Figure A4 - 3: Alert Zones within a Numerical Field .......................................... 28
Figure A4 - 4: Mission Waypoint Message Link ................................................. 32
Figure A4 - 5: Mission Message Upload Sequence ............................................ 34
Figure A4 - 6: Mission Message Download Sequence ....................................... 36
Figure A4 - 7: Example Task Using UA Position Waypoint Message ............... 38
Figure A4 - 8: Azimuth Offset ............................................................................ 123
Figure A4 - 9: Example of a VSM Response ..................................................... 125
Figure A4 - 10: Data Link Configuration ........................................................... 126
Figure A4 - 11: Potential CUCS/VSM/CDT Configuration ................................ 126
Figure A4 - 12: Configuration Information ........................................................ 134
Figure A4 - 13: Generic Depiction of the Field Configuration Float Response
Message............................................................................................. 138
5
Edition A Version 1
AEP-84.1
TABLE OF TABLES
Table 1: Example of a Formatted DLI Wrapped Message ..................................20
Table A1 - 1: STD 0601.4 KLV Metadata Elements and DLI/CCI Mapping
Requirements
.........................................................................................6
Table A2 - 1:
Definition of
Information/Control Elements ....................................4
Table A2 - 2: HCI Functions for LOI 1 ....................................................................4
Table A2 - 3: Additional HCI Functions for LOI 2 ..................................................5
Table A2 - 4: Additional HCI Functions for LOI 3 ..................................................7
Table A2 - 5: HCI Functions for LOI 4 ....................................................................9
Table A2 - 6: Additional HCI Functions for LOI 5 ..................................................9
Table A2 - 7: User Interface Requirements ..........................................................14
Table A3 - 1: ID Fields in STANAG Messages ....................................................... 3
Table A3 - 2: Typical Sequence for Downloading Configuration Data ............... 9
Table A3 - 3: Entity Types.................................................................................... 18
Table A3 - 4: Fully Supported Messages ............................................................ 19
Table A3 - 5: Message #800 Field 5 Values ........................................................ 33
Table A3 - 6: Message #47 from AEP-84 Volume I ............................................. 37
Table A3 - 7: Flight Termination Mode Message Sequence ............................ 126
Table A3 - 8: Source Message for Altitude/Airspeed ....................................... 129
Table A3 - 9: Source Message for Heading ...................................................... 129
Table A3 - 10: Data Link Message Sequencing ................................................ 148
Table A3 - 11: Vehicle Specific Subsystem Parameters, States and Subsystem
........................................................................................................... 157
Table A4 - 1: Entity Types .................................................................................... 21
Table A4 - 2: Vehicle Operating Mode Message Sequence ............................... 44
Table A4 - 3: Cross Reference Table for CUCS Vehicle Operating Modes (Flight
Modes) ................................................................................................. 46
Table A4 - 4: Flight Termination Mode Message Sequence .............................. 49
Table A4 - 5: UA Specific Parameters and Associated Range of Values for
Identified STANAG Parameters .......................................................... 56
Table A4 - 6: EO/IR/Laser Payload Message Sequence ..................................... 92
Table A4 - 7: Vehicle Specific Subsystem Parameters, States and Subsystem
............................................................................................................ 133
6
Edition A Version 1
AEP-84.1
1 Background
This Implementation Guide was written to facilitate implementation of a STANAG
conforming system and its requirements for system developers. As a parallel effort, a
Validation Guide was written to provide guidance on methodologies for ensuring that
Unmanned Aircraft (UA) Control System (UCS) equipment is compliant with the
STANAG. Together these two documents along with the STANAG 4586 document
define the requirements for NATO interoperable UCS equipment, provide guidance on
the implementation of such equipment, and provide guidance on confirming that this
equipment complies with the STANAG.
The STANAG defines common interfaces and architectures with the intention of
providing interoperability within and between the various NATO allied forces at various
Levels of Interoperability (LOIs). These levels range from Level 1 (indirect receipt of
UA related data) to Level 5 (control and monitoring of the UA (Level 4), plus launch
and recovery functions). Particular STANAG requirements are tailored specifically to
each LOI.
The Implementation Guide provides guidance for NATO governments and industry to
assist in developing nationally designed and built UCSs. It describes the overall Core
UCS (CUCS) architectural characteristics, concerning both hardware and software,
necessary to support STANAG 4586 requirements. Examples are given for various
LOI architectures addressing standalone configurations, portable configurations, and
networked configurations. Technical information and guidance on the implementation
of the Vehicle Specific Module (VSM) functions, Command and Control Interface
Specific Module (CCISM) functions, Control Data Terminal (CDT) functions, launch
and recovery systems and mandatory protocols and standards as well as incorporation
of related STANAGs into the UCS are also addressed.
The recommendations for design and implementation of a STANAG 4586 compliant
UCS contained in this document were based on the lessons learned from the
development of a prototype STANAG 4586 compliant UCS (focusing on the Data Link
Interface (DLI)) funded by Canadian MOD, similar developments by NIAG SG 73
industry members as well as further analysis of the STANAG 4586 Edition 4/AEP-84
by the STANAG 4586 Custodian Support Team (CST).
1.1 Document Objectives
STANAG 4586 defines a standard for system designers to apply in the creation of
interoperable control systems for UA. The term “interoperable” refers to:



The ability of any compliant control system to monitor and/or control any
compliant UA.
The ability of any compliant control system to interchange information with
C4I systems extant within the NATO community.
The ability to receive and disseminate imagery and other specified payload
formats.
This standard mandates neither a particular design nor a unique hardware and
software architecture. However, it does imply a functional architecture and set of
interfaces that, if adhered to, will provide the capability to achieve the desired LOI.
The subject area covered by STANAG 4586 is both broad and complex and many
interpretations and design choices are possible. The objective of this document is to
provide developers with the background and understanding used by the writers of
STANAG 4586 in defining the standard.
It also provides suggestions for
implementation that will, if adhered to, help assure that compliance and interoperability
7
Edition A Version 1
AEP-84.1
are readily achieved. The guidance contained in this document is not considered
mandatory, and does not constitute criteria for system validation.
1.2 Document Structure
STANAG 4586/AEP-84 defines requirements and two “over the air” encoding
schemes. AEP-84 Volume I defines the protocol and encoding scheme utilizing IEEE
four-byte and eight-byte floating point representations of data and a fixed message
length. The messages support the following functions: command and control of UA
and EO/IR, SAR, CBRN, and Weapons payloads.
AEP-84 Volume II incorporates the protocol and encoding scheme utilizing scaled
integers in lieu of IEEE four-byte and eight-byte floating point representations and a
variable message length resulting in a more efficient bandwidth utilization. The
messages support the following functions: command and control of UA and EO/IR and
SAR payloads; automated vehicle behaviour; expanded STANAG 7085 data link
control; extensions to Common Route Definition (CRD) standard to define UAS flight
and mission plans; map drawing; and monitor only capability for LOI 3 and 4.
This document provides Implementation Guidance for interoperable implementations
of both AEP-84 Volumes 1 and 2 and is structured as follows:

The main document of SRD AEP-84.1 provides an overview and
functional architecture requirements of the Unmanned Aircraft System
(UAS) and it’s Control System comprised of: Core Unmanned Control
System (CUCS); Vehicle Specific Module (VSM); and interfaces
between the CUCS and VSM ( Data Link Interface (DLI)), between, the
VSM and Launch and Recovery (L/R) system, between the CUCS and
Command and Control System ( Command and Control Interface (CCI))
and between the CUCS and the Control Data Terminal (CDT). The
provided guidance is applicable for both AEP-84 Volumes 1 and 2.

Annex 1 provides implementation guidance for the CCI interface and is
applicable for both AEP-84 Volumes 1 and 2.

Annex 2 provides guidance for the implementation of Human Computer
Interface and is applicable for both AEP-84 Volumes 1 and 2.

Annex 3 provides guidance for implementation of function and message
requirements specified in AEP-84 Volume I.

Annex 4 provides guidance for implementation of function and message
requirements specified in AEP-84 Volume II

Annex 5 provides guidance and mapping between data elements
specified by AEP-84 Volume I and Volume II. The mapping will facilitate
interoperability between Volume I and Volume II compliant systems.
8
Edition A Version 1
AEP-84.1
2 UAS Architecture Overview
Figure 1 depicts a possible configuration of a STANAG 4586 compliant system. This
figure covers more than just the UCS; it defines the relationships between the UCS,
the UA, the C4I nodes with which it interacts, and the various interfacing components.
The major blocks include:

Various instantiations of UCSs at LOIs 1 through 5 (defined below).

Command, Control, Communications, Computers and Intelligence
(C4I) nodes serving as information channels for coordination and data
dissemination, including mission planning requirements and
specifications, UA mission tasking, intelligence on targets and threats,
payload data products and secondary intelligence data products.

VSM functions that provide management of real-time control
interactions with the UA; translation between common messages used
by the CUCS and specific messages used by the UA and data link; and
a repository and server for vehicle-specific data and methods. Note:
Although represented as a system component in the following
diagrams, VSM is a collection of functions which can be allocated to
various UAS system components.

CDTs that consist of the communications hardware and software
associated with the UCS side of the data link.

Special equipment required for launch and recovery operations.

Vehicle Data Terminal (VDT) that consists of the communications
hardware and software associated with the UA side of the data link.

The UA, including payload(s).
UA
Payload(s)
VDT
CDT
CDT
VSM
VSM
VDT
Level 1 CUCS
CCISM
Level 4, 5 CUCS
Level 2, 3 CUCS
Level 1 CUCS
Launch/Recovery
Equipment
CCISM
Level 2, 3 CUCS
Level 4, 5 CUCS
Figure 1: Overview of a STANAG 4586 UAS Compliant System
9
Edition A Version 1
AEP-84.1
The relationships implied by the connections between blocks in Figure 1 are just as
important as the blocks themselves. The following items are the noteworthy points
about these relationships:

A Level 1 CUCS may interface with either a node in the C4I
infrastructure or another CUCS operating at interoperability Level 1 or
higher.

CUCSs generally will connect with the C4I infrastructure, but they may
operate as standalone devices as well.

There is no fundamental limit to the number of CUCSs that may be
connected, directly or indirectly, to a given UA. Conversely, there is no
restriction on the number of UA that may be in contact with a given
CUCS. However, specific UA or CUCS configurations may impose a
limit by virtue of the method of handover or hardware limitations, such
as the number of available data link channels.

Coordination of control handover among CUCSs may be achieved
through the use of “out of band” communications such as C4I system
communications (if available), via relay through the UA, or by prelaunch
flight planning. No provision is made for dedicated communications
channels between CUCSs for the purposes of handover coordination.
Direct communications may be established between the respective
CDTs if supported by the data link hardware.

Figure 1 depicts CUCSs as having point-to-point communications with
a C4I node. In actuality, the connection might be with a network of C4I
nodes, or even with a network of other UCSs without the presence of
other C4I nodes.
In the latter case, direct peer-level CUCS
communications should be viewed as passing through a C4I
infrastructure and through the CCISMs between the respective UCSs.

The connection between a CUCS and a VSM function is the DLI. One
of the functions/roles of the VSM is to provide translation between DLI
compliant message formats and those hardware and software
interfaces that control the data link or the UA. Low-latency real-time
requirements are managed/allocated to the “real-time” function of the
VSM. The VSM functions may be physically co-located with or hosted
by the CUCS, CDT or the UA.

When special launch and recovery equipment is required to support this
capability, such equipment interfaces through the VSM/CDT. This
approach is taken because such equipment, in general, has low latency
real-time requirements that are allocated to the VSM/CDT. The same
is true for any controls or displays having real-time requirements for the
vehicle design.

Generally, communications between the CDT and the VDT must be bidirectional to support messaging for control and status messages.
However, in the case of a Level 2 CUCS, the CDT may support receiveonly operations.
It is important to note that compliance does not require a completely fresh re-design of
a legacy system. While the most compact and efficient implementation may well be
different from any existing system, the STANAG has defined a functional architecture
10
Edition A Version 1
AEP-84.1
and set of logical interfaces making it possible for legacy systems to become compliant
with a minimal amount of redesign, particularly at the lower LOIs.
2.1 Control Station Architecture
As illustrated in Figure 2, the CUCS is the central element of the Control Station (CS)
Architecture. The CUCS implements the DLI, CCI and CUCS/Human Computer
Interface (HCI) functionality through which it communicates to the UA via the VSM,
directly to a C4I node or via a CCISM if necessary, and to the UA System Operator(s)
via the CUCS/HCI.
Figure 2: The CUCS Relationship within the CS Architecture
The CUCS software provides the UA System Operator the necessary tools for
computer related communications, mission planning, mission execution, payload data
receipt, limited data exploitation, and data dissemination. The software also supports
a computer generated GUI that enables UA operator(s) to effectively execute assigned
missions. Although shown as a “single box” in Figure 2, the CUCS software
architecture should be open and modular. For example, the mission planning function
11
Edition A Version 1
AEP-84.1
can be allocated to an existing, certified mission planning system, (hardware and
software) to satisfy the UA Mission Planning requirement in a very cost effective
manner.
2.1.1 CUCS Architecture Overview; Minimum Hardware and Software
The minimum required CUCS architecture and functionality, software and hardware,
is dependent on the desired LOI. The STANAG 4586 specified CUCS requirements
provide:

The functionality and capability to receive, process, and
disseminate (if necessary) payload data from the UA and payload;
perform mission planning (if required); monitor and control the
payload; monitor and control the UA; and monitor and control the
data links

A software architecture to support additional future UA and payload
capabilities

The UA operator with the necessary tools for computer related
communications, mission tasking, mission planning, mission
execution and monitoring, data receipt, data processing, and data
dissemination

The capability to host the VSM and CCISM functions
These requirements apply to a CS supporting all LOIs. For selected interoperability
LOIs only a subset of these requirements are applicable.
For LOI 1, the only applicable requirement is to receive and process, and depending
on the concept of operations, to further disseminate the UA data. This can be
accomplished using any system (new or existing) having the capability to receive UA
system status and payload data directly from a CS using the STANAG 4586 CCI
specified message formats or from another C4I node using the CCI specified
messages. The system used for this purpose would then be, in the context of STANAG
4586, a CS and be compliant with STANAG 4586 for LOI 1. Depending on applicable
concept of employment and operations, the LOI 1 CUCS can be interfaced with the
transmitting CS or C4I node via a physical interface (e.g., copper, fibre, or Radio
Frequency (RF) link). The choice is driven by the proximity of the receiving CUCS to
the transmitting element.
For LOI 2, in addition to LOI 1 requirements, the CUCS needs to provide the capability
to monitor and control the status of the CDT used for direct receipt of data from the
UA. It also needs the ability to receive, process and display the data elements within
the STANAG 4586 specified LOI 2 messages for the DLI and CCI interfaces for those
systems not receiving sensor metadata. For systems receiving digital sensor
metadata, receipt and processing of LOI 2 DLI messages is optional. Dependent on
the functional allocation of the data link control and the “translation” of DLI specified
message formats to the respective UA unique formats, the appropriate VSM functions
may or may not be required. One of the functions of a VSM is to translate from DLI to
a non-DLI control message set so that the organic message set is not changed. Once
the UA and/or CDT are coded to “speak” DLI, it no longer needs this VSM function; it
only needs to be DLI compliant. In those cases, the UA and/or CDT would be STANAG
compliant to a certain LOI. Otherwise, the VSM functions for the associated UA(s) need
to be provided and integrated with the CUCS. The ability to receive and transmit LOI
2 messages for the CCI may or may not be required. This will be dependent on the
12
Edition A Version 1
AEP-84.1
applicable concept of operations and the CS operational architecture (e.g., standalone
workstation or Personal Computer (PC)), interfaced with other C4I nodes via a network
or point-to-point communication link. If the CS is operated in the stand-alone mode,
then there is no interface with other C4I nodes and therefore no need for the CUCS to
receive/transmit (and process) any of the STANAG 4586 CCI specified messages. For
applications where there is a requirement to interface with specified C4I nodes, in a
network configuration or via a data link, the CCI specified messages must be
implemented in order to be interoperable with those nodes.
For LOI 3, the CUCS must, at a minimum, provide the capability to control and monitor
the status of the UA payload(s), generate and upload payload related mission planning
data, in addition to providing all of the LOI 2 capabilities. If the UA payloads require
real or near-real time control then a compatible VSM/CDT function that provides this
capability is required. Handover of payloads (receive and relinquish) is an additional
function required of LOI 3 payload control.
For LOI 4, receipt of control of UA, the CUCS must provide for UA control and
monitoring and upload of UA mission plans. In this case the “stand alone” mission
planning hardware and software are an integral part of the CUCS. In general, all
elements, hardware and software, which support the desired CUCS requirements and
functionality, are considered to be an element of the CUCS. It should be noted that a
UCS that supports both UA and payload control and monitoring is both a LOI 3 and 4
compliant CS.
In support of LOI 5, Launch and Recovery, the assumption is to have a launch and
recovery standalone system interface to the UA or to incorporate the launch and
recovery functions (e.g., tracking system interface and glide slope management) in the
respective VSMs. Thus, the CUCS requirements for this LOI would be the same as for
LOI 4.
2.1.2 Scalability
The critical element of the CUCS is the software component. The software implements
the required functionality to support UA interoperability and operations in a Joint,
Combined operating environment. The software should support a computer generated
graphics user interface that enables a UA operator to effectively carry out the requisite
tasks in the execution of an assigned mission. In real operational environments, the
required CUCS functionality can vary significantly – from receipt of UA data using a
stand-alone PC with LOI 2, to control and monitoring of the payload(s) with LOI 3, to
control and monitoring of the UA with LOI 4 and/or 5, to control and monitoring of both
payload(s) and UA(s) with LOI 3 and 4/5. Thus, the CUCS software architecture should
allow for the addition of functionality associated with the various concepts of
employments. It should also be portable so that it can be hosted on different hardware
platforms with minimum modifications.
In similar fashion, the CUCS hardware architecture must be scalable so as to provide
the required resources for the various software configurations and satisfy the physical
constraints mandated by the various UA concepts of employment (i.e., adding
additional memory to support expanded functionality). The hardware configurations
can range from a stand-alone laptop utilised by a single individual to several, network
configured, workstations in a Tactical Operations Centre (TOC).
2.1.3 System Performance
The CUCS is intended to be a non-real or near-real time application. All UAS time
critical functions should be allocated to the VSM/CDT, and the CCISM as applicable.
For example, all UA and payload real-time functions would be allocated to the VSM. In
13
Edition A Version 1
AEP-84.1
similar fashion, any CCI real-time requirements would be allocated to their respective
specific modules. This approach will permit the best-qualified system element provider
(e.g., UA and payload developer), to implement these system critical functions and
allow the CUCS to implement the more general, non-real-time functions. However, as
the overall UAS performance is dependent on overall end-to-end latency, care should
be taken that the CUCS throughput performance does not make a significant
contribution to latency (from the receipt of a signal or operator input to the
desired/specified output (e.g., operator input for payload pointing, to its output on the
DLI).
Excessive latency can adversely affect the ability of the operator to control the UA and
payload. Since latency of the entire system is not within the scope of STANAG 4586,
it does not address latency at a system level. The current STANAG does, however,
specify latency for the CUCS.
Latency of the system can be allocated to three components shown in Figure 3 below:
the CUCS, VSM/data link/UA, and DLI - 4586 communication link. The latency within
the VSM/UA is outside of the STANAG set of interfaces and is the responsibility of the
VSM and UA providers (who may be the same). The communication link between the
CUCS and the VSM/CDT may have a variable latency based on the physical link that
is selected and is within the STANAG interfaces. The latency from one CUCS interface
to another, other than the communication link, is totally under the control of the CUCS
manufacturer.
DLI-4586
VSM CDT/VDT
UA
Core UCS
UDP
Figure 3: DLI-4586 Communication Link
The system designer is ultimately responsible for designing a system that will perform
as required when using the components shown above. If latency is critical, then the
system designer must evaluate the latencies measured or allocated to the components
and verify the system will operate as desired.
The media chosen for the DLI implementation can pose a difficult problem for the
system designer in that its latency can vary markedly based on the physical link chosen
and may not be under the direct selection of the system designer. The latency for a
CUCS and VSM that are collocated and connected by a dedicated hard wire
connection would be effectively zero, while a CUCS located in one country connected
to a VSM in another country connected by a satellite link could have latencies in terms
of seconds. This variation in latency due to the physical communications link will result
in different qualification tests for each type/length of physical link used.
If no limits in the transport of data through the CUCS were defined, it could result in a
system that, with a change of a CUCS component, would no longer be operable. Since
the desire is to have interoperable CUCS systems, the STANAG specifies maximum
latency for each message. Interoperability will be facilitated if systems are designed
14
Edition A Version 1
AEP-84.1
with the latencies suggested in tables throughout STANAG/AEP-84 Volumes 1 and 2
(e.g., Table 4 - 5: Message Summary and Properties of Volume I and Tables 4 – 6
through 4 – 33 of Volume II). These latency numbers do not support a hard real-time
system but a near-real-time system.
2.2 UAS Level of Interoperability (LOI)
The conceptual basis upon which STANAG 4586 rests is that of a compliant CS that
operates with a range of UA and supports various LOIs. These interoperability levels
could also be thought of as levels of control that restrict the amount of influence a given
control system can exert over a UA. These levels are defined in detail in STANAG
4586/AEP-84 Volume I Chapter 3 “Top Level Description”, and AEP-84 Volume II and
are as follows:
AEP-84 Volume I
Level 1:
Indirect receipt of UA related data
Level 2:
Direct receipt of ISR/other data where “direct” covers reception of the
UA data by the UCS when it has direct communication with the UA.
Level 3:
Control and monitoring of the UA payload in addition to direct receipt of
ISR/other data
Level 4:
Control and monitoring of the UA, less launch and recovery.
Level 5:
Control and monitoring of the UA (Level 4), plus launch and recovery
functions
AEP-84 Volume II
Level 1:
Indirect receipt and/or transmission of sensor product and associated
metadata, for example KLV Metadata elements from the UA.
Level 2:
Direct receipt of sensor product data and associated metadata from the
UA.
Level 3:
Control and monitoring of the UA payload unless specified as monitor
only.
Level 4:
Control and monitoring of the UA, unless specified as monitor only, less
launch and recovery.
Level 5:
Control and monitoring of UA launch and recovery unless specified as
monitor only.
Unless otherwise stated, LOI 3, 4 & 5 assume control and monitor.
Note: LOIs 1 - 3 in the above definitions includes dissemination of payload imagery or
data products if the CS is connected to a C4I node.
A CS can be compliant for any combination of the above LOIs or all levels. For
example, a CS can be LOI 1, 2, 3, 4, and 5 for its “native” system (e.g., Predator), and
LOI 2 and 3 (direct receipt of payload data as well as control and monitor of UA
payloads) with a different UA (e.g., UK Watchkeeper).
These various levels imply different functional requirements that clearly have an impact
on the CS architecture and how a system is composed to meet those requirements.
The following sections provide guidance on tailoring the architecture for each of these
“interoperability levels”.
15
Edition A Version 1
AEP-84.1
3 DLI Implementation Guidelines
The STANAG 4586 concept calls for a certain level of generic UA control from the
CUCS, supplemented with the specific control being provided by the implementation
of VSM functions. The STANAG 4586/AEP-84 Volume I and Volume II DLI message
sets provide the interface between the VSM component and the CUCS component of
the system. Annex 3 and 4 of this document expand on the message sets and data
elements to ensure that there is a common understanding of the intent of these
messages.
The DLI message set is a standard set of messages, in a specified format that provides
for the base functionality of a CUCS for any given control system (CS). The VSM and
CUCS combination must also support a defined method, such as X-protocol or Hyper
Text Transfer Protocol (http), to control and display data elements that are specific to
a particular CS, in addition to the defined generic control and display capability. There
is to be no reliance on real-time interaction between the CUCS and the VSM in the
system. The “real-time” function of the VSM, wherever allocated, provides for the realtime control of the UA, and is the interface between the UA and the CUCS.
The CUCS component of the system has been defined to provide a specific level of
control over the UA and/or its payload at a specified LOI. For AEP-84 Volume I, Table
4 - 5 Message Summary and Properties in Chapter 4, lists all of the DLI messages.
Similarly, AEP-84 Volume II, Tables 4 – 5 through 4 – 33 in Chapter 4, lists all of the
DLI messages. The implementation approach presented here focuses on LOI 3, 4 and
5, as these require implementation of all defined payload and UA DLI messages.
Part of the purpose of this Implementation Guide is to make recommendations
regarding what elements should be implemented in the CUCS, and what elements
should be implemented through the VSM functions.
Note that the LOI specified in the STANAG 4586/AEP-84 Volume I (Chapter 4, Table
4 – 5) and STANAG 4586/AEP-84 Volume II (Chapter 4, Tables 4 – 5 through 4 – 33)
define the messages that are required to be supported by the CUCS and the VSM for
each of the specified LOIs. In addition, LOI 2 messages may be available prior to
specific authorizations being granted by the VSM to allow field configurations for the
GUIs to be completed prior to initiating an active session. In AEP-84 Volume I the
CUCS transmits the CUCS Resource Report (Message #1202) to authorize vehiclespecific displays. In AEP-84 Volume II, this can be accomplshed by requesting LOI 2
Monitor Only via CUCS Authorization Request (Message #1). Additionally,
configuration of the data links may be accomplished prior to obtaining VSM
authorization.
3.1 CUCS Interface
The intent of STANAG 4586 is to define a generic control system for all UA systems
running an interoperable software package, which is capable of interfacing with
multiple VSMs and their respective UA. This means that there must be a well-defined
interface between the CUCS, which provides the User Interface for the system, and
the VSM, which provides the interface from the CUCS to the UA. A bi-directional data
interface is needed to provide a communication pathway between the VSM and the
CUCS for the passing of DLI messages between the two components. STANAG 4586
imposes a requirement for the CUCS to support User Datagram Protocol (UDP)
multicast for the transmission of the generic DLI formatted messages and provides for
the option of either Transmission Control Protocol (TCP)/Internet Protocol (IP) or
UDP/IP for the transmission of remote vehicle specific displays between the CUCS
and VSM. When the VSM functions and CUCS are both implemented as software
16
Edition A Version 1
AEP-84.1
components, and loaded on the same computer for future connections to other VSMs
or CUCSs, it is recommended that the VSM and CUCS software components transmit
the DLI messages between themselves with a pair of multicast IP addresses and UDP
ports (IP/port). An arbitrary number of software processes may be configured to send
(publish) data to a single UDP multicast address (IP/port) and an arbitrary number of
software processes may be configured to receive data from that same UDP multicast
address. A single IP address and port is designated for multicast of messages sent
from every CUCS and a second IP address and port is designated for multicast of
messages from every VSM.
3.1.1 Software Interface Protocol
The generic message interface between a CUCS and a VSM uses UDP/IP multicast,
and the interface between the CUCS and the VSM for the vehicle specific interface
may optionally be TCP/IP or UDP/IP.
The UDP multicast protocol requires the specification of both an IP address and a port.
A service may be added to the services file that identifies the UDP ports to be used
between the CUCS and the VSM.
For example on a UNIX system:
Service_name
port/protocol
CucsMulticast 52000/udp
Multicast from CUCS
VsmMulticast 52001/udp
Multicast from VSM
There is an additional requirement to identify the IP multicast address for the
connection. On many network configurations, the IP address range available for UDP
multicast is restricted to be between 224.0.0.0 and 239.255.255.255. The description
of the CUCS multicast address and the VSM multicast address must be specified by a
combination of IP address and port number (e.g., 233.16.14.28:52000). Determination
of the appropriate UDP multicast addresses and ports is ultimately a network
administration task that must be coordinated to configure each VSM and CUCS onto
a common network.
The CUCS will queue and process the packets received from the VSMs on a first in
first out basis. The system UDP buffer is a limited size and does not expand. Therefore
if the CUCS is connected to too many VSMs, the buffer could be overrun and data lost.
There is a potential for a single CS to have a CUCS and multiple, distinct VSMs colocated on a single hardware platform.
When the VSM is located on the ground with the CUCS, multiple Vehicle IDs (VSM
IDs) may be assigned to a VSM dependent on the number of vehicles that can be
simultaneously controlled from the VSM. (This is done in order to be able to distinctly
identify “logical” VSMs in a networked system.) The VSM will monitor the UDP socket
for each of its assigned Vehicle IDs, and internally route the messages as required to
the appropriate Vehicle IDs.
When the VSM is in the air, the Vehicle ID will be the VSM ID, and the Vehicle ID will
most likely also be the vehicle tail number. Although the STANAG 4586 uses the
Vehicle ID numbers to identify vehicles, to support “legacy” systems the STANAG 4586
has recognized that a VSM ID is required for the system to work in a network
environment. When the VSM is in the air, there will be only one VSM per UA.
3.1.2 Interface Data Representation
17
Edition A Version 1
AEP-84.1
The representation of data across the DLI interface is very important, especially since
there is a potential for using different Operating Systems within the same CS.
Developers are required to ensure that they are sending data across the DLI interface
with the correct Byte and Bit ordering as specified in the STANAG 4586. It is also
important to verify that the correct units are being used in the creation of the DLI
messages for transmission across the interface. STANAG 4586 has attempted to
standardize on the Scientific International (SI) International Organisation for
Standardization (ISO) 1000:1992 system, however there may be inconsistencies.
Implementers are required to verify the correct units for each parameter within the
formatted messages contained in STANAG 4586/AEP-84 Volume I and Volume II.
3.1.3 Packaging of Formatted Messages
Table 4 – 5 of STANAG 4586/AEP-84 Volume I and Tables 4 – 5 through 4 – 33 of
AEP-84 Volume II identify the DLI messages applicable/required for the respective LOI
configurations. The VSM and CUCS have the capability to transmit correctly formatted
messages for which they are specified as the source of the message. The CUCS must
be able to receive correctly formatted messages from the VSM, and the VSM must be
able to receive correctly formatted messages from the CUCS. The reception of
erroneous messages, or messages not supported at the specified LOI, must not cause
adverse effects at either the CUCS or VSM.
The interaction between messages, such as the requirement for acknowledgements,
will be described in Annex 3 and 4 of this document, respectively.
3.1.4 Message Distributed Standard
STANAG 4586 uses a “message passing” approach to provide inter-process
communications. The STANAG defines a system for transporting these messages, to
assure proper delivery of the messages, manage the allocation of resources, and
provides a standard definition for how the data is to be formatted and packaged.
3.1.4.1 Message Wrapper
The STANAG defines the message wrapper that is required for transmission of the
formatted DLI messages. The message wrapper format for AEP 84 Volume I and
Volume II are different as illustrated below. The definition of the respective elements
of the wrapper are provided in Section 3.3.1 of AEP-84 Volume I and 2 respectively,
The wrapper is used to address the messages to the correct destination, and to verify
their correct reception. The following Figures show the message wrapper structure for
AEP-84 Volumes 1 and 2:
18
Edition A Version 1
AEP-84.1
IDD Version
Msg Instance ID
Instance Number
Message Type
Number of bytes in body
Message Length
Unique stream for each source/destination pair
Stream ID
Message Properties
Message
Data
Checksum
Figure 4: Message Wrapper Structure for AEP-84 Vol 1
Source Port*
Destination Port*
Packet Length*
UDP Checksum*
Reserved
Message Length
Source ID
Destination ID
Message Type
Message Properties
Data (Message Payload)
Optional Checksum
Figure 5: Message Wrapper Structure for AEP-84 Vol 2
19
Edition A Version 1
AEP-84.1
3.1.4.1.1 Example of a Wrapped AEP-84 Volume I DLI Message
The following Table is an example of an AEP-84 Volume I formatted DLI message
wrapped in the message wrapper structure. Message #1, CUCS Authorization
Request, is used in the following example:
Wrapping
Element
Message
section
Size (bytes)
Content
Formatted content
(Hex)
10 (NULL
Terminated)
"2.0"
32 2e 30 00 00 00 00 00
00 00
Msg
Instance Id
4
751
00 00 02 ef
Msg Type
4
1
00 00 00 01
Message
Length
4
31
00 00 00 1f
Stream ID
4
-1
ff ff ff ff
Packet Seq.
#
4
-1
ff ff ff ff
Timestamp
8
0.1234
3f bf 97 24 74 53 8e f3
Vehicle ID
4
10.8.1.167
0a 08 01 a7
CUCS ID
4
10.12.0.4
0a 0c 00 04
Vehicle Type
2
11
00 0b
Vehicle Sub
Type
2
2
00 02
Data link ID
4
10.12.0.1
0a 0c 00 01
Requested LOI
1
3
03
Controlled
Station
4
0x00000004
00 00 00 04
Controlled
Station Mode
1
1
01
Wait for Data
link Trans. Msg.
1
0
00
4
3738
00 00 0e 9a
IDD
Message
Data
Checksum
Total length
65
Table 1: Example of a Formatted DLI Wrapped Message
The resulting complete formatted message is the following hex bytes sequence:
20
Edition A Version 1
AEP-84.1
32 2e 30 00 00 00 00 00 00 00 00 00 02 ef 00 00 00 01 00 00 00 1f ff ff ff ff ff ff ff ff 3f
bf 97 24 74 53 8e f3 0a 08 01 a7 0a 0c 00 04 00 0b 00 02 0a 0c 00 01 03 00 00 00 04
01 00 00 00 0e 9a
3.2 CUCS DLI Implementation
The intent of STANAG 4586 is to define a generic control system for all UA systems
running an interoperable software package, which is capable of interfacing with
multiple VSMs and their respective UA. This means that there must be a well-defined
interface between the CUCS, which provides the User Interface for the system, and
the VSM, which provides the interface from the CUCS to the UA. A CUCS
implementation of the DLI must be capable of creating all the DLI messages stated as
being sourced by the CUCS, and be able to decode all messages stated as being
sourced by the VSM, based on the LOI specified for the CUCS as required for a
particular LOI.
3.2.1 Message Implementation
Table 4 - 5: Message Summary and Properties in Chapter 4 of STANAG 4586/AEP84 Volume I and Tables 4 – 5 through 4 - 33 in STANAG 4586/AEP-84 Volume II,
identifies the formatted DLI messages (or group of messages) that must be
implemented to achieve each of the defined LOIs. The CUCS need only implement
messages specific to the desired LOI(s). For example, a LOI 4 CUCS must implement
all the messages contained in the table stated as required for LOI 4, whereas a LOI 2
CUCS need only implement all the Level 2 messages contained in the table, and then
only for a specified payload type. The reception of unimplemented messages should
not affect the operation of a CUCS.
3.2.1.1
Reception of STANAG 4586 DLI Messages
A VSM transmits STANAG 4586 compliant DLI messages to a CUCS. When these
messages are received by the CUCS it must be capable of the following;





Receive messages
Decode messages
Store data
Process data
Present/Distribute data
A possible implementation of this system is presented below in Figure 6.
21
Edition A Version 1
AEP-84.1
Raw
Data
Packet
Sync
Packets
Data
Decoder Elements Memory
Msg Ack
CUCS
App’s
Figure 6: CUCS Message Reception
3.2.1.1.1 Packet Synchronization
The CUCS receives DLI messages from a VSM that have been packaged in
accordance with the respective AEP-84 Volume I and 2 message wrapper definitions.
The wrapper is used to address the messages to the correct destination, and to verify
their correct reception.
The inter-process communication method between the CUCS and the VSM has been
identified as being UDP/IP. The CUCS/VSM integrator must ensure that the correct
IP address and port numbers are identified for the system as described in the Software
Interface Protocol section (Section 3.1.1) of this document.
The packet synchronisation process strips out the STANAG messages from the
wrapper leaving the formatted messages as defined in Table 4 - 5 Message Summary
and Properties (AEP-84 Vol.1) and the functional group tables (Table 4 – 6 through 4
– 33) of AEP-84 Vol. 2. For AEP-84 Volume I stripping process, the first thing that
happens is the “IDD Version” is read and compared to the version of the STANAG
document for which the receiving CUCS was implemented. If the IDD Version is not
the same or backwards compatible, the message is discarded and the operator alerted.
The decoding of the respective elements of the message wrapper are done in
accordance with the descriptions in Section 3.3.1, Message Wrapper Information of
AEP-84 Volume I and 2 respectively.
The next step is to strip out the formatted DLI message from the wrapper, which will
contain one of the messages. For AEP-84 Volume I the last step in the packet
synchronisation process is to calculate the checksum and compare it to the received
checksum. If the checksums do not match the packet is discarded. If the checksums
match, then the formatted DLI message is passed to the decoding process. For AEP84 Volume II this step is optional.
The packet synchroniser only forwards valid DLI messages to the Decoder process.
Elements of the message wrapper structure, such as the Message Properties, are
forwarded with the DLI message to the Decoder Process as this information may be
required for acknowledges, display of warnings, etc.
22
Edition A Version 1
AEP-84.1
3.2.1.1.2 Decoding and Storage of DLI Message Elements
The decoder parses the DLI messages in accordance with the defined common
message formats provided in Chapter 4 of AEP-84 Volumes 1 and 2 respectively. The
AEP-84 Volumes require that metric (SI, ISO 1000:1992) units are to be used unless
otherwise indicated by the messages. Therefore, conversion to SI should be
conducted as required. This will assist in the avoidance of potential system errors.
It is recommended that each of the received message data elements be placed into
memory individually for potential use by application processes loaded on the CUCS.
This method will assist in compliance testing of the CUCS as defined in the SRD Allied
Engineering Publication (AEP) – 84.2: STANAG 4586 Validation/Test Guideline
Document.
3.2.1.2 Message Acknowledgement
It is recommended that the decoder process implement the capability for message
acknowledgement. When “message acknowledgement” is requested in the Message
Properties element of the Message wrapper the decoder sends the required
information to the Message Encoding System (Section 3.3.2.1.2) for the transmission
of a Message Acknowledgement Message (Message #1400 for AEP-84 Volume I;
Message 17000 for AEP-84 Volume II). For additional details on identifying which
messages require an acknowledgement and on sending message acknowledgements,
refer to the Message Implementation sections, Annex 3 and 4 respectively of this
document.
3.2.1.3 Display/Use of Data Elements
The CUCS provides the “generic” user interface for the UAS. It provides all the
processing required to display system status and to execute “generic” control over the
UA through the VSM. In order to achieve this, the following capabilities need to be
available on the CUCS:








Generic vehicle control process
Map display interface
Warning display system
Payload control process
Payload video display system
Mission selection and loading capability
Generic data link control
CUCS vehicle specific mechanisms
Based on the testing philosophy detailed in the SRD Allied Engineering Publication
(AEP) – 84.2: STANAG 4586 Validation/Test Guideline Document, in order to achieve
Component Compliance Testing, there must be access to all implemented message
data elements of the DLI message set. This philosophy demands a user interface
implementation that provides access to all DLI message data elements.
System Level Compliance Interoperability Testing follows Compliance Testing and
verifies that the correct functionality within the UAS is being achieved, and DLI data
elements that are not required by a specific system are hidden from the user. Based
on this philosophy, the capability to provide a reconfigurable user interface is
recommended. However, these user interfaces must remain as static as possible
between vehicles controlled by a CUCS to achieve consistency between UASs.
23
Edition A Version 1
AEP-84.1
The recommendations presented for the use and display of the DLI message data
elements is based on the Compliance Testing philosophy, where all data elements
must be accessible to the user, and upon the capability to configure the interface to
achieve interoperability.
3.2.1.3.1 Generic Vehicle Control Process
The STANAG 4586 concept calls for a certain level of generic control from the CUCS,
with the detailed specific vehicle control being provided by the VSM. The operator
requires sufficient controls and displays at the CUCS to safely control and monitor the
vehicle systems that require monitoring or user input, and the operator must be able
to conduct a mission.
In the development of a generic vehicle control panel there are flight critical displays
and controls that should be placed on the main panel and available at all times. The
pre-flight (set-up) data elements should be placed on separate dialogs that will be out
of the way during flight operations. Complex tasks should be dealt with on the ground
if possible. An example is the handover capability. The handover set-up tasks, such
as frequency configurations, are recommended to be separated from the actual
handover commands. It is recommended that the DLI messages grouped in Chapter
4 of the respective AEP-84 Volumes, as System ID Messages and Flight Vehicle
Command and Status Messages be implemented in the CUCS UA control panel for
the purpose of user display and control.
As many vehicles are supported, parameters used by the majority of vehicles are
recommended to be grouped together, and the others are set aside to reduce clutter.
During Interoperability System Level Compliance Testing this allows parameters to be
removed (hidden) without altering the look and feel of the dialogs.
For different vehicles within a specific CUCS implementation, it is recommended that
a control and status display element for a specified AEP-84 data element, where
applicable, be placed in the same location on a panel, or within a dialog of the User
Interface, for different vehicles within a specific CUCS implementation. This will allow
an operator to easily transition from one type of vehicle to the next without significant
training issues, as the look and feel of the panels will be maintained as much as
possible across vehicle types.
3.2.1.3.2 Map Display Interface
A map component is available on the CUCS, and it is recommended that the following
components be available for display on the map:










Change of coordinate systems/datums
Point navigation through selection on the map – feedback for
demand/reported on map
Scalable map
De-clutter map
CDT location on map
UA location on map – with possibly tail number, UA speed, altitude,
fuel level
UA trail
Mission plan display
Payload footprint
Data link loss for UA
24
Edition A Version 1
AEP-84.1

Import maps
3.2.1.3.3 Warning Display System
The CUCS requires a method to display warnings received from the VSM to the user.
It is recommended that a warning display system be implemented on the CUCS using
the Subsystem Status Alert Message (Message #1100 for AEP-84 Volume I; Message
#16000 for AEP-84 Volume II) and the Subsystem Status Detail Request (Message
#1001 for AEP-84 Volume I; Message #15001 for AEP-84 Volume II). The Subsystem
Status Alert Message is sourced at the VSM as required, and the CUCS can request
additional information on a received alert using the Subsystem Status Request
Message. Refer to the Message Implementation sections (Section 3.2.1 and 3.3.2.1)
of this document for additional details.
VSM
Warning
Detection
System
Msg #1100/#16000
Msg #1001/#15001
Warning
Warning
Encoder Display
Panel
Server
Figure 7: Warning System
The Warning system, as shown above in Figure 7, provides the operator with the
capability to display, track and log warning messages. The operator is provided with
the capability to acknowledge and cancel warnings in accordance with the message
protocol. When a warning is received by the CUCS, it is to be displayed in the
operator’s primary view and not obscured by other elements.
A potential Warning Display is shown below in Figure 8.
Figure 8: Warning Display
3.2.1.3.4 Payload Control Process
The STANAG provides the capability to control a variety of payloads from the CUCS.
The user interface has to provide the capability to select a payload for control, and then
provide sufficient controls and displays to control and monitor the payload.
The sensor control panel contains the controls and displays for the near real time
control of the payload, while configuration and set-up items are contained in dialogs.
The dialogs provide for the implementation of a number of payload status messages
as contained in the DLI message set. A specific payload is selected, and only the data
elements that are relevant to the selected payload are displayed to the operator. To
fulfil the requirements of Compliance Testing, it is recommended the payload dialogs
25
Edition A Version 1
AEP-84.1
provide access to all the payload types and their associated message parameters as
implemented for the CUCS under verification, at the specified LOI.
To meet the requirements of Interoperability System Level Compliance Testing, the
payload status dialogs are configured from the data received from the VSM, via the
Payload Configuration Message and the various other configuration messages with
the dialogs being configured to the specific system’s payloads, not just for a generic
payload. For example, the limits and ranges in the dialogs are bounded to the range
of the specific payload and do not span the entire STANAG 4586 range of values.
3.2.1.3.5 Payload Video Display System
A payload imagery display system is required to be a component of the CUCS, and
should display the image received from the payload in the correct format for the
operator.
3.2.1.3.6 Mission Planning Capability
Mission Planning capabilities identified in the STANAG include the ability to validate
and review missions, and to be able to modify existing missions any time before and
during a flight. The Mission Planning capability may be a capability integrated into the
CUCS, or it may be a separate application loaded onto the CUCS or a standalone
computer. The CUCS must be able to correctly read missions created by the Mission
Planning capability associated with the CUCS.
3.2.1.3.7 Generic Data Link Control Process
A set of Data Link Messages to control a generic STANAG 7085 data link are identified
in Chapter 4 of AEP-84 Volume I and Volume II respectively.
It is recommended that the Data Link Messages be implemented as a set, as outlined
in the Message Implementation sections in Annex 3 and 4 of this document, for the
control of the data link and radio equipment.
The Data Link Transition Messages are used to coordinate the transition of control of
one data link to another for the UA.
3.2.1.3.8 CUCS Vehicle Specific Mechanisms
The CUCS is required to display non-generic information related to the UA
configuration, status monitoring and control as prepared by the VSM, through a vehicle
specific mechanism. The CUCS will control the display of vehicle specific windows on
its displays.
To achieve this capability, the CUCS is required to contain all of the vehicle specific
services identified by the STANAG at the minimum identified revision level or higher.
The VSM will transmit the vehicle specific windows using the identified services at the
identified revision level or lower. This will ensure compatibility between the two
systems. (Note: it is assumed all services will be backward compatible at higher
revision levels.) This guide recommends the initial creation of the generic interface,
and then the CUCS transmits the CUCS Resource Report Message (Message #1202
for AEP-84 Volume1 and Message #4201 for AEP-84 Volume II) to identify to the VSM
how it is to transmit the vehicle specific windows (remote displays) to the CUCS.
3.2.1.4 Transmission of STANAG 4586 DLI Messages
In order to execute control over and request status from the VSM, the CUCS must be
capable of creating the required DLI messages and transmitting them to the VSM.
26
Edition A Version 1
AEP-84.1
Figure 9 depicts a possible methodology for the implementation of a DLI message
transmission system.
CUCS
App’s
Memory
Packet
Stream
Msg Ack
Data
Elements Encoder
DLI
Msg
Message System
Wrapped
I/O
Messages System
Figure 9: CUCS Message Transmission
The CUCS must be capable of creating the DLI messages that are identified in AEP84 as the “source” being the CUCS. The CUCS must be capable of creating all the
DLI messages associated with its stated operational LOI.
3.2.1.4.1 Buffer Data for Transmission
Once the data elements have been prepared by the CUCS, they are placed in a
memory structure or equivalent temporary storage system. The data elements in this
memory structure are for the creation of DLI messages that are sourced by the CUCS.
CUCS applications have the capability to write to relevant data elements within the
memory structure. Data elements are populated ensuring that the “data intent” of each
of the data elements is maintained in accordance with the Message Implementation
sections in Annex 3 and 4 of this document.
A range checking capability may be added to the data storage system to ensure that
data elements do not exceed their allowable ranges. This is best to occur before the
data elements are encoded into their respective DLI message components.
The generic messages are then composed based on their intended usage in
accordance with the message descriptions provided in the Message Implementation
section in Annex 3 and 4 of this document.
3.2.1.4.2 Encode STANAG 4586 DLI Messages
An encoder process is used to create the formatted DLI messages for transmission to
the VSM. There are various methods through which the creation and subsequent
transmission of a DLI message may be initiated from the encoder. These methods are
as follows:



Memory monitor (changes in memory)
Scheduled transmission
Pulled messages
The method for initiating the creation of a DLI message is dependent on the message
to be transmitted. A recommendation for when each of the formatted DLI messages
should be transmitted from the CUCS is included within the Message Implementation
sections in Annex 3 and 4 respectively, of this document.
27
Edition A Version 1
AEP-84.1
The transmission of “Pulled Messages” is conducted after the reception of a request
for a specified message. This can be related to the CUCS responding to a query from
the VSM. A Message Acknowledgement is sent through this mechanism for a
message requiring an acknowledgement from the CUCS.
The transmission of “Scheduled Messages” is conducted based on a communications
schedule. There is no defined communications schedule for the transmission of DLI
messages, as the schedule would be dependent on the UA under control. If a
communications schedule is required to be used as the method of initiating the creation
and transmission of DLI messages from the VSM to the CUCS, the STANAG 4586
provides the capability for a CUCS to create a schedule using the Schedule Message
Update Command (Message #1402 for AEP-84 Volume I; Message #17001 for AEP84 Volume II). This message requests that a specified message be sent at the given
frequency. The effect of this message is to make the requested message a “push” type
message eliminating the need to request each pull individually.
The transmission of DLI messages through “Memory Monitored” values is
accomplished by a process in the encoder monitoring specified values in memory, and
initiating the creation of messages based on changes in these parameters. An
example of this is a Vehicle Operating Mode Command Message being transmitted
based on a data element’s value changing in memory, which represents a change in
demand from a User Interface.
The encoder creates the required formatted DLI messages in the format defined in
AEP-84 Volumes 1 and 2 respectively. The data element values are filled in from the
memory structure described previously.
3.3 VSM Interface
In accordance with the STANAG, the VSM is responsible for the following functions:

Managing real-time control interactions with the UA(s)

Translating data from the representation used by the core (DLI) to
vehicle specific representations and vice versa

Acting as a repository and server for vehicle-specific data (such as
vehicle configuration and performance limitations) and methods
(such as routines for updating vehicle-specific operator displays)

Packing and unpacking data link data to optimise transmission
bandwidth when necessary

Managing interfaces required to control and monitor data link(s)
operation

Parsing the data link data to present UA payload data to a NATO
Intelligence,
Surveillance
and
Reconnaissance
(ISR)
Interoperability Architecture (NIIA) compliant ground exploitation
system as specified by STANAG 7085

Providing any real-time display requirements in the UCS, as no
real-time functions are to be allocated to the CUCS
The first two functions above can be allocated to the UA, but due to data link bandwidth
and other issues as identified in Section 3.1.1 above, the other VSM functions should
be allocated to a “ground” VSM element.
28
Edition A Version 1
AEP-84.1
3.3.1 VSM Architecture
The software architecture and configuration required for the VSM is dependent on the
physical location of the VSM. The following are potential configurations for the VSM:



Located on the same machine as the CUCS
Located on a different machine from the CUCS on the ground
Located on the UA and on the ground (CDT) (i.e., Split VSM)
o Real time UA functions and message translation (if the UA does
not “speak” DLI) allocated to the UA VSM
The architecture and software composition of the VSM may be exactly the same in a
system where the VSM is located on the ground, whether or not it resides on the same
machine as the CUCS. If the VSM is located on the UA, then there normally will be a
requirement for a split VSM dependent on the requirement for controlling the CDT
being used in the system.
VSM development is dependent on whether the VSM is being developed as a new
software component, or if it is an existing organic control station being modified for use
as a VSM. The following recommendations for development are only provided as
examples to show where the STANAG message system would fit into a VSM, and it is
understood there are many potential solutions.
3.3.1.1 Purpose Built VSM – Vehicle Native Protocol
A VSM developed specifically to communicate using the STANAG 4586 DLI protocol
with the UA’s native protocol being transmitted to the vehicle contains the following
components:





Vehicle native protocol message system
Control applications
Vehicle ICD/STANAG DLI message translator
Vehicle specific/remote displays
STANAG 4586 message system
A VSM developed in this configuration would reside as a ground component of the
UCS system. Figure 10 depicts the VSM communication flow between the CUCS and
the UA.
VSM
UAV
Control
Apps
Vehicle ICD/ STANAG DLI
STAN AG
Msg
Translator
System
Remote
Displays
DLI
Msg
CUCS
Remote
Displays
Figure 10: VSM Communication Flow (Configuration One)
The control applications on the VSM provide the functionality required to control the
UA, and transmit/receive the UA native messages at the required frequency. The
29
Edition A Version 1
AEP-84.1
control applications are responsible for the “complete” control of the UA, and as such
this is the process where the VSM sub-divides the UA functionality into generic
(STANAG 4586) functionality and vehicle specific (remote display) functionality.
Where possible, the UA native control elements must be converted to STANAG 4586
for the provision of a generic control capability. Therefore, using this architecture, the
control applications are required to perform the required data conversions from UA
native protocol to STANAG and vice versa, perform any required unit conversions, and
perform any other specific conversions or translations required to effectively control
the UA from the generic interface.
The VSM must be capable of communicating across the DLI interface; therefore it
contains a DLI Message Tx/Rx system.
The remote displays provide for the status monitoring and control functionality over
and above the generic STANAG 4586 defined capability. Refer to the VSM
Implementation sections in Annex 3 and 4 of this document for further implementation
details.
3.3.1.2 Purpose Built VSM - STANAG 4586 Protocol
A VSM developed specifically to communicate using the STANAG 4586 DLI protocol
being transmitted between the CUCS and the UA contains the following components:



Control applications
Vehicle specific/Remote displays
STANAG 4586 Message System
A VSM developed in this configuration would reside, in part, as a component of the UA
in the UCS system.
UAV
VSM GND Component
Remote Displays
Avionics
STANAG Msg
System
STANAG
Msg
System
AV Pass
Through
Data Link
Control
CUCS
STANAG
Msg
System
Figure 11: Communication Flow (Configuration Two)
In the configuration depicted in Figure 11 above, part of the VSM would be a
component of the UA and therefore incorporated into the avionics. The CUCS would
communicate directly to the UA using the STANAG 4586 protocol.
The control applications are responsible for the “complete” control of the UA, and as
such this is the process where the VSM sub-divides the UA functionality into generic
(STANAG 4586) functionality and vehicle specific (remote display) functionality. The
VSM must be capable of communicating using the DLI message sets.
The remote displays provide for the status monitoring and control functionality over
and above the generic STANAG 4586 defined capability. This architecture is
considered for an UA capable of being controlled through the use of the generic
message set. Refer to the VSM Implementation sections in Annex 3 and 4 of this
30
Edition A Version 1
AEP-84.1
document for further implementation details. Using this configuration requires the
division of the VSM into “two” components, as there will still be a ground component
of the VSM required to control the CDT/data link. The ground component of the VSM
would be required to strip out the formatted DLI messages associated with the status
monitoring and control of the CDT (data link) and pass the messages directed to the
vehicle without alteration. Refer to the Split VSM Operations section (Section 3.3.1.4)
of this document.
3.3.1.3 Modified Organic Control Station
A vehicle control station that is organic to an UA can be configured to become a VSM
in the STANAG 4586 context by providing an interface to a CUCS. A VSM
manufacturer taking this approach may consider the following as a potential
implementation as depicted in Figure 12.
VSM
UAV
Organic
Control
Station
Protocol
Translator
STANAG
Data
Elements
STANAG DLI
Msg Tx/Rx
System
DLI
Msg
CUCS
Interface
Application
Figure 12: Potential VSM Implementation
In this approach, the VSM contains a mechanism to convert the vehicle specific
protocol to the STANAG 4586 DLI message elements. This software component may
be considered a protocol translator. This can be accomplished by creating the crossreference between the STANAG DLI message elements and the vehicle specific ICD
data element as specified in the Message Implementation sections in Annex 3 and 4
of this document. The protocol translator is used to translate CUCS commands to
vehicle commands at the organic control station, and conversely to translate vehicle
specific status elements to STANAG for transmission to the CUCS for operator display.
The translator ensures data elements on both sides of the interface remain current. All
the generic messages that can be supported by the UAS data elements must be
supported.
The remote displays are used to provide for the status monitoring and control
functionality over and above the generic STANAG 4586 defined capability. Refer to
the VSM Implementation sections in Annex 3 and 4 of this document for further
implementation details.
The Interface Applications provide the link between the generic and vehicle specific
components of the system. The Interface Application also provides the mechanism to
handle the additional system requirements such as the system warnings, and for the
remote display/control of vehicle specific dialogs and control panels.
The storage mechanism and message transmission/reception mechanisms remain as
described previously.
3.3.1.4 SPLIT VSM OPERATIONS
As identified in a number of preceding sections of this document, the VSM “translation”
function may reside on the UA or it may not be required because the UA “speaks DLI”.
In this instance, there will still be a requirement for the control and monitoring of the
31
Edition A Version 1
AEP-84.1
UCS data link on the UA, the VDT. A “ground based, data link control” VSM can provide
this capability.
Under Split operations, there is a potential impact to running TCP over wireless/ tactical
links. The performance of TCP/IP over a wireless link could be poor, with the potential
for reduced throughput in some conditions. One recommendation to solve potential
TCP/IP performance issues over a wireless data link would be to use Space
Communications Protocol Standards (SCPS) over the wireless portion of the link. The
SCPS defines a set of revisions to the Internet protocols to enable them to operate
effectively over wireless (satellite) connections. Many of the characteristics of satellite
links are also inherent in terrestrial wireless communications, and the secondary
design goal of SCPS was to improve the performance of wireless links in military
tactical environments. The goal of the SCPS project is to provide a suite of standard
data handling protocols which (from a user viewpoint) allow a remote space vehicle to
appear to be just another "node on the Internet". With SCPS, the bandwidth of an
existing link is utilized to a significantly higher efficiency. This translates directly to
faster data transfer and/or accommodating more connections (or customers) with the
existing link infrastructure. The SCPS advantage grows dramatically as link quality
decreases. The SCPS transport layer (SCPS-TP) is compatible with Internet
applications and the Internet itself. It can take the place of the TCP/IP stack in a
computer, or be deployed as a pair of gateways across a RF segment in a conventional
IP network. For further information on SCPS, implementers are directed to
http://www.scps.org. A second recommendation for the creation of remote displays in
a “split” VSM situation is the creation of the remote displays on the “ground component”
of the VSM, as this component is already required in the UCS system to control the
data link.
The VSM developer may develop a set of “private” formatted messages, in the
STANAG 4586 generic format, to be transmitted using the STANAG 4586 UDP/IP
channel. The airborne and ground components of the VSM, as a pair, would identify
the private messages being passed between them. The ground component of the
VSM would be required to convert the vehicle specific formatted messages into a
“remote services” format for the presentation of the remote displays at the CUCS.
3.3.1.5 VSM Display Capability
Some vehicle systems may require a real-time display/HCI connected directly to the
VSM during certain operations or flight modes. The VSM's function is to provide for
real-time vehicle requirements, or to provide any vehicle specific hardware required
(e.g., a non-standard data link). The STANAG 4586 architecture and VSM philosophy
makes provisions for a remote display/input capability to be connected to the VSM.
When implementing a VSM display capability, it is important to note that the STANAG
4586 architecture allows the VSM and CUCS to be located at different physical
locations, and not necessarily accessible by a single operator. Although some systems
may have co-located VSM and CUCS, system designers should account for the
possibility they are not co-located. If a VSM display capability is deemed necessary,
the system designers should also develop an operational profile assuming the VSM
and CUCS are in separate locations.
3.3.1.6 I/O System
The I/O System component specified in the proposed implementation varies
dependent on the physical location of the CUCS and VSM software components. It is
recommended that a client-server socket arrangement be used. The additional
requirements to run the CUCS and VSM software components on physically separate
32
Edition A Version 1
AEP-84.1
hardware are identified in the Software Interface Protocol section (Section 3.1.1) of this
document.
3.3.2
VSM DLI Implementation
The recommended VSM implementation reflects the proposed implementation of the
generic message set on the CUCS. The intention of the generic message set, from
the perspective of the VSM, is presented within the Message Implementation sections
in Annex 3 and 4 respectively of this document.
The VSM transmits STANAG 4586 DLI messages to a CUCS that have been packaged
in accordance with the STANAG message wrapper definition. Refer to the CUCS
Interface sections in Annex 3 and 4 for details of the recommended implementation.
3.3.2.1 Message Implementation
In the STANAG 4586 philosophy, the VSM provides the interface between the UA
system and the CUCS. The VSM also provides the interface between the CDT Data
Link system and the CUCS. The VSM must be capable of accepting all of the
messages included in the STANAG 4586 DLI message set, even if the messages are
not required in the specific implementation. The VSM does not have to act on all the
messages, however the messages should not cause any adverse effects on the
system. The VSM is only required to generate and transmit those DLI messages that
are relevant to the system for which it was developed.
3.3.2.1.1 Reception of STANAG 4586 DLI Messages
A VSM receives and transmits STANAG 4586 compliant DLI messages from/to a
CUCS. When these messages are received by the VSM it must be capable of the
following;





Receive messages
Decode messages
Store data
Process data
Present/Distribute data
3.3.2.1.1.1 Packet Synchronization
The VSM receives DLI messages, from a CUCS, that have been packaged in
accordance with the STANAG message wrapper definition. Refer to the corresponding
CUCS Implementation section for additional details. The CUCS/VSM integrator must
ensure that the correct IP address and port numbers are identified for the system as
described in the Software Interface Protocol section (Section 3.1.1) of this document.
It is recommended that the VSM use the same packet synchronisation process as the
CUCS implementation. Refer to CUCS Implementation section for details. Figure 13
is one implementation that could be used.
33
Edition A Version 1
AEP-84.1
Raw Data
Packet
Sync
Packets
Decoder
Data
Memory
Elements
Msg Ack
VSM
App’s
Figure 13: VSM Message Reception
3.3.2.1.1.2 Decoding and Storage of DLI Message Elements
The same Decoder and Storage process as used in the CUCS Implementation can be
implemented to parse the formatted STANAG messages that are received from the
packet synchronisation process. The storage process can be used to verify the validity
of the data received from the CUCS.
3.3.2.1.2 Message Acknowledgement
It is recommended that the Decoder process implement the capability for message
acknowledgement. When the VSM receives a “Msg Type” that requires an
acknowledgement, the decoder sends the required information to the Message
Encoding System for the transmission of a Message Acknowledgement Message
(Message #1400 for AEP-84 Volume I and Message #17000 for AEP-84 Volume II).
For additional details on sending message acknowledgements refer to the Message
Implementation sections in Annex 3 and 4 of this document.
3.3.2.1.3 Transmission of STANAG 4586 DLI Messages
The VSM must be capable of creating the required STANAG 4586 DLI messages and
transmitting them to the CUCS. The same methodology for the implementation of the
DLI message transmission system at the CUCS is recommended for the VSM. This is
illustrated in Figure 14.
VSM
App’s
Memory
Msg Ack
Data
Elements
Encoder
Packet
Stream
DLI
Message
Msg
System
Wrapped
Messages
I/O
System
Figure 14: VSM Message Transmission
The VSM is only required to create those messages, and support those data elements
within a message, that its associated UAS supports. Any unsupported data elements
must be filled in, in accordance with AEP-84 Volume I or 2, respectively, to indicate
they are unsupported by the system. The VSM is required to support all AEP-84
34
Edition A Version 1
AEP-84.1
Volume I or 2 data elements possible for the UAS. If there is a generic way to send
data from the VSM to the CUCS, then it must be used by the VSM.
3.3.2.1.4 Buffer Data for Transmission
Once the data elements have been prepared by the VSM, they are placed in a memory
structure or equivalent temporary storage system. The data elements in this memory
structure are used for the creation of DLI messages that are sourced by the VSM. Data
elements are populated, ensuring that the “data intent” of each of the data elements is
maintained in accordance with the Message Implementation sections of Annex 3 or 4
of this document.
3.3.2.1.5 Encode STANAG 4586 DLI Messages
An Encoder process is used to create the formatted DLI messages for transmission to
the CUCS. There are various methods through which the creation and subsequent
transmission of a DLI message may be initiated from the encoder. These methods are
as follows:



Memory monitor (changes in memory)
Scheduled transmission
Pulled messages
The method for initiating the creation of a DLI message is dependent on the message
to be transmitted. Recommendations for when specific DLI messages should be
transmitted from the VSM to the CUCS are provided in the Message Implementation
sections of Annex 3 or 4 of this document. Refer to the CUCS Implementation sections
for additional descriptions of the methods for the initiation of the transmission of the
DLI messages.
3.3.2.2 Display/use of STANAG Data Elements
The applications located on the VSM are provided to interface the CUCS to the UA for
the execution of the control functionality contained in the STANAG, and to provide the
required operator feedback to the CUCS. It is expected that the VSM causes the UA
to perform the functionality as commanded from the CUCS in a safe and accurate
manner. There is no requirement for the VSM manufacturer to display DLI message
content, except for verification of the correct reception of data elements during
Compliance Testing. The VSM is required to display vehicle specific data upon request
from the CUCS; however the VSM first identifies if there is vehicle specific information
available to the CUCS. Refer to the VSM Implementation sections of Annex 3 or 4 of
this document.
There are some recommended processes that the VSM should implement, in addition
to its vehicle control applications, to provide the STANAG functionality. The processes
include:



Warning Detection System
STANAG to vehicle data element translators
STANAG to vehicle specific mission converter
3.3.2.2.1 Vehicle Specific Mechanisms
In addition to the transmission and reception of STANAG 4586 DLI messages, the
VSM is required to provide HCI controls and status displays for vehicle specific
elements as illustrated in Figure 15 below. These are control and status display
elements that are not provided for by the generic STANAG 4586 DLI message set,
such as the take-off and landing capabilities of a UA. These VSM-driven HCI elements
35
Edition A Version 1
AEP-84.1
include display of data, which is not part of any standard "data" message sets, and
they allow an operator to interact with the UA directly through the VSM to select
options, modes of operation, and other vehicle-specific actions. These VSM elements
provide for all real time control requirements that are part of the UAS.
Generic Messages
VSM
Vehicle Specific
Displays – X11
CUCS
X-Server
Netscape
Vehicle Specific
Displays – HTML
Figure 15: Vehicle Specific Messaging
STANAG 4586 leaves the VSM designer quite a bit of flexibility for implementing the
vehicle specific portion. However, there are some significant limitations. Since there
is no requirement for the VSM to have its own dedicated display, all of the
windows/dialog boxes must appear on the CUCS displays. This is complicated by the
fact that the STANAG 4586 does not place any restrictions on what sort of computer
or operating system is used for the CUCS. The VSM designer is free to choose the
hardware and operating system for the VSM, with the goal that the VSM should operate
with all CUCS systems via an Ethernet connection.
AEP-84 Volumes 1 and 2 specify the “services” that must be made available to the
VSM by the CUCS, and the VSM designer must implement the vehicle specific displays
utilizing these services. The services that will be made available by every CUCS
include:



Web browser (such as Netscape)
X Server
Java Virtual Machine
Using X-Windows to “export” the windows from the software running on the VSM to
the displays connected to the CUCS is one method to provide remote display and
control over data elements only available at the VSM. Another method is to use HTTP.
An interface to a Tactical Automatic Landing System could be provided through one of
these services.
3.3.2.2.1.1 Vehicle Specific Data Elements
The vehicle specific data elements are those data elements contained in the vehicle
specific ICD that are not cross-referenced to AEP-84 Volume I or Volume II DLI
message data element. These data elements provide for any real time control and
display capabilities or functionalities additional to the generic control provided for by
the CUCS interface. As an example, an Auto-land System is considered vehicle
specific, therefore all the data elements associated with auto-land are included in this
category.
36
Edition A Version 1
AEP-84.1
3.3.2.2.1.2 Vehicle Specific Dialogs
The vehicle specific dialogs are VSM-driven HCI elements that are not included in the
generic message set. The dialogs allow an operator to interact with the UA directly to
select options, modes of operation, and other vehicle-specific actions. The vehicle
specific dialogs and control panels provide the functionality that is not accessible from
the generic dialogs and control panels.
There are various possibilities for the implementation of vehicle specific control panels
and dialogs, two possibilities are:


Organic Control Station displays
AEP-84 Volume I or Volume II tailored displays
3.3.2.2.2 Remote Display – Subsystem Detail Request
One of the methods of initiating the remote display of vehicle specific dialogs is through
the use of AEP-84 Volume I or Volume II “Subsystem State Report Reference” of the
Subsystem Status Detail Request Messages (Msg. #1001, Vol. 1; Msg. #15001, Vol.
2).
In the recommended implementation, the Warning Detection System as part of the
VSM is responsible for creating the Subsystem State Report Reference, which is a
field in the Subsystem Status Alert Message and the Subsystem Status Report
message. The VSM determines whether or not there is vehicle specific information
available for the specified message, and includes a reference in the message as
required. The CUCS may then request the additional information through the
Subsystem Status Detail Request (Message #1001, Vol.1; Message #15001, Vol.2)
from the VSM. When the VSM receives the request it pops up the requested dialog
for display on the CUCS. In the recommended implementation, the additional
information on warnings is requested through links on the Warning Display System
and the Master Caution panel of the CUCS.
The dialog is created by the VSM, and may be a vehicle specific dialog that is a
component part of the VSM. An example of this capability is the Warning Detection
System may link a Global Positioning System (GPS) Status dialog to a Loss of GPS
warning message. When the CUCS requests additional information on the Loss of
GPS warning, the VSM pops up the GPS Status dialog on the CUCS.
The dialog may be an information dialog specifically created by the VSM for the
specified warning. An example of this implementation for a Carburettor Icing warning
is to create an information dialog on the action to take to eliminate the problem. When
the CUCS requests the additional information on the warning the informational dialog
is displayed on the CUCS.
3.3.2.2.3 Organic Control Station Displays
A vehicle control station that is organic to a specific UA can be configured to provide a
remote display to a CUCS as depicted below in Figure 16.
37
Edition A Version 1
AEP-84.1
VSM
DLI
Msg
STANAG
Data
Elements
Protocol
Translator
STANAG DLI
Msg Tx/Rx
System
Interface
Application
CUCS
Vehicle
Specific
Figure 16: Configuration of Organic Control Station Display
The Interface Application provides the mechanism, such as X-windows or HTTP, to
remotely display dialogs and control panels on the CUCS displays. The VSM may
display organic panels on the CUCS through this mechanism, or the interface
application may create tailored vehicle specific control panels and dialogs. The
requirement for these control panels and dialogs is that they provide the functionality
additional to the generic displays. On connection of the CUCS to the VSM, the vehicle
specific control panels are displayed on the CUCS. Refer to Annex 3 or 4 of this
document for details on how to create an initial connection between a CUCS and a
VSM, and how to configure the CUCS displays for use with the connected VSM.
3.3.2.2.4 STANAG 4586 Tailored Displays
A VSM may be developed such that the vehicle specific control panels and dialogs are
tailored to compliment the STANAG generic displays and controls. Vehicle specific
data elements that are not cross-referenced to a generic data element are the only
elements included as part of these displays and controls. A vehicle specific control
panel is developed to complement each of the CUCS generic control panels:



UA control panel
Sensor control panel
CDT control panel
On connection of the CUCS to the VSM, these vehicle specific control panels are
displayed on the CUCS. The control panels provide the displays and controls required
for the flight operations of the UA, in addition to the generic panel, in a safe and
effective manner. Vehicle specific dialogs are accessed from the menus located on
these control panels.
The development of vehicle specific panels and dialogs should follow the methodology
identified for the creation of the generic panels and dialogs, in the consideration that
flight critical elements are separated from configuration elements.
An example of this implementation methodology is provided below in Figure 16 for the
IFF system.
38
Edition A Version 1
AEP-84.1
Figure 16: Generic IFF Dialog
The Generic IFF dialog, as accessed from the Generic UA control panel, would contain
all the functionality provided for by the generic DLI messages. The VSM IFF dialog
would then contain any additional IFF information as provided by the UAS for which
the VSM has been implemented. Figure 17 below is an example of a VSM IFF dialog
that would be complimentary to the Generic IFF dialog.
39
Edition A Version 1
AEP-84.1
Figure 17: VSM IFF Dialog
The same methodology would be applied to all the sub-systems within the UAS, to
include all the control panels.
3.4 Control Data Terminal (CDT) Interface
The goal of the STANAG 4586 is for the air borne components of the system; UA,
payloads, and Vehicle Data Terminal (VDT), to communicate using DLI messages as
their native control message set thus eliminating the requirement for an UA VSM on
the ground. This UA System configuration requires that the Control Data Terminal
(CDT) component communicate using DLI (or translate from DLI to its native protocol),
and pass through all the STANAG 4586 DLI messages intended for the UA, payloads,
and VDT. The CDT itself would respond to any control messages from the CUCS.
AEP-84 Volume I and 2 define STANAG 7085 as the compliant Data Link type, and
define a set of DLI messages for interfacing directly between a CUCS and a STANAG
7085 Data Link. It is also anticipated that the UA avionics will communicate with the
VDT using the same messages. Note that it is highly recommended that the UA control
its on-board VDT vice the CDT on the ground controlling the airborne VDT.
3.4.1 STANAG 7085 Ideal Interface
The following diagram shows the intended AEP-84 Volume I and Volume II UA
Configuration using sub-system representations.
40
Edition A Version 1
AEP-84.1
UA Type 1
UA Type 2
UA Type 3
CDT
Control
Station
Figure 18: UA System Configuration
The following diagram shows the intended STANAG 4586 UA Configuration in a more
detailed representation with the intended messaging:
Ground
Based
Vehicle
Based
D
CUCS
UA/
PAYLOAD
STANAG 4586 DLI
A
STANAG
4586 DLI
F
Application Layer
C
STANAG
4586 DLI
E
CDT
STANAG 7085
VDT
B
Data Terminal Layer
B
RF Link
Data Link Layer
Actual flow of data
Figure 19: UA Message Configuration
Interface A) The CUCS controls the CDT/UA/payload/VDT using AEP-84 Volume I or
Volume II messages.

CDT data link filters out messages intended for it (on the physical interface),
forwards all other messages through RF link (virtual Interface D).
41
Edition A Version 1
AEP-84.1
o
Requires that data link “filters” all messages to determine which
messages are intended for it in current multicast definition.
Interface B) STANAG 7085 RF Link passes (uplinks/downlinks) AEP-84 Volume I or
Volume II messages between the CUCS and UA.
Interface C) The VDT data link receives “AEP-84” messages (virtual interface D) over
RF link and passes them to the UA avionics.

The VDT transmits the VDT command messages from the CUCS to the UA
avionics (as received on the RF link from the CUCS), and then the UA
avionics controls the VDT accordingly via the physical link (Interface F).

The VDT transmits its status messages to the UA avionics, and the UA
avionics is in turn responsible for providing the status of the VDT to the
CUCS (i.e., the UA is fully responsible to the control and status of the VDT
subsystem).
Interface F) The UA avionics controls the VDT via the physical link, similar to the CUCS
controlling the CDT. UA avionics transmits UA, payload, and VDT status messages via
the VDT to the CUCS using 4586 messages via the RF downlink, and the VDT strips
out VDT command messages from the UA (i.e., VDT filters out messages intended for
it, forwards all other messages through RF link (virtual Interface D).

Requires that data link “filters” all messages to determine which messages
are intended for it – since the VDT is dedicated to the UA there could be a
dedicated command and control interface between the UA avionics and the
VDT.
Interface G) The CDT data link terminal receives “AEP-84” messages (virtual interface
D) over RF link and passes them all to the CUCS

CDT data link terminal transmits CDT status messages to the CUCS
The Data Terminal interface from STANAG 7085 compliant data links to AEP-84
Volume I or Volume II are based on the requirements of the STANAG 7085
Implementation Specific Data Link Specification and Section 3.2 of Annex B Part 1 of
STANAG 7085.
3.4.2 STANAG 7085 Compliant Data Links Behind a VSM
In this configuration, all message traffic between the CUCS and the VSM is on the
common multicast interface, and the VSM may or may not control the CDT datalinks
on a different channel/port than the UA/payload DLI interface, although the data link
will be using AEP-84 Volume I messages for control and status of the data link. A dual
VSM/STANAG 7085 interface would mean that the STANAG 7085 data link terminal
would not require the filtering capability of the ideal implementation where the STANAG
7085 compliant unit communicates directly to the CUCS, not having to distinguish the
DLI messages intended for the terminal vice the UA. Note, in this configuration, a
proprietary protocol is most likely being transmitted across the STANAG 7085 RF
channel.
42
Edition A Version 1
AEP-84.1
Ground
Based
Vehicle
Based
CUCS
STANAG
4586 DLI
Application Layer
VSM
Data Link
Control
UA/
PAYLOAD
Proprietary
VDT
Control
UA/Payload
VDT Control
CDT
STANAG 7085
UA/Payload
VDT Status
Data Terminal Layer
VDT
RF Link
Data Link Layer
Actual flow of data
Figure 20: Data Link Messaging
If the STANAG 7085 data link is shared between STANAG 4586-specific message
exchanges and ISR payload data (typically to STANAG 7023 and 4609 formats), the
VSM will support the arbitration and interfacing to allow compatibility with both
STANAG 4586 and ISR payload data.
Figure 22 shows a possible UCS configuration where two different UA systems share
a common CDT. An example where this might occur is on-board a ship, where the
limited data link resources are shared among many systems. In this case, the DLI
messages transmitted from the CUCS to VSM A and VSM B address the same Data
Link ID. The Vehicle ID contained in the received message is used by VSM A and
VSM B to identify to whom the message is addressed. Only the VSM associated with
the identified UA would respond as required to the received DLI message.
DLI
VSM A
CUCS
Data Link Protocol
CDT
VSM B
43
Edition A Version 1
AEP-84.1
Figure 21: A Possible Data Link Configuration
The system configuration will determine whether or not two VSMs are capable of
concurrently controlling a single CDT, potentially through a routing system. If a data
link is only capable of being configured to a single configuration, which may not be
compatible for the different vehicles being controlled through the data link, this will limit
control to a single VSM at a time. The connectivity between VSMs and a shared data
link resource is the responsibility of the system administrator/integrator, and is limited
to the system’s design. Management of a shared data link resource is outside the
scope of this STANAG.
3.4.3 STANAG 7085 Non-Compliant Data Links
The CDT interface from STANAG 7085 non-compliant data links to UCS are based on
the requirements of the specific data link specification chosen. When such a data link
is used, the VSM provides the interface and message translation between the DLI and
the data link.
3.4.4 Launch and Recovery Interface
This section of the document specifically defines the interaction of LOI 5, Launch and
Recovery, activities with the generic capabilities of the CUCS. The formatted DLI
message set provides a generic capability for the initiation of the launch and recovery
sequences, and provides the operator with the capability to abort a recovery sequence.
The majority of the launch and recovery requirements for an UA are vehicle specific
and must be handled through the vehicle specific mechanism or through direct
interaction with the VSM if real time interactions are required with the UA.
The CUCS generic control requires a “high level” flight capability, which in this instance
can be conducted at the VSM where the UA does not have an advanced high level
flight control. The CUCS commands “outer loop” parameter such as heading,
airspeed, altitude, flight modes and waypoint values.
The VSM developer is responsible for all the connections between the required launch
and recovery equipment and the VSM hardware, and the interface between this
equipment and the UA. Figure 22 below depicts a representative Launch and
Recovery system.
Launch/
Recovery
Equipment
Ranging
Transponder
UA
HCI
CUCS
DLI
VSM
CDT
CCI
44
Edition A Version 1
AEP-84.1
Figure 22: Launch/Recovery System
3.4.4.1 Launch System Integration to CUCS
There are usually a number of steps required in the preparation of an UA for launch.
These configuration or set-up requirements are in most instances vehicle specific and
not real time in nature. Therefore it is recommended this activity be conducted through
the remote display mechanism implemented on the VSM.
On the CUCS there is a generic vehicle control panel, and it is anticipated that most
vehicles will have some sort of vehicle specific control panel for functionality that is not
contained in the generic message set. It is recommended that the launch
configuration/set-up functionality for the vehicle be initiated from the vehicle specific
panel. The following items may be included as part of the set-up as they are not
incorporated into the generic message set:




Launch configuration
o Vehicle mass
o Magnetic variation
o Navigation system initialisations
o UA identification
Launch site
o Launch point – absolute or relative
o Release point – absolute or relative
Reversionary point
o Point or pattern
o Conditions for reversion
Checklist
o Launch preparation
o Pre-launch conditions
From the above listing it is noted again that the set-up and configuration of the UA for
launch is a vehicle specific requirement. Once the vehicle has been prepared for
launch, it is recommended that the VSM notify the CUCS by enabling the “launch”
mode at the CUCS.
It is recommended that the UA launch be initiated using the generic launch mode as
identified in formatted DLI Message #49 in AEP-84 Volume I or Message #2016 in
AEP-84 Volume II. In many instances all that is required to launch an UA is the push
of a button, however the launch command from the CUCS could cause the enabling of
the launch functionality at the VSM. This implementation methodology defines UA
control as always being from the CUCS in terms of initiating the functionality of the UA.
Once the vehicle has been launched, the VSM is responsible for the safe operation of
the UA. The VSM passes control to the CUCS, allowing access to other flight modes,
once the UA has achieved the release point.
3.4.4.2 Recovery System Integration to CUCS
There are usually a number of steps required to prepare an UA for recovery, and
sometimes these preparations are required before the UA is launched. Similar to the
launch interface, these configuration or set-up requirements are most likely UA specific
and not real time in nature. It is recommended the recovery set-up activities be
conducted through the remote display mechanism implemented on the VSM.
45
Edition A Version 1
AEP-84.1
On the CUCS there is a generic vehicle control panel, and it is anticipated that most
UA will have some sort of vehicle specific control panel for functionality that is not
contained in the generic message set. It is recommended that the recovery
configuration/set-up functionality for the UA be initiated from the vehicle specific panel.
The following items may be included as part of the set-up as they are not incorporated
into the generic message set:

Recovery configuration
o Recovery/acquisition – point/pattern – relative/absolute
o Touch down/landing point – relative/absolute
o Wave-off/abort requirements
Checklist
o Recovery preparation
o Pre-recovery conditions

The recovery set-up and configuration is preformed from the VSM, and once all
conditions for the recovery of the UA have been met, the VSM indicates this condition
to the CUCS by providing access to the “autoland engage” mode.
It is recommended that the recovery of the UA be initiated from the CUCS through the
selection of the “autoland engage” flight mode, through formatted DLI Message #49 in
AEP-84 Volume I or Message #2016 in AEP-84 Volume II. Selection of this mode of
operation will then initiate the vehicle specific displays required to conduct the recovery
of the UA. The recovery of the UA becomes the responsibility of the VSM for the
purpose of real-time control operations.
During the recovery operation, the vehicle specific displays may provide the capability
to abort the recovery. The generic formatted DLI message set also provides the
capability to send an abort message to the VSM through Message #49. It is
recommended that the VSM implement this capability to provide an overall command
capability from the CUCS.
Once the UA has been successfully recovered, control of the UA is passed back from
the VSM to the CUCS based on post-recovery requirements.
3.5 Video Interface
Implementation of the video streams in the UA systems is directly influenced by their
intended use, which itself may be a function of the LOI:

At LOI 2, video via the CDT, like other sensor data, will interface via
the generic NIIA and AEP-84 Volume I or Volume II specified
standards. This will support network-centric dissemination of this
data. For example, future systems must follow STANAG 4609 for
motion imagery. Other examples include STANAG 4607 for GMTI,
STANAG 7023 for primary imagery and STANAG 4545 for single
frame, annotated imagery. Time and metadata (geo-spatial,
environment, etc.) will be closely tied, as upstream as possible, to
the video. If loss of information content due to the compression is
significant, on-board recording of uncompressed, or less
compressed, digital video may be considered. All the above is also
applicable if the platform generates multiple video streams.

In addition at LOI 3, the participating UCS must be able to control
the payload(s), using the received video. In that case, the maximum
46
Edition A Version 1
AEP-84.1
latency compatible with real-time control does not exceed 300
milliseconds. The near-real-time payload control in this case should
be accomplished via the VSM since all-time critical functions are
allocated to the VSM. Two independent streams, one for collection
and one for control, using the same source, but with different
compression schemes, can be considered if required. This
requirement concerns only the control of a video payload as mission
payload and not as a video payload used for "see/sense & avoid"
functionalities. If the system latency constraints are not satisfied by
STANAG 4609 and the extensive use of MPEG-2-based
compression technique, interoperability may exclude certain modes
of use for some end-users. Latency requirements may also be
satisfied through special implementations which are based on other
techniques (JPEG-2000, M-JPEG-2000,) or through either a VSM
solution on a case-by-case basis, or a STANAG 7023
implementation (using for instance JPEG-2000 technique).
It must be noted that all the above are based on digital files, which can be transmitted
using whatever protocol is available. It is a VSM’s responsibility to adopt appropriate
means to achieve latency and quality of service compatible with the intended use.
In order to facilitate interoperability between various CUCS and VSMs however, the
following protocols should be used for transmitting digital sensor data between a VSM
and CUCS via a physical interface separate from the DLI, and between a CUCS and
external C4I systems via CCI:
3.5.1
I/O Protocols
I/O protocols may be:




Ground Motion Target Indicator Format (GMTIF), STANAG
4607
o
Transport Protocol – UDP
o
Network Protocol – IP
Motion Imagery, STANAG 4609
o
Transport Protocol – UDP
o
Network Protocol – IP
Still Frame, Annotated Imagery, STANAG 4545
o
Transport Protocol – TCP
o
Network Protocol – IP
Primary Imagery, STANAG 7023
o Transport Protocol - UDP
o
Network Protocol – IP
3.6 Audio Interface
Audio in UA systems may be:

Payload voice data: such voice data is the basic data for certain
payloads (COMINT, loudspeakers, etc.)
47
Edition A Version 1
AEP-84.1

Voice comment data about the mission: this type of voice data is
issued by a Ground Operator located somewhere in the ISR/RISTA
chain, depending on the LOI (LOI 2 and 3). Most of the time this
Operator is the one who interprets the images in near real time,
possibly off-line, in which case the comments will be written as
metadata associated to a frozen image (still frame). Whenever
possible, provisions of STANAG 4609 will be used.

Air Traffic Control (ATC) voice dialogue is restricted to the "UA Pilotin-Command" and the Air Traffic Controller. ATC voice exchanges
have to comply with latency constraints as defined by competent
authorities (CAA, DGAC, FAA, etc.), which are typically around 250
milliseconds end-to-end (per RTCA DO-225).
3.6.1 Voice Over IP
While flying in Air Space Control, UA will need to communicate with ATC. ATC will not
wish to use specific procedures to communicate with UA, beyond those used for
manned aircraft, thus any transmissions between the UA operator and ATC will need
to be:

On ATC compatible radios and frequencies

May require Communication to be via the UA, as though the operator
were on the aircraft as shown in Figure 23 below.
ATC link
Data Link
ATC
Control Station
Figure 23: ATC/UCS Communication
The UA operator in some systems may wish to relay voice beyond the range on ground
based radios using the UA.
In either case, voice communication may be required over the data link. However,
RTCA requirements state that relayed voice between the ATC and the operator should
be less than 250 ms and therefore voice over the data link is seen as a real-time
function, and as such should be handled by the VSM.
The ITU H.323 standard for voice over IP is based on TCP and hence may prove
problematical in some data link applications. Therefore, the recommended method of
voice communication over the data link is to use the audio channel specified in
STANAG 708A4.1.2. Although voice over the DLI is not a requirement in STANAG
4586, this does not preclude its use in the CUCS nor does it preclude a dedicated
voice link between the VSM and the CCISM.
3.7 Use of Referenced Protocols and Standards
3.7.1 Use of Protocols and Standards
Protocols and standards, which are mandatory for UCS, can be found in STANAG
4586. However, always refer to the latest edition of Volume 4 of the NCIA (NC3
Common Standards Profile (NCSP) for the current version of the specifications,
48
Edition A Version 1
AEP-84.1
protocols, and standards. Specifications and usage of other standards, if required
beyond those identified here and in the NCSP, must be additive, complementary, and
non-conflicting with NCSP mandated standards.
Emerging standards are standards required to capitalize on new technologies. It is
expected that emerging standards will be elevated to mandatory status when
implementations of the standards mature, and national consensus is reached. These
standards will then be incorporated into the next edition of STANAG 4586.
3.7.2 Implementation of Cited STANAGS
When adopting the standards listed as required in STANAG 4586, the manufacturer is
responsible for obtaining and implementing the most current version of the STANAGs.
The current version can be obtained from the Custodian of the STANAG in question.
3.8 Network Configuration
As defined in AEP-84 Volumes 1 and 2, by default, the DLI messages are to be
transmitted through a port configured for communications using UDP multicast. UDP
multicast enables multiple processes (VSMs, data links and CUCSs) to communicate
with each other on a single common IP address and port number. The setup of
networks to use multicast is an administrative procedure not defined by this document
with only a brief statement of the issues noted below. Again, as specified in the AEP84 Volumes 1 and 2, a single IP address and port is designated for multicast of the
generic DLI messages sent from every CUCS and a second IP address and port is
designated for multicast of generic DLI messages from every VSM.
UDP multicast allows for the Discovery/ Connection mechanism, defined in following
sections, by providing the CUCS with a mechanism for discovering any VSM, UA,
payload and data link connected to the network without all those components (VSM/
UA/ data link) first having to separately register on the network. Currently, the
Discovery/Connection mechanism process assumes that all the UCS components are
located on the same subnet of the network, as UDP multicast and broadcast messages
are not passed through a router unless the router is specifically configured to forward
multicasts. Setting up router tables for port forwarding across multiple routers is
beyond the scope of this document.
49
Edition A Version 1
AEP-84.1
Mini
STANAG
7085
Modem
Figure 24: Networking Configuration Example
In the figure above, the STANAG 7085 data link unit is a routing device, with two
Ethernet ports and one CDL RF data link. The STANAG 7085 data link unit is capable
of routing network traffic onto the two Ethernet ports. The diagram shows three subnetworks. The PCs behind the switch on eth1 are on one subnet; the PC on eth0 is
on a second subnet and the UA is on a third subnet. For the PCs on the eth1 subnet,
multicast traffic will be seen by all three computers; in order for the PC1-A computer
network and the UA to receive multicast messages sent from the eth1 network, the
TCDL router must be configured to pass multicast messages to those networks. Once
the CUCS has discovered the VSMs and data links on the network, the configuration
process between the CUCS and data links/UA/payloads/VSMs occurs. Successful
configuration is then followed by the CUCS monitoring and/or controlling the specified
component.
The UDP multicast protocol requires the specification of both an IP address and a port.
For example on a UNIX system, a service may be added to the services file that
identifies the UDP ports to be used between the CUCS and the VSM. The multicast IP
address for the uplink must be different than the multicast IP address for the downlink.
Service_name
port/protocol
CucsMulticast
220.0.0:52000/udp
Multicast from CUCS
VsmMulticast
220.0.1:52001/udp
Multicast from VSM
There is a requirement to identify the IP multicast address for the connection. On many
network configurations, the IP address range available for UDP multicast is restricted
to be between 22.0.0.0 and 239.25.2.25.2.25.2.
The description of the CUCS
multicast address and the VSM multicast address must be specified by a combination
of IP address and port number (e.g., 233.16.1.28:52000). Determination of the
appropriate UDP multicast addresses and ports is ultimately a network administration
50
Edition A Version 1
AEP-84.1
task that must be coordinated to configure each VSM, CUCS, and hardware device
(router) on the common network.
.
CUCS
VSM A
VSM B
Figure 25: CUCS Multicast
In the above figure, all the VSMs that have subscribed to the subnet address will
receive the CUCS UDP datagrams.
To provide the capability for the CUCS to subscribe to transmissions from more than
one VSM, the VSMs must be set to publish on a specified port on a specified multicast
address as shown below in Figure 26.
224.0.0:52001
VSM A
CUCS
224.0.0:52001
VSM B
Figure 26: VSM Broadcast
The CUCS should queue the packets received from the VSMs on a first in first out
basis. Frequently, the protocol stack software UDP buffer is small and does not
expand, therefore the CUCS should remove and process the incoming UDP packets
at a rate sufficient to prevent the buffer from overflowing and losing data.
Multicast loopback is required if the CUCS and VSM software are installed on the
same computer. By default, loopback is enabled. Loopback should be explicitly set
based on the deployment configuration.
Once the network configuration has been established, the CUCS can initiate the
VSM/UA discovery process as per the “CUCS/VSM Initialization and Connection”
sections in Annex 3 and 4 respectively.
3.9 Mission Planning
Mission planning for a UAS generally consists of five areas of activity:


Basic route planning—simple navigation routes for the vehicle
Alternative route planning—navigation routes to address
emergencies or conditional situations
51
Edition A Version 1
AEP-84.1



Sensor collection planning—basic pre-planned instructions for a
sensor including scanning techniques and patterns
Communications planning—selection of communication devices
and frequencies
Dissemination planning—selection of methods to store or retransmit collected sensor information.
STANAG 4586 selected the Common Route Definition (CRD) interface as the
standard for passing mission planning information among UASs. However, for UAS
purposes, the CRD was incomplete and Attachment B2-4, UAV Custom Tags, of the
STANAG was defined to create an additional set of interfaces to augment the CRD.
The basic CRD addresses activity areas 1 and 2 above and the UAS Custom Tags
address 3, 4, and 5 above. They must be used together for a full mission plan.
Attachment B, UAV Custom Tag Implementation, provides a detail explanation and
examples showing how these two interfaces operate together.
ATTACHMENT A: UA Custom Tag Implementation
This Attachment explains how to incorporate the UA Custom Tags within the
Common Route Definition (CRD).
52
Edition A Version 1
AEP-84.1
ANNEX 1
CCI IMPLEMENTATION GUIDELINES
A1 CCI Implementation Guidelines
This section of the Implementation Guide addresses the CCI products to be exchanged
with various C4I systems, such as message sets, video products, and ISR products
(refer to AEP-84 Volume I Attachment 5 – 1: Information Exchange Requirements).
The CCI message set is a standard set of ADatP-3 Baseline 11 messages that
provides for the base functionality of a CUCS for any given UA system. The
implementation approach presented here addresses each LOI from LOI 1 through LOI
5. A listing of the CCI messages necessary to support each LOI is contained in the
AEP-84 Volume I, Attachment 5 – 3: UAS LOI ADatP-3 Build 11 Requirements. In
addition to the capability to generate and display all of the specified CCI messages,
this Implementation Guide also makes recommendations regarding what message
field elements may be operationally significant and should be processed by the CUCS.
Real/near-real-time interaction between the CUCS and the CCI in the system will not
be specified.
The sensor data processed by the CUCS in support of the CCI consists of various
digital data such as primary video imagery, secondary imagery files, synthetic aperture
radar data, and moving target indicator data, based on the specific payload(s)
supported by the UA. All these data types should be in accordance with the NATO
STANAGs specified in STANAG 4586. If a particular payload type is not supported by
the UAS, the UCS is not required to support dissemination of that type of data in order
to be STANAG 4586 compliant.
When necessary, the CCISM component of the system will provide for the interface to
those C4I systems that are not fully compliant with ADatP-3 Baseline 11 messages
(e.g., STANAG 3377 messages), with digital video and other digital data standards, or
with other dissemination protocol/format requirements specified in STANAG 4586.
The CCISM then becomes the “translator” between the CUCS and the unique
requirements of a particular C4I system.
A1.1 Interface Implementation
A1.1.1 Physical Interface
An electronic interface is necessary to provide a communications pathway between
the CUCS and the C4I systems for the exchange of digital products across the CCI.
The typical media for exchange of digital information between systems is an Ethernet
network (Wide Area Network - WAN, Local Area Network - LAN). The commonly
accepted standard for the physical interface on an Ethernet system is 100BaseT, using
RJ-45 connectors, routers, etc. To ensure the initial interoperability between systems,
it is recommended that these two standards be followed in forming a connection
between the CUCS and various C4I systems via the CCI.
Additional methods of connectivity to C4I systems for digital data can be employed
such as satellite, Ultra High Frequency (UHF) radio, or Mobile Subscriber Equipment
(MSE) connections, etc.
A1 - 1
Edition A Version 1
AEP-84.1
An interface such as copper or fibre optic cable or a wireless RF link is necessary to
provide a communication pathway between the CUCS (via the CCISM) and the C4I
systems for the exchange of products across the CCI.
A1.1.2 Transmission of CCI Information
TCP/IP is the specified protocol for transmission of digital products across the CCI
because it provides consistent end-to-end network and transport communications
compliant with NATO-wide digitisation initiatives. The use of TCP/IP guarantees the
delivery of the CCI products between the CUCS and the C4I systems. The use of
TCP/IP by both the CUCS and the CCISM developers ensures that there is one
standard method of data transmission across the CCI.
A1.2 Message Implementation
Over 100 ADatP-3 messages, as defined in STANAG 5500, were determined to be
appropriate for unit operation (refer to AEP-84 Volume I Attachment 5 – 2: ADatP-3
Build 11 Message Implementation Requirements). All of these messages must be
displayed for operator visual review. Of these, several have been identified as
containing operationally significant data that may require additional processing beyond
textual display by the CUCS. An example of this may be the display of air coordination
corridors contained in Message F011, Air Coordination Order (ACO), as an overlay on
a map. Implementation of detailed processing to any of the STANAG 4586 specified
CCI messages will require coordination between the CUCS developer and the
procuring agent to define the details of the desired processing capability.
A1.2.1 CCI Message Set Level Implementation
This CCI Message Set Level Implementation section provides CUCS and CCISM
developers with information that is complimentary to the details provided in AEP-84
Volume I Chapter 5.
Attachment A: CCI Implementation/HCI Mapping Matrix provides a listing of CCI
(ADatP-3) messages that may require additional processing beyond textual display of
the message. Attachment B: Parsed Field Utilization also provides additional
information and details for each of these messages, such as set name, field name,
field data intent, and the relationship (e.g., mapping) of the data to the HCI and to a
"non ADatP-3 compliant" specific C4I node data element.
The information contained in these sections is extracted from ADatP-3, Build 11.
(Note: Refer to ADatP-3, Build 11, for a detailed syntax structure. The rules contained
in ADatP-3 take precedence over those listed in this document.)
A1.2.2 Resource Availability Implementation
The CCI has the capability to provide and receive the status and operational capability
of the sub-components of the UA system. This includes both the Air Segment and the
Ground Segment of the UA system as specified in Section 2.8 and 3.8 of Chapter 5 of
AEP-84 Volume I. Air segment resource data applicable to the UA status, payload
availability and Vehicle Data Terminal status can be reported in the GENTEXT fields
of J002, J082, J095 or J099 in accordance with relevant Standard Operating
Procedures. Ground Segment resource data applicable to the UCS, Launch Recovery
Systems and Control Data Terminals can be reported in the GENTEXT fields of A010,
J002, J082, J095 and J099 in accordance with relevant Standard Operating
Procedures.
A1 - 2
Edition A Version 1
AEP-84.1
A1.3 Sensor Data Implementation
Sensor data can be received from the UA in a variety of formats, depending on the
type of UA and sensor payload. This data then gets input into the CUCS, and the
formats used to transmit data from the UCS to a C4I system across the CCI will use
the STANAG 4586 specified standards whenever possible. This will minimise the
number of formats used in the CCI and also by the receiving C4I systems. Since it is
virtually impossible to cover all existing and future types of UA and their payloads, only
the most common types of sensors currently available have been addressed within the
current edition of STANAG 4586. (Refer to AEP-84 Volume I, Chapter 5, Section
2.9/Table 5 - 11, Payload and Sensor Type with CCI Output.) Specific UCS
implementations, including VSM and CCISM, may need to convert from a particular
sensor data format to that desired by a particular C4I system.
A1.3.1 Video Imagery Implementation
A1.3.1.1 Common KLV Metadata Elements
The following table derived from the UAS Data Link Local Metadata Set, lists the data
elements which are identified in the current Motion Imagery Standards Board (MISB)
STD 0601.4. Information in the MISB table has been adopted by many existing UA
systems.
UAS LDS Key
(Note 1)
DLI / CCI (Note 3)
Suggested
Elements (Note 2)
It should be noted that an “X” in the first column indicates that the particular element is
suggested for implementation in order to enhance imagery exploitation. If the
particular element is implemented, then it shall be applicable to the interface specified
in the second column of the table – either the CCI interface only, or both the CCI and
DLI interfaces. This table also specifies for each element which DLI Unique ID is to
be used.
Name (Note 1)
DLI Unique
Identifier
X
Co
1
Checksum
-
X
D&C
2
UNIX Time Stamp
0101.01
X
Co
3
Mission ID
0020.10
Co
4
Platform Tail Number
0020.09
X
D&C
5
Platform Heading Angle
0101.16
X
D&C
6
Platform Pitch Angle
0101.15
X
D&C
7
Platform Roll Angle
0101.14
Co
8
Platform True Airspeed
0102.06
Co
9
Platform Indicated Airspeed
0102.07
Co
10
Platform Designation
0020.06 & 0020.07
D&C
11
Image Source Sensor
-
X
A1 - 3
Edition A Version 1
UAS LDS Key
(Note 1)
DLI / CCI (Note 3)
Suggested
Elements (Note 2)
AEP-84.1
Name (Note 1)
DLI Unique
Identifier
X
Co
12
Image Coordinate System
-
X
D&C
13
Sensor Latitude
0101.04
X
D&C
14
Sensor Longitude
0101.05
X
D&C
15
Sensor True Altitude
0101.06
X
D&C
16
Sensor Horizontal Field of View
0302.13
X
D&C
17
Sensor Vertical Field of View
0302.11
X
D&C
18
Sensor Relative Azimuth Angle
0302.12
X
D&C
19
Sensor Relative Elevation Angle
0302.10
X
D&C
20
Sensor Relative Roll Angle
0302.14
Co
21
Slant Range
-
X
Co
22
Target Width
-
X
Co
23
Frame Center Latitude
0302.16
X
Co
24
Frame Center Longitude
0302.17
X
Co
25
Frame Center Elevation
0302.18
Co
26
Offset Corner Latitude Point 1
-
Co
27
Offset Corner Longitude Point 1
-
Co
28
Offset Corner Latitude Point 2
-
Co
29
Offset Corner Longitude Point 2
-
Co
30
Offset Corner Latitude Point 3
-
Co
31
Offset Corner Longitude Point 3
-
Co
32
Offset Corner Latitude Point 4
-
Co
33
Offset Corner Longitude Point 4
-
D&C
34
Icing Detected
-
Co
35
Wind Direction
0102.09 & 0102.10
Co
36
Wind Speed
0102.09 & 0102.10
D&C
37
Static Pressure
0102.14
D&C
38
Density Altitude
0102.08 & 0102.14
A1 - 4
Edition A Version 1
X
X
UAS LDS Key
(Note 1)
DLI / CCI (Note 3)
Suggested
Elements (Note 2)
AEP-84.1
Name (Note 1)
DLI Unique
Identifier
D&C
39
Outside Air Temperature
0102.08
Co
40
Target Location Latitude
-
Co
41
Target Location Longitude
-
Co
42
Target Location Elevation
-
Co
43
Target Track Gate Width
-
Co
44
Target Track Gate Height
-
Co
45
Target Error Estimate - CE90
-
Co
46
Target Error Estimate - LE90
-
Co
47
Generic Flag Data 01
-
Co
48
Security Local Metadata Set
-
D&C
49
Differential Pressure
0102.07
D&C
50
Platform Angle of Attack
0102.04
D&C
51
Platform Vertical Speed
0101.10
D&C
52
Platform Sideslip Angle
0102.05
Co
53
Airfield Barometric Pressure
-
Co
54
Airfield Elevation
-
Co
55
Relative Humidity
-
D&C
56
Platform Ground Speed
0102.17 & 0102.18
Co
57
Ground Range
-
D&C
58
Platform Fuel Remaining
010A4.1.16
Co
59
Platform Call Sign
0020.08
Co
60
Weapon Load
-
Co
61
Weapon Fired
-
Co
62
Laser PRF Code
0302.24
Co
63
Sensor Field of View Name
-
D&C
64
Platform Magnetic Heading
0101.16 & 0101.20
D&C
65
UAS LDS Version Number
-
A1 - 5
Edition A Version 1
UAS LDS Key
(Note 1)
DLI / CCI (Note 3)
Suggested
Elements (Note 2)
AEP-84.1
Name (Note 1)
DLI Unique
Identifier
Co
66
Target Location Covariance Matrix
-
D&C
67
Alternate Platform Latitude
-
D&C
68
Alternate Platform Longitude
-
D&C
69
Alternate Platform Altitude
-
D&C
70
Alternate Platform Name
-
D&C
71
Alternate Platform Heading
-
Co
72
Event Start Time - UTC
-
Co
73
RVT Local Data Set
-
Co
74
VMTI Local Data Set
-
Co
75
Sensor Ellipsoid Height
-
D&C
76
Alternate Platform Ellipsoid Height
-
Co
77
Operational Mode
-
Co
78
Frame Center Height Above Ellipsoid
-
Co
79
Sensor North Velocity
-
Co
80
Sensor East Velocity
-
Table A1 - 1: STD 0601.4 KLV Metadata Elements and DLI/CCI Mapping Requirements
Table notes:
1. The element name and key refers to MISB STD 0601.4 UAS Data Link Local
Metadata Set.
2. Elements marked with an ”X” are suggested to be included as an extended list
of elements, oriented for image exploitation.
3.
(Co): The element shall be available at the CCI only. (D&C): The element
shall be available at the DLI and the CCI.
A1.3.1.2 Digital Video
The CUCS processes digital video, but has no requirement to process analogue video.
This video processing also includes associated metadata, which must be time
synchronized with the video stream. Payload-specific metadata associated with the
digital sensor data needs to be published on the same interface as the sensor data in
accordance with applicable NATO standards. (Note: STANAG 4609 specifies a
A1 - 6
Edition A Version 1
AEP-84.1
standard compression and means to capture metadata describing digital motion
imagery.)
If analogue video is transmitted directly from the UA, the VSM will convert this video
into a digital format in accordance with STANAG 4609 (Digital NATO Motion Imagery
Format), STANAG 4545 (NATO Secondary Imagery Format), or STANAG 7023 (Air
Reconnaissance Imagery Data) and transmit it to the CUCS. For all still imagery types,
STDI-0002 will be used to record metadata describing the imagery when using
STANAG 4545. However when STANAG 7023 is used, metadata describing the
imagery will be captured as specified within STANAG 7023 If the analogue video is
required by one of the connected C4I nodes, the analogue video is transmitted directly
to the CCISM (if one is required) or to the respective C4I modem/link.
Digital video products (i.e., primary full motion digital imagery, secondary still digital
imagery, etc.) can likewise be transferred from the CUCS across the CCI to C4I
systems using established NATO standards (e.g., STANAG 4609 for digital motion
imagery) for both communication protocols and physical media.
Processing of these secondary imagery files takes place within the CUCS, and
dissemination of these files to applicable C4I systems takes place across the CCI using
the formats and standards specified in either STANAG 4607 for GMTI, STANAG 4609
for motion imagery (MPEG-2), STANAG 4545 for still frame imagery or STANAG 7023
for streaming primary imagery, as appropriate.
When using STANAG 4545 format for the imagery files, it is appropriate to use NATO,
AEDP-4, Implementation Guide, Annex D. For STANAGs 4607 and 4609, it is
appropriate to use the corresponding Implementation Guides, NATO AEDP – 7 and 8
respectively. However, when using STANAG 7023 format for the imagery files, the
metadata describing this imagery should be captured as specified within STANAG
7023. STANAG 7023 Implementation Guide, AEDP – 9 should also be used.
As bandwidth constraints permit, the physical interface between the CUCS and the C4I
system across the CCI can be shared for both digital sensor data and tactical
messages. If bandwidth requirements exceed the capabilities of the core-to-C4I
system interface (via the CCI and/or CCISM), a separate physical interface (e.g., a
second Ethernet port) may be desirable for transfer of digital sensor products.
A1.3.1.3 Analogue Video
If a particular C4I system requires analogue video, there are different methods through
which the analogue video product can be obtained by the C4I system from the UCS.
When analogue video and associated telemetry data are directly output from an UA to
the VSM, analogue video can be forwarded directly from the VSM to a C4I interface or
to the CCISM, if the VSM has provided an analogue output port. (Refer to Chapter 5
of AEP-84 Volume I, Section 2.9.2.1.2.1, Analogue Video).
For those cases when digital video is directly output from an UA, and processed
digitally within the CUCS, then this digital product will need to be input to the CCISM
from the CUCS for conversion to the appropriate analogue format for a particular C4I
system.
The CCISM can be designed to provide the analogue video in any of the international
standard formats and protocols necessary to meet the requirements of a specific C4I
interface (e.g., NTSC SMPTE 170-M, SECAM, PAL, etc.). Processing within the
CCISM should also include implementation of special features required by a particular
C4I system, such as encoding of telemetry metadata within the analogue video stream
in a closed caption format.
A1 - 7
Edition A Version 1
AEP-84.1
The CCISM will support interoperability with the applicable C4I system by providing for
the appropriate physical medium such as copper cable (e.g., RG/59U), fibre optic
cable, RF wireless, etc.
A1.3.2 Radar Sensor Implementation
A1.3.2.1 Synthetic Aperture Radar (SAR)
Synthetic Aperture Radar data that has been processed on the UA or within the UCS
is transmitted across the CCI to C4I systems using the formats specified in STANAG
4545 or STANAG 7023 as appropriate. When STANAG 4545 is used, the SAR
auxiliary text files contain support data as defined in that STANAG and in NATO,
AEDP-4, Annex D. When STANAG 7023 is used, the SAR auxiliary text files contain
support data as defined in STANAG 7023.
A1.3.2.2 Ground Moving Target Indicator (GMTI)
Processed GMTI data provides the position and velocity of moving targets, and
consists of sets of target vectors. GMTI data requires extensive processing of the
sensor data to generate these target vectors. This processing can occur in the UA or
within the UCS.
This digital data is provided from the UCS to a C4I system across the CCI, in
accordance with the formats and standards specified in STANAG 4607.
A1.3.3 Secondary Imagery File Implementation
Dependent upon the type of UA and payload utilized, secondary imagery files (digital
still imagery) may be generated aboard the UA, and also within the UCS. Processing
of these secondary imagery files takes place within the UCS, and dissemination of
these files to applicable C4I systems takes place across the CCI using the formats and
standards specified in either STANAG 4545 for still frame imagery or STANAG 7023
for streaming primary imagery, as appropriate.
When using STANAG 4545 format for the imagery files, it is appropriate to use NATO,
AEDP-4, Implementation Guide, Annex D. However, when using STANAG 7023 format
for the imagery files, the metadata describing this imagery should be captured as
specified within STANAG 7023. STANAG 7023 Implementation Guide, AEDP – 9
should also be used.
A1.4 Voice Over IP Implementation
A1.4.1 Elements of Voice Over IP Implementation
The implementation of Voice over IP (VoIP) into a UCS should be done by the CUCS
developer according to the ITU-standard H.323. The standard H.323 defines an IPbased protocol structure, which uses TCP for data and control application packets
while UDP is used for real-time transportation of audio and registration packets. The
real-time transmission over IP networks is made up by the Real-time Transport
Protocol (RTP) in conjunction with the Real-time Control Protocol (RTCP).
For VoIP functionality, at least a H.323 terminal (e.g., workstation with Computer
Telephony Integration (CTI) or IP-Telephone), which is connected to an Ethernet
switch/router with the appropriate H.323 supporting software, is required. The
integration of other VoIP components such as gatekeepers or gateways is not
mandatory and depends on the number of endpoints to be operated on the network.
The following figure shows a possible configuration for VoIP implementation. However,
A1 - 8
Edition A Version 1
AEP-84.1
the detailed design for implementation of VoIP products is the responsibility of the UCS
developer.
CCISM
H.323
Elements
H.323 CTI
IP LAN
Ethernet
Router
C4I
Node
H.323
Gatekeeper
H.323
Telephone
Figure A1 - 1: Principle Structure of VoIP Implementation
A1.4.2 VoIP Interface Quality of Service Implementation
The Information Exchange Requirements for the CCI described in Chapter 5,
Attachment 5 - 1 of AEP-84 Volume I defines digital voice as a requirement for all LOIs.
Digital voice is characterized as non-critical for UCS operation, while the majority of
information to be exchanged via the CCI is mission-critical. Due to these
characterizations, mission-critical application data should be protected from VoIP
traffic, and the available network bandwidth should be high enough to transport all
applications according to their individual requirements. To control the quality of the
network (e.g., latency, jitter, congestion, etc.), Quality of Service (QoS) mechanisms
should be used.
For VoIP implementation, two network zones should be considered. Both network
zones should distinguish between voice and data traffic and apply separate network
services to each. The first network zone consists of the CUCS with the CCISM and the
C4I node, which connects the UCS to the external C4I network. The second zone
consists of the C4I network. Although this second zone is outside the scope of
STANAG 4586, it is necessary that the QoS mechanisms are implemented for this
zone. Otherwise, VoIP may become unacceptable to the users due to insufficient
quality of voice.
This Implementation Guide does not address the integration of an interface between
the Public Switched Telephone Network (PSTN) and the VoIP network.
The implementation of VoIP into a data network requires the network architecture
elements to be compliant with the protocol suite H.323. Clients, routers, switches and
gateways should be capable of handling the H.323 protocols as well as support and
supply the prerequisite QoS features. QoS is an end-to-end requirement. There are
different techniques for QoS to provide better and more predictable network service.
The most common techniques are Queuing, IP-Type of Service (IP-TOS) and the
Resource Reservation Protocol (RSVP).
Queuing describes an operation where certain rules are used to place applications in
a priority queue. There are different types of queuing. Weighted Fair Queuing is a
A1 - 9
Edition A Version 1
AEP-84.1
procedure that dynamically allocates free bandwidth to information flows. Source and
destination address, type of protocol, socket or port address and TOS may be used for
identification. The classification is performed with respect to IP-Precedence, RSVP,
IP-RTP priority, etc. Custom Queuing (CQ) is a procedure where available bandwidth
is allocated to certain protocols based on manual administration. Priority Queuing (PQ)
assigns incoming information to four output queues with different priorities. The
information of one queue will be processed with priority until the buffer is empty. This
procedure may cause long delays for information with low priority.
IP-Type of Service, also referred to as IP Precedence, uses the three precedence bits
of the IPv4 header to specify the priority for each packet. The IP-TOS field allows up
to six priority classes. The priority level can be set by the endpoint, switch or router.
IP-TOS has some restrictions because many Ipv4 hubs ignore it.
RSVP is a standardized protocol (RFC 2205), which enables endpoints to signal the
network with the kind of QoS needed for a particular application. It is an end-to-end
signalling protocol that requests a certain amount of bandwidth and latency at every
RSVP-supporting hub. If a hub does not support RSVP, and packets need to travel
through, the packets can be “tunnelled” through as ordinary packets.
RSVP should be used, as it is currently the only standard protocol designed to
guarantee network bandwidth from end-to-end for IP networks.
A1.5 CCISM Implementation
When C4I systems are not fully compliant with the requirements of STANAG 4586
communication interfaces, the CCISM will need to perform the translation and/or
adaptation to enable the exchange of data between the CCI and the C4I system in the
format required by the C4I system. The CCISM will also need to handle the real-time
applications when a C4I system requires real-time operations, since the CUCS is not
a real-time system.
A1.5.1 C4I Systems
The use of a CCISM is required on a case-by-case basis for many of the legacy C4I
systems currently in use by the allied forces. Examples of issues that may necessitate
the use of a CCISM include the following:

The development of C4I systems is complex, especially in the
interoperability arena. This complexity is increasing with the extent of
the exchanges: Service level, Joint level (multi-service of the same
nation), Combined level (service of Allied Nations) or a Joint
Combined level (multi-service of Allied Nations). As a result, the
nations may have to "freeze" the versions of the interfaces (for
instance France refers to ADatP-3 Baseline 8 for its Army C4I.

Line of Sight and Beyond Line of Sight links may be more complex,
because some interoperable links are already operational with their
own requirements and protocols (Link 1, Link 4, Link 11, Link 16, Link
22, SATCOM links, etc.).

Provision of gateways into communication media such as Public
Switched Telephone Network (PSTN); mobile systems such as GSM,
GPRS, UMTS; microwave links (with the two communication worlds
(Europe: E-i standards; USA: T-i standards)); and TV broadcasting
systems (Europe: DVB systems, USA: ATSC systems).
A1.5.2 CCISM Functional Architecture
A1 - 10
Edition A Version 1
AEP-84.1
The Figure below presents a functional overview of a potential implementation of the
CCISM, with various functions that could be accomplished by the CCISM.
The CCISM may need to perform the following tasks:

Translations from the specified CRD format to non-standard
implementations

Routing and conversion of analogue video signals from the VSM to
the C4I customer.

Support of digital voice using "Voice over IP" protocols.

Support of video and voice storage devices.

Conversion of digital video from the CUCS into the appropriate
analogue video format for the particular C4I system.
The CCISM may be an element of either the CUCS or the C4I Node and physically
co-located with the CUCS or the C4I node.
CCI
ADatP-3
C4I
CUCS
STANAG 4545, 7023, 4607, 4609; JSH
CRD
Handover Messages
ATS (DOC 4444-RAC/501)
E-Mail
ISO/IEC 8802-3
ANSI/IEEE Std 802.3
CCISM
CRD
Voice
CRD
Analogue
Video
Other
Analogue Video
TCP / IP
SMTP
VSM
Intercom
Storage
Device
Fax
H.323
Other Protocols
PAL, SECAM
NTSC
Figure A1 - 2: CCISM Functional Architecture
A1 - 11
Edition A Version 1
AEP-84.1
A1.5.3 Data Rates
The CCISM may also need to adjust data rates between payload data and C4I
systems. For example, when the minimal mode of STANAG 7085 data links is fixed
at 10.71 Mbps and if the interface between a deployed UCS and a distant C4I ranges
from one or a few tenths of Mbps to Gbps the CCISM will have to perform the
interconnectivity through a change of data rates.
A1.5.4
Communications
Voice dialogue may be exchanged with external systems. Personnel performing air
operations may need to communicate (e.g., communications between any airspace
controller, any pilot of manned aircraft or operators of unmanned aircraft).
Between the CUCS operator and an external source, a voice communications system
may be implemented to enable communications with other UCS operators, C4I system
operators, etc.
The HCI may include a microphone/loudspeaker headset per operator in addition to a
selection device in order to communicate in accordance with doctrinal requirements.
A1 - 12
Edition A Version 1
AEP-84.1
ATTACHMENT A: CCI IMPLEMENTATION/HCI MAPPING MATRIX
This Attachment presents an example of an implementation of STANAG 4586 with respect to incorporation of the CCI messages within the
HCI. Although all ADatP-3 messages will be readable and printable on the CUCS, some data fields within an ADatP-3 message will be
extracted from the message to be used by the HCI. Not every ADatP-3 message will require data field extraction. Typically, the extracted data
fields will allow the HCI to display:
- Position of enemy or friendly forces
- Targets, landmarks, or obstacles
- Air corridors, UA routes, or aircraft routes
- Reference text to show source and effective duration of the message
Attachment A identifies the specific ADatP-3 messages that were selected for parsing.
Ref #
A026
Identifier
ENSITREP
Name
Enemy Land Forces Situation Report
A031
OWNSITREP
Own Land Forces Situation Report
A032
ORBATLAND
Order of Battle – Land Forces
Function
Used to report and inform on the enemy forces situation,
to include locations, activities, boundaries, status, order of
battle, and subordination of units/formations.
Used to report factors affecting the situation, deployment,
status, and/or order of battle of own and subordinate units.
(NR) - Used to inform major NATO commanders, strategic
A1 - 14
Edition A Version 1
AEP-84.1
Ref #
Identifier
Name
A058
ATI.ATR
Artillery Target Intelligence - Artillery Target
Report
A060
A062
MET.CM
MET.TA
Meteorological – Computer
Meteorological – Target Acquisition
A069
SPRT.ACA
Support – Airspace Coordination Area
A070
SPRT.GEOM
Support - Battlefield Geometry
A080
FRAGO
Fragmentary Order
F011
ACO
Airspace Control Order
Function
commanders, and other NATO commanders in peacetime
and in periods of crisis and war of changes in the Order Of
Battle Land forces; and thereby assure that the most
current information is available for operational planning.
Used to transmit targets by target type based on a standing
request for information or a one-time query for target
information resulting from an ATI.TIR message. It will also
be used to establish or delete target information.
Used to transmit computer meteorological data.
Used to transmit meteorological data for target acquisition
purposes.
Used to establish or delete Airspace Coordination Areas
(ACAs). The SPRT.ACA message can only be used to
identify an ACA in a single Grid Zone. Additional
SPRT.ACA messages must be used when an ACA covers
multiple Grid Zones.
Used to establish or delete battlefield geometries (e.g.,
Avenue of Approach, Axis of Advance, Target Areas, Zone
of Fire) in support of land combat operations for current
operations or for a fire plan.
Used to issue key sections of an operation order before
the complete order has been produced; provide specific
instructions to commanders who do not require the
complete operation order; provide a summary of the
complete order to serve as confirmatory notes; issue
timely changes to existing operation orders; or provide an
outline operational directive (mission order) for use in fast
moving mobile operations.
(NR) Used to provide specific detailed orders for airspace
management and control from a higher command to
A1 - 15
Edition A Version 1
AEP-84.1
Ref #
Identifier
Name
F032
ORBATAIR
Order of Battle – Air Forces
F058
ATO
Air Tasking Order
J017
IFFPROD
IFF Procedures
J033
J034
NBC4
NBC5
NBC 4 Report
NBC 5 Report
J065
EWSTOPJAM
Electronic Warfare Stop Jamming Message
J066
EWRTM
Electronic
Message
J071
J103
TRACKREP
RECCEXREP
Target Track Report
Reconnaissance Exploitation Report
N003
N023
JAMWARN
GREEN
Jamming Warning
Maritime Unit Execution Order
N025
LOCATOR
Maritime Force Locator
N028
OPTASKAIR
Operational Tasking Organic Aircraft
Warfare
Requesting/Tasking
Function
subordinate units.
(NR) Used to inform major NATO commanders, strategic
commanders, and other NATO Commanders in peacetime
and in periods of crisis and war of changes in the Order Of
Battle Air Forces; and thereby assure that the most current
information is available for operational planning.
Used to task air missions, assign cross-force tasking, and
may also be used for intraservice tasking.
Used to provide friendly forces with effective IFF modes
and codes, and effective time periods.
Used to report NBC monitoring and survey results.
Used for passing information on areas of actual nuclear,
biological, or chemical contamination.
Used to terminate immediately a jamming mission being
conducted by an electronic countermeasures asset.
Used to task component commanders to perform
electronic warfare (EW) operations in support of the overall
joint EW plan, and to support component EW operations.
Used to report aircraft movement by track number.
Used to report the results of an air reconnaissance mission
by the interpretation of sensor data.
Used to issue a warning about own jamming operations.
(NR) Used to task Maritime Patrol or Surveillance and
ASW units.
Used to report surface, subsurface, air, or special interest
units operating in the maritime environment.
(NR) Used for the OTC or delegated authority to
promulgate detailed tasking and instructions for all organic
A1 - 16
Edition A Version 1
AEP-84.1
Ref #
Identifier
N068
OPTASKEW
Name
Operational Tasking Electronic Warfare
Function
aircraft. This message is normally promulgated by the
OTC or the air coordinator.
(NR) Used to promulgate detailed tasking and instructions
for the conduct of Electronic Warfare.
Table ATT A1 - 1: ADatP-3 Messages Selected for Parsing
A1 - 17
Edition A Version 1
AEP-84.1
ATTACHMENT B: Parsed Field Utilization
Attachment B identifies selected fields from the parsed messages that are being used for implementation with the HCI, and are discussed in
some detail in the table. The data in Attachment B is grouped and labelled by ADatP-3 message number and name. The column headings for
each message are defined as follows:
- Seq/SETID — The sequence number and sequence identifier of the subset of data fields within the message
- Data Element Name and Description — The number and name of the extracted data field from the message
-
Seq/
SETID
A026
3
Data Intent — The intended use of the data by the CUCS
HCI Component — The set of HCI display screens that will utilize the data field to list text or plot message information
Compliance — A placeholder for the developer to indicate whether or not he is compliant
C4I Node XX ICD Data Element — A placeholder for the developer to indicate if he has defined a set of equivalent ADatP-3 which
he is matching to actual ADatP-3 field elements.
Data Element Name & Description
ENSITREP
MSGID
Data Intent
HCI Component
Compliance
Test
C4I Node
XX
ICD Data
Element
ENEMY LAND FOCES SITUATION REPORT
F1 - Message Text
Format Identifier
F2 - Originator
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Data set reference; maybe used in
operator display and associated
Operator
Situational
Displays
Operator
Situational
Displays
A1 - 18
Edition A Version 1
AEP-84.1
with object in overlays for mission
planning.
Seq/
F3 - Message Serial
Number
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Operator
Situational
Displays
F4 - Month Name
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Operator
Situational
Displays
Data Element Name & Description
SETID
Data Intent
HCI Component
F5 - Qualifier
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Operator
Situational
Displays
F6 - Serial Number of
Qualifier
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Operator
Situational
Displays
Compliance
Test
C4I Node
XX
ICD Data
Element
A1 - 19
Edition A Version 1
AEP-84.1
10
EORGID
F1 - Unit Designation
Name
F10 - Unidentified Enemy
Unit Addressing Number;
Unknown Enemy Unit
Addressing Number
Seq/
Used as label to identify enemy
unit on overlay of map display for
mission planning.
Used as label to identify enemy
unit on overlay of map display for
mission planning.
Operator
Situational
Displays
Operator
Situational
Displays
F3 - Verified Nationality
Used as label to identify enemy
unit on overlay of map display for
mission planning.
Operator
Situational
Displays
F4 - Verified Unit Role
Indicator Code ‘A’
Provides information related to
enemy role. Can be plotted or
labelled on map overlay.
Operator
Situational
Displays
F5 - Verified Unit Role
Indicator Code ‘B’
Provides information related to
enemy role. Can be plotted or
labelled on map overlay.
Operator
Situational
Displays
Data Element Name & Description
SETID
F6 - Verified Unit Role
Indicator Code ‘C’
Data Intent
Provides information related to
enemy role. Can be plotted or
labelled on map overlay.
HCI Component
Compliance
Test
C4I Node
XX
ICD Data
Element
Operator
Situational
Displays
A1 - 20
Edition A Version 1
AEP-84.1
10
14
20
Seq/
SETID
EORGID
Provides information related to
enemy role. Can be plotted or
labelled on map overlay.
Operator
Situational
Displays
Provides information on enemy's
short range air defence system.
Can be plotted or labelled on map
overlay (threat evaluation).
Operator
Situational
Displays
F4 - Quantity on Hand
Provides information on enemy's
short range air defence system.
Can be plotted or labelled on map
overlay (threat evaluation).
Operator
Situational
Displays
F5 - Rounds of
Ammunition/Missiles on
Hand
Provides information on enemy's
short range air defence system.
Can be plotted or labelled on map
overlay (threat evaluation).
Operator
Situational
Displays
F7 - Verified Unit Role
Indicator Code ‘D’
F3 - Weapon System
2SHORAD
Short Name
LOCATION F3 - Location
Data Element Name & Description
Provides graphic location on the
enemy and own forces information
are related to. Can be plotted or
labelled on map overlay.
Data Intent
Operator
Situational
Displays
HCI Component
Compliance
Test
C4I Node
XX
ICD Data
Element
A1 - 21
Edition A Version 1
AEP-84.1
23
24
25
DRCTN
ORGIDAFU
F1 - Direction of
Movement
Provides information on enemy's
movement. Can be plotted or
labelled on map overlay.
Operator
Situational
Displays
F2 - Day-Time Effective
Provides information on enemy's
movement. Can be plotted or
labelled on map overlay.
Operator
Situational
Displays
F3 - Speed in Kilometres
Per Hour
Provides information on enemy's
movement. Can be plotted or
labelled on map overlay.
Operator
Situational
Displays
F1 - Unit Designation
Name
Provides information on own forces
under attack. Can be plotted or
labelled on map overlay.
Operator
Situational
Displays
Provides information on the type of
attack the own forces are affected
by. Can be plotted or labelled on
map overlay.
Operator
Situational
Displays
F2 - Location
Provides geographic location of the
two following enemy units. Can be
plotted or labelled on map overlay.
Operator
Situational
Displays
F1 - Unit Designation
Name
Provides enemy unit name #1
related to enemy position. Can be
plotted or labelled on overlay.
Operator
Situational
Displays
ATKTYPE F1 - Employment Type
28
LOCNF
29
EORGBDRY
Seq/
SETID
Data Element Name & Description
Data Intent
HCI Component
Compliance
Test
C4I Node
XX
A1 - 22
Edition A Version 1
AEP-84.1
ICD Data
Element
29
EORGBDRY
F6 - Unit Designation
Name
Provides enemy unit name #2
related to enemy position. Can be
plotted or labelled on overlay.
Operator
Situational
Displays
A1 - 23
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
A031
3
OWNSITREP
MSGID
Compliance
Test
Vehicle XX
ICD Data
Element
Own Land Forces Situation Report
F1 - Message Text
Format Identifier
Data set reference; maybe used as
identifier of dialog box on C4I
Operator Situational
display and associated to objects
Displays
to be displayed in overlays.
F2 - Originator
Data set reference; maybe used as
identifier of dialog box on C4I
Operator Situational
display and associated to objects
Displays
to be displayed in overlays
F3 - Message Serial
Number
Data set reference; maybe used as
identifier of dialog box on C4I
Operator Situational
display and associated to objects
Displays
to be displayed in overlays.
F4 - Month Name
Data set reference; maybe used as
identifier of dialog box on C4I
Operator Situational
display and associated to objects
Displays
to be displayed in overlays.
A1 - 24
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
SETID
10
17
ORGID
Data Intent
HCI Component
F5 - Qualifier
Data set reference; maybe used as
identifier of dialog box on C4I
Operator Situational
display and associated to objects
Displays
to be displayed in overlays.
F6 - Serial Number of
Qualifier
Data set reference; maybe used as
identifier of dialog box on C4I
Operator Situational
display and associated to objects
Displays
to be displayed in overlays.
F1 - Unit Designation
Name
Maybe used as primary identifier
on C4I display for selection of
report on own forces task
organisation.
F9 - Unit
Maybe used as secondary identifier
on C4I display for selection of
Operator Situational
report on own forces task
Displays
organisation.
F1 - Unit Designation
Name
Used as label to identify friendly
forces on overlay of map display
for mission planning.
Compliance
Test
C4I Node
XX
ICD Data
Element
Operator Situational
Displays
Operator Situational
Displays
A1 - 25
Edition A Version 1
AEP-84.1
18
Seq/
TPERID
F9 - Unit
Used as label to identify friendly
forces on overlay of map display
for mission planning.
Operator Situational
Displays
F1 - DTG From, Zulu, 4
YR
Provides the start time friendly
forces are present at location. Can
be plotted or labelled on map
overlay.
Operator Situational
Displays
Data Element Name & Description
SETID
F2 - DTG To, Zulu, 4 YR
19
25
LOCNFSTS F3 - Location
ORGID
Data Intent
Provides the end time friendly
forces are present at location. Can
be plotted or labelled on map
overlay.
HCI Component
Compliance
Test
C4I Node
XX
ICD Data
Element
Operator Situational
Displays
Provides the location of the friendly
Operator Situational
forces. Can be plotted or labelled
Displays
on map overlay.
F1 - Unit Designation
Name
Maybe used as primary identifier
on C4I display for selection of
report on own forces unit status.
F9 - Unit
Maybe used as secondary identifier
Operator Situational
on C4I display for selection of
Displays
report on own forces unit status.
Operator Situational
Displays
A1 - 26
Edition A Version 1
AEP-84.1
29
EORGID
Used as label to identify enemy
unit on overlay of map display and
for mission planning.
Operator Situational
Displays
F10 - Unidentified Enemy
Used as label to identify enemy
Unit Addressing Number;
unit on overlay of map display and
Unknown Enemy Unit
for mission planning.
Addressing Number
Operator Situational
Displays
F1 - Unit Designation
Name
F4 - Verified Unit Role
Indicator Code ‘A’
Seq/
Data Element Name & Description
SETID
Provides information related to
enemy role. Can be plotted or
labelled on map overlay.
Data Intent
Operator Situational
Displays
HCI Component
F5 - Verified Unit Role
Indicator Code ‘B’
Provides information related to
enemy role. Can be plotted or
labelled on map overlay.
Operator Situational
Displays
F6 - Verified Unit Role
Indicator Code ‘C’
Provides information related to
enemy role. Can be plotted or
labelled on map overlay.
Operator Situational
Displays
F7 - Verified Unit Role
Indicator Code ‘D’
Provides information related to
enemy role. Can be plotted or
labelled on map overlay.
Operator Situational
Displays
Compliance
Test
C4I Node
XX
ICD Data
Element
A1 - 27
Edition A Version 1
AEP-84.1
31
32
34
39
Seq/
EMAT
F2 - Verified Equipment
Category
LOCATION F3 - Location
Operator Situational
Displays
Provides the location of enemy
forces. Can be plotted or labelled
on map overlay.
Operator Situational
Displays
Operator Situational
Displays
Operator Situational
Displays
TIME
F2 - DTG, Zulu, 4 YR
Provides the time the enemy had
been observed at the location.
Can be plotted or labelled on map
overlay.
ORGID
F1 - Unit Designation
Name
Used as label to identify friendly
forces on overlay of map display
for mission planning.
Data Element Name & Description
SETID
F9 - Unit
40
Provides information on enemy's
equipment. Can be plotted or
labelled on map overlay (threat
evaluation).
F2 - Control or
LINETYPE
Coordination Line Type
Data Intent
Used as label to identify friendly
forces on overlay of map display
for mission planning.
HCI Component
Compliance
Test
C4I Node
XX
ICD Data
Element
Operator Situational
Displays
Geographical area of special
interest which is described by a line Operator Situational
type; overlay for map display and
Displays
mission planning
A1 - 28
Edition A Version 1
AEP-84.1
41
LOCNF
Location
Geographical location of area of
interest with line type; overlay for
map display
Operator Situational
Displays
43
TPERID
F1 - DTG From, Zulu, 4
Yr
Start time of effectiveness of line
type; used for mission planning
Operator Situational
Displays
F2 - DTG To, Zulu, 4 Yr
End time of effectiveness of line
type; used for mission planning
Operator Situational
Displays
A1 - 29
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
A032
3
ORBATLAND
MSGID
Compliance
Test
Vehicle XX
ICD Data
Element
Order of Battle - Land Forces
F1 - Message Text
Format Identifier
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Mission Planning
Displays
F2 - Originator
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Mission Planning
Displays
F3 - Message Serial
Number
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Mission Planning
Displays
F4 - Month Name
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Mission Planning
Displays
F5 - Qualifier
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Mission Planning
Displays
A1 - 30
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
F6 - Serial Number of
Qualifier
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Compliance
Test
Vehicle XX
ICD Data
Element
Mission Planning
Displays
10
ORGIDRPT
F1 - Unit Designation
Name
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
10
ORGIDRPT
F10 - Unit Identification
Code
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
F2 - Unit Size Indicator
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
F3 - Geographical Entity
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
F4 - Unit Role Indicator
Code “A”
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
F5 - Unit Role Indicator
Code “B”
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
F6 - Unit Role Indicator
Code “C”
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
A1 - 31
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
F7 - Unit Role Indicator
Code “D”
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
F8 - Higher Formation
Name
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
F9 - Armed Service or
Civilian Agency Code
Order of battle data set; overlay for Mission Planning
mission planning
Displays
11
CEFT
F1 - Combat
Effectiveness
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
13
UNST
F1 - Unit Readiness
Status
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
F2 - Unit Availability
Status
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
F3 - Unit Assignment
Status
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
F3 - Peacetime Location
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
F4 - Unit Identifier
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
16
LOCA
Compliance
Test
Vehicle XX
ICD Data
Element
A1 - 32
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
17
18
LOCB
F3 - Peacetime Location
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
F4 - Estimated Time of
Arrival
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
F5 - Unit Identifier
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
Compliance
Test
Vehicle XX
ICD Data
Element
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
DPLOY
F1 - DTG of Arrival, 4 Yr
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
F4 - Arrival Grid
Reference Location
Coordinate
Order of battle data set; overlay for Mission Planning
mission planning.
Displays
F5 - Estimated Day-Time Order of battle data set; overlay for Mission Planning
and Month of Departure mission planning.
Displays
A058
ATI.ATR
Artillery Target Intelligence-Artillery Target Report
A1 - 33
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
F1 - Message Text
Format Identifier
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Operator Situational
Displays
F2 - Originator
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Operator Situational
Displays
F3 - Message Serial
Number
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Operator Situational
Displays
F4 - Month name
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Operator Situational
Displays
F5 - Qualifier
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Operator Situational
Displays
F6 - Serial number of
qualifier
Data set reference; maybe used in
operator display and associated
Operator Situational
Displays
SETID
3
MSGID
Compliance
Test
Vehicle XX
ICD Data
Element
A1 - 34
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
Compliance
Test
Vehicle XX
ICD Data
Element
with object in overlays for mission
planning.
6
OPT
7
TNO
9
GRIDTG
F1 - Primary Option
Provides information related to
identified targets to the operator in
display for mission planning.
Operator Situational
Displays
F2 - Secondary Option
Provides information related to
identified targets to the operator in
display for mission planning.
Operator Situational
Displays
F1 - Target Number
Provides information related to
identified targets to the operator in
display for mission planning.
Operator Situational
Displays
Provides information related to
F1 - UTM 1 Metre Higher
Operator Situational
location of identified target. Used to
Order Easting
Displays
plot target on overlay.
Provides information related to
F2 - UTM 1 Metre Higher
Operator Situational
location of identified target. Used to
Order Northing
Displays
plot target on overlay.
F3 - Altitude in Metres
Provides information related to
location of target. Can be used to
label on overlay.
Operator Situational
Displays
A1 - 35
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
10
GZE
Provides information related to
F1 - Earth Hemisphere
Operator Situational
location of identified target. Used to
and Grid Zone Designator
Displays
plot target on overlay.
11
TST
F1 - Target Type and
Subtype
Seq/
Data Element Name & Description
3
MET.CM
MSGID
Vehicle XX
ICD Data
Element
Provides information related to
Operator Situational
identified target. Maybe associated
Displays
to target on overlay.
Data Intent
HCI Component
SETID
A060
Compliance
Test
Compliance Test
Vehicle
XX
ICD Data
Element
Meteorological-Computer
Data set reference; maybe used in
F1 - Message Text Format operator display and associated
Mission Planning
Identifier
with object in overlays for mission Displays
planning.
F2 - Originator
Data set reference; maybe used in
operator display and associated
Mission Planning
with object in overlays for mission Displays
planning.
A1 - 36
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
6
MSTA
F3 - Message Serial
Number
Data set reference; maybe used in
operator display and associated
Mission Planning
with object in overlays for mission Displays
planning.
F4 - Month Name
Data set reference; maybe used in
operator display and associated
Mission Planning
with object in overlays for mission Displays
planning.
F5 - Qualifier
Data set reference; maybe used in
operator display and associated
Mission Planning
with object in overlays for mission Displays
planning.
F6 - Serial Number of
Qualifier
Data set reference; maybe used in
operator display and associated
Mission Planning
with object in overlays for mission Displays
planning.
Provides information on
Meteorological Station to the
F2 - MET Station Location
operator in display for mission
planning and for overlay on map.
Compliance Test
Vehicle
XX
ICD Data
Element
Mission Planning
Displays
A1 - 37
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
7
DCM
F3 - Met Validity
Provides information on
Meteorological Station to the
operator in display for mission
planning.
Mission Planning
Displays
F4 - Met Station Height
and Pressure
Provides information on
Meteorological Station to the
operator in display for mission
planning and for overlay on map.
Mission Planning
Displays
Provides information on wind
Mission Planning
direction and speed to the operator
Displays
in display for mission planning.
Provides information on air
F3 - Air Temperature and temperature and pressure to the
Pressure
operator in display for mission
planning.
MET.TA
ICD Data
Element
Provides information on
F1 - Computed
Mission Planning
meteorological data to the operator
Meteorological Zone Code
Displays
in display for mission planning.
F2 - Wind Direction and
Speed
A062
Compliance Test
Vehicle
XX
Mission Planning
Displays
Meteorological-Target Acquisition
A1 - 38
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
3
MSGID
Compliance Test
Vehicle
XX
ICD Data
Element
Data set reference; maybe used in
F1 - Message Text Format operator display and associated
Mission Planning
Identifier
with object in overlays for mission Displays
planning.
F2 - Originator
Data set reference; maybe used in
operator display and associated
Mission Planning
with object in overlays for mission Displays
planning.
F3 - Message Serial
Number
Data set reference; maybe used in
operator display and associated
Mission Planning
with object in overlays for mission Displays
planning.
F4 - Month Name
Data set reference; maybe used in
operator display and associated
Mission Planning
with object in overlays for mission Displays
planning.
F5 - Qualifier
Data set reference; maybe used in
operator display and associated
Mission Planning
with object in overlays for mission Displays
planning.
A1 - 39
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
F6- Serial Number of
Qualifier
6
7
MSTA
CBMRI
Compliance Test
Vehicle
XX
ICD Data
Element
Data set reference; maybe used in
operator display and associated
Mission Planning
with object in overlays for mission Displays
planning.
Provides information on
Meteorological Station to the
F2 – MET Station Location
operator in display for mission
planning and for overlay on map.
Mission Planning
Displays
F3 - Met Validity
Provides information on
Meteorological Station to the
operator in display for mission
planning.
Mission Planning
Displays
F4 - Met Station Height
and Pressure
Provides information on
Meteorological Station to the
operator in display for mission
planning and for overlay on map.
Mission Planning
Displays
F1 - Cloud Base Height
Provides information on cloud
Mission Planning
height to the operator in display for
Displays
mission planning.
A1 - 40
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
Compliance Test
Vehicle
XX
ICD Data
Element
Provides information on refractive
Mission Planning
F2 - Mean Refractive Index index to the operator in display for
Displays
mission planning.
8
A069
3
DTA
SPRT.ACA
MSGID
Provides information on
F1 - Target Acquisition
Mission Planning
meteorological data to the operator
Meteorological Zone Code
Displays
in display for mission planning.
F2 - Wind Direction and
Speed
Provides information on wind
Mission Planning
direction and speed to the operator
Displays
in display for mission planning.
F3 - Met Air Temperature
and Relative Humidity
Provides information on air
temperature and pressure to the
operator in display for mission
planning.
Mission Planning
Displays
Support-Airspace Coordination Area
Data set reference; maybe used in
F1 - Message Text Format operator display and associated
Operator Situational
Identifier
with object in overlays for mission Displays
planning.
F2 - Originator
Data set reference; maybe used in Operator Situational
Displays
operator display and associated
A1 - 41
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
Compliance Test
Vehicle
XX
ICD Data
Element
with object in overlays for mission
planning.
6
OPT
F3 - Message Serial
Number
Data set reference; maybe used in
operator display and associated
Operator Situational
with object in overlays for mission Displays
planning.
F4 - Month Name
Data set reference; maybe used in
operator display and associated
Operator Situational
with object in overlays for mission Displays
planning.
F5 - Qualifier
Data set reference; maybe used in
operator display and associated
Operator Situational
with object in overlays for mission Displays
planning.
F1 - Primary Option
Provides information related to
Operator Situational
identified targets to the operator in
Displays
display for mission planning.
F2 - Secondary Option
Provides information related to
Operator Situational
identified targets to the operator in
Displays
display for mission planning.
A1 - 42
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
9
DUR
10
GZE
11
LEGA
F1 - Estimated DTG
Effective From, 4-Digit Yr
Data set reference; overlay for
mission planning. Establishes
affectivity of message.
Operator Situational
Displays
F2 - Estimated DTG
Effective To, 4-Digit Yr
Data set reference; overlay for
mission planning. Establishes
affectivity of message.
Operator Situational
Displays
Compliance Test
Vehicle
XX
ICD Data
Element
Provides information related to
F1 - Earth Hemisphere and
Operator Situational
location of identified target. Used to
Grid Zone Designator
Displays
plot target on overlay.
F1 - UTM 1-Metre Higher
Order Easting
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F2 - UTM 1-Metre Higher
Order Northing
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F3 - Width in Metres, 19999
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
A1 - 43
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
12
LEGB
F4 - Minimum Altitude in
Metres
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F5 - Maximum Altitude in
Metres
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F1 - UTM 1-Metre Higher
Order Easting
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F2 - UTM 1-Metre Higher
Order Northing
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F3 - Width in Metres, 19999
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F4 - Minimum Altitude in
Metres
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
Compliance Test
Vehicle
XX
ICD Data
Element
A1 - 44
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
F5 - Maximum Altitude in
Metres
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
13
LEGC
F1 - UTM 1-Metre Higher
Order Easting
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
13
LEGC
F2 - UTM 1-Metre Higher
Order Northing
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F3 - Width in Metres, 19999
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F4 - Minimum Altitude in
Metres
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F5 - Maximum Altitude in
Metres
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
Compliance Test
Vehicle
XX
ICD Data
Element
A1 - 45
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
14
15
LEGD
LEGE
F1 - UTM 1-Metre Higher
Order Easting
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F2 - UTM 1-Metre Higher
Order Northing
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F3 - Width in Metres, 19999
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F4 - Minimum Altitude in
Metres
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F5 - Maximum Altitude in
Metres
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F1 - UTM 1-Metre Higher
Order Easting
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
Compliance Test
Vehicle
XX
ICD Data
Element
A1 - 46
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
Compliance Test
Vehicle
XX
ICD Data
Element
Provides data to draw and display
F2 – UTM 1-Metre Higher
Operator Situational
air corridor on map. Used for
Order Northing
Displays
mission planning.
16
LEGF
F3 - Width in Metres, 19999
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F4 - Minimum Altitude in
Metres
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F5 - Maximum Altitude in
Metres
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F1 - UTM 1-Metre Higher
Order Easting
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F2 - UTM 1-Metre Higher
Order Northing
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
A1 - 47
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
F3 - Width in Metres, 19999
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F4 - Minimum Altitude in
Metres
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
16
LEGF
F5 - Maximum Altitude in
Metres
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
17
LEGG
F1 - UTM 1-Metre Higher
Order Easting
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F2 - UTM 1-Metre Higher
Order Northing
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F3 - Width in Metres, 19999
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
Compliance Test
Vehicle
XX
ICD Data
Element
A1 - 48
Edition A Version 1
AEP-84.1
Seq/
Data Element Name & Description
Data Intent
HCI Component
SETID
18
LEGH
F4 - Minimum Altitude in
Metres
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F5 - Maximum Altitude in
Metres
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F1 - UTM 1-Metre Higher
Order Easting
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
F2 - UTM 1-Metre Higher
Order Northing
Provides data to draw and display
Operator Situational
air corridor on map. Used for
Displays
mission planning.
Compliance Test
Vehicle
XX
ICD Data
Element
A1 - 49
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
A070
SPRT.GEOM
3
MSGID
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Support-Battlefield Geometry
F1 - Message Text
Format Identifier
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Operator
Situational
Displays
F2 - Originator
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Operator
Situational
Displays
Data set reference; maybe used in
F3 - Message Serial operator display and associated
Number
with object in overlays for mission
planning.
Operator
Situational
Displays
F4 - Month Name
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Operator
Situational
Displays
F5 - Qualifier
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
Operator
Situational
Displays
A1 - 50
Edition A Version 1
AEP-84.1
Seq/
SETID
6
7
Data Element Name &
Description
OPT
DUR
Data Intent
HCI Component Compliance Test
F6 – Serial Number
of Qualifier
Data set reference; maybe used in
operator display and associated
with object in overlays for mission
planning.
F1 - Primary Option
Provides information related to
Operator
battlefield geometry to the operator Situational
in display for mission planning.
Displays
F2 - Secondary
Option
Provides information related to
Operator
battlefield geometry to the operator Situational
in display for mission planning.
Displays
Vehicle XX
ICD Data Element
Operator
Situational
Displays
F1 - Estimated DTG
Operator
Established affectivity for message
Effective from, 4
Situational
set. Used for mission planning.
Digit Yr
Displays
F2 - Estimated DTG
Operator
Established affectivity for message
Effective to, 4 Digit
Situational
set. Used for mission planning.
Yr
Displays
8
BGEOM
F1 - Battlefield
Geometry Type
Used for creating battle field
geometry as map overlay.
Operator
Situational
Displays
F2 - Battlefield
Geometry Type
Name
Maybe used as label for battlefield
in map overlay.
Operator
Situational
Displays
A1 - 51
Edition A Version 1
AEP-84.1
Seq/
SETID
11
12
13
Data Element Name &
Description
PNTNCG
CIR
GZE
Data Intent
HCI Component Compliance Test
Geographic points of battlefield to
F1 - Sequence Point
be used to draw and display
Number (1-30)
battlefield zone as map overlay.
Operator
Situational
Displays
Geographic points of battlefield to
F2 - UTM 1-Metre
be used to draw and display
Higher Order Easting
battlefield zone as map overlay.
Operator
Situational
Displays
F3 - UTM 1-Metre
Higher Order
Northing
Geographic points of battlefield to
be used to draw and display
battlefield zone as map overlay.
Operator
Situational
Displays
Geographic points of battlefield to
F1 - UTM 1-Metre
be used to draw and display
Higher Order Easting
battlefield zone as map overlay.
Operator
Situational
Displays
F2 - UTM 1-Metre
Higher Order
Northing
Geographic points of battlefield to
be used to draw and display
battlefield zone as map overlay.
Operator
Situational
Displays
F3 - Radius in
Metres, 10-9999
Geographic points of battlefield to
be used to draw and display
battlefield zone as map overlay.
Operator
Situational
Displays
F1 - Earth
Hemisphere and
Grid Zone
Designator
Geographic points of battlefield to
be used to draw and display
battlefield zone as map overlay.
Operator
Situational
Displays
Vehicle XX
ICD Data Element
A1 - 52
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
14
ARE
F1 - Ammunition
Restricted
Established ammunition restrictions Operator
in battlefield zone. Maybe used as Situational
label for map overlay.
Displays
15
BDY
F1 - Boundary
Identifier
Maybe used as label to identify
units near battlefield zone.
A080
FRAGO
Fragmentary Order
MSGID
F1 - Message Text
Format Identifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F2 - Originator
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
3
Vehicle XX
ICD Data Element
Operator
Situational
Displays
Data set reference; maybe used in
Operator
F3 - Message Serial operator display and associated with
Situational
Number
object in overlays for mission
Displays
planning.
F4 - Month Name
Operator
Data set reference; maybe used in Situational
operator display and associated with Displays
A1 - 53
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
object in overlays for mission
planning.
19
EORGID
22
LOCATION
F5 - Qualifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F6 - Serial Number
of Qualifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F1 - Unit
Designation Name
Operator
Used as label to identify enemy unit
Situational
on overlay. For mission planning.
Displays
F1 - Stage of
Confirmation
Provides information related to
enemy position. Can be plotted or
labelled on overlay.
Operator
Situational
Displays
Provides information related to
F2 - Type of Graphic
enemy position. Can be plotted or
Shape
labelled on overlay.
Operator
Situational
Displays
Provides information related to
F3 - Grid Reference
enemy position. Can be plotted or
Location Coordinate
labelled on overlay.
Operator
Situational
Displays
A1 - 54
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F1 - Unit
Designation Name
Provides information related to
enemy position. Can be plotted or
labelled on overlay.
Operator
Situational
Displays
LOCNF
F1 - Geographic
Place Name
Provides information related to
enemy position. Can be plotted or
labelled on overlay.
Operator
Situational
Displays
27
LOCNF
F2 - UTM Grid
Reference
Provides information related to
enemy position. Can be plotted or
labelled on overlay.
Operator
Situational
Displays
32
ORGID
F1 - Unit
Designation Name
Used to identify other forces. Used
as label in map overlay.
Operator
Situational
Displays
33
LOCNF
F1 - Geographic
Place Name
Geographic feature and position
near other forces. Used for label
and/or display as map overlay.
Operator
Situational
Displays
F2 - UTM Grid
Reference
Geographic feature and position
near other forces. Used for label
and/or display as map overlay.
Operator
Situational
Displays
F1 - Unit
Designation Name
Used as label to identify name of
adjacent organisational unit.
Operator
Situational
Displays
26
EORGBDRY
27
36
ORGIDBDY
Vehicle XX
ICD Data Element
A1 - 55
Edition A Version 1
AEP-84.1
Seq/
SETID
37
Data Element Name &
Description
LOCNF
Data Intent
HCI Component Compliance Test
F1 - Geographic
Place Name
Geographic feature and position
Operator
near other adjacent units. Used for Situational
label and/or display as map overlay. Displays
F2 - UTM Grid
Reference
Geographic feature and position
Operator
near other adjacent units. Used for Situational
label and/or display as map overlay. Displays
Used as label to identify name of
adjacent organisational unit.
Provides information to plot, label, Operator
and display force locations as a map Situational
overlay.
Displays
50
ORGID
F1 - Unit
Designation Name
52
AREA
F1 - Area Name
Vehicle XX
ICD Data Element
Operator
Situational
Displays
Provides information to plot, label, Operator
F2 - Position or Point
and display force locations as a map Situational
Name
overlay.
Displays
Provides information to plot, label, Operator
and display force locations as a map Situational
overlay.
Displays
53
GRID
F1 - UTM Grid
Reference
54
LINE
Provides information to plot, label, Operator
F1 - Line Designator and display force locations as a map Situational
overlay.
Displays
A1 - 56
Edition A Version 1
AEP-84.1
Seq/
SETID
55
Data Element Name &
Description
TIME
Data Intent
HCI Component Compliance Test
F2 - Line Location
Provides information to plot, label, Operator
and display force locations as a map Situational
overlay.
Displays
F1 - Time Qualifier
Establishes affectivity for UA
mission duration.
Operator
Situational
Displays
F2 - Date-Time
Indicator
Establishes affectivity for UA
mission duration.
Operator
Situational
Displays
56
ROUTESP
F1 - UTM Grid
Reference
Information used to plot, label, and
display UA route points as map
overlay.
Operator
Situational
Displays
56
ROUTESP
F2 - Geographic
Place Name
Information used to plot, label, and
display UA route points as map
overlay.
Operator
Situational
Displays
57
ROUTEIP
F1 - Intermediate
Point Number
Information used to plot, label, and
display UA route points as map
overlay.
Operator
Situational
Displays
F2 - UTM Grid
Reference
Information used to plot, label, and
display UA route points as map
overlay.
Operator
Situational
Displays
Vehicle XX
ICD Data Element
A1 - 57
Edition A Version 1
AEP-84.1
Seq/
SETID
58
59
Data Element Name &
Description
ROUTERP
TIME
62
ORGIDBDY
63
LOCNF
Data Intent
HCI Component Compliance Test
F3 - Geographic
Place Name
Information used to plot, label, and
display UA route points as map
overlay.
Operator
Situational
Displays
F1 - UTM Grid
Reference
Information used to plot, label, and
display UA route points as map
overlay.
Operator
Situational
Displays
F2 - Geographic
Place Name
Information used to plot, label, and
display UA route points as map
overlay.
Operator
Situational
Displays
F1 - Time Qualifier
Provides for the validity of UA
mission affectivity.
Operator
Situational
Displays
F2 - Date-Time
Indicator
Provides for the validity of UA
mission affectivity.
Operator
Situational
Displays
F1 - Unit
Designation Name
Label to designate friendly forces.
Operator
Situational
Displays
F1 - Geographic
Place Name
Information used to draw, label, and Operator
display the position of friendly
Situational
forces.
Displays
Vehicle XX
ICD Data Element
A1 - 58
Edition A Version 1
AEP-84.1
Seq/
SETID
64
78
Data Element Name &
Description
TIME
AREA
Data Intent
HCI Component Compliance Test
F2 - UTM Grid
Reference
Information used to draw, label, and Operator
display the position of friendly
Situational
forces.
Displays
F1 - Time Qualifier
Provides for the validity of mission
affectivity.
Operator
Situational
Displays
F2 - Date-Time
Indicator
Provides for the validity of mission
affectivity.
Operator
Situational
Displays
F1 - Area Name
Information used to draw, label, and Operator
display the position of friendly
Situational
forces.
Displays
Vehicle XX
ICD Data Element
Information used to draw, label, and Operator
F2 - Position or Point
display the position of friendly
Situational
Name
forces.
Displays
F011
3
ACO
MSGID
Airspace Control Order
F1 - Message Text
Format Identifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
A1 - 59
Edition A Version 1
AEP-84.1
Seq/
SETID
3
Data Element Name &
Description
MSGID
F2 - Originator
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
Data set reference; maybe used in
Operator
F3 - Message Serial operator display and associated with
Situational
Number
object in overlays for mission
Displays
planning.
5
ACOID
F4 - Month Name
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F5 - Qualifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F6 - Serial Number
of Qualifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
Information related to airspace
F1 - Name of Area of
control. Used to plot or label on
Validity
overlay.
Operator
Situational
Displays
A1 - 60
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
F2 - ACO Serial
Number
7
10
Information related to airspace
control. Used to plot or label on
overlay.
HCI Component Compliance Test
Operator
Situational
Displays
Information related to affectivity of
F2 - Stop Day-Time airspace control. Used to plot or
label on overlay.
Operator
Situational
Displays
Information related to affectivity of
airspace control. Used to plot or
label on overlay.
Operator
Situational
Displays
F1 - Airspace
ACMSTAT Control Means
Status
Information related to airspace
control. Used to plot or label on
overlay.
Operator
Situational
Displays
NATO
RESTRICTED
Information related to airspace
control. Used to plot or label on
overlay.
Operator
Situational
Displays
F1 - Airspace
Control Means
Information related to airspace
control. Used to plot or label on
overlay.
Operator
Situational
Displays
ACMID
Vehicle XX
ICD Data Element
Operator
Situational
Displays
Information related to affectivity of
F1 - Start Day-Time airspace control. Used to plot or
label on overlay.
PERIOD
F3 - Day-Time
9
Data Intent
A1 - 61
Edition A Version 1
AEP-84.1
Seq/
SETID
12
Data Element Name &
Description
POLYARC
Data Intent
HCI Component Compliance Test
F2 - Airspace
Control Means
Identifier
Information related to airspace
control. Used to plot or label on
overlay.
Operator
Situational
Displays
F3 – Type of
Airspace Shape
Information related to airspace
control. Used to plot or label on
overlay.
Operator
Situational
Displays
Information related to airspace
F4 - Airspace Usage control. Used to plot or label on
overlay.
Operator
Situational
Displays
F1 - Origin of
Bearing
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Operator
Situational
Displays
F2 - Beginning
Radial Bearing,
Degrees True
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
Information related to location of
F3 - Radius, M, KM,
controlled airspace. Used to plot or
NM
label on overlay.
Mission Planning
Displays
F4 - Ending Radial
Bearing, Degrees
True
Mission Planning
Displays
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Vehicle XX
ICD Data Element
A1 - 62
Edition A Version 1
AEP-84.1
Seq/
SETID
13
14
Data Element Name &
Description
RADARC
1TRACK
Data Intent
HCI Component Compliance Test
F5 - Points
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
F1 - Bearing Origin
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
F2 - Beginning
Radial Bearing,
Degrees True
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
F3 - Ending Radial
Bearing, Degrees
True
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
F4 - Inner Radius,
m, km, nm
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
F5 - Outer Radius,
m, km, nm
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
F1 - Track Leg
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
Vehicle XX
ICD Data Element
A1 - 63
Edition A Version 1
AEP-84.1
Seq/
SETID
15
16
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F2 - Leg-Begin
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
F3 - Leg-End
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
F4 - Leg-Width
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
F5 - Min-Max Alt
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
Information related to location of
POLYGON F1 - Polygon Points controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
Information related to location of
F2 - Radius, m, km,
controlled airspace. Used to plot or
nm
label on overlay.
Mission Planning
Displays
CIRCLE
F1 - Circle Centre
Vehicle XX
ICD Data Element
A1 - 64
Edition A Version 1
AEP-84.1
Seq/
SETID
17
Data Element Name &
Description
CORRIDOR
Data Intent
HCI Component Compliance Test
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
Information related to location of
F2 - Position or Point controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
F1 - Width, m, km,
nm
18
APOINT
F1 - Airspace Point
19
AORBIT
Information related to location of
F1 - First Point of the
controlled airspace. Used to plot or
Orbit
label on overlay.
Mission Planning
Displays
Information related to location of
F2 - Second Point of
controlled airspace. Used to plot or
the Orbit
label on overlay.
Mission Planning
Displays
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
Information related to location of
F4 - Orbit Alignment controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
F3 - Width, m, km,
nm
Vehicle XX
ICD Data Element
A1 - 65
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
20
Information related to location of
GEOLINE F1 - Position or Point controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
21
EFFLEVEL
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Mission Planning
Displays
22
F1 - Airspace Time
APERIOD
Mode
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Operator
Situational
Displays
F2 - Day-Time and
Month of Start
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Operator
Situational
Displays
F3 - Stop Time
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Operator
Situational
Displays
F4 - Interval
Frequency
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Operator
Situational
Displays
F5 - Interval
Duration
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Operator
Situational
Displays
F1 - Vertical
Dimension
Vehicle XX
ICD Data Element
A1 - 66
Edition A Version 1
AEP-84.1
Seq/
SETID
23
F032
3
Data Element Name &
Description
CNTRLPT
HCI Component Compliance Test
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Operator
Situational
Displays
Information related to location of
F2 - Position or Point
controlled airspace. Used to plot or
Name
label on overlay.
Operator
Situational
Displays
F3 - Control Point
Location
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Operator
Situational
Displays
F4 - Control Point
Altitude
Information related to location of
controlled airspace. Used to plot or
label on overlay.
Operator
Situational
Displays
F1 - Control Point
Type
ORBATAIR
MSGID
Data Intent
Vehicle XX
ICD Data Element
Order of Battle - Air Forces
F1 - Message Text
Format Identifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F2 - Originator
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
A1 - 67
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Data set reference; maybe used in
Operator
F3 - Message Serial operator display and associated with
Situational
Number
object in overlays for mission
Displays
planning.
10
ORGIDRPT
F4 - Month Name
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F5 - Qualifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F6 - Serial Number
of Qualifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F1 - Unit
Designation Name
Order of battle data set; overlay for
mission planning.
Mission Planning
Displays
F10 - Unit
Identification Code
Order of battle data set; overlay for
mission planning.
Mission Planning
Displays
F2 - Unit Size
Indicator
Order of battle data set; overlay for
mission planning.
Mission Planning
Displays
A1 - 68
Edition A Version 1
AEP-84.1
Seq/
SETID
10
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F3 - Geographical
Entity
Order of battle data set; overlay for
mission planning.
Mission Planning
Displays
F4 - Unit Role
Indicator Code “A”
Order of battle data set; overlay for
mission planning.
Mission Planning
Displays
F5 - Unit Role
Indicator Code “B”
Order of battle data set; overlay for
mission planning.
Mission Planning
Displays
F6 - Unit Role
Indicator Code “C”
Order of battle data set; overlay for
mission planning.
Mission Planning
Displays
F7 - Unit Role
Indicator Code “D”
Order of battle data set; overlay for
mission planning.
Mission Planning
Displays
F8 - Higher
Formation Name
Order of battle data set; overlay for
mission planning.
Mission Planning
Displays
Order of battle data set; overlay for
mission planning.
Mission Planning
Displays
F9 - Armed Service
ORGIDRPT or Civilian Agency
Code
11
CEFT
F1 - Combat
Effectiveness
Order of battle data set; overlay for
mission planning.
Mission Planning
Displays
13
UNST
F1 - Unit Readiness Order of battle data set; overlay for
Status
mission planning.
Mission Planning
Displays
Vehicle XX
ICD Data Element
A1 - 69
Edition A Version 1
AEP-84.1
Seq/
SETID
16
17
Data Element Name &
Description
LOCA
LOCB
DPLOY
HCI Component Compliance Test
F2 - Unit Availability Order of battle data set; overlay for
Status
mission planning
Mission Planning
Displays
F3 - Unit Assignment Order of battle data set; overlay for
Status
mission planning.
Mission Planning
Displays
F3 - Peacetime
Location
Order of battle data set; overlay for
mission planning.
Mission Planning
Displays
F4 - Unit Identifier
Order of battle data set; overlay for
mission planning.
Mission Planning
Displays
F3 - Peacetime
Location
Order of battle data set; overlay for
mission planning.
Mission Planning
Displays
F4 - Estimated Time Order of battle data set; overlay for
of Arrival
mission planning.
Mission Planning
Displays
Order of battle data set; overlay for
mission planning.
Mission Planning
Displays
F1 - DTG of Arrival, Order of battle data set; overlay for
4 Digit Yr
mission planning.
Mission Planning
Displays
F4 - Arrival Grid
Order of battle data set; overlay for
Reference Location
mission planning.
Coordinate
Mission Planning
Displays
F5 - Unit Identifier
18
Data Intent
Vehicle XX
ICD Data Element
A1 - 70
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
F5 - Estimated DayOrder of battle data set; overlay for
Time and Month of
mission planning.
Departure
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Mission Planning
Displays
A1 - 71
Edition A Version 1
AEP-84.1
Seq/
SETID
F058
3
Data Element Name &
Description
ATO
MSGID
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Air Tasking Order
F1 - Message Text
Format Identifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F2 - Originator
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
Data set reference; maybe used in
Operator
F3 - Message Serial operator display and associated with
Situational
Number
object in overlays for mission
Displays
planning.
3
MSGID
F4 - Month Name
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F5 - Qualifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
A1 - 72
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
F6 - Serial Number
of Qualifier
7
TIMEFRAM
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
Operator
F1 - DTG of Start, 4 Data set used to establish period of
Situational
Digit Yr
mission validity.
Displays
Operator
F2 - DTG of Stop, 4 Data set used to establish period of
Situational
Digit Yr
mission validity.
Displays
F3 - As of DTG, 4
Digit Yr
11
Operator
Data set used to establish period of
Situational
mission validity.
Displays
F1 - Geographic
CNXMSN Entities, Notional
and Actual
Data set provides information on
cancelled missions; used for
mission planning.
Operator
Situational
Displays
F2 - Tasked Unit
Designator
Data set provides information on
cancelled missions; used for
mission planning.
Operator
Situational
Displays
Data set provides information on
F3 - Mission Number cancelled missions; used for
mission planning.
Operator
Situational
Displays
A1 - 73
Edition A Version 1
AEP-84.1
Seq/
SETID
13
Data Element Name &
Description
F1 - Geographic
TSKCNTRY Entities, Notional
and Actual
F1 - Armed Service
Code
Data Intent
HCI Component Compliance Test
Operator
Data set used for mission planning. Situational
Displays
SVCTASK
15
F1 - Tasked Unit
TASKUNIT
Designator
Operator
Data set used for mission planning. Situational
Displays
F2 - Tasked Unit
Location
Operator
Data set used for mission planning. Situational
Displays
F3 - Comments
Operator
Data set used for mission planning. Situational
Displays
AMSNDAT F1 - Mission Number
F2 - AMC Mission
Number or Event
Number
ICD Data Element
Operator
Data set used for mission planning. Situational
Displays
14
25
Vehicle XX
Data set used for aircraft mission
planning.
Mission Planning
Displays
Data set used for aircraft mission
planning.
Mission Planning
Displays
A1 - 74
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
F3 - Package
Identification
25
Mission Planning
Displays
Data set used for aircraft mission
planning.
Mission Planning
Displays
Data set used for aircraft mission
planning.
Mission Planning
Displays
F6 - Secondary
Data set used for aircraft mission
Aerial Mission Type planning.
Mission Planning
Displays
F7 - Air Alert Status
Data set used for aircraft mission
planning.
Mission Planning
Displays
F8 - Departure
Location
Data set used for aircraft mission
planning. For use in map overlays.
Mission Planning
Displays
F9 - Recovery
Location
Data set used for aircraft mission
planning. For use in map overlays.
Mission Planning
Displays
F1 - Number of
Aircraft
Data set used for aircraft mission
planning.
Mission Planning
Displays
F2 - Type of Aircraft
Data set used for aircraft mission
planning.
Mission Planning
Displays
F4 - Mission
AMSNDAT Commander
Designator
MSNACFT
HCI Component Compliance Test
Data set used for aircraft mission
planning.
F5 - Primary Aerial
Mission Type
26
Data Intent
Vehicle XX
ICD Data Element
A1 - 75
Edition A Version 1
AEP-84.1
Seq/
SETID
29
30
Data Element Name &
Description
ROUTE
1MSNRTE
Data Intent
HCI Component Compliance Test
F3 - Aircraft Call
Sign, Abbreviated
Data set used for aircraft mission
planning.
Mission Planning
Displays
F4 - Primary
Configuration Code
Data set used for aircraft mission
planning.
Mission Planning
Displays
F5 - Secondary
Configuration Code
Data set used for aircraft mission
planning.
Mission Planning
Displays
F6 - IFF/SIF Mode
and Code, NonHyphenated
Data set used for aircraft mission
planning.
Mission Planning
Displays
F1 - Day-Time of
Position
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F2 - Route Point
Name
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F3 - Track/Route
Type
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F1 - Related Route
Name
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
Vehicle XX
ICD Data Element
A1 - 76
Edition A Version 1
AEP-84.1
Seq/
SETID
30
Data Element Name &
Description
HCI Component Compliance Test
F2 - Day-Time and
Month of Route
Entry
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F3 - Entry Point
Name
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
Location and mission execution
F5 - Exit Point Name information used for mission
planning.
Mission Planning
Displays
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F4 - Day-Time of
1MSNRTE
Route Exit
F6 - True Airspeed
in Knots
33
Data Intent
F1 - Day-Time and
AMSNLOC
Month of Start
F2 - Day-Time and
Month of Stop
Vehicle XX
ICD Data Element
Provides UA mission tasking. This
data is used to construct the mission Mission Planning
plan that is used to load into UA
Displays
mission parameters
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
A1 - 77
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
HCI Component Compliance Test
Location and mission execution
F3 - Location Name information used for mission
planning.
Mission Planning
Displays
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
Location and mission execution
F5 - Mission Priority,
information used for mission
Literal
planning.
Mission Planning
Displays
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
F11 - Desired Mean
Point of Impact
Target information to be used as
Elevation in Feet or icon label or map overlay.
Metres
Operator
Situational
Displays
F4 - Altitude in
Hundreds of Feet
F6 - Location
34
Data Intent
F1 GTGTLOC Primary/Alternate
Target Designator
F10 - Geodetic
Datum
Vehicle XX
ICD Data Element
A1 - 78
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Operator
Situational
Displays
F13 - Target Priority, Target information to be used as
Literal
icon label or map overlay.
Operator
Situational
Displays
F14 - Additional
Target information to be used as
Target Identification
icon label or map overlay.
Features
Operator
Situational
Displays
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
F3 - Not Earlier Than Target information to be used as
Day-Time and Month icon label or map overlay.
Operator
Situational
Displays
F4 - NLT Time
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
F5 - Target/Facility
Name
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
F2 - Time On Target
GTGTLOC
HCI Component Compliance Test
Target information to be used as
icon label or map overlay.
F12 - Component
Target Identifier
34
Data Intent
Vehicle XX
ICD Data Element
A1 - 79
Edition A Version 1
AEP-84.1
Seq/
SETID
35
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F6 - Target Position Target information to be used as
Identifier
icon label or map overlay.
Operator
Situational
Displays
F7 - Target Type
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
F8 - Desired Mean
Point of Impact
Description
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
F9 - Desired Mean
Point of Impact
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
F10 - Day-Time of
Position
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
F11 - Ship Location
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
SHIPTGT F1 - Time On Target
Vehicle XX
ICD Data Element
A1 - 80
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F12 - Component
Target Identifier
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
F13 - Course in
Degrees, True
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
F14 - Speed in
Knots, Decimal
Prohibited
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
F2 - Not Earlier Than Target information to be used as
Day-Time and Month icon label or map overlay.
Operator
Situational
Displays
F3 - NLT Time
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
F4 - Ship Target
Identity
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
F5 - Ship Type
Category
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
Vehicle XX
ICD Data Element
A1 - 81
Edition A Version 1
AEP-84.1
Seq/
SETID
35
37
Data Element Name &
Description
SHIPTGT
Data Intent
HCI Component Compliance Test
F6 - Special Hull
Number
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
F7 - Ship Name,
Abbreviated
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
F8 - Target Priority
Identifier
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
F9 - Target Priority,
Literal
Target information to be used as
icon label or map overlay.
Operator
Situational
Displays
Location and mission execution
RECCEDAT F1 - Mission Priority information used for mission
planning.
Vehicle XX
ICD Data Element
Mission Planning
Displays
F10 - Imagery
Coverage Extent
and Mode
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F11 Reconnaissance
Mission Purpose
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
A1 - 82
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F12 - Type of
Intelligence Task
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F13 - Component
Target Identifier
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F14 - Target
Category Code
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F15 - Essential
Location and mission execution
Elements of
information used for mission
Information (EEI) of
planning.
Target Category
Mission Planning
Displays
F2 - Day-Time and
Month Over Target
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F3 - Net Time
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F4 - NLT Time
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
Vehicle XX
ICD Data Element
A1 - 83
Edition A Version 1
AEP-84.1
Seq/
SETID
38
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F5 - DTG of Latest Location and mission execution
Time of Intelligence information used for mission
Value, 4 Digit Yr
planning.
Mission Planning
Displays
F6 Reconnaissance
Mission Type
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F7 - Type of
Reconnaissance/
Surveillance
Coverage
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F8 - Sensor Type
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
Location and mission execution
F9 - Image Qualifier information used for mission
planning.
Mission Planning
Displays
F1 - Location of
PTRCPLOT Reconnaissance
Mission
Location and mission execution
information used for mission
planning.
Operator
Situational
Displays
Location and mission execution
F2 - Target Identifier information used for mission
planning.
Operator
Situational
Displays
Vehicle XX
ICD Data Element
A1 - 84
Edition A Version 1
AEP-84.1
Seq/
SETID
38
Data Element Name &
Description
PTRCPLOT
HCI Component Compliance Test
Location and mission execution
information used for mission
planning.
Operator
Situational
Displays
Location and mission execution
F4 - Geodetic Datum information used for mission
planning.
Operator
Situational
Displays
Location and mission execution
information used for mission
planning.
Operator
Situational
Displays
F3 - Area
Description
F5 - Trace Point
40
Data Intent
IMDATLNK F1 - Frequency
Vehicle XX
ICD Data Element
Information for set up of imagery
Mission Planning
data link; used for mission planning. Displays
F2 - Imagery
Receiver Call Sign
Information for set up of imagery
Mission Planning
data link; used for mission planning. Displays
F3 - Report-In Point
Information for set up of imagery
Mission Planning
data link; used for mission planning. Displays
F4 - Day-Time of
Link Start
Information for set up of imagery
Mission Planning
data link; used for mission planning. Displays
F5 - Day-Time of
Link Stop
Information for set up of imagery
Mission Planning
data link; used for mission planning. Displays
A1 - 85
Edition A Version 1
AEP-84.1
Seq/
SETID
41
42
Data Element Name &
Description
REQNO
Data Intent
HCI Component Compliance Test
Location and mission execution
information used for mission
planning.
Operator
Situational
Displays
Target and mission execution
information used for mission
planning.
Operator
Situational
Displays
Target and mission execution
F10 - Target Priority,
information used for mission
Literal
planning.
Operator
Situational
Displays
Target and mission execution
information used for mission
planning.
Operator
Situational
Displays
Target and mission execution
F12 - Desired Mean
information used for mission
Point of Impact
planning.
Operator
Situational
Displays
F13 - Geodetic
Datum
Target and mission execution
information used for mission
planning.
Operator
Situational
Displays
F14 - Aim Point
Suffix
Target and mission execution
information used for mission
planning.
Operator
Situational
Displays
F1 - Request
Identifier
F1 MTGTLOC Primary/Alternate
Target Designator
F11 - Component
Target Identifier
Vehicle XX
ICD Data Element
A1 - 86
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
MTGTLOC
HCI Component Compliance Test
Target and mission execution
F2 - Mission Number information used for mission
planning.
Operator
Situational
Displays
Target and mission execution
F3 - Time On Target information used for mission
planning.
Operator
Situational
Displays
Target and mission execution
information used for mission
planning.
Operator
Situational
Displays
Target and mission execution
F5 - Not Later Than
information used for mission
Day-Time
planning.
Operator
Situational
Displays
Target and mission execution
F6 - Target Identifier information used for mission
planning.
Operator
Situational
Displays
F7 - Target Type
Target and mission execution
information used for mission
planning.
Operator
Situational
Displays
F8 - Type of Cruise
Missile
Target and mission execution
information used for mission
planning.
Operator
Situational
Displays
F4 - Net Time
42
Data Intent
Vehicle XX
ICD Data Element
A1 - 87
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
F9 – Number of
Missiles
45
46
Data Intent
Target and mission execution
information used for mission
planning.
HCI Component Compliance Test
Mission Planning
Displays
Location and mission execution
F2 - Control Agency
information used for mission
Call Sign, Extended
planning.
Mission Planning
Displays
F3 - Primary
Frequency
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F4 - Secondary
Frequency
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
Location and mission execution
F5 - Report-In Point information used for mission
planning.
Mission Planning
Displays
F1 - Primary Aerial
Mission Type
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
ICD Data Element
Operator
Situational
Displays
Location and mission execution
CONTROL F1 - Type of Aircraft
information used for mission
A
Control Agency
planning.
ASUPTFOR
Vehicle XX
Mission Planning
Displays
A1 - 88
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F2 - Tasked Unit
Designator
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F3 – Mission
Number
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F4 - Aircraft Call
Sign, Abbreviated
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F5 - Number of
Aircraft
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
Provides information related to
F6 - Type of Aircraft mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F7 – Primary
Frequency
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F8 - Secondary
Frequency
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
Vehicle XX
ICD Data Element
A1 - 89
Edition A Version 1
AEP-84.1
Seq/
SETID
47
Data Element Name &
Description
ASUPTBY
Data Intent
HCI Component Compliance Test
F1 - Primary Aerial
Mission Type
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F2 - Tasked Unit
Designator
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
Provides information related to
F3 - Mission Number mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F4 - Aircraft Call
Sign, Abbreviated
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F5 - Number of
Aircraft
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
Provides information related to
F6 - Type of Aircraft mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F7 - Primary
Frequency
Vehicle XX
ICD Data Element
A1 - 90
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
49
FACINFOR
HCI Component Compliance Test
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
Provides information related to
F1 - Control Agency
mission routes. Can be plotted or
Call Sign, Extended
labelled on overlay.
Mission Planning
Displays
F2 - Primary
Frequency
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F3 - Secondary
Frequency
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F4 - Contact Point
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F5 - Unit
Identification Code,
Specific
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F8 - Secondary
Frequency
48
Data Intent
Provides information related to
8FACSCHD F1 - Mission Number mission routes. Can be plotted or
labelled on overlay.
Vehicle XX
ICD Data Element
Operator
Situational
Displays
A1 - 91
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F2 - Attack Aircraft
Call Sign
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Operator
Situational
Displays
F3 - Arrival Time
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Operator
Situational
Displays
F4 - Number of
Aircraft
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Operator
Situational
Displays
F5 - Aircraft Type
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Operator
Situational
Displays
F6 - Primary
Configuration Code
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Operator
Situational
Displays
49
8FACSCHD
50
6EWDATA F1 - Emitter Identifier
Vehicle XX
ICD Data Element
Information related to EW data. Can Mission Planning
be plotted or labelled on overlay.
Displays
F2 - ELINT Notation Information related to EW data. Can Mission Planning
or Sorting Code
be plotted or labelled on overlay.
Displays
F3 - Radio/Radar
Function
Information related to EW data. Can Mission Planning
be plotted or labelled on overlay.
Displays
A1 - 92
Edition A Version 1
AEP-84.1
Seq/
SETID
51
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F4 - Lower
Frequency
Information related to EW data. Can Mission Planning
be plotted or labelled on overlay.
Displays
F5 - Upper
Frequency
Information related to EW data. Can Mission Planning
be plotted or labelled on overlay.
Displays
F6 - Electronic
Attack (ES)
Technique
Information related to EW data. Can Mission Planning
be plotted or labelled on overlay.
Displays
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F2 - Route Point
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F3 - Route Point
Name
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F4 - Arrival Time
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
6ROUTE F1 - Point Number
Vehicle XX
ICD Data Element
A1 - 93
Edition A Version 1
AEP-84.1
Seq/
SETID
54
Data Element Name &
Description
CHAFF
Data Intent
HCI Component Compliance Test
F5 - Speed of
Movement in mph,
kps, kph or mps
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F6 - Altitude in
Hundreds of Feet
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F1 - Type of Chaff
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F2 - Lower
Frequency
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F3 - Upper
Frequency
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F4 - Lower Flight
Provides information related to
Level in Hundreds of mission routes. Can be plotted or
Feet
labelled on overlay.
Mission Planning
Displays
F5 - Upper Flight
Provides information related to
Level in Hundreds of mission routes. Can be plotted or
Feet
labelled on overlay.
Mission Planning
Displays
Vehicle XX
ICD Data Element
A1 - 94
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
54
CHAFF
55
LANDSTS
Data Intent
HCI Component Compliance Test
F6 - Mechanical
Jamming
Techniques
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
F1 - Mission
Location
Provides information related to
Mission Planning
friendly landing site. Can be plotted
Displays
or labelled on overlay.
F2 - Enemy Action
Status
Provides information related to
Mission Planning
friendly landing site. Can be plotted
Displays
or labelled on overlay.
Vehicle XX
ICD Data Element
Mission Planning
Displays
Provides information related to
Mission Planning
F3 - Day-Time As Of friendly landing site. Can be plotted
Displays
or labelled on overlay.
F4 - Method of
Marking Friendly
Positions
Provides information related to
Mission Planning
friendly landing site. Can be plotted
Displays
or labelled on overlay.
F5 - Colour
Provides information related to
Mission Planning
friendly landing site. Can be plotted
Displays
or labelled on overlay.
F6 - Contact Name
or Call Sign
Provides information related to
Mission Planning
friendly landing site. Can be plotted
Displays
or labelled on overlay.
A1 - 95
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Provides information related to
F7 - Primary
Mission Planning
friendly landing site. Can be plotted
Frequency or Phone
Displays
or labelled on overlay.
Provides information related to
F8 - Secondary
Mission Planning
friendly landing site. Can be plotted
Frequency or Phone
Displays
or labelled on overlay.
56
Provides information related to
GNDFRND F1 - Time of Position friendly ground forces. Can be
plotted or labelled on overlay.
Mission Planning
Displays
Provides information related to
friendly ground forces. Can be
plotted or labelled on overlay.
Mission Planning
Displays
Provides information related to
F3 - Geodetic Datum friendly ground forces. Can be
plotted or labelled on overlay.
Mission Planning
Displays
F4 - Method of
Marking Friendly
Positions
Provides information related to
friendly ground forces. Can be
plotted or labelled on overlay.
Mission Planning
Displays
Provides information related to
friendly ground forces. Can be
plotted or labelled on overlay.
Mission Planning
Displays
F2 - Friendly Unit
Location
56
GNDFRND F5 - Colour
A1 - 96
Edition A Version 1
AEP-84.1
Seq/
SETID
57
60
Data Element Name &
Description
PGMINFO
ASACSDAT
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Provides information related to laser
F1 - Laser/Data Link
Mission Planning
guided munitions. Can be plotted or
Code
Displays
labelled on overlay.
F2 - Guidance
Frequency
Provides information related to laser
Mission Planning
guided munitions. Can be plotted or
Displays
labelled on overlay.
F3 - Contact Call
Sign
Provides information related to laser
Mission Planning
guided munitions. Can be plotted or
Displays
labelled on overlay.
F4 - Primary
Frequency
Provides information related to laser
Mission Planning
guided munitions. Can be plotted or
Displays
labelled on overlay.
F4 - Secondary
Frequency
Provides information related to laser
Mission Planning
guided munitions. Can be plotted or
Displays
labelled on overlay.
Location and mission execution
F1 - Type of Aircraft
information used for mission
Control Agency
planning.
Mission Planning
Displays
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F2 - Call Sign of
Control Agency
A1 - 97
Edition A Version 1
AEP-84.1
Seq/
SETID
61
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F3 - Tasked
Equipment
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F4 - Aerial Mission
Type
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F5 - State of
Emission
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F6 - Operational
Control Authority
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F7 - Primary
Frequency
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
F8 - Secondary
Frequency
Location and mission execution
information used for mission
planning.
Mission Planning
Displays
Provides information related to
7CONTROL F1 - Mission Number mission routes. Can be plotted or
labelled on overlay.
Vehicle XX
ICD Data Element
Mission Planning
Displays
A1 - 98
Edition A Version 1
AEP-84.1
Seq/
SETID
61
64
Data Element Name &
Description
7CONTROL
NAVFLTOP
Data Intent
HCI Component Compliance Test
F2 - Aircraft Call
Sign, Abbreviated
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F3 - Number of
Aircraft
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
Provides information related to
F4 - Type of Aircraft mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F5 - Aerial Mission
Type
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F6 - Day-Time on
Station
Provides information related to
mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
Provides information related to
F7 - Report-In Point mission routes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F1 - Ship Name,
Abbreviated
Vehicle XX
ICD Data Element
Provides information related to Navy Operator
flight operations. Can be plotted or Situational
labelled on overlay.
Displays
A1 - 99
Edition A Version 1
AEP-84.1
Seq/
SETID
65
66
Data Element Name &
Description
FYFCE
AAXIS
Data Intent
HCI Component Compliance Test
F2 - Day-Time and
Month of Start
Provides information related to Navy Operator
flight operations. Can be plotted or Situational
labelled on overlay.
Displays
F3 - Day-Time and
Month of Stop
Provides information related to Navy Operator
flight operations. Can be plotted or Situational
labelled on overlay.
Displays
F4 - Scheduled
Launch/Recovery
Time
Provides information related to Navy Operator
flight operations. Can be plotted or Situational
labelled on overlay.
Displays
F1 - Unit
Provides information related to
friendly forces. Can be plotted or
labelled on overlay.
Operator
Situational
Displays
Provides information related to
F2 - Number of
friendly forces. Can be plotted or
Cooperating Forces
labelled on overlay.
Operator
Situational
Displays
F3 - Cooperating
Forces
Provides information related to
friendly forces. Can be plotted or
labelled on overlay.
Operator
Situational
Displays
F1 - Geographic
Position, Lat/Long,
Minutes
Provides information related to
friendly forces. Can be plotted or
labelled on overlay.
Mission Planning
Displays
Vehicle XX
ICD Data Element
A1 - 100
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F2 - Day-Time of
Position
Provides information related to
friendly forces. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F3 - Course in
Degrees, True
Provides information related to
friendly forces. Can be plotted or
labelled on overlay.
Mission Planning
Displays
Provides information related to
F4 - Speed in Knots,
friendly forces. Can be plotted or
Decimal Prohibited
labelled on overlay.
Mission Planning
Displays
F5 - Bearing (001360) in Degrees,
True
Provides information related to
friendly forces. Can be plotted or
labelled on overlay.
Mission Planning
Displays
66
AAXIS
F6 - Zone Angle in
Degrees
Provides information related to
friendly forces. Can be plotted or
labelled on overlay.
Mission Planning
Displays
67
FYLOC
Discrete Identifier
Provides information related to
friendly forces. Can be plotted or
labelled on overlay.
Operator
Situational
Displays
Provides information related to
F1 - Unit Designator friendly forces. Can be plotted or
labelled on overlay.
Operator
Situational
Displays
Vehicle XX
ICD Data Element
A1 - 101
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
CODES
HCI Component Compliance Test
Provides information related to
friendly forces. Can be plotted or
labelled on overlay.
Operator
Situational
Displays
Provides information related to
F3 - Geodetic Datum friendly forces. Can be plotted or
labelled on overlay.
Operator
Situational
Displays
F4 - Time
Provides information related to
friendly forces. Can be plotted or
labelled on overlay.
Operator
Situational
Displays
F5 - Course and
Speed
Provides information related to
friendly forces. Can be plotted or
labelled on overlay.
Operator
Situational
Displays
F6 - Geographic
Entities, Notional
and Actual
Provides information related to
friendly forces. Can be plotted or
labelled on overlay.
Operator
Situational
Displays
F2 - Unit Location
68
Data Intent
Provides information related to
F1 - Codes-Crypto In
crypto codes. Can be plotted or
Use
labelled on overlay.
Mission Planning
Displays
Provides information related to
crypto codes. Can be plotted or
labelled on overlay.
Mission Planning
Displays
F2 - Code Day
Number
Vehicle XX
ICD Data Element
A1 - 102
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
F3 - Authentication
System
69
IFF
3
Seq/
SETID
IFFPROD
MSGID
Provides information related to
crypto codes. Can be plotted or
labelled on overlay.
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Mission Planning
Displays
Provides information related to IFF
F1 - Supporting Unit
Mission Planning
codes. Can be plotted or labelled on
or Base
Displays
overlay.
F2 - IFF/SIF Mode
and Code or
Condition
J017
Data Intent
Provides information related to IFF
Mission Planning
codes. Can be plotted or labelled on
Displays
overlay.
IFF Procedures
F1 - Message Text
Format Identifier
Data Element Name &
Description
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
Data Intent
HCI Component Compliance Test
C4I Node XX
ICD Data Element
A1 - 103
Edition A Version 1
AEP-84.1
3
MSGID
F2 - Originator
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F3 - Message Serial
Number
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F4 - Month Name
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F5 - Qualifier
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
Data set reference; maybe used in
Operator
F6- Serial Number of operator display and associated
Situational
Qualifier
with object in overlays for mission
Displays
planning.
6
Seq/
EFFAREA
F1 - IFF Effective
Area
Provides information related to IFF
Mission Planning
affected area. Can be plotted or
Displays
labelled on overlay.
Data Intent
HCI Component Compliance Test
C4I Node XX
A1 - 104
Edition A Version 1
AEP-84.1
SETID
7
8
9
Data Element Name &
Description
ICD Data Element
F1 - Day-Time and
Month of Start
Provides information related to
Mission Planning
valid duration of IFF codes. Can be
Displays
plotted or labelled on overlay.
F2 - Day-Time and
Month of Stop
Provides information related to
Mission Planning
valid duration of IFF codes. Can be
Displays
plotted or labelled on overlay.
F3 - IFF Mode
Provides information related to IFF
Mission Planning
codes. Can be plotted or labelled
Displays
on overlay.
F1 - Day-Time and
Month of Start
Provides information related to
Mission Planning
valid duration of IFF codes. Can be
Displays
plotted or labelled on overlay.
F2 - Day-Time and
Month of Stop
Provides information related to
Mission Planning
valid duration of IFF codes. Can be
Displays
plotted or labelled on overlay.
F3 - Combined IFF
Modes
Provides information related to IFF
Mission Planning
codes. Can be plotted or labelled
Displays
on overlay.
F1 - Day-Time and
IFFCODE
Month of Start
Provides information related to
Mission Planning
valid duration of IFF codes. Can be
Displays
plotted or labelled on overlay.
IFFMODE
CMBMODE
A1 - 105
Edition A Version 1
AEP-84.1
Seq/
SETID
10
11
J033
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F2 - Day-Time and
Month of Stop
Provides information related to
Mission Planning
valid duration of IFF codes. Can be
Displays
plotted or labelled on overlay.
F3 - IFF/SIF Code
Provides information related to IFF
Mission Planning
codes. Can be plotted or labelled
Displays
on overlay.
F1 - Effective DayTime & Month
Provides information related to
Mission Planning
valid duration of IFF codes. Can be
Displays
plotted or labelled on overlay.
F2 - Cancelled IFF
Mode
Provides information related to IFF
Mission Planning
codes. Can be plotted or labelled
Displays
on overlay.
F1 - Effective DayCNXCODE
Time & Month
Provides information related to
Mission Planning
valid duration of IFF codes. Can be
Displays
plotted or labelled on overlay.
F2 - IFF/SIF Code
Provides information related to IFF
Mission Planning
codes. Can be plotted or labelled
Displays
on overlay.
CNXMODE
NBC4
C4I Node XX
ICD Data Element
NBC 4 Report
A1 - 106
Edition A Version 1
AEP-84.1
Seq/
SETID
3
Data Element Name &
Description
MSGID
Data Intent
HCI Component Compliance Test
F1 - Message Text
Format Identifier
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F2 - Originator
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F3 - Message Serial
Number
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F4 - Month Name
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F5 - Qualifier
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
C4I Node XX
ICD Data Element
A1 - 107
Edition A Version 1
AEP-84.1
Data set reference; maybe used in
Operator
F6 - Serial Number of operator display and associated
Situational
Qualifier
with object in overlays for mission
Displays
planning.
Seq/
SETID
Data Element Name &
Description
7
ORGID
8
NBCEVENT
10
HOTEL
Data Intent
HCI Component Compliance Test
F1 - Unit Designation Data set reference; overlay for
Name
mission planning.
Mission Planning
Displays
F1 - Type of NBC
Report
Data set reference; overlay for
mission planning.
Mission Planning
Displays
F1 - Type of Nuclear
burst or Bio/Chem
release height
Type of NBC agent; overlay for
mission planning.
Mission Planning
Displays
F2 - Type of
Bio/Chem agent,
Type of NBC agent; overlay for
ROTA nuclear or toxic mission planning.
Ind. material
Mission Planning
Displays
Type of NBC agent; overlay for
mission planning.
Mission Planning
Displays
F3 - Persistency
C4I Node XX
ICD Data Element
A1 - 108
Edition A Version 1
AEP-84.1
13
ROMEO
F1 - Radiation dose
rate in CGY/Hr
Provides information related to
radiation. Can be used to plot or
label on overlay.
Mission Planning
Displays
13
ROMEO
F2 - Dose rate trend
Provides information related to
radiation. Can be used to plot or
label on overlay.
Mission Planning
Displays
Provides information related to
F3 - Radiation Decay
radiation. Can be used to plot or
Rate
label on overlay.
Mission Planning
Displays
Seq/
SETID
J034
3
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
NBC5
NBC 5 Report
MSGID
F1 - Message Text
Format Identifier
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F2 - Originator
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
C4I Node XX
ICD Data Element
A1 - 109
Edition A Version 1
AEP-84.1
Seq/
SETID
F3 - Message Serial
Number
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F4 - Month Name
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F5 - Qualifier
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
C4I Node XX
ICD Data Element
Data set reference; maybe used in
Operator
F6 - Serial Number of operator display and associated
Situational
Qualifier
with object in overlays for mission
Displays
planning.
7
ORGID
8
NBCEVENT
F1 - Unit Designation NBC planning information. Used
Name
for comments or label on overlay.
Mission Planning
Displays
F1 - Type of NBC
Report
Mission Planning
Displays
NBC planning information. Used
for comments or label on overlay.
A1 - 110
Edition A Version 1
AEP-84.1
10
DELTA
F1 - DTG, Zulu, 4 Yr
NBC planning information. Used
for comments or label on overlay.
Mission Planning
Displays
11
HOTEL
F1 - Type of Nuclear
Burst or Bio/Chem
Release Height
NBC planning information. Used
for comments or label on overlay.
Mission Planning
Displays
F2 – Type of
Bio/Chem agent,
NBC planning information. Used
ROTA nuclear or toxic for comments or label on overlay.
Ind. material
Mission Planning
Displays
F3 - Persistency
NBC planning information. Used
for comments or label on overlay.
Mission Planning
Displays
F1 - DTG, Zulu, 4 Yr
NBC planning information. Used
for comments or label on overlay.
Mission Planning
Displays
12
Seq/
SETID
OSCAR
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
16
UNIFORM
F1 - Red 1000
Radiation contour information.
CGY/Hr Contour Line Used to plot or label on overlay.
Mission Planning
Displays
17
VICTOR
F1 - Green 300
Radiation contour information.
CGY/Hr Contour Line Used to plot or label on overlay.
Mission Planning
Displays
C4I Node XX
ICD Data Element
A1 - 111
Edition A Version 1
AEP-84.1
18
J065
3
Seq/
SETID
WHISKEY
F1 - Blue 100 CGY/Hr Radiation contour information.
Contour Line
Used to plot or label on overlay.
EWSTOPJAM
MSGID
Mission Planning
Displays
Electronic Warfare Stop Jamming Message
F1 - Message Text
Format Identifier
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F2 - Originator
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F3 - Message Serial
Number
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
Data Element Name &
Description
F4 - Month Name
Data Intent
HCI Component Compliance Test
C4I Node XX
ICD Data Element
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
A1 - 112
Edition A Version 1
AEP-84.1
F5 - Qualifier
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
Data set reference; maybe used in
Operator
F6 - Serial Number of operator display and associated
Situational
Qualifier
with object in overlays for mission
Displays
planning.
7
J066
3
Seq/
SETID
3
Data set reference; maybe used in
Operator
operator display and associated
STOPJAM F1 - Radio Frequency
Situational
with object in overlays for mission
Displays
planning.
EWRTM
MSGID
Electronic Warfare Requesting/Tasking Message
F1 - Message Text
Format Identifier
Data Element Name &
Description
MSGID
F2 - Originator
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
Data Intent
HCI Component Compliance Test
C4I Node XX
ICD Data Element
Operator
Data set reference; maybe used in Situational
operator display and associated
Displays
A1 - 113
Edition A Version 1
AEP-84.1
with object in overlays for mission
planning.
F3 - Message Serial
Number
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F4 - Month Name
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F5 - Qualifier
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
Data set reference; maybe used in
Operator
F6 - Serial Number of operator display and associated
Situational
qualifier
with object in overlays for mission
Displays
planning.
9
TASKUNIT
F1 - Tasked Unit
Designator
Seq/
SETID
Data Element Name &
Description
Provides information related to a
Mission Planning
tasked unit. Can be used as icon or
Displays
label on overlay.
Data Intent
HCI Component Compliance Test
C4I Node XX
ICD Data Element
A1 - 114
Edition A Version 1
AEP-84.1
10
F2 - Tasked Unit
Location
Provides information related to
location of a tasked unit. Can be
used plot or label on overlay.
Mission Planning
Displays
F3 - Comments
Provides information related to a
tasked unit. Can be used as
comments or label on overlay.
Mission Planning
Displays
5ECMTGT F1 - Data Entry
Provides information related to
location of a tasked unit. Can be
used plot or label on overlay.
Mission Planning
Displays
Provides information related to
F4 - Emitter Location location of a target. Can be used
plot or label on overlay.
Mission Planning
Displays
Provides information related to a
Mission Planning
F5 - Target Call Sign target. Can be used as comments
Displays
or label on overlay.
F6 - Enemy Unit
Designator
11
5ETGINFO F1 - Data Entry
Provides information related to a
Mission Planning
target. Can be used as comments
Displays
or label on overlay.
Provides information related to a
Mission Planning
target. Can be used as comments
Displays
or label on overlay.
A1 - 115
Edition A Version 1
AEP-84.1
Seq/
SETID
11
Data Element Name &
Description
5ETGINFO
Data Intent
HCI Component Compliance Test
F2 - Emitter Spot
Number
Provides information related to a
Mission Planning
target. Can be used as comments
Displays
or label on overlay.
F3 - Transmit Radio
Frequency
Provides information related to a
Mission Planning
target. Can be used as comments
Displays
or label on overlay.
C4I Node XX
ICD Data Element
Provides information related to a
F4 - Radio Frequency
Mission Planning
target. Can be used as comments
Bandwidth
Displays
or label on overlay.
12
F5 - Signal Type
Provides information related to a
Mission Planning
target. Can be used as comments
Displays
or label on overlay.
F6 - Radio/Radar
Function
Provides information related to a
Mission Planning
target. Can be used as comments
Displays
or label on overlay.
5ECMACT F1 - Data Entry
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
A1 - 116
Edition A Version 1
AEP-84.1
F2 - Day-Time On
Seq/
SETID
Data Element Name &
Description
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Data Intent
Mission Planning
Displays
HCI Component Compliance Test
F3 - Day-Time Off
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
F4 - Mission Priority
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
F5 - Electronic
Countermeasures
Type
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
F6 - Electronic
Countermeasures
Technique
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
C4I Node XX
ICD Data Element
A1 - 117
Edition A Version 1
AEP-84.1
13
5ETGFREQ F1 - Data Entry
F2 - Primary Radio
Frequency
Seq/
SETID
13
Data Element Name &
Description
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
Data Intent
HCI Component Compliance Test
Provides information related to
F3 - Secondary Radio electronic countermeasures. Can
5ETGFREQ
Frequency
be used as comments or label on
overlay.
Mission Planning
Displays
F4 - Lower Radio
Frequency Limit
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
F5 - Upper Radio
Frequency Limit
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
C4I Node XX
ICD Data Element
A1 - 118
Edition A Version 1
AEP-84.1
14
Seq/
SETID
Provides information related to
electronic countermeasures. Can
F6 - Pulse Repetition
be used as comments or label on
overlay.
Mission Planning
Displays
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
Provides information related to
electronic countermeasures. Can
F2 - Request Number
be used as comments or label on
overlay.
Mission Planning
Displays
5ESMTGT F1 - Data Entry
Data Element Name &
Description
F3 - Geographical
Entity
Data Intent
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
HCI Component Compliance Test
C4I Node XX
ICD Data Element
Mission Planning
Displays
Provides information related to
location of electronic
Mission Planning
F4 - Emitter Location
countermeasures. Can be used as Displays
comments or label on overlay.
A1 - 119
Edition A Version 1
AEP-84.1
Provides information related to
electronic countermeasures. Can
F5 - Target Call Sign
be used as comments or label on
overlay.
Mission Planning
Displays
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
F6 - Enemy Unit
Designator
15
5ETGINFO F1 - Data Entry
F2 - Emitter Spot
Number
Seq/
SETID
Data Element Name &
Description
F3 - Transmit Radio
Frequency
Data Intent
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
HCI Component Compliance Test
C4I Node XX
ICD Data Element
Mission Planning
Displays
A1 - 120
Edition A Version 1
AEP-84.1
15
16
Provides information related to
F4 - Radio Frequency electronic countermeasures. Can
5ETGINFO
Bandwidth
be used as comments or label on
overlay.
Mission Planning
Displays
F5 - Signal Type
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
F6 - Radio/Radar
Function
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
5ETGFREQ F1 - Data Entry
F2 - Primary Radio
Frequency
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
C4I Node XX
ICD Data Element
A1 - 121
Edition A Version 1
AEP-84.1
17
Provides information related to
F3 - Secondary Radio electronic countermeasures. Can
Frequency
be used as comments or label on
overlay.
Mission Planning
Displays
F4 - Lower Radio
Frequency Limit
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
F5 - Upper Radio
Frequency Limit
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
Provides information related to
electronic countermeasures. Can
F6 - Pulse Repetition
be used as comments or label on
overlay.
Mission Planning
Displays
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
5ESMACT F1 - Data Entry
F2 - Day-Time On
Seq/
Data Intent
HCI Component Compliance Test
C4I Node XX
A1 - 122
Edition A Version 1
AEP-84.1
SETID
Data Element Name &
Description
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
Provides information related to
F4 - Essential
electronic countermeasures. Can
Elements of
be used as comments or label on
Information Category
overlay.
Mission Planning
Displays
Provides information related to
electronic countermeasures. Can
be used as comments or label on
overlay.
Mission Planning
Displays
F1 - Reference
Number
Provides information related to
chaff missions. Can be used as
comments or label on overlay.
Mission Planning
Displays
F2 - Type of Chaff
Provides information related to
chaff missions. Can be used as
comments or label on overlay.
Mission Planning
Displays
F3 - Lower Radio
Frequency
Provides information related to
chaff missions. Can be used as
comments or label on overlay.
Mission Planning
Displays
F3 - Day-Time Off
17
18
5ESMACT F5 - Mission Priority
8CHAFF
ICD Data Element
A1 - 123
Edition A Version 1
AEP-84.1
Seq/
SETID
19
Data Element Name &
Description
8TIMELOC
Data Intent
HCI Component Compliance Test
Provides information related to
F4 - Upper Frequency
chaff missions. Can be used as
Limit
comments or label on overlay.
Mission Planning
Displays
Provides information related to
F5 - Boundary Lower
chaff missions. Can be used as
Limit, Flight Level
comments or label on overlay.
Mission Planning
Displays
Provides information related to
F6 - Boundary Upper
chaff missions. Can be used as
Limit, Flight Level
comments or label on overlay.
Mission Planning
Displays
F7 - Mechanical
Jamming Technique
Provides information related to
chaff missions. Can be used as
comments or label on overlay.
Mission Planning
Displays
F1 - Reference
Number
Provides information related to
chaff missions. Can be used as
comments or label on overlay.
Mission Planning
Displays
F2 - Geographical
Entity
Provides information related to
chaff missions. Can be used as
comments or label on overlay.
Mission Planning
Displays
C4I Node XX
ICD Data Element
A1 - 124
Edition A Version 1
AEP-84.1
F3 - Day-Time On
Seq/
SETID
J071
3
Provides information related to
chaff missions. Can be used as
comments or label on overlay.
Data Element Name &
Description
HCI Component Compliance Test
F4 - Day-Time Off
Provides information related to
chaff missions. Can be used as
comments or label on overlay.
F5 - Start Location
Provides information related to
locations of chaff missions. Can be Mission Planning
used as comments or label on
Displays
overlay.
TRACKREP
MSGID
Data Intent
Mission Planning
Displays
C4I Node XX
ICD Data Element
Mission Planning
Displays
Target Track Report
F1 - Message Text
Format Identifier
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F2 - Originator
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
A1 - 125
Edition A Version 1
AEP-84.1
F3 - Message Serial
Number
Seq/
SETID
Data Element Name &
Description
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
Data Intent
HCI Component Compliance Test
F4 - Month Name
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F5 - Qualifier
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
C4I Node XX
ICD Data Element
Data set reference; maybe used in
Operator
F6 - Serial Number of operator display and associated
Situational
Qualifier
with object in overlays for mission
Displays
planning.
5
F3 - Aircraft Track
ACTKNO
Identification Code
For HCI display: aircraft track
information
Operator
Situational
Displays
A1 - 126
Edition A Version 1
AEP-84.1
6
Seq/
SETID
7
POSN
F1 - Air Track
Position
Provides information on aircraft
Operator
Situational
Displays
F2 - Day-Time of Air
Track
Provides information on aircraft
Operator
Situational
Displays
Data Element Name &
Description
ACTINFO F1 - Heading
F2 - Relative Height,
Alphabetic Format
Data Intent
HCI Component Compliance Test
C4I Node XX
ICD Data Element
Operator
Provides information on aircraft for
Situational
overlay or map display
Displays
Operator
Provides information on aircraft for
Situational
overlay or map display
Displays
Operator
F3 - General indicator Provides information on aircraft for
Situational
of speed
overlay or map display
Displays
F4 - General aircraft
category
Operator
Provides information on aircraft for
Situational
overlay or map display
Displays
A1 - 127
Edition A Version 1
AEP-84.1
Operator
F5 - Aircraft formation Provides information on aircraft for
Situational
size
overlay or map display
Displays
J103
3
Seq/
SETID
RECCEXREP
MSGID
Reconnaissance Exploitation Report
F1 - Message Text
Format Identifier
Data Element Name &
Description
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
Data Intent
HCI Component Compliance Test
F2 - Originator
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F3 - Message Serial
Number
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F4 - Month Name
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
C4I Node XX
ICD Data Element
A1 - 128
Edition A Version 1
AEP-84.1
F5 - Qualifier
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
Data set reference; maybe used in
Operator
F6 - Serial Number of operator display and associated
Situational
Qualifier
with object in overlays for mission
Displays
planning.
7
Seq/
SETID
LOCREF
F1 - Location of
Discriminator
Data Element Name &
Description
F2 - Coordinates
Qualifier
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
Data Intent
HCI Component Compliance Test
C4I Node XX
ICD Data Element
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
Operator
F3 - Reference Point Target location information. Can be
Situational
Type
used to plot or display on overlay.
Displays
F4 - Bearing from
Reference Point
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
A1 - 129
Edition A Version 1
AEP-84.1
10
Seq/
SETID
10
UNITIDD
F5 - Distance from
Reference Point
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
F1 - Geographical
Entity
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
F2 - Identifier
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
F3 - BE Number of
Peacetime Location
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
Data Element Name &
Description
UNITIDD
Data Intent
HCI Component Compliance Test
F4 - Basic
Encyclopaedia
Number Suffix
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
F5 - Armed Service
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
C4I Node XX
ICD Data Element
A1 - 130
Edition A Version 1
AEP-84.1
12
TGTARDES
F6 - Identification
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
F1 – Target Area
Functional Type
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
F2 - Target Area
Description
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
F3 - Target Graphic
Annotation
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
Operator
F4 - Reference Point Target location information. Can be
Situational
of Target Area
used to plot or display on overlay.
Displays
Seq/
SETID
Data Element Name &
Description
F5 - Bearing from
Reference Point in
Degrees, True
Data Intent
HCI Component Compliance Test
C4I Node XX
ICD Data Element
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
A1 - 131
Edition A Version 1
AEP-84.1
22
Seq/
SETID
MAP
F6 - Distance from
Reference Point
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
F1 - Map or Chart
Series Designator
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
F2 - Map or Chart
Suffix Number
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
F3 - Map or Chart
Sheet Number
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
F4 - Map or Chart
Edition Number
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
F5 - Geodetic Datum
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
C4I Node XX
ICD Data Element
A1 - 132
Edition A Version 1
AEP-84.1
23
ADSIGHT
Operator
F1 - Target Category Target location information. Can be
Situational
Code
used to plot or display on overlay.
Displays
F10 - Target Speed
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
Operator
F2 - Target Category Target location information. Can be
Situational
Designator
used to plot or display on overlay.
Displays
23
ADSIGHT
F3 - Target
Description
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
F4 - Number of
Target Elements
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
F5 - Geographical
Entity
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
F6 - Target Location
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
C4I Node XX
ICD Data Element
A1 - 133
Edition A Version 1
AEP-84.1
N003
3
F7 - Target Activity
Description
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
F8 - Day-Time
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
F9 - Target Course
Operator
Target location information. Can be
Situational
used to plot or display on overlay.
Displays
JAMWARN
MSGID
Jamming Warning
F1 - Message Text
Format Identifier
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F2 - Originator
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F3 - Message Serial
Number
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
A1 - 134
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F4 - Month Name
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
F5 - Qualifier
Data set reference; maybe used in
Operator
operator display and associated
Situational
with object in overlays for mission
Displays
planning.
C4I Node XX
ICD Data Element
Data set reference; maybe used in
Operator
F6 - Serial Number of operator display and associated
Situational
Qualifier
with object in overlays for mission
Displays
planning.
5
PERIOD
F1 - Start Day-Time
Information related to affectivity of Operator
jamming. Used for comments or
Situational
label on overlay.
Displays
F2 - Stop Day-Time
Information related to affectivity of Operator
jamming. Used for comments or
Situational
label on overlay.
Displays
A1 - 135
Edition A Version 1
AEP-84.1
F3 - Day-Time
Seq/
SETID
Data Element Name &
Description
6
JAMTYP
7
AREA
8
Information related to affectivity of Operator
jamming. Used for comments or
Situational
label on overlay.
Displays
Data Intent
HCI Component Compliance Test
F1 - Jamming Type,
Name
Information related to jamming.
Used for comments or label on
overlay.
Operator
Situational
Displays
F1 - Area Name
Information related to location of
jamming. Used to plot or label on
overlay.
Operator
Situational
Displays
Information related to location of
F2 - Position or Point
jamming. Used to plot or label on
Name
overlay.
Operator
Situational
Displays
Information related to location of
1ROUTE F1 - Position or Point jamming routes. Used to plot or
label on overlay.
Operator
Situational
Displays
Information related to location of
jamming routes. Used to plot or
label on overlay.
Operator
Situational
Displays
F2 - Day-Time of
Position
C4I Node XX
ICD Data Element
A1 - 136
Edition A Version 1
AEP-84.1
Seq/
SETID
9
F3 - Flight Event
Information related to location of
jamming routes. Used to plot or
label on overlay.
Operator
Situational
Displays
F4 - Flight Level
Information related to location of
jamming routes. Used to plot or
label on overlay.
Operator
Situational
Displays
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
Information related to location of
jamming routes. Used to plot or
label on overlay.
Operator
Situational
Displays
Information related to location of
F2 - Modulation Type jamming routes. Used to plot or
label on overlay.
Operator
Situational
Displays
Information related to location of
jamming routes. Used to plot or
label on overlay.
Operator
Situational
Displays
CHANJAM
F1 - Frequency
D
F3 - Signal Strength
C4I Node XX
ICD Data Element
A1 - 137
Edition A Version 1
AEP-84.1
Seq/
SETID
N023
3
Data Element Name &
Description
GREEN
MSGID
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Maritime Unit Execution Order
F1 - Message Text
Format Identifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F2 - Originator
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
Data set reference; maybe used in
Operator
F3 - Message Serial operator display and associated with
Situational
Number
object in overlays for mission
Displays
planning.
F4 - Month Name
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F5 - Qualifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
A1 - 138
Edition A Version 1
AEP-84.1
Seq/
SETID
5
6
Data Element Name &
Description
PERIOD
MISSN
Data Intent
HCI Component Compliance Test
F6 - Serial Number
of Qualifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F1 - Start Day-Time
Affectivity for mission; overlay for
mission planning.
Operator
Situational
Displays
F2 - Stop Day-Time
Affectivity for mission; overlay for
mission planning.
Operator
Situational
Displays
F3 - Day-Time
Affectivity for mission; overlay for
mission planning.
Operator
Situational
Displays
F1 - Mission
Purpose
Mission/event basic planning
information. Used for comments or
label on overlay.
Operator
Situational
Displays
F2 - MPA Mission
Designator
Mission/event basic planning
information. Used for comments or
label on overlay.
Operator
Situational
Displays
F3 - Mission
Requirements
Mission/event basic planning
information. Used for comments or
label on overlay.
Operator
Situational
Displays
Vehicle XX
ICD Data Element
A1 - 139
Edition A Version 1
AEP-84.1
Seq/
SETID
7
8
Data Element Name &
Description
FORCE
IFF
Data Intent
HCI Component Compliance Test
F4 - Mission
Objective
Mission/event basic planning
information. Used for comments or
label on overlay.
Operator
Situational
Displays
F1 - Unit
Mission/event basic planning
information. Used for comments or
label on overlay.
Operator
Situational
Displays
F2 - Number
Ordered
Mission/event basic planning
information. Used for comments or
label on overlay.
Operator
Situational
Displays
F3 - Platform Type
Mission/event basic planning
information. Used for comments or
label on overlay.
Operator
Situational
Displays
F4 - Platform
Identification
Mission/event basic planning
information. Used for comments or
label on overlay.
Operator
Situational
Displays
Mission/event basic planning
F5 - Mission Number information. Used for comments or
label on overlay.
Operator
Situational
Displays
Mission/event basic planning
F1 - Supporting Unit
information. Used for comments or
or Base
label on overlay.
Mission Planning
Displays
Vehicle XX
ICD Data Element
A1 - 140
Edition A Version 1
AEP-84.1
Seq/
SETID
9
9
Data Element Name &
Description
EVTASK
EVTASK
Data Intent
HCI Component Compliance Test
F2 - IFF/SIF Mode
and Code or
Condition
Mission/event basic planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
F1 - Departure
Location Identifier
Mission/event basic planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
F2 - Day-Time
Mission/event basic planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
Mission/event basic planning
F3 - On Station Time information. Used for comments or
label on overlay.
Mission Planning
Displays
Mission/event basic planning
F4 - Off Station Time information. Used for comments or
label on overlay.
Mission Planning
Displays
Mission/event basic planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
Mission/event basic planning
F6 - Arrival Location
information. Used for comments or
Identifier
label on overlay.
Mission Planning
Displays
F5 - Arrival Time
Vehicle XX
ICD Data Element
A1 - 141
Edition A Version 1
AEP-84.1
Seq/
SETID
10
11
13
Data Element Name &
Description
ALT
ROUTE
TRACK
Data Intent
HCI Component Compliance Test
Mission/event basic planning
F7 - Mission Number information. Used for comments or
label on overlay.
Mission Planning
Displays
Mission/event basic planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
Mission/event basic planning
F2 - Type of Altitude information. Used for comments or
label on overlay.
Mission Planning
Displays
F1 - Day-Time of
Position
Mission/event basic planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
F2 - Route Point
Name
Mission/event basic planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
F3 - Track/Route
Type
Mission/event basic planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
F1 - Search Track
Mission/event basic location
Mission Planning
planning information. Used to plot or
Displays
label on overlay.
F1 - Designated
Altitude Purpose
Vehicle XX
ICD Data Element
A1 - 142
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
14
AREA
Mission/event basic location
F2 - Position or Point
Mission Planning
planning information. Used to plot or
Name
Displays
label on overlay.
15
CIRC
F1 - Position of
Centre of Circle
Vehicle XX
ICD Data Element
Mission/event basic location
Mission Planning
planning information. Used to plot or
Displays
label on overlay.
Mission/event basic location
F2 - Radius, yd, kyd,
Mission Planning
planning information. Used to plot or
or nm
Displays
label on overlay.
16
Mission/event basic location
Mission Planning
ELLIPSE F1 - Ellipse Position planning information. Used to plot or
Displays
label on overlay.
F2 - Orientation of
Semi-Major Axis,
Qualified
Mission/event basic location
Mission Planning
planning information. Used to plot or
Displays
label on overlay.
F3 - Semi-Major Axis Mission/event basic location
Mission Planning
Length, Nautical
planning information. Used to plot or
Displays
Miles
label on overlay.
F4 - Semi-Minor Axis Mission/event basic location
Mission Planning
Length, Nautical
planning information. Used to plot or
Displays
Miles
label on overlay.
A1 - 143
Edition A Version 1
AEP-84.1
Seq/
SETID
17
Data Element Name &
Description
SECTOR F1 - Daytime
F2 - Geographic
Location
17
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Mission/event basic location
Mission Planning
planning information. Used to plot or
Displays
label on overlay.
Mission/event basic location
Mission Planning
planning information. Used to plot or
Displays
label on overlay.
F3 - Inner Radius,
SECTOR
nm
Mission/event basic location
Mission Planning
planning information. Used to plot or
Displays
label on overlay.
F4 - Outer Radius,
nm
Mission/event basic location
Mission Planning
planning information. Used to plot or
Displays
label on overlay.
F5 - Left-most
Bearing, Degrees
True
Mission/event basic location
Mission Planning
planning information. Used to plot or
Displays
label on overlay.
F6 - Right-most
Bearing, Degrees
True
Mission/event basic location
Mission Planning
planning information. Used to plot or
Displays
label on overlay.
F7 - Sector
Reference Number
Mission/event basic location
Mission Planning
planning information. Used to plot or
Displays
label on overlay.
A1 - 144
Edition A Version 1
AEP-84.1
Seq/
SETID
18
Data Element Name &
Description
FYFCE
F1 - Unit
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Mission/event basic location
Operator
planning information. Used to plot or Situational
label friendly forces on overlay.
Displays
Mission/event basic location
Operator
F2 - Number of
planning information. Used to plot or Situational
Cooperating Forces
label friendly forces on overlay.
Displays
19
FYPOS
F3 - Cooperating
Forces
Mission/event basic location
Operator
planning information. Used to plot or Situational
label friendly forces on overlay.
Displays
F1 - Unit
Mission/event basic location
Operator
planning information. Used to plot or Situational
label friendly forces on overlay.
Displays
Mission/event basic location
Operator
F2 - Friendly Forces
planning information. Used to plot or Situational
Position Name
label friendly forces on overlay.
Displays
F3 - Day-Time of
Position
Mission/event basic location
Operator
planning information. Used to plot or Situational
label friendly forces on overlay.
Displays
F4 - Friendly Force
Course and Speed
Mission/event basic location
Operator
planning information. Used to plot or Situational
label friendly forces on overlay.
Displays
A1 - 145
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F5 - Flag
Mission/event basic location
Operator
planning information. Used to plot or Situational
label friendly forces on overlay.
Displays
F6 - Discrete
Identifier
Mission/event basic location
Operator
planning information. Used to plot or Situational
label friendly forces on overlay.
Displays
Mission/event basic location
Operator
planning information. Used to plot or Situational
label friendly forces on overlay.
Displays
20
ISR
F1 - Identification
Safety Range,
Nautical Miles
20
ISR
F2 - Mean Line of
Advance, Degrees
True
Mission/event basic location
Operator
planning information. Used to plot or Situational
label friendly forces on overlay.
Displays
F3 - Speed of
Advance
Mission/event basic location
Operator
planning information. Used to plot or Situational
label friendly forces on overlay.
Displays
F1 - Emission
Control Plan
Identifier
Mission/event basic emission
control planning information. Used
for comments or label on overlay.
Mission Planning
Displays
Mission/event basic emission
F2 - Start Day-Time control planning information. Used
for comments or label on overlay.
Mission Planning
Displays
22
EMCON
Vehicle XX
ICD Data Element
A1 - 146
Edition A Version 1
AEP-84.1
Seq/
SETID
23
Data Element Name &
Description
COMMS
Data Intent
HCI Component Compliance Test
Mission/event basic emission
F3 - Stop Day-Time control planning information. Used
for comments or label on overlay.
Mission Planning
Displays
F1 - Unit
Mission/event basic
communications control planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
F2 - Call Sign
Mission/event basic
communications control planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
F3 - Radio
Frequency
Mission/event basic
communications control planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
F4 - Frequency
Priority
Mission/event basic
communications control planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
F5 - Transmission
Mode
Mission/event basic
communications control planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
Vehicle XX
ICD Data Element
A1 - 147
Edition A Version 1
AEP-84.1
Seq/
SETID
24
Data Element Name &
Description
CODES
Data Intent
HCI Component Compliance Test
Mission/event basic
F1 - Codes-Crypto in communications control planning
Use
information. Used for comments or
label on overlay.
Mission Planning
Displays
F2 - Code Day
Number
Mission/event basic
communications control planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
F3 - Authentication
System
Mission/event basic
communications control planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
Vehicle XX
ICD Data Element
A1 - 148
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
N025
LOCATOR
3
MSGID
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Maritime Force Locator
F1 - Message Text
Format Identifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F2 - Originator
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
Data set reference; maybe used in
Operator
F3 - Message Serial operator display and associated with
Situational
Number
object in overlays for mission
Displays
planning.
F4 - Month Name
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F5 - Qualifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
A1 - 149
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
5
QUEWORD
7
SUB
9
ELLIPSE
Data Intent
HCI Component Compliance Test
F6 - Serial Number
of Qualifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F1 - Maritime
Indicator
Provides information related to
Operator
maritime missions. Can be used as Situational
comments or label on overlay.
Displays
F1 - Contact Serial
Number
Provides information related to
submarine contacts. Can be used
as comments or label on overlay.
Vehicle XX
ICD Data Element
Operator
Situational
Displays
Provides information related to
Operator
F1 - Ellipse Position location of submarine contacts. Can Situational
be used to plot or label on overlay. Displays
F2 - Orientation of
Semi-Major Axis,
Qualified
Provides information related to
Operator
location of submarine contacts. Can Situational
be used to plot or label on overlay. Displays
F3 - Semi-Major Axis Provides information related to
Operator
Length, Nautical
location of submarine contacts. Can Situational
Miles
be used to plot or label on overlay. Displays
F4 - Semi-Minor Axis Provides information related to
Operator
Length, Nautical
location of submarine contacts. Can Situational
Miles
be used to plot or label on overlay. Displays
A1 - 150
Edition A Version 1
AEP-84.1
Seq/
SETID
10
Data Element Name &
Description
CIRC
F1 - Position of
centre of circle
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Provides information related to
Operator
location of submarine contacts. Can Situational
be used to plot or label on overlay. Displays
Provides information related to
Operator
F2 - Radius, yd, kyd
location of submarine contacts. Can Situational
or nm
be used to plot or label on overlay. Displays
11
AREA
F1 – Area Name
Provides information related to
Operator
location of submarine contacts. Can Situational
be used to plot or label on overlay. Displays
Provides information related to
Operator
F2 - Position or Point
location of submarine contacts. Can Situational
Name
be used to plot or label on overlay. Displays
12
13
TIMEVENT F1 - Day-Time
BRNG
Provides information related to
Operator
location of submarine contacts. Can Situational
be used to plot or label on overlay. Displays
F1 - Date-Time
Provides information related to
Operator
location of submarine contacts. Can Situational
be used to plot or label on overlay. Displays
F2 - Bearing Origin
Provides information related to
Operator
location of submarine contacts. Can Situational
be used to plot or label on overlay. Displays
A1 - 151
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F3 - Bearing,
Degrees True
Provides information related to
Operator
location of submarine contacts. Can Situational
be used to plot or label on overlay. Displays
F4 - Sector HalfWidth
Provides information related to
Operator
location of submarine contacts. Can Situational
be used to plot or label on overlay. Displays
Vehicle XX
ICD Data Element
F5 - Line of Bearing Provides information related to
Operator
(LOB) range,
location of submarine contacts. Can Situational
Nautical Miles
be used to plot or label on overlay. Displays
Provides information related to
Operator
F6 - Acoustic Sensor location of submarine contacts. Can Situational
be used to plot or label on overlay. Displays
14
31
TMPOS
NAVAL
F1 - Date-Time
Group
Provides information related to
Operator
location of submarine contacts. Can Situational
be used to plot or label on overlay. Displays
F2 - Geographic
Position
Provides information related to
Operator
location of submarine contacts. Can Situational
be used to plot or label on overlay. Displays
F1 - Contact Serial
Number
Provides information related to
surface contacts. Can be used to
plot or label on overlay.
Operator
Situational
Displays
A1 - 152
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
F2 - Unit
33
ELLIPSE
Data Intent
Provides information related to
surface contacts. Can be used to
plot or label on overlay.
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Operator
Situational
Displays
Provides information related to
Operator
F1 - Ellipse Position location of surface contacts. Can be Situational
used to plot or label on overlay.
Displays
F2 - Orientation of
Semi-Major Axis,
Qualified
Provides information related to
Operator
location of surface contacts. Can be Situational
used to plot or label on overlay.
Displays
F3 - Semi-Major Axis Provides information related to
Operator
Length, Nautical
location of surface contacts. Can be Situational
Miles
used to plot or label on overlay.
Displays
F4 - Semi-Minor Axis Provides information related to
Operator
Length, Nautical
location of surface contacts. Can be Situational
Miles
used to plot or label on overlay.
Displays
34
CIRC
F1 - Position of
centre of circle
Provides information related to
Operator
location of surface contacts. Can be Situational
used to plot or label on overlay.
Displays
Provides information related to
Operator
F2 - Radius, yd, kyd
location of surface contacts. Can be Situational
or nm
used to plot or label on overlay.
Displays
A1 - 153
Edition A Version 1
AEP-84.1
Seq/
SETID
35
Data Element Name &
Description
AREA
F1 - Area Name
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Provides information related to
Operator
location of surface contacts. Can be Situational
used to plot or label on overlay.
Displays
Provides information related to
Operator
F2 - Position or Point
location of surface contacts. Can be Situational
Name
used to plot or label on overlay.
Displays
37
37
BRNG
BRNG
F1 - Date-Time
Provides information related to
Operator
location of surface contacts. Can be Situational
used to plot or label on overlay.
Displays
F2 - Bearing Origin
Provides information related to
Operator
location of surface contacts. Can be Situational
used to plot or label on overlay.
Displays
F3 - Bearing,
Degrees True
Provides information related to
Operator
location of surface contacts. Can be Situational
used to plot or label on overlay.
Displays
F4 - Sector HalfWidth
Provides information related to
Operator
location of surface contacts. Can be Situational
used to plot or label on overlay.
Displays
F5 - Line of Bearing Provides information related to
Operator
(LOB) Range,
location of surface contacts. Can be Situational
Nautical Miles
used to plot or label on overlay.
Displays
A1 - 154
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Provides information related to
Operator
F6 - Acoustic Sensor location of surface contacts. Can be Situational
used to plot or label on overlay.
Displays
38
54
55
TMPOS
AIR
TMPOS
F1 - Date-Time
Group
Provides information related to
Operator
location of surface contacts. Can be Situational
used to plot or label on overlay.
Displays
F2 - Geographic
Position
Provides information related to
Operator
location of surface contacts. Can be Situational
used to plot or label on overlay.
Displays
F1 - Contact Serial
Number
Provides information related to
aircraft contacts. Can be used to
plot or label on overlay.
Operator
Situational
Displays
F2 - Unit
Provides information related to
aircraft contacts. Can be used to
plot or label on overlay.
Operator
Situational
Displays
F1 - Date-Time
Group
Provides information related to
Operator
location of aircraft contacts. Can be Situational
used to plot or label on overlay.
Displays
F2 - Geographic
Position
Provides information related to
Operator
location of aircraft contacts. Can be Situational
used to plot or label on overlay.
Displays
A1 - 155
Edition A Version 1
AEP-84.1
Seq/
SETID
63
65
Data Element Name &
Description
MERCH
ELLIPSE
ELLIPSE
HCI Component Compliance Test
F1 - Contact Serial
Number
Provides information related to
merchant ship contacts. Can be
used to plot or label on overlay.
Operator
Situational
Displays
F2 - Unit
Provides information related to
merchant ship contacts. Can be
used to plot or label on overlay.
Operator
Situational
Displays
Provides information related to
location of merchant ship contacts.
F1 - Ellipse Position
Can be used to plot or label on
overlay.
Operator
Situational
Displays
Provides information related to
location of merchant ship contacts.
Can be used to plot or label on
overlay.
Operator
Situational
Displays
Provides information related to
F3 - Semi-Major Axis
location of merchant ship contacts.
Length, Nautical
Can be used to plot or label on
Miles
overlay.
Operator
Situational
Displays
Provides information related to
F4 - Semi-Minor Axis
location of merchant ship contacts.
Length, Nautical
Can be used to plot or label on
Miles
overlay.
Operator
Situational
Displays
F2 - Orientation of
Semi-Major Axis,
Qualified
65
Data Intent
Vehicle XX
ICD Data Element
A1 - 156
Edition A Version 1
AEP-84.1
Seq/
SETID
66
67
69
Data Element Name &
Description
CIRC
AREA
BRNG
Data Intent
HCI Component Compliance Test
Provides information related to
location of merchant ship contacts.
Can be used to plot or label on
overlay.
Operator
Situational
Displays
Provides information related to
F2 - Radius, yd, kyd location of merchant ship contacts.
or nm
Can be used to plot or label on
overlay.
Operator
Situational
Displays
Provides information related to
location of merchant ship contacts.
Can be used to plot or label on
overlay.
Operator
Situational
Displays
Provides information related to
F2 - Position or Point location of merchant ship contacts.
Name
Can be used to plot or label on
overlay.
Operator
Situational
Displays
F1 - Date-Time
Provides information related to
location of merchant ship contacts.
Can be used to plot or label on
overlay.
Operator
Situational
Displays
F2 - Bearing Origin
Provides information related to
location of merchant ship contacts.
Operator
Situational
Displays
F1 - Position of
centre of circle
F1 - Area Name
Vehicle XX
ICD Data Element
A1 - 157
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Can be used to plot or label on
overlay.
70
TMPOS
F3 - Bearing,
Degrees True
Provides information related to
location of merchant ship contacts.
Can be used to plot or label on
overlay.
Operator
Situational
Displays
F4 - Sector HalfWidth
Provides information related to
location of merchant ship contacts.
Can be used to plot or label on
overlay.
Operator
Situational
Displays
Provides information related to
F5 - Line of Bearing
location of merchant ship contacts.
(LOB) Range,
Can be used to plot or label on
Nautical Miles
overlay.
Operator
Situational
Displays
Provides information related to
location of merchant ship contacts.
F6 - Acoustic Sensor
Can be used to plot or label on
overlay.
Operator
Situational
Displays
Provides information related to
location of merchant ship contacts.
Can be used to plot or label on
overlay.
Operator
Situational
Displays
F1 - Date-Time
Group
A1 - 158
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
70
TMPOS
87
FISHCTC
89
ELLIPSE
Data Intent
HCI Component Compliance Test
F2 - Geographic
Position
Provides information related to
location of merchant ship contacts.
Can be used to plot or label on
overlay.
Operator
Situational
Displays
F1 - Contact Serial
Number
Provides information related to
fishing vessel contacts. Can be
used to plot or label on overlay.
Operator
Situational
Displays
F2 - Unit
Provides information related to
fishing vessel contacts. Can be
used to plot or label on overlay.
Operator
Situational
Displays
Provides information related to
location of fishing vessel contacts.
F1 - Ellipse Position
Can be used to plot or label on
overlay.
Operator
Situational
Displays
Provides information related to
location of fishing vessel contacts.
Can be used to plot or label on
overlay.
Operator
Situational
Displays
Provides information related to
F3 - Semi-Major Axis
location of fishing vessel contacts.
Length, Nautical
Can be used to plot or label on
Miles
overlay.
Operator
Situational
Displays
F2 – Orientation of
Semi-Major Axis,
Qualified
Vehicle XX
ICD Data Element
A1 - 159
Edition A Version 1
AEP-84.1
Seq/
SETID
90
91
93
Data Element Name &
Description
CIRC
AREA
BRNG
Data Intent
HCI Component Compliance Test
Provides information related to
F4 - Semi-Minor Axis
location of fishing vessel contacts.
Length, Nautical
Can be used to plot or label on
Miles
overlay.
Operator
Situational
Displays
Provides information related to
location of fishing vessel contacts.
Can be used to plot or label on
overlay.
Operator
Situational
Displays
Provides information related to
F2 - Radius, yd, kyd location of fishing vessel contacts.
or nm
Can be used to plot or label on
overlay.
Operator
Situational
Displays
Provides information related to
location of fishing vessel contacts.
Can be used to plot or label on
overlay.
Operator
Situational
Displays
Provides information related to
F2 - Position or Point location of fishing vessel contacts.
Name
Can be used to plot or label on
overlay.
Operator
Situational
Displays
Provides information related to
location of fishing vessel contacts.
Operator
Situational
Displays
F1 - Position of
Centre of Circle
F1 - Area Name
F1 - Date-Time
Vehicle XX
ICD Data Element
A1 - 160
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Can be used to plot or label on
overlay.
93
BRNG
F2 - Bearing Origin
Provides information related to
location of fishing vessel contacts.
Can be used to plot or label on
overlay.
Operator
Situational
Displays
F3 - Bearing,
Degrees True
Provides information related to
location of fishing vessel contacts.
Can be used to plot or label on
overlay.
Operator
Situational
Displays
F4 - Sector HalfWidth
Provides information related to
location of fishing vessel contacts.
Can be used to plot or label on
overlay.
Operator
Situational
Displays
Provides information related to
F5 - Line of Bearing
location of fishing vessel contacts.
(LOB) Range,
Can be used to plot or label on
Nautical Miles
overlay.
Operator
Situational
Displays
Provides information related to
location of fishing vessel contacts.
F6 - Acoustic Sensor
Can be used to plot or label on
overlay.
Operator
Situational
Displays
A1 - 161
Edition A Version 1
AEP-84.1
Seq/
SETID
94
110
112
Data Element Name &
Description
TMPOS
UNK
ELLIPSE
Data Intent
HCI Component Compliance Test
F1 - Date-Time
Group
Provides information related to
location of fishing vessel contacts.
Can be used to plot or label on
overlay.
Operator
Situational
Displays
F2 - Geographic
Position
Provides information related to
location of fishing vessel contacts.
Can be used to plot or label on
overlay.
Operator
Situational
Displays
F1 - Contact Serial
Number
Provides information related to
unknown contacts. Can be used to
plot or label on overlay.
Operator
Situational
Displays
F2 – Trademark or
Discrete Identifier
Provides information related to
unknown contacts. Can be used to
plot or label on overlay.
Operator
Situational
Displays
Provides information related to
F1 - Ellipse Position location of unknown contacts. Can
be used to plot or label on overlay.
Operator
Situational
Displays
F2 - Orientation of
Semi-Major Axis,
Qualified
Operator
Situational
Displays
Provides information related to
location of unknown contacts. Can
be used to plot or label on overlay.
Vehicle XX
ICD Data Element
A1 - 162
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F3 - Semi-Major Axis Provides information related to
Length, Nautical
location of unknown contacts. Can
Miles
be used to plot or label on overlay.
Operator
Situational
Displays
F4 - Semi-Minor Axis Provides information related to
Length, Nautical
location of unknown contacts. Can
Miles
be used to plot or label on overlay.
Operator
Situational
Displays
Provides information related to
location of unknown contacts. Can
be used to plot or label on overlay.
Operator
Situational
Displays
113
CIRC
F1 - Position of
Centre of Circle
113
CIRC
Provides information related to
F2 - Radius, yd, kyd
location of unknown contacts. Can
or nm
be used to plot or label on overlay.
Operator
Situational
Displays
114
AREA
F1 - Area Name
Provides information related to
location of unknown contacts. Can
be used to plot or label on overlay.
Operator
Situational
Displays
Provides information related to
F2 - Position or Point
location of unknown contacts. Can
Name
be used to plot or label on overlay.
Operator
Situational
Displays
Provides information related to
location of unknown contacts. Can
be used to plot or label on overlay.
Operator
Situational
Displays
116
BRNG
F1 - Date-Time
Vehicle XX
ICD Data Element
A1 - 163
Edition A Version 1
AEP-84.1
Seq/
SETID
117
Data Element Name &
Description
TMPOS
Data Intent
HCI Component Compliance Test
F2 - Bearing Origin
Provides information related to
location of unknown contacts. Can
be used to plot or label on overlay.
Operator
Situational
Displays
F3 - Bearing,
Degrees True
Provides information related to
location of unknown contacts. Can
be used to plot or label on overlay.
Operator
Situational
Displays
F4 - Sector HalfWidth
Provides information related to
location of unknown contacts. Can
be used to plot or label on overlay.
Operator
Situational
Displays
F5 - Line of Bearing Provides information related to
(LOB) Range,
location of unknown contacts. Can
Nautical Miles
be used to plot or label on overlay.
Operator
Situational
Displays
Provides information related to
F6 - Acoustic Sensor location of unknown contacts. Can
be used to plot or label on overlay.
Operator
Situational
Displays
F1 - Date-Time
Group
Provides information related to
location of unknown contacts. Can
be used to plot or label on overlay.
Operator
Situational
Displays
F2 - Geographic
Position
Provides information related to
location of unknown contacts. Can
be used to plot or label on overlay.
Operator
Situational
Displays
Vehicle XX
ICD Data Element
A1 - 164
Edition A Version 1
AEP-84.1
Seq/
SETID
N028
3
3
Data Element Name &
Description
OPTASK AIR
MSGID
MSGID
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Operational Tasking Organic Aircraft
F1 - Message Text
Format Identifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F2 - Originator
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F3 - Message Serial
Number
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F4 - Month Name
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F5 - Qualifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
A1 - 165
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Data set reference; maybe used in
Operator
F6 - Serial Number of operator display and associated with
Situational
Qualifier
object in overlays for mission
Displays
planning.
5
6
PERIOD
SORTIE
F2 - Stop Day-Time
Mission/event basic planning
information for mission duration.
Used for comments or label on
overlay.
Operator
Situational
Displays
F3 - Day-Time
Mission/event basic planning
information for mission duration.
Used for comments or label on
overlay.
Operator
Situational
Displays
F1 - Number of
Sorties
Mission/event basic planning
information. Used for comments or
label on overlay.
Operator
Situational
Displays
F10 - Alternate
Mission/event basic planning
Frequency Designator information. Used for comments or
or Channel
label on overlay.
Operator
Situational
Displays
Mission/event basic planning
F11 - Type of Aircraft
information. Used for comments or
Control
label on overlay.
Operator
Situational
Displays
A1 - 166
Edition A Version 1
AEP-84.1
Seq/
SETID
6
Data Element Name &
Description
SORTIE
Data Intent
HCI Component Compliance Test
F2 - Parent Unit
Mission/event basic planning
information. Used for comments or
label on overlay.
Operator
Situational
Displays
F3 - NATO Aircraft
Number and Type
Mission/event basic planning
information. Used for comments or
label on overlay.
Operator
Situational
Displays
F4 - Call Sign
Mission/event basic planning
information. Used for comments or
label on overlay.
Operator
Situational
Displays
Mission/event basic planning
F5 - Aircraft Weapon
information. Used for comments or
Load
label on overlay.
Operator
Situational
Displays
F6 - Start Time
Mission/event basic planning
information. Used for comments or
label on overlay.
Operator
Situational
Displays
F7 - Stop Time
Mission/event basic planning
information. Used for comments or
label on overlay.
Operator
Situational
Displays
F8 - Mission Type
Mission/event basic planning
information. Used for comments or
label on overlay.
Operator
Situational
Displays
Vehicle XX
ICD Data Element
A1 - 167
Edition A Version 1
AEP-84.1
Seq/
SETID
9
10
11
Data Element Name &
Description
ISR
IFF
SELFID
Data Intent
HCI Component Compliance Test
F9 - Primary
Mission/event basic planning
Frequency Designator information. Used for comments or
or Channel
label on overlay.
Operator
Situational
Displays
F1 - Identification
Safety Range,
Nautical Miles
Mission/event basic planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
F2 - Mean Line of
Advance, Degrees
True
Mission/event basic planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
F3 - Speed of
Advance
Mission/event basic planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
F1 - Supporting Unit
or Base
Mission/event basic planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
F2 - IFF/SIF Mode
and Code or
Condition
Mission/event basic planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
F1 - ID Checkpoint
Name
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
Vehicle XX
ICD Data Element
A1 - 168
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
F2 - Location
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
Mission/event location planning
F3 - Self Identification
Mission Planning
information. Used to plot or label on
Recognition
Displays
overlay.
12
Mission/event location planning
Mission Planning
REFPOINT F1 - Reference Point information. Used to plot or label on
Displays
overlay.
Mission/event location planning
Mission Planning
F2 - Point Designator information. Used to plot or label on
Displays
overlay.
F3 - Location
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
F4 - Effective Time
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
F5 - Flight Level of
Altitude
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
A1 - 169
Edition A Version 1
AEP-84.1
Seq/
SETID
13
Data Element Name &
Description
APPRSECT
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Mission/event location planning
F1 - Approach Sector
Mission Planning
information. Used to plot or label on
Letter or Number
Displays
overlay.
Mission/event location planning
Mission Planning
F2 - Origin of Position information. Used to plot or label on
Displays
overlay.
F3 - Bearing,
Qualified
13
APPRSECT
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
Mission/event location planning
F4 - Angle either side
Mission Planning
information. Used to plot or label on
of Axis
Displays
overlay.
F5 - Lower Altitude
Limit
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
F6 - Upper Altitude
Limit
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
F7 - Safety Distance
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
A1 - 170
Edition A Version 1
AEP-84.1
Seq/
SETID
14
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F8 - Start Time
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
F9 - End Time
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
MARSHAL F1 - Location Name
Vehicle XX
ICD Data Element
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
Mission/event location planning
F2 - Marshalling Point
Mission Planning
information. Used to plot or label on
Position
Displays
overlay.
Mission/event location planning
F3 - Altitude or Flight
Mission Planning
information. Used to plot or label on
Level
Displays
overlay.
15
APPRCOR
F1 - Approach
Corridor Identifier
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
F10 - End Time
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
A1 - 171
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
F11 - Checkpoint
Name
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
F12 - Checkpoint
Distance
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
F13 - Approach
Speed in Knots
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
F2 - Origin Call Sign
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
F3 - Bearing,
Qualified
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
Vehicle XX
ICD Data Element
Mission/event location planning
Mission Planning
F4 - Width of Corridor information. Used to plot or label on
Displays
overlay.
F5 - Length
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
A1 - 172
Edition A Version 1
AEP-84.1
Seq/
SETID
15
16
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Mission/event location planning
Mission Planning
APPRCOR F6 - TACAN Channel information. Used to plot or label on
Displays
overlay.
ALTSEP
F7 - Lower Altitude
Limit
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
F8 - Upper Altitude
Limit
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
F9 - Start Time
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
F1 - Aircraft Mission
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
F2 - Lower Altitude
Limit
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
F3 - Upper Altitude
Limit
Mission/event location planning
Mission Planning
information. Used to plot or label on
Displays
overlay.
A1 - 173
Edition A Version 1
AEP-84.1
Seq/
SETID
N068
3
Data Element Name &
Description
OPTASKEW
MSGID
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Operational Tasking Electronic Warfare
F1 - Message Text
Format Identifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F2 - Originator
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F3 - Message Serial
Number
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F4 - Month Name
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
F5 - Qualifier
Data set reference; maybe used in
Operator
operator display and associated with
Situational
object in overlays for mission
Displays
planning.
A1 - 174
Edition A Version 1
AEP-84.1
Seq/
SETID
Data Element Name &
Description
Data Intent
HCI Component Compliance Test
Vehicle XX
ICD Data Element
Data set reference; maybe used in
Operator
F6 - Serial Number of operator display and associated with
Situational
Qualifier
object in overlays for mission
Displays
planning.
5
PERIOD
F1 - Start Day-Time
Mission/event EW planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
F2 - Stop Day-Time
Mission/event EW planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
5
PERIOD
F3 - Day-Time
Mission/event EW planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
7
EMLIST
Mission/event EW planning
F1 - Emitter Category information. Used for comments or
label on overlay.
Mission Planning
Displays
F2 - SPOT Number
Mission/event EW planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
F3 - Emitter NATO
Nickname or
Designation
Mission/event EW planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
A1 - 175
Edition A Version 1
AEP-84.1
Seq/
SETID
9
Data Element Name &
Description
HCI Component Compliance Test
Mission/event EW planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
Mission/event EW planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
Mission/event EW planning
F3 - Frequency Limits
information. Used for comments or
or SPOT Number
label on overlay.
Mission Planning
Displays
Mission/event EW planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
Mission/event EW planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
Mission/event EW planning
F3 - Frequency Limits
information. Used for comments or
or Spot Number
label on overlay.
Mission Planning
Displays
Mission/event EW planning
information. Used for comments or
label on overlay.
Mission Planning
Displays
ESMTASK F1 - Unit
F2 - Equipment
Designator
10
Data Intent
JAMTASK F1 - Platform
F2 - Jammer
Equipment Type
F4 - Jammer Alert
State
Vehicle XX
ICD Data Element
A1 - 176
Edition A Version 1
AEP-84.1
Table ATT A1 - 2: Parsed Field Utilization
A1 - 177
Edition A Version 1
AEP-84.1
ANNEX 2
HUMAN COMPUTER INTERFACE REQUIREMENTS
A2 Human Computer Interface Requirements Implementation
The intent of this section of the document is to provide unambiguous interpretation of
the UCS HCI requirements. The HCI is the operator’s interface to the CUCS. The figure
below depicts a high level functional architecture for the HCI as it is applied for the 5
LOIs. The recommended implementation will be discussed in terms of this functional
architecture and in conjunction of a functional set of HCI components. The HCI
components represent functional groupings of lower level HCI requirements, which can
be related to DLI and CCI messages. The listing of the HCI components (called
Information/Control Elements) is contained in the table below. It should be noted that
the functional groupings do not infer a specific design, and the developer could merge
or modify the Information/Control Elements in order to optimise his overall design.
LOI 4, 5
LOI 3
LOI 2
LOI 1
Comm
Mgt
C4I
Nodes
Core
CUCS
VSM
Mission
Planning
Figure A2 - 1: HCI Functional Architecture
The architecture does not infer that Comm Mgt and Mission Planning, for example,
need to be physically separate from the Core CUCS. This is a developer decision. It
does imply that a LOI 1 CUCS must contain the functionality to control CCI
communications links external to the UCS system and be able to access C4I nodes.
A2 - 1
Edition A Version 1
AEP-84.1
HCI Component
Description
Active Image
Operating
Displays
A screen or series of screens, which display operational
states or equipment condition for active image
payloads, such as radar, SAR, ISAR, etc.
Active Image
Payload Cmd &
Control
A screen or series of screens, which provide for issuing
and monitoring commands to the active image
payloads.
UA Unique
Displays
A screen or series of screens, which display operational
states or equipment condition unique to a particular
configuration of the UAS, such as pre-flight checks,
maintenance diagnosis, etc. This is generally in a
vendor-defined format.
Bearer System
Cmd & Control
A screen or series of screens, which provide for issuing
and monitoring commands to the bearer system
payloads.
C4I Message
Development
Display
A screen or series of screens, which provide for the
display, printing, editing, and creation of ADatP-3
messages.
Comm Mgt
Displays
A screen or series of screens, which provide for issuing
and monitoring commands to the ground and airborne
communications equipment and data links.
Comm Relay
Cmd & Control
A screen or series of screens, which provide for issuing
and monitoring commands to the communication relay
payloads.
Encryption Cmd
& Control
A screen or series of screens, which provide for issuing
and monitoring commands to the encryption devices.
EW Payload
Cmd & Control
A screen or series of screens, which provide for issuing
and monitoring commands to the electronic warfare
payloads.
Gateway Cmd &
Control
A screen or series of screens, which provide for issuing
and monitoring commands to the gateway devices.
Laser Payload
Cmd & Control
A screen or series of screens, which provide for issuing
and monitoring commands to the laser payloads.
Met Payload
Cmd & Control
A screen or series of screens, which provide for issuing
and monitoring commands to the meteorological
payloads.
Mission Analysis
Displays
A screen or series of screens, which provide for the
creation, display, or transmission of post mission
events, data, or C4I analyses.
A2 - 2
Edition A Version 1
AEP-84.1
HCI Component
Description
Mission Planning
Displays
A screen or series of screens, which display relevant
information, digital maps, and overlays for the planning
and creation of UA Mission Plans.
NBC Payload
Cmd & Control
A screen or series of screens, which provide for issuing
and monitoring commands to the nuclear, biological,
and chemical payloads.
Operator
Situational
Displays
A single integrated presentation that displays relevant
UA flight parameters and its route of flight as an overlay
on a digital map.
Passive Image
Operating
Displays
A screen or series of screens, which display operational
states or equipment condition for passive image
payloads, such as EO/IR.
Passive Image
Payload Cmd &
Control
A screen or series of screens, which provide for issuing
and monitoring commands to the passive imaging
payloads, such as EO/IR.
Payload Product
Displays
A screen or series of screens, which display sensor
information with relevant metadata, such as an IR
imagery presentation with target position information.
Stores Release
Cmd & Control
A screen or series of screens, which provide for issuing
and monitoring commands to activate and release
equipment carried on external stores stations of an UA.
Subsystem Cmd
& Control
Displays
A screen or series of screens, which provide for issuing
and monitoring commands to activate the UA's
subsystems.
Subsystem
Detailed Reports
A screen or series of screens, which display requested
detailed operational states or equipment condition for
the UA subsystems. This is generally unique to a
particular UA system and in vendor format.
Subsystem
Operating
Displays
A screen or series of screens, which display the normal
operational states or equipment condition for the UA's
subsystems.
System
Configuration
Display
A screen or series of screens, which list the UA or
subsystem fixed characteristics or configuration.
UCS Operating
Displays
A screen or series of screens, which display the
operating parameters or states of the CUCS.
UCS Set-Up
Displays
A screen or series of screens, which allow set-up,
initialisation, or tailoring of the UCS for a particular UA
system.
A2 - 3
Edition A Version 1
AEP-84.1
HCI Component
Description
Warnings &
Cautions
Displays
A screen or series of screens, which display cautions
or warnings associated with the UA or any of its
subsystems.
Table A2 - 1: Definition of Information/Control Elements
In general HCI LOI capabilities are obtained by adding new Information/Control
Elements or expanding existing Information/Control Elements from the previous LOI
level.
The intent of this section of the document is to provide the information requirements
and examples of their physical implementation.
A2.1 LOI 1 Information/Control Elements (HCI)
The HCI functions for LOI 1 are contained in the table below.
HCI Component
Description
System Configuration
Display
Displays that list the UA or subsystem fixed
characteristics or configuration.
UCS Operating Displays
Displays that provide operating parameters or
states of the CUCS.
C4I Message
Development Display
Displays to read, edit, and print ADatP-3
messages.
Comm Mgt Displays
Displays to operate, switch, and monitor
external communications equipment.
UCS Set-Up Displays
Displays to set-up, initialise, or tailor the UCS
for a particular UA system.
Table A2 - 2: HCI Functions for LOI 1
A2.1.1 LOI 2 Information/Control Elements (HCI)
The HCI functions for LOI 2 should be in accordance with Chapter 6 of AEP-84 Volume
I and Volume II. In addition to the functions defined in Table A2 - 2 above, LOI 2 HCI
functions are contained in Table A2 - 3. This LOI allows receipt of sensor data via a
VSM. It also extracts unique data fields from ADatP-3 messages to provide target or
informational overlays for operator situational awareness. Therefore the additional
Information/Control Elements address this added functionality. Attachment B in Annex
1, CCI Implementation Guidelines, lists the discrete message fields or elements that
are associated with each of the Information/Control Elements.
HCI Component
Description
UCS Operating
Displays
Expands display to include operating or warning display limits
provided by a VSM. Enables the operator to enter parameter sets
A2 - 4
Edition A Version 1
AEP-84.1
HCI Component
Description
that will adapt the UCS for the vehicle type and the respective
missions.
Comm Mgt
Displays
Expands the displays to include monitoring VDT/CDT and data
link information provided by a VSM. Would include placement of
communications icons as overlays on a digital map.
Warnings &
Cautions
Displays
Displays of cautions and warnings provided by the VSM.
Indications should be located in the operator’s primary field of
view and should not be obscured by other HCI elements.
Subsystem
Operating
Displays
Displays of operating states provided by the VSM.
Operator
Situational
Displays
Displays and controls related to presenting and manipulating
icons on a digital map with the following generic overlays:
- Enemy and friendly force disposition from LOI 2 ADatP-3
messages
- Route planning information from LOI 2 messages ADatP-3
messages
- Target information from LOI 2 ADatP-3 messages
- UA position/route information
- UA trail for every UA from which the CUCS is
receiving data
- Sensor foot print information
Displays should be able to support the following map types:
- Digital Terrain Elevation Data (DTED) Geographic
Information Exchange Standard, STANAG 3809
- Digital Feature Analysis Data (DFAD)
- World Geodetic System - 84 (WGS-84), Mil-Std 2401
Vector
- ARC Standard Raster Product
- Digital Geographic Information Exchange Standard
(DIGEST Version 2.1) STANAG 7074:1998
Mission Analysis
Displays
Displays for the creation, display, or transmission of post mission
events, data, or C4I analyses.
Table A2 - 3: Additional HCI Functions for LOI 2
A2.1.2 LOI 3 Information/Control Elements (HCI)
The HCI functions for LOI 3 should be in accordance with Chapter 6 of AEP-84 Volume
I and Volume II. In addition to the functions defined in Tables A2-2 and A2-3, LOI 3
HCI functions are contained in Table A2 - 4. LOI 3 introduces the mission planning
functionality and two-way communication with the VSM. At this LOI, the VSM
communication is limited to the ability to control and monitor the payload(s). Although
an HCI component was created for each possible payload, the developer may combine
relevant payload commands and reports tailored to a particular sensor suite. However,
the developer must clearly show that the functionality to completely control the payload
A2 - 5
Edition A Version 1
AEP-84.1
is reflected in the HCI. Attachment B in Annex 1, CCI Implementation Guidelines lists
the discrete message fields or elements that are associated with each of the
Information/Control Elements.
HCI Component
Description
UCS Set Up Displays
Expands displays to incorporate all relevant
payload controls and functions and the
functionality to “hand-off” payload control.
Operator Situational
Displays
Expands displays to incorporate:
- Additional payload parameters as map
overlays.
- Enemy and friendly force disposition from
LOI 3 ADatP-3 messages.
- Route planning information from LOI 3
ADatP-3 messages.
- Target information from LOI 3 ADatP-3
messages.
Active Image Operating
Displays
Displays for control and monitoring radar type
sensors.
Active Image Payload
Cmd & Control
Displays related to radar image products.
Bearer System Cmd &
Control
Displays for issuing and monitoring
commands to the bearer system payloads.
Comm Relay Cmd &
Control
Displays for issuing and monitoring
commands to the ground and airborne
communications equipment and data links.
Encryption Cmd & Control
Displays for issuing and monitoring
commands to the encryption devices.
EW Payload Cmd &
Control
Displays for issuing and monitoring
commands to the electronic warfare payloads.
Gateway Cmd & Control
Displays for issuing and monitoring
commands to the gateway devices.
Laser Payload Cmd &
Control
Displays for issuing and monitoring
commands to the laser payloads.
Met Payload Cmd &
Control
Displays for issuing and monitoring
commands to the meteorological payloads.
Mission Planning Displays
Displays for the planning and creation of UA
Mission Plans. Includes Payload planning and
Mission planning based on LOI 3 ADatP-3
messages.
A2 - 6
Edition A Version 1
AEP-84.1
HCI Component
Description
NBC Payload Cmd &
Control
Displays for issuing and monitoring
commands to the nuclear, biological, and
chemical payloads.
Passive Image Operating
Displays
Displays for operational states or equipment
condition for passive image payloads, such as
EO/IR.
Passive Image Payload
Cmd & Control
Displays for issuing and monitoring
commands to the passive imaging payloads,
such as EO/IR.
Payload Product Displays
Displays, which actually present the sensor
information, with relevant sensor/target
information. This could be a SAR, EO, or
hyper-spectral image.
Subsystem Cmd & Control
Displays
Displays for additional command & control
functions for a payload. This represents any
VSM “push” information. VSM generated
displays should not hide safety of flight related
display panels/screens from the operator.
Table A2 - 4: Additional HCI Functions for LOI 3
This payload control may be accomplished in a variety of physical configurations. The
payload may be operated via a hand controller (joystick). The payload may also be
controlled via software (on screen HCI). The payload can be monitored through the
use of an overlay on the imagery display or through the use of a separate window.
LOI 3 may introduce the effects of system latency upon operator performance. These
time lags will have an adverse effect upon perceptual motor performance. The adverse
effects of time delays in UA control systems may be most apparent during operatorcontrolled payload operations. Man-in-the-loop payload control, such as manually
slewing a payload camera while searching for or tracking a ground target, is utilized by
most tactical UA. Human control of the payload is often necessary because tactical
battlefield intelligence requirements cannot be met by currently available automated
target search and identification technologies. Latency in manual payload control
(slewing azimuth and elevation) can cause difficulties in acquiring and tracking. Pilot
induced oscillation (PIO) can occur when the system is not sufficiently responsive to
the operator input. It is recommended for manually controlled payload tracking tasks
that the total latency does not exceed 350 ms. The total latency is defined as the
duration between operator input & the response being seen on the video display. This
latency component should be addressed within the total system latency budget and
allocation
A2.1.3 LOI 4 INFORMATION/CONTROL ELEMENTS (HCI)
The HCI functions for LOI 4 should be in accordance with Chapter 6 of AEP-84 Volume
I and Volume II. LOI 4 functions can be implemented independently from LOI 1, 2, and
3 functions. The minimum set of LOI 4 HCI functions are contained in Table A2 - 5.
Although the table below shows the use of certain common functional blocks for LOIs
A2 - 7
Edition A Version 1
AEP-84.1
3, 4, and 5, the difference is the degree and type of communication that is performed
between the CUCS and the VSM. LOI 4 communication with the VSM is the command
and control of the UA, with the exception of take-off and landing. Attachment B in
Annex 1, CCI Implementation Guidelines lists the discrete message fields or elements
that are associated with each of the Information/Control Elements.
HCI Component
Description
Operator Situational Displays
Displays and controls related to a presenting and
manipulating icons on a digital map with the
following generic overlays:
- UA parameters as map overlays.
- Enemy and friendly force disposition from LOI
4 ADatP-3 messages.
- Route planning information from LOI 4
messages ADatP-3 messages.
- UA position/route information
- Target information from LOI 4 ADatP-3
Messages.
System Configuration Display
Displays that list the UA or subsystem fixed
characteristics or configuration
UCS Operating Displays
Displays that provide operating parameters or
states of the CUCS; includes operating or warning
display limits provided by a VSM
Comm Mgt Displays
Displays to operate, switch, and monitor external
communications equipment; includes monitoring
VDT/CDT and data link information provided by a
VSM
UCS Set-Up Displays
Displays to set-up, initialise, or tailor the UCS for a
particular UA system
Warnings & Cautions Displays
Displays of cautions and warnings provided by the
VSM
Mission Planning Displays
Displays for the planning and creation of UA Mission
Plans based on LOI 4 ADatP-3 messages
Subsystem
Displays
Cmd
&
Control Displays for the command and control of all of the
UA’s subsystems.
Subsystem Detailed Reports
Display of UA subsystem unique information that
cannot be presented via DLI message sets. This can
be in vendor format for information not contained in
the DLI.
Subsystem Operating Displays
Displays for the normal operational states or
equipment condition for the rest of the UA's
A2 - 8
Edition A Version 1
AEP-84.1
HCI Component
Description
subsystems. These displays utilize DLI data and are
primarily any VSM “pull” information.
UA Cmd & Control
Displays for the command and control of the UA.
Flight critical control/monitor data should be visible
at all times while an UA is under control. These are:
- Airspeed/Altitude
- Track/Heading
- Current position
UA Unique Displays
Display of UA unique information that cannot be
presented via DLI message sets. This can be in
vendor format for information not contained in the
DLI.
Table A2 - 5: HCI Functions for LOI 4
A2.1.4 LOI 5 INFORMATION/CONTROL ELEMENTS (HCI)
The HCI functions for LOI 5 should be in accordance with Chapter 6 of AEP-84 Volume
I and Volume II. In addition to the functions defined in Table A2 - 5, LOI 5 HCI functions
are contained in Table A2 - 6. Although the table below shows the same functional
relationship for LOIs 4 and 5, the difference is the degree and type of communication
that is performed between the CUCS and the VSM. LOI 5 expands the communication
with the VSM to include take-off and landing. Attachment B in Annex 1, CCI
Implementation Guidelines, lists the discrete message fields or elements that are
associated with each of the Information/Control Elements.
HCI Component
Description
UA Cmd & Control
Expands the displays for the command and
control of the landing and take-off functionality
for the UA
Subsystem Cmd & Control
Displays
Expands the displays to include the command
and control of all of the UA’s subsystems
related to take-off and landing.
Subsystem Operating
Displays
Expands the displays to incorporate the
control and monitoring of external UA
equipment associated with the take-off and
landing of the UA.
Table A2 - 6: Additional HCI Functions for LOI 5
A2.2 HCI Development Process
A2.2.1 Goals
The HCI development process should be conducted in an auditable manner that
provides traceability throughout the design process of how interoperability
requirements are developed (from an HCI perspective) into a working system.
A2 - 9
Edition A Version 1
AEP-84.1
Regardless of the LOI required, the process by which the final HCI is derived should
be consistent and utilise international best practise in Human Factors.
A2.2.2 Human Factors Standards
The following Human Factors standards provide specific national guidance on process
and design criteria to meet basic human factors requirements. At least one of these
standards should be utilised as the baseline from which to develop and assess the
HCI:

ISO 9241

MIL-STD-1472

DEF-STAN 00-25
A2.2.3 Human Factors Integration Plan
The development programme should be supported by a Human Factors Integration
Plan (HFIP), which should be produced at the outset of the development programme.
The HFIP should present the specific human factors tasks to be completed in support
of the HCI design & development, and should also illustrate how human factors
information should be communicated to other participants in the development process.
The HFIP is a management plan and as such should be maintained and updated at
regular intervals throughout the programme. Guidance on format of HFIP documents
is available from:

US MANPRINT Office

UK MoD (HFI Office)
A2.2.4 Human Factors Tasks
The following represent the likely human factors tasks that should be undertaken in
support of development of UCS HCI in compliance with STANAG 4586.
It is assumed that the majority of these tasks will be conducted as part of the core UCS
UA development process, however the tasks are presented here as a prompt to the
design & development team to ensure that all such issues are being correctly
addressed within the system engineering process.
It is possible to create a highly internally consistent HCI, but one that does not share a
common look and feel or operational metaphor with other UA systems. While such a
system may in fact be interoperable technically, the impact on the operators in terms
of workload, error, and training are likely to be considerable.
A2.2.5 Target Audience Description
The human factors process should formally identify the target audience of the system.
The Target Audience Description (TAD) should identify but not be limited to:

System operators

System supervisors/managers

System maintainers

External personnel who may utilise the UCS (e.g., to control an
alternative UA)
A2 - 10
Edition A Version 1
AEP-84.1
Understanding the skills, background, training, and expectation of each group of users
ensures that the design is supportive of their needs. Specifically, identification of
potential external users will help to ensure that the necessary LOIs are achieved at the
HCI.
A2.2.6 Function and Task Analysis
The functions associated with operating and maintaining the system should be
identified. Those functions that are unique to the system and those that are common
to other UA should be identified.
A task analysis should be performed that identifies the operational tasks to be
performed by the user. There are many methods of performing task analysis, and
some are more suitable than others for specific systems.
As a minimum, the task analysis should identify:

Task description

Task context (triggers & outcomes)

Criticality of task

Frequency of task

Who conducts the task

Skills & knowledge required to execute task

Unique or Common task
From an interoperability perspective, knowledge of which of the operational tasks are
the same or similar to other systems provides immediate guidance on the focus for
HCI interoperability. Common tasks should be developed in accordance with the
STANAG HCI requirements, and unique tasks should be developed to be internally
consistent with the rest of the HCI.
A2.2.7 Workload and Human Error Prediction
Workload prediction should be conducted in order to assess how demanding the task
design is on known human performance limitations. There are a number of recognised
methods of human workload prediction available, and selection of appropriate methods
should be a decision for the human factors team on each specific programme.
The outcome of the workload prediction tasks should be an individual task rating or a
grouped rating by time period that indicates the work loading/spare capacity on the
user. This data should then be used to assist in the decisions made on allocation of
function and selection of appropriate levels of automation.
A human error analysis should also be conducted to assess the likely occurrence of
human error implicit in the task model. The human error analysis will identify types of
error, their criticality and the possible mitigation strategies that could be employed.
The error analysis should also be repeated once a prototype HCI has been developed
to capture and mitigate human error potential implicit in the HCI design.
A2.2.8 Function Allocation/Levels of Automation
Function allocation is the point when firm decisions are taken with regard to the
adoption of levels of automation and the allocation of responsibility for system functions
between team members. The function allocation provides the logical audit trail of
decision making from the initial human factors analysis to a firm decision.
A2 - 11
Edition A Version 1
AEP-84.1
A2.2.9 Manning Requirements
Manpower requirements should form a part of the function allocation decision process.
As a key whole life cost driver, manpower should be minimised where possible through
careful functional design and HCI design. Increased automation may appear to
reduce manpower; however, often manpower requirements are simply converted from
a hands-on to system monitoring.
A2.2.10 Style Guides/Interaction Style
Interoperability at the HCI level demands an attempt to achieve common look and feel
at the user interface. A style guide should be developed/adopted that provides a
framework to design the system around. The style guide should cover issues such as:

Layout of Windows

Navigation between Windows

Object behaviour

Metaphor of use

Iconology/Symbology

Use of colour

Alarm behaviour
A2.2.11 Ergonomics and Console Design
The human factors analysis should also address the system ergonomics both for the
operator’s console, and also for the UA and payloads themselves.
Providing a consistent ergonomic layout of the console with hardware controls and
other devices properly positioned in accordance with approved standards will improve
usability of the system.
A2.2.12 HCI Design and Prototype
The HCI should be formally designed prior to any software development. This design
should involve a small team of software and human factors professionals and Subject
Matter Experts (SMEs) whose task will be to design a system that meets the needs of
the operator(s) in support of the required operational missions and tasks in accordance
with the standards and style guides adopted.
The HCI design should initially be on paper and provide a storyboard for the system.
It is vital that the SMEs are fully involved in this early evolution of the design to ensure
that problems with existing systems are fully addressed.
The HCI design should also evolve through a series of prototypes, each involving
participation by SMEs and (where possible) the customer.
A2.2.13 HCI User Interface Standards Development
Interface services are needed to ensure a high degree of application portability and to
provide a consistent “look and feel” across multiple implementations. The user
interface services provide a consistent means for developers, administrators and users
of a system to gain access to application programs, operating system functions and
system utilities. Information system architecture should not only address technical
features of the user interface, but also the human engineering considerations.
The style of a UI may fall into one of three main categories:
A2 - 12
Edition A Version 1
AEP-84.1

Character-Oriented interfaces (e.g., for DOS on a Personal
Computer) are subject to few standards, except for the underlying
character sets or common, but proprietary, terminal emulation
standards (e.g., VT100).

Graphical User Interfaces (GUIs) may be created for a variety of
different computer systems (e.g., UNIX workstation, Macintosh or
personal computer (PC), running their specific windowing
environment). The choice of a GUI standard is largely driven by the
choice of the underlying operating system. For instance, Microsoft
operating systems uses the Microsoft Windows GUI, for UNIX it is
X-Windows.

Dedicated interfaces are typically purpose built, using dedicated
displays and electronics (e.g., for weapon systems). They are
subject to few standards; the main concerns are those of usability
as opposed to those of design.
A modern GUI presents the programmer with a wide range of capabilities for displaying
the output of a computer program on the screen. These comprise the appearance of
screen entities such as windows, buttons and scroll bars, as well as the actions that
users must perform to navigate the display and utilise the program’s functions. While
this breadth of capability is powerful, it can lead to systems in which different
applications behave in different ways. Standardisation of GUIs is important to allow
the transfer of a user’s knowledge of one application to the operation of another, thus
reducing the training costs. “User portability” makes the definition of a common HCI a
desirable objective. Two areas of GUI standardisation can be distinguished:

The first area of standardisation consists of a toolkit, which supports
the developer to establish the overall style of an on-screen
presentation

The second area of standardisation involves the detailed design of
appearance and behaviour
Unfortunately, it is possible to use a toolkit’s capabilities in many different ways to yield
different appearances and behaviours. The solution is the use of style guides, which
are available for specific toolkits (e.g., defining functions of menus, push-buttons, or
dialog boxes), as well as for overarching design decisions. Hence, applications can be
designed to behave in a similar way under different GUIs. However, it is equally
possible for two developers to follow the appropriate style guide and come up with two
drastically different products.
The following table shows NATO existing and emerging standards for User Interface
Requirements.
A2 - 13
Edition A Version 1
AEP-84.1
Service Area
Class
Mandatory
Standards
Emerging
Standards
Remarks
User
Interface
Graphical
User
Interface
X Windows
System 11R5
X Windows
System
11R6.4
Although X11R6.4
is the current
version, only
services based on
version X11R5
have enough
product support.
This situation
should be
monitored as a
shift to X11R6.4
may be expected
in the near future.
Win 32 APIs
Look and
Feel
As part of MS NT
(See OS)
CDE 1.0
CDE 2.1
Motif Style
Guide Rev 1.2
Motif/CDE
Style Guide
Rev 2.1
MS Windows
Interface
Guidelines for
Software
Design (1995)
Toolkit specific
style guides.
US DoD HCI
Style Guide
(TAFIM V3.0)
Domain specific
style guide
As part of MS NT
(See OS Svc)
UK Army CIS
Style guide
V2.0
Toolkit
Toolkit specific
style guides
Motif 1.2
Domain specific
style guide
Motif 2.1
Table A2 - 7: User Interface Requirements
A2 - 14
Edition A Version 1
AEP-84.1
ANNEX 3
IMPLEMENTATION GUIDELINES FOR AEP-84 VOLUME I
A3 Implementation Guidelines for AEP-84 Volume I
A3.1 Functional Description
A3.1.1 Network Configuration
Prior to discovery and initialization of VSM/UA, the network should be configured as
per Section 3.8 of this document.
A3.1.2 CUCS/VSM Initialization and Connection
Once a CUCS manufacturer has developed a CUCS software component and verified
its correct operation through the compliance testing process, the CUCS may be
connected to a STANAG 4586 compliant VSM. A physical connection may be required
between the two components hosting the CUCS and VSM functionality dependent on
their physical location, and then a software “socket” connection must be made between
the two components. Once the data “pipeline” has been established between the
CUCS and the VSM, there is a requirement to configure the CUCS to work within the
limits of the specified UCS system. The CUCS must request and receive authorization
to control an UA and or its payload(s) through the VSM.
A3.1.2.1 Defining Entities
The term entity is used as a generic term to refer to any of the following conceptual
components in STANAG 4586:






CUCS – Core Unmanned Control Segment
VSM – Vehicle Specific Module
UA – Unmanned Aircraft / Unmanned Vehicle / Unattended Ground Sensor
Platform
CDT – Control Data Terminal
VDT – Vehicle Data Terminal
Payload Station
A3.1.2.2 Message Addressing
Each DLI message contains ID fields that help identify the sender and the receiver of
a message. The ID fields alone are not sufficient to identify the source and destination
of a message so it is important that messages are divided into at least two multicast
groups:
1. Messages being sent from a CUCS
2. Message being sent to a CUCS
More multicast groups could be added to separate UA from Data Links or VSMs from
UA, but the network layout is not mandated by STANAG 4586.
In some cases, an ID will not apply to a particular message. For instance, if a data link
control message (e.g., Message #401) is sent from a CUCS to a CDT, the Vehicle ID
will likely be unneeded. In this case it can be set to the Null ID (0xFF000000).
A3 - 1
Edition A Version 1
AEP-84.1
The Broadcast ID (0xFFFFFFFF) can be used when the sender may not know the
destination’s ID or a message may be intended for multiple recipients. For instance,
when a CUCS is broadcasting its presence to any UA, it doesn’t know the Vehicle ID
in advance.
The ID fields in STANAG messages are:
CUCS ID
For messages sent from a CUCS, this is set to the ID of that
CUCS.
For Discovery/Configuration/Control and Mission Download
Messages (#20, #21, #300, #301, #310, #500, #800-806, #900,
#1202-1203, #1300-1303, #1400-1403) this is set to the CUCS
that is destined to receive this message or the CUCS that sent
the message.
For vehicle status messages such as Message #101, #102, etc…
this is set to the CUCS ID of the CUCS with the LOI 4 or LOI 5
connection. If there is no LOI 4 or LOI 5 connection established
it should be set to the Broadcast ID.
For payload station messages such as Message #302, #310,
etc… this is set to the CUCS ID of the CUCS with the LOI 3
connection. If there is no LOI 3 connection established it should
be set to the Broadcast ID.
This should never be set to a Null ID.
Vehicle ID
Indicates the UA that is destined to receive this message or the
UA that sent this message. This value could be a “logical Vehicle
ID” to indicate that it is a placeholder for a future UA. This can be
a Broadcast ID or a Null ID depending on the situation.
Data Link ID
Indicates the data link that is destined to receive this message or
the data link where this message originated. Note that a data
terminal (CDT or VDT) can provide multiple data links. If the data
link is provided by a VDT, the Vehicle ID is specified as well.
This can be a Broadcast ID or a Null ID depending on the
situation.
VSM ID
Indicates the VSM that a message is originating from or being
sent to. This can be a Broadcast ID or a Null ID depending on
the situation.
A3 - 2
Edition A Version 1
AEP-84.1
Table A3 - 1: ID Fields in STANAG Messages
It is recommended that all entity IDs in a system are unique to enable interoperability.
Note that Logical Vehicle IDs only need to be unique for a given VSM ID.
A3.1.2.3 Entity Connection Management
There are four phases involved in managing a connection between a CUCS and a
VSM/UA/CDT/VDT/payload station.
The phases are:




Discovery
Downloading Configuration Data
Establish Connection
Release
During these phases the CUCS will discover an entity and its capabilities. If the entity
is a VSM, UA or payload station, the operator can then choose to establish one (or
more) LOI connection(s) with the entity. If the entity is a data terminal, the CUCS only
has the ability to request full control of it. There are no LOIs between a CUCS and a
data terminal.
The LOIs for a UA are:



LOI 2 – Monitoring the UA
LOI 4 – Controlling the UA without takeoff/landing
LOI 5 – Controlling the UA with takeoff/landing
The LOIs for a payload station are:


LOI 2 – Monitoring the Payload
LOI 3 – Controlling the Payload
After the operator is finished controlling the entity they can either hand it off to another
CUCS or simply release the connections.
The figure below shows an example sequence where a user wants to monitor a UA.
In this use case, the user first needs to control a CDT and establish a data link between
it and the UA. Once the link has been created, the CUCS can discover the UA and
proceed to request the LOI 2 connection.
A3 - 3
Edition A Version 1
AEP-84.1
Figure A3 - 1: Example Sequence to Setup a CDT and Monitor a UA
A3.1.2.3.1 Connection Phase 1: Discovery
In the first phase, a CUCS will broadcast messages to discovery which entities are
reachable on the network and what level of control the CUCS can request.
A3.1.2.3.1.1 Discovering VSMs, UA and Payload Stations
To discover a VSM, UA and/or payload station, the CUCS sends Message #1 with all
IDs (except the CUCS ID) set to the Broadcast ID.
Unique
ID
Name
Value
0001.02
Vehicle ID
Broadcast ID
0001.03
CUCS ID
<ID of CUCS that is broadcasting>
0001.04
VSM ID
Broadcast ID
0001.05
Data Link ID
Broadcast ID or Null ID
0001.06
Vehicle Type
0
0001.07
Vehicle Subtype
0
A3 - 4
Edition A Version 1
AEP-84.1
0001.08
Requested/Handover LOI
0 (N/A)
0001.09
Controlled Station
0xFFFFFFFF (All stations)
0001.10
Controlled Station Mode
0 (N/A)
0001.11
Wait for Vehicle Data Link
Transition Coordination
Message
0 (N/A)
Any VSM/UA/Payload Station that receives this message will respond with Message
#21 for each entity indicating the authorized LOI for the CUCS. The LOI Authorized
field indicates which LOIs the CUCS can currently request for the entity specified by
the ID fields.
A response for a VSM/UA will look like this:
Unique
ID
Name
Value
0021.02
Vehicle ID
<UA’s ID>
0021.03
CUCS ID
<ID of the CUCS that sent the broadcast>
0021.04
VSM ID
<VSM ID> (if applicable)
0021.05
Data Link ID
<Data Link ID> (if applicable)
0021.06
LOI Authorized
<LOIs authorized to the CUCS> (LOI 3 not
applicable)
0021.07
LOI Granted
<LOIs granted to the CUCS> (LOI 3 not
applicable)
0021.08
Controlled Station
UA Platform (0x00000000)
0021.09
Controlled Station Mode
Either 1 (In Control) or 0 (Not in Control) for
the UA
0021.10
Vehicle Type
<UA’s vehicle type>
0021.11
Vehicle Subtype
<UA’s vehicle subtype>
The Message #21 is followed by a Message #20 to indicate the vehicle’s tail number.
Unique
ID
Name
Value
0020.05
Vehicle ID Update
<UA’s ID>
0020.06
Vehicle Type
<UA’s vehicle type>
0020.07
Vehicle Subtype
<UA’s vehicle subtype>
0020.08
Owning ID
<Owning ID>
A3 - 5
Edition A Version 1
AEP-84.1
0020.09
Tail Number
<Tail Number>
0020.10
Mission ID
<Mission ID>
0020.11
ATC Call Sign
<ATC Call Sign>
0020.12
Configuration Checksum <Configuration Checksum>
Note that the Vehicle ID Update (Unique ID 0020.05) field is used for VSMs that use
Logical Vehicle IDs. If a VSM or UA doesn’t use Logical Vehicle IDs, always keep this
field set to the same value as the Vehicle ID field (Unique ID 0020.02). Refer to the
Logical Vehicles section for more information.
A response for a payload station or multiple payload stations will look like this:
Unique
ID
Name
Value
0021.02
Vehicle ID
<UA’s ID>
0021.03
CUCS ID
<ID of the CUCS that sent the broadcast>
0021.04
VSM ID
<VSM ID> (if applicable)
0021.05
Data Link ID
<Data Link ID> (if applicable)
0021.06
LOI Authorized
<LOIs authorized to the CUCS> (LOI4/5
not applicable)
0021.07
LOI Granted
<LOIs granted to the CUCS> (LOI4/5 not
applicable)
0021.08
Controlled Station
<The station number(s)>
0021.09
Controlled Station Mode
Either 1 (In Control) or 0 (Not in Control) for
all stations referenced in 0021.08.
0021.10
Vehicle Type
<UA’s vehicle type>
0021.11
Vehicle Subtype
<UA’s vehicle subtype>
Note that a VSM can send one Message #21 for all payload stations if the LOI fields
and Controlled Stations Modes are the same for each station. Otherwise, it can send
a separate Message #21 for each station.
The VSM then sends a Message #300 for each Payload Station to indicate its payload
type:
Unique
ID
Name
Value
0300.05
Payload Stations
Available
<All the Stations that are installed>
0300.06
Station Number
<One station>
A3 - 6
Edition A Version 1
AEP-84.1
0300.07
Payload Type
<Payload Type>
0300.08
Station Door
Either 1 (Yes) or 0 (No)
0300.09
Number of Payload
Recording Devices
Number of recording devices on this
payload.
A3.1.2.3.1.2 Discovering Data Links
A data link defines a potential “link” between two data terminals – a CDT and a VDT.
A data terminal may provide the ability to have one or more data links. For instance,
a data terminal may know how to communicate with two different vehicle types (e.g.,
a Northrop Grumman Global Hawk and a Boeing Insitu Scan Eagle). It is possible that
each of these links require different parameters such as frequency ranges, etc… hence
they need to be identified separately.
On the other hand, it is possible that the data terminal isn’t configured for a specific
type of vehicle. In these cases, the data terminal can report a single data link without
any specific vehicle type. In these cases, there is a 1:1 relationship between a data
link and a data terminal.
Data links are discovered by a CUCS with a Message #404 with the Vehicle ID, VSM
ID and Data Link ID set to the Broadcast ID.
Unique
ID
Name
Value
0404.02
Vehicle ID
Broadcast ID
0404.03
CUCS ID
<ID of CUCS that is broadcasting>
0404.04
VSM ID
Broadcast ID
0404.05
Data Link ID
Broadcast ID
0404.06
Control Assignment
Request
1 (Release Control as per DLI0395)
0404.07
Vehicle Type
0
0404.08
Vehicle Subtype
0
Any data terminal or VSM that receives this message will respond with Message
#500 for each possible data link. The Data Link Control Availability field (Unique ID
0500.06) indicates whether the CUCS can request control or not.
Unique
ID
Name
Value
0500.02
Vehicle ID
Null ID if CDT or <Vehicle ID> if VDT
0500.03
CUCS ID
<ID of the CUCS that sent the broadcast>
0500.04
VSM ID
<VSM ID> if Applicable
A3 - 7
Edition A Version 1
AEP-84.1
0500.05
Data Link ID
<Data Link ID>
0500.06
Data Link Control
Availability
0 if CUCS can request Control or already
has control, or
1 if CUCS cannot request control
(2 is an invalid response to a broadcast
request)
0500.07
Terminal Type
0 if CDT or 1 if VDT
0500.08
Data Link Type
<Type of Data Link>
0500.09
Data Link Name
<Name>
0500.10
Antenna Type
1 if Omni, or
2 if Direction, or
3 if Omni + Directional
0500.11
Vehicle Type
<UA’s vehicle type> if VDT, otherwise 0
0500.12
Vehicle Subtype
<UA’s vehicle subtype> if VDT, otherwise 0
Note that it is not defined how a CUCS will handle receiving an invalid Authorized LOI
combination, such as LOI 5 for a Payload Station. The CUCS may ignore the message
or it may simply ignore the fields or bits that don’t make sense. In general, to attain
interoperability, it is the VSMs responsibility to ensure the data in the message is never
invalid. Other special cases to avoid are:


Specifying an LOI for a data link with Message #21 (this is done with Message
#500)
Specifying LOI 3 for an Air Vehicle Platform
A3.1.2.3.2 Connection Phase 2: Downloading Configuration Data
A CUCS can download Configuration Data from an entity using Message #1200. This
typically happens before the CUCS requests an LOI connection for the UA so that the
CUCS can understand the capabilities of the entity and tailor its user interface.
A typical sequence has three stages as seen below:
A3 - 8
Edition A Version 1
AEP-84.1
Table A3 - 2: Typical Sequence for Downloading Configuration Data
A3.1.2.3.2.1 Stage 1: Initiate Download
In this stage, the CUCS begins the request with Message #1200.
Unique
ID
Name
Value
1200.02
Vehicle ID
<Vehicle ID> (if applicable)
1200.03
CUCS ID
<ID of CUCS that is requesting>
1200.04
VSM ID
<VSM ID> (if applicable)
1200.05
Data Link ID
<Data Link ID> (if applicable)
1200.06
Request Type
LOI2 or LOI3 or LOI4 or LOI5 or Data Link
1200.07
Requested Message
0 (N/A)
1200.08
Requested Field
0 (N/A)
1200.09
Station Number
0x0000 (for UA) or <The station
number(s)>
1200.10
Sensor Select
0 (N/A)
A CUCS cannot request vehicle and payload station configuration with the same
message. Note that there is no requirement specifying if a CUCS or VSM needs to
support downloading configuration data from different entities simultaneously.
It is possible that an entity has different configuration data for each LOI so the CUCS
should request the configuration data for any LOI that it expects it will request. In
practice, many entities will provide the same configuration data for any LOI requested.
Note that it is not possible to download configuration data for different LOIs of the same
entity simultaneously since the CUCS has no way of associating configuration
messages to LOI.
A3 - 9
Edition A Version 1
AEP-84.1
It is entirely acceptable to download the configuration data for one entity at a time (i.e.,
waiting for the download to be completed before initiating the next download).
A3.1.2.3.2.2
Stage 2: Send Configuration Messages
Upon receiving a request from the CUCS, an entity should begin to send the
Configuration Data messages. This includes the following messages:
Name
Number
Vehicle
Station
Data
Link
Vehicle Configuration
#100
Yes
No
No
Payload Configuration
#300
No
Yes
No
EO/IR Configuration State
#301
No
If EO/IR
No
CBRN Payload Configuration
State
#310
No
If CBRN
No
Field Configuration Integer
Response
#1300
Field Configuration Double
Response
#1301
Field Configuration Enumerated
Response
#1302
Field Configuration Command
#1303
Field Configuration Unsigned
Response
#1305
Vehicle Steering/Operating
Mode Configuration
#1306
If needed
Yes
No
No
This stage may take a long time to complete if the entity has a large amount of
configuration data. It is highly recommended that entities use the acknowledgment
system to ensure that all data has been received by the CUCS before moving on to
the next stage.
Note that IDs in these messages are particularly important since a CUCS could be
downloading multiple configurations simultaneously.
Refer to Section A3.1.2.4 Downloading Configuration Data to learn more about the
contents of these messages.
A3.1.2.3.2.3 Stage 3: Send Configuration Complete
When the CUCS has received all of the configuration data, the entity sends Message
#1203 to indicate the transfer is complete.
A3 - 10
Edition A Version 1
AEP-84.1
Unique
ID
Name
Value
1203.02
Vehicle ID
<Vehicle ID> (if applicable)
1203.03
CUCS ID
<ID of CUCS that is requesting>
1203.04
VSM ID
<VSM ID> (if applicable)
1203.05
Data Link ID
<Data Link ID> (if applicable)
1203.06
Station Number
0x0000 (for UA) or <The station number(s)>
1203.07
Vehicle Type
<UA’s vehicle type> or N/A
1203.08
Vehicle Subtype
<UA’s vehicle subtype> or N/A
Note that since the CUCS does not know how many messages will arrive in Stage 2,
it is the responsibility of the entity to ensure that all of the messages have arrived
before sending Message #1203. This is typically accomplished by requesting
acknowledgements from the CUCS for each message.
Once the CUCS has received Message #1203, it can process the configuration data.
If the CUCS has requested to download the configuration data for multiple stations
simultaneously, the entity can choose to send a single Message #1203 with multiple
station numbers or a separate Message #1203 for each station number. An entity
cannot indicate that the configuration download is complete for a vehicle and payload
station with the same Message #1203 message due to the nature of the station number
field.
A3.1.2.3.2.4 Caching Configuration Data
A CUCS may choose to save the downloaded configuration data to disk; however, in
cases where the configuration data can change, the CUCS may need to be aware if
the entity’s data is different than the stored version. The Configuration Checksum
(0020.12) can potentially be used to identify if a vehicle’s configuration has changed,
however, there is no similar mechanism for a payload station or data link.
A3.1.2.3.3 Connection Phase 3: Establish Connection
A CUCS can request to establish an LOI connection at any time. The receiving entity
can choose to accept or deny the request. A CUCS should only request an LOI
connection that it has been authorized to request.
A3.1.2.3.3.1 Requesting LOI Connection for VSMs, UA and Payload Stations
To establish an LOI connection between a CUCS and a VSM, UA and/or payload
station, the CUCS sends Message #1.
Unique
ID
Name
Value
0001.02
Vehicle ID
<Vehicle ID>
0001.03
CUCS ID
<ID of CUCS that is requesting>
A3 - 11
Edition A Version 1
AEP-84.1
0001.04
VSM ID
<VSM ID> (if applicable)
0001.05
Data Link ID
Null ID
0001.06
Vehicle Type
<Vehicle Type> (as received in discovery)
0001.07
Vehicle Subtype
<Vehicle Subtype> (as received in
discovery)
0001.08
Requested/Handover LOI
<All LOI Connections Requested>
It is recommended to request all
applicable lower LOIs:
0x01 (LOI2) or
0x03 (LOI2+LOI3) or
0x05 (LOI2+LOI4) or
0x0D (LOI2+LOI4+LOI5)
0001.09
Controlled Station
0x0000 (for UA) or <The station
number(s)>
0001.10
Controlled Station Mode
1 (Request Control)
0001.11
Wait for Vehicle Data Link
Transition Coordination
Message
0 (Don’t wait) or 1 (Wait). Note that this
field was added to support handoff.
Any VSM/UA/Payload Station that receives this message will respond with Message
#21. If the request was granted, the LOI Granted (Unique ID 0021.07) field should
specify the new LOI connection as well as the currently established LOI connections.
If the request is denied, the LOI Granted field will simply contain the existing LOI
connections.
Unique
ID
Name
Value
0021.02
Vehicle ID
<Vehicle ID>
0021.03
CUCS ID
<ID of the CUCS that requested>
0021.04
VSM ID
<VSM ID> (if applicable)
0021.05
Data Link ID
Null ID
0021.06
LOI Authorized
<LOIs authorized to the CUCS> This
should be all LOIs currently authorized for
the requesting CUCS (including if they are
already granted to that CUCS).
0021.07
LOI Granted
<LOIs granted to the CUCS>
A3 - 12
Edition A Version 1
AEP-84.1
0021.08
Controlled Station
UA Platform (0x00000000) or <The station
number(s)>
0021.09
Controlled Station Mode
Either 1 (In Control) or 0 (Not in Control) for
the UA
0021.10
Vehicle Type
<UA’s vehicle type>
0021.11
Vehicle Subtype
<UA’s vehicle subtype>
Note that if a request is made for multiple payload stations, the response may be
combined into a single Message #21 response or multiple Message #21 responses.
Also note that a CUCS does not typically need to request control of the UA to request
control of the UA’s payload stations.
For a CUCS to receive an explicit rejection message, it should request an
acknowledgement in Message #1. The entity will then send Message #1400 indicating
the request was rejected:
Unique
ID
Name
Value
1400.06
Original Message Time
Stamp
<Timestamp in message #1>
1400.07
Original Message ID
<Instance ID in message #1>
1400.08
Original Message Type
1
1400.09
Acknowledgement Type
3 (Message Received, but Rejected)
In some cases, the CUCS may want to override an LOI connection of the
UA/VSM/Payload Station. This would typically be for specific LOI connections of a
UA/VSM/Payload Station where only one CUCS can maintain the connection at a time.
For instance, it may be necessary to override the LOI 5 connection from another CUCS
if the original CUCS malfunctions. This is almost the same as requesting control with
Message #1, except that the Controlled Station Mode field (Unique ID 0001.10) is
different:
Unique
ID
Name
Value
0001.10
Controlled Station Mode
2 (Override Control)
The UA/VSM/Payload Station will respond in the same way it would to a normal control
request. If the CUCS succeeds in overriding control, the UA/VSM/Payload Station
should notify the original CUCS that it has now lost control. It can do this by sending
an unsolicited Message #21 with an updated list of granted LOIs.
A CUCS can maintain multiple LOI connections with an entity. If a CUCS requests a
new LOI connection it does not affect the status of the other LOI connection. For
instance, a CUCS can have LOI 2 and LOI 4 control of a UA and then request LOI 5
A3 - 13
Edition A Version 1
AEP-84.1
as well. If the LOI 4 and LOI 5 connections are released, the CUCS will still maintain
an LOI 2 connection with the UA.
Note that UA/VSM/Payload Station should avoid granting control to a CUCS
unexpectedly. For instance, if a CUCS has an LOI 2 connection with a UA it may not
handle the case where the UA arbitrarily provides an LOI 4 connection without a
request from the CUCS.
A3.1.2.3.3.2 Requesting Control of Data Links
A CUCS can request control of a data link with Message #404. Unlike with
VSM/UA/Payload Station entities, there is no concept of an LOI connection between a
CUCS and data link. A CUCS should only request control if it is available for that
CUCS (as determined from receiving a Message #500 in the earlier broadcast phase).
Unique
ID
Name
Value
0404.02
Vehicle ID
<Vehicle ID> (If applicable)
0404.03
CUCS ID
<ID of CUCS that is requesting >
0404.04
VSM ID
<VSM ID> (if applicable)
0404.05
Data Link ID
<Data Link ID>
0404.06
Control Assignment
Request
0 (Request Control)
0404.07
Vehicle Type
<Vehicle Type> (if applicable)
0404.08
Vehicle Subtype
<Vehicle Subtype> (if applicable)
When a data terminal receives this message and recognizes the identified data link, it
will respond with a Message #500 for that data link. To grant the request, the data
terminal will set the Data Link Control Availability field (Unique ID 0500.06) to
2=Request Granted.
Unique
ID
Name
Value
0500.06
Data Link Control
Availability
2 (Request Granted)
To deny the request, the data terminal will set the Data Link Control Availability field
(Unique ID 0500.06) to 1 (Not available for Control).
Unique
ID
Name
Value
0500.06
Data Link Control
Availability
1 (Unavailable for Control)
In some cases, the CUCS may want to override control of the data terminal. For
instance, it may be necessary to override control of a VDT from another CUCS if the
A3 - 14
Edition A Version 1
AEP-84.1
original CUCS malfunctions. This is almost the same as requesting control with
Message #404, except that the Control Assignment Request field (Unique ID 0404.06)
is different:
Unique
ID
Name
Value
0404.06
Control Assignment
Request
2 (Override Control)
The data terminal will respond in the same way it would to a normal control request. If
the CUCS succeeds in overriding control, the data terminal should notify the original
CUCS that it has now lost control. It can do this by sending an unsolicited Message
#500 with:
Unique
ID
Name
0500.06
Data Link Control
Availability
Value
1
(Unavailable for Control)
A3.1.2.3.4 Connection Phase 4: Release
A connection between a CUCS and an entity can be released for reasons such as:




The CUCS requests the connection to be released
The entity spontaneously releases the connection
Another CUCS requests to override the connection
The CUCS hands control over to another CUCS
A3.1.2.3.4.1 Releasing a LOI Connection for VSMs, UA and Payload Stations
To request releasing an LOI connection of a VSM/UA/Payload Station, the CUCS
sends Message #1.
Unique
ID
Name
Value
0001.02
Vehicle ID
<Vehicle ID>
0001.03
CUCS ID
<ID of CUCS that is requesting>
0001.04
VSM ID
<VSM ID> (if applicable)
0001.05
Data Link ID
Null ID
0001.06
Vehicle Type
<Vehicle Type> (as received in discovery)
0001.07
Vehicle Subtype
<Vehicle Subtype> (as received in
discovery)
0001.08
Requested/Handover LOI
<All LOI Connections Requested to
Release/Handover>
A3 - 15
Edition A Version 1
AEP-84.1
0001.09
Controlled Station
0x0000 (for UA) or <The station
number(s)>
0001.10
Controlled Station Mode
0 (Relinquish/Handoff Control)
0001.11
Wait for Vehicle Data Link
Transition Coordination
Message
0 (Don’t wait)
Note that it is possible for a UA to release an LOI connection while still maintaining
other connections. For example, the CUCS can maintain a LOI 2 connection while it
hands off LOI 4 to another control station (assuming that the UA is capable of
maintaining a data link with each CUCS).
The VSM/UA/Payload Station releases the LOI connection by sending Message #21
with an updated set of granted LOI connections in the LOI Granted field (Unique ID
0021.07). To release all LOI connections, set this field to zero.
Unique
ID
Name
Value
0021.07
LOI Granted
0 (Release all connections) or < LOIs still
granted to the CUCS>
A3.1.2.3.4.2 Release Control of Data Links
To request releasing control of a data link, the CUCS sends Message #404.
Unique
ID
Name
Value
0404.02
Vehicle ID
<Vehicle ID> (If applicable)
0404.03
CUCS ID
<ID of CUCS that is requesting >
0404.04
VSM ID
<VSM ID> (if applicable)
0404.05
Data Link ID
<Data Link ID>
0404.06
Control Assignment
Request
1 (Release Control)
The CDT/VDT responds to this request by sending a Message #500 with the Data Link
Control Availability field (Unique ID 0500.06) indicating that the request has been
granted.
Unique
ID
Name
Value
0500.06
Data Link Control
Availability
2 (Request Granted)
The CDT/VDT can also release control at any time by sending a Message #500 with
the Data Link Control Availability field (Unique ID 0500.06) set to unavailable.
A3 - 16
Edition A Version 1
AEP-84.1
Unique
ID
Name
0500.06
Data Link Control
Availability
Value
0
(Unavailable for Control)
A3.1.2.4 Downloading Configuration Data
Not all UA are built with the same capabilities. Some can fly extremely high and far
while others fly low for short durations. Some are capable of following preprogrammed routes while some can only loiter. Some have EO/IR cameras that are
capable of firing lasers while some carry CBRN sensors to detect harmful substances.
A CUCS needs to be able to understand these capabilities and constraints so that it
can provide an appropriate User Interface to the operator. In STANAG 4586, a
UA/VSM/CDT/VDT/Payload Station declares its configuration to a CUCS with the
following configuration messages:
Name
ID
Vehicle Station
Data
Link
Vehicle Configuration
100
Yes
No
No
Payload Configuration
300
No
Yes
No
EO/IR Configuration State
301
No
If EO/IR
No
CBRN Payload Configuration State
310
No
If CBRN
No
Field Configuration Integer Response
1300
Field Configuration Double Response
1301
Field Configuration Enumerated
Response
1302
Field Configuration Command
1303
Field Configuration Unsigned
Response
1305
Vehicle Steering/Operating Mode
Configuration
1306
If needed
Yes
No
No
The combined set of information that is transmitted via these messages is often
referred to as an entity’s Configuration Data. These messages are sent during the
Downloading Configuration Data phase of Entity Connection Management.
Note that a CUCS cannot send Configuration Messages to the entity.
A3.1.2.4.1 UA Specific Configuration Messages
Message #20 (Vehicle Configuration) is used to indicate some UA specific
configuration information that cannot be conveyed via the generic messages. This
contains information such as the number of engines and the maximum fuel/battery
capacity.
A3 - 17
Edition A Version 1
AEP-84.1
Message #1306 (Vehicle Steering/Operating Mode Configuration) is used to configure
the availability of enumerations in Message #49 (Vehicle Steering/Operating Mode) on
a per flight mode basis.
A3.1.2.4.2 Payload Specific Configuration Messages
Message #300 (Payload Configuration) is used to indicate the type of each Payload
Station that is available for configuration. For instance, a payload could be a
SAR/GMTI payload or a CBRN sensor.
If the payload is a CBRN sensor more configuration information will be conveyed in
Message #310 (CBRN Payload Configuration State). Message #301 (EO/IR
Configuration State) will be used if the payload is an EO, IR or EO/IR payload.
A3.1.2.4.3 Data Terminal Specific Configuration Messages
There are no CDT/VDT specific configuration messages. Configuration is achieved
entirely through the generic messages.
A3.1.2.4.4 Generic Configuration Messages
Each type of entity is assumed to support a specific set of messages as defined by
the table below:
Type
Messages Supported By Default
UA
40, 41, 44-47, 49, 101-111, 600, 700, 800806, 900, 1000, 1001, 1100, 1101, 1202,
1304, 1500-1503, 1600
EO, IR, EO/IR Payload
200, 201, 302, 1000, 1001, 1100
SAR Payload
202, 303, 1000, 1001, 1100
Stores Management Payload
1000, 1001, 1100, 1800-1830, 19001920,1922-1926
Communications Relay
Payload
204, 305, 1000, 1001, 1100
CBRN Payload
Payload Door
208-212, 309-311, 313, 314, 1000, 1001,
1100
208-212, 213, 309-311, 312, 313, 314,
1000, 1001, 1100
206, 308, 1000, 1001, 1100
Recorder Payload
205, 306, 307, 1000, 1001, 1100
CDT/VDT
400-403, 501-503, 1000, 1001, 1100, 1101,
1304
CBRN Standoff Payload
Table A3 - 3: Entity Types
A3 - 18
Edition A Version 1
AEP-84.1
A CUCS should assume that each UA/Payload Station/CDT/VDT provides full support
of each message, field and enumeration for their respective message sets unless
otherwise declared during the Downloading Configuration Data phase.
Configuration Data is communicated through the use of the following generic
configuration messages:
Name
ID
Field Configuration Integer Response
#1300
Field Configuration Double Response
#1301
Field Configuration Enumerated Response #1302
Field Configuration Command
#1303
Field Configuration Unsigned Response
#1305
With these generic configuration messages, an entity can declare:





If a capability is not supported
If a capability is unavailable
The acceptable limits and resolution of message fields
Warning and alert thresholds of message fields
Custom enumerations for enumerated message fields
Note that some messages are expected to be supported by an entity to facilitate Entity
Connection Management. As such, an entity cannot use any of the generic
configuration messages to change support or availability of these messages. They are
defined in the following table:
Type
Messages That Are Expected To Be Fully
Supported (i.e., Are Not Configurable)
UA
21, 1300, 1301, 1302, 1303, 1305, 1306,
1400, 1402, 1403
EO, IR, EO/IR Payload
301, 1300, 1301, 1302, 1303, 1305, 1400,
1402, 1403
All Other Payloads
1300, 1301, 1302, 1303, 1305, 1400, 1402,
1403
CDT/VDT
500, 1300, 1301, 1302, 1303, 1305, 1400,
1402, 1403
Table A3 - 4: Fully Supported Messages
A3.1.2.4.5 Declaring That a Message Is Not Supported
If an entire message is not supported by an entity, it can send Message #1303 (Field
Configuration Command) to declare that the entire message is not supported.
A3 - 19
Edition A Version 1
AEP-84.1
Unique
ID
Name
Value
1303.06
Reported Message
<Applicable message>
1303.07
Reported Field
0
For example, if a vehicle does not support the IFF messages it can send the following
messages:
Message ID
Reported Message
Reported Field
1303
1500
0
1303
1501
0
1303
1600
0
Note that it is not possible to declare that a message or field is supported since
STANAG 4586 assumes that everything is supported by default.
A3.1.2.4.6 Declaring that a Field is Not Supported
If a field is not supported by an entity, it can send a #1300, #1301, #1302 or #1305
Message (depending on the type of field) to indicate that the field is not supported:
Unique ID
Name
Value
130[0|1|2|5].07 Requested Message
<Applicable message>
130[0|1|2|5].08 Requested Field
<Applicable field>
130[0|1|2|5].09 Field Supported
0 (Field Not Supported)
For instance, if a vehicle doesn’t support the capability to indicate which waypoint it is
flying “From”, it can send the following messages:
Message ID
Reported
Message
Reported Field
Field Supported
1301
110
6
0
1301
110
7
0
1301
110
8
0
1301
110
9
0
1305
110
10
0
A3.1.2.4.7 Declaring that an Enumeration is Not Supported
If an entity does not support a field’s enumeration, it can send Message #1303 to
indicate that the enumeration is not supported:
A3 - 20
Edition A Version 1
AEP-84.1
Unique
ID
Name
Value
1303.06
Reported Message
<Applicable message>
1303.07
Reported Field
<Applicable field>
1303.08
Field Available
0 (All enumerations are unavailable to
start) or 1 (All enumerations are available
to start)
1303.09
Reported Enumeration
Index
<Applicable enumeration>
1303.10
Enumerated Index
Enable
-2 (Not Implemented)
For instance, if an EO/IR payload doesn’t have a Cage Operating Mode it can send
the following:
Message
ID
Reported
Message
Reported
Field
Field
Available
Reported
Enumeration
Index
Enumerated
Index Enable
1303
201
6
1
2
-2
1303
302
6
1
2
-2
A3.1.2.4.8 Declaring That a Bit in a Bit Field Is Not Supported
If an entity does not support a specific bit in a bit field, it can send Message #1303 to
indicate that the bit is not supported:
Unique
ID
Name
Value
1303.06
Reported Message
<Applicable message>
1303.07
Reported Field
<Applicable field>
1303.08
Field Available
0 (All bits are unavailable to start) or 1 (All
bits are available to start)
1303.09
Reported Enumeration
Index
<Applicable bit> (Note that this is the index
of the bit starting at 0, not the value of the
bit. E.g.:
0=0x0001, 1=0x0002, 2=0x0004,
3=0x0008, etc…
1303.10
Enumerated Index
Enable
-2 (Not Implemented)
A3 - 21
Edition A Version 1
AEP-84.1
A3.1.2.4.9 Declaring Entity Specific Enumerations
There are many cases where an entity will need to define custom enumerations. For
example, a UA will likely define Flight Termination modes in Message #46 (Flight
Termination Command) since STANAG 4586 does not define any by default.
To declare new enumerations, an entity can use Message #1302 (Field Configuration
Enumerated Response) with the enumeration index and enumeration text.
Unique
ID
Name
Value
1302.07
Requested Message
<Applicable message>
1302.08
Requested Field
<Applicable field>
1302.09
Field Supported
1 (Field Supported)
1302.10
Enumeration Count
Total number of enumerations available
1302.11
Enumeration Index
<New enumeration index>
1302.12
Enumeration Text
<Text for the new enumeration>
1303.13
Help Text
<Helpful text to describe the enumeration>
For example, a UA can declare two Flight Termination Modes “Parachute” and
“Spiral Down” with the following messages:
Messag
e ID
Reporte
d
Messag
e
Reporte
d Field
Field
Supporte
d
Enumeratio
n Count
Enumeratio
n Index
Enumeratio
n Text
1302
46
5
1
2
1
Parachute
1302
46
5
1
2
2
Spiral
Down
1302
108
5
1
2
1
Parachute
1302
108
5
1
2
2
Spiral
Down
Note that an entity can only declare new enumerations for fields that list “VSM
specific” or “Payload specific” and the enumerations should be in the ranges
provided.
A3.1.2.4.10 Declaring That a Capability is not Available
There are many capabilities of an entity that may be temporarily unavailable to a
CUCS. For instance, if an EO/IR payload hasn’t been powered on, it is unlikely that
the CUCS will be able to use the laser rangefinder or pointer.
A3 - 22
Edition A Version 1
AEP-84.1
A CUCS will assume that all supported functionality is immediately available to use
once a connection has been established with an entity unless the entity has declared
otherwise. The entity can do this by sending Message #1303:
Unique
ID
Name
Value
1303.06
Reported Message
<Applicable message>
1303.07
Reported Field
<Applicable field>
1303.08
Field Available
0 (Field not available) or 1 (Field available)
1303.09
Reported Enumeration
Index
<Applicable enum or bit if needed>
1303.10
Enumerated Index
Enable
-1 (Not Available)
For example, if the CUCS cannot request any laser rangefinder changes and none of
the laser rangefinder status fields are valid, the entity can send the following:
Message
ID
Reported
Message
Reported
Field
Field
Available
1303
201
12
0
1303
201
13
0
1303
302
21
0
1303
302
23
0
1303
302
24
0
Note that there is a special exception for the enumerations of Message #49 (Vehicle
Operating Mode and Steering Command). See Section A3.2.4.11 Declaring Entry
Values and Availability of Flight Navigation Enumerations for Each Flight Mode for
more information.
A3.1.2.4.11
Declaring Entry Values and Availability of Flight Navigation
Enumerations for Each Flight Mode
One of the problems experienced by early Edition 2 (now known as AEP-84 Volume I)
adopters was the need to send a set of #1303 Messages after each flight mode
change. This is because the availability of the enumerations in the flight control
messages (Message #43 and Message #48 in these earlier editions which have now
been replaced with Message #49) typically changes from flight mode to flight mode.
This could lead to several different timing problems that impacted flight controls so
AEP-84 Volume I introduced the capability to pre-define the availability of these
enumerations for each flight mode.
A UA/VSM can send a Message #1306 for each flight mode that it has implemented.
The CUCS will use the Entry Value fields in these messages to populate the fields of
A3 - 23
Edition A Version 1
AEP-84.1
Message #49 when the operator requests a new flight mode. This is important
because Message #49 is a large message and may contain fields that are relevant to
the requested flight mode.
If the UA/VSM switches to the new flight mode, the CUCS can immediately modify its
User Interface to reflect the Availability fields in the Message #1306 associated with
the new flight mode (as opposed to waiting for an unknown number of #1303
Messages to change the availability).
A CUCS should ignore any Availability fields where the associated field has been
declared to not be supported. For example, if the CUCS received Message #1303
declaring Vertical Speed Altitude (Unique ID 0043.04 Enumeration 2) is unsupported,
then the CUCS should ignore the contents of Vertical Speed Altitude Command Type
Availability (Unique ID 1306.07) since this enumeration is not supported.
A3.1.2.4.12 Declaring Limits for a Field
If a UA cannot (or will not) use the complete range of a message field, it can declare
that only a smaller range is acceptable. For instance, a UA may only accept speed
commands higher than 5 m/s to prevent its engine from stalling. With this knowledge,
the CUCS can prevent the operator from entering values lower than 5 m/s.
To declare limits for a field, an entity will send either Message #1300, #1301 or #1305
(depending on the type of field):
Unique ID
Name
Value
130[0|1|5].07 Requested Message
<Applicable message>
130[0|1|5].08 Requested Field
<Applicable field>
130[0|1|5].09 Field Supported
1 (Field Supported)
130[0|1|5].10 Max Value
<Maximum limit>
130[0|1|5].11 Min Value
<Minimum limit>
For instance, if a UA can:



Accept speed commands between 5 m/s and 15 m/s, and
Report Indicated and True Airspeeds from 0 m/s to 25 m/s, and
Report ground relative northing and easting magnitudes up to 100 m/s
It can send the following configuration messages:
Message
ID
Requested Requested
Message
Field
Field
Supported
Max Value
Min Value
1301
49
13
1
15.0
5.0
1301
102
6
1
25.0
0.0
1301
102
7
1
25.0
0.0
A3 - 24
Edition A Version 1
AEP-84.1
1301
101
8
1
100.0
-100.0
1301
101
9
1
100.0
-100.0
1301
102
17
1
100.0
-100.0
1301
102
18
1
100.0
-100.0
A3.1.2.4.13 Declaring Alert Zones for a Field
It is often valuable for an operator to know if an important attribute is operating outside
of its nominal range. For instance, a UA may be leaking fuel if Current Propulsion
Energy Usage Rate is too high or the IMU may be defective if the Roll that is greater
than the UA is designed to allow.
An entity can identify the alert using Message #1300, #1301 or #1305:
Unique ID
Name
Value
130[0|1|5].07 Requested Message
<Applicable message>
130[0|1|5].08 Requested Field
<Applicable field>
130[0|1|5].09 Field Supported
1 (Field Supported)
…
…
…
130[0|1|5].15 High Caution Limit
<Threshold to trigger an Upper Caution
Alert >
130[0|1|5].16 High Warning Limit
<Threshold to trigger an Upper Warning
Alert >
130[0|1|5].17 Low Caution Limit
<Threshold to trigger an Lower Caution
Alert >
130[0|1|5].18 Low Warning Limit
<Threshold to trigger an Lower Warning
Alert >
An entity can indicate up to four alert zones as illustrated on the right side of Figure A3
- 2. The left side shows the meaning of the values in Message #1300, 1301 and 1305.
Max Value
Upper Warning Zone
High Warning Limit
Upper Caution Zone
High Caution Limit
Nominal Zone
Low Caution Limit
Lower Caution Zone
Low Warning Limit
A3 - 25
Min Value
Lower Warning Zone
Edition A Version 1
AEP-84.1
Figure A3 - 2: Alert Zones within a Numerical Field
Each of the four zones is optional. For example, an entity can choose to only declare
high limits or only low limits for a field or only caution zones. To indicate that a zone
is not applicable, the entity can set the associated limit to a value higher than the Max
Value or lower than the Min Value. For instance, to specify a Lower Caution Zone is
not applicable, the Low Caution Limit should be set a value lower than the Min Value.
STANAG 4586 does not define the HMI for how the CUCS will bring this information
to the operator’s attention. One CUCS may display the values in different color while
another CUCS may display a persistent window with values that are out of nominal
range.
Also note that limits cannot be defined for enumerated fields since enumerations do
not typically represent a continuous range.
A3.1.2.4.14 Declaring Help Text for a Field
In some cases, an operator could benefit from additional information about a particular
field or enumeration. For instance, if a UA reports a custom flight mode named
“Evade”, the operator may benefit from the help text “UA will speed up, zig zag and
change directions constantly”.
Note that in most systems it is expected that an operator will be trained on the different
attributes of a vehicle before flight so the extra help may be redundant. Historically the
Help Text field has been more valuable for engineers that are integrating the system.
A3.1.2.5 Changing Configuration Data
In many situations an entity’s Configuration Data will change over time. This can be
for a wide variety of reasons ranging from flight mode state changes to malfunctioning
sensors. Regardless of the reason, the entity has the ability to update some
Configuration Data through the following mechanisms.
A3.1.2.5.1 Changing Field Availability
An entity can send Message #1303 to indicate that a field’s availability has changed.
It will do this by setting the fields as follows:
Unique
ID
Name
Value
1303.06
Reported Message
<Applicable message>
1303.07
Reported Field
<Applicable field> (0 does not apply)
1303.08
Field Available
Either 0 (Not Available) or 1 (Available)
1303.09
Reported Enumerated
Index
Not applicable
A3 - 26
Edition A Version 1
AEP-84.1
1303.10
Enumerated Index
Enable
Not applicable
If the Reported Field refers to an enumerated field, the Field Available will apply to all
supported enumerations in the field. This provides a simple way for an entity to disable
or enable all the enumerations at once. If the entity only wishes to enable a few of the
enumerations, refer to the next section.
For example, an EO/IR payload station may indicate that the Set Centerline Azimuth
(Unique ID 0200.05) and Set Centerline Elevation Angle (0200.06) fields are not
available if its current EO/IR Pointing Mode (Unique ID 0302.19) is Lat-Long Slaved.
A3.1.2.5.2 Changing Enumeration Availability
An entity can send Message #1303 to indicate that an enumeration’s availability has
changed. It will do this by setting the fields as follows:
Unique
ID
Name
Value
1303.06
Reported Message
<Applicable message>
1303.07
Reported Field
<Applicable field> (0 does not apply)
1303.08
Field Available
1
1303.09
Reported Enumerated
Index
<Applicable enumeration>
1303.10
Enumerated Index
Enable
Either -1 (Not Available) or 0 (Available)
Note that Unique ID 1303.10 should not be set to “-2 = Not Implemented”. This is
reserved for during the initial configuration download.
For example, if an EO/IR payload station has reached its maximum zoom level, it can
tell the CUCS that the “2 = Zoom In” enumeration for the Set Zoom (Unique ID 0200.17)
field is no longer available.
A3.1.2.5.3 Changing Bit Field Availability
An entity can send Message #1303 to indicate that a bit in a Bitmapped field’s
availability has changed. This is exactly the same as changing an enumeration, except
the right most bit is considered Enumeration 0, the second right most bit is considered
Enumeration 1, and so on.
Unique
ID
Name
Value
1303.06
Reported Message
<Applicable message>
1303.07
Reported Field
<Applicable field>
1303.08
Field Available
1
A3 - 27
Edition A Version 1
AEP-84.1
1303.09
Reported Enumeration
Index
<Applicable bit> (Note that this is the index
of the bit starting at 0, not the value of the
bit. For example:
0=0x0001, 1=0x0002, 2=0x0004,
3=0x0008, etc…)
1303.10
Enumerated Index
Enable
Either -1 (Not Available) or 0 (Available)
A3.1.2.5.4 Changing Entry Values and Availability of Flight Navigation
Enumerations for Each Flight Mode
If an entry value or the availability of an enumeration changes for any flight mode, the
UA/VSM should send updated #1306 Messages so the CUCS uses the new
information when it switches into the new flight modes.
For example, if the UA is too high for the radar altimeter to be effective, it may want to
send Message #1306 with an update to the Altitude Type Entry Value (Unique ID
1306.24) to indicate that enumeration “2 = AGL: is no longer available. To make the
change consistent for all flight modes, the UA/VSM would need to send a Message
#1306 for each implemented flight mode.
A3.1.2.5.5 Changing Field Limits
In some circumstances, an entity may be required to change the valid limits of a field.
For instance, if the vehicle’s stall speed changes it can notify the CUCS that the
minimum speed command should be changed. This can be accomplished with either
Message #1300, #1301 or #1305 depending on the field required:
Unique ID
Name
Value
130[0|1|5].07 Requested Message
<Applicable message>
130[0|1|5].08 Reported Field
<Applicable field>
130[0|1|5].09 Field Supported
1
130[0|1|5].10 Max Value
<New max value>
130[0|1|5].11 Min Value
<New min value>
A3.1.2.5.6 Changing Warning and Caution Thresholds
Message #1300, #1301 and #1305 can be pushed from the VSM to update the warning
and cautions thresholds.
A3.1.2.5.7 Changing a Previously Unsupported Capability to be Supported
While STANAG 4586 does not specifically prevent this behaviour it is recommended
that this functionality be avoided. Many UA designers and members of the STANAG
4586 community have indicated that they would not support it. Consider declaring the
capability unavailable instead of unsupported.
A3 - 28
Edition A Version 1
AEP-84.1
A3.1.3 Mission Transfer
There are two primary cases that need to be handled for mission transfer. Missions
may be transferred from a CUCS to a UA/VSM and they may be transferred from a
UA/VSM to a CUCS. The messages required for delivery of the mission information
are Messages #800 - #806 and Message #900. Message #800 (Mission Transfer) is
the master message that controls the direction and scope of individual mission
transfers and Message #900 describes the progress and status of each mission
transfer from a UA/VSM to a CUCS. Message #900 also indicates to the CUCS the
progress that the UA/VSM has made in receiving a mission plan from the CUCS and
successfully loading it onto the UA embedded avionics. (Note that in AEP-84 Volume
I, Message #900 does not describe which mission transfer it is providing status for, in
the event that more than one is in progress, so it is strongly recommended that only a
single mission should be transferred from a UA/VSM to a CUCS at one time. This has
been corrected in AEP-84 Volume II)
The Mission Upload Command (Message #800) is used to control the overall upload,
download and storage of a mission between the CUCS and VSM/UA. Message #900,
Mission Upload/Download Status, is used by the VSM to report the status of the upload
or download of the mission to and from the VSM respectively. Until the mission has
been uploaded to the UA, the CUCS operator should not be provided the capability to
control the UA in the “waypoint” Flight mode as defined in Message #49. Refer to the
following sections for additional details.
While in the “waypoint” Flight mode of operation, it is expected that the VSM report the
“From”, “To,” and “Next” waypoint information to the CUCS using Message #104,
Vehicle Operating States, upon a change in state/value of any of the waypoint
parameters.
The structure of missions, routes and waypoints is shown below. Missions may contain
one or more routes and routes may contain one or more waypoints. Routes are defined
using Message #801 that names the route and provides the first waypoint in the route.
Each waypoint is defined using Message #802 and each waypoint provides the next
waypoint number in the route that it is on, or it may indicate that it is the final waypoint
on the route by indicating that the next waypoint number is zero. Routes are included
in missions through their transmission prior to the transmission of a Mission Transfer
Command (Message #800). It is very strongly recommended (essential) that
acknowledgments for all mission Messages #800 - #806 be used.
A3 - 29
Edition A Version 1
AEP-84.1
Mission Plan ID #800
Route ID #801
Route ID #801
#802
#802
First WP #
WP
#
WP
#
#802
Next WP #
#803
#804
Loiter
First WP #
#802
Next WP #
WP
#
#803
WP
#
Loiter
#804
WP
WP
#802
#802
WP
#
#804
Payload
Action
Payload
Action
#805
Airframe
Action
WP
#
#804
#805
#806
Airframe
Action
Vehicle
Specific WP
#806
Vehicle
Specific WP
Figure A3 - 3: Mission Plan ID
Loiter Points (#803), Payload Actions (#804), Airframe Actions (#805) and Vehicle
Specific Waypoint (#806) actions are associated with waypoints by using the
respective messages listed. Each of the Messages #803 - #806 includes the waypoint
number with which the loiter, payload action, airframe action or vehicle specific action
is associated.
To send a mission plan from a CUCS to a UA/VSM the following sequence of
messages should be sent from the CUCS to the UA/VSM:
1. Send all of the waypoints using #802 Messages
2. Send all of the associated loiters, payload actions, airframe actions and vehicle
specific actions using Messages #803, #804, #805 and #806.
3. Send the route messages that define the starting points, provide the route IDs
and route types for each route using #801 Messages
4. Send the #800 Mission Message with field #5 set to “2 = Transmit Mission”
which implies that all of the prior routes and waypoints are included in the
Mission ID provided by the #800 Message.
Note: It is nearly essential that all of these messages be acknowledged to ensure that
the mission is transferred accurately and completely. The order of steps 1, 2 and 3
may be changed without any impact to interoperability. The order provided here is
expected to reduce computational complexity.
To have a CUCS acquire a mission plan from a UA/VSM, the following sequence of
messages should be sent:
1. The CUCS sends #800 Message to the UA/VSM with field #5 set to “3 =
Receive Mission” and with the Mission ID sent in Field #4.
A3 - 30
Edition A Version 1
AEP-84.1
2. The UA/VSM sends Messages #802, #803, #804, #805, #806 and #801 to the
CUCS (these should all be acknowledged) and intersperses #900 Messages
to indicate the progress of the transfer. The final #900 Message from the
UA/VSM should follow all of the 800 series messages, should indicate 100%
transfer and should be acknowledged. (Note that the order of the #801 - #806
Messages will not affect interoperability.)
In order to have a CUCS acquire a single waypoint from a UA/VSM, the following
sequence of messages should be sent:
1. The CUCS sends #800 Message to UA/VSM with Field #5 set to “4 = Receive
Single Waypoint” and with the waypoint number sent in Field #6.
2. The UA/VSM sends a single #802 Message corresponding to the waypoint
number requested in the #800 Message and all of the #803, #804, #805 and
#806 Messages associated with that waypoint, if any. Then the UA/VSM
should send a #900 Message indicating 100% transfer. All of these messages
should be acknowledged.
The following list of messages are the messages that have been developed to transfer
a mission plan from a CUCS to an UA through the DLI, and to download the mission(s)
that are currently loaded on the UA :








Mission Transfer Command (Message #800)
UA Route (Message #801)
Mission Upload/Download Status (Message #900)
UA Position Waypoint (Message #802)
UA Loiter Waypoint (Message #803)
Payload Action Waypoint (Message #804)
Airframe Action Waypoint (Message #805)
Vehicle Specific Waypoint (Message #806)
The UA Position Waypoint (Message #802) is the base message for defining a mission
waypoint and all the other waypoint messages must reference this message. For each
UA Position Waypoint there may be a loiter (Message #803), payload (Message #804),
airframe (Message #805) and/or vehicle specific (Message #806) message linked to
that waypoint. The “Waypoint Number” field in each of the messages is the link that
ties each of the messages together. Figure A3 - 4 represents the association between
the mission waypoint messages. Only the UA Position Waypoint is mandatory for
creating a mission as it defines the sequence of waypoints within the mission; all of the
other waypoint messages are optional per waypoint based on what is supported by the
UA/ VSM.
The mission(s) are uploaded from the CUCS to the VSM as a series of individual
waypoints based on the UA Position Waypoint Message (Message #802). The Mission
Waypoints may be loaded to the VSM in any order as the UA Position Waypoint
identifies the “Waypoint Number” being uploaded in the message and the “Next
Waypoint” in the sequence is identified in the message as well. Waypoint numbers do
not need to be contiguous within a mission, however it is recommended that they are
made contiguous.
A3 - 31
Edition A Version 1
AEP-84.1
UA Position Waypoint
- Message #802
- Latitude
- Longitude
- Altitude
- Airspeed
- Next Waypoint
- Required
UA Loiter
- Message #803
- Optional
Payload Action
- Message #804
- Optional
Airframe Action
- Message #805
- Optional
Vehicle Specific Action
- Message #806
- Optional
Figure A3 - 4: Mission Waypoint Message Link
A3.1.3.1 Message #800: Mission Transfer Command Implementation
Message #800 is pushed from either the UA/VSM to the CUCS or from the CUCS to
the UA/VSM. If pushed from a CUCS, the CUCS must have LOI 4 control over the
UA/VSM to transfer a mission to the UA. However, a CUCS with LOI 2 authorization
may request that the UA/VSM send an existing UA/VSM mission to the CUCS but it
may not send a mission to the UA/VSM.
Message #800 Unique ID 0800.05 (Mission Plan Mode) describes the type of mission
transfer command that is to occur. Message #800 may also be used to clear an
existing mission or to cancel a mission transfer that is pending or is in progress. The
Unique ID 0800.05 values and their meanings are described in the table below.
Message #800 Unique ID
0800.05 Value
1 = Clear Mission
Meaning
The mission with the Mission ID contained in
Message #800 (Unique ID 0800.04) is to be
cleared by the receiving component. This should
be sent only from the CUCS to the UA/VSM.
Storage of missions by a CUCS should not be
controlled from the UA/VSM.
A3 - 32
Edition A Version 1
AEP-84.1
2 = Transmit Mission
After the mission with the Mission ID contained in
Message #800 (Unique ID 0800.04) has been sent
to the UA/VSM from the CUCS through the
transmission of all required Messages #801 - #806,
if a VSM is required to convert the mission into a
vehicle specific format, then it should perform that
conversion and send the mission to the UA. If the
UA receives the #801 - #806 Messages directly,
then it should load the mission.
This value should not be sent from the UA/VSM to
the CUCS.
3 = Receive Mission
The mission with the Mission ID contained in
Message #800 (Unique ID 0800.04) is to be sent
from the receiving component to the sending
component. If sent from the CUCS to the UA/VSM,
the requested mission should be sent to the CUCS.
If sent from the UA/VSM, the requested mission
should be sent to the UA/VSM.
4 = Receive Single Waypoint
The waypoint with the number contained in
Message #800 (Unique ID 0800.06) is to be sent
from the receiving component to the sending
component. If sent from the CUCS to the UA/VSM,
the requested waypoint should be sent to the
CUCS. If sent from the UA/VSM, the requested
waypoint should be sent to the UA/VSM.
5 = Cancel Transmit/Receive
In AEP-84 Volume I, there should only be a single
pending mission or waypoint transfer in progress
at any time, since there is not a mechanism to
differentiate between two transfers. This value
indicates that the transfer in progress should be
stopped.
Table A3 - 5: Message #800 Field 5 Values
The Mission Transfer Command is used to control the overall upload, download and
storage of a mission between the CUCS and VSM/UA. The Mission Transfer
Command has been developed to account for situations where the VSM may be
located on the ground as well as for situations where the Mission Waypoint Messages
may be transmitted directly to the UA (VSM in the UA) from the CUCS.
The first step in the Mission Upload process is to transmit all the DLI mission waypoints
from the CUCS to the VSM (e.g., Message #802, 803, 804, 805, 806). Refer to Figure
A3 - 5 for a representation of the Mission Upload sequence of events. The next step in
the process is to transmit the optional Message #801, UA Route, messages to the
VSM to identify the Route ID and Route Type if required. In the absence of a UA Route
Message (#801), the route type defaults to “Flight” and no Route ID or initial waypoint
is designated; this enables upload of anonymous sequences of waypoints. After the
CUCS has transmitted the complete set of DLI mission waypoints and UA Route
Messages to the VSM, the CUCS transmits the Mission Transfer Command (Message
#800) with the “Mission Plan Mode” set to “2 = Transmit Mission”.
A3 - 33
Edition A Version 1
AEP-84.1
Where the VSM is on the ground (UA does not transmit STANAG DLI messages), the
Mission Upload Command is used to control the translation of the DLI Mission
Waypoint Messages to the UA native (IDD) mission format.
Step 1: CUCS transmits all of the mission Waypoints and their associated parameters to the
VSM.
CUCS – Mission Waypoints
VSM – Mission Waypoints
Message # 802
Message # 802
- Waypoint Number
- Waypoint Number
- Message #803
- Message #803
- Message #804
- Message #804
- Message #805
- Message #805
- Message #806
- Message #806
Step 2: CUCS transmits Message #800 to VSM.
CUCS – Mission Transfer Command
Message #800
- Mission Plan Mode
Transmit Mission
VSM
Step 3: VSM converts mission messages to vehicle native mission format.
VSM
Vehicle Native Mission
Format
VSM
Message # 802
- Waypoint Number
- Message #803
- Message #804
- Message #805
- Message #806
Step 4: VSM transmits the vehicle native mission format to the air vehicle.
Air Vehicle
Vehicle Native Mission
Format
VSM
Vehicle Native Mission
Format
Figure A3 - 5: Mission Message Upload Sequence with VSM
Once all the mission waypoints have been transmitted from the CUCS to the VSM,
a Mission Transfer Command (Message #800) is transmitted with the Mission Plan
Mode field set to “2 = Transmit Mission” to indicate to the VSM that the transmitted DLI
mission waypoints are ready to be converted to the vehicle specific format and then
transmitted to the UA. (This means the VSM is responsible for converting the mission
from the DLI Mission Message format to any vehicle native format required, and then
transmitting it to the UA.)
Where the UA can accept the DLI Mission Waypoints Messages directly (e.g., VSM
on-board the UA), the reception of a Mission Transfer Command (Message #800) with
the Mission Plan mode field set to “2 = Transmit Mission” signifies that all the DLI
mission waypoints have been transmitted to the UA. The UA would then perform any
required mission format conversions.
Message #900, Mission Upload/Download Status, is used by the VSM/UA to provide
the status of the mission upload to the UA. This means the transmission of the vehicle
native waypoints (mission) from the VSM to the UA. The VSM will report the upload
as “In Progress” and the “Percent Complete”, or as “Complete.”
A3 - 34
Edition A Version 1
AEP-84.1
The Mission Upload sequence as defined above may be used by the CUCS to replace
specific waypoints within a previously loaded mission, or to insert new waypoints within
the defined mission. If the intention of the mission upload is to entirely replace the
mission that is currently loaded on the UA, the CUCS should transmit the Mission
Transfer Command (Message #800) with the Mission Plan Mode field set to “1 = Clear
Mission” to identify to the VSM that all previously loaded waypoints are now invalid.
The “1 = Clear Mission” should be sent prior to other #80X Messages that redefine the
mission.
The Mission Plan Mode “3 = Receive Mission” and “4 = Receive Single Waypoint” are
used to request the download of the mission waypoint information currently loaded to
the UA. Where the VSM is located on the ground, this is not a request for the DLI
mission waypoints that were previously uploaded to the VSM from the CUCS as these
may be different from the mission plan that is loaded on the UA. When the VSM
receives this command from the CUCS, the VSM must first query the UA for its current
mission plan, convert this vehicle native mission plan to the DLI Mission Waypoint
formatted messages, and then transmit the DLI Mission Waypoint Messages to the
CUCS. If the UA is capable of directly transmitting DLI Mission Waypoint Messages
(e.g., VSM on-board the UA), there is no additional conversion required. In the case
of a “Receive Mission” request, the VSM is required to download all of the UA Route
Message (Message #801) to the CUCS in addition to the Waypoint messages.
The “Waypoint Number” field in the Mission Transfer Command indicates which
waypoint to download in the case of a “Receive Single Waypoint” request. The VSM
responds to the waypoint request by sending all the available waypoint messages
(Message #802 required, Message #803,804,805, and 806 if available as they are
optional) for the specified waypoint number. The VSM is required to keep track of any
translations between the DLI mission waypoint number and vehicle native message
numbers as required to ensure a valid response is made to the mission waypoint query.
Message #900, Mission (VSM) Upload/Download Status, is used to report the status
of the Mission download from the VSM to the CUCS where a complete download has
been requested.
A3.1.3.2 Message #801: UA Route
This message is used to define a UA route. If the “Initial Waypoint Number” field in the
message is set to 0, the route definition (Route ID) defined in the message is deleted
from the VSM/UA, however the waypoints contained in the route definition are not.
A3.1.3.3 Message #802: UA Position Waypoint Implementation
The UA Position Waypoint Message defines the geographical location of a waypoint
that the UA will fly toward. The UA Position Waypoint Message is used to transmit a
series of waypoints from the CUCS to the VSM that are linked together using the “Next
Waypoint” field in Message #802 to form a single mission or series of smaller routes
for the UA. UA missions are created using the UA Position Waypoint by identifying the
“Waypoint Number” in the message with the next waypoint in the sequence being
identified by the “Next Waypoint” field in the message.
The VSM may be required to convert these mission waypoints into the format required
for transmission of the mission to the UA if it differs from the DLI message format.
The following attributes are defined for the waypoint in the message; the geographical
location of the waypoint, the airspeed at which the UA will fly toward the waypoint and
the altitude at which the UA will fly.
A3 - 35
Edition A Version 1
AEP-84.1
The “Next Waypoint” field provides the link from one waypoint to the next thus
identifying a sequence of waypoints, where a value of “zero” indicates that the waypoint
is the last waypoint in the sequence of waypoints. The UA Position Waypoint Message
may be used to create multiple waypoint sequences, where each sequence comprises
a different route, possibly with payload actions and other ancillary activities. To
command a specific mission, Message #49 is used as described above to direct the
UA to one of the waypoints on the sequence that makes up the route (note that it does
not have to be the first waypoint in the sequence). When the VSM receives the DLI
Mission Waypoints, if the UA does not support the DLI Mission Waypoints directly, the
VSM must convert the DLI Mission Waypoints to the vehicle specific format. If the
CUCS requests the download of a mission, the CUCS will receive the UA Position
Waypoint Messages from the VSM/UA that specified the requested mission. The
CUCS, if authorized, may then modify the missions by sending new #80X Messages
to the VSM/UA.
It is the responsibility of the CUCS to ensure the waypoints are correctly configured
before transmitting the information to the VSM. This includes ensuring that if two tasks
are linked together that the waypoint identifying the end of the first task is correctly
linked to the first waypoint in the second task, and that waypoint numbers are not
repeated within the tasks.
A3.1.3.4 Message #803: UA Loiter Waypoint Implementation
The UA Loiter Waypoint Message defines the loiter characteristics the UA will perform
once it has arrived at the waypoint location identified in the UA Position Waypoint
Message (Message #802) while in the Waypoint Flight mode.
A3.1.3.5 Message #804: Payload Action Waypoint Implementation
The Payload Action Waypoint Message defines the payload action that will be
performed when the UA begins to fly toward the waypoint identified in the UA Position
Waypoint Message (Message #802) for the identified waypoint number while in the
Waypoint Flight mode.
A3.1.3.6 Message #805: Airframe Action Waypoint Implementation
The Airframe Action Waypoint Message defines the Airframe action that will be
performed when the UA begins to fly toward the waypoint identified in the UA Position
Waypoint Message (Message #802) while in the Waypoint Flight mode. Airframe
actions include turning on/off UA navigation lights, data link transmitters, etc. as
identified in the Airframe Action Waypoint Message.
A3.1.3.7 Message #806: Vehicle Specific Waypoint Implementation
The Vehicle Specific Waypoint Message defines the vehicle specific actions that will
be performed when the UA begins to fly toward the waypoint identified in the UA
Position Waypoint Message (Message #802) while in the Waypoint Flight mode. This
message is used to pass any vehicle or payload specific information that is not covered
by the Generic Mission Upload Messages to the VSM, for subsequent transmission to
the UA. A waypoint value of zero indicates mission generic data that is not associated
with any specific waypoint. The following messages are considered the Generic
Mission Messages:




UA Position Waypoint (Message #802)
UA Loiter Waypoint (Message #803)
Payload Action Waypoint (Message #804)
Airframe Action Waypoint (Message #805)
A3 - 36
Edition A Version 1
AEP-84.1
Common Route Definition (CRD) data tags (see Attachment A in this document) may
be used to provide a standard and interoperable method to transfer information
between a CUCS and a VSM for data that is not supported by the generic message
set. To determine the required CRD data tag for a UA (vehicle specific) data element
the CRD Standard must be referenced.
One application of this message is to provide for the transmission of elements of the
CRD messages, received via the CCI interface, to a UA where the data elements
cannot be mapped to the generic mission messages. A VSM that does not support
the CRD data tags may ignore this message without causing adverse effects to the
system.
A3.1.3.8 Message #900: Mission Upload/Download Implementation
The Mission Upload/Download Message is sent by the VSM to the CUCS to provide
status on a mission upload/download from a VSM to a CUCS. More thorough
descriptions on the use of this message are provided throughout the Mission Message
implementation sections of this document.
A3.1.3.9 Relative Waypoints
The discussion above pertains to waypoint locations that are absolute. That is, they
are specified in terms of latitude and longitude values that are earth centric and fixed
within the earth’s frame of reference. STANAG 4586 also provides the capability to
specify waypoint locations in a different, possibly moving, reference frame using
Message #802 and Message #47. The Message #802 “Location Type” field uses
either the “Absolute” value for all of the discussion above or may use the “Relative”
value to specify waypoint locations in a different frame of reference. If the “Relative”
value is used, the frame of reference is acquired from Message #47. The Message
#47 table from AEP-84 Volume I is shown below.
Unique
ID
Field
Data Element Name &
Description
Type
Units
Range
0047.01
1
Time Stamp
Double
s
See Section 1.7.2
0047.02
2
Vehicle ID
Integer 4
None
See Section 1.7.5
0047.03
3
CUCS ID
Integer 4
None
See Section 1.7.5
0047.04
4
Latitude (Y-axis zero)
Double
rad
-π/2 ≤ x ≤ π/2
0047.05
5
Longitude (X-axis zero)
Double
rad
-π ≤ x ≤ π
0047.06
6
Altitude Type
Unsigned 1
Enumerated
0 = Pressure Altitude
1 = Baro Altitude
2 = AGL
3 = WGS-84
Defines altitude type
(reference frame) for all
altitude related fields in this
message
0047.07
7
Altitude
Float
m
-1,000 ≤ x ≤ 100,000
0047.08
8
Orientation
Float
rad
-π ≤ x ≤ π
Character 20
None
No Restrictions
Defines heading Y-axis.
0047.09
9
Route ID
Text identifier of route, or
null to update all routes.
Table A3 - 6: Message #47 from AEP-84 Volume I
To establish a relative reference frame, two things are required:
A3 - 37
Edition A Version 1
AEP-84.1

The origin of the reference frame

The orientation of the reference frame
The origin of the relative reference frame is specified on top of the earth centric fixed
latitude, longitude and altitude reference frame. Note: The Message #47 Latitude,
Longitude and Altitude fields serve this function. The Orientation of the relative
reference frame is specified using the Message #47 Orientation field.
For example, to specify a relative reference frame that was centred on a UA heading
due East (true, not magnetic), Message #47 would specify the latitude, longitude and
altitude of the vehicle and the orientation value would be East = π/2.
The Route ID value may be used to update only relative waypoints (with Message #802
values that use “Relative” location type) that have been specified to be on a specific
route. If set to zero, then the reference frame for all relative waypoints is updated.
Separation of the reference frame specification into a message (Message #47)
Start of route Alpha
Message 801
Route ID = Alpha
Initial WP = 1
Message 802
WP = 1
Next WP = 3
Start of route Bravo
Message 801
Route ID = Bravo
Initial WP = 2
Message 802
WP = 2
Next WP = 3
WP 3 is on both
route Alpha and
route Bravo!
Message 802
WP = 3
Next WP = …
Figure A3 - 6: Waypoint Transitions
separate from the relative waypoint values (Message #802), enables a relative
reference that moves to be easily specified through updating only the value of the
reference frame by sending a sequence of #47 Messages as the reference frame
moves and turns. Both normal and contingency waypoints may use the relative
reference frame.
Note, that for relative waypoints that may be reached from two or more different Route
IDs, updating the reference frame using a Route ID value may produce unexpected
behaviour. This can occur because the UA Route (Message #801) specifies only the
initial waypoint number. Subsequent waypoints may be reached through “Next
Waypoint” transitions from more than one Route ID initial waypoint as illustrated below.
A3.1.3.9 Contingency Setup with Lost Link Example
Contingency route setup is a normal part of uploading a mission to the UA. It is
therefore identical to transferring a mission from the CUCS to the UA as specified in
Section A3.1.3. The only difference from a normal mission transfer is that in addition
to specifying the “Next Waypoint” number in the UA Position Waypoint Message
(Message #802), the “Contingency Waypoint A” and/or “Contingency Waypoint B”
values are also specified. This defines up to two alternate routes to be followed during
off nominal conditions, described in further detail below. The following list of messages
has been developed to transfer a mission plan from a CUCS to an UA through the DLI:
A3 - 38
Edition A Version 1
AEP-84.1








Mission Upload Command (Message #800)
UA Route (Message #801)
Mission (VSM) Upload/Download Status (Message #900)
UA Position Waypoint (Message #802)
UA Loiter Waypoint (Message #803)
Payload Action Waypoint (Message #804)
Airframe Action Waypoint (Message #805)
Vehicle Specific Waypoint (Message #806)
The UA Position Waypoint (Message #802) is the base message for defining a mission
waypoint and all the other waypoint messages must reference this message. For each
UA Position Waypoint there may be a loiter (Message #803), payload (Message #804),
airframe (Message #805) and/or vehicle specific (Message #806) message linked to
that waypoint. The “Waypoint Number” field in each of the messages is the link that
ties each of the messages together. Figure A3 - 6 represents the association between
the Mission Waypoint Messages. Only the UA Position Message is required.
Message #802 includes two fields that may be used to specify contingency routes
through the use of “Contingency Waypoint A” or “Contingency Waypoint B”.
Contingency conditions (A or B) are vehicle specific and are defined by the UA to
describe off nominal conditions that are to be responded to by automatically changing
the vehicle route.
Typical off nominal conditions include loss of communication and/or equipment
failures. For example, if contingency condition “A” includes vehicle loss of
communication, then the UA would follow the route specified by all of the “Contingency
Waypoint A” waypoints. These would be used in place of the usual “Next Waypoint”
waypoints. Please refer to Message #802 Fields 13, 14, and 15.
The behaviour of the UA in transitioning from the normal route specified by the “Next
Waypoint” Field 13 values and the “Contingency Waypoint A” route specified by the
Field 14 values is vehicle specific. If the vehicle loses communication and that triggers
contingency condition “A”, the vehicle could begin to fly immediately to the waypoint
specified in Field 14, or it could complete its journey to the current waypoint and then
begin to use the “Contingency Waypoint A” route.
Note that Message #803, #804, #805 and #806 may be associated with waypoints on
the “Contingency Waypoint A” route. These may be used to configure the UA for the
specific contingency condition that caused the UA to transition to the contingency
route.
Note also, that a contingency route can be commanded as if the UA had experienced
an off nominal condition corresponding to that contingency level through the use of
Message #49 Field 20 (Unique ID 0042.04) using the values 23 or 24 to force
contingency route A or B. When these commands are sent the UA should remain in
the contingency level commanded until a Message #49 with a different value in Feld
20 (Unique ID 0042.04) is received. For example, to return to the normal sequence of
waypoints the value of 11 would be sent, directing the vehicle to fly its normal waypoint
sequence.
The “Contingency Waypoint” fields identify the waypoint toward which the UA will fly if
that contingency level is either commanded (as described above) or if the on-board
vehicle logic determines that contingency level has occurred due to some event or
combination of events.
A3 - 39
Edition A Version 1
AEP-84.1
The figure below provides a brief example of creating an alternate “contingency” route
through the use of the UA Position Waypoint Message.
Waypoint #1
Waypoint #5
Next Waypoint #2
Next Waypoint #6
Contingency Waypoint #5
Contingency Waypoint #200
Waypoint #2
Waypoint #6
Next Waypoint #3
Next Waypoint #200
Contingency Waypoint #200
Waypoint #3
Waypoint #7
Next Waypoint #4
Next Waypoint #200
Contingency Waypoint #200
Waypoint #4
Waypoint #200
Next Waypoint #5
Next Waypoint #0
Figure A3 - 7: Routes with UA Position Waypoint Message Contingencies
A3.1.4 Message Acknowledgment
Entities can use the STANAG 4586 acknowledgement system to detect if their
messages have arrived at their destination and whether their requests are rejected or
accepted and completed/failed. This is important since the underlying transport
mechanism (i.e., UDP) is not reliable and does not guarantee that packets arrive in the
same order that they were sent.
Acknowledgements are typically not needed for status messages that are sent
frequently and where the content of the most recent message supersedes the data of
the older messages. For instance, a UA may send Message #101, Inertial States, at a
rate of 5 Hz. In this case, there is little value in requesting an acknowledgement since
the data will be stale by the time the UA realizes that the CUCS did not receive the
message. The table below highlights situations where it is a good idea to use the
acknowledgement system.
Situation
Event-driven
Examples

Message #1100, Subsystem Status Alert,
when a Warning or Caution condition is
detected
A3 - 40
Edition A Version 1
AEP-84.1
The message is only sent when needed
(i.e., not sent periodically and not if
updates happen frequently)

Transactional


The message is part of a set of
messages where the receiving entity
should only accept the messages if all
the messages have been received


Sequential
The message is part of a sequence
where the order of receipt matters
Message #20, Vehicle ID, if a virtual
Vehicle ID is changed to a real Vehicle ID
Message #1303, Field Configuration
Command, to indicate that a Vehicle
Operating Mode is suddenly unavailable
Downloading Configuration Data
Transferring Route/Waypoint Messages
Message #1100, Subsystem Status Alert,
when responding to a request for
additional details with multiple messages
Note that an entity does not always need to request a Message #1400 Message
Acknowledgement, as an entity may use an expected response as an
acknowledgement. For instance, if a CUCS sends a Message #1200 Field
Configuration Request, to download a single configuration parameter, the receipt of
the requested configuration parameter in a Message #130x implies that the destination
entity received the request.
A3.1.4.1 Requesting an Acknowledgement
To request an acknowledgement, an entity needs to set the ACK bit in the Message
Properties field of the message header and set an Unique ID in the Message Instance
ID field.
Header
field
Name
Value
1
IDD Version
“12” (Edition 2.4)
2
Message Instance ID
<A unique ID that will be included in the ACK>
3
Message Type
<Message Type>
4
Message Length
<Message Length>
5
Stream ID
<Stream ID>
6
Message Properties
0x80000000 (note that the least significant 31
bits are undefined)
If the sending entity does not receive a Message #1400 Message Acknowledgement,
within a reasonable time frame, the entity may assume that the message was not
received at the destination. In this case, the entity can choose to resend the message
or timeout.
Note that a message will not be acknowledged if any of the following conditions exist,
since the entity cannot trust the integrity of the received message:
A3 - 41
Edition A Version 1
AEP-84.1
1. The message specifies an IDD version of STANAG 4586 that is not
supported by this entity
2. The message specifies an incorrect message length
3. The message has an incorrect checksum
An entity should use a Unique ID for each sent message unless it is a retry attempt of
a previously sent message. While entities could use a globally Unique ID for each
message, the ID only needs to be unique for a given Message Type. This is because
the responding entity is required to specify the Original Message Type (Unique ID
1400.08) in the acknowledgement.
A3.1.4.2 Sending an Acknowledgement
To acknowledge a message, the entity sends Message #1400:
Unique ID
Name
Value
1400.01
Time Stamp
Time of Message #1400 creation
1400.02
Vehicle ID
<Vehicle ID from the received Message>
1400.03
CUCS ID
<CUCS ID from the received Message>
1400.04
VSM ID
<VSM ID from received Message> or Null ID
1400.05
Data Link ID
<Data Link ID from received Message> or Null
ID
1400.06
Original Message Time
Stamp
<Timestamp from received Message>
1400.07
Original Message Instance
ID
<Instance ID from received Message>
1400.08
Original Message Type
<Message Type from received Message>
1400.09
Acknowledgement Type
<Acknowledgement Type as needed>
Note that some messages do not have a Data Link ID and/or a VSM ID (for example,
Message #49, Message #1500, Message #200, etc…). In these cases, the entity
should use the Null ID for these fields.
An entity may send multiple copies of the Acknowledgement Message at the same
time to increase the chances that one will be received at the destination. The receiving
entity should be able to receive multiple copies of the same acknowledgement without
unintended side effects.
There are five different types of acknowledgements that an entity can send:
Enumeration Name
Meaning
0
The message was received and no further
acknowledgement will be sent.
Message Received
A3 - 42
Edition A Version 1
AEP-84.1
This does not imply that the contents of the
message were correct or the data in the
message was used for its intended purpose. It
only indicates that the message was received
and that the sending entity does not need to
resend it.
1
Message Received, but
not completed
This is the same as 0=Message Received,
except that it indicates that a further
acknowledgement will be sent to indicate if
the received message was accepted and
completed, accepted and failed, or rejected.
This message can be useful for cases where
the entity requires additional time to decide
the outcome of the request. By sending this
message, the sending entity is informed that
the message was received so it doesn’t need
to re-send the message.
2
Message Received and
Completed
This indicates that the message was received
and the request was accepted and completed.
For instance, the UA can use this message to
indicate that it has received and accepted the
the new parameters when it receives Message
#41, Loiter Configuration.
3
Message Received, but
Rejected
This indicates that the message was received
4
Message Received, but
Not Carried out
and that the request was rejected. The entity
can send it to indicate that something was
wrong with the request. It could be because
there was an error encoding the message or
because the entity does not accept the
request. This may be because the data in the
request is not within the entity’s
configuration or because the entity is
temporarily unable to accept the request.
This indicates that the message was received
and the request was accepted but the entity
failed to carry out the request. For example,
if an entity requested to turn on the power to
an EO/IR payload but the payload failed to
turn on due to an electrical problem.
A3 - 43
Edition A Version 1
AEP-84.1
A3.1.5 Vehicle Control Modes
TBD
A3.1.5.1 Loiter Control
A3 - 44
Edition A Version 1
AEP-84.1
A3.1.5.2 Vector Vehicle Control
A3 - 45
Edition A Version 1
AEP-84.1
A3.1.5.3 Lights
A3 - 46
Edition A Version 1
AEP-84.1
A3.1.5.4 Engine
A3 - 47
Edition A Version 1
AEP-84.1
A3.1.5.5 Lost Link
A3.1.6 Payload Control
As defined by AEP-84 Volume I, a payload is one of the following:

UA sensor(s), weapons, chaff, pamphlets, on-board systems, etc. carried
on-board which are used to accomplish a specified mission.
As stated in AEP-84 Volume I:
The Payload and Vehicle subsystems have been developed to provide a set of
generic messages for common UA payloads, and for common UA subsystems.
A CUCS and/or VSM do not have to support the generic payload messages or
the vehicle subsystem messages that do not apply to the systems
configuration. However, if one of the generically identified payload or
subsystem messages is applicable for the UAS, the identified formatted DLI
messages shall be supported.
A3 - 48
Edition A Version 1
AEP-84.1
A set of generic Payload Types has been identified in the Payload Configuration
Message (Message #300). The generic DLI messages associated with each of the
payload types is identified in Table 4 – 6 (Conditional Payload Message Groups) of
AEP-84 Volume I
A3.1.6.1 Payload Configuration
The UA needs to inform the CUCS what its payload configuration is (i.e., which
payloads it has on board) by type and payload station. The UA uses Message #300
Payload Configuration to provide this information to a CUCS.
See also requirements DLI 0240, DLI 0393, DLI 0241, and DLI 0242 in AEP-84
Volume I which all pertain to payload configuration.
300
4
Payload Configuration
Push/Pull
VSM
Y
Y
-
A3.1.6.1.1 Payload Stations Available
Unique ID 0300.05 Payload Stations Available identifies to a CUCS the payload
stations on the UA which have a payload associated with them. A CUCS may see from
a UA that the least significant bits 1, 2, and 3 are all equal to 1, in which case the CUCS
has 3 stations associated with a payload, and those stations are 1, 2, and 3. This
information can be used to error check the number of stations which are reported by
Unique ID 0300.06.
A3 - 49
Edition A Version 1
1,000
AEP-84.1
0300.05
5
Payload Stations
Available
Unsigned
4
Bitmapped
0x00000001 = Stn #1
0x00000002 = Stn #2
0x00000004 = Stn #3
0x00000008 = Stn #4
0x00000010 = Stn #5
0x00000020 = Stn #6
0x00000040 = Stn #7
0x00000080 = Stn #8
0x00000100 = Stn #9
0x00000200 = Stn #10
0x00000400 = Stn #11
0x00000800 = Stn #12
0x00001000 = Stn #13
0x00002000 = Stn #14
0x00004000 = Stn #15
0x00008000 = Stn #16
0x00010000 = Stn #17
0x00020000 = Stn #18
0x00040000 = Stn #19
0x00080000 = Stn #20
0x00100000 = Stn #21
0x00200000 = Stn #22
0x00400000 = Stn #23
0x00800000 = Stn #24
0x01000000 = Stn #25
0x02000000 = Stn #26
0x04000000 = Stn #27
0x08000000 = Stn #28
0x10000000 = Stn #29
0x20000000 = Stn #30
0x40000000 = Stn #31
0x80000000 = Stn #32
A3.1.6.1.2 Station Number
The station number is a virtual identifier associated with a particular payload (or in
some cases, the UA).
The following field description is a representative station number field. It is bitmapped,
meaning that a message could be sent or received and be intended for multiple
stations, though this is rare in practice as one on-board payload tends not to be
performing the same actions as a second on-board payload. For command messages,
all stations for which the message identifies a station being commanded should be
under LOI 3 control. For status messages, all messages for which the message
identifies a station being statused should be under LOI 2 control.
A3 - 50
Edition A Version 1
AEP-84.1
0300.06
6
Station Number
Unsigned
4
Bitmapped
0x00000001 = Stn #1
0x00000002 = Stn #2
0x00000004 = Stn #3
0x00000008 = Stn #4
0x00000010 = Stn #5
0x00000020 = Stn #6
0x00000040 = Stn #7
0x00000080 = Stn #8
0x00000100 = Stn #9
0x00000200 = Stn #10
0x00000400 = Stn #11
0x00000800 = Stn #12
0x00001000 = Stn #13
0x00002000 = Stn #14
0x00004000 = Stn #15
0x00008000 = Stn #16
0x00010000 = Stn #17
0x00020000 = Stn #18
0x00040000 = Stn #19
0x00080000 = Stn #20
0x00100000 = Stn #21
0x00200000 = Stn #22
0x00400000 = Stn #23
0x00800000 = Stn #24
0x01000000 = Stn #25
0x02000000 = Stn #26
0x04000000 = Stn #27
0x08000000 = Stn #28
0x10000000 = Stn #29
0x20000000 = Stn #30
0x40000000 = Stn #31
0x80000000 = Stn #32
Unique ID 0300.06 Station Number is the data item which, when correlated to Unique
ID 0300.07 Payload Type, sets the station number of a particular type of sensor.
In command messages with a station number field, a CUCS should send those
command messages associated with a payload with the station that has previously
been identified as correlated by Unique IDs 0300.06 and 0300.07. Likewise, where a
status message carries a station number field, the UA should send only the appropriate
status messages. In other words, a developer should consider a station number being
sent or received, for which there are no such stations as identified in those Unique IDs,
as an error case, and treat the message accordingly.
A3.1.6.1.3 Payload Type
Unique ID 0300.07 Payload Type indicates the payload type associated with the station
number(s) populated in Unique ID 0300.06. This informs the CUCS which payload
messages the UA expects to be used to control, configure, and report the status of the
payload at the specified station. This permits a group of payload messages associated
with that payload type (as in Table 4 – 6 of AEP-84 Volume I to be used with any
payload, whether that payload is actually of the type specified or not. Example: A UA
carries a payload which requires EO control but which is not actually an EO payload
could report that on the particular station its assigned to this payload is an EO payload.
A3 - 51
Edition A Version 1
AEP-84.1
0300.07
7
Payload Type
Type ID associated
with deployable or
dispensable payloads
(e.g., chaff, weapons).
Unsigned
1
Enumerate
d
0 = Not Specified
1 = EO
2 = IR
3 = EO/IR
4 = SAR
5 = Fixed Camera
6 = Comms Relay
7 = Dispensable
Payload
8 = Recorder
9 = Payload Bay Door
10 = CBRN
11 = SMS
12 - 50 = Reserved
51 - 255 = VSM
Specific
Payload type is the only method to inform a CUCS the type of payload at a station, and
the CUCS should not assume prior knowledge of any station.
The UA can configure the enumerations in the field; in particular, it might want to
include some non-generic payload which cannot be controlled as another of the other
types of payloads. The UA should at a minimum resend Message #300 with the
enumeration(s) in question after the enumerations have been configured during the
configuration process.
A3.1.6.1.4 Station Door
Unique ID 0300.08 Station Door indicates whether the station(s) in Unique ID 0300.06
is associated with a station door. Messages #206 and #308 are used to control a
station identified as a payload bay door by Unique ID 0300.07 Payload Type = 9 =
Payload Bay Door (which would be sent in a separate Message #300). AEP-84 Volume
I does not provide messaging to inform the CUCS which payloads with station doors
are correlated to which station doors. Implementers needing to provide this information
can either use private messaging or by providing a correlation in the VSM.
0300.08
8
Station Door
Unsigned
1
Enumerated
0 = No
1 = Yes
A3.1.6.1.5 Number of Payload Recording Devices
Unique ID 0300.09 Number of Payload Recording Devices indicates how many
payload recording devices there are on-board a UA. This information can also be
conveyed by a UA providing the stations in Unique ID 0300.06 and their respective
assignment as recorders in 0300.07 = 8 = Recorder.
0300.09
9
Number of Payload
Recording Devices
Unsigned
1
None
No Restrictions
A3.1.6.1.6 Configuration Requirements
The following parameters are required to support configuration:

Message #200, Horizontal Slew Rate
A3 - 52
Edition A Version 1
AEP-84.1
 Message #200, Vertical Slew Rate
 Message #200, Altitude
 Message #200, Altitude Type
A3.1.6.2 EO/IR
An electro-optical/infrared (EO/IR) payload is used to get video payload products from
a UA. STANAG 4586 allows for control of EO/IR-specific parameters using Messages
#200, #201, #301, and #302. This section documents elements of control specific to
EO/IR payloads.
UA which need to use Messages #201 and #302 but which do not carry an EO sensor
should configure Unique IDs 0201.07 and 0302.07 out of a compliant CUCS. They
should additionally ignore those EO sensor command fields when they receive a
Message #201, and they should always send 0s in those EO sensor status fields. A
CUCS should have the reverse logic. These UA should also configure out the following
bits and enumerations of the following Unique IDs: 0201.05 0x01 bit and 0302.05 0x01
bit, 0201.09 enumerations 1 and 3, 0302.09 enumerations 1 and 3.
UA which need to use Messages #201 and #302 but which do not carry an IR sensor
should configure Unique IDs 0201.08 and 0302.08 out of a compliant CUCS. They
should additionally ignore those IR sensor command fields when they receive a
Message #201, and they should always send 0s in those IR sensor status fields. A
CUCS should have the reverse logic. These UA should also configure out the following
enumerations of the following Unique IDs: 0201.05 0x02 bit and 0302.05 0x02 bit,
0201.09 enumerations 2 and 3, 0302.09 enumerations 2 and 3.
A UA which does not carry an EO/IR/laser payload or a fixed camera, or a CUCS which
does not support an EO/IR laser payload or fixed camera, do not need to support
Messages #201, #301, or #302.
In addition, it’s recommended for a CUCS to provide for controllability of the majority
of the fields and enumerations in Messages #200 and #201 via support for Message
#1303. This enables a UA to provide information on what the CUCS should be able to
change at any given time.
A3.1.6.2.1 Configuration Requirements
The following parameters are required to support configuration (see DLI Requirement
IDs 0303, 0308, and 0317; 0389 also):








Message #200, Set Horizontal Field of View
Message #200, Set Vertical Field of View
Message #302, Reported Range
Message #200, Set Focus
Message #201, System Operating Mode
Message #201, Set EO Sensor Mode
Message #201, Set IR Polarity
Message #201, Set EO/IR Pointing Mode
A3 - 53
Edition A Version 1
AEP-84.1
201
31
301
23
302
50
EO/IR/Laser Payload
Command
EO/IR - Configuration
State
EO/IR/Laser Operating
State
Push
CUCS
-
Y
-
1,000
Pull
VSM
Y
Y
-
200
Push/Pull
VSM
Y
Y
-
2,000
A3.1.6.2.2 EO/IR Configuration State
The UA provides additional configuration information beyond Messages #130x and the
#301 to the CUCS in the form of the EO/IR Configuration State. The message used to
carry this information is Message #301.
A3.1.6.2.2.1 EO/IR Type and Type Revision Level
Unique IDs 0301.06 EO/IR Type and 0301.07 EO/IR Type Revision Level provide
information regarding the model of EO/IR payload which is being carried by the UA.
This information could be used to design a CUCS around a particular EO/IR payload,
though this is not recommended.
0301.06
6
EO/IR Type
Type is identified
using NATO stock
numbers, which are
13-digit numerical
values conforming
with the NATO
Codification System
as defined in
STANAGs 3150 and
3151 which define the
structure for these
values.
Character
14
None
No Restrictions
0301.07
7
EO/IR Type Revision
Level
Number identifying
modification level of
the type specified in
EO/IR Type Field.
Unsigned
1
None
No Restrictions
A3.1.6.2.2.2 Image Dimensions
0301.08
8
EO Vertical Image
Dimension
Number of pixel rows,
where 0 = Off.
Integer 2
None
0≤x
0301.09
9
EO Horizontal Image
Dimension
Number of pixel
columns, where 0 =
Off.
Integer 2
None
0≤x
A3 - 54
Edition A Version 1
AEP-84.1
0301.10
10
IR Vertical Image
Dimension
Number of pixel rows,
where 0 = Off.
Integer 2
None
0≤x
0301.11
11
IR Horizontal Image
Dimension
Number of pixel
columns, where 0 =
Off.
Integer 2
None
0≤x
Unique IDs 0301.08 EO Vertical Image Dimension, 0301.09 EO Horizontal Image
Dimension, 0301.10 IR Vertical Image Dimension, and 0301.11 IR Horizontal Image
Dimension provide the dimensions of the current payload video, in number of pixels,
to the CUCS. The size of the video should accurately reflect Unique ID 0302.09 Image
Output State:


For Unique ID 0302.09 = 0 = None, the image dimensions should all be 0.
For Unique ID 0302.09 = 1 = EO, the EO dimensions should reflect the size of
the EO image output; the IR dimensions should be 0.
 For Unique ID 0302.09 = 2 = IR, the IR dimensions should reflect the size of
the IR image output; the EO dimensions should be 0.
 For Unique ID 0302.09 = 3 = Both, the image dimensions should reflect the
size of the image output for both the EO and IR streams respectively.
A3.1.6.2.2.3 Field of Regard Minimums and Maximums
Unique IDs 0301.12 Field of Regard – Elevation Min, 0301.13 Field of Regard –
Elevation Max, 0301.14 Field of Regard – Azimuth Min, and 0301.15 Field of Regard
– Azimuth Max provide the maximum dimensions of the payload’s field of view with
respect to the UA to the CUCS. This information should be used by the CUCS to
prevent sending any steering commands using Message #200 regardless of the
payload’s operating mode which fall outside of the payload’s possible field of regard.
0301.12
12
Field of Regard Elevation Min
Minimum payload
centre field of view wrt
UA, using payload
gimbal if present.
Positive value is
above the surface
defined by the UA
lateral/longitudinal
plane.
Float
rad
-π ≤ x ≤ π
A3 - 55
Edition A Version 1
AEP-84.1
0301.13
13
Field of Regard Elevation Max
Maximum payload
centre field of view wrt
UA, using payload
gimbal if present.
Positive value is
above the surface
defined by the UA
lateral/longitudinal
plane.
Float
rad
-π ≤ x ≤ π
0301.14
14
Field of Regard Azimuth Min
Minimum payload
centre field of view wrt
UA, using payload
gimbal if present.
Positive value is
clockwise as viewed
from above relative to
the nose of the UA.
Float
rad
-π ≤ x ≤ π
0301.15
15
Field of Regard Azimuth Max
Maximum payload
centre field of view wrt
UA, using payload
gimbal if present.
Positive value is
clockwise as viewed
from above relative to
the nose of the UA.
Float
rad
-π ≤ x ≤ π
A3.1.6.2.3 Addressed Sensor
Unique IDs 0201.05 Addressed Sensor and 0302.05 Addressed Sensor mediate the
sensor under control, where an EO/IR payload station has multiple sensors that can
be used separately. Where a payload is EO according to Unique ID 0300.07, this field
should always equal 0x01 = EO; similarly for IR and 0x02 = IR. In all other cases,
including the mixed payload and payload-specific cases, without operator interaction,
it cannot be determined when a particular sensor should be used.
There are some fields in Message #200 Payload Steering Command which are
dependent on this field being correctly set. See also Section A3.1.6.7 Payload Steering
for more information.
A3 - 56
Edition A Version 1
AEP-84.1
0201.05
5
Addressed Sensor
Unsigned
Identifies which sensor 1
(s) to control where
applicable.
Laser pointers and
rangefinders
integrated with an
EO/IR sensor are not
considered a separate
sensor.
Bitmapped
0x01 = EO
0x02 = IR
0x04 = Payload Specific
0302.05
5
Addressed Sensor
Identifies which
sensor(s) is under
control where
applicable.
Bitmapped
0x01 = EO
0x02 = IR
0x04 = PayloadSpecific
Unsigned
1
A3.1.6.2.3.1 EO Sensor Mode
Unique IDs 0201.07 Set EO Sensor Mode and 0302.07 EO Sensor Mode Status
mediate the color that the video will return with from an EO/IR sensor. Commanding
BW mode will direct the UA to return black and white imagery, whereas commanding
colour mode will direct the UA to return colored imagery.
UA which need to use Messages #201 or #302 but which cannot permit selection of
the EO imagery color should configure the enumeration which they cannot support out
of a compliant CUCS.
Unique ID 0201.07 enumeration 0 = BW Mode matches Unique ID 0302.07
enumeration 0 = BW Mode; similarly for enumerations 1 and 1.
0201.07
7
Set EO Sensor Mode
Unsigned
1
Enumerated
0 = BW Mode
1 = Colour Mode
0302.07
7
EO Sensor Mode
Status
Unsigned
1
Enumerated
0 = BW Mode
1 = Colour Mode
A3.1.6.2.3.2 IR Polarity
Unique IDs 0201.08 Set IR Polarity and 0302.08 IR Polarity Status mediate the polarity
of the IR camera. IR polarity herein is defined as the color for which an IR sensor will
represent temperatures. “Black Hot” means that the IR sensor will produce imagery
where the color black represents high temperature and where the color white
represents low temperature (represented on the infrared spectrum). Gray scale
imagery will be produced per the IR sensor’s design specifications between whatever
the manufacturer has designated as the “upper end” of the “hot” spectrum. “White Hot”
represents the opposite.
UA which need to use Messages #201 or #302 but which cannot permit selection of
the IR polarity should configure the enumeration which they cannot support out of a
compliant CUCS. Alternatively, they can configure the entire field which they cannot
support out of a compliant CUCS.
Unique ID 0201.07 enumeration 0 = BW Mode matches 0302.07 enumeration 0 = BW
Mode; similarly for enumerations 1 and 1.
A3 - 57
Edition A Version 1
AEP-84.1
0201.08
8
Set IR Polarity
Unsigned
1
Enumerated
0 = Black Hot
1 = White Hot
0302.08
8
IR Polarity Status
Unsigned
1
Enumerated
0 = Black Hot
1 = White Hot
A3.1.6.2.3.3 Image Output
Unique IDs 0201.09 Image Output and 0302.09 Image Output State mediate the type
of video which the UA will be sending. None indicates that the UA should not send
video. EO indicates electro-optical video only. IR indicates infrared video only. Both
indicates a fused stream of both EO and IR data.
UA which need to use Messages #201 or #302 but which cannot permit selection of
the image output, configure the enumerations which they cannot support out of a
compliant CUCS. Alternatively, they can configure the entire field which they cannot
support out of a compliant CUCS.
Systems which have an image output state not enumerated in items 0 through 3 can
elect to configure in a single payload-specific image output state. This might be useful
for example with a multispectral payload, or a mode which provides some functionality
of one of the other enumerations plus some additional functionality.
Unique ID 0201.09 enumeration 0 = None matches Unique ID 0302.09 enumeration 0
= None; similarly for enumerations 1 through 3 and 1 through 3, respectively.
0201.09
9
Image Output
Unsigned
1
Enumerated
0 = None
1 = EO
2 = IR
3 = Both
4 = Payload-Specific
0302.09
9
Image Output State
Unsigned
1
Enumerated
0 = None
1 = EO
2 = IR
3 = Both
4 = Payload-Specific
A3.1.6.2.3.4 Preplan Mode
Unique IDs 0201.15 and 0302.20 mediate the mode of operation for the EO/IR payload
relative to the mission uploaded to the UA. An enumeration of 0 indicates that the
EO/IR payload should operate according to the set of Message #804s uploaded as
part of the mission. An enumeration of 1 indicates that the EO/IR payload should act
on the most recent Message #200 and #201 that it has received, for fields which are
also controlled in Message #804.
0201.15
16
Preplan Mode
Unsigned
1
Enumerated
0 = Operate in
Preplanned Mode
1 = Operate in
Manual Mode
A3 - 58
Edition A Version 1
AEP-84.1
0302.20
20
Preplan Mode
Unsigned
1
Enumerated
0 = Operate in
Preplanned Mode
1 = Operate in
Manual Mode
See the following Table for the comparison between Message #804 and Messages
#201 and #200.
Unique
ID
0804.06
Data Item
Unique
ID
0201.05
= 0x01
0201.06
0804.07
Set Sensor 2 Mode
0201.05
= 0x02
0201.06
0804.08
0804.09
Sensor Output
Set Sensor Pointing Mode
0201.06
0201.10
0804.10
0804.11
0804.12
0804.13
0804.14
Starepoint Latitude
Starepoint Longitude
Starepoint Altitude
Starepoint Altitude Type
Payload Az (wrt UA)
0200.11
0200.12
0200.13
0200.14
0200.05
0804.15
Payload El (wrt UA)
0200.06
0804.16
Payload Sensor Rotation
Angle
0302.14
Set Sensor 1 Mode
Data Item
Addressed Sensor =
EO
System Operating
Mode
Addressed Sensor =
IR
System Operating
Mode
Image Output
Set EO/IR Pointing
Mode
Latitude
Longitude
Altitude
Altitude Type
Set Centreline Azimuth
Angle
Set Centreline
Elevation Angle
Actual Sensor Rotation
Angle
Given that some of these data items are not immediately obvious to be the same (e.g.,
Unique IDs 804.06-804.09), this would require some assumptions by a CUCS-VSM
pair about the meanings of the enumerations in Message #804.
A data item in Message #200 or #201 could not be identified to match with Unique ID
0804.16 Payload Sensor Rotation Angle. The most similar data item is actually in
Message #302, Unique ID 0302.14 Actual Sensor Rotation Angle. Like with the
enumerated data items, the fields’ ranges differ; Message #804’s Sensor Rotation
Angle is from -π/2 ≤ x ≤ π/2 while Message #302’s is from –π ≤ x ≤ π.
A3 - 59
Edition A Version 1
AEP-84.1
A3.1.6.2.3.5 System Operating Mode
0201.06
6
System Operating
Mode
Unsigned
1
Enumerated
0 = Stow
1 = Off
2 = Cage
3 = Initialise
4 = Standby
5 = Active
6 = Calibrate
7 - 9 = Reserved
10 - 255 = Payload Specific
0302.06
6
System Operating
Mode State
Unsigned
1
Enumerated
0 = Stowed
1 = Off
2 = Caged
3 = Initialising
4 = Standby
5 = Active
6 = Calibrating
7 - 9 = Reserved
10 - 255 = PayloadSpecific
Unique IDs 0201.06 System Operating Mode and 0302.06 System Operating Mode
State mediate the operating mode of the EO/IR payload.
Unique IDs 0201.06 enumeration 0 = Stow matches 0302.06 enumeration 0 = Stowed;
similarly for enumerations 1-6 and 1-6 respectively. Enumerations 7-9 = Reserved in
both command status should never be used. Enumerations 10-255 = Payload-Specific
may be configured using the standard configuration process.







0 = Stow/Stowed: Indicates to the UA that it should stow the payload within the
UA.
1 = Off/Off: Indicates to the UA that it should turn the payload off.
2 = Cage/Caged: Indicates to the UA that the payload should steer itself to a
stationary, pre-defined position. The pre-defined position is vehicle-specific.
3 = Initialise/Initialising: Indicates to the UA that the payload should begin
turning on. When the payload is done initializing, it should probably report
standby. A CUCS could then automatically send a standby command to match
the standby status.
4 = Standby/Standby: This enumeration indicates to the UA that the payload
should wait for another command and basically means “the payload should be
on”. The payload can be oriented to some pre-defined location or it can be
loose in its gimbals; pre-defined is probably preferred for HMI reasons.
5 = Active/Active: This enumeration indicates to the UA that the CUCS is
sending it payload steering commands as well as a non-0 pointing mode in
Unique ID 0201.10 Set EO/IR Pointing Mode. The UA must also correctly report
the pointing mode which it was last commanded to be in. See also Section
A3.1.6.7 Payload Steering.
6 = Calibrate/Calibrating: This enumeration indicates to the UA that it should
calibrate its EO/IR payload. This may be an internal or external calibration, and
A3 - 60
Edition A Version 1
AEP-84.1
may apply to a part or the whole of the payload. When the payload is done
calibrating, it should probably report standby. A CUCS could then automatically
send a standby command to match the standby status.
A3.1.6.3 Synthetic-Aperture Radar (SAR)
Synthetic Aperture Radar (SAR) is a form of radar which is used to create images of
an object, such as a landscape. These images can be 2D or 3D representations of
the object. SAR uses the motion of the SAR antenna over a target region to provide
finer spatial resolution than is possible with conventional beam-scanning radars. SAR
is typically mounted on a moving platform such as an aircraft or spacecraft, and it
originated as an advanced form of side-looking airborne radar. Environmental
monitoring, earth-resource mapping, and military systems require broad-area imaging
at high resolutions. Often this imagery must be acquired at night or during inclement
weather. SAR provides such a capability.
Within STANAG 4586, the Message #202 is used to uplink SAR commands from the
CUCS to the UA/VSM and Message #303 is used to downlink SAR responses or status
updates from the UA/VSM to the CUCS.
A3.1.6.3.1 SAR Payload Steering
The control over the SAR payload type’s pointing angles and FOV are conducted from
the Payload Steering Command Message (Message #200). For additional information
see Section A3.1.6.7 Payload Steering.
A3.1.6.3.2
Message #202: SAR Payload Command
The SAR Payload Command Message is used by the CUCS to execute control over a
SAR payload located at the specified UA station, with the exception of pointing and
FOV commands.
The Set Radar State, Set Moving Target Indicator (MTI) mode, Set Radar Mode and
Set Resolution are commanded from this message. It is the responsibility of the
UA/VSM to correctly convert the commands to the correct payload format and transmit
them to the specified payload on board the UA.
0202.05
5
Set Radar State
Unsigned
1
Enumerated
0 = Turn Off
1 = Turn On
2 = Go To Standby
3 = Deploy
4 = Activate
5 = Deactivate
6 = Stow
7 - 9 = Reserved
10 - 255 = PayloadSpecific
A3 - 61
Edition A Version 1
AEP-84.1
0202.06
6
Set MTI Radar Mode
Unsigned
1
Enumerated
1 = Clutter Map
2 = Moving Target
3 - 9 = Reserved
10 - 255 = PayloadSpecific
0202.07
7
Set SAR Modes
Per the NSIF Registry,
AEDP-4, Annex D.
See message #303,
field 7 for details).
0202.08
8
Set Radar Resolution
Character
6
None
No Restrictions
Integer 2
cm
0 ≤ x ≤ 10,000
0 = Unknown
A3.1.6.3.3 Message #303: SAR Operating State
The intent of the SAR Operating State Message is for the UA/VSM to provide the status
of the SAR payload to the CUCS, if one is present on the UA. The CUCS must support
the reception of this message if the CUCS supports a “SAR” payload type.
The Station Number field in the message identifies the location of the payload on the
UA, and it must have been identified to the CUCS using the Payload Configuration
Message (Message #300).
A UA/VSM is required to support this message if it supports a SAR payload.
The UA/VSM is responsible to send the correct state, and not allow invalid states for
the selected payload control mode.
0303.05
5
SAR Type
Type is identified
using NATO stock
numbers, which are
13-digit numerical
values as of date of
publication.
0303.06
6
SAR Type Revision
Level
Character
14
None
No Restrictions
Unsigned
1
Enumerated
0 - 255 = Revision
Level
Number identifying
modification level of
the type specified in
the SAR Type Field.
A3 - 62
Edition A Version 1
AEP-84.1
0303.07
7
Radar Operating
Mode
Character
5
None
No Restrictions
Unsigned
1
Enumerated
0 = Powered Off
Reference: NSIF
Registry, AEDP-4,
Annex-D
0303.08
8
Radar Operating
Status
1 = Powered On
2 = Standby
3 = Deployed
4 = Activated
5 = Deactivated
6 = Stowed
7 - 9 = Reserved
10 - 255 = PayloadSpecific
0303.09
9
Radar MTI Mode
Status
Unsigned
1
Enumerated
1 = Clutter map
2 = Moving target
3 - 9 = Reserved
10 - 255 = PayloadSpecific
0303.10
10
Resolution
Float
m
0 ≤ x ≤ 100 (0 =
unknown)
Float
rad
-π ≤ x ≤ π
Float
rad
-π ≤ x ≤ π
Float
rad
-π ≤ x ≤ π
Current pixel
resolution of SAR
product.
0303.11
11
Current Field of View Elevation Min
(above body x axis)
0303.12
12
Current Field of View Elevation Max
(above body x axis)
0303.13
13
Current Field of View Azimuth Min
right of body x axis
A3 - 63
Edition A Version 1
AEP-84.1
0303.14
14
Current Field of View Azimuth Max
Float
rad
-π ≤ x ≤ π
right of body x axis
A3.1.6.4 CBRN Payload
A3.1.6.4.1 CBRN Payload Classes
The CBRN messages in STANAG 4586 support the following classes of CBRN
payloads:


Point payloads
Standoff payloads
A3.1.6.4.1.1 CBRN Point Payloads
Most CBRN payloads are typically point payloads. CBRN point payloads are a
subclass of CBRN payloads characterized by the ability to detect threats at the location
(i.e., the point) where the payload is currently deployed.
CBRN point payloads are different from CBRN standoff payloads in a couple of ways:
 That they normally would not implement the Payload Scan Window
Configuration Command (Message #213) or the Payload Scan Window
Operating State (Message #312).
 That when threat detection occurs, then the threat is typically a point detection
that matches the location of the payload. Therefore fields Detection Latitude
(Unique ID 0309.18), Detection Longitude (Unique ID 0309.19) and Detection
Altitude (Unique ID 0309.20) are equal to Payload Latitude (Unique ID
0311.12), Payload Longitude (Unique ID 0311.13) and Payload Altitude
(Unique ID 0311.14).
A3.1.6.4.1.2 CBRN Standoff Payloads
CBRN Standoff payloads are a subclass of CBRN payloads characterized by the ability
to detect threats from a distance. They typically employ a scanning beam (laser,
infrared, etc.) that scans for the threat. Payloads operating individually may have the
ability to detect the area where the threat is or an exact location for the threat
depending on the payload capability. In other cases, some payloads have the ability to
operate as a group to help “triangulate” together a cloud that constitutes the threat.
CBRN standoff payloads are different from typical CBRN payloads (i.e., point
detectors) in a couple of ways:
 That they would implement the Payload Scan Window Configuration Command
(Message #213) and the Payload Scan Window Operating State (Message
#312) to define the payload’s scanning window. See Section A3.1.6.4.4.1
Scanning manually using Payload Scan Window Configuration Command
(Message #213).
A3 - 64
Edition A Version 1
AEP-84.1

That when a threat detection occurs, then the threat can be either a point
detection (at a distance from the payload, see : Standoff Detection of a Point
Threat) or a cloud detection (see : Standoff Detection of a Cloud Threat).
Detection Latitude (Unique ID 0309.18),
Detection Longitude (Unique ID 0309.19) and
Detection Altitude (Unique ID 0309.20)
Payload Latitude (Unique ID 0311.12),
Payload Longitude (Unique ID 0311.13) and
Payload Altitude (Unique ID 0311.14)
Sensor
Figure A3 - 8: Standoff Detection of a Point Threat
Left Radial Line (Unique ID 0309.14)
Right Radial Line (Unique ID 0309.15)
Distance To Cloud (Unique ID 0309.13)
Sensor
Payload Latitude (Unique ID 0311.12),
Payload Longitude (Unique ID 0311.13) and
Payload Altitude (Unique ID 0311.14)
Figure A3 - 9: Standoff Detection of a Cloud Threat
A3.1.6.4.2 CBRN Payload Data and Products
CBRN payloads will use message CBRN Detection (Message #309) to report the
detection state of the payload. This message is used to report when there is a threat
detected (i.e., above threshold or above threshold update) as well as when there is
nothing abnormal detected (i.e., below threshold or NIL1) which is indicated in field
Detection Type (Unique ID 0309.06).
Any given detection state is composed of the following key elements:


What: Which agent/substance was detected? Reported in field Substance
Detected (Unique ID 0309.07)
How Much: What is the contamination level? Reported in:
NIL is a special case of “below threshold”. It is the point at which the payload indicates that it no longer detects the
threat that it has previously detected.
1
A3 - 65
Edition A Version 1
AEP-84.1
o


Field Contamination Level and Contamination Level UoM (Unique IDs
0309.08 and 0309.09). These fields represent an actual contamination
value and unit of measurement (respectively). For example: 1.234
MGM3. These fields are the basic minimum information that should be
reported by any CBRN payload.
o Field Contamination Severity Level (Unique ID 0309.12). This is an
abstract value that maps to the Contamination Level and is used by
payload’s that are capable of multi substance detection to facilitate the
setting of warning and caution thresholds for those substances so that
an operator can take appropriate action, for example: 3 bars on the
display of the payload. This field may not be relevant to some payloads
and therefore the payload may configure this field out.
When: The detection occurred when? Reported in field Detection Timestamp
(Unique ID 0309.10)
Where: The detection/measurement occurred where?
o For point payloads: Reported in field Detection Latitude, Detection
Latitude and Detection Altitude (Unique IDs 0309.18, 0309.19, and
0309.20). Typically cloud related fields (Unique IDs 0309.13 to 0309.17)
will be configured out by point detectors.
o For standoff payloads: Depending on the payload capability or its
current working configuration with other standoff payloads, it may
provide either
 Detection Latitude, Detection Latitude and Detection Altitude
(Unique IDs 0309.18, 0309.19, and 0309.20), see : Standoff
Detection of a Point Threat; or
 Cloud related fields (Unique ID 0309.13 to 0309.17), see :
Standoff Detection of a Cloud Threat.
A3.1.6.4.2.1 Example of the Lifecycle of a Detection
Note that different payloads will have different characteristics that determine which
fields are configured out, when they go in and out of a CBRN alarm state, etc. These
characteristics can also be dictated by national requirements. As such this example is
only provided to illustrate one of many ways that a CBRN payload may behave.
This example will assume a chemical point detector that samples the air against a
specific library of chemicals. This example will also assume that Contamination
Severity Level (Unique ID 0309.12) is supported in addition to Contamination Level
(Unique ID 0309.08). Also for this example, we will assume that the field Contamination
Severity Level (Unique ID 0309.12) is the field used for visual warnings rather than
Contamination Level (Unique ID 0309.08), for more information see Section
A3.1.6.4.3.7 Relationship between Contamination Level, Contamination Severity and
Detection Type.
Typically this payload will normally report no detection. Visually on a dashboard this
can be represented with a green light and zero “bars” for the field Contamination
Severity. For more information on how to configure alert zones see Section
A3.1.6.4.3.5 Alert Zones for CBRN Related Fields.
A3 - 66
Edition A Version 1
AEP-84.1
Unique
ID
Name
Value
0309.02
Vehicle ID
<Vehicle ID>
0309.03
CUCS ID
<broadcast CUCS ID>
0309.04
VSM ID
<VSM ID> (if applicable)
0309.05
Station number
<station number of the reporting payload>
0309.06
Detection Type
0 = Below Threshold
0309.07
Substance Detected
Null
0309.08
Contamination Level
0
0309.09
Contamination Level
UoM
MGM3
0309.12
Contamination Severity
Level
0
0309.10
Detection Timestamp
<current>
0309.11
CBRN4 Report
Reference
0
..
cloud related fields
(Unique IDs 0309.13 to
0309.17) are configured
out
0309.18
Detection Latitude
<payload latitude at time of detection>
0309.19
Detection Longitude
<payload longitude at time of detection>
0309.20
Detection Altitude
<payload altitude at time of detection>
At some point it might detect something but it is still below threshold. Visually on a
dashboard this can be represented with a yellow light and appropriate number of “bars”
for the field Contamination Severity. For more information on how to configure alert
zones see Section A3.1.6.4.3.5 Alert Zones for CBRN Related Fields.
A3 - 67
Edition A Version 1
AEP-84.1
Unique
ID
Name
Value
0309.02
Vehicle ID
<Vehicle ID>
0309.03
CUCS ID
<broadcast CUCS ID>
0309.04
VSM ID
<VSM ID> (if applicable)
0309.05
Station number
<station number of the reporting payload>
0309.06
Detection Type
0 = Below Threshold
0309.07
Substance Detected
L
0309.08
Contamination Level
0.196
0309.09
Contamination Level
UoM
MGM3
0309.12
Contamination Severity
Level
2
0309.10
Detection Timestamp
<detection timestamp>
0309.11
CBRN4 Report
Reference
0
..
cloud related fields
(Unique IDs 0309.13 to
0309.17) are configured
out
0309.18
Detection Latitude
<payload latitude at time of detection>
0309.19
Detection Longitude
<payload longitude at time of detection>
0309.20
Detection Altitude
<payload altitude at time of detection>
The payload then detects enough of the chemical to trigger an above threshold alarm.
Visually on a dashboard this can be represented with a red light and appropriate
number of “bars” for the field Contamination Severity. For more information on how to
configure alert zones see Section A3.1.6.4.3.5 Alert Zones for CBRN Related Fields.
A3 - 68
Edition A Version 1
AEP-84.1
Note that a CBRN4 product is now available and a reference is provided in Unique ID
0309.11. This reference can be for a Generic Product Transport (GPT) message ID.
GPT is a protocol that allows for guaranteed file transfer over UDP and is used here
since a CBRN4 is a file based product. For more information about GPT please refer
to the AEP-84 Volume I.
A CBRN4 is an APP-11 message in accordance with NATO’s Warning and Reporting
procedures as per ATP-45. CBRN4 is used to report basic sensor measurements. The
CBRN4 is intended to be passed on by the CCI to the C4I systems.
Unique
ID
Name
Value
0309.02
Vehicle ID
<Vehicle ID>
0309.03
CUCS ID
<broadcast CUCS ID>
0309.04
VSM ID
<VSM ID> (if applicable)
0309.05
Station number
<station number of the reporting payload>
0309.06
Detection Type
1 = AboveThreshold
0309.07
Substance Detected
L
0309.08
Contamination Level
0.280
0309.09
Contamination Level
UoM
MGM3
0309.12
Contamination Severity
Level
3
0309.10
Detection Timestamp
<detection timestamp>
0309.11
CBRN4 Report
Reference
12345
..
cloud related fields
(Unique IDs 0309.13 to
0309.17) are configured
out
0309.18
Detection Latitude
<payload latitude at time of detection>
0309.19
Detection Longitude
<payload longitude at time of detection>
A3 - 69
Edition A Version 1
AEP-84.1
0309.20
Detection Altitude
<payload altitude at time of detection>
Continuing with the example, the payload detects an increase in the chemical
detection. Visually on a dashboard this can be represented with a red light and
appropriate number of “bars” for the field Contamination Severity. For more information
on how to configure alert zones see Section A3.1.6.4.3.5 Alert Zones for CBRN
Related Fields.
With every update, it is recommended that the payload send an updated CBRN4 until
a NIL state is reached.
Unique
ID
Name
Value
0309.02
Vehicle ID
<Vehicle ID>
0309.03
CUCS ID
<broadcast CUCS ID>
0309.04
VSM ID
<VSM ID> (if applicable)
0309.05
Station number
<station number of the reporting payload>
0309.06
Detection Type
2 = AboveThreshold Update
0309.07
Substance Detected
L
0309.08
Contamination Level
8.213
0309.09
Contamination Level
UoM
MGM3
0309.12
Contamination Severity
Level
5
0309.10
Detection Timestamp
<detection timestamp>
0309.11
CBRN4 Report
Reference
12346
..
cloud related fields
(Unique IDs 0309.13 to
0309.17) are configured
out
0309.18
Detection Latitude
<payload latitude at time of detection>
A3 - 70
Edition A Version 1
AEP-84.1
0309.19
Detection Longitude
<payload longitude at time of detection>
0309.20
Detection Altitude
<payload altitude at time of detection>
Then the payload detects a decrease in the chemical. The detection is still above
threshold. Visually on a dashboard this can be represented with a red light and
appropriate number of “bars” for the field Contamination Severity. For more information
on how to configure alert zones see Section A3.1.6.4.3.5 Alert Zones for CBRN
Related Fields.
With every update, it is recommended that the payload send an updated CBRN4 until
a NIL state is reached.
Unique
ID
Name
Value
0309.02
Vehicle ID
<Vehicle ID>
0309.03
CUCS ID
<broadcast CUCS ID>
0309.04
VSM ID
<VSM ID> (if applicable)
0309.05
Station number
<station number of the reporting payload>
0309.06
Detection Type
2 = Above Threshold Update
0309.07
Substance Detected
L
0309.08
Contamination Level
0.219
0309.09
Contamination Level
UoM
MGM3
0309.12
Contamination Severity
Level
3
0309.10
Detection Timestamp
<detection timestamp>
0309.11
CBRN4 Report
Reference
12347
..
cloud related fields
(Unique IDs 0309.13 to
0309.17) are configured
out
A3 - 71
Edition A Version 1
AEP-84.1
0309.18
Detection Latitude
<payload latitude at time of detection>
0309.19
Detection Longitude
<payload longitude at time of detection>
0309.20
Detection Altitude
<payload altitude at time of detection>
The payload continues to detect a decrease in the chemical. The detection is now
below threshold but it is recommended that the payload continues to send an updated
CBRN4 until a NIL state is reached (compare with the beginning of this example).
Visually on a dashboard this can be represented with a yellow light and appropriate
number of “bars” for the field Contamination Severity. For more information on how to
configure alert zones see Section A3.1.6.4.3.5 Alert Zones for CBRN Related Fields.
Unique
ID
Name
Value
0309.02
Vehicle ID
<Vehicle ID>
0309.03
CUCS ID
<broadcast CUCS ID>
0309.04
VSM ID
<VSM ID> (if applicable)
0309.05
Station number
<station number of the reporting payload>
0309.06
Detection Type
0 = Below Threshold
0309.07
Substance Detected
L
0309.08
Contamination Level
0.070
0309.09
Contamination Level
UoM
MGM3
0309.12
Contamination Severity
Level
1
0309.10
Detection Timestamp
<detection timestamp>
0309.11
CBRN4 Report
Reference
12348
..
cloud related fields
(Unique IDs 0309.13 to
0309.17) are configured
out
A3 - 72
Edition A Version 1
AEP-84.1
0309.18
Detection Latitude
<payload latitude at time of detection>
0309.19
Detection Longitude
<payload longitude at time of detection>
0309.20
Detection Altitude
<payload altitude at time of detection>
Finally the payload reaches its NIL state which for this particular payload is when the
detection is back to zero again. A special NIL CBRN4 is generated and sent and can
be used for reach-back and forensic purposes.
Visually on a dashboard this can be represented with a green light and appropriate
number of “bars” for the field Contamination Severity. For more information on how to
configure alert zones see Section A3.1.6.4.3.5 Alert Zones for CBRN Related Fields.
Unique
ID
Name
Value
0309.02
Vehicle ID
<Vehicle ID>
0309.03
CUCS ID
<broadcast CUCS ID>
0309.04
VSM ID
<VSM ID> (if applicable)
0309.05
Station number
<station number of the reporting payload>
0309.06
Detection Type
3 = NIL
0309.07
Substance Detected
L
0309.08
Contamination Level
0
0309.09
Contamination Level
UoM
MGM3
0309.12
Contamination Severity
Level
0
0309.10
Detection Timestamp
<detection timestamp>
0309.11
CBRN4 Report
Reference
12349
..
cloud related fields
(Unique IDs 0309.13 to
A3 - 73
Edition A Version 1
AEP-84.1
0309.17) are configured
out
0309.18
Detection Latitude
<payload latitude at time of detection>
0309.19
Detection Longitude
<payload longitude at time of detection>
0309.20
Detection Altitude
<payload altitude at time of detection>
Then the payload is back to reporting no detection. Visually on a dashboard this can
be represented with a green light and zero “bars” for the field Contamination Severity.
For more information on how to configure alert zones see Section A3.1.6.4.3.5 Alert
Zones for CBRN Related Fields.
Unique
ID
Name
Value
0309.02
Vehicle ID
<Vehicle ID>
0309.03
CUCS ID
<broadcast CUCS ID>
0309.04
VSM ID
<VSM ID> (if applicable)
0309.05
Station number
<station number of the reporting payload>
0309.06
Detection Type
0 = Below Threshold
0309.07
Substance Detected
Null
0309.08
Contamination Level
0
0309.09
Contamination Level
UoM
MGM3
0309.12
Contamination Severity
Level
0
0309.10
Detection Timestamp
<current>
0309.11
CBRN4 Report
Reference
0
..
cloud related fields
(Unique IDs 0309.13 to
A3 - 74
Edition A Version 1
AEP-84.1
0309.17) are configured
out
0309.18
Detection Latitude
<payload latitude at time of detection>
0309.19
Detection Longitude
<payload longitude at time of detection>
0309.20
Detection Altitude
<payload altitude at time of detection>
The CUCS can visualize the information it receives in different ways, the example
below is a different view that employs a trend graph where each red dot represents the
receipt of a CBRN4, see Figure A3 - 10: Example CBRN Detection Trend Graph.
Figure A3 - 10: Example CBRN Detection Trend Graph
A3.1.6.4.2.2 What about More Detailed CBRN Data?
Although a CBRN4 is an important requirement for NATO’s Warning and Reporting
procedures and is used operationally, it is not sufficient for all CBRN users. The reachback community, typically scientists, requires more data than what is provided in
Message #309 and the CBRN4.
Detailed CBRN measurements, such as spectra, are captured using other standards.
For the RAD/NUC domain the appropriate standard is the American National Standard
Data format standard for radiation detectors used for homeland security (ANSI
N42.42). Unfortunately, at the moment there is a gap in capturing detailed
measurements for the CHEM/BIO domain, however, the relevant NATO bodies are
aware of the gap and are looking at closing this gap sometime in the future.
A3.1.6.4.2.2.1 How to Implement Detailed CBRN Measurements?
ANSI N42.42 is an XML file based standard and it is expected that a CHEM/BIO
standard would follow suite. Unlike video, CBRN detailed measurements are not
A3 - 75
Edition A Version 1
AEP-84.1
envisioned to be stream-based considering the amount of data involved and the lack
of the skilled resources to interpret this data in the theater of operation. Instead
payloads capable of detailed measurements are expected to manually or automatically
start ‘recording’ file based detailed measurements around the time a threat occurs.
A3.1.6.4.2.2.2 How to Download Detailed CBRN Measurements?
Since detailed sensor measurements will be stored as files, it will be possible to
download the data. STANAG 4586 provides CBRN Payload Detailed Info Request
(Message #210), CBRN Payload Detailed Info Response (Message #313) and CBRN
Payload Detailed Info Estimate Response (Message #314) to facilitate the download
of such detailed measurements using the appropriate Information Type (Unique ID
0210.06).
Since detailed measurements are expected to be quite large in size, it is highly
recommended to get an estimate first before committing to the download. For more
information see Section A3.1.6.4.4.2 Downloading CBRN Related Information.
A3.1.6.4.3 CBRN Payload Configuration and State
The following sub sections address topics related to the CBRN payload configuration
and state.
A3.1.6.4.3.1 CBRN Payload State
Field Payload State (Unique ID 0311.11) captures the overall state of the payload at
any given moment. The following is worth noting:
-
-
Start up: Depending on the payload type, the payload start state may be
set to Starting up, then possibly followed by Calibrating and then finally set
to Operating while assuming that there were no faults or warnings detected.
Alternatively, a simpler payload’s start state would begin directly at
Operating.
Warning levels: At any point the payload may encounter faults2 or
warnings3. Since these conditions could interfere with the operation of the
payload, their occurrence will be reflected in the Payload State (Unique ID
0311.11) and will supersede other states. Similarly, detections are
considered a critical event that will supersede other states. In the unlikely
event, that some of those 3 states occur at the same time, the following is
the order they supersede each other:
a) Above Threshold (highest priority)
b) Has faults
c) Has warnings (lowest priority)
A3.1.6.4.3.2 CBRN Sampling State
Field Sampling State (Unique ID 0311.22) captures the state of the payload sensing
component at any given moment, the following is worth noting:
2
Corresponds to high or low warning limit for alert zones in Messages #1300, #1301 or #1305.
3
Corresponds to high or low caution limit for alert zones in Messages #1300, #1301 or #1305.
A3 - 76
Edition A Version 1
AEP-84.1





Idle, typically means that the payload is not capable of detecting CBRN
substances for any number of reasons.
Sampling, typically means that the payload is continuously sampling its
environment without holding onto the physical sample. However, some
CBRN payload types have the ability to collect a physical sample. In
this case, Sampling should not be used and instead a new Payload
specific enumeration for “Collecting” is recommended.
Sensing Component Test, used to indicate the payload sensing
component is busy with an internal test that was automatically or
manually commanded.
Scanning, typically is associated with standoff payloads that are
scanning an area of interest.
Tracking, typically is associated with standoff payloads that are
capable of tracking a detected threat cloud.
A3.1.6.4.3.3 Relationship between Payload State, Operating Mode, Sampling
State and Testing State
The following table describes the relationship between the fields Payload State
(Unique ID 0311.11), Operating Mode (Unique ID 0311.21), Sampling State (Unique
ID 0311.22) and Testing State (Unique ID 0311.23).
Payload State
Operating Mode
Sampling State
Testing State
(Unique ID 0311.11)
(Unique ID 0311.21)
(Unique ID 0311.22)
(Unique ID 0311.23)
Has faults
Typically faults2
are severe
conditions that will
cause the payload
to no longer be
able to detect
contamination thus
the field Operating
Mode will typically
be set to Standby.
Typically faults2 are
severe conditions
that will cause the
payload to no longer
be able to detect
contamination thus
the field Sampling
State will typically be
set to Idle.
The field Testing
State will be set to
Not Testing.
Has warnings
Depending on the
severity of the
warnings2 the
payload may no
longer be able to
detect
contamination thus
the field Operating
Mode will be set
accordingly to
Operating or
Standby.
Depending on the
severity of the
warnings2 the
payload may no
longer be able to
detect contamination
thus the field
Sampling State will
either be set
accordingly to Idle or
Sampling.
The field Testing
State will be set to
Not Testing.
A3 - 77
Edition A Version 1
AEP-84.1
Above threshold
Typically the field
Operating Mode
will be set to either
Operating or
Training as
applicable.
Typically the field
Sampling State will
be set to Sampling
or Scanning or
Tracking as
applicable.
The field Testing
State will be set to
Not Testing.
Operating
The field Operating
Mode could be set
to any of the
available values
Operating or
Standby or
Training as
applicable.
If field Operating
Mode is set to
Standby then
typically the payload
detection capability
is not active which
would set the
Sampling State to
Idle. Otherwise the
Sampling State will
be set to Sampling
or Scanning or
Tracking as
applicable.
The field Testing
State will be set to
Not Testing.
Powered off
n/a
n/a
n/a
Starting up
Typically the field
Operating Mode
will be set to
Standby since the
payload detection
capability is not
active.
Typically the field
Sampling State will
be set to Idle since
the payload
detection capability
is not active.
The field Testing
State will be set to
Not Testing.
Calibrating
Typically the field
Operating Mode
will be set to
Standby since the
payload detection
capability is not
active.
Typically the field
Sampling State will
be set to Idle since
the payload
detection capability
is not active.
The field Testing
State will be set to
Not Testing.
Testing
Typically the field
Operating Mode
will be set to
Operating.
Typically Sampling
State will be set to
Idle assuming that
the payload is not
capable of
detections during the
commanded test
operation. But the
The field Testing
State will be set
depending on the
commanded test.
A3 - 78
Edition A Version 1
AEP-84.1
field Sampling State
will be set to
Sensing Component
Test if Testing State
is set to Self Testing
or Sensing
Component Test as
applicable.
A3.1.6.4.3.4 CBRN4 Delivery Mode
The purpose of field CBRN4 Delivery Mode (Unique ID 0310.39) is to


Control the amount of payload product (i.e., the CBRN4) delivered to the
CUCS
Can be used by the CUCS to determine the level of warning delivered to
the operator
A3.1.6.4.3.4.1 CBRN4 Delivery Mode set to Threat Related
This mode is typically used in force protection scenarios where the operator is only
interested in receiving a CBRN product (i.e., CBRN4) and the associated visual/audio
warning only when a threat related detection actually occurs.
Note that field Detection Above Threshold Update Frequency (Unique ID 0310.28), if
not set to zero, will be used by the payload to determine the frequency to send updates
on an already trigged threat detection. If set to zero, the payload will use its own logic
to determine this update frequency, hopefully without inundating the operator.
A3.1.6.4.3.4.2 CBRN4 Delivery Mode set to Continuous
This mode is typically used in survey scenarios where the operator is interested in
receiving and collecting all CBRN products (i.e., CBRN4) based on a configured
frequency via the Schedule Message Update Command (Message #1402). In this
mode the operator would typically not require visual/audio warnings considering the
type of mission and the amount of data expected.
Note that it is important to consider how the payload should report on event based
detections when Continuous mode is set. If the payload is going through a
contamination area and has a reasonably high frequency for reporting Message #309
(and the associated CBRN4) then the normal event based triggering of Message #309
(and the associated CBRN4) might be suppressed so as not to overload the operator
with data outside of the desired frequency. However, this has to be carefully
implemented in order to avoid a situation where the operator is not alerted of a
contamination because Continuous mode was set by mistake and the frequency was
set too low by default resulting in the operator being exposed for a long time before
being properly alerted.
Similarly it is recommended that field Detection Above Threshold Update Frequency
(Unique ID 0310.28) is not used and is even made unavailable while in Continuous
mode so as not to overload the operator with data outside of the desired frequency
setup using the Schedule Message Update Command (Message #1402).
A3 - 79
Edition A Version 1
AEP-84.1
A3.1.6.4.3.5 Alert Zones for CBRN Related Fields
Typically alert zones for CBRN related fields use a visual indicator of Green, Yellow or
Red using either the upper alert zones or the lower alert zones but not both. General
guidance on Alert Zones is found in Section A3.1.2.4.13 but the following is an example
for how to achieve this by declaring certain zone as not applicable.
if isHighLimitValid(highWarning) && value >= highWarning
return RED
else if isLowLimitValid(lowWarning) && value <= lowWarning
return RED
else if isHighLimitValid(highCaution) && value >= highCaution
return YELLOW
else if isLowLimitValid(lowCaution) && value <= lowCaution
return YELLOW
else
return GREEN
boolean isHighLimitValid(limit)
{
return min < limit && limit <= max
}
boolean isLowLimitValid(limit)
{
return min <= limit && limit < max
}
A3.1.6.4.3.6.1 Example of Configuring Alert Zones for Contamination Severity
Level
Assuming a CBRN sensor that reports on Contamination Severity Level (Unique ID
0309.12) and where the integer values are expected to range from 0 to 8 as follows: A
value of 0 is Green, between 1 and 2 is Yellow, and between 3 and 8 is Red. Therefore
using Message #1305 the zones will be defined as follows:
MaxValue = 8
HighWarning = 3 // (>= this) is red
HighCaution = 1 // (>= this) is yellow
LowCaution = 9 // this invalidates
LowWarning = 9 // this invalidates
MinValue = 0
A3.1.6.4.3.6.2 Example of Configuring Alert Zones for Contamination Level
Assuming a CBRN sensor that reports on Contamination Level (Unique ID 0309.08)
and where the floating point values are expected to range from 0.0 to 100.0 as follows:
A value of 0.0 is Green, while any significant value above zero is considered Red.
Therefore using Message #1301 the zones will be defined as follows:
MaxValue = 100.0
HighWarning = 1E-30 // (>= this) is red
HighCaution = 101.0 // this invalidates
LowCaution = -1.0 // this invalidates
A3 - 80
Edition A Version 1
AEP-84.1
LowWarning = -1.0 // this invalidates
MinValue = 0.0
A3.1.6.4.3.6.3 Example of Configuring Alert Zones for Battery Remaining Level
Assuming a CBRN sensor that reports on Battery Remaining Level (Unique ID
0311.08) and where the Battery remaining level (%), where integer values are
expected to range from 0 to 100 as follows: A value from 0 to 25 is Red, from 26 to 50
is yellow and from 51 to 100 is Green. Therefore using Message #1305 the zones will
be defined as follows:
MaxValue = 100
HighWarning = 101 // this invalidates
HighCaution = 101 // this invalidates
LowCaution = 50 // (<= this) is yellow
LowWarning = 25 // (<= this) is red
MinValueUInt = 0
A3.1.6.4.3.7 Relationship between Contamination Level, Contamination
Severity and Detection Type
The payload is ultimately responsible for determining how the operator will be visually
warned regarding a given detection by selecting the field that the CUCS will use to
deliver that threat warning. The VSM accomplishes this by indicating in field
Contamination Threshold Field (Unique ID 0310.37) whether the CUCS is to use field
Contamination Level (Unique ID 0309.08) or field Contamination Severity Level
(Unique ID 0309.12).
In contrast, field Detection Type (Unique ID 0309.06) contains a basic assessment
about the detection and whether it has crossed the warning threshold but it is not really
intended as the primary means to deliver visual warnings. It is intended to:


Provide certain CUCSs with a quick indicator of the type of detection so that it
can be used to route the data quickly to other C4ISR systems or databases
without having to worry about the specific caution and warning levels for
individual types/classes of CBRN payloads.
Act as a backup for the visual warning to the operator in the situation where the
configuration of the caution and warning levels haven’t been completed yet
such as when the CUCS is first establishing the LOI on the payload while Above
Threshold detections are occurring yet the configuration for field Contamination
Level (Unique ID 0309.08) or field Contamination Severity Level (Unique ID
0309.12) are delayed or in progress. In this case, the CUCS will still be able to
display an adequate warning to the operator based on Detection Type (Unique
ID 0309.06).
A3.1.6.4.3.5.1 Example Warning Using Contamination Level
During configuration the VSM will indicate using Contamination Threshold Field
(Unique ID 0310.37) which field the CUCS should use for visual warnings.
A3 - 81
Edition A Version 1
AEP-84.1
Unique
ID
Name
Value
…
…
….
0310.37
Contamination
Threshold Field
0 = Contamination Level
…
….
…
(Unique ID #0309.08)
As part of the CUCS request for configuration, the VSM will provide the appropriate
thresholds for the caution and warning levels using Field Configuration Double
Response (Message #1301). In this example, the payload caution and warning level
will be represented simply as green (contamination is at zero) or red (contamination is
above zero).
Unique
ID
Name
Value
…
…
….
1301.07
Requested Message
309
1301.08
Requested Field
7
1301.09
Field Supported
1 = field supported
1301.10
Max Value
100
1301.11
Min Value
0
1301.12
Max Display Value
100
1301.13
Min Display Value
0
A3 - 82
Edition A Version 1
AEP-84.1
1301.14
Minimum Resolution
1
1301.15
High Caution Limit
101
1301.16
High Warning Limit
1E-30
1301.17
Low Caution Limit
-1
1301.18
Low Warning Limit
-1
1301.19
Help Text
“Contamination level”
1301.20
Subsystem ID
6
1301.21
Route Type
0xFF (all routes)
A3.1.6.4.3.5.2 Example Warning Using Contamination Severity
During configuration, the VSM will indicate using Contamination Threshold Field
(Unique ID 0310.37) which field the CUCS should use for visual warnings.
Unique
ID
Name
Value
…
…
….
0310.37
Contamination
Threshold Field
1 = Contamination Severity
Level (Unique ID
#0309.12)
…
…
….
As part of the CUCS request for configuration, the VSM will provide the appropriate
thresholds for the caution and warning levels using Field Configuration Unsigned
Response (Message #1305). In this example, the payload caution and warning level
will be represented as green (contamination severity is at zero), yellow (contamination
severity is above zero but below 3) or red (contamination severity is equal or above 3).
A3 - 83
Edition A Version 1
AEP-84.1
Unique
ID
Name
Value
…
…
….
1305.07
Requested Message
309
1305.08
Requested Field
9
1305.09
Field Supported
1 = field supported
1305.10
Max Value
8
1305.11
Min Value
0
1305.12
Max Display Value
8
1305.13
Min Display Value
0
1305.14
Minimum Resolution
1
1305.15
High Caution Limit
1
1305.16
High Warning Limit
3
1305.17
Low Caution Limit
9
1305.18
Low Warning Limit
9
1305.19
Help Text
“Contamination severity”
1305.20
Subsystem ID
6
1305.21
Route Type
0xFF (all routes)
A3 - 84
Edition A Version 1
AEP-84.1
A3.1.6.4.3.5.3 Detection Low level and Detection Operational Level
Some CBRN payloads can provide the operator with the capability to override the
payload thresholds with the operator’s desired thresholds. This is in particular useful
for radiological payloads but can be leveraged by all CBRN payload types as well.
If available, the CUCS can command the different thresholds using field Set Detection
Low Threshold Level (Unique ID 0209.20) and field Set Detection Operational
Threshold Level (Unique ID 0209.19). This would affect how the fields for
Contamination Severity Level (Unique ID 0309.12) and/or Contamination Level
(Unique ID 0309.08) will be configured using Message #1305 and #1301 respectively.
For more information on how to configure alert zones see Section A3.1.6.4.3.5 Alert
Zones for CBRN Related Fields.
Assuming a payload that detects positive values, this will effectively result in having
the VSM:


Set the High Caution Limit to the value from field Detection Low Threshold
Level (Unique ID 0310.16)
Set the High Warning Limit to the value from field Detection Operational
Threshold Level (Unique ID 0310.15)
High Warning Limit = Detection Operational Threshold Level (Unique ID 0310.15)
Contamination level
Upper warning zone
Upper caution zone
Nominal zone
Time
Figure A3 - 11: Example of Configuring the CBRN Detection Low and Operational threshold
Levels
High Caution Limit = Detection Low Threshold Level (Unique ID 0310.16)
A3.1.6.4.4 CBRN Payload Commands
The following sub sections address topics related to the CBRN payload commands.
A3.1.6.4.4.1 Scanning manually using Payload Scan Window Configuration
Command (Message #213)
Typically most CBRN standoff payloads will have field Detection Mode (Unique ID
0310.13) configured to “Automatic” allowing the payload on start-up to automatically
A3 - 85
Edition A Version 1
AEP-84.1
scan using the last configured scan window. To manually override the scanning
operation, the operator can use the command field Set Sampling Mode (Unique ID
0208.12) to start and stop the scanning; or if the payload is capable of tracking a threat
cloud to start and stop the tracking. The outcome of the command field Set Sampling
Mode (Unique ID 0208.12) is to be reflected in the operating state of the payload using
the field Sampling State (Unique ID 0311.22).
Max elevation
Actual elevation
Min elevation
End Azimuth
Start Azimuth
Scan radius
Actual Azimuth
Figure A3 - 12: Payload Scan Window
A3.1.6.4.4.2 Downloading CBRN Related Information
CBRN related data can be downloaded using the CBRN Payload Detailed Info Request
(Message #210). Since some data such as detailed measurements might be quite
large in size, the recommendation is for the CUCS to get an estimate of the size of the
data (field Command mode, Unique ID 0210.10, set to Estimate) before committing to
a download (field Command mode, Unique ID 0210.10, set to Download).
Once a download is commanded, the VSM will respond with the message CBRN
Payload Detailed Info Response (Message #313). Note that field File Reference
(Unique ID 0313.08) can be a reference to a Generic Product Transport (GPT)
Message ID. GPT is a protocol that allows for guaranteed file transfer over UDP and
is used here since a CBRN detailed measurement is a file based product, for more
information about GPT please refer to the AEP-84 Volume I.
A3.1.6.4.4.2.1 Relationship Between Information Type and Detection Type
CBRN related data can be downloaded using the CBRN Payload Detailed Info Request
(Message #210). It is important to understand the relationship between Information
Type (Unique ID 0210.06) and Detection Type (Unique ID 0309.06).
For example, for CBRN4s:
A3 - 86
Edition A Version 1
AEP-84.1
Information Type
What to download
(Unique ID 0210.06)
2 = Above Threshold CBRN4s
All CBRN4s that were associated to a
Message #309 where Unique ID
0309.06 was set to 1 (Above Threshold)
OR 2 (Above Threshold Update)
3 = Below Threshold CBRN4s
All CBRN4s that were associated to a
Message #309 where Unique ID
0309.06 was set to 0 (Below Threshold)
OR 3 (NIL, Detection cleared)
6 = NIL CBRN4s
All CBRN4s that were associated to a
Message #309 where Unique ID
0309.06 was set to only 3 (NIL,
Detection cleared)
A similar correlation will exist for detailed sensor measurements.
A3.1.6.5
Weapons
Within STANAG 4586, the 18xx series of messages are used to uplink message
commands from the CUCS to the UA/VSM and the 19xx series of messages are used
to downlink responses or status updates from the UA/VSM to the CUCS. Many of
these messages are optional and may only be necessary for a specific implementation.
For example, Message #1827 (GeoZone Control) will only be used by systems
implementing GeoZones in a particular theater of operations.
A3.1.6.5.1 General Information
This implementation guide focuses only on the messages and message sequences
that are necessary to discover, configure, arm, and fire a weapons store. It does not
address the many optional messages that system developers may choose to
implement.
A weapons store is a single instantiation of a specific weapon type (e.g., a vehicle
carrying four of Missile Type A and two of Missile Type B has six weapons stores).
Weapons stores are assumed to be air-to-ground weapons and not static sensors or
other non-dispensable payloads, nor does this standard take into consideration air-toair weapons. Weapons stores are managed by the Stores Management System
(SMS), a subsystem which controls and monitors the operational state of weapons
stores and provides and manages the communications between weapon stores and
other aircraft subsystems. Within STANAG messaging, the SMS is addressed the
same as any other payload is addressed and is discovered and configured the same
as any other payload.
Stores may be addressed individually or as a weapons package. A weapons package
is a group of weapons and their associated parameters that are intended to be
released in a specific order. A package may consist of one or multiple weapons stores.
A3 - 87
Edition A Version 1
AEP-84.1
Weapon packages may be considered to be static or dynamic. A static weapon
package is typically loaded onto the UA prior to the mission via a system-specific
method and is not changed throughout the duration of the mission. There are no
STANAG 4586 messages dedicated to the creation or maintenance of a static weapon
package. A dynamic weapon package may be configured real-time using specific
messaging. Message #1819, Dynamic Weapon Package Control, may be sent by the
CUCS to the UA indicating that a series of messages will follow to describe the weapon
types to be included in the dynamic package and establishing a weapon package ID.
This message is followed by one or multiple Message #1820s, Dynamic Weapon
Package Store Request, which assign weapon and warhead types to the specific
dynamic weapon package ID established in Message #1819. The UA should respond
with Message #1905, Weapon Package Status Response, followed by one or multiple
Message #1906s, Weapon Package Status, indicating the status of each store
requested in the series of 1820 messages.
In order to initialize all of the stores contained within the defined dynamic weapons
package as a single batch, the CUCS sends Message #1821, Initialize Dynamic
Weapon Package, which indicates the desired weapon package ID. The UA should
respond to this message with Message #1903, Primary Store Status, indicating that
the stores are initialized. Stores within a weapon package may also be initialized
sequentially by the CUCS via Message #1805, Prepare Store. The UA should respond
with Message #1903, Primary Store Status, to indicate that the specified store was
initialized.
Weapon messages contain a “Station ID” field which identifies the SMS on the UA,
and may contain Hardpoint, Carriage, and Store ID fields to provide for specific
subsystem addressing. The SMS Station ID is reported in Message #300. These IDs
allow for addressing all levels of the SMS system depending on need from SMS as a
whole down to specific carriages or stores.
If the Hardpoint, Carriage, and Store ID fields are all set to zero, then the message is
referring to the weapon package. Many messages contain a Weapon Package ID
field. A value of 255 is used to indicate the default weapon package; else, if the CUCS
has created a dynamic weapon package, then the assigned package ID value is used.
When addressing specific stores, multiple selections can be obtained by ORing the bit
values. For example, a message sent to hardpoints 1, 7, and 17 would be denoted by
ORing 0x00000001, 0x00000040, and 0x00010000 resulting in 0x00010041. Wild
cards would be indicated by all FFF…’s meaning that the messages are meant for all
nodes where FFF… occurs. A non-zero value in the hard point position with zeroes in
the carriage and the store positions means that the action is meant only for the
indicated hard point. Similarly, non-zero values in the hard point and carriage position
with a zero in the store position means that the message is destined only for the
carriage nodes.
Several command messages contain a generic “Request ID” field which is used to
differentiate one request from another. This ID is echoed back in the response(s) to
that command or request, thereby allowing explicit association of a response to the
request. Use of this mechanism allows multiple requests to be dispatched without
having to wait for all responses to a single request to be received. The field also
allows systems to ensure that commands do not inadvertently conflict with each other
(e.g., if an older command is received after a more recently sent command of the same
A3 - 88
Edition A Version 1
AEP-84.1
message type, by using a sequential numeric order in the “Request ID” field, a system
can determine the intended order of the commands and only implement the most
recent).
A3.1.6.5.2 Weapon Discovery and Configuration
Discovery of the SMS station is accomplished via Message #300 by setting Unique ID
300.07 to enumeration 11 = SMS. Once the CUCS has discovered the location of the
SMS station, the CUCS requests the status of each weapons store by sending
Message #1814 (Store Inventory Status Request). The UA/VSM responds to this
request by sending Message #1901 (Store Specific Information Response) and a
series of Message #1902s (Store Inventory Status), one per weapons store. The total
number of Message #1902s that the CUCS can expect to receive is indicated by the
value in Unique ID 1901.06. It is recommended that the UA/VSM request
acknowledgement of Message #1901 and each individual Message #1902. Once all
Message #1902’s have been received, the CUCS will be aware of exactly how many
weapon types and individual stores for each type are available on the UA.
Configuration of weapons stores may or may not be necessary if the default
configuration is acceptable to the CUCS. To determine the default configuration for
each store, the CUCS sends Message #1800 (Store Specific Information Request) to
request the various configuration status messages. There are three configuration
status messages that may be requested in any order:
o
o
o
Message #1908 (Seeker Sensor Status): indicates the default trajectory
in Unique ID 1908.28
Message #1911 (Fuze Status): indicates the fuze status and current
settings
Message #1912 (Weapon Laser Status): indicates the currently loaded
laser code and status
If the CUCS desires to change any of the default configuration settings for a store, then
the CUCS sends the appropriate command message or messages; Message #1810
(Fuze Control), Message #1811 (Seeker Sensor Control), or Message #1812 (Weapon
Laser Control). The CUCS may opt to send all, some, or none of these command
messages, in any order.
It is important for the CUCS to be aware of the default firing order of all weapons within
a weapons package. If the default weapons package is being used, the CUCS uses
Message #1800 to request Message #1903 (Primary Store Status) which reports the
assigned firing order of each store in Unique ID 1903.09. If the CUCS has assigned a
dynamic weapons package, then the CUCS can assign firing order using Message
#1820 via Unique ID 1820.06.
Configuration or firing order may be changed at any time, either when the SMS is
armed or unarmed, including after the firing of a weapon store in order to reconfigure
for a second firing attempt.
A3.1.6.5.3 Weapon Mission Key
Once the CUCS is satisfied concerning weapon package status, firing order, and store
configuration, there is a minimum set of messages necessary to transition the SMS
from an unarmed state to an armed state with the potential to dispense a weapons
store. The SMS state diagram below depicts the states of the SMS once a CUCS has
A3 - 89
Edition A Version 1
AEP-84.1
achieved LOI 3 control of the UA/SMS station, and the transitions that occur moving
from one state to the next.
Control of SMS granted
Control of SMS terminated
Disarmed
Jettison complete
Idle
Jettisoning
Mission Key Loaded
Valid key received
Jettison command
received with valid key
Arm command received
with valid key
Disarm command
received
Armed
Fire command received
with valid key
Pending Engagement
Jettison command
received with valid key
Firing
Jettisoning
Firing complete
Jettison
complete
Figure A3 - 13: SMS State Diagram
Upon initial control, the SMS is in an unarmed state. In order to transition from the
initial idle state, the UA/SMS needs to receive a valid mission key from the CUCS.
A3 - 90
Edition A Version 1
AEP-84.1
There are three safety-critical functions that require a mission key in order to be
executed. Prior to arming, firing, or jettisoning a store, the CUCS needs to first publish
an implementation-dependent mission key via Message #1816. The key value sent in
Unique ID 1816.06 can be set to any value (a 32-bit prime number is recommended).
The UA should verify receipt of the key via Message #1924 (Key Status). The validated
mission key will be included in Message #1806 (Master Arm Control), Message #1808
(Fire Control), and Message #1813 (Jettison Store) in order for the UA to accept and
execute the commanded actions.
If Unique ID 1816.05 equals 255, the CUCS is instructing the UA to use the same
mission key for all three safety-critical functions. If Unique ID1816.05 equals 0, 1, or
2, then the CUCS is providing the UA with a different mission key for each of the three
safety-critical functions, and the UA can expect to receive three separate Message
#1816s in total.
The Message #1924 response sent by the UA also contains several safety-critical
Unique IDs (1924.08, 1924.09, and 1924.10) that allow implementers to set certain
safety parameters for arming, firing, or jettisoning a store. See the descriptions below
for more detailed descriptions.
A3.1.6.5.4 Weapon Arming
Once the mission key has been published and verified, the CUCS can arm the SMS at
any time. To arm the SMS, the CUCS transmits Message #1806 to the UA/VSM with
the mission key value in Unique ID 1806.06 set to the same value published via
Message #1816. The UA/VSM responds with Message #1900 (SMS Status) with
Unique ID 1900.08 set to Enabled to verify that the mission key was valid and that the
SMS is now armed. Arming of each individual weapon store managed by the SMS is
handled via communication between the SMS and the weapon store itself and is not
covered by this guide.
Once the SMS is armed, system implementers should provide some form of safety
oversight to account for situations where communication between the CUCS and UA
may be lost. Message #1924 allows designers the option of establishing a “weapons
heartbeat” that would provide for the UA to disarm automatically upon the loss of the
heartbeat.
1924.10
10 Minimum Master
Arm Heartbeat Rate
Float
Hz
x < 0 (Error)
0≤x
Use of 0 Hz indicates
alternate action
Master Arm
If a non-zero value is entered in Unique ID 1924.10, then the UA is instructing the
CUCS to use Message #1806 as a periodic heartbeat at the specified rate once arming
has occurred, and to ignore Unique IDs 1924.08 and 1924.09 for arming. If a zero
value is entered into Unique ID 1924.10, then the UA is instructing the CUCS to use
Unique IDs 1924.08 and 1924.09 for arming criteria.
A3 - 91
Edition A Version 1
AEP-84.1
1924.08
8
Safety Critical
Command Minimum
Message Count
Unsigned
1
None
No Restrictions
Unsigned
2
s
No Restrictions
If 192A3.10 is nonzero, then this field
does not apply to
Master Arm (#1806)
1924.09
9
Safety Critical
Command Message
Sequence Maximum
Time Limit
If 1924.10 is non-zero,
then this field does not
apply to Master Arm
(#1806)
In the case where Unique ID 1924.10 is set to zero, the UA will use Unique ID 1924.08
to specify the number of arming messages in accordance with a systems safety
requirements that must be received within a certain time limit, as specified in Unique
ID 1924.09. For example, the UA may specify that the CUCS must send three
Message #1806s within 5 seconds in order for the UA to consider the arming command
to be valid. Alternatively, the UA may specify that only one Message #1806 is required
for arming, or may specify an indefinite time period by inputting a value of zero in
Unique ID1924.09. For arming safety considerations, it is left to system developers
whether they opt to use the heartbeat method, the minimum message count method,
or a system-specific method.
Unique ID 1806.05 contains the Master Arm Request ID. If Message #1806 is used
as a heartbeat for an armed SMS, the Request ID should be the same for all heartbeats
in order to differentiate it from a command to change state. If multiple Message #1806s
are sent to arm the UA/SMS, then the Request ID should be the same for each required
message. For example, if Unique ID 1924.08 indicates that three arming messages
are required to successfully arm the SMS, the CUCS should use the same Request ID
for all three arming messages.
Note that if the UA/SMS becomes disarmed due to any safety related condition (system
specific), the CUCS should use a different Request ID value in Unique ID 1806.05 if
they desire to re-arm the SMS. This is to prevent a weapons heartbeat from the initial
arming sequence from accidentally re-arming the SMS when that may not be the intent.
A3.1.6.5.5
Weapon Firing
Firing cannot occur unless the SMS has been previously armed. A store must be
configured appropriately prior to release (or firing). Each store may have different
minimum parameters required prior to being available for release. For example, one
critical parameter will likely be the target location. To transmit target information to the
UA if not already accomplished via other implementation-specific means, the CUCS
sends Message #1815 (Modify Target). In response, the UA should send Message
A3 - 92
Edition A Version 1
AEP-84.1
#1916 (Modify Target Status) to verify that the correct target information was received
and stored. The CUCS may request the target information status message from the
UA via Message #1800 at any time. Not all weapons may need targets.
When the system is armed and target information is confirmed to be valid, the CUCS
may instruct the UA to fire the next weapon store in the firing order by transmitting
Message #1808. Note that the UA may have previously specified (via Message #1924,
Unique IDs 1924.08 and 1924.09) a required number of Message #1808s that must be
received within a specified time limit. For example, if Unique ID 1924.08 was set to 3
and Unique ID1924.09 to 3, then the UA must receive three valid Message #1808s
within 3 seconds for the UA to execute the Fire command.
Once a valid firing command has been received and executed, the UA reports the
status of the firing attempt by sending Message #1903 and denoting the store status
in Unique ID 1903.13, to include misfires, hang fires, and launches.
When the CUCS is satisfied with the firing status as reported by the UA in Message
#1903, the CUCS may elect to fire again using the next store in the firing order (using
the same default configurations), to reconfigure a weapon store using the method
noted above, to disarm the SMS, or to do nothing until further action is required.
A3.1.6.5.6 Weapon Jettison
In the event that a CUCS desires to jettison a store from the UA, the CUCS should
transmit Message #1813 with Unique ID 1813.10 set to the valid mission key
previously published in Message #1816 and the individual store to be jettisoned
specified in Unique IDs 1813.05, 1813.06, and 1813.07, which denote the specific
hardpoint, carriage, and store. Note that jettison may not be available on all UA or for
some stores, all dependent on the UA SMS architecture.
It is critical to note that if values of zero are indicated in Unique ID 1813.05 (hardpoint),
Unique ID 1813.06 (carriage), and Unique ID 1813.07 (store), all weapons stores
currently managed by the SMS will be jettisoned from the UA. Additionally, if the
hardpoint ID is specified as non-zero, and both carriage and store ID’s are set to zero,
then all stores on all carriages at the specified hardpoint will be jettisoned. The same
applies if hardpoint and carriage ID’s are set to non-zero, but the store ID is set to zero.
All stores on the specified carriage on the specified hardpoint will be jettisoned.
The UA may have previously specified (via Message #1924, Unique IDs 1924.08 and
1924.09) a required number of Message #1813s that must be received within a
specified time limit. For example, if 1924.08 equals 3 and 1924.09 equals 10, then the
UA must receive three valid Message #1813s within 10 seconds for the UA to execute
the Jettison command.
Jettisoning may be directed at any time after the mission key has been published and
accepted by the UA – the SMS may be in either the unarmed or armed state. However,
it is recommended that all stores be attempted to be disarmed prior to jettison. If this
is an emergency situation, no confirmation of safeing should be required. If it’s a nonemergency situation, then confirmation of safeing should be required.
A3.1.6.5.7 Weapon Disarm
The CUCS may disarm the SMS at any point after it has been armed by sending
Message #1806 with any value OTHER than the previously specified mission key in
A3 - 93
Edition A Version 1
AEP-84.1
Unique ID 1806.06. Disarming the SMS via Message #1806 does not require any
minimum message count received within a specified time period.
The SMS may also be disarmed via loss of weapon heartbeat (#Message 1806 at a
specified rate, if this was implemented via Message #1924, Unique ID 1924.10) or via
a system-specific method not covered in this guide.
The UA reports the status of the disarming command by sending Message #1900 with
Unique ID 1900.08 set to Disabled.
Once disarmed, SMS and stores are still powered and the CUCS may still configure
weapon stores, load or view target information, or conduct any weapon messaging
except for firing.
A3.1.6.5.8
Example Message Sequence
The following message sequence depicts nominal message flow to arm and fire a
weapon store. In this example, the SMS has already been discovered, the default
weapon package is being used, and the weapon stores have already been determined
to be configured as needed. All specified field values are example only.
A3 - 94
Edition A Version 1
AEP-84.1
UA/VSM
CUCS
Message #1816: Publish Key
1816.05 = All
1816.06 = Key Value
Message #1924: Key Status
1924.08, .09, .10 set to desired values
Message #1806: Master Arm Control
1816.06 = Mission Key Value
Message #1900: SMS Status
1900.08=1
Optional: sent periodically at n Hz IF a non-zero value was used in 1924.10
Message #1806: Master Arm Control
1806.06=Mission Key Value
Optional: may already have been accomplished, completed by other means or may not be necessary
Message #1815: Modify Target
Message #1916: Modify Target Status
May be sent n times (specified in 1924.08) within x seconds (specified in 1924.09)
Message #1808: Fire Command
1808.10=Mission Key Value
Message #1903: Primary Store Status
1903.13=Launch
Disarming
Message #1806: Master Arm Control
1806.06=NOT Mission Key Value
Message #1900: SMS Status
1900.08=0
Figure A3 - 14: Nominal Message Flow to Arm and Fire a Weapon Store
A3.1.6.6 Lasers
STANAG 4586 allows for control of laser pointers, designators, and rangefinders using
Messages #201 and #302. This section documents elements of control specific to
those devices.
A3 - 95
Edition A Version 1
AEP-84.1
If present, it is assumed that a laser pointer, designator, and rangefinder will be
integrated into the EO/IR payload type. They are not themselves considered a sensor,
but it is possible to have a payload that contains a laser of one of the three types but
is neither an EO nor IR sensor.
These lasers, when integrated with an EO/IR Sensor are not considered a sensor, but
it is possible to have a payload that only contains a laser and not an EO or IR sensor
For laser modes, the implementers(s) of the VSM and the CUCS may elect to support
making certain enumerations available on a dynamic basis. This might be desirable
because the VSM may want to take some action based on operator input which cannot
be reflected in the DLI with the message. Alternatively, the implementer of a CUCS
may elect to make certain enumerations available based on the logical progression of
states based on the CUCS’s system requirements (e.g., that a laser that is off cannot
immediately be armed or fired but instead must be turned on). A CUCS could
conceptually support both cases, presumably defaulting to the desired behavior of the
VSM, but this adds significant complexity.
A3.1.6.6.1 Laser Designator
Laser designation is the act of using a laser to mark a target for elimination by use of
a laser guided weapon. There are two primary data items which the UA needs for laser
designation: the CUCS’s desired mode of the laser designator as well as the laser
designation code.
UA which need to use Messages #201 and #302 but which do not carry a laser
designator should configure Unique IDs 0201.13, 0201.14, 0302.24, and 0302.25 out
of a CUCS. They should additionally ignore the laser designator command fields when
they receive a Message #201, and they should always send 0s in the laser designator
status fields. A CUCS should have the reverse logic.
A3.1.6.6.1.1 Laser Designator Mode
0201.14
15
Initiate Laser
Designator
Unsigned
1
Enumerated
0 = Off
51 = Arm
68 = On - Safe
85 = Fire
0302.25
26
Laser Designator
Status
Unsigned
1
Enumerated
0 = Off
1 = On - Safed
2 = Armed
3 = Firing
4 = Masked
Unique IDs 0201.14 Initiate Laser Designator and 0302.25 Laser Designator Status
mediate the laser designator’s mode. The enumerations in both fields deliberately do
not match, as a laser designator is generally considered to need a higher level of
system safety. The command enumerations are specifically designed to be resistant
to bit-flip errors which could cause an undesired action.
The following is a list of matching fields and enumerations between command and
status, as well as the intent of the enumerations:
A3 - 96
Edition A Version 1
AEP-84.1





Unique IDs 0201.14 and 0302.25 enumeration 0 = Off: As a command, this
means the laser should turn off completely if not already off; as a status, this
means the laser is completely off.
Unique IDs 0201.14 enumeration 68 and 0302.25 enumeration 1 = On –
Safe(d): As a command, this means the laser should turn on (into a safe mode
as in eye-safe or weapons-safe) or should go from an armed or firing state to
the safe state; as a status, this means the laser is on and in the safe state.
Unique IDs 0201.14 enumeration 51 and 0302.25 enumeration 2 = Arm(ed):
As a command, this means the laser should arm (into an unsafe state) with the
expectation that it is or will be firing soon; as a status this means the laser is
armed. “Armed” is usually considered the first step in a two-step process to fire
a laser.
Unique IDs 0201.14 enumeration 85 and 0302.25 enumeration 3 = Fire/Firing:
As a command, this means the laser is to fire on the location of interest at which
the payload is pointing; as a status, this means the laser is currently firing.
Unique ID 0302.25 enumeration 4 = Masked cannot be commanded using
0201.14. The intent of “Masked” is that the laser is unable to fire on the target
location. The reason for a mask may be natural obstruction, such as clouds
between the laser and its target, or system obstruction, such as the UA’s own
wing during a banking turn. System designers should consider this case
carefully – requirements regarding how to handle laser masked are concept of
operations-specific but are generally considered a failure case.
Implementers should account for their safety needs with respect to configured
enumerations.
A3.1.6.6.1.2 Laser Designator Code
0201.13
14
Set Laser Designator Unsigned
Code
2
Laser Illuminator Code
per STANAG 5516
(Ed 2) (Link 16) Page
E-3-527 DFI #1676
DUI 001
None
No Restrictions
0302.24
25
Laser Designator
Unsigned
Code
2
Laser Illuminator Code
per STANAG 5516
(Ed 2) (Link 16) Page
E-3-527 DFI #1676
DUI 001
None
No Restrictions
The laser code is the code which the laser guided weapon will use to identify the correct
laser point to follow. It will typically correlate to some set of laser light pulses. NATO
has standardized the codes for pulse repetition frequency (PRF) type lasers in
STANAG 3733 Laser Pulse Repetition Frequencies Used for Target Designation and
Weapons Guidance. Other codes are unstandardized at the NATO level.
STANAG 4586 allows for a larger range of codes which correlate to the range and
encoding of the laser illuminator code in STANAG 5516 Link 16. In particular, the
coding required by STANAG 5516 is an unsigned 2 byte binary coded decimal (BCD)
A3 - 97
Edition A Version 1
AEP-84.1
integer sequence. The field requires support for 4 digits, each digit in the range of 0 to
9. For example, the code 1111 would be encoded as 00010001 00010001; the code
1665 would be encoded as 00010110 01100101 (rather than the normal integer
interpretation of 00000100 01010111 and 00000110 10000001, respectively).
Given the BCD nature of the fields, supporting static configuration on the range of this
field is not recommended for either a CUCS or a VSM—a range limitation on this field
is essentially meaningless. System implementers needing to restrict the commands
sent using Unique ID 0302.24 should consider a CUCS-specific solution.
A3.1.6.6.2 Laser Pointer
Laser pointing is the act of using a laser to mark a target without any other implication,
similar to the set of devices called laser pointers that can be purchased and used in
the commercial and education worlds. There is one primary data item which the UA
needs for laser pointing: the CUCS’s desired mode of the laser pointer.
UA which need to use Messages #201 and #302 but which do not carry a laser pointer
should configure Unique IDs 0201.16 and 0302.22 out of a CUCS. They should
additionally ignore the laser pointer command fields when they receive a Message
#201, and they should always send 0s in field with Unique ID 0302.22. A CUCS should
have the reverse logic.
0201.16
11
Fire Laser Pointer
Unsigned
1
Enumerated
0 = Off
51 = Arm
68 = On - Safe
238 = Fire
0302.22
22
Fire Laser Pointer
Status
Unsigned
1
Enumerated
0 = Off
1 = On - Safed
2 = Armed
3 = Firing
4 = Masked
5 - 15 = Reserved
16 - 255 = PayloadSpecific
Unique IDs 0201.16 Fire Laser Pointer and 0302.22 Fire Laser Pointer Status mediate
the laser pointer’s mode. The enumerations in both fields deliberately do not match,
as a laser pointer is generally considered to need a higher level of system safety. The
command enumerations are specifically designed to be resistant to bit-flip errors which
could cause an undesired action.
The following is a list of matching fields and enumerations between command and
status, as well as intent of the enumerations:


Unique IDs 0201.16 and 0302.22 enumeration 0 = Off: As a command, this
means the laser should turn off completely if not already off; as a status, this
means the laser is completely off.
Unique IDs 0201.16 enumeration 68 and 0302.22 enumeration 1 = On –
Safe(d): As a command, this means the laser should turn on (into a safe mode
as in eye-safe or weapons-safe) or should go from an armed or firing state to
the safe state; as a status, this means the laser is on and in the safe state.
A3 - 98
Edition A Version 1
AEP-84.1





Unique IDs 0201.16 enumeration 51 and 0302.22 enumeration 2 = Arm(ed):
As a command, this means the laser should arm (into an unsafe state) with the
expectation that it is or will be firing soon; as a status this means the laser is
armed. “Armed” is usually considered the first step in a two-step process to fire
a laser.
Unique IDs 0201.16 enumeration 238 and 0302.22 enumeration 3 = Fire/Firing:
As a command, this means the laser is to fire on the location of interest at which
the payload is pointing; as a status, this means the laser is currently firing.
Unique ID 0302.22 enumeration 4 = Masked cannot be commanded using
Unique ID 0201.16. The intent of “Masked” is that the laser is unable to fire on
the target location. The reason for a mask may be natural obstruction, such as
clouds between the laser and its target, or system obstruction, such as the UA’s
own wing during a banking turn. System designers should consider this case
carefully – requirements regarding how to handle laser masked are concept of
operations-specific but are generally considered a failure case.
Unique ID 0302.22 enumerations 5-15 = Reserved should not be used.
Unique ID 0302.22 enumerations 16-255 = Payload-Specific may be
configured using the standard configuration process. None of the enumerations
can be commanded using Unique ID 0201.16. Whether this is by design is
unknown.
Implementers should account for their safety needs with respect to configured
enumerations.
A3.1.6.6.3 Laser Rangefinder
Laser rangefinding is the act of using a laser to get the range from the UA to a location
of interest. Typically, the location of interest is a target for future action. Laser
rangefinders provide a higher degree of confidence of a location of interest compared
to the use of terrain elevation data. There are two primary data items which the UA
needs for laser rangefinding: the CUCS’s desired mode of the rangefinder and the
first/last pulse mode. The UA will send one more element of data called the reported
range.
UA which need to use Messages #201 or #302 but which do not carry a laser
rangefinder should configure Unique IDs 0201.11, 0201.12, 0302.21, 0302.23, and
0302.26 out of a CUCS. They should additionally ignore the laser rangefinder
command fields, and they should always send Unique IDs 0302.26 and 0302.23 filled
with a value of 0. A CUCS should have the reverse logic.
A3.1.6.6.3.1 Laser Rangefinder Mode
0201.11
12
Fire Laser
Rangefinder
Unsigned
1
Enumerated
0 = Off
51 = Arm
68 = On – Safe
85 = Fire One Pulse
238 = Fire Multiple
Pulses
A3 - 99
Edition A Version 1
AEP-84.1
0302.26
23
Fire Laser
Rangefinder Status
Unsigned
1
Enumerated
0 = Off
1 = On - Safed
2 = Armed
3 = Recharging
(Armed)
4 = Firing
5 = Masked
6 - 15 = Reserved
16 - 255 = PayloadSpecific
Unique IDs 0201.11 Fire Laser Rangefinder and 0302.26 Fire Laser Rangefinder
Status mediate the laser rangefinder’s mode. The enumerations in both fields
deliberately do not match, as a laser rangefinder is generally considered to need a
higher level of system safety. The command enumerations are specifically designed
to be resistant to bit-flip errors which could cause an undesired action.
The following is a list of matching fields and enumerations between command and
status, as well as intent of the enumerations:





Unique ID 0201.11 and 0302.26 enumeration 0 = Off: As a command, this
means the laser should turn off completely if not already off; as a status, this
means the laser is completely off.
Unique ID 0201.11 enumeration 68 and 0302.26 enumeration 1 = On – Safe(d):
As a command, this means the laser should turn on (into a safe mode as in
eye-safe or weapons-safe) or should go from an armed or firing state to the
safe state; as a status, this means the laser is on and in the safe state.
Unique IDs 0201.11 enumeration 51 and 0302.26 enumeration 2 = Arm(ed):
As a command, this means the laser should arm (into an unsafe state) with the
expectation that it is or will be firing soon; as a status this means the laser is
armed. “Armed” is usually considered the first step in a two-step process to fire
a laser.
o Unique ID 0302.26 enumeration 3 = Recharging (Armed) also matches
Unique ID 0201.11 enumeration 51. This state occurs when a laser
must charge before or after firing. The laser is expected to reject fire
commands—namely Unique ID 0201.11 enumeration 238 and Unique
ID 0201.11 enumeration 85.
Unique ID 0201.11 enumeration 238 and Unique ID 0302.26 enumeration 3 =
Fire Multiple Pulses/Firing: As a command, this means the laser is to fire (and
continue firing) on the location of interest at which the payload is pointing; as a
status, this means the laser is currently firing.
o Unique ID 0201.11 enumeration 85 = Fire One Pulse also matches
Unique ID 0201.11 enumeration 3. As a command, this means the laser
is to fire exactly one pulse on the location of interest at which the
payload is pointing.
Unique ID 0302.26 enumeration 4 = Masked cannot be commanded using
Unique ID 0201.11. This is intentional, as laser masked implies a state where
the laser is unable to fire on the target location. The reason for a mask may be
natural obstruction, such as clouds between the laser and its target, or system
obstruction, such as the UA’s own wing during a banking turn. System
designers should consider this case carefully – requirements regarding how to
A3 - 100
Edition A Version 1
AEP-84.1


handle laser masked are concept of operations-specific but are generally
considered a failure case.
Unique ID 0302.26 enumerations 6-15 = Reserved should not be used.
Unique ID 0302.26 enumerations 16-255 = Payload-Specific may be
configured using the standard configuration process. None of the enumerations
can be commanded using Unique ID 0201.11. Whether this is by design is
unknown.
Implementers should account for their safety needs with respect to configured
enumerations.
A3.1.6.6.3.1.1 First/Last Pulse
0201.12
13
Select Laser
Rangefinder
First/Last Pulse
Unsigned
1
Enumerated
1 = First
2 = Last
0302.23
24
Selected Laser
Rangefinder
First/Last Pulse
Unsigned
1
Enumerated
1 = First
2 = Last
The first/last pulse selection determines whether the laser will report ranges based on
the first pulse of a pulse sequence returned to the laser from the location of interest or
whether the laser will report ranges based on the last pulse of the pulse sequence.
The specific laser rangefinder engagement will usually indicate which of the two values
will be selected.
Calculation or use of this value is entirely a VSM and payload function—the CUCS’s
function is only to permit selection of one of the values.
Unique ID 0201.12 enumeration 1 = First matches Unique ID 0302.23 enumeration 1
= First; similarly for enumerations 2 and 2.
A3.1.6.6.3.1.2 Reported Range
0302.21
21
Reported Range
If > 0 then reported
range is valid for the
current reported
location in this
message.
Float
m
0 ≤ x ≤ 100,000 (0=
Range is invalid)
The reported range is the desired payload product for a laser rangefinder, as this is
the information that indicates the range to a location of interest. The location of interest
can be calculated to a high degree of confidence when the location and orientation of
the UA, the orientation of the laser payload, and the reported range are known.
If the laser becomes masked for any reason, then the range should also be reported
as 0. Other system-specific reasons may be also be applicable. A CUCS receiving a
range of 0 should discard the information.
The reported range can be used outside the context of the laser rangefinder as a way
for a non-laser payload to report the range. Two examples of such a payload might be
a coincidence rangefinder or a VASCAR.
A3 - 101
Edition A Version 1
AEP-84.1
A3.1.6.7 Payload Steering
A steerable payload is a payload which can have its orientation changed in some
fashion to provide a different understanding of the area of interest. The EO/IR, fixed
camera, and SAR payload types are all considered to be steerable in the context of
STANAG 4586; there may be other emerging types of steerable payloads. There are
various potential mount orientations for a payload on an UA, such as a tilt-over-pan
mount or a tilt-over-roll mount, therefore the implementation of the steering commands
is based on the camera centreline.
STANAG 4586 allows for the command of steerable payloads using Message #200,
while payloads which report their orientations must do so in the context of their
dedicated payload message. For EO/IR and fixed camera payloads, this is Message
#302; for SAR payloads, this is Message #303. UA which need to use Message #200
but which do not carry an EO/IR payload should configure Unique IDs 0200.07,
0200.08, 0200.15 and 0200.16 out of the message, and should ignore those fields
when Message #200 is received. These UA should also configure out enumeration 0
of Unique ID 0200.17. In addition, it’s recommended for a CUCS to provide for
controllability of the majority of the fields and enumerations in Messages #200 via
support for Message #1303. This enables a UA to provide information on what the
CUCS should be able to change at any given time.
For EO/IR payloads, any time Message #201 is sent with new or re-commanded
information (specifically if the pointing mode changes or is re-commanded), the CUCS
should also send a Message #200 Payload Steering Command to indicate to the UA
the expected steering.
A3.1.6.7.1 Pointing Mode
0201.10
10
Set EO/IR Pointing
Mode
Unsigned
1
Enumerated
0 = No Value
1 = Angle Relative to
UA
2 = Slewing Rate
Relative to UA
3 = Slewing Rate
Relative to Inertial
4 = Lat-Long Slaved
5 = Target Slaved
(Track)
6 - 9 = Reserved
10 - 255 = PayloadSpecific
A3 - 102
Edition A Version 1
AEP-84.1
0302.19
19
Pointing Mode State
Unsigned
1
Enumerated
0 = No Value
1 = Angle Relative to
UA
2 = Slewing Rate
Relative to UA
3 = Slewing Rate
Relative to Inertial
4 = Lat-Long Slaved
5 = Target Slaved
(track)
6 - 9 = Reserved
10 - 255 = PayloadSpecific
Unique IDs 0201.10 Set EO/IR Pointing Mode and Unique ID 0302.19 Pointing Mode
State mediate the pointing mode of the UA’s EO/IR payload. Unique ID 0201.10
enumeration 0 = No Value matches Unique ID 0302.19 enumeration 0 = No Value;
similarly for enumerations 1-5 and 1-5 respectively. Enumerations 6-9 = Reserved in
both command status should never be used. Enumerations 10-255 = Payload-Specific
may be configured using the standard configuration process. For enumerations other
than 0, Unique ID 0201.06 System Operating Mode should always equal enumeration
5 = Active.
 Enumeration 0 = No Value should be commanded when Unique ID 0201.06
System Operating Mode is commanded as any value other than 5 = Active.
The UA should report Unique ID 302.19 enumeration 0 = No Value and ignore
Message #200 steering parameters while the commanded state is Unique ID
0201.10 enumeration 0 = No Value.
 Enumeration 1 = Angle Relative to UA commands the payload to point at a
constant angle relative to the UA.
 Enumeration 2 = Slewing Rate Relative to UA commands the payload to remain
at a fixed heading.
 Enumeration 3 = Slewing Rate Relative to Inertial commands the payload to
slew the payload with respect to the payload field-of-view.
 Enumeration 4 = Lat-Long Slaved commands the payload to an earthreferenced 3-space location defined by the coordinates latitude, longitude, and
altitude. The note regarding slaved modes in AEP-84 Volume I does not apply
to this mode.
 Enumeration 5 = Target Slaved (Track) commands the payload to track a
target. The method of tracking is payload-specific. Note: AEP-84 Volume II
permits the CUCS to control the payload-specific tracking mode. Adjustment to
the location being tracked is not supported by STANAG 4586 directly and so if
this functionality needs to be present it requires a private message or the VSM
to adjust the location of the tracked part of the field of view. As in AEP-84
Volume I, this mode is assumed to lock to the center of the field-of view when
the command is received by the payload.
For each payload mode, in Message #200, the CUCS should at a minimum command
values for, and the UA should look for values in, the following Unique IDs:

Angle Relative to UA: Unique ID 0200.05 Set Centreline Azimuth Angle and
Unique ID 0200.06 Set Centreline Elevation Angle
A3 - 103
Edition A Version 1
AEP-84.1






Slewing Rate Relative to UA: Unique ID 0200.09 Horizontal Slew Rate and
Unique ID 0200.10 Vertical Slew Rate
Slewing Rate Relative to Inertial: Unique ID 0200.09 Horizontal Slew Rate and
Unique ID 0200.10 Vertical Slew Rate. Maintaining consistent Unique ID
0200.11 Latitude, Unique ID 0200.12 Longitude, Unique ID 0200.13 Altitude,
and Unique ID 0200.14 Altitude Type with Unique ID 0200.09 and Unique ID
0200.10 can aid in stabilization of the payload.
Lat-Long Slaved: Unique ID 0200.11 Latitude, Unique ID 0200.12 Longitude,
Unique ID 0200.13 Altitude, and Unique ID 0200.14 Altitude Type.
Target Slaved (Track): N/A
Reserved: N/A
Payload-Specific: All values in the Message #200 specifically intended to steer
the payload (Unique IDs 0200.05, 0200.06, 0200.09-14) should be consistent
within the Message #200 as sent by the CUCS. This enables the UA to pickand-choose the values it needs to listen for.
If there’s a need to support payload-specific modes, then the CUCS developer should
develop for the most general case of ensuring that Message #200 accurately reflects
the operator intent. The developer might desire to develop to the more specific cases
of the standard pointing modes first (to understand the requirements associated with
Message #200), and then proceed from there.
The UA is responsible for ignoring the commanded parameters in Message #200 which
do not correspond to the pointing mode which its payload is in.
A3.1.6.7.2 Location
The following fields permit the CUCS to command the steerable payload starepoint for
a selected point of interest. For an EO/IR payload, the commanded fields are
necessary for the pointing mode Lat-Long Slaved.
A3.1.6.7.2.1 Latitude
0200.11
12
Latitude
Commanded Stare
Point latitude: Latitude
of centre of FOV
Double
rad
-π/2 ≤ x ≤ π/2
0302.16
16
Latitude
of image centre
Double
rad
-π/2 ≤ x ≤ π/2
Unique ID 200.11 Latitude commands the latitude of the starepoint, which is the
latitude of the center of the field-of-view, while Unique ID 0302.16 Latitude reports the
latitude of the image center when the message is sent by the UA. There is no way to
report the commanded latitude.
A3.1.6.7.2.2 Longitude
0200.12
13
Longitude
Commanded Stare
Point longitude:
Longitude of centre of
FOV
Double
rad
-π ≤ x ≤ π
A3 - 104
Edition A Version 1
AEP-84.1
0302.17
17
Longitude
of image centre
Double
-π ≤ x ≤ π
rad
Unique ID 200.11 Longitude commands the longitude of the starepoint, which is the
longitude of the center of the field-of-view, while Unique ID 0302.17 Longitude reports
the longitude of the image center when the message is sent by the UA. There is no
way to report the commanded longitude.
A3.1.6.7.2.3 Altitude
0200.13
14
Altitude
Altitude of centre of
FOV
Float
m
-1,000 ≤ x ≤ 100,000
0200.14
15
Altitude Type
Defines altitude type
(reference frame) for
all altitude related
fields in this message.
Unsigned
1
Enumerate
d
0 = Pressure Altitude
1 = Baro Altitude
2 = AGL
3 = WGS-84
0302.18
18
Altitude
Distance above (+) or
below (-) the WGS-84
reference geoid of
image centre
Float
m
-1,000 ≤ x ≤ 100,000
Unique IDs 0200.13 Altitude and Unique ID 0200.14 Altitude Type command the
altitude for the center of the field-of-view and the altitude type (reference frame) of the
steerable payload, while Unique ID 0302.18 Altitude reports the altitude of the center
of field-of-view when the message is sent by the UA. There is no way to report the
commanded altitude.
In the context of an EO/IR payload, Unique IDs 0200.13 and 0200.14 should command
the WGS-84 altitude as the only value which can be statused is the WGS-84 altitude
of the point. The CUCS could provide the option also to set an AGL altitude type; where
it does so it should probably convert and subsequently send the altitude as a WGS-84
altitude. The CUCS should probably not support the options for pressure altitude and
baro altitude in this context. It is believed that the WGS-84-only option in Unique ID
0302.18 is correlated to the same value in the MISB metadata (i.e., that the MISB
metadata requires the WGS-84 datum.)
A3.1.6.7.2.4 Image Position (Location Validity)
0302.15
15
Image Position
Unsigned 1 Enumerated
Indicates when the
latitude, longitude and
altitude fields are filled
with valid data
0 = Fields 16,
17, and 18 Not
Valid
1 = Fields 16,
17, 18 Valid
0302.15 Image Position is a report-only data item which indicates whether the UA
believes the data associated with fields 16, 17, and 18 (Unique IDs 0302.16, 0302.17,
0302.18) are valid data. This can aid the CUCS in making a decision whether it should
calculate the payload’s present starepoint based on the provided exact locations or
whether it should calculate the payload’s present starepoint based on the reported
A3 - 105
Edition A Version 1
AEP-84.1
steering angles. The UA might send it in the case where the payload does not know
locations (i.e., it has no or limited DTED internal for the location of interest), or where
the payload is pointing over the horizon.
A3.1.6.7.3 Focus
0200.15
16
Set Focus
Applies to the
Addressed Sensor
specified in Message
#201.
Unsigned
1
Enumerated 0 = No Change
1 = Focus Closer
2 = Focus Farther
0200.16
17
Focus Type
Applies to the
Addressed Sensor
specified in Message
#201.
Unsigned
1
Enumerated 0 = Auto
1 = Manual
Unique ID 0200.15 Set Focus and Unique ID 0200.16 Focus Type are command-only
data items intended exclusively for EO/IR payloads which provide control over the
focus state of the payload.


Unique ID 0200.16 enumeration 0 = Auto: Commands the payload to refocus
itself automatically. 0200.15 should be ignored by the VSM in this case; Unique
ID 0200.15 should be sent by the CUCS as 0 = No Change.
Unique ID 0200.16 enumeration 1 = Manual: Commands the payload to focus
itself according to the commanded value of Unique ID 0200.15.
o Unique ID 0200.15 enumeration 0 = No Change: Commands the
payload to stop changing its focus level and then to maintain that focus
level until commanded otherwise, either by a change in Unique ID
0200.15 or Unique ID 0200.16.
o Unique ID 0200.15 enumeration 1 = Focus Closer: Commands the
payload to increase its focus level until commanded otherwise, either
by a change in Unique ID 0200.15 or Unique ID 0200.16.
o Unique ID 0200.15 enumeration 2 = Focus Farther: Commands the
payload to decrease its focus level until commanded otherwise, either
by a change in Unique ID 0200.15 or Unique ID 0200.16.
SAR payloads should ignore these fields and should configure them accordingly. A
CUCS controlling a SAR payload should send these values as 0 regardless. Fixed
camera payloads may have a mixed level of support and should configure them
accordingly.
According to the field descriptions of Unique ID 0200.07 and Unique ID 0200.08, these
should be applied to the sensor specified in Message #201; there are timing issues
with this approach—how does a VSM know that the Message #200 it received was
applicable to an earlier (or later) received Message #201?
A3.1.6.7.4 Zoom and Field of View
The CUCS can command two methods to control the zoom level of the payload.
A3 - 106
Edition A Version 1
AEP-84.1
For payloads with discrete zoom levels (in particular, IR sensors and their integrated
payloads), the VSM is responsible for stepping the zoom based on the CUCScommanded values.
0200.17
7
Set Zoom
Unsigned
Allows control of the
1
payload zoom by
either requesting a
specific angle or by
requesting the payload
to zoom in or out until
commanded to stop
Enumerated
0 = Use Set
Horizontal & Vertical
Field Of View
1 = Stop Zoom
2 = Zoom In
3 = Zoom Out
0200.07
8
Set Horizontal Field
of View
Applies to the
Addressed Sensor
specified in Message
#201.
Float
rad
0 ≤ x ≤ 2π
0200.08
9
Set Vertical Field of
View
Applies to the
Addressed Sensor
specified in Message
#201.
Float
rad
0 ≤ x ≤ 2π
0302.11
11
Actual Vertical Field
of View
Float
rad
0 ≤ x ≤ 2π
0302.13
13
Actual Horizontal
Field of View
Float
rad
0 ≤ x ≤ 2π
Unique IDs 0200.17 Set Zoom is a command-only data item which commands the
payload to use the zoom method specified in the data item.
Unique IDs 0200.07 Set Horizontal Field of View and Unique ID 0200.08 Set Vertical
Field of View commands the payload to distinct FOV settings, and Unique ID 0302.11
Actual Vertical Field of View and Unique ID 0302.13 Actual Horizontal Field of View
report the present vertical and horizontal fields of view.



Unique ID 0200.17 enumeration 0 = Use Set Horizontal & Vertical Field Of View
commands the UA to use the values in Unique ID 0200.07 and Unique ID
0200.08. The UA should ignore Unique ID 0200.07 and Unique ID 0200.08
when Unique ID 0200.17 is set to enumeration 0 but should continue to report
its actual field of view in Unique ID 0302.11 and Unique ID 0302.13.
Unique ID 0200.17 enumeration 1 = Stop Zoom: Commands the payload to
stop changing its zoom level and then to maintain that zoom level until
commanded otherwise by a change in Unique ID 0200.17.
Unique ID 0200.17 enumeration 2 = Zoom In: Commands the payload to
increase its zoom level until commanded otherwise by a change in Unique ID
0200.17.
A3 - 107
Edition A Version 1
AEP-84.1

Unique ID 0200.17 enumeration 3 = Zoom Out: Commands the payload to
decrease its zoom level until commanded otherwise by a change in Unique ID
0200.17.
Configuration for Unique IDs 0200.07 and 0200.08 are found in Message #301. See
A3.1.6.2.2.3 Field of Regard Minimums and Maximums.
According to the field descriptions of Unique IDs 0200.07 and 0200.08, these should
be applied to the sensor specified in Message #201; there are timing issues with this
approach, as a VSM cannot know (it can assume) that the Message #200 it received
was applicable to an earlier (or later) received Message #201.
For payloads with discrete levels of zoom (i.e., IR payloads), Unique ID 0200.17
enumerations 2 and 3 should be interpreted the same as if the payload had smooth
levels of zoom (i.e., the zooming should be continuous).
For fixed aspect ratio payloads, the UA should ignore commands for either Unique ID
0200.07 or Unique ID 0200.08, but not both. The CUCS should always send what it
understands to be the commanded field of view in both fields, and the VSM should
report what it understands to be the actual field of view in both fields, as the CUCS
does not and should not know that the payload is necessarily fixed aspect ratio.
SAR payloads should ignore the commanded fields and should configure them
accordingly. A CUCS controlling a SAR payload should send these values as 0
regardless, though a CUCS may have interest in the reported actual field of view for a
SAR payload. Fixed camera payloads may have a mixed level of support and should
configure them accordingly.
A3.1.6.7.5 Steering Angles
0200.05
5
Set Centreline
Float
Azimuth Angle
+ right of aircraft x axis
rad
-π ≤ x ≤ π
0200.06
6
Set Centreline
Elevation Angle
+ above aircraft
waterline
Float
rad
-π ≤ x ≤ π
0302.10
10
Actual Centreline
Elevation Angle
+ above aircraft
waterline
Float
rad
-π ≤ x ≤ π
0302.12
12
Actual Centreline
Azimuth Angle
+ right of aircraft axis
Float
rad
-π ≤ x ≤ π
0302.14
14
Actual Sensor
Rotation Angle
+ Clockwise rotation
from aircraft normal
(Up)
Float
rad
-π ≤ x ≤ π
A3 - 108
Edition A Version 1
AEP-84.1
Unique ID 0200.05 Set Centreline Azimuth Angle and Unique ID 0200.06 Set
Centreline Elevation Angle command the payload pointing direction relative to the body
axes of the UA in the azimuth and elevation directions, while Unique ID 0302.10 Actual
Centreline Elevation Angle and Unique ID 0302.12 Actual Centreline Azimuth Angle
report the actual angles. Unique ID 0302.14 Actual Sensor Rotation Angle reports the
field-of-view with respect to the UA horizon, where zero rotation signifies the UA
horizon is parallel to the image horizontal FOV. The VSM is responsible for converting
these Message #200 data items for the orientation of the payload relative to the UA,
the mounting, and the type of the payload.
For a conventional 2-axis tilt-over-pan mount with the mount aligned to the UA
reference axes, the pointing angles are:



Centreline azimuth = Pan
Centreline elevation = Tilt
Camera rotation = 0
For other types of camera mounts, the VSM must derive these angles based on the
characteristics of that mount. For a tilt-over-roll camera mount, where roll is the outer
gimbal axis and is parallel to the roll axis of the UA (platform roll measured positive if
the mount is rolled to the left of the UA body) and the inner gimbal axis is in the foreaft direction (with 0 corresponding to forward-looking and -PI/2 corresponding to
down), the following transformations apply:



Centreline azimuth = atan2 (sin (roll)*sin (tilt), cos (tilt))
Centreline elevation = asin (cos (roll)*sin (tilt))
Camera rotation = atan2 (sin (roll), cos (roll)*cos (tilt))
where the atan2 (y, x) function computes the principal value of the arc tangent of y/x,
using the signs of both arguments to determine the quadrant of the return value.
For an EO/IR payload, the Message #200 fields should be correctly populated while in
the Angle Relative to UA pointing mode.
A3.1.6.7.6 Slew Rates
0200.09
10
Horizontal Slew Rate
+ Slew FOV right
Float
rad/s
-2π ≤ x ≤ 2π
0200.10
11
Vertical Slew Rate
+ Slew FOV up
Float
rad/s
-2π ≤ x ≤ 2π
Unique ID 0200.09 Horizontal Slew Rate and Unique ID 0200.10 Vertical Slew Rate
are command-only data items which command the payload to rotate at the rate and in
the direction provided by these data items. These commands are relative to the
payload’s axes and not the UA body axes. For an EO/IR payload, this is per operator
expectation; the operator expects the displayed video to move in the horizontal axis on
when the operator attempts to move it to the right at the HCI; similarly in the vertical
axis. No additional math is necessary for this functionality.
For an EO/IR payload, these fields should be correctly populated while in the Slewing
Rate Relative to UA or Slewing Rate Relative to Inertial pointing modes.
A3 - 109
Edition A Version 1
AEP-84.1
For both a tilt-over-roll mount and a tilt-over-pan mount, the VSM should translate
Unique ID 0200.10 to the tilt control and Unique ID 0200.09 to the roll/pan control
respectively.
Slew rate should be configured using Message #1301 for the fastest slew rate that the
payload will support. Payloads which have variable maximum slew rates should
configure the CUCS for the absolute maximum slew rate, and when the VSM receives
a command for the absolute maximum slew rate, it should proportionally adjust the
commanded slew rate for the payload.
A3.1.6.7.7 Fixed Camera
A UA reporting that it has a fixed camera in Unique ID 0300.07 and a CUCS supporting
that camera type, per Table 4 – 6 in Section 4.1 of AEP-84 Volume I is expected to
provide the same level of control as with an EO/IR payload, except in the following
circumstances:


In Message #200 and for matching status in Message #302, the data items
applicable to a fixed camera are Unique IDs 0200.07, 0200.08, 0200.150200.17. A UA can configure the other fields out of Message #200 should the
developer feel it’s necessary, and should ignore those same fields, regardless.
In Message #201 and for matching status in Message #302, the data items
applicable to a fixed camera are Unique IDs 0201.05-0201.09, 0201.11-16. For
unmatched status in Message #302, Unique ID 0302.21 is applicable.
A3.1.7 IFF Command and Status
A3.1.7.1 MESSAGE #1500: IFF/SSR Code Command Implementation
Message #1500 provides the capability to control the Identify Friend or Foe (IFF)
and/or Secondary Surveillance Radar (SSR) equipment located on board the UA from
the CUCS. It is recommended that all the functionality available for IFF/SSR control
from the CUCS be placed within a dedicated dialog, in conjunction with the associated
status as received from the VSM in the IFF/SSR Status Report Message (Message
#1600). It is recommended that this message only be sent from the CUCS to the VSM
to change the state of any of the controlled parameters within the message, as the
message is large.
Upon reception of the IFF/SSR Code Command (Message #1500) from the CUCS, the
VSM is required to immediately send the required command states to the IFF/SSR
equipment on board the UA.
Message #1500 permits individual enabling and disabling of Modes 1, 2, 3/A, C, 4, S,
and 5. Transponder codes are encoded in the message as described in AEP-84
Volume I Section 4.1.9.1.
Mode S parameters are defined in ICAO Annex 10 to the Convention on International
Civil Aviation, Volume IV. This document should be consulted for details on Mode S
functionality and capabilities.
Mode 5 parameters are defined in STANAG 4193. This document should be consulted
for details on Mode 5 functionality and capabilities.
One aspect of Mode 5 capability is the use of an extended (two-byte) Mode 1 code. If
this code is used, then the equivalent short (one-byte) Mode 1 code is implicitly
embedded within the extended code, as defined in STANAG 4193. If both the short
A3 - 110
Edition A Version 1
AEP-84.1
and long forms of the Mode 1 codes are sent in one instance of Message #1500, then
the CUCS must ensure that the short Mode 1 code is properly embedded in the long
Mode 1 code. The embedding is as follows:
The 3 high-order bits of the Extended Code make up the 3 high-order bits of the legacy
Mode 1 code. The 5th and 6th high-order bits of the Extended Code make up the 5th
and 6th high-order bits of the legacy Mode 1 code. The 4th high-order bit of the legacy
Mode 1 code (as with all Mode 1 codes) is 0. For example:
Extended Code
Legacy Code
7777
73
5432
50
3375
33
Sample C code that would calculate the correct legacy code to put into Unique ID
1500.04 given a value for Unique ID 1500.19:
legacyCode = (extendedCode >> 6) & 0x3B;
Unique ID 5000.03 in either message may be up to eight characters, although many
countries only allow seven characters. The desired Aircraft ID should be left-justified,
and unused characters up to (but not including) the null terminator should be filled with
spaces (hex 0x20). Only numeric and capital alphabetical characters are permitted.
Unique ID 1500.20 is two bytes long to accommodate a potential change to the Mode
5 encoding for National Origin. The current STANAG 4193 allows for up to 31 different
values, but the most recent NATO country code table have values up to 99.
A3.1.7.2 Message #1501: IFF/SSR Identification of Position Command
Implementation
When the CUCS sends this command, it is the equivalent of a pilot pressing the
Identification of Position (I/P) button on the physical IFF/SSR control panel. This
causes the transponder to add a special code to the normal response code, and
transmit the code for an implementation-specific period of time. This is the expected
vehicle response when Message #1501 is received by the VSM.
If the IFF/SSR subsystem on the UA supports premature suppression of the I/P
transmission, then the CUCS may send Message #1501 with Unique ID 1501.4 set to
0 (Normal) to command that suppression.
A3.1.7.3 Message #1502: IFF Key Control Command Implementation
When the CUCS sends this command, the VSM is expected to immediately take the
indicated action on the cryptographic keys within the IFF subsystem on the UA.
If the CUCS is attempting only to switch the Mode 4 key from A to B (or vice versa),
then Unique IDs 1502.05 (Hold) and 1502.06 (Zeroize) should be set to 0 (No Change).
For the Hold command (Unique ID 1502.05), the Hold state of Modes 4 and 5 is
expected to be as commanded in the most recent message received. Specifically,
setting Unique ID 1502.05 to 2 (Mode 5 Hold) is expected to have the effect that Mode
5 Hold is active and Mode 4 Hold is cleared.
For the Zeroize command (Unique ID 1502.06), the action to clear the indicated keys
is expected to take place with no additional delay.
A3 - 111
Edition A Version 1
AEP-84.1
A3.1.7.4 Message #1503: IFF/SSR Bit Command Implementation
This message provides the capability to initiate the Built-In Test (BIT) functionality of
the IFF/SSR subsystem on the UA. It is assumed that a BIT must run to completion,
so there is no option to cancel an on-going BIT. The use of 0 (No Change) in Unique
ID 1503.04 (IFF/SSR BIT Command) should produce no action in the VSM (it is
included for consistency).
A3.1.7.5 Message #1600: IFF/SSR Status Report Implementation
It is recommended that the CUCS provide a display for each of the parameters as
contained within the IFF/SSR Status Report Message. Upon reception of the IFF/SSR
Status Report Message at the CUCS from the VSM, the CUCS should immediately
update the state of each of the parameters within the display. It is recommended that
the IFF/SSR status displays be collocated with their associated commanded values,
as sent to the VSM in the IFF/SSR command Messages (#1500, #1501, #1502, and
#1503).
The CUCS may pull this message from the VSM to update the status of the IFF/SSR
parameters at the CUCS. Upon a request for this message from the CUCS, the VSM
is required to populate the IFF/SSR Status Report Message with the most recent
equipment status, potentially through an UA query, and then immediately transmit this
message to the CUCS.
It is recommended that this message also be sent by the VSM in the following cases:

Receipt of a properly formatted and valid IFF/SSR Code Command (Message
#1500) and successful completion of the actions required by that message

Receipt of a properly formatted and valid IFF/SSR Identification of Position
Command (Message #1501) and successful completion of the actions required
by that message

Termination of transmission of Identification of Position (I/P) after the systemspecific duration has expired

Receipt of a properly formatted and valid IFF Key Control Command (Message
#1502) and successful completion of the actions required by that message

Receipt of a properly formatted and valid IFF/SSR BIT Command (Message
#1503) and successful completion of the actions required by that message

Completion of a BIT initiated by a valid IFF/SSR BIT Command (Message
#1503)
Details about specific Unique ID/fields can be found in Chapter 4 of AEP-84 Volume I.
A3.1.8 Handover Logic
CUCS Authorisation Request (Message #1) and the VSM Authorisation Response
(Message #21) messages are used to initiate and monitor the handover process. For
handover using a single data link, Vehicle Data Link Transition Coordination Message
(Message #600) is used to switch the connection of the UA data link (VDT) from the
Relinquishing CUCS to the Acquiring CUCS.
A3.1.8.1 Handover Using 2 Data Links
Handovers utilizing two separate data links can provide for transfer of control without
an intermediate “lost link” to the UA. Handovers of this type are also known as a “Make
Before Break” or “positive control” handovers. By using two data links, LOI 3 and 4
A3 - 112
Edition A Version 1
AEP-84.1
control can be passed from a “Relinquishing CUCS” to an “Acquiring CUCS” using
standard discovery, configuration, and control request messages. No specialized
handover messages are required.
A3.1.8.1.1 Assumptions

The UA that is the subject of the handover has 2 bi-directional data links; one
communicating with the Relinquishing CUCS, the control or primary link and
one communicating with the Acquiring CUCS referred to as the secondary link.

The Acquiring CUCS is configured to communicate with the UA using
compatible port numbers and IP addresses.

The current controlling (i.e., primary) link maintains positive control of the UA
during the handover sequencing.

The Acquiring CUCS has established connection to its CDT links.
A3.1.8.1.2
Pre-Handover
The Relinquishing CUCS UA System Operator (USOP) establishes communication
with the Acquiring CUCS UA System Operator (USOP) and transmits the following
information/data:

UA tail number/ID

Current mission the UA is executing

UA position, altitude, heading, and estimated start time of Handover (H/O)

If necessary, inform ATC of H/O

Frequencies, CDL profile and COMSEC keys to establish a functional data link
with the UA to be handed over

Relinquishing CUCS configures the UA secondary VDT per agreed upon data
terminal characteristics;
In response, the Acquiring CUCS USOP performs the following actions:

Calculates and sets Control System (CS) D/L antenna position to the estimated
UA position at H/O

Acquiring CUCS configures the CDT to communicate with the UA secondary
VDT

If necessary, contact ATC to inform of H/O and for area traffic update

Inform the Relinquishing CUCS that it is ready to begin the H/O transition
A3.1.8.1.3 Handover Sequence
There are four phases involved in managing a connection between a CUCS and a
VSM/UA/Payload Station entities.
The phases are:
A3 - 113
Edition A Version 1
AEP-84.1




Discovery
Downloading Configuration Data
Requesting LOI Connection
Release
During these phases the CUCS will discover an entity and its capabilities. If the entity
is a VSM, UA or Payload Station, the operator can then choose to establish one (or
more) LOI connection(s) with the entity. If the entity is a data terminal, the CUCS only
has the ability to request full control of it. There are no LOIs between a CUCS and a
data terminal.
A3.1.8.1.3.1 Discovery
The Acquiring CUCS performs Discovery of the UA Vehicle per standard procedures
described in Section A3.1.2.3.1 Connection Phase 1: Discovery, of this document.
A3.1.8.1.3.2 Downloading Configuration Data
The Acquiring CUCS configures itself for the desired LOI 3/4 of the UA/payload per
procedures in Section A3.1.2.3.2 Connection Phase 2: Downloading Configuration
Data. [This step may be skipped if the Acquiring CUCS has preconfigured for LOI 3/4
of the UA.]
A3.1.8.1.3.3 Requesting LOI Connection
For LOI 3/4 Control, the Acquiring CUCS requests LOI 3/4 Override Control of the
UA/payload per the procedure described in Section A3.1.2.3.3, Connection Phase 3:
Establish Connection. Both the Relinquishing and Acquiring CUCS will be notified of
the results via Message #21.
A3.1.8.1.3.4 Release LOI Control
A connection between a CUCS and an entity can be released for reasons such as:




The CUCS requests the connection to be released
The entity spontaneously releases the connection
Another CUCS requests to override the connection
The CUCS hands control over to another CUCS
Section A3.1.2.3.4.1, Releasing an LOI Connection for VSMs, UA and Payload
Stations, in this document provides the sequence for release of LOI control of an Entity.
A3.1.8.2
Handover Using a Single Data Link
Payload only handover cannot occur separately from the vehicle using only a single
data link. A UA with a single data link, such as a STANAG 7085 compliant link, can
only support uplink communication (UA/payload commands) with one CUCS at a time;
thus control of both the UA (LOI 4) and payload (LOI 3) are possible. A procedure for
this type of handover, sometimes called “throw and catch” is outlined in the following
paragraphs.
A3.1.8.2.1
Assumptions

The Acquiring CUCS is configured to communicate with the UA using
compatible port numbers and IP addresses

The Acquiring CUCS has established connection to its CDT links
A3 - 114
Edition A Version 1
AEP-84.1
A3.1.8.2.2
Pre-Handover
Same as for dual link, Section A3.1.8.1 above
A3.1.8.2.2
Handover Sequence

The Relinquishing CUCS sends Message #600 with the Data Time Out Limit
set to a value “T1” >0. This commands the UA to drop the CDL connection with
the Relinquishing CUCS and point the antenna to the location indicated in
Message #600.

Upon establishing a CDL connection with the UA, the Acquiring CUCS requests
LOI 4 Override Control of the UA per the procedure described in Section
A3.1.2.3.3, Connection Phase 3: Establish Connection.

The UA verifies the CUCS ID in Message #1 of the Acquiring CUCS matches
the ID received in Message #600. If the ID does not match the expected ID
(from Message #600 of the Relinquishing CUCS), the UA continues to wait until
the end of the timeout period for response from the proper CUCS.

If the IDs match, the UA transmits Message #700, “Handover Successful" to
the Acquiring CUCS, indicating that the datalink and LOI connection has been
established and the Acquiring CUCS is in control of the UA.

If on the other hand, after waiting the Data Link Time-Out Limit “T1” the
handover does not succeed, the UA points its antenna back to the
Relinquishing CUCS and transmits the Handover Status Report (Message
#700) with the Status set to “Handover Failed”.

If successful, the Acquiring CUCS can then continue with discovery of
payloads, configuration, etc.
A3.1.8.3 Payload Handover Using a Share Data Link
Handover of payloads where a data link transition is not required uses only the CUCS
Authorization Request Message #1 and the VSM Authorization Response Message
#21. Details of payload discovery and configuration are described in Section
A3.1.2.3.1 of this Annex.
The CUCS attempting to acquire control over a specific payload first sends the CUCS
Authorization Request Message #1, setting the Requested/Handover LOI value to
LOI3 and all applicable lower LOIs which in this case is 0x03 (LOI2+LOI3), setting the
Controlled Station value to the value of the payload for which it is attempting to acquire
control, and setting the Controlled Station Mode value to 1 = Request Control.

Taking Control of an Available Payload: If the requested payload is
available for control by the requesting CUCS, the VSM/UA sends the VSM
Authorization Response Message #21, setting the CUCS ID to the
requesting CUCS, setting the LOI Granted value 0x03 (LOI2+LOI3), setting
the Controlled Station value to the value of the requested payload and
setting the Controlled Station value to 1 = In Control.

Attempting Control of an Unavailable Payload: If the requested payload
is not available for control by the requesting CUCS, the VSM/UA sends the
VSM Authorization Response Message #21, setting the CUCS ID to the
requesting CUCS, setting the LOI Granted value 0x00 = N/A, setting the
Controlled Station value to the value of the requested payload and setting
the Controlled Station value to 0 = Not In Control.
A3 - 115
Edition A Version 1
AEP-84.1

Acquiring Control of a Payload in use by Another CUCS: If the
requested payload is not available for control by the requesting CUCS
because it is in use by another CUCS, the acquiring CUCS may attempt to
override control and wrest the payload away from the CUCS currently in
control. If the currently controlling CUCS has sent the CUCS Authorization
Request Message #1 with the Controlled Station Mode for the requested
payload to a value of 2 = Override Control, then the attempted override by
the CUCS attempting to wrest control from the currently controlling CUCS
will fail and the Message #21 from the prior paragraph will be sent.
Otherwise, the acquiring CUCS sends the CUCS Authorization Request Message #1,
setting the Requested/Handover LOI value to LOI3 and all applicable lower LOIs which
in this case is 0x03 (LOI2+LOI3), setting the Controlled Station value to the value of
the payload for which it is attempting to acquire control, and setting the Controlled
Station Mode value to 2 = Override Control. The VSM/UA sends two VSM
Authorization Response Messages #21. The first message is sent to the CUCS that
has lost control of the payload setting the CUCS ID to the relinquishing CUCS, setting
the LOI Granted value to either 0x00 = N/A or 0x01 = LOI 2, setting the Controlled
Station value to the value of the requested payload and setting the Controlled Station
Mode value to 0 = Not In Control. The second message is sent to the CUCS that has
taken away control of the payload setting the CUCS ID to the acquiring CUCS, setting
the LOI Granted value 0x03 (LOI2+LOI3) , setting the Controlled Station value to the
value of the requested payload and setting the Controlled Station Mode value to 1 = In
Control.
A3.1.9 Virtual Vehicle Logic
In some implementations the CUCS needs to communicate with the VSM before the
VSM has established a link with a UA. This is typically so that the operator can perform
setup in the VSM and may also involve pre-downloading the Configuration Data for the
UA that the CUCS intends to control. For example, the VSM may provide a Remote
Display to allow the operator to indicate which payloads are installed on the UA or to
setup the data link parameters to communicate with the UA.
If the VSM does not know the Vehicle ID of the UA in advance, it can use a Logical
Vehicle ID in place of the Real Vehicle ID. A Logical Vehicle ID has a country code of
0 so a valid ID is in the range:
00:00:00:00 < Logical Vehicle ID <= 00:FF:FF:FF
When the VSM discovers the real UA it can use the Real Vehicle ID instead of the
Logical Vehicle ID. Before it switches to the new ID, however, the VSM needs to
notify the CUCS of the ID change by sending Message #20:
Unique
ID
Name
Value
0020.02
Vehicle ID
<Logical Vehicle ID>
0020.03
CUCS ID
<CUCS ID>
0020.04
VSM ID
<VSM ID>
A3 - 116
Edition A Version 1
AEP-84.1
0020.05
Vehicle ID Update
<Real Vehicle ID>
All future messages from the VSM will use the Real Vehicle ID instead of the Logical
Vehicle ID when referring to this UA. Note that this includes messages for any payload
stations or data links that were pre-configured with the Logical Vehicle ID.
It is highly recommended that VSMs use the acknowledgement system to ensure that
this message is received by each CUCS that has an LOI granted. If a CUCS does not
receive this message, it will likely continue to listen for messages addressed from the
Logical Vehicle ID instead of the Real Vehicle ID.
The Vehicle ID Update field (Unique ID 0020.05) should not be used to change a Real
Vehicle ID to another Real Vehicle ID. A VSM can change the Real Vehicle ID back
to a Logical Vehicle ID to indicate that the VSM is no longer configured to communicate
with the Real UA. The CUCS can use this event to prepare for communicating with a
new Real UA.
If a VSM supports multiple types of vehicles, it can report a Logical Vehicle ID for each
Vehicle Type/Subtype combination. If the VSM can only grant control for one of these
variations at a time, it can send a Message #21 for all other Logical Vehicle IDs with
LOI Authorized (Unique ID 0021.06) set to ”0x00=Connection Not Authorised” when it
grants LOI for one Vehicle Type/Subtype.
To illustrate the use of a Virtual Vehicle, consider the following scenario:
Stage 1: Initial connection between CUCS and VSM without UA
Virtual UA
ID=0.0.0.1
Type=10
Subtype=1
VSM
CUCS
STANAG 4586 DLI
In Stage 1, the VSM has not established a link with a UA, but it can still provide the
discovery and configuration messages for a virtual vehicle by using the Logical Vehicle
ID in the appropriate messages. This approach can work if the VSM knows the
configuration of the vehicles it can control in advance.
A3 - 117
Edition A Version 1
AEP-84.1
VSM
CUCS
Message #1 Broadcast Request
Message #21 (VehicleID=0.0.0.1, Type=10, Subtype=1)
Message #1200 Download Configuration (VehicleID=0.0.0.1)
Message #130x Configuration Messages (VehicleID=0.0.0.1)
Message #1203 Config Complete
(VehicleID=0.0.0.1, Type=10, Subtype=1)
Message #1 Request Control (VehicleID=0.0.0.1, LOI=LOI5)
Message #21 (VehicleID=0.0.0.1, LOIGranted=LOI5)
The CUCS can establish LOI control of the VSM at this stage so that the VSM can
present its Remote Displays.
Stage 2: Data Link is manipulated to communicate with UA
Virtual UA
ID = 0.0.0.1
Type=10
Subtype=1
VSM
CUCS
STANAG 4586 DLI
Proprietary Data Link protocol*
In Stage 2 of this example, the VSM communicates with the data link in preparation for
communicating with a vehicle. This could be a result of operator interaction with the
VSM’s Remote Displays.
* Note that in this example the VSM communicates with a CDT using a proprietary
protocol (such as a command line or REST interface). There are other ways to
accomplish this such as using the Data Link DLI messages or private messages.
Stage 3: VSM Establishes Connection with Real UA
A3 - 118
Edition A Version 1
AEP-84.1
Real UA
ID=32.4.1.1
Type=10
Subtype=1
Tail=”TN039
”
VSM
CUCS
STANAG 4586 DLI
Proprietary UA protocol
In Stage 3, the VSM discovers which UA it is controlling and updates the CUCS with
the new Real Vehicle ID with Message #20.
VSM
CUCS
UA
[Proprietary]
Establish
connection
Message #20
(VehicleID=0.0.0.1,
VehicleIDUpdate=32.4.1.1,
Type=10, Subtype=1,
Tail Number=”TN039”)
[Proprietary]
Send UA
Status
Message #101 Inertial States
(VehicleID=32.4.1.1)
All future messages between the CUCS and the VSM regarding this UA should use
the new Vehicle ID.
VSM
CUCS
Message #44 Unmanned Aircraft
Lights (VehicleID=32.4.1.1)
UA
[Proprietary]
Set the Light
[Proprietary]
Report Light
Status
Message #107 Vehicle Lights
Report (VehicleID=32.4.1.1)
A3 - 119
Edition A Version 1
AEP-84.1
A3.2 Description and Implementation of DLI Messages
A3.2.1 System ID
A3.2.1.1 Message #1: CUCS Authorisation Request CUCS Implementation
This message is used by a CUCS to request a connection to a VSM for a specific
Vehicle ID, at a specific LOI, or it is used by a CUCS to make a general inquiry on the
network to which it is attached to determine what VSMs are attached to the network,
and what are the capabilities of these VSMs. This message is also used to release
control or override control of a specific Vehicle ID by the CUCS. Therefore this
message has a few distinct usages. The response to this message is from a VSM
using Message #21, VSM Authorization Response.
The CUCS ID is a field located in all of the STANAG 4586 formatted DLI messages,
and in this message identifies the CUCS making the request to the VSM. The VSM
should populate the CUCS ID field of the formatted DLI message response (Message
#21) with the CUCS ID as received from the CUCS in the CUCS Authorisation Request
(Message #1). When a VSM authorizes control to a CUCS for the UA/payload, it
should be based on the CUCS ID contained in the CUCS Authorization Request
Message. Once a CUCS has control of a UA/payload, the VSM thereafter filters all
control messages for that functionality based on the authorized CUCS ID, and
addresses all the required status messages to that CUCS ID.
For UA or payload control requests, this message is sent by a CUCS to a VSM to
request a connection to the VSM, for a specific Vehicle ID, at a specific (requested)
LOI, for a specific vehicle type and subtype, potentially for a specific payload station
(dependent on LOI), the Vehicle ID and all other fields in the message are correctly
filled. If more than one payload station authorisation is needed, this message may be
used to identify all the stations at one time. Where a CUCS does not receive
authorization to control a UA or payload at a specific LOI, the CUCS is not to transmit
“command” messages to a Vehicle ID for that functionality.
When the CUCS is using this message to make a general inquiry for VSMs attached
to the network and their capabilities, the Vehicle ID field is filled with the broadcast
request ID (FF.FF.FF.FF). The other fields in this message can be set to create a filter
for specific functionality, or the Requested LOI field can be set to “Unspecified” and
therefore signify that all other fields are invalid.
The vehicle type and subtype fields are used to allow the CUCS to filter a broadcast to
request control of a particular vehicle type/subtype where there is more than one VSM
on the network to which the CUCS is attached, or a particular VSM supports more than
one vehicle type/subtype.
This message is designed to allow more than one CUCS to control a UA and payload
functions from a single logical VSM.
A CUCS controlling a UA at LOI 4 or 5 will maintain UA control until either it relinquishes
control, or is displaced by another CUCS that is asserting override while the current
CUCS is not.
A3 - 120
Edition A Version 1
AEP-84.1
A CUCS controlling a payload at LOI 3 will maintain payload control until it either loses
the connection, specifically relinquishes control, or when the CUCS that has LOI 4 or
5 of the UA on which the payload(s) are located specifically requests control of that
payload. The UA operator is considered to be responsible for the UA, therefore may
remove control from an independent payload operator.
This message is used in conjunction with the Vehicle Data Link Transition Coordination
Message (Message #600) for a handover of a UA without handing over control of the
VSM to another CUCS (e.g., passing control of an UA from one VSM to another). This
message provides the authorisation for the handover of the UA, and identifies to the
UA whether or not it must wait for the Data Link Transition Coordination Message
before performing the transition.
Refer to Section A3.1.2.3 Entity Connection Management for
implementation details of the CUCS Authorization Request message.
additional
A3.2.1.2 Message #1: CUCS Authorisation Request VSM Implementation
This message is received at the VSM as sent by a CUCS to request a connection,
release connection, or override connection to the VSM for a specific Vehicle ID at a
requested LOI (UA/payload), for a specific vehicle type and subtype. If the CUCS does
not know the vehicles (VSMs) available on the network, the Vehicle ID will most likely
be filled with the Broadcast ID identifying that this is a general request for VSMs to
identify their capabilities to the CUCS, potentially filtered to a specific vehicle
type/subtype. If more than one payload station authorisation was requested, this
message may be identifying more than one station.
The VSM must correctly interpret the contents of the CUCS Authorization Request
Message as received from the CUCS, and respond with a Message #21, VSM
Authorization Response, corresponding to the request, either authorizing control for
the requested functionality, releasing control of the selected functionality, or allowing
an override of the selected functionality. Where the request was a Broadcast request,
the VSM responds with its capabilities, but does not authorize control over any of its
functionality.
A3.2.1.3 Message #20: Vehicle ID CUCS Implementation
This Vehicle ID message identifies specific details of the UA identified by the Vehicle
ID parameter contained in the message. Some of these parameters are duplicated
from other messages in order to provide this information in a comprehensive vehicle
identification message.
The STANAG 4586 allows the CUCS to request configuration messages from the
VSM/UA in advance of requesting a LOI from the VSM, and this is one of the possible
configuration messages that may be requested. However where a UA is not connected
to the VSM/system, this message does not provide any useful information above that
contained in Message #21, VSM Authorization Response Message.
It is recommended that these data elements be available for display to the operator in
a System Administration/Configuration dialog on the CUCS, for the UA that the CUCS
is either monitoring or controlling. Data elements of the configuration type are
recommended to be grouped.
A3 - 121
Edition A Version 1
AEP-84.1
A3.2.1.4 Message #20: Vehicle ID VSM Implementation
The Vehicle ID Message is created by the VSM/UA, and more comprehensively
identifies the UA that is controlled through the VSM. This message is only sent from
the VSM to the CUCS when requested by the CUCS for the specified Vehicle ID, or in
response to a general configuration request made for a specific Vehicle ID, for the UA
in particular. The VSM is developed for a specific vehicle type and subtype; therefore
these are specified by the VSM developer. Thus, certain data elements within this
message should not be operator configurable. These data elements are:
 Vehicle Type
 Vehicle Subtype
Other data elements contained in the Vehicle ID Message are dependent on the
specific UA, and they may vary by mission. These data elements include:
 Vehicle ID
 Owning Country ID
 Tail Number
 Mission ID
 ATC Call Sign
These data elements may be potentially operator enterable on the VSM through the
remote display capability. The Mission ID is set from a CUCS for a mission upload,
and is transmitted to the VSM using Message #800, Mission Upload Command. The
Mission ID identified in this message will report the Mission ID loaded on the UA, and
will reflect the uploaded Mission ID if an upload occurred from the same CUCS. This
message may be requested by the CUCS to get a confirmation that Mission ID was
uploaded correctly to the VSM/UA.
When the Vehicle ID Message is requested by the CUCS, all data elements within the
message should be appropriately populated and the message sent as expeditiously
as possible from the VSM.
When the VSM “message translation functionality” is located on the ground, it is
recommended that the Vehicle IDs are used as the VSM IDs. This message reports
the “tail number” that has been associated with a specific Vehicle ID when a UA is
attached/connected to the system. Where a VSM is capable of controlling more than
one “tail number” simultaneously, the VSM should be assigned the number of Vehicle
IDs corresponding to the number of UA that the VSM can control simultaneously, with
one “tail number” being assigned to one Vehicle ID.
A3.2.1.5 Message #21: VSM Authorisation Response CUCS Implementation
The VSM Authorisation Response Message is received at the CUCS as sent by the
VSM in response to Message #1, CUCS Authorisation Request Message. If the
request (enquiry) from the CUCS was a broadcast or for an unspecified LOI, the VSM
will respond with the available Vehicle ID(s), vehicle type/subtype information,
available payload stations, and the LOI that are authorised for the inquiring CUCS.
The response provides the CUCS with “information” on the capabilities of the VSM.
The LOI Authorized field identifies the maximum LOI that could be granted to the
CUCS. The LOI Authorized response does not pass control of the VSM to the CUCS.
A3 - 122
Edition A Version 1
AEP-84.1
The LOI Granted field will be filled with “N/A” for a Broadcast response. If the CUCS
requested a specific LOI in the Authorisation Request Message, it should be granted
control from the VSM over the specified functionality in this message unless the CUCS
is not authorized for control. Once the CUCS has received a “control” authorization
(LOI 3/4/5) for a UA and/or payload, it is authorized to transmit LOI 3/4 command
messages to the specific Vehicle ID.
The CUCS may receive this message to monitor the control status of the entire
UAS/network, where other CUCSs may be in control of portions of the system. This
allows all CUCSs connected to the VSM/UAS to monitor which CUCS(s) is in control
of the different components of the UA, the UA itself and/or its payload(s).
The CUCS may also receive this message to inform the CUCS that it is no longer in
control of a specified functionality, where another CUCS has overridden control of the
specified station.
The CUCS type and CUCS subtype fields can be used during a transfer from one
CUCS to another to inform the giving CUCS the type and subtype of the gaining CUCS.
To implement this function, the UA would send this message not only to the acquiring
CUCS, but also to the relinquishing CUCS. If the acquiring CUCS first requests monitor
mode, the relinquishing CUCS can determine if it should give up control of the UA to
the acquiring CUCS.
A3.2.1.6 Message #21: VSM Authorisation Response VSM Implementation
The VSM Authorisation Response Message is sent by the VSM in response to
Message #1, CUCS Authorisation Request Message, received from a CUCS. If the
request (enquiry) from the CUCS was a broadcast or for an unspecified LOI, and the
CUCS ID received in the message is for an authorized CUCS, the VSM responds with
the specific Vehicle ID(s), to include vehicle type/subtype information, and the LOI(s)
that are authorised for the enquiring CUCS.
The LOI Authorized field is used by the VSM to identify the maximum LOI that could
be granted to the enquiring CUCS. The LOI Authorized response does not pass
control of the VSM to the CUCS. This differs from the LOI Granted field in that when
the VSM reports the LOI Granted to the CUCS, the CUCS is there after considered to
be in control of the VSM at the granted LOI for either the UA and/or controlled station
identified in the message. Once the CUCS has been granted control of VSM
functionality, the VSM transmits the required status messages to the CUCS (CUCS
ID) and accepts the commands for the specified LOI from that CUCS. If the CUCS
requested a specific LOI in the CUCS Authorisation Request Message for a specific
Vehicle ID, it is requesting the granting of control from the VSM over the specified
functionality. Therefore, the VSM should respond with the granted LOI, unless that
functionality is already being controlled by another CUCS and the request is not an
override. Note, the STANAG 4586 does not specifically support a VSM identifying
(reporting) control over a UA component by one CUCS to another CUCS. All CUCSs
must monitor all VSM Authorization Response Messages on the network if they want
to build a picture of the network and the current state of UA payload control on that
network. It is an implementation detail whether a VSM identifies a UA functionality as
not authorized when being controlled by another CUCS (does not report the
functionality in the VSM Authorization Response Message, therefore defeating the
A3 - 123
Edition A Version 1
AEP-84.1
override capability), or shows it as authorized and then when requested not allow
control unless the request is an override over the current CUCS.
The VSM should also transmit this message to a CUCS to inform the CUCS that it is
no longer in control of the specified functionality, through the “Relinquish Control”
setting. This occurs in situations where one CUCS has overridden control of the
specified station from another CUCS, or a CUCS has released control of the specified
functionality.
A VSM on the ground may not be connected to a UA when it receives a CUCS
Authorization Request. In this situation the VSM transmits a VSM Authorization
Response Message for each of its logical VSMs, with each logical VSM identified by
an associated Vehicle ID, vehicle type and vehicle subtype. One message is sent for
each vehicle type/subtype (Vehicle ID) for which the VSM is capable of controlling.
When the VSM is on the ground, the CUCS is in essence controlling the VSM.
Once the CUCS has control over a “logical” VSM, the reception of Message #20,
Vehicle ID, will verify the absence of a vehicle connected to the system with the Tail
Number parameter being reported as “zero”.
Refer to Section A3.1.2.3 Entity Connection Management for
implementation details of the CUCS authorization Request message.
additional
A3.2.2 Vehicle Command and Status
A3.2.2.1 Message #40: Vehicle Configuration Command CUCS
Implementation
The Vehicle Configuration Command message is used by the CUCS to transmit the
initial UA Propulsion Energy to the VSM, as a percentage of the total capacity of the
system. The Propulsion Energy may be a liquid/solid fuel (kg) or a current charge
(joules), therefore the initial capacity is commanded as a percentage of the maximum
capacity of the system as reported (configured) from the VSM using Message #100,
Vehicle Configuration. The CUCS must provide a method for the operator to enter the
Initial Propulsion Energy if supported, and it is recommended this value is entered in
the type reported as supported in Message #100, Vehicle Configuration, either
“Propulsion Fuel Capacity” or “Propulsion Battery Capacity”. Potentially both
propulsion energy types may be available; however, the command of two different
propulsion energy types is not currently supported by this message.
A3.2.2.2 Message #40: Vehicle Configuration Command VSM Implementation
The VSM uses the reception of the Vehicle Configuration Command Message to
identify the initial fuel load, as a percentage of maximum load, on the UA. The VSM
must use the General Configuration Messages, Message #1301, Configuration Double
Response, for the Message #40, Initial Propulsion Energy parameter, to identify
whether or not it supports the entry of an initial propulsion energy value during the
configuration process. Message #100 itself identifies whether or not the vehicle
supports either Message #100, Propulsion Fuel Capacity or Message #100, Propulsion
Battery Capacity, in addition to using this same message (Message #100) to report the
fuel/battery capacity to the CUCS. The Propulsion Energy may be a liquid/solid fuel
(kg) or a current charge (joules), and the initial capacity is received as a percentage of
the maximum capacity of the system.
A3 - 124
Edition A Version 1
AEP-84.1
A3.2.2.3
Message #41: Loiter Configuration CUCS Implementation
The Loiter Configuration Command is used by the CUCS to configure the Loiter pattern
that will be used by the UA while it is in the Message #49, “Loiter” flight path control
mode. The Loiter flight path control mode is transmitted from the CUCS to the VSM
using Message #49, Vehicle Operating Mode and Steering Command. Refer to
Message #49 Implementation section for additional information.
This message configures the loiter pattern (Loiter Type, Loiter Radius, Loiter Length,
Loiter Bearing, Loiter Direction), and provides the capability to select a loiter specific
altitude and/or airspeed for the UA to achieve while in the Message #49, “Loiter” flight
path control mode.
The altitude and (air)speed demands in this message (Message #41) are intended as
configuration settings, and are not intended to be continuously altered while in the
“Loiter” flight path control mode. If the intention is to continuously alter the altitude and
(air) speed settings while in Loiter mode, Message #49, Select Flight Path Control
Mode, Unique ID 0042.04 settings should be “Flight Director (Manual).”
A3.2.2.4 Message #41: Loiter Configuration VSM Implementation
The VSM uses the Loiter Configuration Command Message to configure the Loiter
pattern that will be used by the UA when it is placed into the Message #49, “Loiter”
flight path control mode.
For Message #49, Altitude Mode, Speed Mode and Heading Mode fields:
“Configuration” enumeration: When in the selected Flight mode (Message #49, Select
Flight Path Control Mode), the Altitude, Speed, and Heading from the Configuration
message specified (see below) for that flight mode shall be used. While in this (Altitude,
Speed, Heading) mode, the Altitude/Speed/Heading commanded values shall not be
altered using Message #49.
Refer to “Message #41: Loiter Configuration CUCS Implementation” for additional
details.
A3.2.2.5 Message #44; Unmanned Aircraft Lights VSM Implementation
The Air Vehicle Lights Message is used by the CUCS to execute control over the UA
lights. Upon receipt of this message, the VSM should set the UA lights as commanded
in the message.
The VSM uses the Field Configuration Command Message (Message #1303) to
configure the available Set Lights states.
A3.2.2.6 Message #44: Unmanned Aircraft Lights CUCS Implementation
The CUCS populates the Air Vehicle Lights Message parameters as entered at the
CUCS, and transmits the message to the VSM. It is recommended that this Message
be transmitted to the VSM upon any change in parameter contained in the message.
A3.2.2.7 Message #45: Engine Command VSM Implementation
The Engine Command Message is used by the CUCS to control the UA engine(s).
Upon receipt of this message the VSM should set the UA engine(s) as commanded in
the message.
The VSM uses the Field Configuration Command Message (Message #1303) to
configure the available Engine Command states.
A3 - 125
Edition A Version 1
AEP-84.1
A3.2.2.8 Message #45: Engine Command CUCS Implementation
The CUCS populates the Engine Command Message parameters as entered at the
CUCS, and transmits the message to the VSM. It is recommended that the Engine
Command Message be transmitted to the VSM upon any change in parameter
contained in the message.
A3.2.2.9 Message #46: Flight Termination Command CUCS Implementation
The Flight Termination Command Message is sent from the CUCS to the VSM to
execute a flight termination sequence, or to reset a specified sequence.
The CUCS uses Message #1200, Field Configuration Request, to request the
configuration for the Flight Termination Mode field of the Flight Termination Command,
by requesting the configuration of Message #46, Field 5 (i.e., Unique ID 0046.05) from
the VSM. The response will be received from the VSM using Message #1302, Field
Configuration Enumerated Response. Refer to the Flight Termination Command VSM
Implementation section, the Field Configuration Request Implementation section and
the Field Configuration Enumerated Response Implementation section of this
document for additional details on how to configure the Flight Termination Mode field.
A3.2.2.10 Message #46: Flight Termination Command VSM Implementation
This message is used to provide a means for the CUCS to issue a Flight Termination
Command to the VSM.
The Flight Termination Command is sent from the CUCS to the VSM to execute a flight
termination sequence, or to reset a specified sequence. To accomplish flight
termination at the VSM, this message is received twice with two different values in the
Message #46, Commanded Flight Termination State field (once to arm, and a second
time to execute). If the VSM receives an “execute” command before an “arm”
command has been received, a warning should be sent to the CUCS indicating that
the Flight Termination System has not been armed.
The table below depicts the recommended/expected message sequence between the
CUCS and the VSM in commanding a Flight termination.
CUCS
VSM
Message #46: Flight Termination
Command ->
- Arm FT System
<- Message #108: Flight Termination Mode
Report
- FT System Armed
Message #46: Flight Termination
Command ->
- Execute FT Sequence
<- Message #108: Flight Termination Mode
Report
- FT Sequence Executed
Table A3 - 7: Flight Termination Mode Message Sequence
The VSM uses Message #1302, Field Configuration Enumerated Response, to report
the configuration of the Flight Termination Mode parameter of the Flight Termination
Command in response to a configuration request from the CUCS. The Flight
A3 - 126
Edition A Version 1
AEP-84.1
Termination mode parameter has no identified generic flight termination modes,
therefore the VSM must use Message #1302 to identify the available Flight Termination
modes for the vehicle under control. The Enumeration Count identifies the number of
Termination modes, the Enumeration Index indexes a specific enumeration, and the
Enumeration Text is associated with the Enumeration index to provide a User readable
identification of the specified Termination mode. These modes may then be presented
to the operator in the generic CUCS Displays.
Refer to the Field Configuration Request Implementation and the Field Configuration
Enumerated Response Implementation sections of this document for additional details
on how to configure generic enumerated fields.
A3.2.2.11 Message #47: Relative Route/Waypoint Absolute Reference
Command CUCS Implementation
The Relative Route/Waypoint Absolute Reference Command is used by the CUCS to
identify the absolute reference system for relative routes and their associated
waypoints to the VSM. The intent of this message is to support moving platforms for
launch and recovery, and to support usage of reusable “route templates” (e.g., for
search patterns). This message is sent to the VSM prior to commanding programmed
flight along any relative route, and updated as necessary otherwise.
A3.2.2.12 Message #47: Relative Route/Waypoint Absolute Reference
Command VSM Implementation
The Relative Route/Waypoint Absolute Reference Command is used to identify the
absolute reference system for relative routes and their associated waypoints. The
intent of this message is to support moving platforms for launch and recovery, and to
support usage of reusable “route templates” (e.g., for search patterns). This message
is received prior to commanding programmed flight along any relative route, and
updated as necessary otherwise.
A3.2.2.13 Message #49: Vehicle Operating Mode and Steering Command
This message shall be used to control the Vehicle Operating mode. The Vehicle
Operating mode defines the system behaviour and establishes how commands shall
be interpreted. The behaviours established include vehicle flight path response. The
intent of these behaviours is to provide a standard way of expressing common
operating modes and tactics. The specific implementation is left up to the vehicle
manufacturer.
This message shall be used to provide the ability to command a new flight vector to
the UA. Such commands are generated by manual input. Upon receipt of this
message, the vehicle’s response shall be to immediately enter into a manoeuvre to
achieve the new desired flight state. The vehicle’s responsibility shall be to avoid
unsafe flight states during the manoeuvre to answer the new command.
The VSM shall use the General Configuration Messages to define the UA’s capability
to support the fields commanded in Message #49, dependent on the current Flight
mode (Message #49, Vehicle Operating Mode and Steering Command) and the
current Altitude mode (Message #49, Altitude Mode), Speed mode (Message #49,
Speed Mode) and Heading mode (Message #49, Heading Mode) states. Refer to AEP84 Volume I Section 4.1.7 General Configuration Messages for additional details.
The Message #49, Altitude Mode, the Message #49, Speed Mode, and the Message
#49, Heading Mode fields are used to determine the source of the altitude, (air)speed,
A3 - 127
Edition A Version 1
AEP-84.1
and heading demands respectively for the selected (VSM reported) Flight mode
(Message #49, Select Flight Path Control Mode).
The Altitude, Speed, and Heading commanded values shall come from a specific
configuration message (see below) if the mode setting (report) is “Configuration”, and
the Altitude, Speed, and Heading commanded values shall come from Message #49
when the mode setting (report) is “Manual/Override.”
For Message #49, Altitude Mode, Speed Mode and Heading Mode fields:
“Configuration” enumeration: When in the selected Flight mode (Message #49, Select
Flight Path Control Mode), the Altitude, Speed, and Heading from the Configuration
message specified (see below) for that flight mode shall be used. While in this (Altitude,
Speed, Heading) mode, the Altitude/Speed/Heading commanded values shall not be
altered using Message #49.
“Manual/Override until reaching the Waypoint or Loiter Point” enumeration:
Manual/Override commands (Enumeration 2) shall be used until the UA reaches the
Waypoint or Loiter Point, at which time the commanded values shall be taken from the
Configuration commands (Enumeration 0). When in the selected flight mode
(Message #49, Select Flight Path Control Mode), use the “Manual/Override” settings
for Altitude, Speed, and Heading for that flight mode until next waypoint or loiter
position has been reached, and then use the Configuration message (see below)
settings. Once the UA reaches the transition point, it shall revert to the “Configuration”
mode. In order to re-enter the “Manual/ Override until reaching the Waypoint or Loiter
Point” mode, another mode shall first be commanded.
“Manual/Override” enumeration: When in the selected flight mode (Message #49,
Select Flight Path Control Mode), the Altitude, Speed, and Heading commanded
values shall always be from Message #49.
The following table shows the source message for the altitude/airspeed for each
combination of Flight Mode (Message #49, Select Flight Path Control Mode) and
Altitude or Airspeed Mode (Message #49, Altitude Mode, or Message #49, Speed
Mode).
Flight Mode
Altitude or Airspeed Mode
2 – Flight Director
0 – Configuration
1 – Manual until reaching the
WP, Loiter
2 – Manual/Override
Not Defined
49
0 – Configuration
1 – Manual until reaching the
WP, Loiter
2 – Manual/Override
802
49
0 – Configuration
1 – Manual until reaching the
WP, Loiter
41
49
11 – Waypoint
12 – Loiter
Source Message
for Altitude or
Airspeed
49
49
A3 - 128
Edition A Version 1
AEP-84.1
2 – Manual/Override
All other Flight
Modes
49
0 – Configuration
1 – Manual until reaching the
WP, Loiter
2 – Manual/Override
Not Defined
49
49
Table A3 - 8: Source Message for Altitude/Airspeed
The following table shows the source message for the heading or the lat/long,
dependent on which is valid, for each combination of Flight Mode (Message #49,
Select Flight Path Control Mode) and Heading Mode (Message #49, Heading Mode).
Flight
Mode
Heading Mode
2 – Flight
Director
0 – Configuration
1 – Manual until reaching
the WP, Loiter
2 – Manual/Override
Not Defined
49
Not Valid
Not Valid
49
Not Valid
0 – Configuration
1 – Manual until reaching
the WP, Loiter
2 – Manual/Override
Not Valid
49
802
49
49
49
0 – Configuration
1 – Manual until reaching
the WP, Loiter
2 – Manual/Override
Not Defined
Not Valid
Not Defined
49
Not Valid
49
0 – Configuration
1 – Manual until reaching
the WP, Loiter
2 – Manual/Override
Not Defined
49
Not Defined
49
49
49
11 –
Waypoint
12 – Loiter
All other
Flight
Modes
Source
Message for
Heading
Source
Message for
Lat/Long
Table A3 - 9: Source Message for Heading
Note:
Message # Specified – Mode valid and the specified message shall be used by the
VSM if the functionality is supported by the VSM.
Not Valid – Mode shall never be allowed by STANAG 4586 CUCS or VSM
Not Defined – STANAG 4586 does not define the functionality, the VSM shall define
the required functionality and make the required controls available at the CUCS. The
VSM may use a formatted DLI message for the functionality if desired.
A3 - 129
Edition A Version 1
AEP-84.1
A3.2.2.14
Message #100: Vehicle Configuration CUCS Implementation
The Vehicle Configuration Message is used to provide the CUCS with characteristics
of the vehicle it is controlling through the VSM. This message is used to specify the
characteristics of the vehicle, primarily for flight planning purposes. It indicates the
current characteristics of the vehicle either as specified by type by the manufacturer,
or based on current loading. For instance, “Optimum Cruise Speed” is likely only to be
available as the manufacturer-specified performance index, even though presence of
extra load or external stores may cause the number to vary in an unknown manner.
This message is required to be received by the CUCS during the general configuration
process in order to correctly configure the CUCS for the entry of the Message #40,
Initial Propulsion Energy, parameter if it is supported by the VSM. This message
identifies both the type of fuel supported by the system (Propulsion Fuel Capacity,
Propulsion Battery Capacity), and the maximum capacity for the supported type. Note,
currently the VSM must only identify support for one energy type as Message #40,
Initial Propulsion Energy, can only support one fuel type.
This message is also used to identify the “Number of Engines” supported by the UA
for the configuration purposes.
STANAG 4586 allows the CUCS to request configuration messages from the VSM/UA
in advance of requesting an LOI from the VSM. This is one of the configuration
messages that may be requested from the VSM by the CUCS if it is not received during
the general configuration process as it is required to properly configure the CUCS to
support fuel and engine command and status parameters.
A3.2.2.15
Message #100: Vehicle Configuration VSM Implementation
The Vehicle Configuration Message is used to provide the CUCS with characteristics
of the vehicle it is controlling through the VSM. This message is used to specify the
characteristics of the vehicle, primarily for flight planning purposes. It indicates the
current characteristics of the vehicle either as specified by type by the manufacturer,
or based on current loading
Some of the data elements contained in the Vehicle Configuration Message remain
relatively constant, and should only be configurable on a system administration level.
These data elements are:








Configuration ID
Propulsion Fuel Capacity (if external tanks are not an option)
Propulsion Battery Capacity
Maximum Indicated Airspeed (if not a function of payload
configuration)
Optimum Cruise Indicated Airspeed (if not a function of payload
configuration)
Optimum Endurance Indicated Airspeed (if not a function of
payload configuration)
Maximum Load Factor
Number of Engines
Some of the data elements in the Vehicle Configuration Messages change based on
the mission to be performed, and therefore should be entered by the operator before
conducting the mission. These data elements are as follows:

Gross Weight
A3 - 130
Edition A Version 1
AEP-84.1

X__CG
The VSM should provide a method for the operator to enter these parameters from a
user interface, and the VSM should populate the displays/controls with default values.
The VSM should be able to accept data from the UA to populate these displays if the
data is provided from the UA.
This message may be specifically requested by a CUCS from the UA/VSM using a
Message #1403 request, or is transmitted from the VSM when a CUCS makes a
general configuration request from the VSM using Message #1200, Field
Configuration, at the appropriate LOI (LOI 4). The VSM should populate and send this
message to the CUCS with the most recent data upon request for this message from
the CUCS.
A3.2.2.16 Message #101: Inertial States CUCS Implementation
The Inertial States Message provides the inertial states of the UA, and is pushed from
the VSM to the CUCS. The VSM developer is responsible for determining the rate at
which this message is required in order for the CUCS to provide a timely status display
of these data elements to the operator.
A number of the parameters in this message are configurable from the VSM, and the
CUCS should alter its displays to match the specified values/limits.
A3.2.2.17 Message #101: Inertial States VSM Implementation
The Inertial States Message provides the inertial states of the UA, and is pushed from
the VSM to the CUCS. The VSM is responsible for determining the rate at which this
message is required for the CUCS to provide a timely status display of these data
elements to the operator. The frequency at which the message is sent to the CUCS
should be determined based on the reception of UA messages containing the same
data elements being received from the UA.
The VSM should always populate this message with the latest data received from the
UA under control of the VSM.
Note: The VSM should NOT transmit this message to the CUCS when it is not receiving
the information contained in the message from the UA, as it is a false indication of the
UA status!
The message provides the current UA location, the current UA altitude with the
reference frame as reported in the Altitude type field, the UA ground speed, Roll, Pitch,
and Heading.
As a clarification, the Euler rates as a function of body rates are:

phi-dot = roll-rate + pitch-rate sin(phi) tan(theta) + yaw-rate
cos(phi) tan(theta)

theta-dot = pitch-rate cos(phi) – yaw-rate sin(phi)

psi-dot
=
pitch-rate
cos(phi)/cos(theta)
sin(phi)/cos(theta)
+
yaw-rate
As a clarification, the Accelerations in inertial axes as a function of accelerations in
body axes are:

U-Accel = X-Body-accel cos(theta) cos(psi) + Y-Body-accel
sin(phi) sin(theta) cos(psi) +Z-Body-accel cos(phi) sin(theta)
cos(psi) –Y-Body-accel cos(phi) sin(psi) + Z-accel sin(phi)
sin(psi)
A3 - 131
Edition A Version 1
AEP-84.1

V-Accel = X-Body-accel cos(theta) sin(psi) + Y-Body-accel
sin(phi) sin(theta)
sin(psi) +Z-Body-accel cos(phi) sin(theta)
sin(psi) +Y-Body-accel cos(phi)
cos(psi) –Z-accel sin(phi)
cos(psi)

W-Accel = –X-Body-accel sin(theta) +Y-Body-accel sin(phi)
cos(theta) + Z- Body-accel cos(phi) cos(theta)
A significant number of the UA parameters as reported in this message must be
configured using the General Configuration Messages to assist in the display of caution
and alert conditions at the CUCS. Refer to the STANAG 4586 document for the list of
parameters, identified within the Message #1300, #1301, #1302 and #1303
descriptions, required to be configured and which message is used to configure the
parameter.
The VSM/UA is responsible for providing the magnetic variation it is using to convert
true heading to magnetic.
Note: Magnetic Variation is often called Magnetic Declination.
A3.2.2.18 Message #102: Air and Ground Relative States CUCS
Implementation
The Air and Ground Relative States Message is pushed from the VSM at a rate
determined by the VSM manufacturer to allow for the timely display of the data
elements at the CUCS.
A number of the parameters in this message are configurable from the VSM, and the
CUCS should alter its displays to match the specified values/limits.
Note: The U_Wind and V_Wind variables combine to create a wind vector. The wind
vector indicates the magnitude and direction that the air mass is travelling. For
example, an air mass traveling at 4 m/s from South to North would be reported with
U_Wind=+4 m/s, V_Wind=0 m/s. For an air mass traveling from West to East the
reported V_Wind would be positive.
A3.2.2.19 Message #102: Air and Ground Relative States VSM Implementation
The Air and Ground Relative States Message provides the state of the UA relative to
its environment, and it provides information about the environment in which the UA is
located. This message is pushed from the VSM to the CUCS. The VSM is responsible
for determining the rate at which this message is required at the CUCS to provide a
timely status display of these data elements to the operator. Note: The VSM should
NOT transmit this message to the CUCS when it is not receiving the information
contained in the message from the UA, as it is a false indication of the UA status! The
VSM should always populate this message with the latest data received from the UA
under control of the VSM before sending it to the CUCS.
The STANAG data elements supported by the UA for which the VSM is being
implemented should be referenced appropriately to the required UA data element. The
STANAG 4586 provides the capability for a UA to report both altitude and (air) speed
to the CUCS in a number of frames of reference. This message provides the VSM
with the capability to transmit the altitude and (air) speed data to the CUCS for all
frames of reference it supports in a single message, at a rate to be determined by the
VSM for safe operation of the UA. The VSM must use the General Configuration
Messages to ensure that it correctly defines which frames of reference reports for the
altitude and (air) speed are supported by the UA, and which are not. It is highly
recommended that the configuration for both the reported and commanded altitude
A3 - 132
Edition A Version 1
AEP-84.1
and (air)speed frames of reference be the same (i.e., if a WGS-84 Altitude can be
commanded there should be a corresponding altitude report in the WGS-84 frame of
reference).
A significant number of the UA parameters as reported in this message must be
configured using the General Configuration Messages to assist in the display of caution
and alert conditions at the CUCS. Refer to the STANAG 4586 document for the list of
parameters, identified within the Message #1300, #1301, #1302 and #1303
descriptions, required to be configured and which message is used to configure the
parameter.
A3.2.2.20 Message #103: Body Relative Sensed States CUCS Implementation
The Body Relative Sensed States Message is pushed from the VSM at a rate
determined by the VSM manufacturer to allow for the timely display of the data
elements at the CUCS.
A number of the parameters in this message are configurable from the VSM, and the
CUCS should alter its displays to match the specified values/limits.
A3.2.2.21 Message #103: Body Relative Sensed States VSM Implementation
The Body Relative Sensed States Message provides the body-relative sensed states
of the UA, and is pushed from the VSM to the CUCS. The VSM is responsible for
determining the rate at which this message is required for the CUCS to provide a timely
status display of these data elements to the operator. These directly sensed bodyrelative states are packaged as a separate message type from other vehicle states
because these terms may need to be known at substantially higher rates for various
control-related functions.
The VSM should always populate this message with the latest data received from the
UA under control of the VSM.
Note: The VSM should NOT transmit this message to the CUCS when it is not receiving
the information contained in the message from the UA, as it is a false indication of the
air vehicles status!
The STANAG data elements supported by the UA for which the VSM is being
implemented should be referenced appropriately to the required UA data element.
A significant number of the UA parameters as reported in this message must be
configured using the General Configuration Messages to assist in the display of caution
and alert conditions at the CUCS. Refer to the AEP-84 Volume I document for the list
of parameters, identified within the Message #1300, #1301, #1302 and #1303
descriptions, required to be configured and which message is used to configure the
parameter.
A3.2.2.22 Message #104: Vehicle Operating States CUCS Implementation
The Vehicle Operating States Message provides the CUCS with a report of some of
the more critical parameters of the UA’s current operating states while in flight. The
CUCS requests this message as required from the VSM. It is recommended that the
reported states be presented to the operator in the same location as the corresponding
demanded states for the specified data elements.
The Vehicle Operating States Message should be requested by the CUCS, if not
automatically transmitted from the VSM, following a new operator commanded value
to the VSM for applicable parameters, as this messages contains the “reported
commanded” values for those parameters.
A3 - 133
Edition A Version 1
AEP-84.1
A3.2.2.23 Message #104: Vehicle Operating States VSM Implementation
This message is used by the VSM to provide a “report” of the commanded state at the
VSM/UA for various parameters that can be set from the CUCS, and as simply a report
for other parameters deemed to be of a more critical nature for UA operations.
For the parameters that are the “command” values for parameters commanded from
the CUCS (e.g., Commanded Altitude, Commanded Course Commanded Heading,
Commanded Speed) it is recommended that the VSM sends this message to the
CUCS upon a change in state of any of these parameters deemed critical to flight
operations. This will immediately notify the operator of the new operating states, and
allow action to be taken if the state is not appropriate to the current operating
conditions. For the parameters that are a simple report of a vehicle state, such as the
“Current Propulsion Energy Level”, the VSM transmits this message at a rate required
for the CUCS to provide a timely status display of these data elements to the operator.
Specific implementation considerations follow:
The Altitude type and Speed type fields in this message are used to provide the report
of the frame of reference for which the VSM is interpreting/using the “Commanded
Altitude” and “Commanded Speed” from the CUCS.
The STANAG data elements supported by the UA for which the VSM is being
implemented should be referenced appropriately to the required UA data element.
A couple of the UA parameters, specifically Current Propulsion Energy and Current
Propulsion Energy Usage Rate, as reported in this message must be configured using
the General Configuration Messages to assist in the display of fuel levels, caution and
alert conditions at the CUCS. The Commanded Speed, Altitude Type and Speed Type
fields are to be configured the same as the equivalent parameters in the Vehicle
Operating Mode and Steering Command Message (Message #49).
A3.2.2.24 Message #105: Engine Operating States CUCS Implementation
This message is used to report the operating state of a given engine to the CUCS, and
where there is a requirement to status multiple engines; one such message is sent by
the VSM for each engine. The CUCS should distinguishably display the status for
each of the reported engines to the CUCS operator.
A3.2.2.25 Message #105: Engine Operating States VSM Implementation
This message is used to report the operating state of a given engine, and where there
are requirements to report the status of multiple engines, one such message is
required for each engine. The intent of this message is to provide data for a basic set
of indicators for the operator. Any additional detailed information about an engine’s
operating state and health is a vehicle-specific function.
Where the summary engine status is reported (e.g., output shaft torque), the VSM is
responsible for the translation of the corresponding vehicle native parameters to the
discrete STANAG data elements (for each element identified in the message) and their
corresponding “overall” status value in order to correctly fill in the STANAG message.
The STANAG requires the following status levels with their associated colours:
0 = No Status
1 = Low – Red
2 = Low – Yellow
3 = Low – Green
4 = Normal – Green
5 = High – Green
A3 - 134
Edition A Version 1
AEP-84.1
6 = High – Yellow
7 = High – Red
The “Reported Engine Command” parameter in this message is the reported command
value for the Message #45, Engine Command parameter. The “Reported Engine
Command” parameter in this message identifies what engine command the UA/VSM
is currently executing. The “Engine Status” parameter in this message is a report of
the current status (actual state) of the selected engine.
The “Engine Speed” (rpm) report is provided in this message. It is recommended that
this message be transmitted from the UA/VSM upon change in state of the Engine
“status” parameters as a minimum. A VSM requiring to transmit the Engine Speed
(rpm) to a CUCS as a safely requirement would of course need to transmit this
message to the CUCS at a higher rate.
This message reports the status of a single engine. If more than one engine is present,
then multiple messages are sent, one for each engine. This message supports engines
with up to three different shaft speeds. Caution and warning limits for the engine
temperatures and shaft speeds can be set using Message #1300.
A3.2.2.26 Message #106: Vehicle Operating Mode Report CUCS
Implementation
This message is used to report the vehicle-operating mode, as commanded from the
Vehicle Operating Mode and Steering Command (Message #49).
A3.2.2.27 Message #106: Vehicle Operating Mode Report VSM
Implementation
The VSM uses the Vehicle Operating Mode Report to report the current Vehicle
Operating mode, Flight Path Control mode to the CUCS. The Vehicle Operating Mode
Report is used in conjunction with the Vehicle Operating Mode and Steering Command
(Message #49).
The VSM is required to configure Message #106, Reported Flight Path Control mode,
exactly the same as Message #49 for the equivalent parameter to avoid conflicting
states. This means that the configuration from Message #1303, Field Configuration
Command, for Message #49, Select Flight Path Control Mode, that identifies which of
the “Flight Path Control Modes” are supported by the VSM for control from the CUCS,
are the same control modes that are required to be reported back to the CUCS (i.e.,
the VSM should not be reporting back a flight mode that it has identified as unsupported
in the command).
The VSM must also ensure that it correctly reports back the “vehicle specific” flight
modes that were configured, if applicable, for Message #49, Select Flight Path Control
mode, using Message #1302, Field Configuration Enumerated Response.
A3.2.2.28 Message #107: Vehicle Lights State CUCS Implementation
This message is used to report the current state of the UA lights to the CUCS.
A3.2.2.29 Message #107: Vehicle Lights State VSM Implementation
This message is used to report the current state of the UA lights to the CUCS.
The Message #107, Navigation Lights State parameter identified in this message must
be configured with the same enumerations as established using Message #1303, Field
Configuration Command, for the Message #44, Set Lights parameter, as this message
is used as a report to that message.
A3 - 135
Edition A Version 1
AEP-84.1
Note, it is expected that status reports will be available for all the supported “navigation
lights” commanded parameters as the default implementation, and there will be no
orphaned reports. For example, if a “navigation light” enumeration cannot be
commanded, it is expected that there is no requirement to have a report for the same
enumeration.
A3.2.2.30 Message #108: Flight Termination Mode Report CUCS
Implementation
The CUCS must be capable of receiving this message from the VSM, as well as be
capable of requesting the message from the VSM. This message is used to report the
Flight Termination Command set at the VSM and its current status. This message is
sent from the VSM to the CUCS in response to Message #46 and whenever the current
status of flight termination changes.
Refer to the Message #46 Implementation section for additional details.
A3.2.2.31 Message #108: Flight Termination Mode Report VSM
Implementation
The VSM uses the Message #108, Flight Termination Mode Report, to report the Flight
Termination mode currently set at the VSM and the current Flight Termination state for
that mode. The VSM must be capable of transmitting this message to the CUCS upon
a change in state of the Flight Termination mode, as well as upon request for the
message from the CUCS.
The Message #108, Reported Flight Termination Mode parameter identified in this
message must be configured with the same enumerations as established for the
Message #46, Flight Termination Command, Flight Termination mode parameter, as
this message is used as a report of the system status as a result of that command (i.e.,
It is expected that there will be a report for each of the “vehicle specific” flight
terminations modes that were added to Message #46, Flight Termination Mode, as
applicable.). It is not expected that there will be reports for which a commanded mode
has not been configured.
If the VSM is in the UA, it should report that it is changing state to “Execute Flight
Termination Sequence” prior to any action that would preclude transmission of this
message to the CUCS.
Refer to the Message #46 Implementation section for additional details.
A3.2.2.32
Message #109: Mode Preference Report VSM Implementation
This message is the report for the Altitude mode, Speed mode, and Heading mode
states at the VSM to the CUCS in response to commands in Message #49.
A3.2.2.33
Message #110: From-To-Next Waypoint States VSM
Implementation
This message is used to report where a UA is coming from, where it is currently going
toward, and where it will be going next for certain flight modes as supported by the UA.
This message is used to provide LOI 2/LOI 3 control stations with the capability to
monitor a UA flight path to a limited extent, to allow those operators to determine where
the UA will be located in the near future for such things as payload planning purposes.
It is recommended that the VSM transmit this message to the CUCS upon change in
location of the reported Waypoints as a minimum, and potentially with a change in
“waypoint times” if at a higher rate.
A3 - 136
Edition A Version 1
AEP-84.1
The From, To, or Next Waypoint may not be valid dependent on the current Flight
mode (Message #49, Vehicle Operating Mode and Steering Command), therefore,
zero values shall be transmitted in the waypoint number field for invalid waypoints.
Unique IDs 0110.11 – 0110.16 (To waypoint) shall be used to define the nonloiter/loiter destination (the position toward which the vehicle is flying) when in the
"Loiter", "Waypoint" and "Slave to Sensor" Flight modes (Message #49 Vehicle
Operating Mode and Steering Command). It is highly encouraged that the "To
waypoint" be reported for all other Flight modes where the UA is attempting to achieve
a non-loiter/loiter position.
Unique IDs 0110.06 – 0110.10 (From waypoint) shall be used to define the point the
UA is departing from when in the "Waypoint" Flight mode (Message #49 Vehicle
Operating Mode and Steering Command). Unique IDs 0110.17 – 0110.22 (Next
waypoint) shall be used to define the non-loiter/loiter point to which the vehicle will
proceed after achieving the "To Waypoint" when in the "Waypoint" Flight mode
(Message #49 Vehicle Operating Mode and Steering Command). The From-To-Next
Waypoints provide a monitoring station with the capability to view a portion of the UA
route. It is highly encouraged that the "From waypoint" and Next waypoint" be reported
for all other Flight modes where applicable. The "Waypoint Numbers" used by the VSM
in this message shall not correspond to any Mission Waypoint numbers (Message
#802) loaded to the VSM by a CUCS, except to report those Mission Waypoints. While
in the Loiter mode, or any Flight Path Control Mode without a Next waypoint, the Next
waypoint definition should be set to zero to indicate that the waypoint is not valid. The
same applies to the “From Waypoint” when the UA is in any mode of operation or
situation (i.e., have not passed first waypoint in mission plan) where the “From
Waypoint” definition is not valid. 65535 in these fields indicates that the remaining To
Waypoint data is valid, but there is no valid waypoint number. When the UA is in a
mode of operation where none of the From-To-Next waypoints are valid, this message
is recommended not to be transmitted to the CUCS, such as potentially while in the
Flight Director Mode of operation.
A3.2.2.34 Message #111: Loiter Configuration Report
This message is used to report the current loiter configuration data of the vehicle. This
configuration describes the loiter pattern that the vehicle will fly when it is in ‘Loiter’
flight mode. This message is sent from the VSM to the CUCS in response to Message
#41, Loiter Configuration.
A3.2.2.35 Message #112: Relative Route/Waypoint Absolute Reference Report
CUCS Implementation
The CUCS will receive this message from the VSM so the CUCS can calculate the
absolute coordinates of all the waypoints in the VSM’s current route(s). Refer to
Message #802 and Message #110.
A3.2.2.36 Message #112: Relative Route/Waypoint Absolute Reference Report
VSM Implementation
The VSM will send this message to the CUCS so the CUCS can calculate the absolute
coordinates of all the waypoints in the VSM’s current route(s). Refer to Message #802
and Message #110.
A3.2.3 Payload Command and Status
A generic set of Payload types have been identified in Chapter 4 of AEP-84 Volume I,
and an associated set of generic messages has been identified for use with each of
A3 - 137
Edition A Version 1
AEP-84.1
these payload types. The set of generic DLI messages associated with a payload type
must be used for that payload when installed on an UA to achieve STANAG 4586
compliance.
A3.2.3.1 Message #200: Payload Steering Command CUCS Implementation
See section A3.1.6.1 and A3.1.6.2 for message implementation details.
A3.2.3.2 Message #200: Payload Steering Command VSM Implementation
See sections A3.1.6.1 and A3.1.6.2 of this document for message implementation
details.
A3.2.3.2.1 SAR Payload Steering
The control over the SAR payload type’s pointing angles and FOV are conducted from
the Payload Steering Command Message (Message #200). It is a VSM responsibility
to ensure the Payload Steering Commands are filtered according to the currently
selected “SAR Mode” as commanded by the SAR Payload Command Message
(Message #202), when the message is being used for a SAR payload type.
A3.2.3.3 Message #201: EO/IR/Laser Payload Command CUCS
Implementation
See sections A3.1.6.1 and A3.1.6.2 of this document for message implementation
details.
A3.2.3.4 Message #201: EO/IR/Laser Payload Command VSM Implementation
See sections A3.1.6.1 and A3.1.6.2 of this document for message implementation
details.
A3.2.3.5 Message #202: SAR Payload Command CUCS Implementation
See sections A3.1.6.1 and A3.1.6.3 of this document for message implementation
details.
A3.2.3.6 Message #202: SAR Payload Command VSM Implementation
See sections A3.1.6.1 and A3.1.6.3 of this document for message implementation
details.
A3.2.3.7 Message #203: Stores Management System Command CUCS
Implementation
The Stores Management System Command Message is used by the CUCS to execute
control over the deployable payloads on-board the UA through the VSM. The message
is also used to control the state of all weapons, and their sensors, located on-board
the UA. The CUCS is required to implement the transmission of this message if the
CUCS supports “dispensable” payloads. As this is a very specific capability, it is
recommended this functionality be placed within a separate dialog, only to be opened
as required.
The Station Number field in the message identifies the location of the deployable
payload/weapon on the UA, and it must be identified to the CUCS using the Payload
Configuration Message (Message #300).
A3 - 138
Edition A Version 1
AEP-84.1
The following message is used in conjunction with the Stores Management System
Command Message (Message #203) to provide for the control and status of a
Dispensable payload:
 Stores Management System Status (Message #304)
A3.2.3.8 Message #203: Stores Management System Command VSM
Implementation
The Stores Management System Command Message is used by the CUCS to execute
control over the deployable payloads on-board the UA through the VSM. The message
is also used to control the state of all weapons, and their sensors, located on-board
the UA. A VSM is required to implement reception of this message if it supports this
functionality.
The Station Number and Device Number fields in the message identify the location of
the deployable payload/weapon on the UA, and it must be identified to the CUCS using
the Payload Configuration Message (Message #300).
The following message is used in conjunction with the Stores Management System
Command message to provide for the control and status of a Dispensable payload:

Stores Management System Status (Message #304)
The VSM is required to report to the CUCS which states in the fields contained in the
Stores Management System Command are available for control from the CUCS in
order for the CUCS to correctly configure its displays.
A3.2.3.9 Message #204: Communications Relay Command CUCS
Implementation
The Communication Relay Command Message is used by the CUCS to execute
control over the Communications Relay located on-board the UA at the specified
station number. The CUCS is required to implement the transmission of this message
if the CUCS supports “Communication Relay”.
The Station Number field in the message identifies the location of the payload on the
UA, and it must be identified to the CUCS using the Payload Configuration Message
(Message #300). The communication relay radio is treated like a repeater (i.e., two
separate radios, A & B, whose audio channels are linked). This message also assumes
that the allowable radio frequencies and other parameters (e.g., transmission mode
(AM, FM)), are loaded before flight and cannot be changed while in flight. The following
message is used in conjunction with the Communications Relay Command Message
to provide for the control and status of a Communications Relay payload:
 Communication Relay Status (Message #305)
A3.2.3.10 Message #204: Communications Relay Command VSM
Implementation
The Communication Relay Command Message is used by the CUCS to execute
control over the Communications Relay located on-board the UA at the specified
station number. A VSM is only required to implement this message if it supports this
functionality.
The Station Number field in the message identifies the location of the payload on the
UA, and it must be identified to the CUCS using the Payload Configuration Message
(Message #300). This message reports the current status of all functions commanded
in the Communications Relay Command Message (Message #204).
A3 - 139
Edition A Version 1
AEP-84.1
The following message is used in conjunction with the Communications Relay
Command Message (Message #204) to provide for the control and status of a
Communications Relay payload:

Communication Relay Status (Message #305)
The VSM is required to report to the CUCS which states in the Set Relay State field
contained in the Communication Relay Command are available for control from the
CUCS in order for the CUCS to correctly configure its displays.
A3.2.3.11 Message #205: Payload Data Recorder Control CUCS Command
Implementation
The Payload Data Recorder Command Message is used by the CUCS to command a
Data Recorder located on-board the UA by device number. The CUCS is required to
implement the transmission of this message if the CUCS supports “Recorder”
payloads, and a VSM is required to implement the reception of this message if it
supports Recorder functionality.
The following messages are used in conjunction to provide for the configuration,
control and status reporting of a Recorder payload:
 Vehicle Payload/Recorder Configuration (Message #307)
 Payload Data Recorder Status (Message #306)
 Payload Data Recorder Control Command (Message #205)
The CUCS is required to configure its displays in accordance with the configuration for
the Payload Data Recorder, by station number, as received from the VSM.
A3.2.3.12 Message #205: Payload Data Recorder Control Command VSM
Implementation
The CUCS is required to implement the transmission of this message if the CUCS
supports “Recorder” payloads, and a VSM is required to implement the reception of
this message if it supports Recorder functionality.
The following messages are used in conjunction to provide for the configuration,
control and status reporting of a Recorder payload:


Vehicle Payload/Recorder Configuration (Message #307)
Payload Data Recorder Status (Message #306)

Payload Data Recorder Control Command (Message #205)
The VSM is required to report to the CUCS which states in the various fields, contained
in the Payload Data Recorder Control Command Message, are available for control
from the CUCS in order for the CUCS to correctly configure its displays. The VSM uses
the Field Configuration Command Message (Message #1303) for this purpose.
A3.2.3.13 Message #206: Payload Bay Command CUCS Implementation
The Payload Bay Command is used by the CUCS to command a Payload Bay door to
open or close dependent on its current state. The Payload Configuration Message
(Message #300) identifies if there is a payload bay door associated with a payload
station. The CUCS is required to implement the transmission of this message if the
CUCS supports “Payload Bay” door control, and a VSM is required to implement the
reception of this message if it supports payload doors.
A3 - 140
Edition A Version 1
AEP-84.1
A3.2.3.14 Message #206: Payload Bay Command VSM Implementation
The CUCS is required to implement the transmission of this message if the CUCS
supports “Payload Bay” door control, and a VSM is required to implement the reception
of this message if it supports payload doors.
A3.2.3.15 Message #207: Terrain Data Update Command CUCS
Implementation
The CUCS is required to implement the transmission of this message if the CUCS
supports terrain updates for a VSM that produces Message #302 where the Latitude
(Field 16/Unique ID 0302.16), Longitude (Field 17/Unique ID 0302.17) and Altitude
(Field 18/Unique ID 0302.18) fields are valid as indicated by the Image Position
enumeration (Field 15/Unique ID 0302.15). The sensor providing the image position
updates uses the terrain data to converge on an image location solution. The CUCS
pushes the terrain elevation data using Message #207 for each latitude and longitude
pair that is received in a Message #302 where the image position is valid.
A3.2.3.16 Message #208: CBRN Payload Command CUCS and VSM
Implementation
Refer to AEP-84 Volume I Section 4.1.3.9 and Section A3.1.6.4 in this document for
implementation guidance.
A3.2.3.17 Message #209: CBRN Payload Configuration Command CUCS and
VSM Implementation
Refer to AEP-84 Volume I Section 4.1.3.10 and Section A3.1.6.4 in this document for
implementation guidance.
A3.2.3.18 Message #210: CBRN Payload Detailed Info Request CUCS and VSM
Implementation
Refer to AEP-84 Volume I Section 4.1.3.11 and Section A3.1.6.4 in this document for
implementation guidance.
A3.2.3.19 Message #211: Storage Capacity Management Request CUCS and
VSM Implementation
Refer to AEP-84 Volume I Section 4.1.3.12 and Section A3.1.6.4 in this document for
implementation guidance.
A3.2.3.20 Message #212: CBRN Payload Display Configuration Command
CUCS and VSM Implementation
Refer to AEP-84 Volume I Section 4.1.3.13 and Section A3.1.6.4 in this document for
implementation guidance.
A3.2.3.21 Message #213: Payload Scan Window Configuration Command
CUCS and VSM Implementation
Refer to AEP-84 Volume I Section 4.1.3.14 and Section A3.1.6.4 in this document for
implementation guidance.
A3.2.3.22 Message #300: Payload Configuration CUCS Implementation
See Sections A3.1.6.6 and A3.1.6.7 of this document for message implementation
details.
A3 - 141
Edition A Version 1
AEP-84.1
A3.2.3.23 Message #300: Payload Configuration VSM Implementation
See Sections A3.1.6.6 and A3.1.6.7 of this document for message implementation
details.
A3.2.3.24 Message #301: EO/IR Configuration State CUCS Implementation
See Sections A3.1.6.6 and A3.1.6.7 of this document for message implementation
details.
A3.2.3.25 Message #301: EO/IR Configuration State VSM Implementation
See Sections A3.1.6.6 and A3.1.6.7 of this document for message implementation
details.
A3.2.3.26 Message #302: EO/IR/Laser Operating State CUCS Implementation
See Sections A3.1.6.6 and A3.1.6.7 of this document for message implementation
details.
A3.2.3.27 Message #302: EO/IR/Laser Operating State VSM Implementation
See Sections A3.1.6.6 and A3.1.6.7 of this document for message implementation
details.
A3.2.3.28 Message #303: SAR Operating State CUCS Implementation
See Sections A3.1.6.6 and A3.1.6.7 of this document for message implementation
details.
A3.2.3.29 Message #303: SAR Payload Operating State VSM Implementation
See Sections A3.1.6.6 and A3.1.6.7 of this document for message implementation
details.
A3.2.3.30 Message #304: Stores Management System Status CUCS
Implementation
This message is used to display the status of all weapons, and their sensors, located
on-board the UA. The CUCS is also required to implement the reception of this
message if the CUCS supports “dispensable” payloads. As this is a very specific
capability, it is recommended this functionality be placed within a separate dialog, only
to be opened as required.
The Station Number field in the message identifies the location of the deployable
payload/weapon on the UA, and it must be identified to the CUCS using the Payload
Configuration Message (Message #300).
The following message is used in conjunction with the Stores Management System
Status Message (Message #304) to provide for the control and status of a Dispensable
payload:
 Stores Management System Command (Message #203)
A3.2.3.31 Message #304: Stores Management System Status VSM
Implementation
The Stores Management System Status Message is used by the VSM to report the
status of the Deployable payloads on-board the UA. The message is also used to
display the status of all weapons, and their sensors, located on-board the UA. The
VSM is required to implement this message if it supports this functionality.
A3 - 142
Edition A Version 1
AEP-84.1
The Station Number field in the message identifies the location of the Deployable
payload/weapon on the UA, and it must be identified to the CUCS using the Payload
Configuration Message (Message #300).
The following message is used in conjunction with the Stores Management System
Status Message (Message #304) to provide for the control and status of a Dispensable
payload:

Stores Management System Command (Message #203)
A3.2.3.32 Message #305: Communications Relay Status CUCS Implementation
The CUCS is required to implement the reception of this message if the CUCS
supports “Communication Relay” payloads.
The Station Number field in the message identifies the location of the payload on the
UA, and it must be identified to the CUCS using the Payload Configuration Message
(Message #300).
The following message is used in conjunction with the Communications Relay Status
Message (Message #305) to provide for the control and status of a Communications
Relay payload:
 Communication Relay Command (Message #204)
A3.2.3.33 Message #305: Communication Relay Status VSM Implementation
The Communication Relay Status Message is used by the VSM to report the status of
a Communications Relay located on-board the UA at the specified station number.
A VSM is required to implement this message if it supports this functionality.
The Station Number field in the message identifies the location of the payload on the
UA, and it must be identified to the CUCS using the Payload Configuration Message
(Message #300).
The following message is used in conjunction with the Communications Relay Status
Message (Message #305) to provide for the control and status of a Communications
Relay payload:

Communication Relay Command (Message #204)
The VSM is required to configure the states in the Report Relay State field to the same
values as in the Set Relay State field of the Communication Relay Command.
A3.2.3.34 Message #306: Payload Data Recorder Status CUCS Implementation
The CUCS is required to implement the reception of this message if the CUCS
supports “Recorder” payloads, and a VSM is required to implement this message if it
supports Recorder functionality.
The following messages are used to provide for the configuration, control and status
of a Recorder payload:
 Vehicle Payload/Recorder Configuration (Message #307
 Payload Data Recorder Status (Message #306)
 Payload Data Recorder Control Command (Message #205)
A3.2.3.35 Message #306: Payload Data Recorder Status VSM Implementation
The Payload Data Recorder Status Message is used by the VSM to report the status
of a Data Recorder located on-board the UA by device number. The CUCS is required
A3 - 143
Edition A Version 1
AEP-84.1
to implement the reception of this message if the CUCS supports “Recorder” payloads,
and a VSM is required to implement this message if it supports Recorder functionality.
The following messages are used to provide for the configuration, control and status
of a Recorder payload:


Vehicle Payload/Recorder Configuration (Message #307)
Payload Data Recorder Status (Message #306)

Payload Data Recorder Control Command (Message #205)
A3.2.3.36 Message #307: Vehicle Payload/Recorder Configuration CUCS
Implementation
The Vehicle Payload/Recorder Configuration Message is used by the VSM to identify
to the CUCS which on-board recorders are associated with which on-board payloads.
The message is to be sent once for each recorder/payload pair. The CUCS is required
to implement the reception of this message if the CUCS supports “Recorder” payloads.
The message is used by the CUCS to identify which on-board recorder is associated
with which on-board payload. The CUCS displays may then be configured to identify
the payload/recorder relationship to the operator thus providing a more User Friendly
interface.
The following messages are used in conjunction with the Vehicle Payload/Recorder
Configuration Message (Message #307) to provide for the configuration, control and
status of a Recorder payload:
 Payload Data Recorder Status (Message #306)
 Payload Data Recorder Control Command (Message #205)
A3.2.3.37 Message #307: Vehicle Payload/Recorder Configuration VSM
Implementation
The Vehicle Payload/Recorder Configuration Message is used by the VSM to identify
to the CUCS which on-board recorders are associated with which on-board payloads.
The message is to be sent once for each recorder/payload pair. A VSM is required to
implement this message if it supports Recorder functionality.
The following messages are used in conjunction with the Vehicle Payload/Recorder
Configuration Message (Message #307) to provide for the configuration, control and
status of a Recorder payload:
 Payload Data Recorder Status (Message #306)
 Payload Data Recorder Control Command (Message #205)
A3.2.3.38 Message #308: Payload Bay Status CUCS Implementation
The Payload Bay Status Message is used by the VSM to report the payload bay door
status to the CUCS. The Payload Configuration Message (Message #300) identifies
if there is a payload bay door associated with a payload station. The CUCS is required
to implement the reception of this message if the CUCS supports “Payload Bay” door
control, and a VSM is required to implement the transmission of this message if it
supports payload doors.
A3.2.3.39 Message #308: Payload Bay Status VSM Implementation
The Payload Bay Status Message is used by the VSM to report the payload bay door
status to the CUCS. The Payload Configuration Message (Message #300) identifies
A3 - 144
Edition A Version 1
AEP-84.1
if there is a payload bay door associated with a payload station. The CUCS is required
to implement the reception of this message if the CUCS supports “Payload Bay” door
control, and a VSM is required to implement the transmission of this message if it
supports payload doors.
A3.2.3.40 Message #309, CBRN Detection, Through Message #314, CBRN
Payload Detailed Info Estimate Response
Refer to AEP-84 Volume I Sections 4.1.3.24 through 4.1.3.29 and Section A3.1.6.4 of
this document for implementation details.
A3.2.4 Data Link Command and Status
The Data Link Command and Status Messages have been developed with the
intention of separating the communication equipment functionality from the pedestal
functionality. This division is intended to allow the potential replacement of either the
radio equipment or a pedestal within a system.
The following messages are considered communications equipment configuration,
control, and status messages:





Data Link Configuration/Assignment Message (Message #500)
Data Link Set-up Message (Message #400)
Data Link Status Report (Message #501)
Data Link Control Command (Message #401)
Data Link Control Command Status (Message #502)
The following messages are considered pedestal configuration, control, and status
messages:
 Pedestal Configuration Message (Message #402)
 Pedestal Status Report (Message #503)
 Pedestal Control Command (Message #403)
Each of the above messages contains a Data Link ID field which is used to specifically
identify the data link terminal for which the message applies. There is an additional,
potentially redundant, VDT/CDT flag to specifically identify to which data link terminal
the message refers. The CDT and VDT are not considered paired, therefore the Data
link ID for a CDT/VDT combination will not be a single Data Link ID for that specific
pair. This is to provide the capacity to maintain a Data Link ID reference for each
terminal, such as in the event of a transition in control of an UA from one CDT to
another, where the CDT/VDT combination is altered.
A3.2.4.1 Message #400: Data Link Set-Up Message
The Data Link Set-up Message is transmitted from the CUCS to the VSM, referenced
to a specified Data link ID, and it is used to set the parameters required for the
operation of a STANAG 7085 compliant Common Data Link (CDL) data link. The
message provides the capability to set-up both the VDT and CDT parameters from the
CUCS independently. The parameters in the message are generic, however each
data field must be configured for the specified link. The configuration of the message
VSM specific contents (Data Link Type field) is achieved through the use of the
General Configuration Messages.
Vehicle Data Link Transition Coordination Message (Message #600), contains some
of the same set-up parameters as this message for the VDT terminal, and is used to
A3 - 145
Edition A Version 1
AEP-84.1
change the VDT parameters for a transfer in control of a UA from one UCS to another.
This message is not used for transitions in UA control.
The Addressed Terminal field provides the capability to set-up up the CDT from the
CUCS, and in the cases where a VDT defaults to a known configuration, the VDT
configuration may be modified from the CUCS.
The CDL data link requires a PN Code and Frequency Code to operate. While the
codes are not considered classified, the broadcast of these codes in an unencrypted
manner could result in a compromise to the operational security of the system and
possibly other systems using CDL based data links. If a UA contains another link(s) in
addition to the CDL link, it should not send the CDL codes unless all data links are
encrypted.
The VSM reports whether or not it supports the parameters identified in the message
using General Configuration Message #1300 and 1301. Where a VSM reports it does
not support a parameter, it is expected the CUCS will not provide control of the
parameter to the operator. The General Configuration Messages are also used to
provide control and display limits for the message parameters.
A3.2.4.2 Message #401: Data Link Control Command Implementation
The Data Link Control Command Message is used by the CUCS to send commands
to components of the data link communications equipment. The message provides
the capability to set the state (mode) of the data link, select the antenna type, and
zeroes the communication security equipment if required. The message provides the
capability to command the VDT independent of the CDT.
Some of the parameters within the messages may not be applicable to both the CDT
and VDT terminals within a system.
The Data Link Status Report (Message #501) provides the status of the commanded
parameter, and the Data Link Control Command Status Message (Message #502)
provides the currently demanded value for the commanded parameters.
The Configuration Messages, Message #1301, etc., are used by the VSM to identify
to the CUCS whether or not entire fields within the message, or specific states within
fields, are supported by the VSM. The CUCS is then expected to use this configuration
information to adjust its displays accordingly.
A3.2.4.3 Message #402: Pedestal Configuration Message
The Pedestal Configuration Message is transmitted from the CUCS to the VSM/CDT
data link. This message provides the capability to enter the location of the CDT
antenna at the CUCS and transmit this information to the CDT.
A3.2.4.4 Message #403: Pedestal Control Command
The azimuth and elevation offsets are sent periodically from the CUCS to the VSM/data
Link in Message #403, Set Azimuth Offset, and Set Elevation Offset. The Azimuth
Offset value is defined as the difference between the antenna azimuth relative to
pedestal 0 and the antenna bearing relative to true north. The Offset value is reported
as positive if the pedestal report needs to be adjusted in the clockwise direction and
will be reported as negative if the pedestal report needs to be adjusted in the counterclockwise direction.
A3 - 146
Edition A Version 1
AEP-84.1
Figure A3 - 15: Azimuth Offset
The Elevation Offset value is defined as the difference between the antenna elevation
relative to pedestal 0 and the antenna elevation relative to horizontal, and will be
reported as positive if the elevation needs to be corrected upwards.
As an example, if the antenna is reporting a 110 degree azimuth relative to pedestal
0, and it is actually pointing 50 degree relative to true north, then the azimuth offset is
minus 60 degrees.
It is expected that the pedestal will take the offset values as commanded in Message
#403 and add it to the pedestal antenna azimuth relative to pedestal 0 at all times, and
report this value as the pedestal azimuth in Message #503, Reported Antenna
Azimuth, to the CUCS.
Suppose the operator starts up with the azimuth offset at 0, the antenna is pointing at
110 relative to pedestal 0 and 50 degrees relative to north. The CUCS will set the
azimuth offset to the operator entered bearing (50 degrees) minus the reported
azimuth (110) (i.e., to minus 60). The VSM/data link always adds the Azimuth Offset
to the pedestal antenna azimuth relative to the pedestal 0 value before reporting it to
the CUCS.
A3.2.4.5 Message #404: Data Link Assignment Request Implementation
This message is used by a CUCS to request control over a CDT/VDT for which a VSM
has reported available for control through Message #500, Data Link
Configuration/Assignment Message.
The following sequence diagram depicts the general relationship between Message
#500, Message #404, Message #1, and Message #21. As illustrated above, there are
exceptions to the standard, however it is expected that complex control relationships
will not be the norm and that VSMs will verify expected CONOPS.
CUCS
VSM
Message #1: CUCS Authorization Request
->
<- Message
Response
Message #1200:
Request ->
Field
#21:
VSM
Authorization
Configuration
A3 - 147
Edition A Version 1
AEP-84.1
<Message
#500:
Data
Configuration/Assignment Message
Identify Data
availability.
Link
Link
configuration
and
<Message
#500:
Data
Configuration/Assignment Message
Link
Message #404: Data Link Assignment
Request ->
Request a Data Link for controlling a UA.
Assign Data link control to CUCS.
Message #400: Data Link Setup Message >
Message #402: Pedestal Configuration
Message->
Message #401: Data Link Control
Command ->
Message #403: Pedestal Control
Command
<- Message #502: Data Link Control
Command Status
<- Message #501: Data Link Status Report
<- Message #503: Pedestal Status Report
Message #1: CUCS Authorization Request
->
Vehicle/Payload Control Request
<- Message
Response
#21:
VSM
Authorization
Control Response
Table A3 - 10: Data Link Message Sequencing
A3.2.4.6 Message #500: Data Link Configuration/Assignment Message
Implementation
The Data Link Configuration/Assignment Message is used by the VSM to identify the
data link configuration of the CDTs/VDTs associated with a VSM. The intent of this
message is to provide the CUCS with the data link configuration on initial connection,
with one instance of this message sent for each employed data link.
Where a specific vehicle is not associated with the CDT, the null Vehicle ID is
transmitted with the supported Vehicle Type and Vehicle Subtype identified in the
message. Where a VSM supports more than one Vehicle Type and Vehicle Subtype
for a single CDT (resource sharing), each instance of support is reported to the CUCS
with the same Data Link ID. Where a STANAG 7085 data link is shared between two
or more VSMs, the VSM/CDT Status is the responsibility of the VSMs.
A3 - 148
Edition A Version 1
AEP-84.1
This message is used by the VSM to grant a CUCS control over a specific Data Link
ID, report the Data Link ID as unavailable, or to report the successful release/
availability of a Data Link ID. For each reported Data Link ID/Vehicle Type/Vehicle
Subtype combination, the VSM reports the controllability of the data link in the “Data
Link Control Availability” field. An example response could be as follows based on the
configuration of the Figure below.
STANAG DLI
VSM A:
AV_1
AV_2
CUCS
GDT
VSM B:
AV_3
Vehicle Protocol w/
GDT Protocol
Figure A3 - 16: Example of a VSM Response
VSM A: Message #500: Instance 1: Data Link ID: 123.123.123.123; Vehicle Type:
AV_1; Subtype 1
VSM A: Message #500: Instance 2: Data Link ID: 123.123.123.123; Vehicle Type:
AV_2; Subtype 1
VSM B: Message #500: Instance 1: Data Link ID: 123.123.123.123; Vehicle Type:
AV_3; Subtype 2
For each reported Data Link ID/Vehicle Type/Vehicle Subtype combination, as above,
the VSM reports the controllability of the data link in the “Data Link Control Availability”
field of Message #500 during CUCS configuration.
VSM A: Message #500: Instance 1: Data Link ID: 123.123.123.123; Vehicle Type:
AV_1; Subtype 1: Available
VSM A: Message #500: Instance 2: Data Link ID: 123.123.123.123; Vehicle Type:
AV_2; Subtype 1: Available
VSM B: Message #500: Instance 1: Data Link ID: 123.123.123.123; Vehicle Type:
AV_3; Subtype 2: Available
Any subsequent changes in the “Data Link Control Availability” will be updated from
the VSM using Message #500. For example if the CUCS in the above Figure requests
control of the CDT for VSM A: AV_1 using Message #404, Data Link Assignment
Request, and the VSMs are not capable of concurrently sharing the CDT resource, the
VSMs would report the CDT as being unavailable for the other two vehicles, and grant
control to the CUCS for the AV_1 vehicle.
VSM A: Message #500: Instance 1: Data Link ID: 123.123.123.123; Vehicle Type:
AV_1; Subtype 1: Req. Granted
VSM A: Message #500: Instance 2: Data Link ID: 123.123.123.123; Vehicle Type:
AV_2; Subtype 1: Unavailable
VSM B: Message #500: Instance 1: Data Link ID: 123.123.123.123; Vehicle Type:
AV_3; Subtype 2: Unavailable
This message also identifies the data link type and the system antenna configuration.
The Terminal Type field is specifically used to identify the Antenna Type(s) available
A3 - 149
Edition A Version 1
AEP-84.1
for each of the CDT(s) and the VDT(s) of the identified data links. The Figure below
depicts another potential VSM/data link configuration, where AV1 is available for
connection, however CDT3 does not have a vehicle associated with it.
Figure A3 - 17: Data Link Configuration
In this configuration, the data links would most likely be reported as follows:
VSM A: Message #500: Instance 1: Vehicle ID: 1; Data Link ID: 1; Vehicle Type: AV1;
Subtype 1: Available
VSM A: Message #500: Instance 2: Vehicle ID: 1; Data Link ID: 2; Vehicle Type: AV1;
Subtype 1: Available
VSM A: Message #500: Instance 3: Vehicle ID: FF.0.0.0; Data Link ID: 3; Vehicle Type:
AV1; Subtype 2: Available
The Figure below depicts another potential CUCS/VSM/CDT configuration.
CUCS A
CUCS B
VSM
CUCS
CUCS C
Figure A3 - 18: Potential CUCS/VSM/CDT Configuration
In this configuration, CUCS A may request control of the CDT and then request LOI 4
(UA control). Note that UA and Payload control are requested and granted using
Messages #1 and Message #21 respectively. Control of the CDT would be unavailable
to CUCS B, but CUCS B would be able to request LOI 3 (Payload control) on the UA
controlled by CUCS A using the same data link. In this situation, if CUCS A releases
control of the UA, the VSM could pass control of the CDT to CUCS B. If CUCS C then
requests control of the UA, the VSM may pass control of the CDT to CUCS C or leave
it with CUCS B. There are many combinations of CUCS/VSM/CDTs, therefore the
VSM must use Message #500, Data Link Configuration/Assignment Message as
required to correctly assign CDT control to a CUCS.
A3 - 150
Edition A Version 1
AEP-84.1
A3.2.4.7 Message #501: Data Link Status Report Implementation
The Data Link Status Report is used by the VSM to transmit the status of the data link
to the CUCS, for both the CDT and VDT communication equipment. The message is
used to report the state of the communications equipment, the antenna being used,
and the communication parameters. The message also provides a report of the
Downlink quality (status) as reported by the data link equipment, and reports on the
presence of communications security equipment and its status. The Downlink Status
field report is based on a vehicle specific determination of the quality of the link being
used by the system, where the VSM manufacturer determines how the downlink quality
is calculated. The calculation may be based on Bit Error rates, AGC, other system
parameters, or any combination thereof.
The Data Link Status Report Message reports on the parameters initialised using the
Data Link Set-up Message (Message #400) and reports the state of parameters
commanded from the Data Link Control Command (Message #401).
A3.2.4.8 Message #502: Data Link Control Command Status Implementation
The Data Link Control Command Status Message is sent from the VSM to the CUCS,
and provides a report of the status of the commanded data link parameters. The
message verifies that the commanded data link values were correctly received at the
VSM/CDT data link, as commanded by the Data Link Control Command (Message
#401). The VSM must configure the parameters in this message the same as those in
Message #401, Data Link Control Command.
A3.2.4.9 Message #503: Pedestal Status Report
The Pedestal Status Report Message is transmitted from the VSM/CDT to the CUCS
to report the current status of either the CDT or the VDT. The message is used to
report the pedestal operating mode, the antenna pointing angle, antenna rates, and
the antenna location. The associated pedestal commands are contained in the
Pedestal Control Command. The message parameters that are not applicable to the
CDT or the VDT are recommended to be reported as “zero” in value.
A3.2.5 Data Link Transition
The Data Link Transition Messages are used to provide the capability for a coordinated
transition in control of an UA from one physical CDT to another. These messages are
used in conjunction with the CUCS Authorisation Request (Message #1) and the VSM
Authorisation Response (Message #21) Messages. The Vehicle Data Link Transition
Coordination Message (Message #600) and the Handover Status Report Message
(Message #700) are used to conduct the physical transfer and report its status, while
the Authorisation Messages are used to transfer authority from one CUCS to another.
A description of potential handover/transition sequences are provided in the Handover
Sequence section of this document. Refer to that section of the document for message
sequencing.
Note: The Data Link Command and Status Messages provide some capability for a
transition in control; however they are not intended for this purpose.
A3.2.5.1 Message #600: Vehicle Data Link Transition Coordination Message
Implementation
The Vehicle Data Link Transition Coordination Message is used to initiate the transition
of control over a UV from one UCS data link to another UCS data link. The UCS in
control of the UA transmits this message identifying which VDT will be transferred and
A3 - 151
Edition A Version 1
AEP-84.1
identifies the CUCS ID that control of the VDT data link is to be transferred to. The
message also provides the geographical location of the acquiring CDT for the purpose
of directional link transfers, and the communication parameters required to
successfully complete the transfer.
The transfer of control is initiated with the transmission of the Vehicle Data Link
Transition Coordination Message once authorisation for the transfer has been
authorized through the transmission of a CUCS Authorisation Request Message.
The authorisation for the LOI and the specific UA functionality to be controlled is
conducted through the use of the CUCS Authorisation Request Message and the VSM
Authorisation Response Message.
A3.2.5.2 Message #700: Handover Status Report Implementation
The Handover Status Report Message may be used to report the status of a transition
in the VDT data link control from one controlling UCS to another, as a result of a Vehicle
Data Link Transition Coordination Message. The VSM would send the appropriate
“status” of the transfer to the relinquishing CUCS based on the available status from
the relinquishing CDT. Additionally, either CUCS may use this message to
communicate a failure condition to the VSM by setting the Status field to Handover
Failed.
A3.2.6 Mission Messages
The messages in this section support transfer of a mission plan between the UA and
the CUCS. Mission messages can be sent to/from the UA before and during flight.
A3.2.6.1 Message #800, Mission Transfer Command, Through Message #806,
Vehicle Specific Waypoint
AEP-84 Volume I, Section 4.1.5.1 through Section 4.1.5.7 and Section A3.1.3 of this
document provide Implementation details for these messages.
A3.2.6.2 Message #900 Mission Upload Status
AEP-84 Volume I, Section 4.1.5.8 and Section A3.1.3 of this document provide
Implementation details for this message.
A3.2.7 Subsystem Status Messages
The common message set includes summary health and status information for use by
CUCS status displays. This information need not convey detailed, configurationspecific health and status information, but should provide the CUCS with overall health
summary data suitable for annunciation on the console using conventional colour
codes (Green=Nominal, Yellow=Caution, Red=Warning, Black=Failed or Out-ofservice). In the event of a system caution or warning, vehicle or configuration-specific
status messages can provide detailed diagnostic information peculiar to that
configuration.
Support is provided for up to four engines and primary and auxiliary support systems.
These messages shall provide health and status overview information only in an
interoperable context. Detailed status information about particular subsystems should
use a vehicle-specific message type.
A3.2.7.1 Message #1000: Subsystem Status Request Implementation
This message is sourced at the CUCS, and is used by the CUCS to request subsystem
status from the VSM for all subsystems identified in the message. The CUCS should
request this message automatically at a specified rate providing the operator with a
A3 - 152
Edition A Version 1
AEP-84.1
near-real-time display of the subsystems status. The request rate should be
configurable to account for differences in vehicle systems.
When the VSM receives this message from the CUCS, the VSM sends the Subsystem
Status Report (Message #1101) for the subsystem identified in the received message.
A3.2.7.2 Message #1001: Subsystem Status Detail Request CUCS
Implementation
This message is sourced by the CUCS as a request for additional information from a
received Subsystem Status Alert Message (Message #1100) or from a Subsystem
Status Report Message (Message #1101). Refer to Message #1100 and #1101
implementations for additional information.
The Warning Display System on the CUCS should provide a method to request
additional information for a Received Warning Message (Message #1100) if available
at the VSM. The CUCS request creates this message with the same Subsystem State
Report Reference as received in Message #1100.
The CUCS should provide the operator with the capability to request additional
information on a Subsystem Status Report (Message #1101), in a manner similar to
Message #1100, and the VSM provides the required information to the CUCS upon
receipt of the Subsystem State Report Reference. Again this may be through the use
of a pop up dialog.
A3.2.7.3 Message #1001: Subsystem Status Detail Request VSM
Implementation
Upon the receipt of Message #1001, the VSM provides the information to the CUCS
related to the specified warning. This may be through the use of a pop up window or
dialog on the CUCS display. In a cylinder head temperature example, a suitable
response from the VSM to a request for details would be to present an engine
parameters window showing additional engine parameters, not just a cylinder head
temperature gauge. This could include (at the discretion of the VSM implementer) a
recommendation for an action (e.g., in this case the recommendation might be to slow
down or reduce the climb rate).
A3.2.7.4 Message #1100: Subsystem Status Alert Message Implementation
This message is sourced at the VSM. It is recommended that this message be
implemented, in conjunction with Message #1001, as a warning detection and display
system between the CUCS and VSM. Detailed implementations regarding aspects of
this message follow:

How to use the Priority level (1100.04):
The warning system is capable of displaying warnings based on a priority level in
the priority level field. There should be the ability to display 6 warning levels, with
zero being the lowest level. The warnings are displayed in a warning display system
with the highest priority warning displayed at the top, and then the warnings are
displayed in descending order of priority. It is recommended that the most recent
warnings be placed at the top of each priority level within the warning display. It is
recommended that warnings at one priority level be distinguishable from warnings
at another priority level, such as through the use of colour coded warnings.

How to use the obtain additional information about the alert:
A3 - 153
Edition A Version 1
AEP-84.1
The warning system is able to accept a Subsystem State Report Reference
associated with a specific warning. The report reference is a vehicle specific
reference provided by the VSM, which the CUCS can use to request additional
information from the VSM on the reported warning. If the report reference is “-1”
there is no additional information available for the warning. If the report reference
is greater than zero there is additional information available for the warning, and the
warning system should provide a method to request this additional information using
a vehicle specific service. The method to request this additional information could
be a “Details” button or a “hyperlink” referenced to the displayed warning. Software
within the VSM decides whether more information is available for a specific warning
and sends the required report reference.
Upon user request, the CUCS issues a Subsystem Status Detail Request (Message
#1001) to the VSM to request more details. Unique ID 1001.04 of the Subsystem
Status Detail Request Message contains the Subsystem State Report Reference
as received in the Subsystem Status Alert Message (Message #1100) for the
specified warning.

How to update an existing alert:
The warning system updates a warning by sending a Subsystem Status Alert
Message (Message #1100) with a reference to the original Alert ID (note that in the
Alert ID field the first instance is always a negative value and all subsequent values
are positive (e.g., -123, 123, 123, ...), with changes to the text to be displayed. To
reduce message bandwidth requirements, it is recommended the VSM ensure that
only new or updated messages are transmitted across the DLI.

How to send a longer alert text:
There are situations where the warning system cannot use vehicle specific services
to provide additional information for reasons such as bandwidth, security, etc. In
those situations it may be appropriate to send the CUCS a longer alert text
containing more information. This can be achieved by concatenating the text from
several Subsystem Status Alert Messages (Message #1100).
To use this method, the warning system sends the first 80 characters of the alert as
it normally would and with Message Type (Unique ID 1100.12) set to 0
(New/Update). The next 80 characters of the alert are then sent in a subsequent
Subsystem Status Alert Message (Message #1100) as follows
-
While referencing the original Alert ID
-
With Message Type (Unique ID 1100.12) set to 1 (Append),
-
With Append total number (Unique ID 1100.14) set to the total number of
alert messages that will be concatenated (ex. 3 would indicate that 3
messages are needed to construct the full text of the alert) and;
-
With Append order (Unique ID 1100.13) set to the order number for the
current segment of alert text with respect to the other expected alert
messages (ex. 1 would indicate that this is the 2nd message needed to
A3 - 154
Edition A Version 1
AEP-84.1
construct the full text of the alert). This allows the segments of the alert texts
to be concatenated in the proper order.
Note: This method assumes that the implementer will not change the original values
for the following fields: Unique ID 1100.04 (Priority), Unique ID 1100.05 (Subsystem
State Report Reference), Unique ID 1100.06 (Subsystem ID), Unique ID 1100.07
(Type), Unique ID 1100.10 (Persistence), or Unique ID 1100.11 (Station Number),
so as not to confuse the warning display system.
Edge case reminder #1: It is recommended that the implementation takes into
account edge cases such as if the same alert gets updated for a second time too
quickly before the first set of messages had a chance to be concatenated. If proper
precautions are not observed then there is a risk that segments from the text from
the first alert update can be mixed up with that of the second update.
Edge case reminder #2: It is recommended that the implementation takes into
account edge cases such as if segments of the alert are lost for any reason.

How to clear an Alert:
The warning type (Unique ID 1100.07) identifies the persistency of the message for
display on the CUCS warning panel. The implementation for clearing Type 2 and
Type 3 warnings is at the CUCS developers discretion, however it is recommended
the method to clear these warnings be obvious. In order to clear a Type 1 Warning,
Not Clearable by Operator, the recommended method of implementation is to send
a Subsystem Status Alert Message with a reference to the original Alert ID as sent
to display Warning, but with a Priority of “Cleared”.
It is not necessary to send all the multiple alert messages that formed a
concatenated alert text. It should be sufficient to send only the first message with
the Priority set to “Cleared” assuming that the alert text hasn’t changed.

How to display the Alert:
The warning display system is to be capable of displaying an ASCII string 80
characters in length. It is recommended the entire contents of the received text
string be displayed on the CUCS as received from the VSM. If a concatenated alert
text longer than 80 characters was received then it is at the discretion of the
implementer whether to display more than 80 characters without requiring additional
user action. The CUCS does no interpretation of the warning; it only provides a
display for all warnings, in a prioritised list.

How to use the Persistency (Unique ID 1100.10):
The warning persistence time is used for warnings of Type 1 and Type 2. This time is
measured from when a Type 1 or Type 2 alert is received by the CUCS. If a Type 0
message is received before the time has expired, the alert will remain active for the
defined persistence time. If a Type 0 message is received after the persistence time
has expired, the alert will be deactivated immediately.
The control station field allows payload alerts to be routed to the proper payload
operator, avoiding sending that alert to other payload operators who do not need to
handle the alert.
A3 - 155
Edition A Version 1
AEP-84.1
A3.2.7.5 Message #1101: Subsystem Status Report Implementation
This message provides the general status of all the systems on-board the UA. It is
recommended that this message be used in the creation of a Master Caution panel on
the CUCS display system, where the status of all subsystems is displayed in a common
location. A specific display component should represent each of the subsystems
identified in the message, and each possible state for a subsystem should be
distinguishable from another, such as through the use of colour or icons.
Using this message, the Master Caution panel is able to accept Subsystem State
Report References associated with a specific subsystem. The report reference is a
vehicle specific reference provided by the VSM, which the CUCS can use to request
additional information from the VSM on the specified subsystem. The operator should
have some method, such as a button or a hyperlink, to request the additional
subsystem information.
A user request for additional information from the Master Caution panel initiates the
transmission of a Subsystem Status Detail Request Message (Message #1001) from
the CUCS to the VSM. The Subsystem Status Detail Request Message contains the
Subsystem State Report Reference as received in this message for the specified
subsystem. See Subsystem Status Detail Request Message (Message #1001) for
additional information. One message is required to report each of the identified
subsystems.
The VSM determines the subsystem state in accordance with Chapter 4 of AEP-84
Volume I, with the current states as follows:






No Status
Nominal
Caution
Warning
Emergency
Failed
The overall Subsystem State should be the state of the worst data element that is a
member of the subsystem’s set of data elements. As this message only provides a
generic status for each of the identified subsystems, a Report Reference should be
available to the CUCS for each of the subsystems.
The following Table is a potential table to identify vehicle specific subsystem
parameters, identify the parameter states, and identify any additional information on
the subsystem based on the current state.
A3 - 156
Edition A Version 1
AEP-84.1
Table A3 - 11: Vehicle Specific Subsystem Parameters, States and Subsystem
System
Mechanical
Monitored
Parameter
Nominal
Caution
Warning
Emergency
Failed
List of
Parameters
Communication
Navigation
Engine
Electrical
Payload
Propulsion
Energy
Recovery
System
Environmental
Control
VSM
VDT
CDT
Note: The information column may identify the vehicle specific dialog to show on the
return of a Report Reference. The message provides the VSM implementer the ability
to identify additional vehicle subsystems that are specific to the UA.
A3 - 157
Edition A Version 1
Information
AEP-84.1
A3.2.8 General Configuration Messages
A3.2.8.1 Message #1200, Field Configuration Request, Through Message
#1306, Vehicle Steering Configuration Implementation
AEP-84 Volume I, Section 4.1.7.1 through Section 4.1.7.11 provides Implementation
details for these messages.
A3.2.9 Miscellaneous Message Types
A3.2.9.1 Message #1400: Message Acknowledgement Implementation
The Message Acknowledgement Message is used by either the CUCS or the VSM to
acknowledge a message that requires an acknowledgement as specified by the
Message Acknowledge bit in the message wrapper.
A3.2.9.2 Message #1402: Schedule Message Update Command
Implementation
Refer to AEP-84 Volume I Section 4.1.8.3 and Section A3.1.2.4.4 of this document for
implementation guidance.
A3.2.9.3 Message #1403: Generic Information Request Message
Implementation
AEP-84 Volume I, Table 4 - 5: Message Summary and Properties provides a listing of
all the current STANAG 4586 DLI messages. The Type column in the table indicates
whether the message must be pushed or pulled. The Generic Information Request
Message (Message #1403) is used to request messages that are of the type “pull”.
An example of this implementation is that at the CUCS there is a requirement to display
the Vehicle Operating states. In order to display the most current vehicle operating
states, the CUCS sends a Generic Information Request Message (Message #1403) to
the VSM with the “Pull Message ID” set to “104”. The VSM then replies by sending a
Vehicle Operating States Message (Message #104) to the CUCS, which requested the
message.
This message shall not be used to request Message #1300, Message #1301, Message
#1302, Message #1303 or Message #1306, as those are specifically requested with
Message #1200
A3.2.10 IFF/SSR Command and Status Messages
A3.2.10.1 Message #1500, IFF/SSR Code Command through Message #1600,
IFF/SSR Status Report Implementation
AEP-84 Volume I, Section 4.1.9.1 through Section 4.1.9.5 provides Implementation
details for these messages. Also refer to Section A3.1.7, IFF Command and Status,
for additional implementation guidance for these messages.
A3.2.11 Weapon Command and Status Messages
A3.2.11.1 Message #1800, Store Specific Information Request, Through
Message #1927, SMS Secondary Status, Implementation
AEP-84 Volume I, Section 4.1.10.1 through Section 4.1.10.53 provides Implementation
details for these messages. Also refer to Section A3.1.6.5, Weapons, for additional
implementation guidance for these messages
A3.2.12 UA Group Messages
A3 - 158
Edition A Version 1
AEP-84.1
A3.2.12.1 Message #2000: IP Address and Port Assignment Request
Implementation
This message is sent by the CUCS to a CDT or UA to request a change in the IP
address and/or port used by the CDT or UA. If the receiving CDT or UA accepts the
requested change, it will update Message #540 with the new configuration. The
CDT/UA may reject the request if certain criteria are not meet. If this message is
accepted, all previous stream definitions are deleted and replaced by those in this
message.
A3.2.12.2 Message #2001: UA IP Disclosure Message Implementation
This message is sent by the UA to inform a CUCS of the data streams in the data
uplink and downlink. The primary goal is to inform the receiving entity of what is present
in the UA uplink and downlink and how to connect to those streams. Those streams
include, but are not limited to, bidirectional DLI, bidirectional audio and unidirectional
payload data.
This message shall be sent from the UA on a universal multicast IP address and port
(e.g., 225.200.1.0:51017). It shall be sent once for each stream since a station (or the
UA) may have multiple streams available.
This message shall be sent by the Control Data Link (CDT) to inform the local
controlling processor (e.g., CUCS) of the DLI data streams used to control the CDT.
This message will also indicate the IP routing the CDT will use to send/receive nonCDT data to/from the UA. Those non-CDT data streams include, but are not limited to,
bidirectional DLI for the UA and VDT, bidirectional audio and unidirectional payload
data.
This message shall be sent by the CDT on a different universal multicast IP address
and port than used by the UA (x.x.x.x:x).
Additional detail on the streams will have to be pulled from the streams themselves
(e.g., the KLV portion of the video downlink streams).
A3.2.13 Generic Product Transport Mechanism Implementation
Many standards exists in the public and military domain that define various sensor
product structures; however, there seems to be a gap when it comes to finding a
generic transport mechanism using UDP (User Datagram Protocol) to transport sensor
product data that is not in the form of a data stream and especially when the sensor
product is on demand or event based.
To address this gap, a simple protocol, called “Generic Product Transfer (GPT), is
defined that leverages STANAG 4586 to provide a transport mechanism for payloads
that lack this capability.
Implementation guidance for GPT is provided in AEP-84 Volume I, Attachment 4-3.
A3 - 159
Edition A Version 1
AEP-84.1
ANNEX 4
IMPLEMENTATION GUIDELINES FOR AEP-84 VOLUME II
A4 Implementation Guidelines for the AEP-84 Volume II
Presence Vector
In order to reduce data link bandwidth, the concept of a presence vector to allow
message length control was introduced in each data link message. The presence
vector was added to the messages to allow dynamic message length control. It
provides the sender a method to not send data that is not applicable in the current
message context or is not supported, thereby potentially saving transmission
bandwidth and processing time. An example would be an air vehicle that supports
only one propulsion engine with a single speed. The vehicle should disable all the
fields related to Engines 2, 3 and 4. Then instead of sending all 37 fields of Message
#3007, it would set the presence vector to send only the fields related to Engine 1 and
the fields that are applicable to engine 1, e.g., Propeller Pitch Angle.
Presence vectors can also be used to remove fields which are not used or relevant per
values in other fields in the message. For example, if configuring a circular loiter
pattern, several of the fields in Message #2017 are not used and do not need to be
transmitted:
In the case of a message with repeated fields, such as Message #2012, only one
presence bit is assigned to the repeat count field and all the associated repeated fields.
Other uses of the presence vector are not supported. Specifically, the presence vector
should not be used to omit data that is unchanged or “stale”.
The CUCS is required to support the presence vector capability and demonstrate this
support via the minimum test set described in the SRD AEP-84.2 Validation/Test
Guideline Document. However, should customer or regulatory test requirements for
support of the presence vector prove prohibitive for a specific system, use of the
Presence Vector Support field in Message #1 and Message #2, respectively, may be
used to enforce this field to be ignored in all messaging between the CUCS and VSM
for a given system. The logic applied to the Presence Vector Support fields is as
follows:
CUCS Indicates
Presence Vector
Support
VSM Indicates
Presence Vector
Support
Both CUCS and VSM
utilize the presence
vector within their
messaging to support
variable
length
messaging
CUCS Indicates
Presence Vector
Support
VSM Indicates No
Presence Vector
Support
Both CUCS and VSM
ignore the Presence
Vector field and treat
all PVs as if all bits are
set (note that the bits
need not be set by
sender; the receiver
A4 - 1
Edition A Version 1
AEP-84.1
will treat them as if they
are set, regardless)
CUCS Indicates No
Presence Vector
Support
VSM Indicates
Presence Vector
Support
Both CUCS and VSM
ignore the Presence
Vector field and treat
all PVs as if all bits are
set (note that the bits
need not be set by
sender; the receiver
will treat them as if they
are set, regardless)
A4.1 Functional Description
A4.1.1 Network Configuration
Prior to discovery and initialization of VSM/UA, the network should be configured as
per Section 3.8, Network Configuration, of the SRD AEP-84.1 main document.
A4.1.2 CUCS/VSM Initialization and Connection
Once a CUCS manufacturer has developed a CUCS software component and verified
its correct operation through the compliance testing process, the CUCS may be
connected to a STANAG 4586 compliant VSM. A physical connection may be required
between the two components hosting the CUCS and VSM functionality dependent on
their physical location, and then a software “socket” connection must be made between
the two components. Once the data “pipeline” has been established between the
CUCS and the VSM, there is a requirement to configure the CUCS to work within the
limits of the specified UCS system. The CUCS must request and receive authorization
to control an UA and or its payload(s) through the VSM.
A4.1.2.1 Defining Entities
The term entity is used as a generic term to refer to any of the following conceptual
components in STANAG 4586:






CUCS – Core Unmanned Control Segment
VSM – Vehicle Specific Module
UA – Unmanned Aircraft / Unmanned Vehicle / Unattended Ground Sensor
Platform
CDT – Control Data Terminal
VDT – Vehicle Data Terminal
Payload Station
A4.1.2.2 Message Addressing
Each DLI message contains ID fields that identify the sender and the receiver of a
message. These IDs are contained in the header in the Source ID and Destination ID
fields.
A4 - 2
Edition A Version 1
AEP-84.1
The Source ID must always be set to the ID of the entity that is sending the message.
It cannot be set to the Null ID or the Broadcast ID.
The Destination ID should be set to:


The ID of the entity that is intended to receive the message, or
The Broadcast ID (0xFFFFFFFF) which can be used when the sender may not
know the destination’s ID or a message may be intended for multiple recipients.
For instance, when a CUCS is broadcasting its presence to any UA, it doesn’t
know the Vehicle ID in advance.
Note that all entity IDs must be unique to enable interoperability.
A4.1.2.3 Entity Connection Management
There are four phases involved in managing a connection between a CUCS and a
VSM/UA/CDT/VDT/payload station.
The phases are:




Discovery
Downloading Configuration Data
Establish Connection
Release
During these phases the CUCS will discover an entity and its capabilities. The CUCS
can establish a connection with the entity. The options are:
Entity
UA
Connection Type
LOI4 Monitor
UA
LOI4 Control
UA
Payload Station
Payload Station
Payload Station
CDT/VDT
CDT/VDT
LOI5 Monitor
LOI2
LOI3 Monitor
LOI3 Control
Monitor
Control
Description
Monitor the UA without takeoff/
landing
Control the UA without takeoff/
landing
Monitor the UA with takeoff/landing
Passive receipt of payload data
Monitor the payload station
Control the payload station
Monitor the data terminal
Control the data terminal
The connection type can be changed to another type or the connection can be
released.
The figure below shows an example sequence where CUCS monitors a UA. In this
use case, the CUCS needs to control a CDT and establish a data link between it and
the UA. Once the link has been created, the CUCS can discover the UA and proceed
to request the LOI 5 monitor connection.
A4 - 3
Edition A Version 1
AEP-84.1
CUCS Discovers CDT
CUCS Download CDT’s
Configuration Data
CUCS Requests Control of
CDT
CUCS Changes CDT’s Link
Settings (e.g. Frequencies,
Direction, etc…)
CUCS Discovers UA
CUCS Downloads UA’s
Configuration Data
CUCS Requests LOI 4
Monitor Connection
Figure A4 - 1: Example Sequence to Setup a CDT and Monitor a UA
A4.1.2.3.1 Connection Phase 1: Discovery
In the first phase, a CUCS will broadcast messages to discovery which entities are
reachable on the network and what level of control the CUCS can request.
A4.1.2.3.1.1 Discovering VSMs, UA and Payload Stations
To discover a VSM, UA and/or payload station, the CUCS sends Message #1 with all
IDs (except the CUCS ID) set to the Broadcast ID.
Note that the CUCS should not omit fields from this broadcast message since the
receiving entity may not support the presence vector.
Unique
ID
0001.00
0001.01
0001.04
0001.05
Name
Value
Presence Vector
Time Stamp
VSM ID
Data Link ID
0xFFFFFF
[Timestamp]
Broadcast ID
Broadcast ID or Null ID
A4 - 4
Edition A Version 1
AEP-84.1
0001.06
0001.07
0001.08
0001.16
0001.12
0001.13
0001.18
Vehicle Type
Vehicle Subtype
Requested/Handover LOI
Requested/Handover
Access
Requested Flight Mode
Controlled Station 1-16
Component Number
Sub-Component Number
Payload Class
Asset Mode
Wait for Vehicle Data Link
Transition Coordination
Message
CUCS Type
CUCS Subtype
Presence Vector Support
0001.21
Controlled Station 17-32
0001.17
0001.09
0001.19
0001.20
0001.14
0001.15
0001.11
0
0
0x0 (Unspecified)
0 (Unspecified)
1 = All Modes
0xFFFFFFFF (All stations)
0xFFFFFFFF (All stations)
0xFFFFFFFF (All stations)
0 = Not Specified/NA
3 = Broadcast Request
0 (N/A)
[Type of CUCS]
[Subtype of CUCS]
0 = If the CUCS doesn’t support the
presence vector
1 = If the CUCS supports the presence
vector
0xFFFFFFFF (All stations)
Any VSM/UA/Payload Station that receives this message will respond with Message
#2 for each entity indicating the authorized LOI for the CUCS. The LOI Authorized
field indicates which LOIs the CUCS can currently request for the entity specified by
the ID fields.
Note: If the CUCS indicated that it does not support the presence vector the response
message (and all future messages from the entity to this CUCS must send all fields).
The response will look like this:
Unique
ID
Name
Value
0002.00
Presence Vector
0xFFFFFF
0021.01
Time Stamp
[Timestamp]
0021.04
VSM ID
<VSM ID> (if applicable)
0021.05
Data Link ID
<Data Link ID> (if applicable)
0021.13
Access Authorized
<Level of access authorized to CUCS>
0021.09
Access Granted
0 = N/A
0021.06
LOI Authorized
<LOIs authorized to the CUCS> (LOI 2 and
3 not applicable)
0021.07
LOI Granted
<LOIs granted to the CUCS> (LOI 2 and 3
not applicable)
A4 - 5
Edition A Version 1
AEP-84.1
0021.16
Flight Modes Granted
1=All Modes (or send multiple messages
with each applicable flight mode)
0021.08
Controlled Station 1-16
UA Platform (0x00000000)
0002.07
Component Number
0
0002.08
Sub-Component
Number
0
0021.12
Payload Class
0=Not Specified
0021.09
Access Requested
0x04 Broadcast Response
0021.10
Vehicle Type
<UA’s vehicle type>
0021.11
Vehicle Subtype
<UA’s vehicle subtype>
0002.01
CUCS Type
<Requesting CUCS type>
0002.02
CUCS Subtype
<Requesting CUCS subtype>
0002.05
Presence Vector
Support
0002.06
Controlled Station 17-32
0 = If the VSM doesn’t support the
presence vector
1 = If the VSM supports the presence
vector
0
The Message #2 is followed by a Message #3 to indicate the vehicle’s tail number.
Unique
ID
Name
Value
0020.05
Vehicle ID Update
<UA’s ID>
0020.06
Vehicle Type
<UA’s vehicle type>
0020.07
Vehicle Subtype
<UA’s vehicle subtype>
0020.08
Owning ID
<Owning ID>
0020.09
Tail Number
<Tail Number>
0020.10
Mission ID
<Mission ID>
0020.11
ATC Call Sign
<ATC Call Sign>
0020.12
Configuration Checksum <Configuration Checksum>
Note that the Vehicle ID Update (Unique ID 0020.05) field is used for VSMs that use
Logical Vehicle IDs. If a VSM or UA doesn’t use Logical Vehicle IDs, always keep this
field set to the same value as the Vehicle ID field (Unique ID 0020.02). Refer to the
Logical Vehicles section for more information.
A4 - 6
Edition A Version 1
AEP-84.1
A VSM will respond with a unique Message #2 for each payload station. If a payload
station is comprised of multiple components and/or sub-components, the VSM should
respond with a Message #2 for each combination.
A Message #2 response for a payload station without a component/sub-component
hierarchy will look like this:
Unique
ID
Name
Value
0002.00
Presence Vector
0xFFFFFF
0021.01
Time Stamp
[Timestamp]
0021.04
VSM ID
<VSM ID> (if applicable)
0021.05
Data Link ID
<Data Link ID> (if applicable)
0021.13
Access Authorized
<Level of access authorized to CUCS>
0021.09
Access Granted
0 = N/A
0021.06
LOI Authorized
<LOIs authorized to the CUCS> (LOI 4/5
not applicable)
0021.07
LOI Granted
<LOIs granted to the CUCS> (LOI 4/5 not
applicable)
0021.16
Flight Modes Granted
0=No Modes
0021.08
Controlled Station 1-16
<Station number – lower half>
0002.07
Component Number
<Component number>
0002.08
Sub-Component
Number
<Sub-Component number>
0021.12
Payload Class
<The class of payload>
0021.09
Access Requested
0x04 Broadcast Response
0021.10
Vehicle Type
<UA’s vehicle type>
0021.11
Vehicle Subtype
<UA’s vehicle subtype>
0002.01
CUCS Type
<Requesting CUCS type>
0002.02
CUCS Subtype
<Requesting CUCS subtype>
0002.05
Presence Vector
Support
0002.06
Controlled Station 17-32
0 = If the VSM doesn’t support the
presence vector
1 = If the VSM supports the presence
vector
<Station number – upper half>
A4 - 7
Edition A Version 1
AEP-84.1
Note that a VSM can send one Message #2 for all payload stations if the fields are the
same for each station. Otherwise, it can send a separate Message #2 for each station.
The VSM then sends a Message #21001 for each Payload Station to indicate its
payload type:
Unique ID
Name
Value
00300.05
Payload Count
<All the Stations that are installed>
00300.06
Station Number 1-16
<One station>
21001.04
Component Number
0
21001.04
Sub-Component
Number
0
00300.10
Device Number
<Device number>
00300.07
Payload Class
<Payload class>
21001.01
Payload Type
<Payload type>
21001.02
Payload Subtype
<Payload subtype>
21001.03
Payload Name
<Name of payload>
00300.08
Station Door
Either 1 (Yes) or 0 (No)
00300.09
Number of Devices on
this Station
<Number of devices on this payload>
21001.06
Focus Distance Change
Rate
<Rate of change of the focus distance>
21001.07
Horizontal Zoom
Change Rate
<Rate of change of the zoom>
21001.07
Number of Discrete
Fields of View
<The number of discrete fields of view of
this payload>
21001.09
Horizontal Field of View
[Field of view #n] (Note - Optional and
potentially repeated based on field
21001.07)
21001.11
Vertical Field of View
[Field of view #n] (Note - Optional and
potentially repeated based on field
21001.07)
21001.10
Station Number 17-32
<Station Number portion – if applicable>
A4.1.2.3.1.2 Discovering Data Links
A data link defines a potential “link” between two data terminals – a CDT and a VDT.
A data terminal may provide the ability to have one or more data links. For instance,
A4 - 8
Edition A Version 1
AEP-84.1
a data terminal may know how to communicate with two different vehicle types (e.g.,
a Northrop Grumman Global Hawk and a Boeing Insitu Scan Eagle). It is possible that
each of these links require different parameters such as frequency ranges, etc. hence
they need to be identified separately.
On the other hand, it is possible that the data terminal isn’t configured for a specific
type of vehicle. In these cases, the data terminal can report a single data link without
any specific vehicle type. In these cases, there is a 1:1 relationship between a data
link and a data terminal.
Data links are discovered by a CUCS with a Message #28000 with the Vehicle ID,
VSM ID and Data Link ID set to the Broadcast ID.
Unique ID
Name
Value
00404.10
Requested/Handover
Access
0=Unspecified
00404.12
VSM / Vehicle ID
Broadcast ID
00404.11
Asset Mode
3=Broadcast Request
00404.07
Vehicle Type
0
00404.08
Vehicle Subtype
0
Any data terminal or VSM that receives this message will respond with Message
#28001 for each possible data link. The Access Authorized field (Unique ID 28001.01)
indicates whether the CUCS can request control or not.
Unique ID
Name
Value
28001.06
VSM / Vehicle ID
Null ID if CDT or <Vehicle ID> if VDT
28001.01
Access Authorized
<Access level authorized>
28001.02
Access Granted
<Access type granted>
28001.03
Access Requested
<Request from CUCS> (Mirror of
00404.11)
00500.07
Terminal Type
0 if CDT, or
1 if VDT
00500.08
Data Link Type
<Data Link’s type>
28001.05
Data Link Subtype
<Data Link’s subtype>
00500.09
Data Link Name
<Data Link’s name>
00500.10
Antenna Type
1 if Omni, or
2 if Direction
A4 - 9
Edition A Version 1
AEP-84.1
28001.04
Pedestal Index
<ID of the pedestal>
00500.11
Vehicle Type
<UA’s vehicle type> if VDT, otherwise 0
00500.12
Vehicle Subtype
<UA’s vehicle subtype> if VDT, otherwise 0
28001.07
Data Link Control
Availability
0 if CDT/VDT is available for control
1if CDT/VDT is unavailable for control
Note that it is not defined how a CUCS will handle receiving an invalid Authorized
LOI/Access combination, such as LOI 5 for a Payload Station. The CUCS may ignore
the message or it may simply ignore the fields or bits that don’t make sense. In general,
to attain interoperability, it is the VSMs responsibility to ensure the data in the message
is never invalid. Other special cases to avoid are:


Specifying an LOI for a data link with Message #2 (this is done with Message
#28001)
Specifying LOI 3 for an Air Vehicle Platform
A4.1.2.3.2 Connection Phase 2: Downloading Configuration Data
A CUCS can download Configuration Data from an entity using Message #40000. This
typically happens before the CUCS requests an LOI connection for the UA so that the
CUCS can understand the capabilities of the entity and tailor its user interface.
A typical sequence has three stages as seen below:
Figure A4 - 2: Typical Sequence for Downloading Configuration Data
A4.1.2.3.2.1 Stage 1: Initiate Download
In this stage, the CUCS begins the request with Message #40000.
Unique ID
Name
Value
40000.07
Request LOI
<Desired LOI>
A4 - 10
Edition A Version 1
AEP-84.1
01200.06
Request Type
1 if Monitoring only
2 if Controlling
01200.07
Requested Message
0 (N/A)
01200.08
Requested Field
0 (N/A)
01200.09
Station Number 1-16
0x0000 (for UA) or <The station number(s)
for stations 1-16
40000.01
Component Number
0 or <The Component Number>
40000.02
Sub-Component
Number
0 or <The Sub-Component Number>
01200.10
Sensor Select
0 (N/A)
00500.11
Vehicle Type
<UA’s vehicle type> if VDT, otherwise 0
00500.12
Vehicle Subtype
<UA’s vehicle subtype> if VDT, otherwise 0
40000.06
Activity ID
0
40000.03
Station Number 17-32
0x0000 (for UA) or <The station number(s)
IDs for stations 17-32>
A CUCS cannot request vehicle and payload station configuration with the same
message. Note that there is no requirement specifying if a CUCS or VSM needs to
support downloading configuration data from different entities simultaneously.
It is possible that an entity has different configuration data for each LOI so the CUCS
should request the configuration data for any LOI that it expects it will request. In
practice, many entities will provide the same configuration data for any LOI requested.
Note that it is not possible to download configuration data for different LOIs of the same
entity simultaneously since the CUCS has no way of associating configuration
messages to LOI.
It is entirely acceptable to download the configuration data for one entity at a time (i.e.,
waiting for the download to be completed before initiating the next download).
A4.1.2.3.2.2 Stage 2: Send Configuration Messages
Upon receiving a request from the CUCS, an entity should begin to send the
Configuration Data messages. This includes the following messages:
Name
Number
Vehicle
Station
Data
Link
Vehicle Configuration
#3000
Yes
No
No
UA Route Configuration
#43001
Yes
No
No
Report Controllable Element
#42003
Yes
Yes
No
A4 - 11
Edition A Version 1
AEP-84.1
Payload Configuration
#21001
No
Yes
No
EO/IR Configuration State
#21100
No
If EO/IR
No
Field Configuration Integer
Response
#41000
Field Configuration Float
Response
#41001
Field Configuration
Enumerated Response
#41002
Field Configuration Unsigned
Response
#41003
Field Configuration Character
Response
#41004
Integer Enumeration Response
#41006
If needed
This stage may take a long time to complete if the entity has a large amount of
configuration data. It is highly recommended that entities use the acknowledgment
system to ensure that all data has been received by the CUCS before moving on to
the next stage.
Note that IDs in these messages are particularly important since a CUCS could be
downloading multiple configurations simultaneously.
Refer to Section A4.1.2.4 Downloading Configuration Data to learn more about the
contents of these messages.
A4.1.2.3.2.3 Stage 3: Send Configuration Complete
When the CUCS has received all of the configuration data, the entity sends Message
#41005 to indicate the transfer is complete.
Unique
ID
Name
Value
01203.04
VSM ID
<VSM ID> (if applicable)
01203.05
Data Link ID
<Data Link ID> (if applicable)
01203.06
Station Number 1-16
0x0000 (for UA) or <The station
number(s) IDs for stations 1-16>
41005.01
Component Number
<Component number>
41005.02
Sub-Component Number
<Sub component number>
01203.07
Vehicle Type
<UA’s vehicle type>
01203.08
Vehicle Subtype
<UA’s vehicle subtype>
A4 - 12
Edition A Version 1
AEP-84.1
41005.03
Station Number 17-32
0x0000 (for UA) or <The station
number(s) IDs for stations 17-32>
Note that since the CUCS does not know how many messages will arrive in Stage 2,
it is the responsibility of the entity to ensure that all of the messages have arrived
before sending Message #41005. This is typically accomplished by requesting
acknowledgements from the CUCS for each message.
Once the CUCS has received Message #41005, it can process the configuration data.
If the CUCS has requested to download the configuration data for multiple stations
simultaneously, the entity can choose to send a single Message #1203 with multiple
station numbers or a separate Message #1203 for each station number. An entity
cannot indicate that the configuration download is complete for a vehicle and payload
station with the same Message #1203 message due to the nature of the station number
field.
A4.1.2.3.2.4 Caching Configuration Data
A CUCS may choose to save the downloaded configuration data to disk; however, in
cases where the configuration data can change, the CUCS may need to be aware if
the entity’s data is different than the stored version. The Configuration Checksum
(0020.12) can potentially be used to identify if a vehicle’s configuration has changed,
however, there is no similar mechanism for a payload station or data link.
A4.1.2.3.3 Connection Phase 3: Establish Connection
A CUCS can request to establish an LOI connection at any time. The receiving entity
can choose to accept or deny the request. A CUCS should only request an LOI
connection that it has been authorized to request.
A4.1.2.3.3.1 Requesting LOI Connection for VSMs, UA and Payload Stations
To establish an LOI connection between a CUCS and a VSM, UA and/or Payload
Station, the CUCS sends Message #1.
Unique
ID
Name
Value
0001.04
VSM ID
<VSM ID> (if applicable)
0001.05
Data Link ID
Null ID
0001.06
Vehicle Type
<Vehicle Type> (as received in discovery)
0001.07
Vehicle Subtype
<Vehicle Subtype> (as received in
discovery)
0001.08
Requested/Handover LOI
<Desired LOI level>
0001.16
Requested/Handover
Access
1=Monitor, or
Requested Flight Mode
1 = All Modes
0001.17
2=Control & Monitor
A4 - 13
Edition A Version 1
AEP-84.1
0001.09
Controlled Station 1-16
0x0000 (for UA) or <The station
number(s) IDs for stations 1-16>
0001.19
Component Number
<Component number>
0001.20
Sub-Component Number
<Sub-component number>
0001.14
Payload Class
<Payload class>
0001.15
Asset Mode
1=Request
0001.11
Wait for Vehicle Data Link
Transition Coordination
Message
0 (N/A)
0001.12
CUCS Type
<Type of CUCS>
0001.13
CUCS Subtype
<Subtype of CUCS>
0001.18
Presence Vector Support
0 = If the CUCS doesn’t support the
presence vector
1 = If the CUCS supports the presence
vector
0001.21
Controlled Station 17-32
0x0000 (for UA) or <The station
number(s) IDs for stations 17-32>
Any VSM/UA/Payload Station that receives this message will respond with Message
#2. If the request was granted, the LOI Granted (Unique ID 0021.07) field should
specify the new LOI connection level and the Access Granted field should be updated
accordingly. If the request is denied, the entity can respond with the currently granted
level.
Unique
ID
Name
Value
0021.04
VSM ID
<VSM ID> (if applicable)
0021.05
Data Link ID
<Data Link ID> (if applicable)
0021.13
Access Authorized
<Level of access authorized to CUCS for
the entity identified by the IDs in this
message>
0 if Not authorized, or
1 if Monitor Only, or
2 if Control & Monitor
0021.09
Access Granted
<Level of access granted to CUCS for the
entity identified by the IDs in this message>
1 if Monitor Only
A4 - 14
Edition A Version 1
AEP-84.1
2 if Monitor & Control (as defined by the
LOI)
0021.06
LOI Authorized
<LOIs authorized to the CUCS for the entity
identified by the IDs in this message>
0021.07
LOI Granted
<LOIs granted to the CUCS for the entity
identified by the IDs in this message>
0021.16
Flight Modes Granted
<Flight modes granted>
Typically 0=No Modes or 1=All Modes
0021.08
Controlled Station 1-16
<Station number – lower half>
0002.07
Component Number
<Component number>
0002.08
Sub-Component
Number
<Sub-Component number>
0021.12
Payload Class
<The class of payload>
0021.09
Access Requested
<Echo back of field 0001.15 from Message
#1>
0021.10
Vehicle Type
<UA’s vehicle type>
0021.11
Vehicle Subtype
<UA’s vehicle subtype>
0002.01
CUCS Type
<Requesting CUCS type>
0002.02
CUCS Subtype
<Requesting CUCS subtype>
0002.05
Presence Vector
Support
0002.06
Controlled Station 17-32
0 = If the VSM doesn’t support the
presence vector
1 = If the VSM supports the presence
vector
<Station number – upper half>
Note that if a request is made for multiple payload stations, the response may be
combined into a single Message #2 response or multiple Message #2 responses.
Also note that a CUCS does not typically need to request control of the UA to request
control of the UA’s payload stations.
For a CUCS to receive an explicit rejection message, it should request an
acknowledgement in Message #1. The entity will then send Message #17000
indicating the request was rejected:
Unique ID
Name
Value
1400.06
Original Message Time
Stamp
<Timestamp in message #1>
1400.08
Original Message Type
1
A4 - 15
Edition A Version 1
AEP-84.1
17001.01
Acknowledgement Type
3 (Message Received, but Rejected)
In some cases, the CUCS may want to override an LOI connection of the
UA/VSM/Payload Station. This would typically be for specific LOI connections of a
UA/VSM/Payload Station where only one CUCS can maintain the connection at a time.
For instance, it may be necessary to override the LOI 5 connection from another CUCS
if the original CUCS malfunctions. This is almost the same as requesting control with
Message #1, except that the Controlled Station Mode field (Unique ID 0001.10) is
different:
Unique ID Name
Value
0001.15
2 = Override
Asset Mode
The UA/VSM/Payload Station will respond in the same way it would to a normal control
request. If the CUCS succeeds in overriding control, the UA/VSM/Payload Station
should notify the original CUCS that it has now lost control. It can do this by sending
an unsolicited Message #2 with:
Unique
ID
Name
Value
0021.13
Access Authorized
3=Relinquish/Handover
0021.09
Access Granted
1 = Monitor Only, or
0= N/A (if monitor has been revoked)
Note that UA/VSM/Payload Station should avoid granting control to a CUCS
unexpectedly. For instance, if a CUCS has an LOI4 Monitor connection with a UA it
may not handle the case where the UA arbitrarily grants the LOI4 Control & Monitor
connection level without an explicit request from the CUCS.
A4.1.2.3.3.2 Requesting Control of Data Links
A CUCS can request control of a data link with Message #28000. A CUCS should
only request control if it is available for that CUCS (as determined from receiving a
Message #28001 in the earlier broadcast phase).
Unique
ID
Name
Value
0404.10
Requested/Handover
Access
2=Control
0404.12
VSM / Vehicle ID
<VSM/Vehicle ID> (if applicable)
0404.11
Asset Mode
1=Request
0404.07
Vehicle Type
<Vehicle Type> (if applicable)
A4 - 16
Edition A Version 1
AEP-84.1
0404.08
Vehicle Subtype
<Vehicle Subtype> (if applicable)
When a data terminal receives this message and recognizes the identified data link, it
will respond with a Message #28001 for that data link. To grant the request, the data
terminal will set the Access Granted field (Unique ID 28001.02) to 2=Control.
Unique ID
Name
Value
28001.02
Access Granted
2 = Control
For a CUCS to receive an explicit rejection message, it should request an
acknowledgement in Message #28000. The entity will then send Message #17000
indicating the request was rejected.
In some cases, the CUCS may want to override control of the data terminal. For
instance, it may be necessary to override control of a VDT from another CUCS if the
original CUCS malfunctions. This is almost the same as requesting control with
Message #2800, except that the Asset Mode field (Unique ID 0404.11) is different:
Unique ID Name
Value
0404.11
2 (Override Control)
Asset Mode
The data terminal will respond in the same way it would to a normal control request. If
the CUCS succeeds in overriding control, the data terminal should notify the original
CUCS that it has now lost control. It can do this by sending an unsolicited Message
#28001 with:
Unique ID
Name
Value
28000.02
Access Granted
0= N/A, or
1= Monitor
A4.1.2.3.4 Connection Phase 4: Release
A connection between a CUCS and an entity can be released for reasons such as:




The CUCS requests the connection to be released
The entity spontaneously releases the connection
Another CUCS requests to override the connection
The CUCS hands control over to another CUCS
A4.1.2.3.4.1 Releasing a LOI Connection for VSMs, UA and Payload Stations
To request releasing an LOI connection of a VSM/UA/Payload Station, the CUCS
sends Message #1.
Unique
ID
Name
Value
A4 - 17
Edition A Version 1
AEP-84.1
0001.04
VSM ID
<VSM ID> (if applicable)
0001.05
Data Link ID
Null ID
0001.06
Vehicle Type
<Vehicle Type> (as received in discovery)
0001.07
Vehicle Subtype
<Vehicle Subtype> (as received in
discovery)
0001.08
Requested/Handover LOI
<Desired LOI level to release>
0001.16
Requested/Handover
Access
<Access level to release>
0001.17
Requested Flight Mode
1 = All Modes
0001.09
Controlled Station 1-16
0x0000 (for UA) or <The station number(s)
IDs for stations 1-16>
0001.19
Component Number
<Component number>
0001.20
Sub-Component Number
<Sub-component number>
0001.14
Payload Class
<Payload class>
0001.15
Asset Mode
0=Relinquish/Handover
0001.11
Wait for Vehicle Data
Link Transition
Coordination Message
0 (N/A)
0001.12
CUCS Type
<Type of CUCS>
0001.13
CUCS Subtype
<Subtype of CUCS>
0001.18
Presence Vector Support
0 = If the CUCS doesn’t support the
presence vector
1 = If the CUCS supports the presence
vector
0001.21
Controlled Station 17-32
0x0000 (for UA) or <The station number(s)
IDs for stations 17-32>
The VSM/UA/Payload Station releases the LOI connection by sending Message #2
indicating that the connection level has been relinquished.
Unique
ID
Name
Value
0021.13
Access Authorized
3=Relinquish/Handover
A4.1.2.3.4.2 Release Control of Data Links
To request releasing control of a data link, the CUCS sends Message #28000.
A4 - 18
Edition A Version 1
AEP-84.1
Unique
ID
Name
Value
0404.10
Requested/Handover
Access
2=Control
0404.12
VSM / Vehicle ID
<VSM/Vehicle ID> (if applicable)
0404.11
Asset Mode
0=Relinquish/Handover
The CDT/VDT responds to this request by sending a Message #28001 with the Data
Link Control Availability field (Unique ID 28001.07) indicating that the request has been
granted.
Unique ID
Name
Value
28001.06
VSM / Vehicle ID
Null ID if CDT or <Vehicle ID> if VDT
28001.01
Access Authorized
0=Connection Not Authorized
28001.02
Access Granted
0=N/A
28001.03
Access Requested
0=Unspecified
…
…
…
28001.07
Data Link Control
Availability
2=Request Granted
The CDT/VDT can also release control at any time by sending a Message #28001
with the Data Link Control Availability field (Unique ID 28001.07) set to unavailable.
Unique ID
Name
Value
28001.06
VSM / Vehicle ID
Null ID if CDT or <Vehicle ID> if VDT
28001.01
Access Authorized
0=Connection Not Authorized
28001.02
Access Granted
0=N/A
28001.03
Access Requested
0=Unspecified
…
…
…
28001.07
Data Link Control
Availability
1=Unavailable for Control
A4.1.2.4 Downloading Configuration Data
Not all UA are built with the same capabilities. Some can fly extremely high and far
while others fly low for short durations. Some are capable of following preprogrammed routes while some can only loiter. Some have EO/IR cameras that are
capable of firing lasers while some carry CBRN sensors to detect harmful substances.
A4 - 19
Edition A Version 1
AEP-84.1
A CUCS needs to be able to understand these capabilities and constraints so that it
can provide an appropriate User Interface to the operator. In STANAG 4586, a
UA/VSM/CDT/VDT/Payload Station declares its configuration to a CUCS with the
following configuration messages:
Name
ID
Vehicle Station
Data
Link
Vehicle Configuration
3000
Yes
No
No
Payload Configuration
21001
No
Yes
No
EO/IR Configuration State
21100
No
If EO/IR
No
Field Configuration Integer Response 41000
Field Configuration Float Response
41001
Field Configuration Enumerated
Response
41002
Field Configuration Unsigned
Response
41003
Field Configuration Character
Response
41004
Integer Enumeration Response
41006
If needed
The combined set of information that is transmitted via these messages is often
referred to as an entity’s Configuration Data. These messages are sent during the
Downloading Configuration Data phase of Entity Connection Management.
Note that a CUCS cannot send Configuration Messages to the entity.
A4.1.2.4.1 UA Specific Configuration Messages
Message #3000 (Vehicle Configuration) is used to indicate some UA specific
configuration information that cannot be conveyed via the generic messages. This
contains information such as the number of engines and the maximum fuel/battery
capacity.
Message #43001 (UA Route Configuration) is used to provide configuration
information about the types of routes that the UA support, including information such
as whether or not the UA supports multiple routes of the same type and the maximum
number of waypoints supported by each type.
Message #42003 (Report Controllable Element) is used to indicate elements of the UA
that can be controlled by joystick input. This could be elements such as Elevators,
Rudders, Throttle, etc.
A4.1.2.4.2 Payload Specific Configuration Messages
Message #21000 (Payload Configuration) is used to indicate the type of each Payload
Station that is available for configuration. For instance, a payload could be a
SAR/GMTI payload or a CBRN sensor.
A4 - 20
Edition A Version 1
AEP-84.1
If the payload is an EO, IR or EO/IR payload, additional configuration information will
be conveyed in Message #21100 (EO/IR Configuration State).
Message #42003 (Report Controllable Element) is used to indicate elements of the
Payload Station that can be controlled by joystick input. This could be elements such
as Pan, Tilt, Zoom, etc.
A4.1.2.4.3 Data Terminal Specific Configuration Messages
There are no CDT/VDT specific configuration messages. Configuration is achieved
entirely through the generic messages.
A4.1.2.4.4 Generic Configuration Messages
Each type of entity is assumed to support a specific set of messages as defined by
the table below:
Type
Messages Supported By Default
UA
2000, 2005, 2007-2019, 3001-3016, 4000,
4001, 5000, 5001, 6000, 7000, 7001, 9000,
9001, 11000, 11001, 11101, 12000-12003,
12101, 13000-13011, 14000, 15000, 15001,
16000, 16001, 16002, 18000-18003, 18100,
18101, 18200, 18300, 18400-18403, 18500
EO, IR, EO/IR Payload
2013, 4000, 4001, 15000, 15001, 16000,
16001, 16002, 19001, 19100, 19101,
19700, 19800, 19801, 21100, 21101,
21600, 21700, 21800,
SAR Payload
15000, 15001, 16000, 16001, 16002,
19200, 19700, 21600, 21700
Stores Management Payload
15000, 15001, 16000, 16001, 16002,
19700, 21700, 24000, 26000
Communications Relay
Payload
15000, 15001, 16000, 16001, 16002,
19400, 19401, 19700, 21400, 21700,
21401, 21402
CBRN Payload
15000, 15001, 16000, 16001, 16002,
19700, 21700
15000, 15001, 16000, 16001, 16002,
19700, 21700
15000, 15001, 16000, 16001, 16002,
19000, 21000
CBRN Standoff Payload
Payload Bay Door
Recorder Payload
15000, 15001, 16000, 16001, 16002,
19500, 21500, 21501, 21700
CDT/VDT
15000, 15001, 16000, 16001, 16002,
30000-30400, 32000-32400
Table A4 - 1: Entity Types
A4 - 21
Edition A Version 1
AEP-84.1
A CUCS should assume that each UA/Payload Station/CDT/VDT provides full support
of each message, field and enumeration for their respective message sets unless
otherwise declared during the Downloading Configuration Data phase.
Configuration Data is communicated through the use of the following generic
configuration messages:
Name
ID
Field Configuration Integer Response
#41000
Field Configuration Float Response
#41001
Field Configuration Enumerated Response #41002
Field Configuration Character Response
#41003
Field Configuration Unsigned Response
#41004
Integer Enumeration Response
#41006
With these generic configuration messages, an entity can declare:





If a capability is not supported
If a capability is unavailable
The acceptable limits and resolution of message fields
Warning and alert thresholds of message fields
Custom enumerations for enumerated message fields
A4.1.2.4.5 Declaring That a Message Is Not Supported
If an entire message is not supported by an entity, it can send Message #44003
(Message Parameter Availability) to declare that the entire message is not supported.
Unique
ID
Name
Value
1303.06
Reported Message
<Applicable message>
1303.07
Reported Field
0
For example, if a UA does not support the IFF messages it can send the following
messages:
Message ID
Reported Message
Reported Field
44003
5000
0
44003
5001
0
44003
6000
0
A4 - 22
Edition A Version 1
AEP-84.1
Note that it is not possible to declare that a message or field is supported since
STANAG 4586 assumes that everything is supported by default.
A4.1.2.4.6 Declaring that a Field is Not Supported
If a field is not supported by an entity, it can send a #41000-#41004 Message
(depending on the type of field) to indicate that the field is not supported:
Unique ID
Name
Value
[1300|1301].07 Requested Message
or 41003.09
<Applicable message>
[1300|1301].08 Requested Field
or 41003.10
<Applicable field>
[1300|1301].09 Field Supported
or 41003.11
0 (Field Not Supported)
For instance, if a vehicle doesn’t support the capability to indicate which waypoint it is
flying “From”, it can send the following messages:
Message ID
Reported
Message
Reported Field
Field Supported
41000
4001
4
0
41000
4001
5
0
41000
4001
6
0
41003
4001
7
0
41003
4001
8
0
A4.1.2.4.7 Declaring that an Enumeration is Not Supported
If an entity does not support a field’s enumeration, it can send Message #41002 to
indicate that the enumeration is not supported:
Unique ID
Name
Value
1302.07
Requested Message
<Applicable message>
1302.08
Requested Field
<Applicable field>
1302.09
Field Supported
1 (Field Supported)
…
…
…
41002.04
Remove Enumerated
Index
<Enumeration that is not supported>
For instance, if an EO/IR payload doesn’t have a Cage Operating Mode it can send
the following:
A4 - 23
Edition A Version 1
AEP-84.1
Message
ID
Reported
Message
Reported
Field
Field
Supported
Remove
Enumerated Index
41002
19100
15
1
7
41002
21101
25
1
7
A4.1.2.4.8 Declaring That a Bit in a Bit Field Is Not Supported
If an entity does not support a specific bit in a bit field, it can send Message #41002 to
indicate that the bit is not supported:
Unique ID
Name
Value
1302.07
Requested Message
<Applicable message>
1302.08
Requested Field
<Applicable field>
1302.09
Field Supported
1 (Field Supported)
…
…
…
41002.04
Remove Enumerated
Index
<Applicable bit> (Note that this is the index
of the bit starting at 0, not the value of the
bit. e.g.,:
0=0x0001, 1=0x0002, 2=0x0004,
3=0x0008, etc.
A4.1.2.4.9 Declaring Entity Specific Enumerations
There are many cases where an entity will need to define custom enumerations. For
example, a UA will likely define Flight Termination modes in Message #2005 (Flight
Termination Command) since STANAG 4586 does not define any by default.
To declare new enumerations, an entity can use Message #41002 (Field Configuration
Enumerated Response) with the enumeration index and enumeration text.
Unique ID
Name
Value
1302.07
Requested Message
<Applicable message>
1302.08
Requested Field
<Applicable field>
1302.09
Field Supported
1 (Field Supported)
41002.03
Default Value
<Default value>
1302.10
Vehicle (Payload)
Specific Enumeration
Count
Total number of enumerations available
1302.11
Vehicle (Payload)
Specific Enumeration
Index
<New enumeration index>
A4 - 24
Edition A Version 1
AEP-84.1
1302.12
Vehicle (Payload)
Specific Enumeration
Text
<Text for the new enumeration>
1303.13
Vehicle (Payload)
Specific Help Text
<Helpful text to describe the enumeration>
41002.04
Remove Enumerated
Index
0=N/A
For example, a UA can declare two Flight Termination Modes “Parachute” and “Spiral
Down” with the following messages:
Message
ID
Reported
Message
Reported
Field
Field
Supported
Enumeration
Count
Enumeration
Index
Enumeration
Text
41002
2005
3
1
2
1
Parachute
41002
2005
3
1
2
2
Spiral
Down
41002
3005
3
1
2
1
Parachute
41002
3005
3
1
2
2
Spiral
Down
Note that an entity can only declare new enumerations for fields that list “VSM specific”
or “Payload specific” and the enumerations should be in the ranges provided.
A4.1.2.4.10 Declaring That a Capability is not Available
There are many capabilities of an entity that may be temporarily unavailable to a
CUCS. For instance, if an EO/IR payload hasn’t been powered on, it is unlikely that
the CUCS will be able to use the laser rangefinder or pointer.
A CUCS will assume that all supported functionality is immediately available to use
once a connection has been established with an entity unless the entity has declared
otherwise. The entity can do this by sending Message #44003:
Unique
ID
Name
Value
1303.06
Reported Message
<Applicable message>
1303.07
Reported Field
<Applicable field>
1303.08
Field Available
0 (Field not available) or 1 (Field available)
1303.09
Reported Enumeration
Index
<Applicable enum or bit if needed>
1303.10
Enumerated Index
Enable
-1 (Not Available)
A4 - 25
Edition A Version 1
AEP-84.1
For example, if the CUCS cannot request any laser rangefinder changes and none of
the laser rangefinder status fields are valid, the entity can send the following:
Message
ID
Reported
Message
Reported
Field
Field
Available
44003
19100
18
0
44003
19100
19
0
44003
21101
31
0
44003
21101
33
0
A4.1.2.4.11 Declaring Limits for a Field
If a UA cannot (or will not) use the complete range of a message field, it can declare
that only a smaller range is acceptable. For instance, a UA may only accept speed
commands higher than 5 m/s to prevent its engine from stalling. With this knowledge,
the CUCS can prevent the operator from entering values lower than 5 m/s.
To declare limits for a field, an entity will send either Message #41000, #41001 or
#41003 (depending on the type of field):
Unique ID
Name
Value
[1300|1301].07 Requested Message
or 41003.09
<Applicable message>
[1300|1301].08 Requested Field
or 41003.10
<Applicable field>
[1300|1301].09 Field Supported
or 41003.11
1 (Field Supported)
…
…
…
[1300|1301].10 Max Value
or 41003.12
<Maximum limit>
[1300|1301].11 Min Value
or 41003.13
<Minimum limit>
For instance, if a UA can:
 Accept speed commands between 5 m/s and 15 m/s, and
 Report Indicated and True Airspeeds from 0 m/s to 25 m/s, and
 Report ground relative northing and easting magnitudes up to 100 m/s
It can send the following configuration messages:
Message
ID
Requested Requested Field
Message
Field
Supported
Max Value
Min Value
41003
2016
30 [0.5 m/s]
10 [0.5 m/s]
13
1
A4 - 26
Edition A Version 1
AEP-84.1
41003
3009
4
1
500 [0.05 m/s]
0.0
41003
3009
5
1
500 [0.05 m/s]
0.0
41003
4000
6
1
2000 [0.05
m/s]
-2000 [0.05
m/s]
41003
4000
7
1
2000 [0.05
m/s]
-2000 [0.05
m/s]
41003
3009
15
1
2000 [0.05
m/s]
-2000 [0.05
m/s]
41003
3009
16
1
2000 [0.05
m/s]
-2000 [0.05
m/s]
A4.1.2.4.12 Declaring Alert Zones for a Field
It is often valuable for an operator to know if an important attribute is operating outside
of its nominal range. For instance, a UA may be leaking fuel if Current Propulsion
Energy Usage Rate is too high or the IMU may be defective if the Roll that is greater
than the UA is designed to allow.
An entity can identify the alert using Message #41000, #41001 or #41003:
Unique ID
Name
Value
[1300|1301].07 or
41003.09
Requested Message
<Applicable message>
[1300|1301].08 or
41003.10
Requested Field
<Applicable field>
[1300|1301].09 or
41003.11
Field Supported
1 (Field Supported)
…
…
…
[1300|1301].15 or
41003.17
High Caution Limit
<Threshold to trigger an Upper
Caution Alert >
[1300|1301].16 or
41003.18
High Warning Limit
<Threshold to trigger an Upper
Warning Alert >
[1300|1301].17 or
41003.19
Low Caution Limit
<Threshold to trigger an Lower
Caution Alert >
[1300|1301].18 or
41003.20
Low Warning Limit
<Threshold to trigger an Lower
Warning Alert >
…
…
…
A4 - 27
Edition A Version 1
AEP-84.1
[41000|41001].06 or
41003.23
Disable Alert/Caution
<Disable any/all of the zones>
An entity can indicate up to four alert zones as illustrated on the right side of Figure A4
- 3. The left side shows the meaning of the values in Message #41000, 41001 and
41003.
Max Value
Upper Warning Zone
High Warning Limit
Upper Caution Zone
High Caution Limit
Nominal Zone
Low Caution Limit
Lower Caution Zone
Low Warning Limit
Lower Warning Zone
Min Value
Figure A4 - 3: Alert Zones within a Numerical Field
Each of the four zones is optional. For example, an entity can choose to only declare
high limits or only low limits for a field or only caution zones. To indicate that a zone
is not applicable, use the Disable Alert/Caution field.
STANAG 4586 does not define the HMI for how the CUCS will bring this information
to the operator’s attention. One CUCS may display the values in different colors while
another CUCS may display a persistent window with values that are out of nominal
range.
Also note that limits cannot be defined for enumerated fields since enumerations do
not typically represent a continuous range.
A4.1.2.4.13 Declaring Help Text for a Field
In some cases, an operator could benefit from additional information about a particular
field or enumeration. For instance, if a UA reports a custom flight mode named “Evade”
the operator may benefit from the help text “UA will speed up, zig zag and change
directions constantly”.
Note that in most systems it is expected that an operator will be trained on the different
attributes of a vehicle before flight so the extra help may be redundant. Historically the
Help Text field has been more valuable for engineers that are integrating the system.
A4.1.2.5 Changing Configuration Data
In many situations an entity’s Configuration Data will change over time. This can be
for a wide variety of reasons ranging from flight mode state changes to malfunctioning
A4 - 28
Edition A Version 1
AEP-84.1
sensors. Regardless of the reason, the entity has the ability to update some
Configuration Data through the following mechanisms.
A4.1.2.5.1 Changing Field Availability
An entity can send Message #44003 to indicate that a field’s availability has
changed. It will do this by setting the fields as follows:
Unique
ID
Name
Value
1303.06
Reported Message
<Applicable message>
1303.07
Reported Field
<Applicable field> (0 does not apply)
1303.08
Field Available
Either 0 (Not Available) or 1 (Available)
1303.09
Reported Enumerated
Index
Not applicable
1303.10
Enumerated Index
Enable
Not applicable
If the Reported Field refers to an enumerated field, the Field Available will apply to all
supported enumerations in the field. This provides a simple way for an entity to disable
or enable all the enumerations at once. If the entity only wishes to enable a few of the
enumerations, refer to the next section.
For example, an EO/IR payload station may indicate that the Set Centerline Azimuth
(Unique ID 0200.05) and Set Centerline Elevation Angle (0200.06) fields are not
available if its current EO/IR Pointing Mode (0302.19) is Lat-Long Slaved.
A4.1.2.5.2 Changing Enumeration Availability
An entity can send Message #44003 to indicate that an enumeration’s availability has
changed. It will do this by setting the fields as follows:
Unique
ID
Name
Value
1303.06
Reported Message
<Applicable message>
1303.07
Reported Field
<Applicable field> (0 does not apply)
1303.08
Field Available
1
1303.09
Reported Enumerated
Index
<Applicable enumeration>
1303.10
Enumerated Index
Enable
Either -1 (Not Available) or 0 (Available)
Note that Unique ID1303.10 should not be set to “-2 = Not Implemented”. This is
reserved for during the initial configuration download.
A4 - 29
Edition A Version 1
AEP-84.1
For example, if an EO/IR payload station has reached its maximum zoom level, it can
tell the CUCS that the “2 = Zoom In” enumeration and “4 = Fast Zoom In” enumerations
for the Set Zoom (Unique ID 0200.17) field are no longer available.
A4.1.2.5.3 Changing Bit Field Availability
An entity can send Message #44003 to indicate that a bit in a Bitmapped field’s
availability has changed. This is exactly the same as changing an enumeration, except
the right most bit is considered Enumeration 0, the second right most bit is considered
Enumeration 1, and so on.
Unique
ID
Name
Value
1303.06
Reported Message
<Applicable message>
1303.07
Reported Field
<Applicable field>
1303.08
Field Available
1
1303.09
Reported Enumeration
Index
<Applicable bit> (Note that this is the index
of the bit starting at 0, not the value of the
bit. e.g.,:
0=0x0001, 1=0x0002, 2=0x0004,
3=0x0008, etc.)
1303.10
Enumerated Index
Enable
Either -1 (Not Available) or 0 (Available)
A4.1.2.5.4 Changing Field Limits
In some circumstances, an entity may be required to change the valid limits of a field.
For instance, if the vehicle’s stall speed changes it can notify the CUCS that the
minimum speed command should be changed. This can be accomplished with either
Message #41000, #41001 or #41003 depending on the field required:
Unique ID
Name
Value
[1300|1301].07 or
41003.09
Requested Message
<Applicable message>
[1300|1301].08 or
41003.10
Reported Field
<Applicable field>
[1300|1301].09 or
41003.11
Field Supported
1
[41000|41001].03 or
41003.24
Default value
<Default value within the min/max>
[1300|1301].10 or
41003.12
Max Value
<New max value>
A4 - 30
Edition A Version 1
AEP-84.1
[1300|1301].11 or
41003.13
Min Value
<New min value>
A4.1.2.5.5 Changing Warning and Caution Thresholds
Message #41000, #41001, #41003, can be pushed from the VSM to update the
warning and cautions thresholds.
A4.1.2.5.6 Changing a Previously Unsupported Capability to be Supported
While STANAG 4586 does not specifically prevent this behaviour it is recommended
that this functionality be avoided. Many UA designers and members of the 4586
community have indicated that they would not support it. Consider declaring the
capability unavailable instead of unsupported.
A4.1.3 Mission Transfer
The following list of messages are the messages that have been developed to transfer
a mission plan from a CUCS to an UA through the DLI, and to download the mission(s)
that are currently loaded on the UA:








Mission Transfer Command (Message #13000)
UA Route (Message #13001)
Mission (VSM) Upload/Download Status (Message #14000)
UA Position Waypoint (Message #13002)
UA Loiter Waypoint (Message #13003)
Payload Action Waypoint (Message #13004)
Airframe Action Waypoint (Message #13005)
Vehicle Specific Waypoint (Message #13006)
The UA Position Waypoint (Message #13002) is the base message for defining a
mission waypoint and all the other waypoint messages must reference this message.
For each UA Position Waypoint there may be a loiter (Message #13003), payload
(Message #13004), airframe (Message #13005) and/or vehicle specific (Message
#13006) message linked to that waypoint. The “Waypoint Number” field in each of the
messages is the link that ties each of the messages together. Figure A4 - 4 represents
the association between the mission waypoint messages. Only the UA Position
Waypoint is mandatory for creating a mission as it defines the sequence of waypoints
within the mission, all of the other waypoint messages are optional per waypoint based
on what is supported by the VSM/UA.
A4 - 31
Edition A Version 1
AEP-84.1
Figure A4 - 4: Mission Waypoint Message Link
The mission(s) are uploaded from the CUCS to the VSM as a series of individual
waypoints based on the UA Position Waypoint Message (Message #13002). The
Mission Waypoints may be loaded to the VSM in any order as the UA Position
Waypoint identifies the “Waypoint Number” being uploaded in the message and the
“Next Waypoint” in the sequence is identified in the message as well. Waypoint
numbers do not need to be contiguous within a mission, however it is recommended
that they are made contiguous.
The Mission Transfer Command (Message #13000) is used to control the overall
upload, download and storage of a mission between the CUCS and VSM/UA. Refer
to the next section for additional details. Message #14000, Mission (VSM)
Upload/Download Status, is used by the VSM to report the status of the upload or
download of the mission to and from the VSM respectively. Until the mission has been
uploaded to the UA, the CUCS operator should not be provided the capability to control
the UA in the “waypoint” Flight mode as defined in the STANAG 4586 document.
A4 - 32
Edition A Version 1
AEP-84.1
As defined in Message #2016:
Vehicle Operating Mode Command CUCS
Implementation section of this document, the Waypoint mode should not be available
until a valid flight plan has been loaded to the AV. Refer to the Message #40000: Field
Configuration Request Implementation section of this document for additional details
on configuring the UA control parameters. When the Waypoint mode is commanded
through Message #2016 Vehicle Operating Mode Command, Unique ID 0043.15
(Commanded Waypoint Number) identifies the first waypoint to fly toward, which was
loaded to the VSM/UA using the UA Position Waypoint Message.
The Waypoint mode, specified in Message #2016, Vehicle Operating Mode Command,
can only be initiated if the UA is already in Mission mode and is used to send the
vehicle to any specified “Waypoint Number.”
While in the Waypoint flight mode of operation, it is expected that the VSM report the
“From”, “To,” and “Next” waypoint information to the CUCS using Message #3002,
Vehicle Operating States, upon a change in state/value of any of the waypoint
parameters.
A4.1.3.1 Message #13000: Mission Transfer Command Implementation
The Mission Transfer Command is used to control the overall upload, download and
storage of a mission between the CUCS and VSM/UA. The Mission Transfer
Command has been developed to account for situations where the VSM may be
located on the ground as well as for situations where the Mission Waypoint Messages
may be transmitted directly to the UA (VSM in the UA) from the CUCS.
The first step in the Mission Upload process is to transmit all the DLI mission waypoints
from the CUCS to the VSM (e.g., Message #13002-#13007). Refer to Figure A4 - 5
for a representation of the Mission Upload sequence of events. The next step in the
process is to transmit the required Message #13001, UA Route, messages to the VSM
to identify the Route ID and Route Type as required by the VSM/UA. After the CUCS
has transmitted the complete set of DLI mission waypoints and UA Route messages
to the VSM, the CUCS transmits the Mission Upload Command (Message #13000)
with the “Mission Plan Mode” set to “2= Load Mission”.
Where the VSM is on the ground (UA does not transmit STANAG DLI messages), the
Mission Upload Command is used to control the translation of the DLI mission waypoint
messages to the UA native (IDD) mission format. Once all the mission waypoints have
been transmitted from the CUCS to the VSM, a Mission Upload Command
(Message #13000) is transmitted with the Mission Plan Mode field set to “2 = Load
Mission” to indicate to the VSM that the transmitted DLI mission waypoints are ready
to be converted to the vehicle specific format and then transmitted to the UA. (This
means the VSM is responsible for converting the mission from the DLI Mission
Message format to any vehicle native format required, and then transmitting it to the
UA).
A4 - 33
Edition A Version 1
AEP-84.1
Step 1: CUCS transmits all the mission Waypoints and their associated parameters to the VSM.
CUCS – Mission Waypoints
VSM – Mission Waypoints
Message #13002
- Waypoint Number
- Message #13003
- Message #13004
- Message #13005
- Message #13006
Message #13002
- Waypoint Number
- Message #13003
- Message #13004
- Message #13005
- Message #13006
Step 2: CUCS transmits Message #800 to VSM.
VSM
CUCS – Mission Upload Command
Message #13000
- Mission Plan Mode
Load Waypoints
Step 3: VSM converts mission messages to vehicle native mission format.
VSM
VSM
Message #13002
- Waypoint Number
- Message #13003
- Message #13004
- Message #13005
- Message #13006
Vehicle Native Mission Format
Step 4: VSM transmits the vehicle mission format to the air vehicle.
VSM
Air Vehicle
Vehicle Native Mission Format
Vehicle Native Mission Format
Figure A4 - 5: Mission Message Upload Sequence
Where the UA can accept the DLI mission waypoints messages directly (e.g., VSM onboard the UA), the reception of a Mission Upload Command (Message #13000) with
the Mission Plan mode field set to “2 = Load Mission” signifies that all the DLI mission
waypoints have been transmitted to the UA. The UA would then perform any required
mission format conversions.
Message #14000, Mission (VSM) Upload/Download Status, is used by the VSM to
provide the status of the mission upload to the UA. This means the transmission of
the vehicle native waypoints (mission) from the VSM to the UA. The VSM will report
the upload as “in progress” and the “Percent complete”, or as “Complete.” While an
Upload or Download is in progress, it is the responsibility of the VSM to report to the
CUCS the capability to upload another task or download the task concurrently through
the use of the General Configuration messages.
A4 - 34
Edition A Version 1
AEP-84.1
The Mission Upload sequence as defined above may be used by the CUCS to replace
specific waypoints within a previously loaded mission, or to insert new waypoints within
the defined mission. If the intention of the mission upload is to entirely replace the
mission that is currently loaded on the UA, the CUCS should transmit the Mission
Upload Command (Message #13000) with the Mission Plan Mode field set to “1 = Clear
Mission” to identify to the VSM that all previously loaded waypoints are now invalid.
The Mission Plan mode “3 = Download Mission” and “4 = Download single waypoint”
are used to request the download of the mission waypoint information currently loaded
to the UA. Where the VSM is located on the ground, this is not a request for the DLI
mission waypoints that were previously uploaded to the VSM from the CUCS as these
may be different from the mission plan that is loaded on the UA. When the VSM
receives this command from the CUCS, the VSM must first query the UA for its current
mission plan, convert this vehicle native mission plan to the DLI mission waypoint
formatted messages, and then transmit the DLI mission waypoint messages to the
CUCS. If the UA is capable of directly transmitting DLI mission waypoint messages
(e.g., VSM on-board the UA), there is no additional conversion required. In the case
of a “Download Mission” request, the VSM is required to download all of the UA Route
Message (Message #13001) to the CUCS in addition to the Waypoint messages.
The “Waypoint Number” field in the Mission Upload Command indicates which
waypoint to download in the case of a single waypoint download request. The VSM
responds to the download request by sending all the available waypoint messages
(Message #13002 required, Message #13003-#13006 if available as they are optional)
for the specified waypoint number. The VSM is required to keep track of any
translations between the DLI mission waypoint number and vehicle native message
numbers as required to ensure a valid response is made to the mission waypoint query.
Message #14000, Mission (VSM) Upload/Download Status, is used to report the status
of the Mission download from the VSM to the CUCS where a complete download has
been requested.
Figure A4 - 6 below identifies the Mission Download sequence of events:
A4 - 35
Edition A Version 1
AEP-84.1
Step 1: CUCS transmits Mission Waypoint download request to the VSM.
CUCS – Mission Upload Command
VSM
Message #800
- Mission Plan Mode:
Download Waypoints /
Download Single Waypoint
Step 2: VSM requests required Waypoint information from the Air Vehicle.
Air Vehicle
VSM
Vehicle Native Mission
Waypoint Request
Step 3: The Air Vehicle transmits the requested Mission Waypoint Status messages to the VSM.
Air Vehicle
VSM
Vehicle Native Mission
Status
Step 4: VSM converts the vehicle native mission format to the required STANAG 4586 messages.
VSM – Mission Waypoints
VSM
Message #13002
- Waypoint Number
- Message #13003
- Message #13004
- Message #13005
- Message #13006
Vehicle Native Mission Status
Step 5: VSM transmits the required STANAG 4586 Mission Waypoint messages.
CUCS – Mission Waypoints
VSM – Mission Waypoints
Message #13002
- Waypoint Number
- Message #13003
- Message #13004
- Message #13005
- Message #13006
Message #13002
- Waypoint Number
- Message #13003
- Message #13004
- Message #13005
- Message #13006
Figure A4 - 6: Mission Message Download Sequence
A4.1.3.2 Message #13001 UA Route
This message is used to define an UA route. If the “Initial Waypoint Number” field in
the message is set to 0, the route definition (Route ID) defined in the message is
deleted from the VSM/UA, however the waypoints contained in the route definition are
not. The “Contingency Waypoint” fields, identify the waypoint toward which the UA will
fly if it is required to abandon the current mission, or a route. A “Contingency Waypoint”
may point toward a waypoint, which identifies a task to be conducted in the event of
an emergency. Which of the Contingency Waypoints the UA flies toward in the event
of an emergency is an UA specific implementation. The Contingency waypoint
number, Contingency Scope, e.g., Waypoint, Route, etc. are defined by Message
#13007, Defining Contingency,
A4 - 36
Edition A Version 1
AEP-84.1
A4.1.3.3 Message #13002: UA Position Waypoint Implementation
The UA Position Waypoint Message defines the geographical location that the UA will
fly toward. The UA Position Waypoint Message will be used to transmit a series of
waypoints from the CUCS to the VSM that will be linked together to form a single
mission or series of smaller tasks for the UA. UA missions are created using the UA
Position Waypoint by identifying the “Waypoint Number” in the message with the next
waypoint in the sequence being identified by the “Next Waypoint” field in the message.
The VSM will be required to convert these mission waypoints into the format required
for transmission of the mission to the UA.
The following attributes are defined for the waypoint in the message; the geographical
location of the waypoint, the airspeed at which the UA will fly toward the waypoint and
the altitude at which the vehicle will fly.
The “Next Waypoint” field provides the link from one waypoint to the next thus
identifying tasks, where a value of “zero” indicates that the waypoint is the last waypoint
in the series of waypoints or end of the task. The UA Position Waypoint Message may
be used to create a series of tasks or multiple tasks, where the CUCS is required to
keep track of which waypoint is the start waypoint for each task and which waypoints
form the task. To command a specific mission, Message #2016 is used as described
above. When the VSM receives the DLI Mission Waypoints, if the UA does not support
the DLI Mission Waypoints directly, the VSM must convert the DLI Mission Waypoints
to the vehicle specific format. In the instance where the CUCS requests the download
of a mission(s) from an UA for which it has not uploaded the mission, the CUCS must
recreate the mission(s) from the reception of the UA Position Waypoint Messages from
the VSM/UA as required to determine the mission composition, which may be single
or multiple missions. The CUCS, if authorized, may then modify the missions by
inserting, modifying waypoints, etc.
Figure A4 - 7 below provides a brief example of creating a task through the use of the
UA Position Waypoint Message.
A4 - 37
Edition A Version 1
AEP-84.1
Waypoint #1
Waypoint #5
Next Waypoint #2
Next Waypoint #6
Contingency Waypoint #5
Contingency Waypoint #200
Waypoint #2
Waypoint #6
Next Waypoint #3
Next Waypoint #200
Contingency Waypoint #200
Waypoint #3
Waypoint #7
Next Waypoint #4
Next Waypoint #200
Contingency Waypoint #200
Waypoint #4
Waypoint #200
Next Waypoint #5
Next Waypoint #0
Figure A4 - 7: Example Task Using UA Position Waypoint Message
It is the responsibility of the CUCS to ensure the waypoints are correctly configured
before transmitting the information to the VSM. This includes ensuring that if two tasks
are linked together that the waypoint identifying the end of the first task is correctly
linked to the first waypoint in the second task, and that waypoint numbers are not
repeated within the tasks.
A4.1.3.4 Message #13003: UA Loiter Waypoint Implementation
The UA Loiter Waypoint Message defines the loiter characteristics the UA will perform
once it has arrived at the waypoint location identified in the UA Position Waypoint
Message (Message #13002) while in the Waypoint Flight mode.
A4.1.3.5 Message #13004: Payload Action Waypoint Implementation
The Payload Action Waypoint Message defines the payload action that will be
performed when the UA begins to fly toward the waypoint identified in the UA Position
Waypoint Message (Message #13002) for the identified waypoint number while in the
Waypoint Flight mode.
A4.1.3.6 Message #13005: Airframe Action Waypoint Implementation
The Airframe Action Waypoint Message defines the Airframe action that will be
performed when the UA begins to fly toward the waypoint identified in the UA Position
Waypoint Message (Message #13002) while in the Waypoint Flight mode. Airframe
actions include turning on/off UA navigation lights, data link transmitters, etc. as
identified in the Airframe Action Waypoint Message.
A4 - 38
Edition A Version 1
AEP-84.1
A4.1.3.7 Message #13006: Vehicle Specific Waypoint Implementation
The Vehicle Specific Waypoint Message defines the vehicle specific actions that will
be performed when the UA begins to fly toward the waypoint identified in the UA
Position Waypoint Message (Message #13002) while in the Waypoint Flight mode.
This message is used to pass any vehicle or payload specific information that is not
covered by the Generic Mission Upload Messages to the VSM, for subsequent
transmission to the UA. A waypoint value of zero indicates mission generic data that
is not associated with any specific waypoint. The following messages are considered
the Generic Mission Messages:




UA Position Waypoint (Message #13002)
UA Loiter Waypoint (Message #13003)
Payload Action Waypoint (Message #13004)
Airframe Action Waypoint (Message #13005)
Common Route Definition (CRD) data tags are used to provide a standard and
interoperable method to transfer information between a CUCS and a VSM for data that
is not supported by the generic message set. To determine the required CRD data tag
for a UA (vehicle specific) data element the CRD Standard must be referenced.
One application of this message is to provide for the transmission of elements of the
CRD messages, received via the CCI interface, to an UA where the data elements
cannot be mapped to the generic mission messages. A VSM that does not support
the CRD data tags may ignore this message without causing adverse effects to the
system.
A4.1.3.8 Message #14000: Mission (VSM) Upload/Download Implementation
The Mission (VSM) Upload/Download Message is sent by the VSM to the CUCS to
provide status on a mission upload/download from a VSM to a CUCS.
A4.1.4 Message Acknowledgment
Entities can use the STANAG 4586 acknowledgement system to detect if their
messages have arrived at their destination and whether their requests are rejected or
accepted and completed/failed. This is important since the underlying transport
mechanism (i.e., UDP) is not reliable and does not guarantee that packets arrive in the
same order that they were sent.
Acknowledgements are typically not needed for status messages that are sent
frequently and where the content of the most recent message supersedes the data of
the older messages. For instance, a UA may send Message #3010, Body Relative
Sensed States, at a rate of 5 Hz. In this case, there is little value in requesting an
acknowledgement since the data will be stale by the time the UA realizes that the
CUCS did not receive the message. The table below highlights situations where it is a
good idea to use the acknowledgement system.
Situation
Event-driven
Examples


Message #16000, Subsystem Status Alert,
when a Warning or Caution condition is
detected
Message #3, Vehicle ID, if a virtual Vehicle
ID is changed to a real Vehicle ID
A4 - 39
Edition A Version 1
AEP-84.1
The message is only sent when needed
(i.e., not sent periodically and not if
updates happen frequently)

Message #44003, Message Parameter
Availability, to indicate that a Vehicle
Operating Mode is suddenly unavailable
Transactional


Downloading Configuration Data
Transferring Route/Waypoint Messages

Message #16000, Subsystem Status Alert,
when responding to a request for
additional details with multiple messages
The message is part of a set of
messages where the receiving entity
should only accept the messages if all
the messages have been received
Sequential
The message is part of a sequence
where the order of receipt matters
Note that an entity does not always need to request a Message #17000 Message
Acknowledgement, as an entity may use an expected response as an
acknowledgement. For instance, if a CUCS sends a Message #40000 Field
Configuration Request, to download a single configuration parameter, the receipt of
the requested configuration parameter in a Message #4100x implies that the
destination entity received the request.
A4.1.4.1 Requesting an Acknowledgement
To request an acknowledgement, an entity needs to set the ACK bit in the Message
Properties field of the message header and set a unique time stamp in the message’s
Time Stamp field. For instance, if a VSM requests an ACK for Message #16000,
Subsystem Status Alert, then the Time Stamp field (Unique ID 1100.01) must be set in
Message #16000 so the receiving CUCS can populate the Original Message Time
Stamp field (Unique ID 1400.06) in the acknowledgement.
If the sending entity does not receive a Message #17000, Message Acknowledgement,
within a reasonable time frame, the entity may assume that the message was not
received at the destination. In this case, the entity can choose to resend the message
or timeout.
Note that a message may not be acknowledged if any of the following conditions exist,
since the entity cannot trust the integrity of the received message:
o
o
o
The message specifies an IDD version of STANAG 4586 that is not
supported by this entity
The message specifies an incorrect message length
The message has an incorrect checksum (if used)
An entity should use a unique time stamp for each sent message unless it is a retry
attempt of a previously sent message. While entities could use a globally unique time
stamp for each message, the time stamp only needs to be unique for a given Message
Type. This is because the responding entity is required to specify the Original
Message Type (Unique ID 1400.08) in the acknowledgement.
A4 - 40
Edition A Version 1
AEP-84.1
Header
field
Name
Value
1
IDD Version
“32” (Edition 4 using AEP-84 Volume II)
2
Message Instance ID
<A unique ID that will be included in the ACK>
3
Message Type
<Message Type>
4
Message Length
<Message Length>
5
Stream ID
<Stream ID>
6
Message Properties
0x80000000 (note that the least significant 31
bits are undefined)
A4.1.4.2 Sending an Acknowledgement
To acknowledge a message, the entity sends Message #17000:
Unique ID
Name
Value
1400.01
Time Stamp
Time of Message #17000 creation
1400.06
Original Message Time
Stamp
<Timestamp from received Message>
1400.08
Original Message Type
<Message Type from received Message>
17000.01
Acknowledgement Type
<Acknowledgement Type as needed>
An entity may send multiple copies of the Acknowledgement Message at the same
time to increase the chances that one will be received at the destination. The receiving
entity should be able to receive multiple copies of the same acknowledgement without
unintended side effects.
There are five different types of acknowledgements that an entity can send.
Enumeration
Name
Meaning
0
Message Received
The message was received and
no further acknowledgement
will be sent.
This does not imply that the
contents of the message were
correct or the data in the
message was used for its
intended purpose.
It only
indicates that the message was
A4 - 41
Edition A Version 1
AEP-84.1
received and that the sending
entity does not need to resend
it.
1
Message Received, but not
completed
This is the same as 0=Message
Received, except that it
indicates that a further
acknowledgement will be sent
to indicate if the received
message was accepted and
completed, accepted and
failed, or rejected.
This message can be useful for
cases where the entity requires
additional time to decide the
outcome of the request. By
sending this message, the
sending entity is informed that
the message was received so it
doesn’t need to re-send the
message.
2
Message
Completed
Received
and
This indicates that the message
was received and the request
was accepted and completed.
For instance, the UA can use
this message to indicate that it
has received and accepted the
new parameters when it
receives the Message.
3
Message
Rejected
Received,
but
This indicates that the message
was received and that the
request was rejected. The
entity can send it to indicate
that something was wrong with
the request.
It could be
because there was an error
encoding the message or
because the entity does not
accept the request. This may
be because the data in the
request is not within the
entity’s
configuration
or
because entity is temporarily
unable to accept the request.
4
Message Received, but Failed
This indicates that the message
was received and the request
was accepted but the entity
failed to carry out the request.
For example, if an entity
requested to turn on the power
A4 - 42
Edition A Version 1
AEP-84.1
to an EO/IR payload but the
payload failed to turn on due to
an electrical problem.
A4.1.5 Vehicle Control Modes
A4.1.5.1 Message #2000: Vehicle Configuration Command CUCS
Implementation
The Vehicle Configuration Command message is used by the CUCS to transmit the
initial UA Propulsion Energy to the VSM, as a percentage of the total capacity of the
system. The Propulsion Energy may be a liquid/ solid fuel (kg) or a current charge
(joules), therefore the initial capacity is commanded as a percentage of the maximum
capacity of the system as reported (configured) from the VSM using Message #3000,
Vehicle Configuration. The CUCS must provide a method for the operator to enter the
Initial Propulsion energy if supported, and it is recommended this value is entered in
the type reported as supported in Message #3000, Vehicle Configuration, either
“Propulsion Fuel Capacity” or “Propulsion Battery Capacity”. Potentially both
propulsion energy types may be available; however, the command of two different
propulsion energy types is not currently supported by STANAG 4586.
A4.1.5.2 Message #2000: Vehicle Configuration Command VSM
Implementation
The VSM uses the reception of the Vehicle Configuration Command message to
identify the initial fuel load, percentage of maximum load, on the UA. The VSM must
use the General Configuration messages, Message #41001, Configuration Double
Response, for the Message #2000, Initial Propulsion Energy parameter, to identify
whether or not it supports the entry of an initial propulsion energy value during the
configuration process. Message #3000 itself identifies whether or not the vehicle
supports either Message #3000, Propulsion Fuel Capacity or Message #3000,
Propulsion Battery Capacity, in addition to using this same message (Message #3000)
to report the fuel/ battery capacity to the CUCS. (Yes, this is inconsistent with the
general configuration process.)
The Propulsion Energy may be a liquid/ solid fuel (kg) or a current charge (joules), and
the initial capacity is received as a percentage of the maximum capacity of the system.
It is currently required that the VSM only report one type of Propulsion Energy,
Message #3000, Propulsion Fuel Capacity, or Message #3000, Propulsion Battery
Capacity, as supported (valid) in order for this message to correctly support the initial
value entry at the CUCS. Refer to Message #3000, Vehicle Configuration for
implementation details.
A4.1.5.3 Message #2016: Vehicle Operating Mode Command CUCS
Implementation
The Vehicle Operating Mode Command is used by the CUCS to execute control over
the UA through the VSM. It is recommended that control over this data element be
available on the UA control panel. To conserve bandwidth, it is recommended this
message only be sent on a change in state.
Once a flight path control mode has been commanded using Message #2016, there is
most likely a requirement to command new UA parameters associated with the
selected mode of control. Message #2016, Vehicle Operating Mode Command, is the
message that is used to transmit “manual” commands to the vehicle while in the “Flight
A4 - 43
Edition A Version 1
AEP-84.1
Director” or “Loiter” flight path control mode of operation, and Message #13002, UA
Position Waypoint, is the default message for the Altitude and Speed command values
while in the Message #2016 “Waypoint” flight path control mode of operation.
The following messages are tightly coupled to each other:
o
o
o
Message #2016, Vehicle Operating Mode Command
Message #2017, Loiter Configuration
Message #13002, UA Position Waypoint
Table A4 -2 below depicts the generally expected message sequence between the
CUCS and the VSM in changing from one Message #2016, “Select Flight Path Control
Mode” to another.
CUCS
VSM
Message #2016: Vehicle Operating Mode
Command ->
<- Message #3001: Vehicle Operating Mode
Report
Message #2016: Vehicle Steering Command >
<- Message #3002: Vehicle Operating States
Table A4 - 2: Vehicle Operating Mode Message Sequence
The Waypoint mode should not be available until a valid flight plan has been loaded
to the UA. When the Message #2016, Waypoint mode is commanded, Unique ID
0043.15, Commanded Waypoint Number identifies the waypoint of the selected
mission for the vehicle to proceed toward. While in the Message #2016, Waypoint
flight control path mode of operation, the air vehicle’s altitude and speed commanded
values are to come from Message #13002, UA Position Waypoint as the default
setting. Using Message #2016, Vehicle Operating Mode Command, these default
values of altitude and speed can be overridden by selecting to use the “manual”
settings from Message #2016 if this override is supported by the air vehicle. See AEP84 Volume II, Message #2016, for additional details.
When the Loiter mode is selected, the loiter point (position) is sent to the UA using
Message #2017, Loiter Configuration, parameters:
Additional functionality required by the Autopilot modes of operation is dependent on
the autopilot implementations on the UA. There will be a requirement to define any
additional requirements from the VSM. The VSM will use the General Configuration
messages to identify in particular what Message #2016 and Message #2017
parameters are supported while in each of the different Message #2016, Autopilot
flight path control modes of operation.
The Slave to Sensor mode is used to initiate the Slave to Sensor mode of operation
on the UA, and the Loiter point is calculated on the UA. Note: There may be a future
capability to transmit Slave to Sensor parameters to the UA. The VSM will use the
General Configuration messages to identify in particular what Message #2016
parameters are supported while in Slave to Sensor flight path control mode of
operation.
The selection of the Autoland Engage mode is used to initiate the Autoland
functionality of the VSM. The VSM will use the General Configuration messages to
A4 - 44
Edition A Version 1
AEP-84.1
identify in particular what Message #2016 and Message #2017 parameters are
supported while in the Autoland Engage flight path control mode of operation.
The selection of the Autoland wave-off mode is used to initiate the Wave-off
functionality of the VSM. The VSM will use the General Configuration messages to
identify in particular what Message #2016 and Message #2017 parameters are
supported while in the Autoland Wave-off flight path control mode of operation.
The selection of the Launch mode initiates the launch functionality of the VSM. The
VSM will use the General Configuration messages to identify what Message #2016
and Message #2017 parameters are supported/ available while in the Launch flight
path control mode of operation.
The Vehicle Specific Flight Modes are identified/ configured on the CUCS by the
VSM through the use of the General Configuration Messages. Message #41002, Field
Configuration Enumerated Response, is used to extend the list of Flight Path Control
modes as required by the specific vehicle, and the CUCS must make these additional
modes available to the operator. Any additional control requirements for the vehicle
specific flight modes must be identified by the VSM. The VSM may use the generic
messages, such as Message #2016, Vehicle Operating Mode Command, and
Message #2017, Loiter Configuration, in conjunction with a vehicle specific flight mode
of operation. The VSM will be required to use the General Configuration messages to
identify in particular what Message #2016 and Message #2017 parameters are not
supported/ available while in the Vehicle Specific flight path control mode of
operation.
Message #40000, Field Configuration Request, is used by the VSM to report to the
CUCS which generic Message #2016, Flight Path Control Modes are not supported by
the UA. The CUCS must ensure the operator is not provided with control over these
Flight modes.
A4.1.5.4 Message #2016: Vehicle Operating Mode Command VSM
Implementation
The Vehicle Operating Mode defines the system behaviour and establishes how
commands are to be interpreted. This message is used to establish a standard way
of defining and accessing the common UA operating modes from the CUCS, however
the specific implementation of the operating mode is a vehicle specific function. The
VSM should command the UA as required immediately upon reception of a Vehicle
Operating Mode Command from the CUCS. The CUCS will follow this message with
Message #2017, Loiter Configuration and/or Message #13002, UA Position Waypoint,
that will provide the specific parameters for the active or commanded UA operating
mode.
The following table provides a potential method to identify the cross references
between the CUCS Vehicle Operating modes (i.e., Flight modes) and the UA Native
Flight modes, and identify how the Flight modes are implemented for control from the
CUCS.
A4 - 45
Edition A Version 1
AEP-84.1
Flight Path
Control
Mode #
Flight Path Control
Mode Description
Vehicle Native
Flight Path
Control Mode
Implementation
0
No Mode
1
Reserved
2
Flight Director
3 – 10
Reserved
11
Waypoint
12
Loiter
13 – 14
Reserved
15
Autopilot (general)
16
Autopilot (terrain
avoidance)
17
Autopilot (NavAid
slaved)
18
Reserved
19
Autoland engage
Initiates vehicle specific
Autoland dialog
20
Autoland wave-off
Initiates vehicle specific
Wave-off dialog
21
Launch
22
Slave to Sensor
23
Fly Contingency A
24
Fly Contingency B
25
Slave to Location
26 - 31
Reserved
32-255
Vehicle Specific
Table A4 - 3: Cross Reference Table for CUCS Vehicle Operating Modes (Flight Modes)
The Reserved modes identified in the STANAG are reserved for future revisions to the
STANAG 4586 UA Flight Path Control modes. A VSM implementation may define UA
modes specific to a vehicle using modes 32 through 255. The capability to define
vehicle specific Flight modes is provided through the use of Message #41002, Field
Configuration Enumerated Response.
The VSM must use the Message #40000, Field Configuration Request, to identify to
the CUCS which of the generic Message #2016, “Select Flight Path Control Modes”
are not supported by or available at the CUCS, both statically and dynamically. Refer
to AEP-84 Volume II, Message #40000 for additional details.
A4 - 46
Edition A Version 1
AEP-84.1
The VSM is required to ensure that the each of the Message #2016, “Select Flight
Path Control Mode” enumerations is correctly associated with each of the parameters
in the different messages.
A4.1.5.5 Message #2017: Loiter Configuration CUCS Implementation
The Loiter Configuration Command Message is used in conjunction with Message
#2016, Vehicle Operating Mode Command. The Loiter Configuration Command is
used by the CUCS to configure the Loiter pattern that will be used by the UA while it is
in the Message #2016, “Loiter” flight path control mode. (This message is used for
additional Flight Path Control modes of operation.) The Loiter flight path control mode
is transmitted from the CUCS to the VSM using Message #2016, and the loiter
characteristics are transmitted from the CUCS to the VSM in Message #2017, Loiter
Configuration. Refer to AEP-84 Volume II for additional implementation guidance.
This message configures the loiter pattern (Loiter Type, Loiter Radius, Loiter Length,
Loiter Bearing, Loiter Direction), and provides the capability to select a loiter specific
altitude and/or airspeed for the air vehicle to achieve while in the Message #2016,
“Loiter” flight path control mode.
The altitude and (air)speed demands in this message (Message #2004) are intended
as configuration settings, and are not intended to be continuously altered while in the
“Loiter” flight path control mode. If the intention is to continuously alter the altitude and
(air) speed settings while in Loiter mode, Message #2003, Altitude Mode and Speed
Mode settings should be “Manual/ Override.”
The Altitude type and Speed type fields are to provide the reference frame for the
altitude and speed command values contained in the Loiter Configuration message.
A4.1.5.6 Message #2017: Loiter Configuration VSM Implementation
The Loiter Configuration Command Message is used in conjunction with Message
#2016, Vehicle Operating Mode Command.
The VSM uses the Loiter Configuration Message to configure the Loiter pattern that
will be used by the UA when it is placed into the Message #2016, “Loiter” flight path
control mode. The VSM is responsible for identifying to the CUCS which of the
parameters in the message are supported for the specified UA through the use of the
General Configuration Messages for; the Loiter Type, Loiter Direction, and Flying
Behaviour. The CUCS will then not allow these selections from the CUCS. Refer to
AEP-84, Volume II “Message #2017 Loiter Configuration for additional details.
A4.1.5.7 Message #2018: Slave to Sensor Configuration CUCS
Implementation
This message shall be used to link a specific sensor to the Slave to Sensor Flight
Mode.
The CUCS shall transmit this message to the UA/VSM to provide a “Slave to Sensor
Offset” distance and “Slave to Sensor Direction” to the UA. The UA shall use the offset
distance and offset direction to calculate it’s loiter location with respect to the reported
stare-point location while in Slave to Sensor Flight Mode. Refer to AEP-84, Volume II
Message #2018 Slave To Sensor Configuration for additional details.
A4.1.5.8 Message #2018: Slave to Sensor Configuration VSM Implementation
It is the ultimate responsibility of the VSM to correctly control the UA in accordance
with the selected Message #2016, Select Flight Path Control Mode, mode of operation,
and not allow inappropriate control from the CUCS. The VSM must use Message
A4 - 47
Edition A Version 1
AEP-84.1
#40000, Field Configuration Request, to identify to the CUCS which of the generic
Message #2016, “Select Flight Path Control Modes” are not supported by or available
at the CUCS, both statically and dynamically. The VSM/UA shall use the “Slave to
Sensor Offset” distance and “Slave to Sensor Direction” to calculate it’s loiter location
with respect to the reported stare-point location while in Slave to Sensor Flight Mode.
The VSM should appropriately disregard those fields contained in the Flight Vehicle
Command messages that do not pertain to the currently selected Message #2016,
Select Flight Path Control mode. Refer to AEP-84, Volume II, Message #2018 Slave
To Sensor Configuration for additional details
A4.1.5.9 Message #2007 Unmanned Aircraft Lights VSM Implementation
The Unmanned Aircraft Lights Message is used by the CUCS to execute control over
the UA lights. Upon receipt of this message, the VSM should set the UA lights as
commanded in the message.
The VSM uses the Field Configuration Command Message (Message #40000) to
configure the available Set Lights states.
A4.1.5.10 Message #2007 Unmanned Aircraft Lights CUCS Implementation
The CUCS populates the Unmanned Aircraft Lights Message parameters as entered
at the CUCS, and transmits the message to the VSM. It is recommended that this
Message be transmitted to the VSM upon any change in parameter contained in the
message.
A4.1.5.11 Message #2008 Engine Command VSM Implementation
The Engine Command Message is used by the CUCS to control the UA engine(s).
Upon receipt of this message the VSM should set the UA engine(s) as commanded in
the message.
The VSM uses the Field Configuration Command Message (Message #40000) to
configure the available Engine Command states.
A4.1.5.12 Message #2008 Engine Command CUCS Implementation
The CUCS populates the Engine Command Message parameters as entered at the
CUCS, and transmits the message to the VSM. It is recommended that the Engine
Command Message be transmitted to the VSM upon any change in parameter
contained in the message.
A4.1.5.13 Message #2005: Flight Termination Command CUCS
Implementation
The Flight Termination Command Message is sent from the CUCS to the VSM to
execute a flight termination sequence, or to reset a specified sequence.
The CUCS uses Message #40000, Field Configuration Request, to request the
configuration for the Flight Termination Mode field of the Flight Termination Command,
by requesting the configuration of Message #2005, Unique ID 0046.05 from the VSM.
The response will be received from the VSM using Message #41002, Field
Configuration Enumerated Response. Refer to the Flight Termination Command VSM
Implementation section, the Field Configuration Request Implementation section and
the Field Configuration Enumerated Response Implementation section of this
document for additional details on how to configure the Flight Termination Mode field.
A4 - 48
Edition A Version 1
AEP-84.1
A4.1.5.14 Message #2005: Flight Termination Command VSM Implementation
This message is used to provide a means for the CUCS to issue a Flight Termination
Command to the VSM.
The Flight Termination Command is sent from the CUCS to the VSM to execute a flight
termination sequence, or to reset a specified sequence. To accomplish flight
termination at the VSM, this message is received twice with two different values in the
Message #2005, Commanded Flight Termination State field (once to arm, and a
second time to execute). If the VSM receives an “execute” command before an “arm”
command has been received, a warning should be sent to the CUCS indicating that
the Flight Termination System has not been armed.
Table A4 – 3 depicts the recommended/expected message sequence between the
CUCS and the VSM in commanding a Flight termination.
CUCS
VSM
Message #2005: Flight Termination Command
->
- Arm FT System
<- Message #3005: Flight Termination Mode
Report
- FT System Armed
Message #2005: Flight Termination Command
->
- Execute FT Sequence
<- Message #3005: Flight Termination Mode
Report
- FT Sequence Executed
Table A4 - 4: Flight Termination Mode Message Sequence
The VSM uses Message #41002, Field Configuration Enumerated Response, to report
the configuration of the Flight Termination Mode parameter of the Flight Termination
Command in response to a configuration request from the CUCS. The Flight
Termination mode parameter has no identified generic flight termination modes,
therefore the VSM must use Message #41002 to identify the available Flight
Termination modes for the vehicle under control. The Enumeration Count identifies
the number of Termination modes, the Enumeration Index which indexes a specific
enumeration, and the Enumeration Text is associated with the Enumeration index to
provide a User readable identification of the specified Termination mode. These
modes may then be presented to the operator in the generic CUCS Displays.
Refer to the Field Configuration Request Implementation and the Field Configuration
Enumerated Response Implementation sections of this document for additional details
on how to configure generic enumerated fields.
A4.1.5.15 Message #2019 Slave to Location Configuration Message CUCS
Implementation
The Slave To Location Configuration Message is used by the CUCS to identify the
absolute reference system for locations, relative routes and their associated waypoints
to the VSM. The intent of this message is to support moving platforms for launch and
recovery, and to support usage of reusable “route templates” (e.g., for search
A4 - 49
Edition A Version 1
AEP-84.1
patterns). This message is provided prior to commanding programmed flight along
any relative route, and updated as necessary otherwise. By setting Unique ID 2006.02
to a value of “1 or 2”, the operator defines an offset location that the vehicle should
maneuver to relative to the provided reference location in Message #2019. The type
of loiter the vehicle will perform is defined in this message. The offset location is the
center of the loiter pattern that the vehicle is instructed to perform. The looking angle,
if specified, is the depression angle relative to the local horizon from the offset location
to the provided location. The relative altitude is the UA altitude relative to the location
position altitude. In case the location is a moving location (Like a ground target or flying
helicopter etc.) the UA shall calculate it's loiter position only according to the location
position updates. Refer to AEP-84, Volume II, Message #2019 Slave To Location
Configuration for additional details.
A4.1.5.16 Message #2019 Slave to Location Configuration Message VSM
Implementation
The VSM/UA shall use the “Offset” distance and “Offset” direction from the “Latitude”
and “Longitude” provided in this message to calculate it’s loiter location while in Slave
to Location Flight Mode. The UA shall also use the “Location Altitude” and the “Relative
Altitude”/”Looking Angle” to set its own altitude A4.1.5.17 Message #2010: UA Stick
Command.
The UA Stick Command Message is used to control the UA flight surface and taxi
related functions. The UA Stick Command Message should not be transmitted between
a CUCS and the UA without an authorized connection. This message is used to send
UA stick commands from the CUCS to the UA. The CUCS implementation of this
message should be in conjunction with an HMI implementation which enhances the
operator ability to effectively and efficiently utilize the controls in this message.
A4.1.5.18 Message #3000: Vehicle Configuration CUCS Implementation
The Vehicle Configuration Message is used to provide the CUCS with characteristics
of the vehicle it is controlling through the VSM. The data elements provided by this
message are used to perform calculations, or to perform configurations (that are
inconsistent with the general configuration process) on the CUCS for the specific UA
by vehicle ID.
This message is required to be received by the CUCS during the general configuration
process in order to correctly configure the CUCS for the entry of the Message #2000,
Initial Propulsion Energy, parameter if it is supported by the VSM. This message
identifies both the type of fuel supported by the system (Propulsion Fuel Capacity,
Propulsion Battery Capacity), and the maximum capacity for the supported type. Note,
currently the VSM must only identify support for one energy type as Message #2000,
Initial Propulsion Energy, can only support one fuel type.
This message is also used to identify the “Number of Engines” supported by the air
vehicle for configuration purposes.
The STANAG 4586 allows the CUCS to request configuration messages from the
VSM/air vehicle in advance of requesting an LOI from the VSM. This is one of the
configuration messages that may be requested from the VSM by the CUCS if it is not
received during the general configuration process as it is required to properly configure
the CUCS to support fuel and engine command and status parameters.
A4.1.5.19 Message #3000: Vehicle Configuration VSM Implementation
A4 - 50
Edition A Version 1
AEP-84.1
The Vehicle Configuration Message is used to provide the CUCS with characteristics
of the vehicle it is controlling through the VSM, and to provide vehicle configuration
data to the CUCS. The data elements provided by this message can be used to
perform calculations or configuration on the CUCS for the specific UA.
Some of the data elements contained in the Vehicle Configuration Message remain
relatively constant, and should only be configurable on a system administration level.
These data elements are:








Configuration ID
Propulsion Fuel Capacity (if external tanks are not an option)
Propulsion Battery Capacity
Maximum Indicated Airspeed (if not a function of payload
configuration)
Optimum Cruise Indicated Airspeed (if not a function of payload
configuration)
Optimum Endurance Indicated Airspeed (if not a function of payload
configuration)
Maximum Load Factor
Number of Engines
Some of the data elements in the Vehicle Configuration Messages change based on
the mission to be performed, and therefore should be entered by the operator before
conducting the mission. These data elements are as follows:


Gross Weight
X__CG
The VSM should provide a method for the operator to enter these parameters from a
User interface, and the VSM should populate the displays/controls with default values.
The VSM should be able to accept data from the UA to populate these displays if the
data is provided from the UA.
This message may be specifically requested by a CUCS from the UA/ VSM using a
Message #17002 request, or is transmitted from the VSM when a CUCS makes a
general configuration request from the VSM using Message #40000, Field
Configuration, at the appropriate LOI (LOI 4). The VSM should populate and send this
message to the CUCS with the most recent data upon request for this message from
the CUCS.
A4.1.5.20 Message #4000: Inertial States CUCS Implementation
The Inertial States Message provides the inertial states of the UA, and is pushed from
the VSM to the CUCS. The VSM developer is responsible for determining the rate at
which this message is required in order for the CUCS to provide a timely status display
of these data elements to the operator.
A number of the parameters in this message are configurable from the VSM, and the
CUCS should alter its displays to match the specified values/limits.
A4.1.5.21 Message #4000: Inertial States VSM Implementation
The Inertial States Message provides the inertial states of the AV, and is pushed from
the VSM to the CUCS. The VSM is responsible for determining the rate at which this
message is required for the CUCS to provide a timely status display of these data
A4 - 51
Edition A Version 1
AEP-84.1
elements to the operator. The frequency at which the message is sent to the CUCS
should be determined based on the reception of AV messages containing the same
data elements being received from the AV.
The VSM should always populate this message with the latest data received from the
AV under control of the VSM. *** The VSM should NOT transmit this message to the
CUCS when it is not receiving the information contained in the message from the air
vehicle, as it is a false indication of the air vehicles status!
The message provides the current air vehicle location, the current air vehicle altitude
with the reference frame as reported in the Altitude type field, the air vehicles ground
speed, Roll, Pitch, and Heading.
The Sample Time Stamp is the time the data contained in the Inertial States Message
was acquired by the VSM. The VSM should always populate this message with the
latest data received from the UA under control of the VSM. *** The VSM should NOT
transmit this message to the CUCS when it is not receiving the information contained
in the message from the air vehicle, as it is a false indication of the air vehicles status!
The message provides the current air vehicle location, the current air vehicle altitude
with the reference frame as reported in the Altitude type field, the air vehicles ground
speed, Roll, Pitch, and Heading. The intent of this message is to provide air vehicle
inertial states for geo-referencing of the payload data. It is therefore recommended
that the reference frame selected for the Altitude report be “WGS-84” or AGL where
possible.
As a clarification, the Euler rates as a function of body rates are:

phi-dot = roll-rate + pitch-rate sin(phi) tan(theta) + yaw-rate cos(phi)
tan(theta)

theta-dot = pitch-rate cos(phi) – yaw-rate sin(phi)

psi-dot
=
pitch-rate
cos(phi)/cos(theta)
sin(phi)/cos(theta)
+
yaw-rate
As a clarification, the Accelerations in inertial axes as a function of accelerations in
body axes are:

U-Accel = X-Body-accel cos(theta) cos(psi) + Y-Body-accel sin(phi)
sin(theta) cos(psi) +Z-Body-accel cos(phi) sin(theta) cos(psi) –
Y-Body-accel cos(phi) sin(psi) + Z-accel sin(phi) sin(psi)

V-Accel = X-Body-accel cos(theta) sin(psi) + Y-Body-accel sin(phi)
sin(theta) sin(psi) +Z-Body-accel cos(phi) sin(theta) sin(psi) +YBody-accel cos(phi) cos(psi) –Z-accel sin(phi) cos(psi)

W-Accel = –X-Body-accel sin(theta) +Y-Body-accel sin(phi)
cos(theta) + Z-Body-accel cos(phi) cos(theta)
A significant number of the UA parameters as reported in this message must be
configured using the General Configuration Messages to assist in the display of caution
and alert conditions at the CUCS. Refer to the STANAG 4586 document for the list of
parameters, identified within the Message #41000, #41001, #41002 and #40000
descriptions, required to be configured and which message is used to configure the
parameter.
A4 - 52
Edition A Version 1
AEP-84.1
NOTE: The VSM/UA is responsible for providing the magnetic variation it is using to
convert true heading to magnetic. Note: Magnetic Variation is often called Magnetic
Declination.
A4.1.5.22 Message #3009: Air and Ground Relative States CUCS
Implementation
The Air and Ground Relative States message is pushed from the VSM at a rate
determined by the VSM manufacturer to allow for the timely display of the data
elements at the CUCS.
A number of the parameters in this message are configurable from the VSM, and the
CUCS should alter its displays to match the specified values/limits.
A4.1.5.23 Message #3009: Air and Ground Relative States VSM
Implementation
The Air and Ground Relative States Message provides the state of the UA relative to
its environment, and it provides information about the environment in which the UA is
located. This message is pushed from the VSM to the CUCS. The VSM is responsible
for determining the rate at which this message is required at the CUCS to provide a
timely status display of these data elements to the operator. *** The VSM should NOT
transmit this message to the CUCS when it is not receiving the information contained
in the message from the air vehicle, as it is a false indication of the air vehicles status!
The VSM should always populate this message with the latest data received from the
UA under control of the VSM before sending it to the CUCS.
The STANAG data elements supported by the UA for which the VSM is being
implemented should be referenced appropriately to the required UA data element. The
STANAG 4586 provides the capability for an air vehicle to report both altitude and (air)
speed to the CUCS in a number of frames of reference. This message provides the
VSM with the capability to transmit the altitude and (air) speed data to the CUCS for
all frames of reference it supports in a single message, at a rate to be determined by
the VSM for safe operation of the air vehicle. The VSM must use the General
Configuration messages to ensure that it correctly defines which frames of reference
reports for the altitude and (air)speed are supported by the air vehicle, and which are
not. It is highly recommended that the configuration for both the reported and
commanded altitude and (air)speed frames of reference be the same, i.e., if a WGS84 Altitude can be commanded there should be a corresponding altitude report in the
WGS-84 frame of reference.
A significant number of the UA parameters as reported in this message must be
configured using the General Configuration Messages to assist in the display of caution
and alert conditions at the CUCS. Refer to the STANAG 4586 document for the list of
parameters, identified within the Message #41000, #41001, #41002 and #40000
descriptions, required to be configured and which message is used to configure the
parameter. The Air and Ground Relative States message is pushed from the VSM at
a rate determined by the VSM manufacturer to allow for the timely display of the data
elements at the CUCS.
A number of the parameters in this message are configurable from the VSM, and the
CUCS should alter its displays to match the specified values/limits.
A4 - 53
Edition A Version 1
AEP-84.1
Note: The U_Wind and V_Wind variables combine to create a wind vector. The wind
vector indicates the magnitude and direction that the air mass is travelling. For
example, an air mass traveling at 4 m/s from South to North would be reported with
U_Wind=+4 m/s, V_Wind=0 m/s. For an air mass traveling from West to East the
reported V_Wind would be positive.
A4.1.5.24 Message #3010: Body Relative Sensed States CUCS
Implementation
The Body Relative Sensed States message is pushed from the VSM at a rate
determined by the VSM manufacturer to allow for the timely display of the data
elements at the CUCS.
A number of the parameters in this message are configurable from the VSM, and the
CUCS should alter its displays to match the specified values/limits.
A4.1.5.25 Message #3010: Body Relative Sensed States VSM Implementation
The Body Relative Sensed States message provides the inertial states of the UA, and
is pushed from the VSM to the CUCS. The VSM is responsible for determining the
rate at which this message is required for the CUCS to provide a timely status display
of these data elements to the operator. These directly sensed body-relative states are
packaged as a separate message type from other vehicle states because these terms
may need to be known at substantially higher rates for various control-related
functions.
The VSM should always populate this message with the latest data received from the
UA under control of the VSM. The VSM should NOT transmit this message to the
CUCS when it is not receiving the information contained in the message from the air
vehicle, as it is a false indication of the air vehicles status!
The STANAG data elements supported by the UA for which the VSM is being
implemented should be referenced appropriately to the required UA data element.
A significant number of the UA parameters as reported in this message must be
configured using the General Configuration Messages to assist in the display of caution
and alert conditions at the CUCS. Refer to the STANAG 4586 document for the list of
parameters, identified within the Message #41000, #41001, #41002 and #40000
descriptions, required to be configured and which message is used to configure the
parameter.
A4.1.5.26 Message #3002: Vehicle Operating States CUCS Implementation
The Vehicle Operating States Message provides the CUCS with a report of some of
the UA’s current operating states, for the more critical parameters. The CUCS
requests this message as required from the VSM. It is recommended that the reported
states be presented to the operator in the same location as the corresponding
demanded states for the specified data elements.
The Vehicle Operating States Message should be requested by the CUCS, if not
automatically transmitted from the VSM, following a new operator commanded value
to the VSM for applicable parameters, as this messages contains the “reported
commanded” values for those parameters. These parameters include:



New Altitude Demand
New Course (Heading) Demand
New Turn (Heading, Course) Rate Demand
A4 - 54
Edition A Version 1
AEP-84.1
 New Airspeed Demand
A4.1.5.27 Message #3002: Vehicle Operating States VSM Implementation
This message is used by the VSM to provide a “report” of the commanded state at the
VSM/UA for various parameters that can be set from the CUCS, and as simply a report
for other parameters deemed to be of a more critical nature for UA operations.
For the parameters that are the “reported command” values for parameters
commanded from the CUCS (Commanded Altitude, Commanded Course (Course,
Heading), Commanded Speed) it is recommended that the VSM sends this message
to the CUCS upon a change in state of any of these parameters deemed critical to
flight operations. This will immediately notify the operator of the new operating states,
and allow action to be taken if the state is not appropriate to the current operating
conditions. For the parameters that are a simple report of a vehicle state, such as the
“Current Propulsion Energy Level”, the VSM transmits this message at a rate required
for the CUCS to provide a timely status display of these data elements to the operator.
Specific implementation considerations follow.
The Altitude type and Speed type fields in this message are used to provide the report
of the frame of reference for which the VSM is interpreting/ using the “Commanded
Altitude” and “Commanded Speed” from the CUCS.
A4.1.5.28 Message #3007: Engine Operating States CUCS Implementation
This message is used to report the operating state of a given engine to the CUCS, and
where there is a requirement to status multiple engines; one such message is sent by
the VSM for each engine. The CUCS should distinguishably display the status for
each of the reported engines to the CUCS operator.
A4.1.5.29 Message #3007: Engine Operating States VSM Implementation
This message is used to report the operating state of a given engine, and where there
is a requirement to status multiple engines, one such message is required for each
engine. The intent of this message is to provide data for a generic set of indicators for
the operator, and the detailed information about an engine’s operating state and health
is a vehicle-specific function (See Remote Displays section). The VSM is responsible
for the translation of the corresponding vehicle native parameters to the discrete
STANAG data elements (for each element identified in the message) and their
corresponding “overall” status value in order to correctly fill in the STANAG message.
The STANAG requires the following status levels with their associated colours:
0 = No Status
1 = Low – Red
2 = Low – Yellow
3 = Low – Green
4 = Normal – Green
5 = High – Green
6 = High – Yellow
7 = High – Red
Table A4 - 4 provides a potential methodology for converting UA native variables, with
ranges, to the STANAG enumerated states. The columns would be filled with UA
native parameters, and their associated range of values, for the identified STANAG
parameter.
The “Reported Engine Command” parameter in this message is the reported command
value for the Message #2008, Engine Command parameter. The “Reported Engine
A4 - 55
Edition A Version 1
AEP-84.1
Command” parameter in this message identifies what engine command the air vehicle/
VSM is currently executing. The “Engine Status” parameter in this message is a report
of the current status (actual state) of the selected engine.
The “Engine Speed” (rpm) report is provided in this message. It is recommended that
this message be transmitted from the air vehicle/VSM upon change in state of the
Engine “status” parameters as a minimum. A VSM requiring to transmit the Engine
Speed (rpm) to a CUCS as a safely requirement would of course need to transmit this
message to the CUCS at a higher rate.
Data Element Name & Description
1
2
3
n
Engine Power Setting
Engine Speed 1
Engine Speed 2
Engine Speed 3
Engine Speed 1 Status
Engine Speed 2 Status
Output Shaft Torque
Temperature 1 Status
Temperature 2 Status
Temperature 3 Status
Temperature 4 Status
Lubricant Pressure Status
Lubricant Level Status
Fire Detection Sensor Status
Table A4 - 5: UA Specific Parameters and Associated Range of Values for Identified
STANAG Parameters
A4.1.5.30 Message #3001: Vehicle Operating Mode Report CUCS
Implementation
The Vehicle Operating Mode Report is used to report the current Vehicle Operating
mode, “Select Flight Path Control mode”. The Vehicle Operating Mode Report is used
in conjunction with the Vehicle Operating Mode Command (Message #2016).
A4.1.5.31 Message #3001: Vehicle Operating Mode Report VSM
Implementation
The VSM uses the Vehicle Operating Mode Report to report the current Vehicle
Operating mode, Flight Path Control Mode to the CUCS. The Vehicle Operating Mode
Report is used in conjunction with the Vehicle Operating Mode Command (Message
#2016).
The VSM is required to configure Message #3001, Reported Flight Path Control mode,
exactly the same as Message #2016 for the equivalent parameter to avoid conflicting
states. This means that the configuration from Message #40000, Field Configuration
A4 - 56
Edition A Version 1
AEP-84.1
Request, for Message #2016, Select Flight Path Control mode, that identifies which of
the “Flight Path Control Mode” are supported by the VSM for control from the CUCS,
are the same control modes that are required to be reported back to the CUCS. That
is, the VSM should not be reporting back a flight mode that it has identified as
unsupported in the command.
The VSM must also ensure that it correctly reports back the “vehicle specific” flight
modes that were configured, if applicable, for Message #2016, Select Flight Path
Control mode, using Message #41002, Field Configuration Enumerated Response.
A4.1.5.32 Message #3006: Vehicle Lights State VSM Implementation
This message is used to report the current state of the air vehicle lights to the CUCS.
The Message #3006, Navigation Lights State parameter identified in this message
must be configured with the same enumerations as established using Message
#40000, Field Configuration Command, for the Message #2007, Set Lights parameter,
as this message is used as a report to that message.
Note, it is expected that status reports will be available for all the supported “navigation
lights” commanded parameters as the default implementation, and there will be no
orphaned reports. For example, if a “navigation light” enumeration cannot be
commanded, it is expected that there is no requirement to have a report for the same
enumeration.
A4.1.5.33 Message #3006: Vehicle Lights State CUCS Implementation
This message is used to report the current state of the air vehicle lights to the CUCS.
A4.1.5.34 Message #3005: Flight Termination Mode Report CUCS
Implementation
The CUCS must be capable of receiving this message from the VSM, as well as be
capable of requesting the message from the VSM. This message is used to report the
Flight Termination Command set at the VSM and its current status. This message is
sent from the VSM to the CUCS in response to Message #2005 and whenever the
current status of flight termination changes.
Refer to the Message #2005 Implementation section for additional details.
A4.1.5.35 Message #3005: Flight Termination Mode Report VSM
Implementation
The VSM uses the Message #3005, Flight Termination Mode Report, to report the
Flight Termination mode currently set at the VSM and the current Flight Termination
state for that mode. The VSM must be capable of transmitting this message to the
CUCS upon a change in state of the Flight Termination mode, as well as upon request
for the message from the CUCS.
The Message #3005, Reported Flight Termination Mode parameter identified in this
message must be configured with the same enumerations as established for the
Message #2005, Flight Termination Command, Flight Termination mode parameter,
as this message is used as a report of the system status as a result of that command.
That is, it is expected that there will be a report for each of the “vehicle specific” flight
terminations modes that were added to Message #2005, Flight Termination Mode, as
applicable. It is not expected that there will be reports for which a commanded mode
has not been configured.
A4 - 57
Edition A Version 1
AEP-84.1
If the VSM is in the air vehicle, it should report that it is changing state to “Execute
Flight Termination Sequence” prior to any action that would preclude transmission of
this message to the CUCS.
Refer to the Message #2005 Implementation section for additional details.
A4.1.5.36 Null
A4.1.5.37 Message #4001: From-To-Next Waypoint States VSM
Implementation
This message is used to report where an air vehicle is coming from, where it is currently
going toward, and where it will be going next. This message is used to provide LOI 2/
LOI 3 control stations with the capability to monitor an air vehicle flight path to a limited
extent, to allow those operators to determine where the air vehicle will be located in
the near future for such things as payload planning purposes. It is recommended that
the VSM transmit this message to the CUCS upon change in location of the reported
Waypoints as a minimum, and potentially with a change in “waypoint times” if at a
higher rate.
The From, To, and Next waypoint reports in this messages are populated dependent
on the current air vehicles flight path control mode (Message #2016). This message
has been specifically defined to support the reporting of the From-To-Next waypoint
locations for the current mission that that air vehicle is flying while in the Waypoint flight
path control mode (Message #2016) mode of operation. The second specific purpose
of this message, is that while the air vehicle is in the Loiter or Slave to Sensor flight
path control mode (Message #2016) of operation, the “To Waypoint” in this message
is used by the air vehicle/ VSM to report the vehicles intended (reported commanded)
loiter position.
This message can also be used to provide support to operators with only LOI 2/3
control while in other modes of operation. While in the Loiter mode, or any flight path
control mode without a Next waypoint, the Next waypoint definition should be made 0
to indicate that the waypoint is not valid. The same applies to the “From Waypoint”
when the air vehicle is in any mode of operation or situation (i.e., have not passed first
waypoint in mission plan) where the “From Waypoint” definition is not valid. When the
air vehicle is in a mode of operation where none of the From-To-Next waypoints are
valid, this message is recommended not to be transmitted to the CUCS, such as
potentially while in the Flight Director mode of operation.
While the air vehicle is in the Autopilot (all), Autoland engage, Autoland Wave-off, or
Launch flight path control mode (Message #2016), the “From Waypoint”, “To
Waypoint”, and “Next Waypoint” can be defined by the VSM manufacturer as required
to identify the air vehicles flight path. The STANAG 4586 currently does not define a
generic method to identify the air vehicle flight path while in one of these modes of
operation, and therefore this could be a simple method of achieving this capability.
A4.1.5.38 Message #3016: Relative Route/Waypoint/Location Report
Message #3016 is used by the VSM/vehicle to report the either the relative route and
waypoint settings for each relative route that it is using or to report the single set of
slave to location parameters the VSM/vehicle is using to perform it loiter relative to the
slave to location settings specified in Message #2006. The VSM/vehicle sets Unique
A4 - 58
Edition A Version 1
AEP-84.1
ID 3016.02 to a value of “0” to report settings being used for each relative route, or for
all relative routes if Unique ID 3016.08 is set to null. If Unique ID 3016.08 is not set to
null, then a separate instance of Message #3016 must be used to report the relative
route/waypoint parameters being used for each relative route in the VSM/vehicle. The
VSM/vehicle sets Unique ID 3016.02 to a value of “1 or 2” to report the single set of
parameters that the VSM/vehicle is using to guide its loiter pattern (specified in
Message #2004) to the location relative to the position, orientation, distance and
possibly the looking angle or the relative altitude specified in Message #2006.
A4.1.5.39 Message #2014: Emergency Mode Command
This message shall be used to transmit the Emergency Mode to the VSM/UA that the
UA should enter if not in the Waypoint Flight Path Control Mode. The “Required Manual
Restore Time A and B fields” (Unique IDs 2014.09 and 2014.10) support operation of
a UAV where a sudden change of flight path due to loss of link could endanger other
aircraft.
The Link Loss time can be arbitrarily broken down into 3 segments: Time to detect and
report loss of uplink (TD), time that automatic operator recovery of control is possible
(TR), and time that automatic operator recovery of control is not possible (T N). These
actual times can be zero or near zero and are not defined by this standard. The figure
below shows the relation of these times.
TD
TR
TN
TD is the time from the last received uplink to a downlink report of the loss of uplink.
The last received message may be any STANAG message, a particular message, or
valid uplink received with no data, it is up to the system designer. This time normally
is under 1 minute, but there are no “correct” values. It is important to note that in many
cases the loss of uplink will also mean the loss of downlink, so the CUCS may not
receive the link loss report from the UA.
TR is the time from report of a loss of uplink that if the link is recovered, the operator
automatic regains flight control of the UA. Normally this time is to allow the system
and/or operator to try to reestablish uplink with the UA. In restricted airspace, the UA
may perform a maneuver, e.g., spiral up in altitude, to regain the uplink. In nonrestricted space the UA may not be allowed to perform a maneuver to avoid a collision
with other aircraft in the area. If the restricted area includes the entire flight path back
to the recovery area, this time may be set to a value longer than that transit time.
TN is the time after TD and TR have expired and before the UA will deviate from its
original flight path. This value is normally only used when flying in areas with other
aircraft potentially in close proximity, e.g., non-restricted airspace. It is assumed that
at the beginning of TN the operator will tell the proper entity, e.g., military ATC that the
UA is in a loss of link state and will be doing a maneuver in TN to attempt to regain link
and/or return to the recover location. Once having state the UA’s intentions, regaining
of the link should not automatically return to the original flight mode since that mode
may not match the announced intention. This could result in other aircraft moving out
of the way only to suddenly find out that they moved in to the flight path.
A4 - 59
Edition A Version 1
AEP-84.1
In Message #2014, Contingency A/B Delay is TR + TN and Required Manual Restore
Time A/B is TN. Once the UA is within this “time” from the planned loss link manoeuvre,
restoration of the link will not result in continuation of the current commanded flight
without a new Vehicle Operating Mode Command being received by the UA. It is up to
the CUCS to not send automatic Vehicle Operating Mode Commands during lost link
if this function is desired.
A4.1.5.40 Flight Mode Implementation Examples
Example number 1: Circular Loiter at Point B starting Loiter mode from Point A
1. Flight from Point A to B where the UA shall perform circular loiter pattern;
starting from altitude of 10,000 Ft and airspeed of 160 Kts climbing to 18,000 Ft,
loitering around Point B with reduced airspeed of 100 Kts.
ALT=18,000FT
Air Speed=160Kts
Air Speed=110Kts
Air Speed=110Kts
Air Speed=160Kts
B
A
A
ALT=18,000FT
ALT=10,000FT
B
ALT=10,000FT
Side View
Top View
Sequence Diagram:
A4 - 60
Edition A Version 1
AEP-84.1
LoiterVehicleControl
#2016 Flt Mode (12) ,Alt , Speed (Segment
A Towards the loiter path), Loiter W.P. (Lat.
Lon. )for Segment A
CUCS
VSM
Scenario 2
Segment B
T=T0
x
Segment A
T=T0
#2016 Flt Mode (12) ,Alt , Speed (Segment
A Towards the loiter path), Loiter W.P. (Lat.
Lon. ) For Segment B
x
T=T1
Segment B
Segment A
x
T=T1
#2017 Loiter Configuration, Type, Radius,
Bearing,
T=T0
x
T=T1
T0<T<T1
1.
Send Message #2016 to command Loiter mode. Specify commanded
altitude of 18,000 Ft, airspeed of 160 Kts and Point B Lat./Lon. coordinates.
Note: T=T0 means send this message before entering Loiter mode.
2.
Send again Message #2016 to command Loiter mode. Specify
commanded altitude of 18,000 Ft, change airspeed to 100 Kts and Point B
Lat./Lon. coordinates.
Note: T=T1 means: Send this message before entering Loiter circle
3.
Send Message #2017 for Loiter circle configuration.
Messages for the loiter example:
Message #2016 Vehicle Operating Mode Command.
Unique
ID
Field
Data Element Name
& Description
2002.00
0
0042.01
1
Example
Type
Units
Range
Presence Vector
Unsigned
4
Bitmapped
No Restrictions
03 FF FF FF
Time Stamp
Unsigned
5
0.001 s
See Section 1.7.2
time
A4 - 61
Edition A Version 1
AEP-84.1
Unique
ID
Field
0042.04
2
Data Element Name
& Description
Type
Units
Range
Select Flight Path
Control Mode
Unsigned
1
Enumerated
0 = No Mode
Specifies the method
for controlling the
vehicle’s flight path.
Manual control modes
lie in the range 1-10,
automatic control
modes lie in the range
11-31
Example
12 = Loiter
1 = Reserved 1
2 = Flight Director
3 - 10 = Reserved 310
11 = Waypoint (Fly
to predefined
waypoint(s) Altitude
and Airspeed in
route are taken from
waypoint messages
#13002 UA Position
Waypoint)
12 = Loiter
13 - 14 = Reserved
13-14
15 = Autopilot
(Autopilot engaged,
but manual override
of AV
16 = Terrain
Avoidance (Uses
Message #2016,
field 2 to define
clearance distance)
17 = NavAid (Slaved
Navigation relative
to a navigation
beacon.)
18 = Reserved 18
19 = Autoland
Engage
20 = Autoland
Wave-off
21 = Launch
22 = Slave to
Sensor
23=Fly Contingency A
24=Fly Contingency B
25=Slave to Location
26 - 31 = Reserved
26-31
32 - 255 = Vehicle
Specific
A4 - 62
Edition A Version 1
AEP-84.1
Unique
ID
Field
0043.04
3
Data Element Name
& Description
Type
Units
Range
Altitude Command
Type
Unsigned
1
Enumerated
0 = Not Specified
4
Commanded Altitude
2 = Vertical
Speed
3 = Rate-limited
altitude
Integer 3
0.02 m
Altitude hold value to
be achieved (ignored
in Altitude Command
Type = 2).
0043.06
5
Commanded Vertical
Speed
1
1 = Altitude
Enumeration 0 added
for backwards
compatibility to Edition
2.
0043.05
Example
-1,000 ≤ x ≤
100,000
493E0
(18,000 Ft)
Integer 2
0.05 m/s
-1,000 ≤ x ≤ 1,000
0
Unsigned
1
Enumerated
0 = Not Specified
1
Vertical Speed value
to be achieved
(Used in Altitude
Command Type = 2,
ignored in Altitude
Command Type = 1,
used as rate limit in
Altitude Command
Type = 3).
0043.07
6
Heading Command
Type
1 = Heading
Enumeration 0 added
for backwards
compatibility to Edition
2.
2 = Course
3 = Heading and
Course
4 = Roll
5 = Heading Rate
0043.21
7
Heading Reference
Unsigned
1
Enumerated
0 = True North
1
1 = Magnetic
North
A4 - 63
Edition A Version 1
AEP-84.1
Unique
ID
Field
0043.08
8
Data Element Name
& Description
Commanded
Heading
Example
Type
Units
Range
Integer 2
BAM
No Restrictions
45
Integer 2
BAM
No Restrictions
0
Integer 2
0.0001 rad/s
No Restrictions
10
Heading hold value to
be achieved (Used in
Heading Command
Type = 1 and 3,
ignored in Heading
Command Type = 2,
4, and 5). Provided in
True North if Heading
Reference is 0, and in
Magnetic North if
Heading Reference is
1.
0043.09
9
Commanded Course
Course value to be
achieved (Used in
Heading Command
Type = 2 and 3,
ignored in Heading
Command Type = 1, 4
and 5).
0043.10
10
Commanded Turn
Rate
Heading or Course
turn rate value to be
achieved (Used in
Heading Command
Type = 1 thru 3, and
5)
A zero commanded
rate indicates that the
AV should use its
default rates for the
Applicable Heading
Command type mode.
i.e.; Does not apply to
Heading Command
Type = 5.
A4 - 64
Edition A Version 1
AEP-84.1
Unique
ID
Field
0043.11
11
Data Element Name
& Description
Commanded Roll
Rate
Example
Type
Units
Range
Integer 2
0.0001 rad/s
No Restrictions
0
Integer 2
BAM
No Restrictions
0
Unsigned
2
0.5 m/s
x ≤ 10,000
(160 kts=
Roll rate value to be
achieved (used in
Heading Command
Type = 4)
A zero commanded
rate indicates that the
AV should use its
default rates.
0043.12
12
Commanded Roll
(Used in Heading
Command Type = 4)
0043.13
13
Commanded Speed
84.883m/s)
A9
0043.14
14
Speed Type
Defines speed type
(reference frame) for
all speed related fields
in this message.
Unsigned
1
Enumerated
0 = Indicated
Airspeed
1
1 = True Airspeed
2 = Ground
Speed
3 = Thrust
0043.15
15
Commanded
Waypoint Number
Unsigned
2
None
1 ≤ x < 65,535
1
Unsigned
2
10 Pa
x ≤ 107,500
10132.5
Unsigned
1
Enumerated
0 = Pressure
Altitude
1
As defined in Section
4.12, Mission
Messages.
0043.16
16
Altimeter Setting
Local Barometric
pressure at sea level.
Used to correct
pressure altitude to
barometric altitude.
0043.17
17
Altitude Type
Defines altitude type
(reference frame) for
all altitude related
fields in this message.
1 = Baro Altitude
2 = AGL
3 = WGS-84
A4 - 65
Edition A Version 1
AEP-84.1
Unique
ID
Field
0043.18
18
Data Element Name
& Description
Loiter Position
Latitude
Type
Units
Range
Integer 4
BAM
-π/2 ≤ x ≤ π/2
19
Loiter Position
Longitude
16995F58
Integer 4
BAM
No Restrictions
20
Thrust Direction
(35.213709
Degrees)
Manual Loiter position
longitude command.
2002.02
(31.768319
Degrees)
Manual Loiter position
latitude command.
0043.19
Example
190D6CFF
Integer 2
BAM
No Restrictions
12
Direction that the
thrust is directed.
2002.03
21
Thrust
Unsigned
1
%
No Restrictions
80
2002.01
22
Activity ID
Unsigned
3
None
No Restrictions
0
Used to identify goals,
behaviours and
constraints.
0 = Immediate Activity
Result:
The UA shall enter Loiter flight mode, climb towards Point B to reach the 18,000 Ft
altitude and fly at 160 Kts airspeed.
The next command message shall be:
Send Message #2016 again with ALT and Airspeed for segment B.
Unique
ID
Field
Data Element Name &
Description
2002.00
0
0042.01
1
Example
Type
Units
Range
Presence Vector
Unsigned
4
Bitmapped
No Restrictions
03 FF FF FF
Time Stamp
Unsigned
5
0.001 s
See Section 1.7.2
time
A4 - 66
Edition A Version 1
AEP-84.1
Unique
ID
Field
0042.04
2
Data Element Name &
Description
Type
Units
Range
Select Flight Path
Control Mode
Unsigned
1
Enumerate
d
0 = No Mode
Specifies the method for
controlling the vehicle’s
flight path. Manual
control modes lie in the
range 1-10, automatic
control modes lie in the
range 11-31
Example
12 = Loiter
1 = Reserved 1
2 = Flight Director
3 - 10 = Reserved 310
11 = Waypoint (Fly
to predefined
waypoint(s) Altitude
and Airspeed in
route are taken from
waypoint messages
#13002 UA Position
Waypoint)
12 = Loiter
13 - 14 = Reserved
13-14
15 = Autopilot
(Autopilot engaged,
but manual override
of AV
16 = Terrain
Avoidance (Uses
Message #2016,
field 2 to define
clearance distance)
17 = NavAid (Slaved
Navigation relative to
a navigation
beacon.)
18 = Reserved 18
19 = Autoland
Engage
20 = Autoland Waveoff
21 = Launch
22 = Slave to Sensor
23=Fly Contingency A
24=Fly Contingency B
25=Slave to Location
26 - 31 = Reserved
26-31
32 - 255 = Vehicle
Specific
A4 - 67
Edition A Version 1
AEP-84.1
Unique
ID
Field
0043.04
3
Data Element Name &
Description
Type
Units
Range
Altitude Command
Type
Unsigned
1
Enumerate
d
0 = Not Specified
Enumeration 0 added for
backwards compatibility
to Edition 2.
0043.05
4
Commanded Altitude
5
1 = Altitude
3 = Rate-limited
altitude
Integer 3
Commanded Vertical
Speed
1
2 = Vertical Speed
0.02 m
Altitude hold value to be
achieved (ignored in
Altitude Command Type
= 2).
0043.06
Example
-1,000 ≤ x ≤
100,000
493E0
(18,000 Ft)
Integer 2
0.05 m/s
-1,000 ≤ x ≤ 1,000
0
Unsigned
1
Enumerate
d
0 = Not Specified
1
Vertical Speed value to
be achieved
(Used in Altitude
Command Type = 2,
ignored in Altitude
Command Type = 1,
used as rate limit in
Altitude Command Type
= 3).
0043.07
6
Heading Command
Type
Enumeration 0 added for
backwards compatibility
to Edition 2.
1 = Heading
2 = Course
3 = Heading and
Course
4 = Roll
5 = Heading Rate
0043.21
7
Heading Reference
Unsigned
1
Enumerate
d
0 = True North
1
1 = Magnetic
North
A4 - 68
Edition A Version 1
AEP-84.1
Example
Unique
ID
Field
Data Element Name &
Description
Type
Units
Range
0043.08
8
Commanded Heading
Integer 2
BAM
No Restrictions
45
Integer 2
BAM
No Restrictions
0
Integer 2
0.0001
rad/s
No Restrictions
10
Integer 2
0.0001
rad/s
No Restrictions
0
Integer 2
BAM
No Restrictions
0
Heading hold value to be
achieved (Used in
Heading Command
Type = 1 and 3, ignored
in Heading Command
Type = 2, 4, and 5).
Provided in True North if
Heading Reference is 0,
and in Magnetic North if
Heading Reference is 1.
0043.09
9
Commanded Course
Course value to be
achieved (Used in
Heading Command
Type = 2 and 3, ignored
in Heading Command
Type = 1, 4 and 5)
0043.10
10
Commanded Turn Rate
Heading or Course turn
rate value to be
achieved (Used in
Heading Command
Type = 1 thru 3, and 5)
A zero commanded rate
indicates that the AV
should use its default
rates for the Applicable
Heading Command type
mode. i.e.; Does not
apply to Heading
Command Type = 5.
0043.11
11
Commanded Roll Rate
Roll rate value to be
achieved (used in
Heading Command
Type = 4)
A zero commanded rate
indicates that the AV
should use its default
rates.
0043.12
12
Commanded Roll
(Used in Heading
Command Type = 4)
A4 - 69
Edition A Version 1
AEP-84.1
Unique
ID
Field
Data Element Name &
Description
0043.13
13
Commanded Speed
Type
Units
Range
Unsigned
2
0.5 m/s
x ≤ 10,000
Example
(100kts=
56.59m/s)
71
0043.14
14
Speed Type
Unsigned
1
Defines speed type
(reference frame) for all
speed related fields in
this message.
Enumerate
d
0 = Indicated
Airspeed
1
1 = True Airspeed
2 = Ground Speed
3 = Thrust
0043.15
15
Commanded Waypoint
Number
Unsigned
2
None
1 ≤ x < 65,535
1
Unsigned
2
10 Pa
x ≤ 107,500
10132.5
Unsigned
1
Enumerate
d
0 = Pressure
Altitude
1
As defined in Section
4.12, Mission Messages.
0043.16
16
Altimeter Setting
Local Barometric
pressure at sea level.
Used to correct pressure
altitude to barometric
altitude.
0043.17
17
Altitude Type
Defines altitude type
(reference frame) for all
altitude related fields in
this message.
1 = Baro Altitude
2 = AGL
3 = WGS-84
0043.18
18
Loiter Position
Latitude
Integer 4
BAM
-π/2 ≤ x ≤ π/2
Degrees)
Manual Loiter position
latitude command.
0043.19
19
Loiter Position
Longitude
16995F58
Integer 4
BAM
No Restrictions
20
Thrust Direction
(35.213709
Degrees)
Manual Loiter position
longitude command.
2002.02
(31.768319
190D6CFF
Integer 2
BAM
No Restrictions
12
Unsigned
1
%
No Restrictions
80
Direction that the thrust
is directed.
2002.03
21
Thrust
A4 - 70
Edition A Version 1
AEP-84.1
Unique
ID
Field
Data Element Name &
Description
2002.01
22
Activity ID
Used to identify goals,
behaviours and
constraints.
Type
Units
Range
Unsigned
3
None
No Restrictions
Example
0
0 = Immediate Activity
Send Message #2017 Loiter Configuration for configuring Loiter circle at Point B.
Unique
ID
Field
Data Element Name &
Description
2004.00
0
0042.01
0041.04
Example
Type
Units
Range
Presence Vector
Unsigned
3
Bitmapped
No Restrictions
1
Time Stamp
Unsigned
5
0.001 s
See Section 1.7.2
time
2
Loiter Type
Unsigned
1
Enumerated
1 = Circular
1
2 = Racetrack
3 = Figure 8
4 = Hover
5 = ATC Hold
6 - 9 = Reserved
10 - 255 = Vehicle
Specific
0041.05
3
Loiter Radius
The radius of the turn for
Circular, Racetrack, and
Figure 8 patterns.
0041.06
4
Loiter Length
Used for Racetrack and
Figure 8 to define length
of pattern, centred
around the Loiter Point
in the direction of the
Loiter Bearing.
Unsigned
2
1.5 m
1.5 ≤ x
1000
Unsigned
2
1.5 m or s
1.5 ≤ x
1000
A4 - 71
Edition A Version 1
AEP-84.1
Unique
ID
Field
Data Element Name &
Description
2004.01
5
Loiter Length Units
Used for specifying the
units of measurement for
the Loiter Length.
Time-based loiter
lengths only apply to
Racetrack patterns.
0041.07
6
Loiter Bearing
Example
Type
Units
Range
Unsigned
1
Enumerated
0 = Distance (m)
Integer 2
BAM
No Restrictions
0
Unsigned
1
Enumerated
0 = Vehicle
Dependent
1
0
1 = Time (s)
The bearing of the loiter
pattern, referenced to
the Loiter Point, from
True North.
0041.08
7
Loiter Direction
Defines direction of turn,
viewed from above,
when rounding the loiter
point defined by “Vehicle
Steering Command”
Message .
2004.15
13
Flying Behaviour
1 = Clockwise
2 = CounterClockwise
3 = Into the wind
Unsigned
1
Enumerated
0 = Flyby
1
1 = Flyover
2 = Vehicle
Discretion (added
for backwards
compatibility to
Edition 2)
2004.17
14
Loiter Duration
Expected duration of a
loiter. A zero value
indicates forever.
2004.18
15
Loiter Duration Units
Specifies the units of
measurement for Loiter
Duration (2004.17).
2004.02
16
Activity ID
Used to identify goals,
behaviours and
constraints.
Unsigned
2
User
Specified
No Restrictions
0
Unsigned
1
Enumerated
0 = Lap
0
Unsigned
3
None
1=s
No Restrictions
0
0 = Immediate Activity
A4 - 72
Edition A Version 1
AEP-84.1
Result:
The UA shall loiter around Point B reducing airspeed to 100 Knots.
Example Number 2: Slave to Sensor Mode, starting from Point A at a target in
Point B.
1. Flight from Point A in Slave to Sensor Mode. Target is located at Point C. The
UA shall perform circular Loiter pattern when arriving Point B; starting from
altitude of 10,000 Ft and airspeed of 160 Kts climbing to 18,000Ft, loitering
around Point B with reduced airspeed of 100 Kts.
ALT=18,000FT
Air Speed=160Kts
Air Speed=110Kts
Air Speed=110Kts
HOLD
Air Speed=160Kts
B
A
A
ALT=18,000FT
ALT=10,000FT
B
ALT=10,000FT
C
C
Side View
Top View
A4 - 73
Edition A Version 1
AEP-84.1
Sequence Diagram:
SlaveToSensorControl
ED-3 messages
SlaveToSensorControl
CUCS
VSM
#2016 Flt Mode (22) ,Alt , Speed (Segment
A), Loiter W.P. (Lat. Lon.)
Segment B
T=T0
Segment A
x
T=T0
x
T=T1
#2016 Flt Mode (22) ,Alt , Speed (Segment
B for Loiter path), Loiter W.P. (Lat. Lon.)
T=T1
#2019 Slave to Sensor Loiter
Configuration, Type, Radius, Bearing,
loiter path, Duration,etc.
T0<T<T1
1. Send Message #2016 to command Slave to Sensor Mode. Specify
commanded altitude of 18,000 Ft, airspeed of 160 Kts and Point B Lat/Lon
Coordinates.
Note: T<T0 means send this message before entering Slave to Sensor Mode.
2. Send again Message #2016 to command Loiter mode. Specify commanded
altitude of 18,000 Ft, change airspeed to 100 Kts and Point B Lat/Lon.
Coordinates.
Note: T=T1 means: Send this message before entering Loiter circle
3. Send Message #2018 for Slave to Sensor circle configuration.
Messages for the Slave to Sensor example:
Message #2016 Vehicle Operating Mode Command.
A4 - 74
Edition A Version 1
AEP-84.1
Unique
ID
Field
Data Element Name &
Description
2002.00
0
0042.01
1
Example
Type
Units
Range
Presence Vector
Unsigned
4
Bitmapped
No Restrictions
03 FF FF FF
Time Stamp
Unsigned
5
0.001 s
See Section
1.7.2
time
A4 - 75
Edition A Version 1
AEP-84.1
0042.04
2
Select Flight Path
Control Mode
Unsigned
1
Specifies the method for
controlling the vehicle’s
flight path. Manual
control modes lie in the
range 1-10, automatic
control modes lie in the
range 11-31
Enumerated
0 = No Mode
1 = Reserved 1
22 = Slave to
Sensor
2 = Flight Director
3 - 10 = Reserved
3-10
11 = Waypoint (Fly
to predefined
waypoint(s)
Altitude and
Airspeed in route
are taken from
waypoint
messages #13002
UA Position
Waypoint)
12 = Loiter
13 - 14 = Reserved
13-14
15 = Autopilot
(Autopilot
engaged, but
manual override of
AV
16 = Terrain
Avoidance (Uses
Message #2016,
field 2 to define
clearance
distance)
17 = NavAid
(Slaved
Navigation relative
to a navigation
beacon.)
18 = Reserved 18
19 = Autoland
Engage
20 = Autoland
Wave-off
21 = Launch
22 = Slave to
Sensor
23=Fly Contingency
A
24=Fly Contingency
B
25=Slave to Location
26 - 31 = Reserved
26-31
A4 - 76
Edition A Version 1
AEP-84.1
Unique
ID
Field
Data Element Name &
Description
Type
Units
Range
Example
32 - 255 = Vehicle
Specific
0043.04
3
Altitude Command
Type
Unsigned
1
Enumerated
0 = Not
Specified
1
1 = Altitude
Enumeration 0 added for
backwards compatibility
to Edition 2.
2 = Vertical
Speed
3 = Rate-limited
altitude
0043.05
4
Commanded Altitude
Integer 3
0.02 m
Altitude hold value to be
achieved (ignored in
Altitude Command Type
= 2).
0043.06
5
Commanded Vertical
Speed
-1,000 ≤ x ≤
100,000
493E0
(18,000FT)
Integer 2
0.05 m/s
-1,000 ≤ x ≤
1,000
0
Unsigned
1
Enumerated
0 = Not
Specified
1
Vertical Speed value to
be achieved
(Used in Altitude
Command Type = 2,
ignored in Altitude
Command Type = 1,
used as rate limit in
Altitude Command Type
= 3).
0043.07
6
Heading Command
Type
1 = Heading
Enumeration 0 added for
backwards compatibility
to Edition 2.
2 = Course
3 = Heading and
Course
4 = Roll
5 = Heading
Rate
0043.21
7
Heading Reference
Unsigned
1
Enumerated
0 = True North
1
1 = Magnetic
North
A4 - 77
Edition A Version 1
AEP-84.1
Example
Unique
ID
Field
Data Element Name &
Description
Type
Units
Range
0043.08
8
Commanded Heading
Integer 2
BAM
No Restrictions
45
Integer 2
BAM
No Restrictions
0
Integer 2
0.0001 rad/s
No Restrictions
10
Integer 2
0.0001 rad/s
No Restrictions
0
Integer 2
BAM
No Restrictions
0
Heading hold value to be
achieved (Used in
Heading Command
Type = 1 and 3, ignored
in Heading Command
Type = 2, 4, and 5).
Provided in True North if
Heading Reference is 0,
and in Magnetic North if
Heading Reference is 1.
0043.09
9
Commanded Course
Course value to be
achieved (Used in
Heading Command
Type = 2 and 3, ignored
in Heading Command
Type = 1, 4 and 5)
0043.10
10
Commanded Turn Rate
Heading or Course turn
rate value to be
achieved (Used in
Heading Command
Type = 1 thru 3, and 5)
A zero commanded rate
indicates that the AV
should use its default
rates for the Applicable
Heading Command type
mode. i.e.; Does not
apply to Heading
Command Type = 5.
0043.11
11
Commanded Roll Rate
Roll rate value to be
achieved (used in
Heading Command
Type = 4)
A zero commanded rate
indicates that the AV
should use its default
rates.
0043.12
12
Commanded Roll
(Used in Heading
Command Type = 4)
A4 - 78
Edition A Version 1
AEP-84.1
Unique
ID
Field
Data Element Name &
Description
0043.13
13
Commanded Speed
Type
Units
Range
Unsigned
2
0.5 m/s
x ≤ 10,000
Example
(160kts=
84.883m/s)
A9
0043.14
14
Speed Type
Unsigned
1
Defines speed type
(reference frame) for all
speed related fields in
this message.
Enumerated
0 = Indicated
Airspeed
1
1 = True
Airspeed
2 = Ground
Speed
3 = Thrust
0043.15
15
Commanded Waypoint
Number
Unsigned
2
None
1 ≤ x < 65,535
1
Unsigned
2
10 Pa
x ≤ 107,500
10132.5
Unsigned
1
Enumerated
0 = Pressure
Altitude
1
As defined in Section
4.12, Mission Messages.
0043.16
16
Altimeter Setting
Local Barometric
pressure at sea level.
Used to correct pressure
altitude to barometric
altitude.
0043.17
17
Altitude Type
Defines altitude type
(reference frame) for all
altitude related fields in
this message.
1 = Baro Altitude
2 = AGL
3 = WGS-84
0043.18
18
Loiter Position
Latitude
Integer 4
BAM
-π/2 ≤ x ≤ π/2
Degrees)
Manual Loiter position
latitude command.
0043.19
19
Loiter Position
Longitude
16995F58
Integer 4
BAM
No Restrictions
20
Thrust Direction
(35.213709
Degrees)
Manual Loiter position
longitude command.
2002.02
(31.768319
190D6CFF
Integer 2
BAM
No Restrictions
12
Direction that the thrust
is directed.
A4 - 79
Edition A Version 1
AEP-84.1
Unique
ID
Field
Data Element Name &
Description
2002.03
21
2002.01
22
Example
Type
Units
Range
Thrust
Unsigned
1
%
No Restrictions
80
Activity ID
Unsigned
3
None
No Restrictions
0
Used to identify goals,
behaviours and
constraints.
0 = Immediate Activity
Result:
The UA shall enter Slave to Sensor flight mode, climb towards Point B to reach the
18,000 Ft altitude and fly at 160 Kts airspeed.
The next command message shall be:
Send Message #2016 again with ALT and Airspeed for segment B.
The next command message shall be:
Send again Message #2016 Vehicle Operating Mode Command with Airspeed for
segment B.
Unique
ID
Field
Data Element Name
& Description
2002.00
0
0042.01
1
Example
Type
Units
Range
Presence Vector
Unsigned
4
Bitmapped
No Restrictions
03 FF FF FF
Time Stamp
Unsigned
5
0.001 s
See Section 1.7.2
time
A4 - 80
Edition A Version 1
AEP-84.1
Unique
ID
Field
0042.04
2
Data Element Name
& Description
Type
Units
Range
Select Flight Path
Control Mode
Unsigned
1
Enumerated
0 = No Mode
Specifies the method
for controlling the
vehicle’s flight path.
Manual control modes
lie in the range 1-10,
automatic control
modes lie in the range
11-31
1 = Reserved 1
Example
22 = Slave to
Sensor
2 = Flight Director
3 - 10 = Reserved 310
11 = Waypoint (Fly
to predefined
waypoint(s) Altitude
and Airspeed in
route are taken from
waypoint messages
#13002 UA Position
Waypoint)
12 = Loiter
13 - 14 = Reserved
13-14
15 = Autopilot
(Autopilot engaged,
but manual override
of AV
16 = Terrain
Avoidance (Uses
Message #2016,
field 2 to define
clearance distance)
17 = NavAid (Slaved
Navigation relative to
a navigation
beacon.)
18 = Reserved 18
19 = Autoland
Engage
20 = Autoland Waveoff
21 = Launch
22 = Slave to Sensor
23=Fly Contingency A
24=Fly Contingency B
25=Slave to Location
26 - 31 = Reserved
26-31
32 - 255 = Vehicle
Specific
A4 - 81
Edition A Version 1
AEP-84.1
Unique
ID
Field
0043.04
3
Data Element Name
& Description
Type
Units
Range
Altitude Command
Type
Unsigned
1
Enumerated
0 = Not Specified
4
Commanded Altitude
2 = Vertical Speed
3 = Rate-limited
altitude
Integer 3
0.02 m
Altitude hold value to
be achieved (ignored
in Altitude Command
Type = 2).
0043.06
5
Commanded Vertical
Speed
1
1 = Altitude
Enumeration 0 added
for backwards
compatibility to Edition
2.
0043.05
Example
-1,000 ≤ x ≤
100,000
493E0
(18,000FT)
Integer 2
0.05 m/s
-1,000 ≤ x ≤ 1,000
0
Unsigned
1
Enumerated
0 = Not Specified
1
Vertical Speed value
to be achieved
(Used in Altitude
Command Type = 2,
ignored in Altitude
Command Type = 1,
used as rate limit in
Altitude Command
Type = 3).
0043.07
6
Heading Command
Type
1 = Heading
Enumeration 0 added
for backwards
compatibility to Edition
2.
2 = Course
3 = Heading and
Course
4 = Roll
5 = Heading Rate
0043.21
7
Heading Reference
Unsigned
1
Enumerated
0 = True North
1
1 = Magnetic
North
A4 - 82
Edition A Version 1
AEP-84.1
Unique
ID
Field
0043.08
8
Data Element Name
& Description
Commanded
Heading
Example
Type
Units
Range
Integer 2
BAM
No Restrictions
45
Integer 2
BAM
No Restrictions
0
Integer 2
0.0001 rad/s
No Restrictions
10
Heading hold value to
be achieved (Used in
Heading Command
Type = 1 and 3,
ignored in Heading
Command Type = 2,
4, and 5). Provided in
True North if Heading
Reference is 0, and in
Magnetic North if
Heading Reference is
1.
0043.09
9
Commanded Course
Course value to be
achieved (Used in
Heading Command
Type = 2 and 3,
ignored in Heading
Command Type = 1, 4
and 5)
0043.10
10
Commanded Turn
Rate
Heading or Course
turn rate value to be
achieved (Used in
Heading Command
Type = 1 thru 3, and
5)
A zero commanded
rate indicates that the
AV should use its
default rates for the
Applicable Heading
Command type mode.
i.e.; Does not apply to
Heading Command
Type = 5.
A4 - 83
Edition A Version 1
AEP-84.1
Unique
ID
Field
0043.11
11
Data Element Name
& Description
Commanded Roll
Rate
Example
Type
Units
Range
Integer 2
0.0001 rad/s
No Restrictions
0
Integer 2
BAM
No Restrictions
0
Unsigned
2
0.5 m/s
x ≤ 10,000
(100kts=
Roll rate value to be
achieved (used in
Heading Command
Type = 4)
A zero commanded
rate indicates that the
AV should use its
default rates.
0043.12
12
Commanded Roll
(Used in Heading
Command Type = 4)
0043.13
13
Commanded Speed
56.59m/s)
71
0043.14
14
Speed Type
Defines speed type
(reference frame) for
all speed related fields
in this message.
Unsigned
1
Enumerated
0 = Indicated
Airspeed
1
1 = True Airspeed
2 = Ground Speed
3 = Thrust
0043.15
15
Commanded
Waypoint Number
Unsigned
2
None
1 ≤ x < 65,535
1
Unsigned
2
10 Pa
x ≤ 107,500
10132.5
Unsigned
1
Enumerated
0 = Pressure
Altitude
1
As defined in Section
4.12, Mission
Messages.
0043.16
16
Altimeter Setting
Local Barometric
pressure at sea level.
Used to correct
pressure altitude to
barometric altitude.
0043.17
17
Altitude Type
Defines altitude type
(reference frame) for
all altitude related
fields in this message.
1 = Baro Altitude
2 = AGL
3 = WGS-84
A4 - 84
Edition A Version 1
AEP-84.1
Unique
ID
Field
0043.18
18
Data Element Name
& Description
Loiter Position
Latitude
Type
Units
Range
Integer 4
BAM
-π/2 ≤ x ≤ π/2
19
Loiter Position
Longitude
Integer 4
BAM
No Restrictions
20
Thrust Direction
0000
NA – Automatic
from the Payload
Manual Loiter position
longitude command.
2002.02
0000
NA – Automatic
from the Payload
Manual Loiter position
latitude command.
0043.19
Example
Integer 2
BAM
No Restrictions
12
Direction that the
thrust is directed.
2002.03
21
Thrust
Unsigned
1
%
No Restrictions
80
2002.01
22
Activity ID
Unsigned
3
None
No Restrictions
0
Used to identify goals,
behaviours and
constraints.
0 = Immediate Activity
Send Message #2018 Slave to Sensor Configuration for configuring UA pattern at
Point B.
Unique
ID
Field
Data Element Name
& Description
2004.00
0
0042.01
1
Example
Type
Units
Range
Presence Vector
Unsigned
4
Bitmapped
No Restrictions
03 FF FF FF
Time Stamp
Unsigned
5
0.001 s
See Section 1.7.2
time
A4 - 85
Edition A Version 1
AEP-84.1
Unique
ID
Field
Data Element Name
& Description
Type
Units
Range
19800.03
2
Station Number 116
Unsigned
2
Bitmapped
0x0001 = Stn #1
Example
0x0008 = Stn #4
0x0002 = Stn #2
0x0004 = Stn #3
0x0008 = Stn #4
0x0010 = Stn #5
0x0020 = Stn #6
0x0040 = Stn #7
0x0080 = Stn #8
0x0100 = Stn #9
0x0200 = Stn #10
0x0400 = Stn #11
0x0800 = Stn #12
0x1000 = Stn #13
0x2000 = Stn #14
0x4000 = Stn #15
0x8000 = Stn #16
19800.04
3
Component Number
Location ID on a
given Station
Location
Unsigned
2
Bitmapped
0x0001 = #1
0x0001 = #1
0x0002 = #2
0x0004 = #3
0x0008 = #4
0x0010 = #5
0x0020 = #6
0x0040 = #7
0x0080 = #8
0x0100 = #9
0x0200 = #10
0x0400 = #11
0x0800 = #12
0x1000 = #13
0x2000 = #14
0x4000 = #15
0x8000 = #16
A4 - 86
Edition A Version 1
AEP-84.1
Unique
ID
Field
Data Element Name
& Description
Type
Units
Range
19800.04
4
Sub-Component
Number
Unsigned
2
Bitmapped
0x0001 = #1
Example
0x0001 = #1
0x0002 = #2
Location ID on a
given Component
Location
0x0004 = #3
0x0008 = #4
0x0010 = #5
0x0020 = #6
0x0040 = #7
0x0080 = #8
0x0100 = #9
0x0200 = #10
0x0400 = #11
0x0800 = #12
0x1000 = #13
0x2000 = #14
0x4000 = #15
0x8000 = #16
19800.06
19800.07
19800.08
5
6
7
Slave to Sensor
Offset
Integer 4
Slave to sensor
Direction
Integer 2
Slave to Sensor
Look Down Angle
Integer 2
m
No Restrictions
(6000m)
00001770
BAM
No Restrictions
(90deg)
3FFF
BAM
0 ≤ x ≤ π/2
0
0 = Look down angle
is not defined
A4 - 87
Edition A Version 1
AEP-84.1
Unique
ID
Field
19800.09
8
Data Element Name
& Description
Type
Units
Range
Station Number 1732
Unsigned
2
Bitmapped
0x0001 = Stn #17
Example
0x0002 = Stn #18
0x0004 = Stn #19
0x0008 = Stn #20
0x0010 = Stn #21
0x0020 = Stn #22
0x0040 = Stn #23
0x0080 = Stn #24
0x0100 = Stn #25
0x0200 = Stn #26
0x0400 = Stn #27
0x0800 = Stn #28
0x1000 = Stn #29
0x2000 = Stn #30
0x4000 = Stn #31
0x8000 = Stn #32
19801.05
9
Addressed Sensor
Identifies which
sensor(s) to control
where applicable.
Laser pointers and
rangefinders
integrated with EO/IR
sensor are not
considered a
separate sensor
19801.06
10
Link Sensor
Determines if the
Slave to Sensor flight
mode is linked to this
sensor. Only one
sensor can be linked
at a time.
Unsigned
1
Bitmapped
0x01 = EO
0x02 = IR
0x02 = IR
0x04 = Payload Specific
Unsigned
1
Enumerated
0 = Un-Linked
1 = Linked
1 = Linked
A4 - 88
Edition A Version 1
AEP-84.1
Unique
ID
Field
Data Element Name
& Description
0041.04
11
Loiter Type
Type
Units
Range
Unsigned
1
Enumerated
1 = Circular
Example
1 = Circular
2 = Racetrack
3 = Figure 8
4 = Hover
5 = ATC Hold
6 - 9 = Reserved
10 - 255 = Vehicle
Specific
0041.05
12
Loiter Radius
The radius of the turn
for Circular,
Racetrack, and
Figure 8 patterns.
0041.06
13
Loiter Length
Used for Racetrack
and Figure 8 to
define length of
pattern, centered
around the Loiter
Point in the direction
of the Loiter Bearing.
2004.01
14
Loiter Length Units
Used for specifying
the units of
measurement for the
Loiter Length. Timebased loiter lengths
only apply to
Racetrack patterns.
0041.07
15
Loiter Bearing
Unsigned
2
1.5 m
1.5 ≤ x
1000
Unsigned
2
1.5 m or s
1.5 ≤ x
1000
Unsigned
1
Enumerated
0 = Distance (m)
0
Integer 2
BAM
1 = Time (s)
No Restrictions
0
The bearing of the
loiter pattern,
referenced to the
Loiter Point, from
True North.
A4 - 89
Edition A Version 1
AEP-84.1
Unique
ID
Field
Data Element Name
& Description
0041.08
16
Loiter Direction
Defines direction of
turn, viewed from
above, when
rounding the loiter
point.
Type
Units
Range
Unsigned
1
Enumerated
0 = Vehicle
Dependent
Example
1
1 = Clockwise
2 = CounterClockwise
3 = Into the wind
2004.15
17
Flying Behaviour
Unsigned
1
Enumerated
0 = Flyby
1
1 = Flyover
2 = Vehicle
Discretion (added
for backwards
compatibility to
Edition 2)
2004.17
18
Loiter Duration
Expected duration of
a loiter. A zero value
indicates forever.
2004.18
19
Loiter Duration
Units
Unsigned
2
User
Specified
No Restrictions
0
Unsigned
1
Enumerated
0 = Lap
0
Unsigned
3
None
1=s
Specifies the units of
measurement for
Loiter Duration
(2004.17).
2004.02
20
Activity ID
Used to identify
goals, behaviours
and constraints.
No Restrictions
0
0 = Immediate
Activity
A4.1.6 Payload Command and Status
As stated in the STANAG, “The Payload and Vehicle Subsystem Messages have been
developed to provide a set of generic messages for common UA payloads, and for the
common UA subsystems. A CUCS and/or VSM do not have to support the generic
payload messages or the vehicle subsystem messages that do not apply to the
systems configuration. However, if one of the generically identified payload or
subsystem messages is applicable for the UA system, the identified formatted DLI
messages must be supported.”
A generic set of Payload Types have been identified in the STANAG 4586/AEP-84
Chapter 4, and an associated set of generic messages has been identified for use with
A4 - 90
Edition A Version 1
AEP-84.1
each of these payload types. The set of generic DLI messages associated with a
payload type must be used for that payload when installed on an UA to achieve
STANAG 4586 compliance.
The Station number field in all the messages provides the link to the specified payload
in the formatted DLI messages. It is the VSM’s responsibility to provide the correct
payload identification in the Payload Configuration Message (Message #21001) as this
determines which messages will be used to control and status the payload at the
identified station.
For example, if the Payload type in the Payload Configuration Message is set to
“EO/IR” for Stn #1, then the VSM will be reporting the configuration and status of the
station #1 payload with the EO/IR Configuration State (Message #21100) and the
EO/IR/Laser Operating State (Message #21101) messages respectively. The CUCS
will control the payload using the Payload Steering Command (Message #19001) and
the EO/IR/Laser Payload Command (Message #19100) messages. Any other type of
messages directed at Stn #1 will be rejected by the VSM as invalid.
The following payload message sequence is expected for the identified payload
messages:
a.
UA Payload Configuration
The overall UA payload configuration message is sent to identify the
payloads available on the UA, and their location;
i.
b.
Message #21001: Payload Configuration
Configuration Messages
The configuration messages are sent for each payload on-board the
UA to identify the specific payload configuration as applicable:
i.
Message #21100: EO/IR - Configuration State
ii. Message #41001: Field Configuration Double response; for
configuring Message #19001 data fields for specified Payload
iii.
c.
Other General Configuration Messages, as required.
Status Messages
Once the payloads configuration has been correctly identified to the CUCS
for control, the VSM will commence sending the required status messages for the
payloads on an as required basis. After the VSM has identified a payload configuration
to the CUCS, it is recommended that it send a status message for the payload to
identify its current status. The status messages are thereafter sent on a scheduled
basis (See the Scheduled Message Update Command (Message #17001)), on change
in payload status, or in response to a change in payload demand from the CUCS.
d.
Control Messages
Payload control messages are sent from the CUCS to the VSM to
control a payload at an identified station as demanded.
Table A4 - 5 below depicts the generally expected message sequence between the
CUCS and the VSM, in initialising the CUCS for the EO/IR Payload type, and
subsequently commanding the payload and reporting its status.
CUCS
VSM
A4 - 91
Edition A Version 1
AEP-84.1
Configuration Request: ->
Refer to CUCS VSM Connection Sequence
below.
<- Message #21001: Payload Configuration
One per payload station.
<- Message #21100: EO/IR Configuration State
One per EO/IR payload station.
<- General Configuration Messages:
One per configurable parameter, Message
#41000, 41001, 41002, 41003, per EO/IR station.
<- Message #21101: EO/IR/Laser Operating
State
Message #19001: Payload Steering
Command ->
Message #19100: EO/IR/Laser Payload Cmd >
One per EO/IR payload station.
Table A4 - 6: EO/IR/Laser Payload Message Sequence
A4.1.6.1 Message #19001: Payload Steering Command CUCS Implementation
The intent of the Payload Steering Command Message is for the CUCS to execute
control over a steerable payload, to control the pointing angle, slew rate, stare point
and/or FOV, located at the identified UA station number. This message contains the
CUCS demanded values to the payload. These demands may be through manual
control via an operator interface, or through an automated search process.
The Station Number field in the message identifies the location of the payload on the
UA, and it must have been identified to the CUCS using the Payload Configuration
Message (Message #21001).
The Payload Steering Command is used to control the three different types of payloads
as follows:

EO/IR Payloads

Fixed Camera Payloads

SAR Payloads
There are various potential mount orientations for a payload on an UA, such as a tiltover-pan mount or a tilt-over-roll mount, therefore the implementation of the steering
commands is based on the camera centreline. Commanding a “Set Centreline
Azimuth Angle” and “Set Centreline Elevation Angle” commands a camera orientation
with respect to the UA. The VSM must translate the commands to the payload as
required to attain the correct demanded payload orientation.
Commanding a “Horizontal Slew Rate” will cause the FOV of the payload to move in a
horizontal orientation. Commanding a “Vertical Slew Rate” will cause the FOV of the
payload to move vertically. The slew rate commands are in the camera axes, not in
the UA body axes, which is what the operator expects. If a “joystick” were moved to
the right, then the operator expects the sensor/camera to slew to the right in the
coordinate system they are viewing (e.g., the window’s x axis). If the operator moves
the joystick up, then it is expected that the image will slew in the window’s y axis. No
additional math is required to perform this functionality. The intended use of these
A4 - 92
Edition A Version 1
AEP-84.1
commands for a tilt-over-pan mount is to map the tilt control to the “Vertical Slew Rate”
and pan to the “Horizontal Slew Rate.” The intended use of these commands for a tiltover-roll mount is to map the tilt control to the “Vertical Slew Rate” and roll to the
“Horizontal Slew Rate.”
The “Set Zoom” commands provides two methods to control the payload zoom. For
payload that only have controls to zoom in/out, the last three enumerations 1-3 are
used. For payloads that support setting the FOV to a specific value, enumeration 0 is
used in conjunction with the “Set Horizontal Field of View” (field #10 and “Set Vertical
Field of View” (field #11) are used. For payloads that have fixed FOVs, the
enumerations 1-3 are used, with the FOV changing each time the enumeration
changes from “Stop Zoom” to “Zoom In/Out”, i.e. the rising edge.
The “Set Horizontal FOV” and “Set Vertical FOV” commands provide the capability to
demand distinct horizontal and vertical FOV settings. On fixed aspect ratio payloads
the Vertical Field of View (VFOV) is ignored by the VSM. Message #19100,
EO/IR/Laser Payload Command, Addressed Sensor field identifies if the FOV is being
controlled for the EO or the IR sensor.
The “Latitude,” “Longitude,” and “Altitude” fields provide the capability to demand a
sensor stare point directly to the UA for a specified altitude.
The “Set Focus” and “Focus Type” fields provide the capability to set the focus (focus
closer, focus farther) and focus type (Auto, Manual) for a particular payload.
A4.1.6.2 Message #19001: Payload Steering Command VSM Implementation
The intent of the Payload Steering Command Message is for the CUCS to execute
control over a steerable payload, to control the pointing angle, slew rate, stare point
and/or FOV, located at the identified UA station number. This message contains the
CUCS demanded values to the payload. These demands may be through manual
control via an operator interface, or through an automated search process.
The VSM is responsible to convert the commands received in this message to the
correct payload format and then correctly route the commands to the selected payload.
The “Set Horizontal FOV” and “Set Vertical FOV” commands provide the capability to
demand distinct horizontal and vertical FOV settings. On fixed aspect ratio payloads
the Vertical Field of View (VFOV) is ignored by the VSM. These same commands are
used to control an IR payload with fixed zoom levels, therefore the VSM is required to
step the zoom based on a change in demand of the zoom from the CUCS.
The configuration for the “Set Horizontal FOV” and “Set Vertical FOV” parameters in
this message are from Message #21100, EO/IR Configuration State, in the associated
Field of Regard parameters. The configuration of the Horizontal and Vertical Slew
Rate limits is conducted from the VSM using Message #41001, Configuration Double
Response, to identify whether or not the parameters are supported by the payload,
and if so, it is used to configure the limits, etc for the parameters.
A4.1.6.2.1 EO/IR Payload Steering
The sensor pointing mode (Set EO/IR/Laser Pointing Mode) for an EO/IR payload is
commanded from the EO/IR/Laser Payload Command Message (Message #19100),
therefore it is the responsibility of the VSM to ensure the appropriate fields in the
Payload Steering Command (Message #19001) are used for the selected pointing
mode, and to disregard the redundant fields. The VSM uses Message #40000, Field
Configuration Request, to report to the CUCS which fields in Message #19001,
Payload Steering Command, are not available for selection based on the currently
A4 - 93
Edition A Version 1
AEP-84.1
selected “Set EO/IR Pointing Mode” from Message #19100, EO/IR/Laser Payload
Command. The CUCS should limit the operator interface as per the report.
A4.1.6.2.2 Fixed Camera Steering
The Payload Steering Command (Message #19001) is used to control a “Fixed”
camera type’s FOV (Message #21001). All other fields within this message (Message
#19001) are ignored for a “Fixed” camera payload.
A4.1.6.2.3 SAR Payload Steering
The control over the SAR payload type’s pointing angles and FOV are conducted from
the Payload Steering Command Message (Message #19001). It is a VSM
responsibility to ensure the Payload Steering Commands are filtered according to the
currently selected “SAR Mode” as commanded by the SAR Payload Command
Message (Message #19200), when the message is being used for a SAR payload
type.
A4.1.6.3 Message #19100: EO/IR/Laser Payload Command CUCS
Implementation
The EO/IR/Laser Payload Command Message (Message #19100) is used by the
CUCS to instruct the VSM to generate all commands for EO/IR/Laser payloads except
for payload pointing, manual focus and Field of View (FOV) change commands which
are covered in the Payload Steering Command (Message #19001).
The Addressed Sensor field allows the capability to control the EO and IR sensors
individually where applicable, such as for FOV, and the Image Output command
provides for the selection of the image output from the EO/IR payload. It is
recommended for consistency, that the Addressed Sensor field and the Image Output
field be coupled in order that you are controlling the sensor for the image being viewed.
For EO/IR payloads, this message is used in conjunction with the Payload Steering
Command (Message #19001). The “Set EO/IR Pointing Mode” field commands the
pointing mode of the camera. The status is reported back to the CUCS in the Pointing
Mode field of the EO/IR/Laser Operating State Message (Message #21101). The
following command associations between the EO/IR Pointing modes and the Payload
Steering Command are recommended:

EO/IR Pointing Mode (Msg.#191000): No Value
o



Msg #19001: N/A
EO/IR Pointing Mode: Angle Relative to UA
o
Msg #19001: Set Centreline Azimuth Angle
o
Msg #19001: Set Centreline Elevation Angle
EO/IR Pointing Mode: Slewing Rate Relative to UA
o
Msg #19001: Horizontal Slew Rate
o
Msg #19001: Vertical Slew Rate
EO/IR Pointing Mode: Slewing Rate Relative to Inertial
The Inertial slewing pointing mode is used to slew the payload with respect to payload
FOV and stabilized, if available, to earth referenced coordinates.
o
Msg #19001: Horizontal Slew Rate
o
Msg #19001: Vertical Slew Rate
A4 - 94
Edition A Version 1
AEP-84.1

EO/IR Pointing Mode: Lat-Long Slaved
The Lat-Long Slaved pointing mode is used to direct the payload sensor toward an
earth referenced coordinate. The latitude, longitude and altitude specify the earth
referenced coordinate.

o
Msg #19001: Latitude
o
Msg #19001: Longitude
o
Msg #19001: Altitude
EO/IR Pointing Mode: Target Slaved
The Target Slaved pointing mode is used to initiate a payload specific auto-track mode.
Adjustment of the active tracking location is not supported directly by Message #19001
and will require the VSM to implement this function if required. However the target
tracking box may be adjusted using the centreline angle or slew rate fields.
o
Msg #19001: N/A.
The “Set IR Polarity” field commands the polarity setting for the IR sensor.
Refer to EO/IR Configuration State (Message #21100), EO/IR/Laser Operating State
(Message #21101), and Payload Steering Command (Message #19001) messages for
additional implementation guidelines.
This message provides for the control of a standard Laser Pointer, Laser Range finder,
and a Laser designator. (It is assumed that if present, a laser pointer/ designator/range
finder will be integrated into the EO/IR payload type.) The VSM will ignore the laser
fields within the message if a laser range finder capability is not integrated into the EO
payload, or is not available on-board the UA.
The EO/IR/Laser Payload Command is used to control the System Operating mode
and the sensor state of the fixed payload. All other fields within this message are
ignored for a fixed camera payload.
A4.1.6.4 Message #19100: EO/IR/Laser Payload Command VSM
Implementation
The EO/IR/Laser Payload Command Message is used by the CUCS to execute control
over the EO/IR payload, with the exception of pointing, manual focus and Field of View
(FOV), located on the UA at the specified station number. It is the responsibility of the
VSM to receive this message from the CUCS and route the payload commands to the
specified payload.
The fields in Message #19001 that are not associated with the currently reported/
commanded EO/IR Pointing Mode in Message #19100 must be ignored by the VSM.
It is recommended that the Field Configuration Request (Message #40000) be used
by the VSM to report the controllability of Message #19001 parameters from the CUCS.
The VSM is required to report the controllability/availability of the System Operating
Mode states, Set EO Sensor Mode states, Set IR Polarity Mode states, and Set EO/IR
Pointing Mode states in this message, through Message #40000, Field Configuration
Request, in order for the CUCS to configure its displays for controlling the sensor
correctly.
This message provides for the control of a standard Laser Pointer, Laser Range finder,
and a Laser designator. (It is assumed that if present, a laser pointer/designator/range
finder will be integrated into the EO/IR payload type.) The VSM will ignore the laser
A4 - 95
Edition A Version 1
AEP-84.1
fields within the message if a laser range finder capability is not integrated into the EO
payload, or is not available on-board the UA.
A4.1.6.5 Message #19200: SAR Payload Command CUCS Implementation
The SAR Payload Command Message is used by the CUCS to execute control over a
SAR payload located at the specified UA station, with the exception of pointing and
FOV commands.
The Set Radar State, Set Radar Mode, Set Moving Target Indicator (MTI) mode, and
Set Resolution are commanded from this message, while the states are reported back
to the CUCS from the VSM using the SAR Operating State Message (Message
#21200).
A4.1.6.6 Message #19200: SAR Payload Command VSM Implementation
The SAR Payload Command Message is used by the CUCS to execute control over a
SAR payload located at the specified UA station, with the exception of pointing and
FOV commands. It is the responsibility of the VSM to correctly convert the commands
to the correct payload format and transmit them to the specified payload on-board the
UA.
A4.1.6.7 Message #24000: Stores Management System Command CUCS
Implementation
The Stores Management System Command Message is used by the CUCS to execute
control over the deployable payloads on-board the UA through the VSM. The message
is also used to control the state of all weapons, and their sensors, located on-board
the UA. The CUCS is required to implement the transmission of this message if the
CUCS supports “dispensable” payloads. As this is a very specific capability, it is
recommended this functionality be placed within a separate dialog, only to be opened
as required.
The Station Number field in the message identifies the location of the deployable
payload/weapon on the UA, and it must be identified to the CUCS using the Payload
Configuration Message (Message #21001).
The following message is used in conjunction with the Stores Management System
Command Message (Message #24000) to provide for the control and status of a
Dispensable payload:
 Stores Management System Status (Message #26000)
A4.1.6.8 Message #24000: Stores Management System Command VSM
Implementation
The Stores Management System Command Message is used by the CUCS to execute
control over the deployable payloads on-board the UA through the VSM. The message
is also used to control the state of all weapons, and their sensors, located on-board
the UA. A VSM is required to implement reception of this message if it supports this
functionality.
The Station Number and Device Number fields in the message identify the location of
the deployable payload/weapon on the UA, and it must be identified to the CUCS using
the Payload Configuration Message (Message #21001).
A4 - 96
Edition A Version 1
AEP-84.1
The following message is used in conjunction with the Stores Management System
Command message to provide for the control and status of a Dispensable payload:

Stores Management System Status (Message #26000)
The VSM is required to report to the CUCS which states in the fields contained in the
Stores Management System Command are available for control from the CUCS in
order for the CUCS to correctly configure its displays.
A4.1.6.9 Message #19400: Communications Relay Command CUCS
Implementation
The Communication Relay Command Message is used by the CUCS to execute
control over the Communications Relay located on-board the UA at the specified
station number. The CUCS is required to implement the transmission of this message
if the CUCS supports “Communication Relay”.
The Station Number field in the message identifies the location of the payload on the
UA, and it must be identified to the CUCS using the Payload Configuration Message
(Message #21001). The communication relay radio is treated like a repeater, i.e. two
separate radios, A & B, whose audio channels are linked. This message also assumes
that the allowable radio frequencies and other parameters, e.g. transmission mode
(AM, FM,..), are loaded before flight and cannot be changed while in flight. These
predefined radio configurations are assigned configuration numbers that are selectable
from this message. The operator would select the configuration for both radio A and
radio B to enable the repay (Repeater) function.
The following message is used in conjunction with the Communications Relay
Command Message to provide for the control and status of a Communications Relay
payload:
 Communication Relay Status (Message #21400)
 Communication Relay Configuration Status (Message #21401)
A4.1.6.10 Message #19400: Communications Relay Command VSM
Implementation
This message reports the current status of all functions commanded in the
Communications Relay Command Message (Message #19400) as well as the
Configuration Name stored in the radio.
The following messages are used in conjunction with the Communications Relay
Command Message (Message #19400) to provide for the control and status of a
Communications Relay payload:

Communication Relay Status (Message #21400)

Communication Relay Configuration Status (Message #21401)
The VSM is required to report to the CUCS which states in the Set Relay State field
contained in the Communication Relay Command are available for control from the
CUCS through Message #40000 in order for the CUCS to correctly configure its
displays.
A4.1.6.11 Message #19500: Payload Data Recorder Control CUCS Command
Implementation
The Payload Data Recorder Command Message is used by the CUCS to command a
Data Recorder located on-board the UA by device number. The CUCS is required to
implement the transmission of this message if the CUCS supports “Recorder”
A4 - 97
Edition A Version 1
AEP-84.1
payloads, and a VSM is required to implement the reception of this message if it
supports Recorder functionality.
The following messages are used in conjunction to provide for the configuration,
control and status reporting of a Recorder payload:
 Vehicle Payload/Recorder Configuration (Message #21501)
 Payload Data Recorder Status (Message #21500)
 Payload Data Recorder Control Command (Message #19500)
The CUCS is required to configure its displays in accordance with the configuration for
the Payload Data Recorder, by station number, as received from the VSM.
A4.1.6.12 Message #19500: Payload Data Recorder Control Command VSM
Implementation
The CUCS is required to implement the transmission of this message if the CUCS
supports “Recorder” payloads, and a VSM is required to implement the reception of
this message if it supports Recorder functionality.
The following messages are used in conjunction to provide for the configuration,
control and status reporting of a Recorder payload:


Vehicle Payload/Recorder Configuration (Message #21501)
Payload Data Recorder Status (Message #21500)

Payload Data Recorder Control Command (Message #19500)
The VSM is required to report to the CUCS which states in the various fields, contained
in the Payload Data Recorder Control Command message, are available for control
from the CUCS in order for the CUCS to correctly configure its displays. The VSM uses
the Field Configuration Command Message (Message #40000) for this purpose.
A4.1.6.13 Message #19000: Payload Bay Command CUCS Implementation
The Payload Bay Command is used by the CUCS to command a Payload Bay door to
open or close dependent on its current state. The Payload Configuration Message
(Message #21001) identifies if there is a payload bay door associated with a payload
station. The CUCS is required to implement the transmission of this message if the
CUCS supports “Payload Bay” door control, and a VSM is required to implement the
reception of this message if it supports payload doors.
A4.1.6.14 Message #19000: Payload Bay Command VSM Implementation
The CUCS is required to implement the transmission of this message if the CUCS
supports “Payload Bay” door control, and a VSM is required to implement the reception
of this message if it supports payload doors.
A4.1.6.15 Message #19600: Terrain Data Update Command CUCS
Implementation
The CUCS is required to implement the transmission of this message if the CUCS
supports terrain updates for a VSM that produces Message #21101 where the Latitude
(20), Longitude (21) and Altitude (22) fields are valid as indicated by the Image Position
enumeration (19). The sensor providing the image position updates uses the terrain
data to converge on an image location solution. The CUCS pushes the terrain
A4 - 98
Edition A Version 1
AEP-84.1
elevation data using Message #19600 for each latitude and longitude pair that is
received in a Message #21101 where the image position is valid.
A message from the VSM to the CUCS to request this data explicitly will be added in
future editions of the STANAG. It is an optional message for the CUCS to support for
AEP-84 Volume I implementations. One implementation workaround would be for the
CUCS to issue the message only if the VSM configures the message fields of Msg
#19600 to enabled using Msg #40000 Field Configuration Request.
A4.1.6.16 Message #21001: Payload Configuration CUCS Implementation
The intent of this message is to provide the CUCS with payload configuration on initial
start-up and on a change basis. One instance of this message is sent from the VSM to
the CUCS for each employed payload station during initialisation for configuration and
mission planning purposes. An instance of the message should be received each time
the configuration changes.
NOTE:
Payload class is used to determine which DLI messages are to be
supported for the payload. Payload Type and Subtype provide specific
identification of the payload. Payload Name allows a man readable name
to be associated with a particular payload.
A4.1.6.17 Message #21001: Payload Configuration VSM Implementation
The intent of this message is to provide the CUCS with payload configuration on initial
start-up and on a change basis. One instance of this message is sent from the VSM to
the CUCS for each employed payload station during initialisation for configuration and
mission planning purposes. An instance of the message should be sent each time the
configuration changes.
The Payload Configuration message is used to identify the payload located at a
specified station on-board the UA. Specifying the Payload Type within the Payload
Configuration Message identifies to the CUCS, which payload messages the VSM
expects to be used to control, configure, and report the status of the payload at the
specified station. This mechanism allows a group of Payload messages to be used
with any payload (e.g., a new payload could be controlled using the EO/IR message
group) by selecting the “EO/IR” Payload type from the Payload Configuration Message.
A VSM manufacturer could easily map an unspecified/new payload as required to be
controlled using the “EO/IR” payload message group.
The message identifies if there is a door associated with one of the payload stations,
and provides the capability to identify the number of recording devices, if any, located
on-board the UA.
Payload class is used to determine which DLI messages are to be supported for the
payload. Payload Type and Subtype provide specific identification of the payload.
Payload Name allows a man readable name to be associated with a particular payload.
A4.1.6.18 Message #21100: EO/IR Configuration State CUCS Implementation
The intent of the EO/IR Configuration State Message is for the VSM to provide the
configuration of an EO/IR payload to the CUCS, if one is present on the UA. The
CUCS must support the reception of this message if it supports the “EO/IR” payload
type. For implementation purposes, it is recommended that the display of the
configuration data elements be placed in dialogs.
A4.1.6.19 Message #21100: EO/IR Configuration State VSM Implementation
A4 - 99
Edition A Version 1
AEP-84.1
The intent of the EO/IR Configuration State message is for the VSM to provide the
configuration of an EO/IR payload to the CUCS, if one is present on the UA. The VSM
is only required to support this message if it supports an EO/IR payload.
The Station Number field in the message identifies the location of the payload on the
UA, and it must have been identified to the CUCS using the Payload Configuration
Message (Message #21001).
A4.1.6.20 Message #21101: EO/IR/Laser Operating State CUCS
Implementation
The intent of the EO/IR Operating State Message is for the VSM to provide the status
of an EO/IR payload to the CUCS, if one is present on the UA. The CUCS must support
the reception of this message if it supports the “EO/IR” payload type. For
implementation purposes, it is recommended that the display of the data elements for
the real-time feedback elements, such as Control mode and current FOV, be located
on the main sensor control panel.
A4.1.6.21 Message #21101: EO/IR/Laser Operating State VSM Implementation
The intent of the EO/IR Operating State Message is for the VSM to provide the status
of an EO/IR payload to the CUCS, if one is present on the UA. A VSM is only required
to support this message if it supports an EO/IR payload.
The Station Number field in the message identifies the location of the payload on the
UA, and it must be identified to the CUCS using the Payload Configuration message
(Message #21001). The System Operating mode state parameter identified in the
message is used to determine the Payload Operating mode. When the System
Operating mode state is reported as “Active”, the Pointing mode state must accurately
reflect the pointing mode of the payload.
For payloads that do not embed the camera pointing vector relative to the earth,
Message #4000 would normally be used to convert payload point relative to the UA to
relative to the earth.
The reported azimuth, elevation (tilt), and rotation angles define the pointing direction
of the camera relative to the body axes of the UA. The rotation of the camera FOV is
with respect to the UA horizon, where zero rotation signifies the UA horizon is parallel
to the image horizontal FOV. For a conventional 2-axis tilt-over-pan mount with the
mount aligned to the UA reference axes, the pointing angles are:

Centreline azimuth = Pan

Centreline elevation = Tilt

Camera rotation = 0
If the mount is not exactly aligned to the UA reference axes, then appropriate
corrections should be applied in the VSM.
For other types of camera mounts, the VSM must derive these angles based on the
characteristics of that amount. For example, for a tilt-over-roll camera mount, where
roll is the outer gimbal axis and is parallel to the roll axis of the UA (platform roll
measured positive if the mount is rolled to the left of the UA body) and the inner gimbal
axis is in the fore-aft direction (with 0 corresponding to forward-looking and -PI/2
corresponding to down), the following transformations apply:

Centreline azimuth = atan2 (sin (roll)*sin (tilt), cos (tilt))

Centreline elevation = asin (cos (roll)*sin (tilt))
A4 - 100
Edition A Version 1
AEP-84.1

Camera rotation = atan2 (sin (roll), cos (roll)*cos (tilt))
where the atan2 (y, x) function computes the principal value of the arc tangent of y/x,
using the signs of both arguments to determine the quadrant of the return value.
The “IR Polarity Status” field reports the current polarity setting for the IR sensor.
A4.1.6.22 Message #21200: SAR Operating State CUCS Implementation
The intent of the SAR Operating State Message is for the VSM to provide the status of
the SAR payload to the CUCS, if one is present on the UA. The CUCS must support
the reception of this message if the CUCS supports a “SAR” payload type.
The Station Number field in the message identifies the location of the payload on the
UA, and it must have been identified to the CUCS using the Payload Configuration
Message (Message #21001).
A4.1.6.23 Message #21200: SAR Payload Operating State VSM
Implementation
The intent of the SAR Operating State Message is for the VSM to provide the status of
the SAR payload to the CUCS, if one is present on the UA. A VSM is required to
support this message if it supports a SAR payload.
The Station Number field in the message identifies the location of the payload on the
UA, and it must be identified to the CUCS using the Payload Configuration Message
(Message #21001).
The VSM is responsible to send the correct state, and not allow invalid states for the
selected payload control mode.
A4.1.6.24 Message #26000: Stores Management System Status CUCS
Implementation
This message is used to display the status of all weapons, and their sensors, located
on-board the UA. The CUCS is also required to implement the reception of this
message if the CUCS supports “dispensable” payloads. As this is a very specific
capability, it is recommended this functionality be placed within a separate dialog, only
to be opened as required.
The Station Number field in the message identifies the location of the deployable
payload/weapon on the UA, and it must be identified to the CUCS using the Payload
Configuration Message (Message #21001).
The following message is used in conjunction with the Stores Management System
Status Message (Message #26000) to provide for the control and status of a
Dispensable payload:
 Stores Management System Command (Message #24000)
A4.1.6.25 Message #26000: Stores Management System Status VSM
Implementation
The Stores Management System Status Message is used by the VSM to report the
status of the deployable payloads on-board the UA. The message is also used to
display the status of all weapons, and their sensors, located on-board the UA. The
VSM is required to implement this message if it supports this functionality.
The Station Number field in the message identifies the location of the deployable
payload/weapon on the UA, and it must be identified to the CUCS using the Payload
Configuration Message (Message #21001).
A4 - 101
Edition A Version 1
AEP-84.1
The following message is used in conjunction with the Stores Management System
Status Message (Message #26000) to provide for the control and status of a
Dispensable payload:

Stores Management System Command (Message #24000)
A4.1.6.26 Message #21400: Communications Relay Status CUCS
Implementation
The CUCS is required to implement the reception of this message if the CUCS
supports “Communication Relay” payloads.
The Station Number field in the message identifies the location of the payload on the
UA, and it must be identified to the CUCS using the Payload Configuration Message
(Message #21001).
The following message is used in conjunction with the Communications Relay Status
Message (Message #21400) to provide for the control and status of a Communications
Relay payload:
 Communication Relay Command (Message #19400)
A4.1.6.27 Message #21400: Communications Relay Status VSM
Implementation
The Communication Relay Status Message is used by the VSM to report the status of
a Communications Relay located on-board the UA at the specified station number.
A VSM is required to implement this message if it supports this functionality.
The Station Number field in the message identifies the location of the payload on the
UA, and it must be identified to the CUCS using the Payload Configuration Message
(Message #21001).
The following message is used in conjunction with the Communications Relay Status
Message (Message #21400) to provide for the control and status of a Communications
Relay payload:

Communication Relay Command (Message #19400)
The VSM is required to configure the states in the Report Relay State field to the same
values as in the Set Relay State field of the Communication Relay Command.
A4.1.6.28 Message #21500: Payload Data Recorder Status CUCS
Implementation
The CUCS is required to implement the reception of this message if the CUCS
supports “Recorder” payloads, and a VSM is required to implement this message if it
supports Recorder functionality.
The following messages are used in conjunction to provide for the configuration,
control and status of a Recorder payload:
 Vehicle Payload/Recorder Configuration (Message #21501)
 Payload Data Recorder Status (Message #21500)
 Payload Data Recorder Control Command (Message #19500)
A4.1.6.29 Message #21500: Payload Data Recorder Status VSM
Implementation
A4 - 102
Edition A Version 1
AEP-84.1
The Payload Data Recorder Status Message is used by the VSM to report the status
of a Data Recorder located on-board the UA by device number. The CUCS is required
to implement the reception of this message if the CUCS supports “Recorder” payloads,
and a VSM is required to implement this message if it supports Recorder functionality.
The following messages are used in conjunction to provide for the configuration,
control and status of a Recorder payload:


Vehicle Payload/Recorder Configuration (Message #21501)
Payload Data Recorder Status (Message #21500)

Payload Data Recorder Control Command (Message #19500)
A4.1.6.30 Message #21501: Vehicle Payload/Recorder CUCS Configuration
Implementation
The Vehicle Payload/Recorder Configuration Message is used by the VSM to identify
to the CUCS which on-board recorders are associated with which on-board payloads.
The message is to be sent once for each recorder/payload pair. The CUCS is required
to implement the reception of this message if the CUCS supports “Recorder” payloads.
The message is used by the CUCS to identify which on-board recorder is associated
with which on-board payload. The CUCS displays may then be configured to identify
the payload/recorder relationship to the operator thus providing a more User Friendly
interface.
The following messages are used in conjunction with the Vehicle Payload/Recorder
Configuration Message (Message #21501) to provide for the configuration, control and
status of a Recorder payload:
 Payload Data Recorder Status (Message #21500)
 Payload Data Recorder Control Command (Message #19500)
A4.1.6.31 Message #21501: Vehicle Payload/Recorder Configuration VSM
Implementation
The Vehicle Payload/Recorder Configuration Message is used by the VSM to identify
to the CUCS which on-board recorders are associated with which on-board payloads.
The message is to be sent once for each recorder/payload pair. A VSM is required to
implement this message if it supports Recorder functionality.
The following messages are used in conjunction with the Vehicle Payload/Recorder
Configuration Message (Message #21501) to provide for the configuration, control and
status of a Recorder payload:
 Payload Data Recorder Status (Message #21500)
 Payload Data Recorder Control Command (Message #19500)
A4.1.6.32 Message #21000: Payload Bay Status CUCS Implementation
The Payload Bay Status Message is used by the VSM to report the Payload Bay door
status to the CUCS. The Payload Configuration Message (Message #21001) identifies
if there is a payload bay door associated with a payload station. The CUCS is required
to implement the reception of this message if the CUCS supports “Payload Bay” door
control, and a VSM is required to implement the transmission of this message if it
supports payload doors.
A4.1.6.33 Message #21000: Payload Bay Status VSM Implementation
A4 - 103
Edition A Version 1
AEP-84.1
The Payload Bay Status Message is used by the VSM to report the Payload Bay door
status to the CUCS. The Payload Configuration Message (Message #21001) identifies
if there is a payload bay door associated with a payload station. The CUCS is required
to implement the reception of this message if the CUCS supports “Payload Bay” door
control, and a VSM is required to implement the transmission of this message if it
supports payload doors.
A4.1.7 IFF Command and Status
A4.1.7.1 Message #5000: IFF/SSR Code Command Implementation
Message #5000 provides the capability to control the Identify Friend or Foe (IFF)
and/or Secondary Surveillance Radar (SSR) equipment located on board the UA from
the CUCS. It is recommended that all the functionality available for IFF/SSR control
from the CUCS be placed within a dedicated dialog, in conjunction with the associated
status as received from the VSM in the IFF/SSR Status Report Message (Message
#6000). It is recommended that this message only be sent from the CUCS to the VSM
to change the state of any of the controlled parameters within the message, as the
message is large.
Upon reception of the IFF/SSR Code Command (Message #5000) from the CUCS, the
VSM is required to immediately send the required command states to the IFF/SSR
equipment on board the UA.
Message #5000 permits individual enabling and disabling of Modes 1, 2, 3/A, C, 4, S,
and 5. Transponder codes are encoded in the message as described in AEP-84
Volume II Section 4.6.1.
Mode S parameters are defined in ICAO Annex 10 to the Convention on International
Civil Aviation, Volume IV. This document should be consulted for details on Mode S
functionality and capabilities.
Mode 5 parameters are defined in STANAG 4193. This document should be consulted
for details on Mode 5 functionality and capabilities.
One aspect of Mode 5 capability is the use of an extended (two-byte) Mode 1 code. If
this code is used, then the equivalent short (one-byte) Mode 1 code is implicitly
embedded within the extended code, as defined in STANAG 4193. If both the short
and long forms of the Mode 1 codes are sent in one instance of Message #5000, then
the CUCS must ensure that the short Mode 1 code is properly embedded in the long
Mode 1 code. The embedding is as follows:
The 3 high-order bits of the Extended Code make up the 3 high-order bits of the legacy
Mode 1 code. The 5th and 6th high-order bits of the Extended Code make up the 5th
and 6th high-order bits of the legacy Mode 1 code. The 4th high-order bit of the legacy
Mode 1 code (as with all Mode 1 codes) is 0. For example:
Extended Code
Legacy Code
7777
73
5432
50
3375
33
Sample C code that would calculate the correct legacy code to put into Unique ID
1500.04 given a value for Unique ID 1500.19:
A4 - 104
Edition A Version 1
AEP-84.1
legacyCode = (extendedCode >> 6) & 0x3B;
Unique ID 5000.03 in either message may be up to eight characters, although many
countries only allow seven characters. The desired Aircraft ID should be left-justified,
and unused characters up to (but not including) the null terminator should be filled with
spaces (hex 0x20). Only numeric and capital alphabetical characters are permitted.
Unique ID 1500.20 is two bytes long to accommodate a potential change to the Mode
5 encoding for National Origin. The current STANAG 4193 allows for up to 31 different
values, but the most recent NATO country code table have values up to 99.
A4.1.7.2 Message #5001: IFF/SSR Identification of Position Command
Implementation
When the CUCS sends this command, it is the equivalent of a pilot pressing the
Identification of Position (I/P) button on the physical IFF/SSR control panel. This
causes the transponder to add a special code to the normal response code, and
transmit the code for an implementation-specific period of time. This is the expected
vehicle response when Message #5001 is received by the VSM.
If the IFF/SSR subsystem on the UA supports premature suppression of the I/P
transmission, then the CUCS may send Message #5001 with Unique ID 1501.4 set to
0 (Normal) to command that suppression.
A4.1.7.3 Message #5002: IFF Key Control Command Implementation
When the CUCS sends this command, the VSM is expected to immediately take the
indicated action on the cryptographic keys within the IFF subsystem on the UA.
If the CUCS is attempting only to switch the Mode 4 key from A to B (or vice versa),
then Unique IDs 1502.05 (Mode 4 Hold), 1502.07 (Mode 5 Hold), and 1502.06
(Zeroize) should be set to 0 (No Change).
When setting any of Unique IDs 1502.05, 1502.07, or 1502.06, the fields that are not
being commanded should be set to 0 (No Change). Unique ID 1502.04 (Mode 4 A/B)
should be set to the current value unless it is also desired to change the Mode 4 key.
For the Zeroize command (Unique ID 1502.06), the action to clear the indicated keys
is expected to take place with no additional delay.
A4.1.7.4 Message #5003: IFF/SSR Bit Command Implementation
This message provides the capability to initiate the Built-In Test (BIT) functionality of
the IFF/SSR subsystem on the UA. It is assumed that a BIT must run to completion,
so there is no option to cancel an on-going BIT. The use of 0 (No Change) in Unique
ID 1503.04 (IFF/SSR BIT Command) should produce no action in the VSM (it is
included for consistency).
A4.1.7.5 Message #6000: IFF/SSR Status Report Implementation
It is recommended that the CUCS provide a display for each of the parameters as
contained within the IFF/SSR Status Report Message. Upon reception of the IFF/SSR
Status Report Message at the CUCS from the VSM, the CUCS should immediately
update the state of each of the parameters within the display. It is recommended that
the IFF/SSR status displays be collocated with their associated commanded values,
as sent to the VSM in the IFF/SSR command Messages (#5000, #5001, #5002, and
#5003).
The CUCS may pull this message from the VSM to update the status of the IFF/SSR
parameters at the CUCS. Upon a request for this message from the CUCS, the VSM
A4 - 105
Edition A Version 1
AEP-84.1
is required to populate the IFF/SSR Status Report Message with the most recent
equipment status, potentially through an UA query, and then immediately transmit this
message to the CUCS.
It is recommended that this message also be sent by the VSM in the following cases:

Receipt of a properly formatted and valid IFF/SSR Code Command (Message
#5000) and successful completion of the actions required by that message

Receipt of a properly formatted and valid IFF/SSR Identification of Position
Command (Message #5001) and successful completion of the actions required
by that message

Termination of transmission of Identification of Position (I/P) after the systemspecific duration has expired

Receipt of a properly formatted and valid IFF Key Control Command (Message
#5002) and successful completion of the actions required by that message

Receipt of a properly formatted and valid IFF/SSR BIT Command (Message
#5003) and successful completion of the actions required by that message

Completion of a BIT initiated by a valid IFF/SSR BIT Command (Message
#5003)
Details about specific Unique ID/fields can be found in Section 4.7.1 of AEP-84 Volume
II.
A4.1.8 Handover Logic
CUCS Authorisation Request (Message #1) and the VSM Authorisation Response
(Message #2) messages are used to initiate and monitor the handover process. For
handover using a single data link, Vehicle Data Link Transition Coordination Message
(Message #34000) is used to switch the connection of the UA data link (VDT) from the
Relinquishing CUCS to the Acquiring CUCS.
A4.1.8.1 Handover Using 2 Data Links
Handovers utilizing two separate data links can provide for transfer of control without
an intermediate “lost link” to the UA. Handovers of this type are also known as a “Make
Before Break” or “positive control” handovers. By using two data links, LOI 3 and 4
control can be passed from a “Relinquishing CUCS” to an “Acquiring CUCS” using
standard discovery, configuration, and control request messages. No specialized
handover messages are required.
A4.1.8.1.1 Assumptions

The UA that is the subject of the handover has 2 bi-directional data links; one
communicating with the Relinquishing CUCS, the control or primary link and
one communicating with the Acquiring CUCS referred to as the secondary link.

The Acquiring CUCS is configured to communicate with the UA using
compatible port numbers and IP addresses received from the UA via Message
#32301, UA IP Disclosure Message.

The current controlling (i.e., primary) link maintains positive control of the UA
during the handover sequencing.
A4 - 106
Edition A Version 1
AEP-84.1

The Acquiring CUCS has established connection to its CDT links.
A4.1.8.1.2 Pre-Handover
The Relinquishing CUCS UA System Operator (USOP) establishes communication
with the Acquiring CUCS UA System Operator (USOP) and transmits the following
information/data:

UA tail number/ID

Current mission the UA is executing

UA position, altitude, heading, and estimated start time of Handover (H/O)

If necessary, inform ATC of H/O

Frequencies, CDL profile and COMSEC keys to establish a functional data link
with the UA to be handed over

Relinquishing CUCS configures the UA secondary VDT per agreed upon data
terminal characteristics;
In response, the Acquiring CUCS USOP performs the following actions:

Calculates and sets Control System (CS) D/L antenna position to the estimated
UA position at H/O

Acquiring CUCS configures the CDT to communicate with the UA secondary
VDT

If necessary, contact ATC to inform of H/O and for area traffic update

Inform the Relinquishing CUCS that it is ready to begin the H/O transition
A4.1.8.1.3 Handover Sequence
There are four phases involved in managing a connection between a CUCS and a
VSM/UA/Payload Station entities.
The phases are:
 Discovery
 Downloading Configuration Data
 Requesting LOI Connection
 Release
During these phases the CUCS will discover an entity and its capabilities. If the entity
is a VSM, UA or Payload Station, the operator can then choose to establish one (or
more) LOI connection(s) with the entity. If the entity is a data terminal, the CUCS only
has the ability to request full control of it. There are no LOIs between a CUCS and a
data terminal.
A4.1.8.1.3.1 Discovery
The Acquiring CUCS performs Discovery of the UA Vehicle per standard procedures
described in Section A4.1.2.3.1 Connection Phase 1: Discovery, of this Annex.
A4.1.8.1.3.2 Downloading Configuration Data
A4 - 107
Edition A Version 1
AEP-84.1
The Acquiring CUCS configures itself for the desired LOI 3/4 of the UA/payload per
procedures in Section A4.1.2.3.2 Connection Phase 2: Downloading Configuration
Data. [This step may be skipped if the Acquiring CUCS has preconfigured for LOI
3/4 of the UA.]
A4.1.8.1.3.3 Requesting LOI Connection
The acquiring CUCS requests authorisation for partial or complete control of the
AV/payload using message #4.
The AV, if it supported this type of handover would send message #4 to the
relinquishing CUCS indicating the functions that are being requested.
If the relinquishing CUCS supports this message it could either use a preloaded table
and or operator input to determine what, if any functions would be transferred. It
would then send a message #5, Positive Handover Authorisation Granted message
to the AV, which would send the message to the acquiring CUCS.
At this point the handover occurs when the acquiring CUCS uses message # 1 to
request control. If the acquiring CUCS requests modes that were not authorised the
AV will ignore the requested transfer and send a "Nak" to the acquiring CUCS. In the
case where all control of an AV or payload is requested by the acquiring CUCS, then
the relinquishing CUCS ceases to have authority for those modes, i.e. a complete
transfer of authorisation.
Non-Sunny day Cases
All STANAG 4586 message headers contain the version number of the standard.
The version number can be used to verify if the CUCS/VSM was implemented before
the positive handover was accepted into the standard.
The sunny day case assumed that all three components, Relinquishing CUCS,
Acquiring CUCS and AV implemented the positive handover messages. Below are a
series of non-Sunny day cases:
 In the case were the acquiring CUCS does not support positive handover (i.e.
previous version), the AV would know this based on the version in the
message header and would not send the new messages to both CUCS when
a message #1 was received.
 In the case where the AV implemented a previous version, the acquiring and
relinquishing CUCS would know that from the version number and would not
assume a positive handover was possible.
 In the case where the AV did implement a current version, but chose to not
implement the positive handover messages, during discovery by the CUCS it
would disable the new uplink message from the CUCS, thus signifying that it
did not support this function. If a new enumeration was added to message 1
as suggested, then the CUCS would send a "Nak" when a positive transfer
was requested.
 In the case where the relinquishing CUCS does not support positive
handover, the AV would know this based on the version number in the
wrapper. If the suggested enumeration was not added to message #1, the AV
would assume the Relinquishing CUCS request was a non-positive handover
and the acquiring CUCS would have to assume after no response, that the
relinquishing CUCS did not support positive handover. If the new enumeration
was added, then the AV would send a "Nak" in response to a positive
handover request.
For LOI 3/4 Control, the Acquiring CUCS requests LOI 3/4 Override Control of the
UA/payload per the procedure described in Section A4.1.2.3.3, Connection Phase 3:
A4 - 108
Edition A Version 1
AEP-84.1
Establish Connection. Both the Relinquishing and Acquiring CUCS will be notified of
the results via Message #2.
A4.1.8.1.3.4
Handover Status Report
The Handover Status Report, Message #35000, may be used to report the status of
a transition in the VDT data link control from one controlling UCS to another, as a
result of a Vehicle Data Link Transition Coordination message. The VSM would send
the appropriate “status” of the transfer to the relinquishing CUCS based on the
available status from the relinquishing CDT. Additionally, either CUCS may use this
message to communicate a failure condition to the VSM by setting the Status field to
Handover Failed.
A4.1.8.1.3.5 Release LOI Control
A connection between a CUCS and an entity can be released for reasons such as:




The CUCS requests the connection to be released
The entity spontaneously releases the connection
Another CUCS requests to override the connection
The CUCS hands control over to another CUCS
Section A4.1.2.3.4.1, Releasing an LOI Connection for VSMs, UA and Payload
Stations, in this document provides the sequence for release of LOI control of an Entity.
A4.1.8.2
Handover Using a Single Data Link
Payload only handover cannot occur separately from the vehicle using only a single
data link. A UA with a single data link, such as a STANAG 7085 compliant link, can
only support uplink communication (UA/payload commands) with one CUCS at a time;
thus control of both the UA (LOI 4) and payload (LOI 3) are possible. A procedure for
this type of handover, sometimes called “throw and catch” is outlined in the following
paragraphs.
A4.1.8.2.1 Assumptions

The Acquiring CUCS is configured to communicate with the UA using
compatible port numbers and IP addresses received from the UA via
Message #32301, UA IP Disclosure Message.

The Acquiring CUCS has established connection to its CDT links
A4.1.8.2.2 Pre-Handover
Same as for dual link, Section A4.1.8.1.2 above
A4.1.8.2.2 Handover Sequence

The Relinquishing CUCS sends Message #34000 with the Data Link Time Out
Limit set to a value “T1” >0. This commands the UA to drop the CDL
connection with the Relinquishing CUCS and point the antenna to the location
indicated in Message #34000.

Upon establishing a CDL connection with the UA, the Acquiring CUCS requests
LOI 4 Override Control of the UA per the procedure described in Section
A4.1.2.3.3.1, Requesting LOI Connection for VSMs, UA and Payload Stations.
A4 - 109
Edition A Version 1
AEP-84.1

The UA verifies the CUCS ID in Message #1 of the Acquiring CUCS matches
the ID received in Message #34000. If the ID does not match the expected ID
(from Message #34000 of the Relinquishing CUCS), the UA continues to wait
until the end of the timeout period for response from the proper CUCS.

If the IDs match, the UA transmits Message #35000, “Handover Successful" to
the Acquiring CUCS, indicating that the datalink and LOI connection has been
established and the Acquiring CUCS is in control of the UA.

If on the other hand, after waiting the Data Link Time-Out Limit “T1” the
handover does not succeed, the UA points its antenna back to the
Relinquishing CUCS and transmits the Handover Status Report (Message
#35000) with the Status set to “Handover Failed”.

If successful, the Acquiring CUCS can then continue with discovery of
payloads, configuration, etc.
A4.1.8.3 Payload Handover Using a Share Data Link
Handover of payloads where a data link transition is not required uses only the CUCS
Authorization Request Message #1 and the VSM Authorization Response Message
#2. Details of payload discovery and configuration are described in Section A4.1.2.3.1
of this Annex.
The CUCS attempting to acquire control over a specific payload first sends the CUCS
Authorization Request Message #1, setting the Requested/Handover LOI value to
0x04 = LOI 3, setting the Controlled Station and Component Number to the values of
the payload for which it is attempting to acquire control, setting Asset Mode value to 1
= Request and setting the Request/Handover Access value to 2 = Control & Monitor

Taking Control of an Available Payload: If the requested payload is
available for control by the requesting CUCS, the VSM/UA sends the VSM
Authorization Response Message #2, setting the CUCS ID to the requesting
CUCS, setting the LOI Granted value 0x02 = LOI 3, setting the Controlled
Station value to the value of the requested payload and setting the Access
Granted value to 2 = Control & Monitor.

Attempting Control of an Unavailable Payload: If the requested payload
is not available for control by the requesting CUCS, the VSM/UA sends the
VSM Authorization Response Message #2, setting the CUCS ID to the
requesting CUCS, setting the LOI Granted value 0x00 = N/A, setting the
Controlled Station and Component Number to the values of the requested
payload and setting the Access Granted value to 0 = N/A.

Acquiring Control of a Payload in use by Another CUCS: If the
requested payload is not available for control by the requesting CUCS
because it is in use by another CUCS, the acquiring CUCS may attempt to
override control and wrest the payload away from the CUCS currently in
control. If the currently controlling CUCS had sent the CUCS Authorization
Request Message #1 with the Asset Mode for the requested payload to a
value of 2 = Override, then the attempted override by the CUCS attempting
to wrest control from the currently controlling CUCS will fail and the Message
#2 from the prior paragraph, i.e. Access Granted value 0 – N/A, will be sent.
A4 - 110
Edition A Version 1
AEP-84.1
Otherwise, the acquiring CUCS sends the CUCS Authorization Request Message #1,
setting the Requested/Handover LOI value to 0x04 = LOI 3, setting the Controlled
Station and Component Number to the values of the payload for which it is attempting
to acquire control, and setting Asset Mode value to 2 = Override. The VSM/UA sends
two VSM Authorization Response Messages #2. The first message is sent to the
CUCS that has lost control of the payload setting the CUCS ID to the relinquishing
CUCS, setting the LOI Granted value to either 0x00 = N/A or 0x01 = LOI 2, setting the
Controlled Station value to the value of the requested payload and setting the Access
Granted value to 0 = N/A. The second message is sent to the CUCS that has taken
away control of the payload setting the CUCS ID to the acquiring CUCS, setting the
LOI Granted value 0x02 = LOI 3, setting the Controlled Station value to the value of
the requested payload and setting the Access Granted value to 2 = Control & Monitor.
A4.1.9 Virtual Vehicle Logic
In some implementations the CUCS needs to communicate with the VSM before the
VSM has established a link with a UA. This is typically so that the operator can perform
setup in the VSM and may also involve pre-downloading the Configuration Data for the
UA that the CUCS intends to control. For example, the VSM may provide a Remote
Display to allow the operator to indicate which payloads are installed on the UA or to
setup the data link parameters to communicate with the UA.
If the VSM does not know the Vehicle ID of the UA in advance, it can use a Logical
Vehicle ID in place of the Real Vehicle ID. A Logical Vehicle ID has a country code of
0 so a valid ID is in the range:
00:00:00:00 < Logical Vehicle ID <= 00:FF:FF:FF
When the VSM discovers the real UA it can use the Real Vehicle ID instead of the
Logical Vehicle ID. Before it switches to the new ID, however, the VSM needs to
notify the CUCS of the ID change by sending Message #3:
Unique
ID
Name
Value
Header
Source ID field
<Logical Vehicle ID>
…
…
…
0020.05
Vehicle ID Update
<Real Vehicle ID>
All future messages from the VSM will use the Real Vehicle ID instead of the Logical
Vehicle ID when referring to this UA. Note that this includes messages for any payload
stations or data links that were pre-configured with the Logical Vehicle ID.
It is highly recommended that VSMs use the acknowledgement system to ensure that
this message is received by each CUCS that has an LOI granted. If a CUCS does not
receive this message, it will likely continue to listen for messages addressed from the
Logical Vehicle ID instead of the Real Vehicle ID.
A4 - 111
Edition A Version 1
AEP-84.1
The Vehicle ID Update field (Unique ID 0020.05) should not be used to change a Real
Vehicle ID to another Real Vehicle ID. A VSM can change the Real Vehicle ID back
to a Logical Vehicle ID to indicate that the VSM is no longer configured to communicate
with the Real UA. The CUCS can use this event to prepare for communicating with a
new Real UA.
If a VSM supports multiple types of vehicles, it can report a Logical Vehicle ID for each
Vehicle Type/Subtype combination. If the VSM can only grant control for one of these
variations at a time, it can send a Message #2 for all other Logical Vehicle IDs with LOI
Authorized (Unique ID 0021.06) set to ”0x00= Not Authorised” when it grants LOI for
one Vehicle Type/Subtype.
To illustrate the use of a Virtual Vehicle, consider the following scenario:
Stage 1: Initial connection between CUCS and VSM without UA
Virtual UA
ID=0.0.0.1
Type=10
Subtype=1
VSM
CUCS
STANAG 4586 DLI
In Stage 1, the VSM has not established a link with a UA, but it can still provide the
discovery and configuration messages for a virtual vehicle by using the Logical Vehicle
ID in the appropriate messages. This approach can work if the VSM knows the
configuration of the vehicles it can control in advance.
A4 - 112
Edition A Version 1
AEP-84.1
VSM
CUCS
Message #1 Broadcast Request
Message #2 (VehicleID=0.0.0.1, Type=10, Subtype=1)
Message #40000 Download Configuration (VehicleID=0.0.0.1)
Message #4100x Configuration Messages (VehicleID=0.0.0.1)
Message #41005 Config Complete
(VehicleID=0.0.0.1, Type=10, Subtype=1)
Message #1 Request Control (VehicleID=0.0.0.1,
RequestedAccess=Control&Monitor, LOI=LOI5)
Message #2 (VehicleID=0.0.0.1,
AccessGranted=Control&Monitor, LOIGranted=LOI5)
The CUCS can establish LOI control of the VSM at this stage so that the VSM can
present its Remote Displays.
Stage 2: Data Link is manipulated to communicate with UA
Virtual UA
ID = 0.0.0.1
Type=10
Subtype=1
VSM
CUCS
STANAG 4586 DLI
Proprietary Data Link protocol*
In Stage 2 of this example, the VSM communicates with the data link in preparation for
communicating with a vehicle. This could be a result of operator interaction with the
VSM’s Remote Displays.
* Note that in this example the VSM communicates with a CDT using a proprietary
protocol (such as a command line or REST interface). There are other ways to
accomplish this such as using the Data Link DLI messages or private messages.
Stage 3: VSM Establishes Connection with Real UA
A4 - 113
Edition A Version 1
AEP-84.1
Real UA
ID=32.4.1.1
Type=10
Subtype=1
Tail=”TN039
”
VSM
CUCS
STANAG 4586 DLI
Proprietary UA protocol
In Stage 3, the VSM discovers which UA it is controlling and updates the CUCS with
the new Real Vehicle ID with Message #4000.
VSM
CUCS
UA
[Proprietary]
Establish
connection
Message #3
(VehicleID=0.0.0.1,
VehicleIDUpdate=32.4.1.1,
Type=10, Subtype=1,
Tail Number=”TN039”)
[Proprietary]
Send UA
Status
Message #4000 Inertial
States (VehicleID=32.4.1.1)
All future messages between the CUCS and the VSM regarding this UA should use
the new Vehicle ID.
VSM
CUCS
Message #2007 Unmanned Aircraft
Lights (VehicleID=32.4.1.1)
UA
[Proprietary]
Set the Light
[Proprietary]
Report Light
Status
Message #3006 Vehicle Lights
Report (VehicleID=32.4.1.1)
A4 - 114
Edition A Version 1
AEP-84.1
A4.2 Description and Implementation of DLI Messages
In the development of the STANAG 4586, the generic (common) messages have
been grouped and numbered according to their functionality. These groups of
messages are defined as Functional Groups. The currently defined Functional
Groups are as follows:
a. System ID
b. Flight Vehicle Command
c. Flight Vehicle Status
d. Flight Vehicle Payload Relevant
e. IFF Command
f. IFF Status
g. ATC Interface Command
h. ATC Interface Status
i. Vehicle Auxiliary Command
j. Vehicle Auxiliary Status
k. Mission Command and Status
l. Subsystem Status
m. Miscellaneous Messages
n. Payload Command
o. Payload Status
p. Weapons Command
q. Weapons Status
r. Data Link Discovery
s. Data Link Command
t. Data Link Status
u. Data Link Transition
v. General Pre-connection Configuration
w. General Post-connection Configuration
x. Autonomy
y. VSM Forced Commands
z. Draw Interface
aa. Private Messages
NOTE: Each DLI message contains ID fields that identify the sender and the receiver
of a message. These IDs are contained in the header in the Source ID and Destination
ID fields. The Source ID must always be set to the ID of the entity that is sending the
message. It cannot be set to the Null ID or the Broadcast ID. The Destination ID should
be set to:



the ID of the entity that is intended to receive the message, or
the Broadcast ID (0xFFFFFFFF) which can be used when the sender may not
know the destination’s ID or a message may be intended for multiple recipients.
For instance, when a CUCS is broadcasting its presence to any UA, it doesn’t
know the Vehicle ID in advance.
Note that all entity IDs must be unique to enable interoperability
NOTE: Presence Vector (PV). The first bit (bit 0) of each AEP-84 Volume II message
is a “Bitmapped” field indicating which fields in the remainder of the message are
present in that message. Each bit represents a specific field, and possibly a set of
fields which are dependent on that field. A “1” in a given bit location indicates that the
field, and the set of dependent fields, is present, and a “0” indicates that the field, and
A4 - 115
Edition A Version 1
AEP-84.1
optional set of dependent fields, is absent. The least significant bit indicates the
presence of the time stamp (field 1); the next more significant bit indicates the presence
of the second field, etc.
For example, a message containing ten independent fields would have a two-byte
Presence Vector. For messages that contain repeated fields, the repeated fields and
the repeat count field, are mapped to a single bit. Conditional fields and fields that
determine the presence of the conditional fields are all mapped to the same Presence
Vector bit. And if a field length is variable, based on the value of another field, both
fields would share the same Presence Vector bit. See section A4, Presence Vector,
for specific examples of the use of the Presence Vector bit in DLI messages.
Note: For Messages not listed in the following sections, AEP-84 Volume II standard
should be used for Implementation Guidance.
A4.2.1 System Identification Messages
A4.2.1.1 Message #1: CUCS Autorisation Request CUCS Implementation
This message is used by a CUCS to request a connection to a VSM for a specific
vehicle ID, at a specific LOI, or it is used by a CUCS to make a general inquiry on the
network to which it is attached to determine what VSMs are attached to the network,
and what are the capabilities of these VSMs. This message is also used to release
control or override control of a specific vehicle ID by the CUCS. Therefore, this
message has a few distinct usages. The response to this message is from a VSM
using Message #2, VSM Authorization Response.
The VSM should populate the CUCS ID field of the formatted DLI message response
(Message #2) with the CUCS ID as received from the CUCS in the CUCS Authorisation
Request (Message #1). When a VSM authorizes control to a CUCS for the air vehicle/
payload, it should be based on the CUCS ID contained in the CUCS Authorization
Request message. Once a CUCS has control of an air vehicle/ payload, the VSM
thereafter filters all control messages for that functionality based on the authorized
CUCS ID, and addresses all the required status messages to that CUCS ID.
For vehicle or payload control requests, this message is sent by a CUCS to a VSM to
request a connection to the VSM, for a specific vehicle ID, at a specific (requested)
LOI, for a specific vehicle type and subtype, potentially for a specific payload station
(dependent on LOI), the Vehicle ID and all other fields in the message are correctly
filled. If more than one payload station authorisation is needed, this message may be
used to identify all the stations. Where a CUCS does not receive authorization to
control an air vehicle or payload at a specific LOI, the CUCS is not to transmit
“command” messages to a vehicle ID for that functionality.
When the CUCS is using this message to make a general inquiry for VSMs attached
to the network and their capabilities, the Asset Mode field set to 3 = Broadcast Request.
The other fields in this message can be set to create a filter for specific functionality,
or the Requested LOI field can be set to “Unspecified” and therefore signify that all
other fields are invalid.
The vehicle type and subtype fields are used to allow the CUCS to filter a broadcast to
request control of a particular vehicle type/subtype where there is more than one VSM
on the network to which the CUCS is attached, or a particular VSM supports more than
one vehicle type/ subtype.
This message is designed to allow more than one CUCS to control UA and payload
functions from a single logical VSM.
A4 - 116
Edition A Version 1
AEP-84.1
A CUCS controlling an UA at LOI 4 or 5 will maintain UA control until either it
relinquishes control, or is displaced by another CUCS that is asserting override while
the current CUCS is not.
A CUCS controlling a payload at LOI 3 will maintain payload control until it either loses
the connection, specifically relinquishes control, or when the CUCS that has LOI 4 or
5 of the vehicle on which the payload(s) are located specifically requests control of that
payload. The UA operator is considered to be responsible for the vehicle, therefore
they may remove control from an independent payload operator.
This message is used in conjunction with the Data Link Transition Coordination
Message (Message #34000) for a handover of an UA without handing over control of
the VSM to another CUCS (e.g., passing control of an UA from one VSM to another).
This message provides the authorisation for the handover of the UA, and identifies to
the UA whether or not it must wait for the Data Link Transition Coordination message
before performing the transition.
Refer to Section A4.1.2 CUCS VSM Connection Sequence for additional
implementation details of the CUCS Authorization Request message.
Note: Currently the CUCS Authorization Request message does not provide the
capability to identify the Payload type at the specified station during discovery.
Currently a separate request for Message #21001, Payload Configuration, is required
to be made to determine the payload type located at the reported station number.
A4.2.1.2 Message #1: CUCS Autorisation Request VSM Implementation
This message is received at the VSM as sent by a CUCS to request a connection,
release connection, or override connection to the VSM for a specific vehicle ID at a
requested LOI (air vehicle/ payload), for a specific vehicle type and subtype
The VSM must correctly interpret the contents of the CUCS Authorization Request
Message as received from the CUCS, and respond with a Message #2, VSM
Authorization Response, corresponding to the request, either authorizing control for
the requested functionality, releasing control of the selected functionality, or allowing
an override of the selected functionality. Where the request was a Broadcast request,
the VSM responds with its capabilities, but does not authorize control over any of its
functionality.
A4.2.1.3 Message #3: Vehicle ID CUCS Implementation
This Vehicle ID message identifies specific details of the UA identified by the Vehicle
ID parameter contained in the message. Some of these parameters are duplicated
from other messages in order to provide this information in a comprehensive vehicle
identification message.
The STANAG 4586 allows the CUCS to request configuration messages from the
VSM/ air vehicle in advance of requesting an LOI from the VSM, and this is one of the
possible configuration messages that may be requested. However where a vehicle is
not connected to the VSM/ system, this message does not provide any useful
information above that contained in Message #2, VSM Authorization Response
Message.
It is recommended that these data elements be available for display to the operator in
a System Administration/Configuration dialog on the CUCS, for vehicles that the CUCS
is either monitoring or controlling. Data elements of the configuration type are
recommended to be grouped.
A4.2.1.4 Message #3: Vehicle ID VSM Implementation
A4 - 117
Edition A Version 1
AEP-84.1
The Vehicle ID Message is created by the VSM/ air vehicle, and more comprehensively
identifies the UA that is controlled through the VSM. This message is only sent from
the VSM to the CUCS when requested by the CUCS for the specified vehicle ID, or in
response to a general configuration request made for a specific vehicle ID, for the air
vehicle in particular. The VSM is developed for a specific vehicle type and subtype;
therefore these are specified by the VSM developer. Thus, certain data elements
within this message should not be operator configurable. These data elements are:


Vehicle Type
Vehicle Subtype
The CUCS ID is a field located in the header of all of the STANAG 4586 formatted DLI
messages whose source is a CUCS where the message originated, and in this case
identifies the CUCS to respond, which has specifically requested the message from
the UA/VSM using a Message #17002 request, or making a general configuration
request from the VSM using Message #40000, Field Configuration, at the appropriate
LOI.
Other data elements contained in the Vehicle ID Message are dependent on the
specific UA, and they may vary by mission. These data elements include:





Vehicle ID
Owning Country ID
Tail Number
Mission ID
ATC Call Sign
These data elements may be potentially operator enterable on the VSM through the
remote display capability. The Mission ID is set from a CUCS for a mission upload,
and is transmitted to the VSM using Message #13000, Mission Transfer Command.
The Mission ID identified in this message will report the Mission ID loaded on the UA,
and will reflect the uploaded Mission ID if an upload occurred from the same CUCS.
This message may be requested by the CUCS to get a confirmation that Mission ID
was uploaded correctly to the VSM/ air vehicle.
When the Vehicle ID Message is requested by the CUCS, all data elements within the
message should be appropriately populated and the message sent as expeditiously
as possible from the VSM.
As specified in the Section 3.4.1.2, Software Interface, when the VSM “message
translation functionality” is located on the ground, it is recommended that the vehicle
IDs are used as the VSM IDs. An air vehicle currently is assigned a “tail number” and
the place where the tail number is going to be mapped to the vehicle ID is in the VSM.
This message reports the “tail number” that has been associated with a specific vehicle
ID when an air vehicle is attached/ connected to the system. Where a VSM is capable
of controlling more than one “tail number” simultaneously, the VSM should be assigned
the number of vehicle IDs corresponding to the number of vehicles that the VSM can
control simultaneously, with one “tail number” being assigned to one vehicle ID.
A4.2.1.5 Message #2: VSM Autorisation Response CUCS Implementation
The VSM Authorisation Response message is received at the CUCS as sent by the
VSM in response to Message #1, CUCS Authorisation Request Message. If the
request (enquiry) from the CUCS was a broadcast or for an unspecified LOI, the VSM
will respond with the available vehicle ID(s), vehicle type/ subtype information,
A4 - 118
Edition A Version 1
AEP-84.1
available payload stations, and the LOI that are authorised for the inquiring CUCS.
The response provides the CUCS with “information” on the capabilities of the VSM.
The LOI Authorized field identifies the maximum LOI that could be granted to the
CUCS. The LOI Authorized response does not pass control of the VSM to the CUCS.
The LOI Granted field will be filled with “N/A” for a Broadcast response. If the LOI
Granted field is filled otherwise, the CUCS is thereafter in control of the VSM at the
granted LOI for the controlled station identified in the message. If the LOI is for LOI 3,
LOI 4, or LOI 5, where the CUCS is not correctly configured for control, the operator
should receive a warning and immediately release control.
If the CUCS requested a specific LOI in the Authorisation Request message, it should
be granted control from the VSM over the specified functionality in this message unless
the CUCS is not authorized for control. Note that there currently is no capability in the
STANAG 4586 to identify CUCS IDs that are or are not authorized to control a specific
VSM. Once the CUCS has received a “control” authorization (LOI 3/4/5) for an air
vehicle and/ or payload, it is authorized to transmit LOI 3/4 command messages to the
specific vehicle ID.
The CUCS may receive this message when it is intended for another CUCS to monitor
the control status of the entire UA system/network, where other CUCSs may be in
control of portions of the system. This allows all CUCSs connected to the VSM/ system
of which CUCS(s) is in control of the different components of the UA, the vehicle itself
and/or its payload(s).
The CUCS may also receive this message to inform the CUCS that it is no longer in
control of a specified functionality, where another CUCS has overridden control of the
specified station.
A4.2.1.6 Message #2: VSM Autorisation Response VSM Implementation
The VSM Authorisation Response message is sent by the VSM in response to
Message #1, CUCS Authorisation Request message, received from a CUCS. If the
request (enquiry) from the CUCS was a broadcast or for an unspecified LOI, and the
CUCS ID received in the message is for an authorized CUCS, the VSM responds with
the specific vehicle ID(s), to include vehicle type/ subtype information, and the LOI(s)
that are authorised for the enquiring CUCS.
The LOI Authorized field is used by the VSM to identify the maximum LOI that could
be granted to the enquiring CUCS. The LOI Authorized response does not pass
control of the VSM to the CUCS. This differs from the LOI Granted field in that when
the VSM reports the LOI Granted to the CUCS, the CUCS is there after considered to
be in control of the VSM at the granted LOI for either the UA and/or controlled station
identified in the message. The VSM Authorization Response message should never
contain anything other than “LOI Granted = 0x00 N/A” in response to a broadcast
request from a CUCS with either the vehicle ID parameter (in the Message Header)
containing the broadcast vehicle ID or the “Requested LOI” parameter set as “0x00 =
Unspecified.” Once the CUCS has been granted control of VSM functionality, the
VSM transmits the required status messages to the CUCS (CUCS ID) and accepts the
commands for the specified LOI from that CUCS.
If the CUCS requested a specific LOI in the CUCS Authorisation Request message for
a specific vehicle ID, it is requesting the granting of control from the VSM over the
specified functionality. Therefore, the VSM must respond with the granted LOI, unless
that functionality is already being controlled by another CUCS and the request is not
an override. Note, that STANAG 4586 does not specifically support a VSM identifying
(reporting) control over of an air vehicle component by one CUCS to another CUCS.
A4 - 119
Edition A Version 1
AEP-84.1
All CUCSs must monitor all VSM Authorization Response messages on the network if
they want to build a picture of the network and the current state of vehicle payload
control on that network. It is an implementation detail whether a VSM identifies an air
vehicle functionality as not authorized when being controlled by another CUCS (does
not report the functionality in the VSM Authorization Response message, therefore
defeating the override capability), or shows it as authorized and then when requested
not allow control unless the request is an override over the current CUCS.
The VSM should also transmit this message to a CUCS to inform the CUCS that it is
no longer in control of the specified functionality, through the “Relinquish Control”
setting. This occurs in situations where one CUCS has overridden control of the
specified station from another CUCS, or a CUCS has released control of the specified
functionality.
A VSM on the ground may not be connected to an UA when it receives a CUCS
Authorization Request. In this situation the VSM transmits a VSM Authorization
Response Message for each of its logical VSMs, with each logical VSM identified by
an associated vehicle ID, Vehicle Type and Vehicle Subtype. One message is sent
for each Vehicle Type/Subtype (vehicle ID) for which the VSM is capable of controlling.
When the VSM is on the ground, the CUCS is in essence controlling the VSM.
Once the CUCS has control over a “logical” VSM, the reception of Message #3, Vehicle
ID, will verify the absence of a vehicle connected to the system with the Tail Number
parameter being reported as “zero”.
Refer to Section A.4.1.2 CUCS VSM Connection Sequence for additional
implementation details of the CUCS authorization Request message.
A4.2.1.7 Message #4, Positive Handover Authorisation Request & Message #5,
Positive Handover Authorisation Granted
These two messages, one from the acquiring CUCS to the relinquishing CUCS via the
AV to indicate that a gaining CUCS is requesting authorisation for full or partial control
of the AV/payload, and the second message from the relinquishing CUCS to the
acquiring CUCS via the AV to indicate the requested functions that are authorised for
the acquiring CUCS and be used to implement a positive handover. The suggested
flow is listed below:
The acquiring CUCS requests authorisation for partial or complete control of the
AV/payload using message #4.
The AV, if it supported this type of handover would send message #4 to the
relinquishing CUCS indicating the functions that are being requested.
If the relinquishing CUCS supports this message it could either use a preloaded table
and or operator input to determine what, if any functions would be transferred. It would
then send a message #5, Positive Handover Authorisation Granted message to the
AV, which would send the message to the acquiring CUCS.
At this point the handover occurs when the acquiring CUCS uses message # 1 to
request control. If the acquiring CUCS requests modes that were not authorised the
AV will ignore the requested transfer and send a "Nak" to the acquiring CUCS. In the
case where all control of an AV or payload is requested by the acquiring CUCS, then
the relinquishing CUCS ceases to have authority for those modes, i.e. a complete
transfer of authorisation.
A4 - 120
Edition A Version 1
AEP-84.1
Non-Sunny day Cases
All STANAG 4586 message headers contain the version number of the standard. The
version number can be used to verify if the CUCS/VSM was implemented before the
positive handover was accepted into the standard.
The sunny day case assumed that all three components, Relinquishing CUCS,
Acquiring CUCS and AV implemented the positive handover messages. Below are a
series of non-Sunny day cases:




In the case were the acquiring CUCS does not support positive handover (i.e.
previous version), the AV would know this based on the version in the message
header and would not send the new messages to both CUCS when a message
#1 was received.
In the case where the AV implemented a previous version, the acquiring and
relinquishing CUCS would know that from the version number and would not
assume a positive handover was possible.
In the case where the AV did implement a current version, but chose to not
implement the positive handover messages, during discovery by the CUCS it
would disable the new uplink message from the CUCS, thus signifying that it
did not support this function. If a new enumeration was added to message 1 as
suggested, then the CUCS would send a "Nak" when a positive transfer was
requested.
In the case where the relinquishing CUCS does not support positive handover,
the AV would know this based on the version number in the wrapper. If the
suggested enumeration was not added to message #1, the AV would assume
the Relinquishing CUCS request was a non-positive handover and the
acquiring CUCS would have to assume after no response, that the relinquishing
CUCS did not support positive handover. If the new enumeration was added,
then the AV would send a "Nak" in response to a positive handover request.
A4.2.2 Flight Vehicle Command and Status Messages
Implementation guidance for messages in this functional group is provided in section
A4.1.5 of this Annex and AEP-84 Volume II, Section 4.3 Flight Vehicle Command
Messages.
A4.2.3 Payload Command and Status Messages
The Payload Command Messages table have been developed with the intention of
separating the message according to the payload type being addressed. The Payload
Command messages should not be sent between a CUCS and VSM without an
authorized connection for the specified “Payload Type”.
Payload Command and Status Messages are identified in AEP-84 Volume II, Sections
4.1.1.14 and 4.1.1.15 respectively. The implementation guidance for the messages
comprising this functional group is addressed in section A4.1.6 of this Annex and AEP84 Volume II, Sections 4.15 and 4.16 respectively.
A4.2.4 Data Link Command and Status Messages
A4 - 121
Edition A Version 1
AEP-84.1
The Data Link Command and Status Messages have been developed with the
intention of separating the communication equipment functionality from the pedestal
functionality. This division is intended to allow the potential replacement of either the
radio equipment or a pedestal within a system.
The Data Link Discovery Messages are identified in AEP-84 Volume II, section 4.1.18;
the Data Link Command messages are identified in AEP-84 Volume II, Section 4.1.19;
the Data Link Status messages in Section 4.1.20 and the Data Link Transition
messages in Section 1.1.21, respectively.
The following messages are considered pedestal configuration, control, and status
messages:
 Antenna Pedestal Location Command (Message #30100))
 Antenna Control Command (Message #30101)
 Antenna Position Command (Message #30102)
 Antenna Pedestal Location Status Report (Message #32100)
 Antenna Control Status Report (Message #32101)
 Antenna Position Report (Message #32102)
 Legacy Pedestal Status Report (Message #32103)
Selected Messages contain a VDT/CDT flag to specifically identify to which data link
terminal the message refers.
The Implementation Guidance for the Data Link related messages is provided in the
following sections and in AEP-84 Volume II, Sections 4.19, 4.20, 4.21, and 4.22
respectively.
A4.2.4.1 Message #30001: 7085 Data Link Active Configuration Set-Up
Message
The Data Link Set-up Message is transmitted from the CUCS to the VSM, referenced
to a specified Data link ID, and it is used to set the parameters required for the
operation of a STANAG 7085 compliant Common Data Link (CDL) data link. The
message provides the capability to set-up both the VDT and CDT parameters from the
CUCS independently. The parameters in the message are generic, however each
data field must be configured for the specified link. The configuration of the message
VSM Specific contents (Data Link Type field) is achieved through the use of the general
configuration messages.
Vehicle Data Link Transition Coordination Message (Message #34000), contains some
of the same set-up parameters as this message for the VDT terminal, and is used to
change the VDT parameters for a transfer in control of an UA from one UCS to another.
Message 30001 is not used for transitions in UA control.
The Addressed Terminal field provides the capability to set-up up the CDT from the
CUCS, and in the cases where a VDT defaults to a known configuration, the VDT
configuration may be modified from the CUCS.
The CDL data link requires a PN Code and Frequency code to operate. While the
codes are not considered classified, the broadcast of these codes in an unencrypted
manner could result in a compromise to the operational security of the system and
possibly other systems using CDL based data links. If an UA contains another link(s)
in addition to the CDL link, it should not send the CDL codes unless all data links are
encrypted.
A4 - 122
Edition A Version 1
AEP-84.1
The VSM reports whether or not it supports the parameters identified in the message
using General Configuration Messages #41000 and #41001. Where a VSM reports it
does not support a parameter, it is expected the CUCS will not provide control of the
parameter to the operator. The General Configuration Messages are also used to
provide control and display limits for the message parameters.
A4.2.4.2
Message #30003: Data Link Control Command Implementation
The Data Link Control Command Message is used by the CUCS to send commands
to components of the data link communications equipment. The message provides
the capability to set the state (mode) of the data link, select the antenna type, and
zeroes the communication security equipment if required. The message provides the
capability to command the VDT independent of the CDT.
Some of the parameters within the messages may not be applicable to both the CDT
and VDT terminals within a system.
The Data Link Status Messages (Message #32000 - 32006) provide the status of the
selected data links with respect to the commanded parameters.
The Configuration Messages are used by the VSM to identify to the CUCS whether or
not entire fields within the message, or specific states within fields, are supported by
the VSM. The CUCS is then expected to use this configuration information to adjust
its displays accordingly.
A4.2.4.3
Message #30100: Antenna Pedestal Location Command Message
The Pedestal Location Command Message is transmitted from the CUCS to the
VSM/CDT Data Link. This message provides the capability to enter the location of the
CDT Antenna at the CUCS and transmit this information to the CDT.
A4.2.4.4
Message #30101: Antenna Control Command
The azimuth and elevation offsets are sent from the CUCS to the VSM/ Pedestal in
Message #30101, Set Azimuth Offset, and Message #30101, Set Elevation Offset.
The Azimuth Offset value is defined as the difference between the antenna azimuth
relative to pedestal 0 and the antenna bearing relative to true north. The Offset value
is reported as positive if the pedestal report needs to be adjusted in the clockwise
direction and will be reported as negative if the pedestal report needs to be adjusted
in the counter-clockwise direction.
Figure A4 - 8: Azimuth Offset
A4 - 123
Edition A Version 1
AEP-84.1
The Elevation Offset value is defined as the difference between the antenna elevation
relative to pedestal 0 and the antenna elevation relative to horizontal, and will be
reported as positive if the elevation needs to be corrected upwards.
As an example, if the antenna is reporting a 110 deg azimuth relative to pedestal 0,
and it is actually pointing 50 deg relative to true north, then the azimuth offset is minus
60 degrees.
It is expected that the pedestal will take the offset values as commanded in Message
#30101 and add it to the pedestal antenna azimuth relative to pedestal 0 at all times,
and report this value as the pedestal azimuth in Message #503, Reported Antenna
Azimuth, to the CUCS.
Suppose the operator starts up with the azimuth offset at 0, the antenna is pointing at
110 relative to pedestal 0 and 50 degrees relative to north. The CUCS will set the
azimuth offset to the operator entered bearing (50 degrees) minus the reported
azimuth (130), i.e. to minus 60. The VSM/ Data link always adds the Azimuth Offset
to the pedestal antenna azimuth relative to the pedestal 0 value before reporting it to
the CUCS via Message #32100, Antenna Pedestal Location Status Report.
A4.2.4.5 Message #28000: Data Link Control Authorization Request
Implementation
This message is used by a CUCS to request control over a CDT/VDT for which a VSM
has reported available for control through Message #28001, Data Link
Configuration/Assignment Message.
A4.2.4.6 Message #28001: Data Link Configuration/Assignment Message
Implementation
The Data Link Configuration/Assignment Message is used by the VSM to identify the
data link configuration of the CDTs/VDTs associated with a VSM. The intent of this
message is to provide the CUCS with the data link configuration on initial connection,
with one instance of this message sent for each employed data link.
Where a specific vehicle is not associated with the CDT the null vehicle ID is
transmitted with the supported Vehicle Type and Vehicle Subtype identified in the
message. Where a VSM supports more than one Vehicle Type and Vehicle Subtype
for a single CDT (resource sharing), each instance of support is reported to the CUCS
with the same data link ID. Where a STANAG 7085 data link is shared between two or
more VSMs, the VSM/CDT Status is the responsibility of the VSMs.
This message is used by the VSM to grant a CUCS control over a specific data link ID,
report the data link ID as unavailable, or to report the successful release/ availability of
a data link ID. For each reported data link ID/Vehicle Type/Vehicle Subtype
combination, the VSM reports the controllability of the data link in the “Data Link
Control Availability” field. An example response could be as follows based on the
configuration of Figure A4 - 9.
A4 - 124
Edition A Version 1
AEP-84.1
STANAG DLI
VSM A:
AV_1
AV_2
VDT
CUCS
VSM B:
AV_3
Vehicle Protocol w/
VDT Protocol
Figure A4 - 9: Example of a VSM Response
VSM A: Message #28001: Instance 1: Data Link ID: 123.123.123.123; Vehicle Type:
AV_1; Subtype 1
VSM A: Message #28001: Instance 2: Data Link ID: 123.123.123.123; Vehicle Type:
AV_2; Subtype 1
VSM B: Message #28001: Instance 1: Data Link ID: 123.123.123.123; Vehicle Type:
AV_3; Subtype 2
For each reported Data Link ID/Vehicle Type/Vehicle Subtype combination, as above,
the VSM reports the controllability of the data link in the “Data Link Control Availability”
field of Message #28001 during CUCS configuration.
VSM A: Message #28001: Instance 1: Data Link ID: 123.123.123.123; Vehicle Type:
AV_1; Subtype 1: Available
VSM A: Message #28001: Instance 2: Data Link ID: 123.123.123.123; Vehicle Type:
AV_2; Subtype 1: Available
VSM B: Message #28001: Instance 1: Data Link ID: 123.123.123.123; Vehicle Type:
AV_3; Subtype 2: Available
Any subsequent changes in the “Data Link Control Availability” will be updated from
the VSM using Message #28001. For example if the CUCS in Figure A4 - 9 requests
control of the CDT for VSM A: AV_1 using Message #28000, Data Link Control
Authorization Request, and the VSMs are not capable of concurrently sharing the CDT
resource, the VSMs would report the CDT as being unavailable for the other two
vehicles, and grant control to the CUCS for the AV_1 vehicle.
VSM A: Message #28001: Instance 1: Data Link ID: 123.123.123.123; Vehicle Type:
AV_1; Subtype 1: Req. Granted
VSM A: Message #28001: Instance 2: Data Link ID: 123.123.123.123; Vehicle Type:
AV_2; Subtype 1: Unavailable
VSM B: Message #28001: Instance 1: Data Link ID: 123.123.123.123; Vehicle Type:
AV_3; Subtype 2: Unavailable
This message also identifies the data link type and the system antenna configuration.
The Terminal Type field is specifically used to identify the Antenna Type(s) available
for each of the CDT(s) and the VDT(s) of the identified data links. Figure A4 - 10
depicts another potential VSM/data link configuration, where AV1 is available for
connection, however CDT3 does not have a vehicle associated with it.
A4 - 125
Edition A Version 1
AEP-84.1
Figure A4 - 10: Data Link Configuration
In this configuration, the data links would most likely be reported as follows:
VSM A: Message #28001: Instance 1: Vehicle ID: 1; Data Link ID: 1; Vehicle Type:
AV1; Subtype 1: Available
VSM A: Message #28001: Instance 2: Vehicle ID: 1; Data Link ID: 2; Vehicle Type:
AV1; Subtype 1: Available
VSM A: Message #28001: Instance 3: Vehicle ID: FF.0.0.0; Data Link ID: 3; Vehicle
Type: AV1; Subtype 2: Available
Figure A4 - 11 depicts another potential CUCS/VSM/CDT configuration.
CUCS A
CUCS B
VSM
CUCS
CUCS C
Figure A4 - 11: Potential CUCS/VSM/CDT Configuration
In this configuration, CUCS A may request control of the CDT and then request LOI 4
(UA control). Note that UA and Payload control are requested and granted using
Messages #1 and #2 respectively. Control of the CDT would be unavailable to CUCS
B, but CUCS B would be able to request LOI 3 (Payload control) on the UA controlled
by CUCS A using the same data link. In this situation, if CUCS A releases control of
the UA, the VSM could pass control of the CDT to CUCS B. If CUCS C then requests
control of the UA, the VSM may pass control of the CDT to CUCS C or leave it with
CUCS B. There are many combinations of CUCS/VSM/CDTs, therefore the VSM must
A4 - 126
Edition A Version 1
AEP-84.1
use Message #28001, Data Link Configuration/Assignment Message as required to
correctly assign CDT control to a CUCS.
A4.2.4.7
Message #32005: Legacy Data Link Status Report Implementation
The Legacy Data Link Status Report is used by the VSM to transmit the status of the
data link to the CUCS, for both the CDT and VDT communication equipment. The
message is used to report the state of the communications equipment, the antenna
being used, and the communication parameters. The message also provides a report
of the Downlink quality (status) as reported by the data link equipment, and reports on
the presence of communications security equipment and its status. The Downlink
Status field report is based on a vehicle specific determination of the quality of the link
being used by the system, where the VSM manufacturer determines how the downlink
quality is calculated. The calculation may be based on Bit Error rates, AGC, other
system parameters, or any combination thereof.
The Legacy Data Link Status Report Message reports on the parameters initialised
using the Data Link Control Command Message (Message #30003) and reports the
state of parameters commanded from the Data Link Control Command (Message
#402).
A4.2.4.8 Message #32003: Data Link Control Command Status
Implementation
This message is to support backwards compatibility to AEP-84 Volume I.The Data Link
Control Command Status Message is sent from the VSM to the CUCS, and provides
a report of the status of the commanded data link parameters. The message verifies
that the commanded data link values were correctly received at the VSM/CDT data
link, as commanded by the Data Link Control Command (Message #401 of AEP 84
Volume I). The VSM must configure the parameters in this message the same as
those in AEP-84 Volume I, Message #401, Data Link Control Command.
A4.2.4.9
Message #32100: Antenna Pedestal Location Status Report
The Pedestal Location Status Report Message is transmitted from the VSM/CDT to
the CUCS to report the current status of antenna pedestal location. The message is
used to report the antenna pointing angle, antenna rates, and the antenna location.
The associated pedestal commands are contained in the Antenna Pedestal Location
Command, Message #30100.
A4.2.4.10 Message #30301: IP Address and Port Assignment Request
This message shall be sent by the CUCS to a CDT or UA to request a change in the
IP address and/or port used by the CDT or UA. If the receiving CDT or UA accepts the
requested change, it will update Message #32301 with the new configuration.
A4.2.4.11 Message #32301: UA IP Disclosure Message
This message provides a method for a CUCS to determine the IP address and IP port
used to transmit information to/from the AV. While most of the items defines are data
streams on the downlink, there are a few that also define the IP address/port the AV
expects to receive data, e.g. ATC Uplink Audio. This message also defines the
multicast IP address used for the DLI messages to both the AV and Data Link. If this
message is sent on a universal IP Address/port, then each AV and Data link can have
its own multicast address/port for the remaining DLI messages.
A4 - 127
Edition A Version 1
AEP-84.1
The UA IP Disclosure Message allows the VSM to specify a URI for a payload product
location. A URI provides the flexibility necessary to describe how to connect to
different payload products.
NOTE:
“[…] a Uniform Resource Identifier (URI) is a string of characters used to identify a
name or a resource on the Internet. Such identification enables interaction with
representations of the resource over a network (typically the World Wide Web) using
specific protocols. Schemes specifying a concrete syntax and associated protocols
define each URI.”
Sample URIs:
http://example.org/absolute/URI/with/absolute/path/to/resource.txt
ftp://example.org/resource.txt
mailto:John.Doe@example.com
rtsp://example.org:1234/media/resource.mov
Note: Refer to AEP-84 Volume II for the implementation requirements for the
messages not addressed above.
A4.2.5 Data Link Transition Messages
The Data Link Transition Messages are used to provide the capability for a coordinated
transition in control of an UA from one physical CDT to another. These messages are
used in conjunction with the CUCS Authorisation Request (Message #1) and the VSM
Authorisation Response (Message #2) messages. The Vehicle Data Link Transition
Coordination Message (Message #34000) and the Handover Status Report Message
(Message #35000) are used to conduct the physical transfer and report its status, while
the Authorisation Messages are used to transfer authority from one CUCS to another.
A description of potential handover/transition sequences are provided in the Handover
Sequence section of this document. Refer to that section of the document for message
sequencing.
Note: The Data Link Command and Status Messages provide some capability for a
transition in control, however they are not intended for this purpose.
A4.2.5.1 Message #34000: Vehicle Data Link Transition Coordination Message
Implementation
The Vehicle Data Link Transition Coordination Message is used to initiate the transition
of control over an UA from one UCS data link to another UCS data link. The UCS in
control of the UA transmits this message identifying which VDT will be transferred and
identifies the CUCS ID or the null ID that control of the VDT data link is to be
transferred. The message also provides the geographical location of the acquiring
CDT for the purpose of directional link transfers, and the communication parameters
required to successfully complete the transfer.
The transfer of control is initiated with the transmission of the Vehicle Data Link
Transition Coordination Message once authorisation for the transfer has been
authorized through the transmission of a CUCS Authorisation Request Message.
A4 - 128
Edition A Version 1
AEP-84.1
The authorisation for the LOI and the specific UA functionality to be controlled is
conducted through the use of the CUCS Authorisation Request Message and the VSM
Authorisation Response Message.
A4.2.5.2 Message #35000: Handover Status Report Implementation
The Handover Status Report message may be used to report the status of a transition
in the VDT data link control from one controlling UCS to another, as a result of a Vehicle
Data Link Transition Coordination message. The relinquishing VSM would send the
appropriate “status” of the transfer to the relinquishing CUCS based on the available
status from the relinquishing CDT.
A4.2.6 Mission Messages
The following list of messages are the messages that have been developed to transfer
a mission plan from a CUCS to an UA through the DLI, and to download the mission(s)
that are currently loaded on the UA :














Mission Upload Command (Message #13000)
UA Route (Message #13001)
Mission (VSM) Upload/Download Status (Message #14000)
UA Position Waypoint (Message #13002)
UA Loiter Waypoint (Message #13003)
Payload Action Waypoint (Message #13004)
Airframe Action Waypoint (Message #13005)
Vehicle Specific Waypoint (Message #13006)
Define Contingency (Message #13007)
IFF/SSR Action Waypoint (Message #13008)
Data Recorder Action Waypoint (Message #13009)
VSM Flight Data Record Stream (Message #13010)
Playback Control Command (Message #13011)
Mission Upload/Download Status (Message 14000)
The implementation of these messages is addressed in section A4.1.3 of this Annex
and AEP-84 Volume II, Section 4.12 respectively.
A4.2.7 Subsystem Status Messages
The following messages provide health and status overview information in an
interoperable context.
A4.2.7.1 Message #15000: Subsystem Status Request Implementation
This message is sourced at the CUCS, and is used by the CUCS to request subsystem
status from the VSM for all subsystems identified in the message. The CUCS should
request this message automatically at a specified rate providing the operator with a
near-real-time display of the subsystems status. The request rate should be
configurable to account for differences in vehicle systems.
When the VSM receives this message from the CUCS, the VSM sends the Subsystem
Status Report (Message #16001) for the subsystem identified in the received
message.
A4 - 129
Edition A Version 1
AEP-84.1
A4.2.7.2 Message #15001: Subsystem Status Detail Request CUCS
Implementation
This message is sourced by the CUCS as a request for additional information from a
received Subsystem Status Alert Message (Message #16000) or from a Subsystem
Status Report Message (Message #16001). Refer to Message #16000, and /#16001
implementations for additional information.
The Warning Display System on the CUCS should provide a method to request
additional information for a Received Warning Message (Message #16000) if available
at the VSM. The CUCS request creates this message with the same Subsystem State
Report Reference as received in Message #16000.
The CUCS should provide the operator with the capability to request additional
information on a Subsystem Status Report (Message #16001), in a manner similar to
Message #16000, and the VSM provides the required information to the CUCS upon
receipt of the Subsystem State Report reference. Again this may be through the use
of a pop up dialog.
A4.2.7.3 Message #15001: Subsystem Status Detail Request VSM
Implementation
Upon the receipt of Message #15001, the VSM provides the information to the CUCS
related to the specified warning. This may be through the use of a pop up window or
dialog on the CUCS display. In a cylinder head temperature example, a suitable
response from the VSM to a request for details would be to present an engine
parameters window showing additional engine parameters, not just a cylinder head
temperature gauge. This could include (at the discretion of the VSM implementer) a
recommendation for an action (e.g., in this case the recommendation might be to slow
down or reduce the climb rate).
A4.2.7.4 Message #16000: Subsystem Status Alert Message Implementation
This message is sourced at the VSM. It is recommended that this message be
implemented, in conjunction with Message #15001, as a warning detection and display
system between the CUCS and VSM.
The warning system is capable of displaying warnings based on a priority level in the
priority level field. There should be the ability to display 6 warning levels, with zero
being the lowest level. The warnings are displayed in a warning display system with
the highest priority warning displayed at the top, and then the warnings are displayed
in descending order of priority. It is recommended that the most recent warnings be
placed at the top of each priority level within the warning display. It is recommended
that warnings at one priority level be distinguishable from warnings at another priority
level, such as through the use of colour coded warnings.
The warning system is able to accept a Subsystem state report reference associated
with a specific warning. The report reference is a vehicle specific reference provided
by the VSM, which the CUCS can use to request additional information from the VSM
on the reported warning. If the report reference is “-1” there is no additional information
available for the warning. If the report reference is greater than zero there is additional
information available for the warning, and the warning system should provide a method
to request this additional information. The method to request this additional information
could be a “Details” button or a “hyperlink” referenced to the displayed warning.
Software within the VSM decides whether more information is available for a specific
warning and sends the required report reference.
A4 - 130
Edition A Version 1
AEP-84.1
Upon user request, the CUCS issues a Subsystem Status Detail Request (Message
#15001) to the VSM to request more details. Field #4 of the Subsystem Status Detail
Request Message contains the Subsystem State report reference as received in the
Subsystem Status Alert Message (Message #16000) for the specified warning.
The warning system updates a warning by sending a Subsystem Status Alert Message
with a reference to the original Report Reference, with changes to the text to be
displayed. To reduce message bandwidth requirements, it is recommended the VSM
ensure that only new or updated messages are transmitted across the DLI.
The warning type identifies the persistency of the message for display on the CUCS
warning panel. The implementation for clearing Type 2 and Type 3 warnings is at the
CUCS developers discretion, however it is recommended the method to clear these
warnings be obvious. In order to clear a Type 1 Warning, Not Clearable by Operator,
the recommended method of implementation is to send a Subsystem Status Alert
Message with a reference to the original Report Reference as sent to display Warning,
but with a Priority of “Cleared”.
The warning display system is to be capable of displaying an ASCII string 80
characters in length. It is recommended the entire contents of the received text string
be displayed on the CUCS as received from the VSM. The CUCS does no
interpretation of the warning; it only provides a display for all warnings, in a prioritised
list.
The warning persistence time is used for warnings of Type 1 and Type 2. This time is
measured from when a Type 1 or Type 2 alert is received by the CUCS. If a Type 0
message is received before the time has expired, the alert will remain active for the
defined persistence time. If a Type 0 message is received after the persistence time
has expired, the alert will be deactivated immediately.
A4.2.7.5 Message #16001: Subsystem Status Report Implementation
This message provides the general status of all the systems on-board the UA. It is
recommended that this message be used in the creation of a Master Caution panel on
the CUCS display system, where the status of all subsystems is displayed in a common
location. A specific display component should represent each of the subsystems
identified in the message, and each possible state for a subsystem should be
distinguishable from another, such as through the use of colour or icons.
Using this message, the Master Caution panel is able to accept Subsystem state report
references associated with a specific subsystem. The report reference is a vehicle
specific reference provided by the VSM, which the CUCS can use to request additional
information from the VSM on the specified subsystem. The operator should have some
method, such as a button or a hyperlink, to request the additional subsystem
information.
A user request for additional information from the Master Caution panel initiates the
transmission of a Subsystem Status Detail Request Message (Message #15001) from
the CUCS to the VSM. The Subsystem Status Detail Request Message contains the
Subsystem State report reference as received in this message for the specified
subsystem. See Subsystem Status Detail Request Message (Message #15001) for
additional information. One message is required to report each of the identified
subsystems.
The VSM determines the subsystem state in accordance with the STANAG 4586/AEP84 Chapter 4, with the current states as follows:

No Status
A4 - 131
Edition A Version 1
AEP-84.1





Nominal
Caution
Warning
Emergency
Failed
The overall Subsystem State should be the state of the worst data element that is a
member of the subsystem’s set of data elements. As this message only provides a
generic status for each of the identified subsystems, a Report Reference should be
available to the CUCS for each of the subsystems.
Table A4 - 7 is a potential table to identify vehicle specific subsystem parameters,
identify the parameter states, and identify any additional information on the subsystem
based on the current state.
A4 - 132
Edition A Version 1
AEP-84.1
System
Monitored
Parameter
Mechanical
List of
Parameters
Nominal
Caution
Warning
Emergency
Failed
Information
Communication
Navigation
Engine
Electrical
Payload
Propulsion
Energy
Recovery
System
Environmental
Control
VSM
VDT
CDT
Note: The information column may identify the vehicle specific dialog to show on the return of a Report Reference. The message provides
the VSM implementer the ability to identify additional vehicle subsystems that are specific to the UA.
Table A4 - 7: Vehicle Specific Subsystem Parameters, States and Subsystem
A4 - 133
Edition A Version 1
AEP-84.1
A4.2.7.6 Message #16002: Heartbeat Message Implementation
The Heartbeat Message is used by either the CUCS or the VSM to monitor the other component
to ascertain if the other component is operational. One component will need to use Message
#17001 Schedule Message Update Command to schedule this message of the other
component at a desired rate, and take appropriate action if the message is not received within
the allowable latency of this message. This message may be used for a heartbeat from either
the CUCS or the VSM.
A4.2.8 General Configuration Messages
The General Configuration Messages are used to provide configuration information for a selected
UA from a VSM to a CUCS. This information allows a CUCS to configure the generic operator
displays and controls specifically for the selected UA. The General Configuration Messages used
to provide this capability and their intended sequence are as follows:
CUC
S
VSM
Message #40000: Sent from CUCS to
VSM for a requested parameter, for a
specific LOI, or a specific data link.
Messages #41001, #41002, #41003
and #41004: Sent from VSM to CUCS
for requested and required parameters.
Message #41005: Sent from CUCS to
VSM on completion of requests.
Message #41005: Sent from VSM to
CUCS on completion of configuration
message transmission from VSM to the
Figure A4 - 12: Configuration Information
The STANAG 4586/AEP-84 Volume II Chapter 4 identifies a list of parameters that must be
supported by the VSM for each of the General Configuration Messages to achieve interoperability.
The VSM must transmit the General Configuration Messages required for each of these
parameters upon reception of the Field Configuration Request message(s) from the CUCS. The
CUCS may request additional parameters from the VSM which it may or may not support.
Messages #42000 and #42001 are Generic Configuration Messages used to set up remote
display parameters. Message #41002 is a configuration message that provides both static
configuration (initialisation) for parameters and an update, in near real time (dynamic), of the
controllability of VSM (vehicle) parameters as applicable from the CUCS
Additional details on the intended use of the General Configuration Messages and expected
message sequencing is contained in the CUCS VSM Connection Sequence section of this
document and AEP-84 Volume II, Section 4.24.
A4.2.8.1 Message #40000: Field Configuration Request CUCS Implementation
The Field Configuration Request Message is used by the CUCS to request and initiate the
transmission of mandatory DLI field related configuration details, at the specified LOI, from the
VSM, or to request the configuration of a single parameter, for the specified Vehicle Type and
A4 - 134
Edition A Version 1
AEP-84.1
Subtype, payload station, sensor or data link. The VSM reports back the parameter configuration
it supports using one of the following formatted DLI messages:
 Field Configuration Integer Response (Message #41000)
 Field Configuration Float Response (Message #41001)
 Field Configuration Enumerated Response (Message #41002)
 Field Configuration Unsigned Response (Message #41003
 Field Configuration Character Response (Message #41004)
If the parameter is not supported by the VSM for the UA, the VSM is required to report back with
the appropriate message with the “Field Supported” field indicating such.
The Vehicle Type and Vehicle Subtype fields are used to provide the capability for the CUCS to
request the configuration of a specific UA where a VSM supports more than one type of UA.
A4.2.8.2 Message #41000: Field Configuration INTEGER Response Implementation
This message is transmitted from the VSM/UA/data link to the CUCS after the reception of
Message #40000 as required for each of the parameters that are required per a single parameter,
monitor, or control configuration request, and supported by the VSM for the ‘Station Number” (i.e.,
based on the Request Type and Station Number fields in the Message #40000 configuration
request) Message #41000 is used for a couple of purposes in reporting the configuration of the
VSM/UA to the CUCS. The first type of Message #41000 report is used to remove unsupported
generic enumerations from enumerated parameters with generic lists. This is conducted during
the initialisation process to ensure an operator is not provided access to an unsupported
enumeration. The CUCS must be capable of receiving this message from the VSM. This message
may be used by the CUCS to control and configure display information presented to the operator
on the CUCS display screens. It is used to configure the generic displays to the UA being
controlled through the VSM.
Refer to AEP-84 Volume II, Section 4.24.2 for additional implementation guidance.
A4.2.8.3 MESSAGE #42000: DISPLAY UNIT REQUEST CUCS IMPLEMENTATION.
The CUCS uses the Display Unit Request Message to indicate to the VSM the units that are
required to be displayed in vehicle specific dialogs for the vehicle specific parameters. The
message identifies a set of measurable parameters, and provides a selection of units for the
display of vehicle specific parameters. This message may be sent dynamically to the VSM by the
CUCS whenever the display units of the VSM need to be changed.
A4.2.8.4 MESSAGE #42000: DISPLAY UNIT REQUEST VSM IMPLEMENTATION.
The VSM must be capable of receiving the Display Unit Request Message from the CUCS, and
identify the display units that the VSM must use for display of the specified parameters within
remote displays. When a remote display is requested from the VSM by the CUCS, the parameters
displayed in the remote dialog must be displayed in the units specified in this message. This
message must be processed by the VSM whenever received from the CUCS.
A4.2.8.5 MESSAGE #42001: CUCS RESOURCE REPORT IMPLEMENTATION.
This message should be transmitted from the CUCS to the VSM to identify the parameters for the
vehicle specific services identified in the STANAG. The VSM should then transmit the vehicle
specific dialogs to the CUCS using the specified parameters.
A4 - 135
Edition A Version 1
AEP-84.1
A4.2.8.6 MESSAGE #41005: CONFIGURATION COMPLETE MESSAGE
IMPLEMENTATION.
The Configuration Complete Message is transmitted to the VSM by the CUCS once it has
transmitted all its Configuration Request Messages.
The Configuration Complete Message is transmitted from the VSM to the CUCS once the VSM
has sent all its available Configuration (report) Messages to the CUCS. This signals to the CUCS
that the HCI elements may be configured and displayed to the CUCS operator. When the VSM
is connected to an UA it specifies the Vehicle ID and when no vehicle is connected to the VSM
the null Vehicle ID is specified. In situations where more than one type of vehicle is supported by
the VSM, the Vehicle Type and Vehicle Subtype fields in the message identify the specific type
of vehicle for which the configuration information was requested by and transmitted to the CUCS.
A4.2.8.7 MESSAGE #41003: FIELD CONFIGURATION UNSIGNED RESPONSE
IMPLEMENTATION.
The CUCS must be capable of receiving this message from the VSM. This message may be
used by the CUCS to control and configure display information presented to the operator on the
CUCS display screens. It is used to configure the generic displays to the UA being controlled
through the VSM. Where the UA/VSM/data link uses this message to report a DLI message
parameter, the CUCS should present the Cautions and Warnings to the operator in accordance
with the message for the specified parameter. The High Caution limit and Low Caution Limit shall
be equivalent to Message #16000, priority enumeration of “Caution”. The High Warning limit and
Low Warning limit shall be equivalent to Message #16000, priority enumeration of “Warning”. The
VSM should not present these same warnings. The Help text is provided in the event the CUCS
supports context sensitive help for parameters in the generic displays.
For both the CUCS and VSM implementation in messages #41000 and 41003, a BAM
field that is Unsigned, the following Min/Max values will result in a valid value range:
Min
Value
Max
Value
Allowable Range
Prohibited Range
10
230
10 to 230
230 (exclusive) to
360 (inclusive)
and
0 (inclusive) to
10 (exclusive)
230
10
230 to 360 and
0 to 10
10 (exclusive) to
230 (exclusive)
For a BAM field that is Signed the following Min/Max values will result in a valid value
range:
A4 - 136
Edition A Version 1
AEP-84.1
Min
Value
Max
Value
Allowable
Range
Prohibited Range
-40
60
-40 to 60
60 (exclusive) to
180 (inclusive)
and
-180 (inclusive) to
-40 (exclusive)
60
-40
60 to 180 and
-180 to -40
10 (exclusive) to
230 (exclusive)
A4.2.8.8 Message #41001: Field Configuration Float Response CUCS Implementation
The CUCS must be capable of receiving this message from the VSM. This message may be
used by the CUCS to control and configure display information presented to the operator on the
CUCS display screens. The intended purpose of the message is to provide sufficient information
from the VSM, regarding the limits of a specific UA parameter, to the CUCS to allow the
configuration of the generic displays for the UA being controlled through the VSM.
The Max and Min value fields identify the minimum and maximum values a parameter is capable
of achieving in the system, and the Max Display and Min Display values are the recommended
ranges for a display used to present this parameter to the operator. For operator entered data,
the Min Value and Max Value fields define the range of values that the CUCS must allow the
operator to enter. While this standard does not explicitly require the CUCS HMI to prevent
operator entries outside of this range, it does prohibit them from being sent in the DLI message.
How the CUCS handles operator entered values is not defined by this standard.
For data received by the CUCS, the Min Value and Max Value fields define the range of values
that the CUCS must accept and process. The Standard does not specify how the CUCS should
process data that is outside of this range.
For data displayed to the operator, the Max Display and Min Display fields define a range of values
that potentially can be displayed to the operator. This range is allowed to be greater than then
Max Value and Min Value to support HMI "analogue" gauges where the normal value is
traditionally mid-scale in the display but not in the middle of the allowed range.
The Minimum Resolution is only used to define the HMI display resolution. It is a suggested
minimum resolution. The CUCS is free to ignore this field but this may reduce the usability of the
data. The message provides the Caution and Warning high and low limits for the parameter as
specified for the UA. The Help text is provided in the event the CUCS supports context sensitive
help for parameters in the generic displays.
A4.2.8.9 Message #41001: Field Configuration Float Response VSM Implementation
The intended purpose of the message is to provide sufficient information from the VSM, regarding
the limits of a specific UA parameter. For float parameters that the VSM is required to support,
this message is transmitted to the CUCS for each of the vehicle parameters when requested by
A4 - 137
Edition A Version 1
AEP-84.1
the CUCS with the Configuration Request Message. The CUCS uses the Field Configuration
Request (Message #40000), to request optional parameters from the VSM for configuration.
The Max and Min value fields identify the minimum and maximum values a parameter is capable
of achieving in the system, and the Max Display and Min Display values are the recommended
ranges for a display used to present this parameter to the operator.
The message provides the Caution and Warning high and low limits for the parameter as specified
for the UA. The Help text is provided in the event the CUCS supports context sensitive help for
parameters in the generic displays.
As a minimum, the VSM is required to support the Field Configuration Float Response Message
for the formatted DLI message parameters identified in STANAG 4586/AEP-84, Volume II,
Section 4.24.3. Configuration of other parameters contained in the formatted DLI messages is
optional.
The following diagram is a generic depiction of the use of the Field Configuration Float Response
Message.
STANAG Max. Value
Out of
Range
Values
AV Specific Max. Value
Max. Display Value
High Warning Level
High Caution Level
]
Out of
Range
Values
Min. Display Resolution
Low Caution Level
Low Warning Level
Min. Display Value
AV Specific Min. Value
STANAG Min. Value
Figure A4 - 13: Generic Depiction of the Field Configuration Float Response Message
A4 - 138
Edition A Version 1
AEP-84.1
A4.2.8.10 Message #41002: Field Configuration Enumerated Response CUCS
Implementation
The CUCS must be capable of receiving this message from the VSM. It is highly recommended
that this message be used by the CUCS to configure display information presented to the operator
on the CUCS display screens, as this message may be used to add control modes for the UA.
The “Enumeration Text” provides a description of the added enumerations to allow for operator
displays to present the data and for control over the enumerated value. This capability is used to
configure enumerated fields where there is no generic enumerated listing for the parameter, or to
extend the set of enumerated values where there are vehicle specific enumerations available.
An example of where this capability is used is for the Flight Termination Command (Message
#2005), Flight Termination mode. This parameter has no identified generic Flight Termination
modes, therefore the VSM uses the Field Configuration Enumerated Response (Message
#41002), to identify the available Flight Termination modes for the vehicle under control. These
modes must then be presented to the operator in the generic displays by the CUCS.
A4.2.8.11 Message #41002: Field Configuration Enumerated Response VSM
Implementation
The VSM is required to support the Field Configuration Enumerated Response Message for the
formatted DLI message parameters identified in STANAG 4586/AEP-84 Volume II, Section
4.24.4, with other parameters contained in the formatted DLI messages being optional. This
message is used specifically by the VSM to create an enumerated list for parameters that do not
have a list of generic enumerations, or to add to the list of generic enumerations for the specified
parameter. Where there is a generic list in existence, the enumerations from Message #41002
are added to the end of the list in the Vehicle (VSM) Specific reserved enumerations. The
message is not to be used to create a new set or re-organize a set of generic enumerations
already specified for an enumerated field.
The “Enumeration Count” field identifies the number of VSM specific enumerations that are
supported for the field, and the message is sent once for each enumerated value to be added to
the list. The “Enumeration Index” identifies the current enumeration and the “Enumeration Text”
provides a description of the enumeration to allow for operator displays and control over the
enumerated value.
An example of where this capability is used is for the Flight Termination Command (Message
#2005), Flight Termination mode. This parameter has one ”Unspecified” generic Flight
Termination mode, therefore the VSM uses the Field Configuration Enumerated Response
(Message #41002), to identify the available Flight Termination modes for the vehicle under
control. Adding two VSM Specific enumerations requires this message to be transmitted from the
VSM to the CUCS twice:
A4 - 139
Edition A Version 1
AEP-84.1
Instance One:
Requested Message
46
Requested Field
5
Field Supported
1
Enumeration Count
2
Enumeration Index
1
Enumeration Text
Parachute
Help text
Deploy the parachute
Instance Two:
Requested Message
46
Requested Field
5
Field Supported
1
Enumeration Count
2
Enumeration Index
2
Enumeration Text
Self Destruct
Help text
Blow up UA
A4.2.9 Miscellaneous Message Types
Implementation Guidance for selected messages in this functional group are provided in the
following sub-sections of A4.2.9. Guidance for the remaining messages in this functional group
are adequately defined in the AEP-84 Volume II document.
A4.2.9.1 Message #17000: Message Acknowledgement Implementation
The Message Acknowledgement Message is used by either the CUCS or the VSM to
acknowledge a message that requires an acknowledgement. Message acknowledgement
requirements are established using the Message Acknowledge Configuration Message (Message
#1401).
If an acknowledgement is not granted in a timely fashion, the requestor must regenerate the
message request as required by the system.
A4.2.9.3 Message #17001: Schedule Message Update Command Implementation
A4 - 140
Edition A Version 1
AEP-84.1
The CUCS uses the Schedule Message Update Command to request a message that is of type
“pull” from the VSM, to be sent from the VSM to the CUCS at a defined frequency. Where the
VSM is already transmitting a requested message at a specified frequency to the CUCS as
required by the VSM manufacturer, the VSM will not accept a slower rate.
A4.2.9.4 Message #17002: Generic Information Message Implementation
The STANAG 4586/AEP-84, Volume II, Chapter 4, Data Link Interface document, Tables 4 – 6
thru 4 - 32: provides a listing of all the current STANAG 4586 DLI messages. The Type column
in the table indicates whether the message must be pushed or pulled. The Generic Information
Request Message (Message #17002) is used to request messages that are of the type “pull”.
An example of this implementation is that at the CUCS there is a requirement to display the
Vehicle Operating states. In order to display the most current vehicle operating states, the CUCS
sends a Generic Information Request Message (Message #17002) to the VSM with the “Message
Type” set to “3002”. The VSM then replies by sending a Vehicle Operating States Message
(Message #3002) to the CUCS which requested the message.
A4.2.9.5 Message #17003: File Transfer Notification
The FTP protocol is used to exchange file-based data between the CUCS and the VSM.
Specifically, still imagery (in STANAG 4545 format) captured by the UA needs to be transferred
to the CUCS as a series of files, rather than streaming data such as that supported by STANAG
4609 for the video imagery. This message allows the VSM to notify the CUCS that a new payload
data file has been deposited into the ftp directory previously defined by the CUCS in the #42001
CUCS Resource Report message. Additionally, the message may be used to report the transfer
of other files between the CUCS and the VSM, for VSM-specific purposes. For this use, the
message may be generated by the CUCS.
A4.2.9.6 Message #18002: Console Light Command
Message #41002, Field Configuration Enumerated Response, can be used to assign text to a
given light enumeration that can be used by the CUCS to display on or near the light.
A4.2.9.7 Message #18200: Meteorological Table Message
This message is used by the CUCS to send meteorological data to the UA.
A4.2.9.8 Message #18300: Meteorological Table Report
This message shall be used by the UA to report meteorological data to the CUCS
Meteorological data sent from the AV can be used to update the expected mission plan as well
as providing input to support weapons delivery.
Sending meteorological data to the AV can be used to support enhanced landing algorithms.
Forecast time (Field 4) may not necessarily be in the future relative to current time. Forecast time
(Field 4) will always be greater or equal to publish time (Field 3).
A4 - 141
Edition A Version 1
AEP-84.1
A4.2.9.9 Message #18500: GPS Status Report
The GPS reported in this message is the time to the nearest second. If more accurate time is
required, the hardware PPS output of the GPS should be used and is not supported for
transmission with a DLI message.
A4.2.10 IFF Command and Status Messages
See section A4.1.7 of this Annex for message implementation details.
A4.2.11 Flight Vehicle Command and Status Messages
See Section A4.1.5, Vehicle Control Modes, section of this Annex and AEP-84 Volume II,
Sections 4.3, 4.4 and 4.5 respectively for Implementation Guidance.
A4.2.12 Vehicle Auxiliary Command and Status Messages
See AEP-84 Volume II Sections 4.10 and 4.11, respectively for Implementation Guidance.
A4.2.13 ATC Interface Command and Status Messages
See AEP-84 Volume II Sections 4.8 and 4.9 respectively for Implementation Guidance.
A4.2.14 Autonomy Messages
See AEP-84 Volume II Section 4.23 for Implementation Guidance.
A.4.2.15 VSM Forced Command Messages
See AEP-84 Volume II Section 4.26 for Implementation Guidance.
A4.2.16 Draw Interface Messages
See AEP-84 Volume II Section 4.27 for Implementation Guidance.
A4 - 142
Edition A Version 1
AEP-84.1
ANNEX 5
A5 Backward/Forward Compatibility Issues/Recommendations
The embedded spreadsheet maps the AEP-84 Volume I data elements to AEP-84 Volume II’s
respective data elements. Unique IDs, Field numbers, hardcoding values, notes and numerations
are included. This spreadsheet was developed to assist AEP-84 Volume I users to migrate to the
AEP-84 Volume II and vice versa. Please contact the Chairman at john.e.mayer1@navy.mil for
questions, issues, or recommendations.
The yellow and red highlights are concerns which are being reviewed. Potential DCPs may be
generated in the future to help make the two AEP-84 Volumes more compatible.
STANAG 4586 AEP-84 Vol 1 To AEP-84 Vol 2 Mapping.xls
A5 - 1
Edition A Version 1