Basic concepts

This document acts as a supplement to the schema. As a result, it should not be used as a reference but a guide.

The main procedure should be to:

  • Log data either in detection or tracks depending on the nature of the data.
  • Organize and distinguish elements through record fields.
  • Classify and identify objects.
  • Fill in all fields that the system allows. Leaving optional fields blank means the system is incapable of obtaining such information.

This document will focus on explaining these concepts.

Record organization

The format uses different structures to organize and distinguish data.

Records

Records represent all the information related with an entity in a given time and, when applicable, point in space.

Record sets

Record sets are clusters of records under a unique uas_id and name. These fields are used to identify and distinguish record sets within the format.

  • name simply acts as free-form text to distinguish record sets. As it is an optional field, each company can use it to organize their data as they see fit.

  • uas_id is used to distinguish and correlate different record sets within the format. Unique sets of records should have unique values while record sets that refer to the same UAS should have the same uas_id. In the case of tracks, this allows a method of logging the C-UAS losing the UAS momentarily, emulating a discontinuous track.

It is essential for C-UAS that intercept the UAS communication to view the Intercepting C-UAS segment to understand the UAV - GCS logging procedure.

1

Record sets refers to both track and detection set elements (inside detection and tracks).

Tracking and Detection

The format distinguishes 2 types of data: tracking and detection. Data inside tracks and detection is organized in record sets (called tracks and detection sets, respectively).

Tracking

Tracking is used for targets that the C-UAS has locked on and is actively tracking their positions. These records should describe the trajectory of a specific target.

When the system locks on a target and starts to track its position, the system should log each continuous track as an element of tracks. In the case of a target coming in and out of view, each continuous track should be logged separately under the same uas_id, as a way to link the tracks.

Detection

Detection is used for sporadic detections without a clear spatial or temporal relation and thus can't be considered to be tracked. This does not include tracks that are momentarily lost and picked up later.
Targets aren't required to be identified to be part of a record, only detected.

When these systems detect potential targets, the system should log each unique target as a different detection set (members of detection). In the case of entities not properly identified as a unique target, they should omit the uas_id parameter.

Classification and Identification

The format allows systems to classify and identify target records through the appropriately named fields classification and identification. The only required field is classification while identification is used to complement the classification.

Classification refers to the basic category of the target detected. The available options are:

  • Unknown: The C-UAS could not classify the entity with certainty
  • UAV: Unmanned Aerial Vehicle
  • GCS : Ground Control Station, the entity is the operator of another entity of the same uas_id
  • Other: The entity doesn't fall in any of the previous categories, e.g. bird.

Identification refers to a more detailed description of the entity in question. This field is optional and is meant to act as a more thorough description of the entity than classification. As such, it is left free for the company to include a description more in line with their system's capabilities, whether it's specific information on the target (operator’s ID, ID of the drone, UAV model, etc) or a more robust classification than the one provided.

C-UAS Location

C-UAS systems are required to provide their position for the trials. To accommodate for mobile and static systems, there are 2 methods of providing the C-UAS position.

static_cuas_location is used for denoting the position of a static system. This field is compulsory for all C-UAS, but mobile systems can rely on the cuas_location field inside all records for a dynamic position that will override the value given on static_cuas_location. In such cases, static_cuas_location should include the first C-UAS position recorded.

Special cases

The format allows a wide range of systems to log information.

As is expected, this diversity gives rise to a variety of structures depending on the system in question. As a result, some systems require extra effort when logging data.

This chapter offers a set of examples intended to act as a reference for both the format and the results expected using the track visualizer (track2kml).

Basic example

Here are record examples extracted from the basic COURAGEOUS example file.

Using BearingElevation:

...
{
    "alarm": {
        "active": true,
        "certainty": 1
    },
    "classification": "Unknown",
    "location": {
        "$type": "BearingElevation",
        "bearing": 43.563024999999996,
        "elevation": 2.211875
    },
    "record_number": 4,
    "time": 1696255068480
},
...

Using Position3d and including the identification and velocity optional fields:

...
{
    "classification": "UAV",
    "identification": "UAV description",
    "alarm": {
        "active": false,
        "certainty": 0.55
    },
    "location": {
        "$type": "Position3d",
        "height_amsl": 47.15314324164956,
        "lat": 51.158929232973726,
        "lon": 2.7414165702140973
    },
    "record_number": 0,
    "time": 1696421411207,
    "velocity": {
        "east": -2.14297,
        "north": 1.69235,
        "up": -0.86349
    }
},
...

Intercepting C-UAS

Systems that intercept the communication between GCS and UAV require a specific logging procedure.

1. UAV logging

When a UAV is detected or tracked, the system should log the UAV position instances in the same record set1 under a unique uas_id.

2. GCS logging

The GCS location can be logged either in the same record set1 or a different one with the same uas_id.

3. UAV Home location

In the case of C-UAS systems that are capable of extracting the home location of the UAV, it should be included in the UAV record set1 using the uav_home_location member.

Example

This is set of records extracted from the intercepting C-UAS COURAGEOUS format example.

...
 {
    "classification": "UAV",
    "identification": "UAV Description",
    "alarm": {
        "active": true,
        "certainty": 1
    },
    "location": {
        "$type": "Position3d",
        "height_amsl": 52.33707466137043,
        "lat": 51.15836795030467,
        "lon": 2.736868683313011
    },
    "record_number": 2,
    "time": 1696421607569
},
{
    "classification": "GCS",
    "identification": "GCS Description",
    "alarm": {
        "active": true,
        "certainty": 1
    },
    "location": {
        "$type": "Position3d",
        "height_amsl": 9,
        "lat": 51.157409,
        "lon": 2.740082
    },
    "record_number": 3,
    "time": 1696421411207
},
...
1

detection set or track (members of detectionor tracks, respectively).

Visualizing data

Data in the COURAGEOUS format can be visualized using Google Earth Pro using track2kml.

track2kml is a commandline application that converts COURAGEOUS JSON files into KML.

More information on track2kml can be found writing track2kml --help.

Executing track2kml on any of the following examples:

Gives the following KML files (On version 0.4.2):

Which when viewed on Google Earth appears as such:

alt text Basic example

alt text Intercepting C-UAS example

alt text

KML file organization on Google Earth.