BARNARD MICROSYSTEMS LIMITED

helping you keep an eye on things...

unmanned air ...

issues

Unmanned Aircraft Command and Control

- from 1033_paparazzi.pdf

• BLOS Unmanned Aircraft control
• Bandwidth required for UA operations
• Example of a UAS Status Message Syntax
• Status message size
• UA Message Syntax and STANAG 4586 (+ download)
• Flight Plan Language

In the command and control system shown next for use on small Unmanned Aircraft, several important features are supported:

• we use a 9,600 bps, duplex, satellite link which can be implemented using a small, light, relatively inexpensive satellite phone modem. This link is used for the duration of the flight. See comms BLOS.
• Air Traffic Control (ATC) messages picked up on the VHF frequency band are digitally encoded, for example, using the Code Excited Linear Prediction (CELP) algorithm at 4,800 bps and are switched by SW1 in the diagram below to the multiplexer, which combines the FEC coded status message data with the digitised ATC voice and sends this information to the satellite modem for transmission to the satellite. SW1 is controlled by the Received Signal Strength Indicator (RSSI) from the VHF receiver, so the switching of Tx CH B from video line scan data to ATC voice data is immediate on detection of voice data.
• In the absence of any ATC voice data, SW1 switches in video line scan data at 4.8 kbps (600 pixels x 8 bit mono imagery) derived from a 640 x 480 pixel imaging array. One line is sent every second to enable the Ground Control Station (GCS) to build up a strip map showing the progress of the UA.
• On the uplink from the GCS to the Unmanned Aircraft, 4,800 bps of the 9,600 bps duplex data rate is used for direct UA control, which might be in response to an ATC request or order. In order to make it more difficult for an unauthorised person to gain control of the UA, this data is encrypted with a lossless encryption algorithm, and then coded with Forward Error Correction (FEC)  at the GCS, so FEC decoding followed by decryption must be applied in the Unmanned Aircraft receiver.
• a unique, contiguous, message number + GPS synchronised, UTC time + date must be included in each uploaded flight plan update message, in each UA remote control message and in each UA status message download to avoid what is referred to as a "spoofing" attack in which a copy of an earlier message is inadvertently, or deliberately, transmitted to the UA, or, to the GCS.
• SW2 is used to switch the Channel B data received between digital-to-analog conversion of the digitally encoded voice data reply to the ATC and the flight plan update system. The control of SW2 is both by the VHF Receiver and by the Aircraft Remote Control, with the Aircraft Remote Control having priority.
• Again, to make it more difficult for an unauthorised person to gain control of the Unmanned Aircraft, the flight plan update information is both encrypted with Forward Error Correction applied at the GCS, with FEC decoding being applied on the UA to retrieve the original data.
• One of the advantages of applying FEC to both the status messages from the UA to the GCS and the flight update plans and the UA remote control commands from the GCS to the UA is that the Bit Error Rate of the duplex communications link can be continuously monitored by tracking the number of errors detected by the FEC data processing.

• See the Status Message section for details on the Unmanned Aircraft Status Message format.
• See the Remote Control Message section for details on the Unmanned Aircraft Remote Control message format.

Diagrammatic view of the duplex, 9,600 bps, communication channel

In summary, the single 9,600 bps duplex channel is used to:

• relay voice communications from FIS-B to the GCS
• relay duplex voice communications to and from the Tower, an ATC_1 centre and an adjacent ATC-2 centre;
• support the download of progressive line scan imagery when voice channel 1 relay is not in use
• support the download of Unmanned Aircraft status messages sent from the UA to the GCS at a rate of 1 message per second
• support the upload of UA configuration control commands and flight plan change commands
• support the remote control of the Unmanned Aircraft from the GCS

The Rx signal summing, Tx signal switching, section

The Rx and Tx data multiplexing, front-end, section

return to top

- from http://www.caa.gov.au/pilotcentre/projects/vhf25khz/Discussion_paper_25_kHz_channel.pdf

• We have demonstrated that the Unmanned Aircraft Status Message can be less than 4,800 bits in size. We envisage an always-ON link over which one status message per second is sent from the Unmanned Aircraft to the Ground Control station.
• We sum the three voice channels picked up by the three VHF receivers on the Unmanned Aircraft and then digitise (for example, using the CELP algorithm) the resultant voice signals to a 4,800 bps data stream. The voice channels correspond to:

TOWER or FIS-B (Flight Information Service - Broadcast)

ATC_1 centre = an arbitrary ATC centre

ATC_2 centre = an adjacent ATC centre

• We need to be able to transmit three channels (forward left, forward and forward right) of video information when the Unmanned Aircraft is on the ground to enable the remote pilot to steer the Unmanned Aircraft on the runway, and avoid all obstacles (including other aircraft). The video cameras need to convey at least the same visual information as seen by a real pilot, that is +/- 115 degrees azimuth and +/- 15 degrees in elevation. Hence the need to use three cameras. These same three cameras can be used by an on-board sense and avoid system, although the video signals will not be transmitted back to the GCS once the Unmanned Aircraft is in the air due to the extreme bandwdth requirements for such a transmission.

return to top

We assume the use of an efficient modulation scheme, such as GMSK or QPSK to achieve a modulation efficiency in excess of 1 bit/s/Hz:

The suggested bandwidth requirement for each Unmanned Aircraft is shown next.

• remote control = Unmanned Aircraft remote control, typically on take-off, landing and in an emergency
• FPU = Unmanned Aircraft Flight Plan update

So, from the above, one can support the Command and Control communications (apart from the video data required at take-off and landing, including emergency landing)  for 80 Unmanned Aircraft per MHz of bandwidth. Since one might like to use a LOS link to an aircraft at Flight Level 600 (= 60,000 ft = 18.3 km) one would define a LOS distance of at least 20 km.

Since the video transmission will only occur when the aircraft is moving relatively slowly at take-off and landing, one could use the high fidelity COFDM modulation format as used in DVB-T (Digital Video Broadcasting-Terrestrial) which has a bandwidth of 8 MHz (actually, 7.61 MHz + guard band). This modulation scheme is sensitive to Doppler shift, and degrades when the speed difference between the transmitter and the receiver exceeds 185 kph.

The license free, 5.8 GHz Industrial, Scientific and Medical ("ISM") band, is a large, contiguous, 125 MHz band stretching from 5,725 MHz to 5,850 MHz. It appears that manufacturers have selected bands in the 5.8 GHz ISM band to suit their communication system technology. One could support up to 5 Unmanned Aircraft, each using three video channels, in the ISM band at 5.8 GHz.

return to top

In the Beyond-Line-Of-Sight situation, the Status Messages and the digitised Tower, ATC_1 and ATC_2 data is send using a modem via a satellite link with a GSM back-up link. Again, as in the LOS situation, we will assume the use of an efficient modulation scheme, such as GMSK or QPSK to achieve a modulation efficiency in excess of 1 bit/s/Hz.

Again, as in the LOS case, one can support the Command and Control communications (apart from the video data required at take-off and landing, including emergency landing)  for 80 Unmanned Aircraft per MHz of bandwidth. However, in this BLOS case, the number of Unmanned Aircraft that need to be supported are those that will fall within the antenna footprint of the satellite.

For the video data transmission via a satellite link, we have suggested the use of MPEG-2 video compression in which a 720 x 480 pixel frame at a rate of 30 frames per second requires a bit rate of about 4 Mbps. Again we assume the use of an efficient modulation scheme, such as QPSK, GMSK or better, to achieve 1 b/s/Hz or better. This will allow each MPEG-2 video channel to be squeezed into a 4 MHz band, including guard band.

It is suggested that the amount of satellite bandwidth required for video data transmission required during take-off and landing, including emergency landings, is 4 + n x 4 MHz, where n = the number of Unmanned Aircraft taking off and landing within the antenna footprint of the satellite. 

return to top

Here is the message syntax used at Barnard Microsystems for the status message transmitted at regular intervals from the Unmanned Aircraft to the Ground Control Station via a GSM modem or satellite phone modem based Beyond-Line-Of-Sight ("BLOS") communications link. See comms BLOS .

The compact binary implementation of this format is shown in the Status Message section.

• The status message consists of a set of data blocks, each block beginning with the BEGIN keyword SectionName, and ending with an END keyword.
• The data items are listed between the BEGIN and END keywords.

• A comment can be included after the exclamation mark.
• A sub-section can be nested within a section, with the sub-section also starting with a BEGIN SubSectionName and ending with an END keyword.

• Section names can be added, or omitted.

The main section names are as follows:

By way of example, here are some example sections. We start with the HEADER Section.

The IMU Section

The GPS Section

The Aircraft Sense Section

return to top

Although a 9.6 kbps BLOS sat comms link is used, both the transmit and the receive paths are divided into two equal data rate channels A and B, each operating at 4.8 kbps. A 9.6 kbps duplex data link represents a small, lightweight, relatively inexpensive solution for an always-ON satellite based data link between the Unmanned Aircraft and a distant Ground Control Station. This link is operational even when the Unmanned Aircraft is beyond the line of sight of staff at the GCS.

We send a status message from the UA to the GCS every second, corresponding to the GPS data update rate. The transmitted message size is 4,800 bits. The status message data is Forward Error Correction encoded using the standard Reed Solomon RS(255,223) format, in which 223 bytes of message data are supplimented with 32 bytes of FEC information to make up a 255 byte data block. We can fit 2 such data blocks in our 4,800 bit maximum message size, with 720 bits to spare. The 720 bits = 90 Bytes are used for the Payload status information, since this information is not considered "mission critical". This payload information section included a 4 Byte checksum, but is not FEC encoded to enable the detection of a transmission error in this section, but not the correction of any errors.

A typical message length in plain text form, as shown above, is 3,600 text characters, where each character is represented by a Byte. This message size dramatically exceeds our above mentioned limit. In order to compress the information, we use a binary format. For a small Unmanned Aircraft, the status message consists of:

• two blocks of 223 Bytes of binary data each. Each block is then FEC encoded using RS(255,223) to become 255 Bytes in size.
• we can transmit important information in each message (such as GPS location, bearing), with other information (such as battery voltage), being reported less frequently. To ensure correct interpretation of the different message data set formats, we identify a Data_Set_ID in the header of each message.
• each data item starts with a one byte Status_Item_ID (= B0) followed by the Status_Item_Value, which can be 8 bits (B1), 16 bits (B1:B2), 24 bits (B1:B2:B3) or 32 bits (B1:B2:B3:B4) in length.
• a maximum of 256 types of Status_Item_ID
• Byte numbering is as follows: B0:B1:B2:B3:B4

See the Status Message section for the binary message syntax, and details on the message size.

return to top

Commonalities

• ...the philosophy for developing the message types in the DLI shall be to use metric (SI, ISO 1000:1992) units wherever possible. - STANAG 4586
• All times shall be represented in Universal Time Coordinated (UTC) in seconds since Jan 1, 1970 ... - STANAG 4586
• ID numbers are represented as individual hexadecimal bytes separated by colons (e.g., 10:4E:F3:06).
• STANAG 4609 specifies a standard compression (MPEG-2) and means to capture metadata describing digital motion imagery.

Differences

This section outlines the differences between the Small Unmanned Aircraft Message Syntax and that in STANAG 4586.

Download a copy of STANAG 4586

return to top

Here is an example from the Paparazzi Project, from 1033_paparazzi.pdf. Note the use of the XML Format.

return to top

© Barnard Microsystems Limited 2006 - 2008