CPDLC: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(Post-Hackathon PoV)
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
'''Controller-pilot data link communication''' (CPDLC) is a direct connection between ATC and aircraft through which controllers can communicate with pilots based on text, thereby relieving radio traffic. Its use is increasing everywhere in real life, while no aircraft is equipped in FlightGear yet.
{{WIP}}


If taken up in the [[Virtual_FSWeekend_Hackathon_2020|2020 Hackathon]], this feature missing today could become available quite soon, as no serious core change seems necessary, at least for first versions to start working.
'''Controller-pilot data link communication''' (CPDLC) is a direct connection between ATC and aircraft through which pilots and controllers can communicate based on text, thereby relieving radio traffic.
Its use is increasing everywhere in real life, and an extension to FlightGear is currently under development to support it in the multi-player environment.


== Recent efforts ==
== Status in FlightGear multi-player ==
This would not start from scratch. Recent efforts have already taken place towards making it possible:
Recent efforts have already taken place towards making it possible:
* [[ATC-pie]] already integrates CPDLC: it is working for other session types (e.g. solo), and an IRC-based (simple text) infrastructure for FG sessions is already in place, including transfers between data authorities, etc. (all it needs now is to be contacted by aircraft!);
* the [[Virtual FSWeekend Hackathon 2020]] attracted a team to work on the CPDLC proposal, and significant progress was made (see [[#Hackathon 2020 results]]);
* work is currently in progress on a cockpit CPDLC panel;
* work is currently in progress on a cockpit CPDLC panel;
* a CPDLC middleware is under dev, required at this point because FG models cannot open their own TCP connections.
* [[ATC-pie]], an ATC client able to join FG networks, already integrates a working service for when the first ACFT are equipped (use of a demo dialog in the mean time).


== Issues/ideas ==
== Hackathon 2020 results ==
We have a proof of concept up and running :)
[[File:Cpdlc-demo.png|thumb|CPDLC demo dialg]]
 
* Basic IRC protocol has been implemented in C++
* Some dummy CPDLC messages have been successfully passed around
* CPDLC connect/disconnect works, handover to othe ATS unit works
* Inbound CPDLC messages are processed and queued for later display in the cockpit
* A simple PUI dialog interface is available in FGAddon
 
== Hackathon run-up (historical) ==
The following sections are kept here for the record as they are still recent. They contain speculation and technical aspects discussed before the Hackathon event, and wrong information.
 
=== Issues/ideas ===
The following could be done in the hackathon:
The following could be done in the hackathon:
* write the Nasal to exchange the right data with the outside system;
* write the Nasal to exchange the right data with the outside system;
* write the IRC hook to connect FlightGear to IRC (not least a generic capability, that other applications may use)
* involving core dev's at least for the design choice, a way to get rid of the middleware eventually, e.g. allow Nasal connections to FG-approved servers (like irc.flightgear.org) or integrate specific accesses in the C++ code base (sort of the same history as FGCom, going from standalone executables to an option in the FG menu)?
* involving core dev's at least for the design choice, a way to get rid of the middleware eventually, e.g. allow Nasal connections to FG-approved servers (like irc.flightgear.org) or integrate specific accesses in the C++ code base (sort of the same history as FGCom, going from standalone executables to an option in the FG menu)?
* can someone create a sketch of a block diagram of the elements that need to communicate and the connections between them? -- p callahan
* can someone create a sketch of a block diagram of the elements that need to communicate and the connections between them? -- p callahan Done -- J Redpath
 
[[File:CPDLC Block.png|thumb|Block diagram for CPDLC subsystem]]
The block diagram describes how such a system might operate. The crucial elements are the IRC Hook and the FlightGear API. These are what the aircraft / ATC talk to directly, and therefore where input and output occur.
 
The IRC hook will require elements such as:
* Connection
* Respond to PING
* Disconnection
* Transmit and receive PRIVMSG to a specified UID
* Error handling - if UID does not exist, if server disconnects, if ...
 
The FlightGear API will require elements such as:
* Connection
* Disconnection
* Transmit + receive message element (including message history as a vector)
 
One option is to have a
/sim/network/cpcdlc/received/
message
sender
status
.. etc ….
 
and then an additional
 
/sim/network/cpcdlc/signals/message-received
 
Then in C++ you fill in all the ‘received’ values from your socket callback, and fire value changed on the signal property. This will allow a Nasal listener to process the received data.
 
For message history, you could either have multiple received nodes (e.g. received[0], [1], [2]) or else a Nasal hook that accesses a vector.
 
For transmitted messages, a similar scheme would work; however, what would probably be better would be:
 
<tt>fgcommand(‘cpcdlc-transmit’, props.Node.new({‘receient’:’blah’, ‘mesage’:’foobarzot’,<etc, etc>});</tt>
 
We’d use the same to establish the connection:
 
<tt>fgcommand(‘cpcdlc-connect’, props.Node.new({
’server’: “foo.bar.com’,
‘port’ : 666,
‘callsign’ : ‘wibble’,
<etc, etc?
‘recv-path’ : ‘/sim/network/cpcdlc/received’,
‘recv-signal’ : /sim/network/cpcdlc/signals/received'
});</tt>
 
=== Available ATC-pie IRC scheme ===
When connected to an IRC server, e.g. <code>irc.flightgear.org</code>, ATC-pie features an integrated text chat system for ATCs to coordinate off the (public) FG text chat. The choice of IRC and plain text lines was in part motivated by the possibility for users of other clients (e.g. OpenRadar) still to take part via their own IRC client.
 
The connection is also used to embed special commands, in the form of escaped text lines, starting with <code>___ATC-pie___ </code>, e.g. for strip exchange (handovers) or "who-has" requests. Commands were later added to support CPDLC, which is ready for ACFT to connect. What follows is a description of those CPDLC-related commands.
 
Note that the IRC nicknames are assumed to match the FGMS network callsigns, so the first line sent after connection is always:
:<code>NICK <callsign>\r\n</code>
Then, from an ACFT point of view, every CPDLC command is sent to the current (or requested) data authority (ATC) via an escaped chat message line:
:<code>PRIVMSG <atc> :___ATC-pie___ <command_line>\r\n</code>
 
Command lines that an aircraft can send to an ATC are:
* <code>CPDLC_CONNECT</code>: attempt log-on
* <code>CPDLC_MSG <msg_contents></code>: connected CPDLC dialogue message (see below)
* <code>CPDLC_DISCONNECT</code>: connection shut down
 
Command lines that an aircraft can receive from an ATC are:
* <code>CPDLC_CONNECT</code>: accepted log-on, or new data authority (link has been transferred)
* <code>CPDLC_MSG <msg_contents></code>: connected CPDLC dialogue msg (see below)
* <code>CPDLC_DISCONNECT</code>: connection voluntarily dropped by ATC, or refused log-on
 
The contents of connected dialogue messages (contained in CPDLC_MSG lines) can be discussed as part of the interface between aircraft and ATC-pie, but for the moment they are of either format below:
* <code>REQUEST <display_text>(<sep_char><encoded_instruction>)*</code>: likely answered with an INSTR msg
* <code>INSTR <display_text>(<sep_char><encoded_instruction>)*</code>: never sent by ACFT, only received
* <code>ACK</code>: acknowledgement/"WILCO"
* <code>REJECT <optional_reason></code>
* <code>TEXT <free_text></code>


[[Category:Hackathon 2020 Ideas]]
[[Category:Hackathon 2020 Ideas]]

Revision as of 00:27, 21 November 2020

WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.

Controller-pilot data link communication (CPDLC) is a direct connection between ATC and aircraft through which pilots and controllers can communicate based on text, thereby relieving radio traffic. Its use is increasing everywhere in real life, and an extension to FlightGear is currently under development to support it in the multi-player environment.

Status in FlightGear multi-player

Recent efforts have already taken place towards making it possible:

  • the Virtual FSWeekend Hackathon 2020 attracted a team to work on the CPDLC proposal, and significant progress was made (see #Hackathon 2020 results);
  • work is currently in progress on a cockpit CPDLC panel;
  • ATC-pie, an ATC client able to join FG networks, already integrates a working service for when the first ACFT are equipped (use of a demo dialog in the mean time).

Hackathon 2020 results

We have a proof of concept up and running :)

CPDLC demo dialg
  • Basic IRC protocol has been implemented in C++
  • Some dummy CPDLC messages have been successfully passed around
  • CPDLC connect/disconnect works, handover to othe ATS unit works
  • Inbound CPDLC messages are processed and queued for later display in the cockpit
  • A simple PUI dialog interface is available in FGAddon

Hackathon run-up (historical)

The following sections are kept here for the record as they are still recent. They contain speculation and technical aspects discussed before the Hackathon event, and wrong information.

Issues/ideas

The following could be done in the hackathon:

  • write the Nasal to exchange the right data with the outside system;
  • write the IRC hook to connect FlightGear to IRC (not least a generic capability, that other applications may use)
  • involving core dev's at least for the design choice, a way to get rid of the middleware eventually, e.g. allow Nasal connections to FG-approved servers (like irc.flightgear.org) or integrate specific accesses in the C++ code base (sort of the same history as FGCom, going from standalone executables to an option in the FG menu)?
  • can someone create a sketch of a block diagram of the elements that need to communicate and the connections between them? -- p callahan Done -- J Redpath
Block diagram for CPDLC subsystem

The block diagram describes how such a system might operate. The crucial elements are the IRC Hook and the FlightGear API. These are what the aircraft / ATC talk to directly, and therefore where input and output occur.

The IRC hook will require elements such as:

  • Connection
  • Respond to PING
  • Disconnection
  • Transmit and receive PRIVMSG to a specified UID
  • Error handling - if UID does not exist, if server disconnects, if ...

The FlightGear API will require elements such as:

  • Connection
  • Disconnection
  • Transmit + receive message element (including message history as a vector)

One option is to have a /sim/network/cpcdlc/received/ message sender status .. etc ….

and then an additional

/sim/network/cpcdlc/signals/message-received

Then in C++ you fill in all the ‘received’ values from your socket callback, and fire value changed on the signal property. This will allow a Nasal listener to process the received data.

For message history, you could either have multiple received nodes (e.g. received[0], [1], [2]) or else a Nasal hook that accesses a vector.

For transmitted messages, a similar scheme would work; however, what would probably be better would be:

fgcommand(‘cpcdlc-transmit’, props.Node.new({‘receient’:’blah’, ‘mesage’:’foobarzot’,<etc, etc>});

We’d use the same to establish the connection:

fgcommand(‘cpcdlc-connect’, props.Node.new({ ’server’: “foo.bar.com’, ‘port’ : 666, ‘callsign’ : ‘wibble’, <etc, etc? ‘recv-path’ : ‘/sim/network/cpcdlc/received’, ‘recv-signal’ : /sim/network/cpcdlc/signals/received' });

Available ATC-pie IRC scheme

When connected to an IRC server, e.g. irc.flightgear.org, ATC-pie features an integrated text chat system for ATCs to coordinate off the (public) FG text chat. The choice of IRC and plain text lines was in part motivated by the possibility for users of other clients (e.g. OpenRadar) still to take part via their own IRC client.

The connection is also used to embed special commands, in the form of escaped text lines, starting with ___ATC-pie___ , e.g. for strip exchange (handovers) or "who-has" requests. Commands were later added to support CPDLC, which is ready for ACFT to connect. What follows is a description of those CPDLC-related commands.

Note that the IRC nicknames are assumed to match the FGMS network callsigns, so the first line sent after connection is always:

NICK <callsign>\r\n

Then, from an ACFT point of view, every CPDLC command is sent to the current (or requested) data authority (ATC) via an escaped chat message line:

PRIVMSG <atc> :___ATC-pie___ <command_line>\r\n

Command lines that an aircraft can send to an ATC are:

  • CPDLC_CONNECT: attempt log-on
  • CPDLC_MSG <msg_contents>: connected CPDLC dialogue message (see below)
  • CPDLC_DISCONNECT: connection shut down

Command lines that an aircraft can receive from an ATC are:

  • CPDLC_CONNECT: accepted log-on, or new data authority (link has been transferred)
  • CPDLC_MSG <msg_contents>: connected CPDLC dialogue msg (see below)
  • CPDLC_DISCONNECT: connection voluntarily dropped by ATC, or refused log-on

The contents of connected dialogue messages (contained in CPDLC_MSG lines) can be discussed as part of the interface between aircraft and ATC-pie, but for the moment they are of either format below:

  • REQUEST <display_text>(<sep_char><encoded_instruction>)*: likely answered with an INSTR msg
  • INSTR <display_text>(<sep_char><encoded_instruction>)*: never sent by ACFT, only received
  • ACK: acknowledgement/"WILCO"
  • REJECT <optional_reason>
  • TEXT <free_text>