BAO Kit ICD 3 - Software.pdf

ST Toolkit Core Interface Control Document for Version 1.0

Prepared for:

Battlefield Airman Branch (ASC/WISN)

1895 Fifth Street, Building 46

Wright-Patterson AFB OH 45433-7200

Prepared by:

SRA International, Inc.

SRA C4ISR Center

5000 Springfield St., Suite 200

Dayton, OH 45431

December 15, 2010

ICD for ST Toolkit Core ii

SRA International, Inc. December 15, 2010

STToolkitCoreICD_13230.001_15Dec10v1.0 BAO Kit ICD 3

Document Change History

Revision

Number

Date DCN Change

Description

1.0 for ST

Toolkit Core v1.0

15 Dec

STTCoreICD_13230.001_15Dec10v1.0 Initial Release iii

Table of Contents

1. Introduction

2. ST Toolkit Core Output

2.1 Common CoT Fields

2.1.1 Start Time/Time/Stale Time

2.1.2 UIDs

2.1.3 How

2.1.4 LE

2.1.5 CE

2.1.6 Flow-tag

2.1.7 Version

2.2 Image CoT Message

2.3 Send CoT to PSS-SOF

2.3.1 Calibrating an LRF Device

3. ST Toolkit Core Input

3.1 Main Port

3.2 Feedback Port

3.3 Announcement Port

4. ST Toolkit Core Tasking

4.1 Issuing Tasks

4.1.1 General Information

4.1.1.1 Request and Notify Information

4.1.2 Ping Task

4.2 Processing Tasks

4.2.1 Ping Task

4.2.2 Ping Task Reply

5. Acronyms iv

List of Tables

Table 2-4 Image CoT Table 3-1 CoT on Feedback Port

Table 4-1 Request and Notify Tags

Table 4-3 APTD Request Task ..................................... Error! Bookmark not defined.

Table 4-5 Ping Task CoT Table 4-6 Ping Reply CoT

1. Introduction ST Toolkit Core is an application that significantly improves an operator‟s capability to communicate and validate a point‟s location through a map-centric process. ST Toolkit

Core allows an operator to generate, save, and send CoT messages, providing a fully digital machine-to-machine ability to transmit data about a given location. This document is intended to provide information needed to interface with ST Toolkit Core using

Cursor-on-Target (CoT). Specifically, it details the data being sent from ST Toolkit Core along with the CoT messages that ST Toolkit Core will process when received. This document is not intended to provide detail on the CoT protocol itself, but it provides information on how ST Toolkit Core uses this protocol. Documentation and further information about CoT can be obtained from http://cot.mitre.org. This document pertains to version 1.0 of the ST Toolkit Core software.

2. ST Toolkit Core Output ST Toolkit Core communicates by sending and receiving CoT via Transmission Control

Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) Multicast.

2.1 Common CoT Fields

Though ST Toolkit Core sends multiple different types of messages, there are several generalities that the application applies to each message. The following sections outline the generalities of the ST Toolkit Core-generated CoT messages.

2.1.1 Start Time/Time/Stale Time

ST Toolkit Core sets the CoT time and start time attributes to the current system time when the CoT message is saved. The stale time is set to the current time plus a date-time delta that is set in ST Toolkit Core‟s configuration. By default, the delta is set to five minutes for friendlies and four hours for all other points. CoT messages are saved before they are sent and when manually saved by the user.

2.1.2 UIDs

ST Toolkit Core generates CoT unique identifiers (UIDs) based on the type and name of the entity and the currently-configured callsign. The UID consists of a variable number of parts, depending on the type of CoT message, which are “.” delimited. The first segment is always the system prefix, which ST Toolkit Core sets to “BAO”. The second segment identifies the type of event with „H‟ denoting hostile or neutral, „F‟ denoting friend, „IP‟ denoting Initial Point/Control Point (IP/CP), and „SPI‟ denoting Sensor Point of Interest (SPI). The type attribute should always be used for determining an event‟s type, but this is encoded in the UID to provide name uniqueness across events. The third segment of the UID is the currently configured callsign in ST Toolkit Core or the callsign of the friend if the CoT type is friendly. Again, this should not be used to determine the message‟s originator, but is simply included to provide UID name uniqueness. The fourth segment only exists for non-friendly CoT messages and is set to the simple name of the CoT message.

http://cot.mitre.org/

2.1.3 How

ST Toolkit Core tracks how coordinates are derived and assigns the appropriate CoT

How value. For target and friend entities, ST Toolkit Core will set the How value to “h-e”

(human-entered estimated) by default. For an IP/CP, the default How value is “h-t”

(human transcribed) but will be set to “h-e” if the Circular Error (CE) or Linear Error

(LE) are manually entered. For CoT that has had coordinates, elevation, range, or heading manually entered, the How value will be set to “h-e” (human-entered estimated).

The How value is set depending on the order in which the CE and LE are manually entered for CoTs. If the CE is set after the LE, then the How value will be based on the range in which the manually-entered CE falls. If the CE is between .001 meters and 49 meters then the How will be set to “h-t”, and if it is between 50 meters and 99.999 meters then the How value will be set to “h-c”. If the CE is greater than 100 meters, the How value will be set to “h-e”. If the LE is set after the CE then the How value will be set to

“h-e”, no matter the range in which the LE falls. If a CoT‟s coordinates were generated from a Laser Range Finder (LRF), the value will be set to “m-m” (machine generated-magnetic). If a CoT‟s location has been pulled from a map or the entity has been plotted to the map, the value will be set to “m-s” (machine generated-simulated). If CoT‟s coordinates were mensurated, namely through Precision Strike Suite Special Operation

Forces (PSS-SOF), the How will be set to “m-i” (machine generated-mensurated from imagery). Finally, if a CoT‟s coordinates were generated by a Global Positioning System

(GPS) receiver, the How will be set to “m-g” (machine generated-GPS receiver).

2.1.4 LE

The LE is set or calculated based on how the associated coordinates are acquired. If the coordinates are entered manually, the LE is set to 50 m. When coordinates are pulled from the map, the LE is set to 20 m if there is Digital Terrain Elevation Data (DTED) available and is set to 999.8 m if no DTED is available. When coordinates are sent to

PSS-SOF for mensuration, the LE is set based on the data returned from PSS-SOF.

When using the LRF to acquire coordinates, the LE is calculated based on the returned range and accuracy of the current friendly location.

2.1.5 CE

The CE is set or calculated based on how the associated coordinates are acquired. If the coordinates are entered manually, the CE is set to 100 m. When coordinates are pulled from the map, the CE is set to 20 m regardless of the presence of DTED. When coordinates are sent to PSS-SOF for mensuration, the CE is set based on the data returned from PSS-SOF. When using the LRF to acquire coordinates, the CE is calculated based on the returned range and accuracy of the current friendly location.

2.1.6 Flow-tag

All CoT messages sent from ST Toolkit Core have a flow tag inserted into the event detail section of the CoT message. The flow-tag attribute is named “STToolkit” and its value is set to the current system time when the message was sent.

2.1.7 Version

All CoT messages sent from ST Toolkit Core are based on CoT version 2.0, therefore the

CoT version attribute is always set to 2.0.

2.2 Image CoT Message

Image CoT messages are sent by ST Toolkit Core if an entity CoT (such as a hostile or friendly) has an associated file and the user has configured to send the file. Unless specified, all fields in the image CoT are copied from the CoT message to which the image is linked.

Note that although the CoT message is called an “image CoT,” ST Toolkit Core has the capability to embed file data of any type, not just images.

Example “Image” CoT:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<event uid="BAO.H.Callsign.Tgt01.Image" version="2.0" how="m-s" type="b-i" time="2010-10-17T15:21:34.242Z" start="2010-10-17T15:21:34.242Z" stale="2010-10-18T15:21:34.242Z">

<point lat="17.441871" lon="-2.098034" hae="0."

ce="20."

le="999.8" />

<detail>

<image mime="image/jpeg">

Base64 encoded file data goes here.

</image>

</detail>

</event>

Table 2-1 Image CoT

Tag Name Tag Description event uid The UID of the image CoT message is derived from the UID of the CoT to which the file is linked. The file CoT UID is a result of appending an “.Image” to the corresponding CoT‟s UID.

type BareBack sets the CoT type attribute to "b-i" for image CoT messages.

image This is the standard CoT image subschema. Though it is called

“image,” ST Toolkit Core has the capability to embed file data of any type in a CoT message. The content of this node is the base64 encoded file.

mime This attribute describes the mime type of the file.

2.3 Send CoT to PSS-SOF

ST Toolkit Core may interact with PSS-SOF to obtain mensurated coordinates for a

CoT‟s position. After ST Toolkit Core sends the appropriate CoT message to PSS-SOF, PSS-SOF may respond to ST Toolkit Core with an updated CoT message. ST Toolkit maintains a persistent connection with PSS-SOF when sending the CoT message, opposed to following the typical open-squirt-close paradigm when sending CoT messages.

2.3.1 Calibrating an LRF Device

By communicating with PSS-SOF, ST Toolkit Core is also able to calculate an LRF correction value. ST Toolkit Core will send the laser-designated position to PSS-SOF; it should then receive mensurated coordinates for that position from PSS-SOF. ST Toolkit

Core will use the mensurated location, the original location, and the user‟s location to calculate the LRF correction angle.

3. ST Toolkit Core Input ST Toolkit Core is able to receive CoT messages on three different ports. When receiving on the main port, ST Toolkit Core processes the entire CoT message that is received. CoT messages received on ST Toolkit Core‟s feedback port are considered updates to existing messages, so only Link 16 track information is processed when present. When receiving on the announcement port, ST Toolkit Core checks the CoT message for a service detail in order to determine if it is an announcement and which types of CoT messages the sender can receive.

3.1 Main Port

Messages received on the main port will be forward to all applets that have registered to the receive that CoT‟s type.

If a received CoT message has an image detail, the image detail data is stripped from the received CoT message and saved into separate CoT message(s) of type “b-i”. The newly created image CoT message(s) are then linked back to the originally received CoT message.

3.2 Feedback Port

ST Toolkit Core processes messages received on the feedback port in a much different manner than messages received on the main external port. Whereas entire new, or updated, CoT events are processed on the main port, CoT messages received on the feedback port are only used to provide supporting data for existing entities. Upon receipt of a feedback message, ST Toolkit Core checks for the existence of the received CoT

UID in the active database. If the received CoT UID is present in the database, the track numbers for the existing CoT message will be updated with the track number data from the newly received feedback CoT message. If the feedback CoT message is stale upon receipt, the track numbers it contains will be removed from the currently stored CoT.

Otherwise, the feedback CoT‟s track numbers will be merged with the existing CoT‟s track numbers.

Example “Update” CoT:

<?xml version='1.0' standalone='yes'?>

<event how="m-s" stale="2007-10-24T17:10:20.82Z" start="2007-10-23T17:10:20.81Z" time="2007-10-23T17:10:20.82Z" type="a-h-X" uid="BAO.H.Callsign.Tgt01" version="2.0">

<detail>

<_flow-tags_ ST Toolkit Core="2007-10-23T17:10:20.827Z"

GetNineLine="2007-10-23T17:34:21.559Z" mtcd="2007-10-23T17:34:21.00Z" />

<link relation="p-p" type="a-f-G-U-C-I" uid="BAO.F.Callsign.Fnd01" />

<remarks>remarksText</remarks>

<uid tadilj="01500" />

</detail>

<point ce="100."

hae="51.090999603271" lat="40."

le="50."

lon="0." />

Table 3-1 CoT on Feedback Port

Tag/Field Name Tag Description event uid ST Toolkit Core uses the CoT UID to determine if the CoT exists in the active database.

stale ST Toolkit Core uses the stale time to determine the action to take with the received track data. If the stale time has passed, the track data in the UID subschema is removed from the existing CoT in the active database. Otherwise, the track data is merged with the existing CoT, uid This is the standard CoT uid subschema. ST Toolkit Core uses the attributes in this node to update the existing CoT messages track data.

tadilj ST Toolkit Core will process all attributes of the uid node.

The tadilj attribute is MTCD‟s system identifier. This is used as an example of uid data, though ST Toolkit Core does not specifically look for this attribute.

3.3 Announcement Port

ST Toolkit Core processes received announcement messages which contain information about the sender including their callsign and an IP/port pair to which CoT messages should be sent. ST Toolkit Core checks the CoT message for a service detail to determine if it is an announcement message. If so, ST Toolkit Core then checks each ipfeatures in the service detail to determine which types of CoT messages (i.e., friendlies, hostiles, etc.) the sender is capable of receiving. Once these capabilities are determined, relevant communication information is saved and can be used when sending CoT messages of the appropriate type(s).

Example “Announcement” CoT:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<event uid="BAO.F.CS" version="2.0" how="h-g-i-g-o" type="a-f-G-U-C-I" time="2008-12-09T21:17:04.113Z" start="2008-12-09T21:17:04.113Z" stale="2008-12-09T21:23:04.113Z">

<point lat="0" lon="0" hae="0" ce="99999999" le="99999999" />

<detail>

<contact callsign="CS" />

<__services>

<ipfeature type="s-t-k-d" desc="Targets">

<sink uri="cot://163.252.218.167:1234;tcp" mime="application/x-cot" />

</ipfeature>

</__services>

<_flow-tags_ ApplicationX="2008-12-09T21:17:04.128Z" />

<__serverdestination destinations="udp:224.10.10.1:18012" />

</detail> event type The announcement message CoT type is "a-f-G-U-C-I".

__services This is the custom services CoT subschema ipfeature Contains information regarding the ipfeature.

desc This to the description of the ipfeature, (i.e., Targets).

type This is the CoT type associated with the ipfeature. In this example, the type of “s-t-k-d” indicates that the sender can receive targets.

sink Contains information regarding the sink, which is the relationship from the current user to the remote user.

uri This should be set to the URI of the announcement sender to which CoT messages can be directly sent.

contact The standard contact detail.

callsign This should be the callsign of the sender.

4. ST Toolkit Core Tasking ST Toolkit Core can issue and process certain tasking CoT messages, and it may receive responses to those tasking requests. The following sections describe these types of messages.

4.1 Issuing Tasks

ST Toolkit Core issues specific tasks to either acquire coordinate information, obtain imagery for a location, or to determine if there is a communication connection between

ST Toolkit Core and another application. If a point is changed to an ISR type through ST

Toolkit Core, it will be sent as an ISR task. This will set the request notify tag in the CoT message so that the recipient knows to whom a response should be sent. If any point is sent to the BatMAV client in ST Toolkit Core, it will be sent with an event type of “t-s-i-e” and the request notify tag will be populated accordingly.

4.1.1 General Information

Though ST Toolkit Core sends multiple different types of tasking messages, there are several generalities that the application applies to each message. The following sections outline the generalities of the ST Toolkit Core-generated CoT tasking messages.

4.1.1.1 Request and Notify Information

In order for a tasking message to be completed, a response to the tasking is expected.

When sending tasks, ST Toolkit Core will always add a request detail, with a notify attribute, to the CoT message. This allows the application processing the tasking message to send a response back to ST Toolkit Core. This is standard data that should be included when sending tasking CoT messages.

Table 4-1 Request and Notify Tags request This is the standard CoT request subschema.

notify ST Toolkit Core sets the notification IP address to its hosting computer‟s IP address. Additionally, the notification port is set to

ST Toolkit Core‟s main receiving port and the protocol is TCP.

(The value format is: host:port:protocol, e.g., 192.168.0.1:6565:tcp.)

4.1.2 Ping Task

ST Toolkit Core has the ability to send out a ping tasking CoT message to any CoT compliant application. The ping tasking CoT invokes a response from the receiving application to determine if there are good communications between ST Toolkit Core and that application.

Example “Ping Task” CoT:

<event how="h-g-i-g-o" stale="2008-01-08T18:01:35.23Z" start="2008-01-08T18:01:05.23Z" time="2008-01-08T18:01:05.23Z" type="t-x-a-c-c" uid="__ping.EV" version="2.0">

<detail>

<_flow-tags_ ST_Toolkit="2008-01-08T18:01:05.248Z" />

<request notify="127.0.0.1:6565:TCP" />

</detail>

<point ce="99999999."

hae="0."

lat="0."

le="99999999."

lon="0." />

Table 4-2 Ping Task CoT event uid ST Toolkit Core sets this to be “__ping.” followed by the configured name of the application that is being pinged.

stale ST Toolkit Core sets the stale time of the tasking message to the start time plus five minutes.

type ST Toolkit Core sets the type to “t-x-a-c-c” (tasking-application-control-communication).

4.2 Processing Tasks

ST Toolkit Core has the ability to process ping tasking messages and replies.

4.2.1 Ping Task

ST Toolkit Core has the ability to process a ping task. Please refer to Section 4.1.2 for an example of a ping tasking message. When ST Toolkit Core receives a ping task it sends back a reply message to the designated location found in the notify attribute. ST Toolkit

Core only changes the type to “y-c-s” to indicate successful receipt of the task. All other information in the tasking CoT message is kept the same.

4.2.2 Ping Task Reply

ST Toolkit Core expects a reply to the issued ping task. If the reply is received before the ping tasking message stales out, ST Toolkit Core is able to communicate with the receiving application. If the task stales out before a response is received, ST Toolkit

Core is not able to communicate with the receiving application.

Example “Ping Reply” CoT:

<event how="h-g-i-g-o" stale="2008-01-08T18:01:35.23Z" start="2008-01-08T18:01:05.23Z" time="2008-01-08T18:01:05.23Z" type="y-c-s" uid="__ping.EtherView" version="2.0">

<detail>

<_flow-tags_ ST Toolkit Core="2008-01-08T18:01:05.248Z"

EtherView=”2008-01-08T18:01:06.2341Z” />

<request notify="127.0.0.1:6565:TCP" />

</detail>

<point ce="99999999."

hae="0."

lat="0."

le="99999999."

lon="0." />

</event> Table 4-3 Ping Reply CoT

Tag Name Tag Description event uid ST Toolkit Core uses the CoT UID to determine the application that is responding to the ping request. ST Toolkit Core removes the “__ping.” prefix to determine which application responded to the ping request.

type ST Toolkit Core looks for the “y-c-s” (tasking-complete-success) to indicate successful communications.

5. Acronyms BAO – Battlefield Air Operations

CE – Circular Error

CoT – Cursor-on-Target

DTED – Digital Terrain Elevation Data

EP – Exit Point

EV – EtherView

FV – FalconView

FT – Feet

GPS – Global Positioning System

HAE – Height Above Ellipsoid

ICD – Interface Control Document

IP – Internet Protocol

IP/CP – Initial Point / Contact Point

LE – Linear Error

LRF – Laser Range Finder

MSL – Mean Sea Level

PSS-SOF – Precision Strike Suite, Special Operation Forces

SPI – Senor Point of Interest

TCP – Transmission Control Protocol

UDP – User Datagram Protocol

UID – Unique Identifier

WPAFB – Wright Patterson Air Force Base

XML – eXtensible Markup Language