The DCDU and the ATC MSG Pushbutton

Of the three cockpit interfaces (article 1) — MCDU builds/manages/edits, DCDU reads/answers, ATC MSG pb reminds — the applications of the earlier articles (CPDLC/DCL/OCL) all land on the DCDU to "read one, answer one". This article covers the DCDU in full: the new-message reminder (ATC MSG pb), the default screen, the message-area colour language, and most importantly the answer keys (WILCO/UNABLE/STBY…) and function keys (LOAD/MODIFY/CLOSE…).

1. The ATC MSG pushbutton — new-message reminder

A new message flashes the ATC MSG pb with an audio alert. Per FCOM DSC-46-10-40-10:

Flashes when a datalink message from the ATC center is received, or a reminder message (linked to a deferred clearance or a report request) is received. When a message is received, the DCDU automatically displays the message on the screen if no other message is already displayed. [...] When the flight crew presses one of the two ATC MSG pbs or a key on the DCDU, the ATC MSG lights go off and the aural alert [...] is cancelled.

Handling during take-off and landing. Per FCOM DSC-46-10-40-10:

ATC alerts are inhibited during the takeoff and landing phases. If the aircraft receives a message during the inhibition period, the ATC center is automatically warned of the uplink message rejection (except for A623 application messages).

[!warning]- A CPDLC message received during take-off/landing is "auto-rejected" Take-off and landing are the busiest, least-interruptible phases (the same critical-phase-silence design as SELCAL and cabin calls, ATA-23), so ATC alerts are inhibited. But datalink differs from voice: a message received during the inhibition is automatically answered to ATC as "rejected" — the controller knows you did not receive it and will use voice or re-send later. A623 (DCL/OCL/D-ATIS) messages are the exception (not auto-rejected). So during take-off/landing do not rely on CPDLC — use voice where voice is needed.

2. The DCDU default screen

Black when not connected; when connected with no message, it shows the connection summary. Per FCOM DSC-46-10-40-20:

[...] the DCDU displays: ACTIVE ATC and the active ATC ICAO code; NEXT ATC and the next ATC ICAO code [...]; ADS-C status, when the ADS-C is set to OFF; ADS-C CONNECTED (X), if an ADS-Contract is established [...] (X): Displays the number of ADS-C active connections; NO ATC DLK/ATC DISCONNECTED, when the datalink connection is lost.

A glance at the default screen tells you who is working you (active), who is next, how many centres watch you over ADS, and whether the connection is up.

3. The message-area colour language

The DCDU colour-codes message state — worth memorising. Per FCOM DSC-46-10-40-20:

Uplink messages are displayed on a black background, and: When received, the message appears in white and the main parameters in cyan. When answered, the message becomes green. When monitored, a parameter appears in magenta (This indicates that the FMGES monitors this parameter). If the monitoring fails, this parameters become amber. When the value is attained, this parameter becomes green. If the loading of the clearance in the secondary flight plan fails, parameters appear in amber. Downlink messages appear in black: On a cyan background before sending; On a green background while and after sending.

[!note]- Colour crib: white = new, green = answered/attained, magenta = monitored, amber = failed Uplink: white (just received) → green (answered); a parameter: magenta (FMS is watching) → green (attained) / amber (monitoring or loading failed). Downlink: cyan background (not yet sent) → green background (sent). One glance at the colour tells you where each message stands — green = done, amber = a problem to watch.

4. Answer keys — WILCO / UNABLE / ROGER / STBY / AFFIRM / NEGATV

This is the "how to answer an ATC message" deferred from article 3. The DCDU message status changes with the answer (per the FCOM DSC-46-10-40-20 MESSAGE STATUS section, each verbatim):

For example, per FCOM DSC-46-10-40-20:

The status of the message changes to WILCO, when the flight crew selects WILCO, in order to inform the ATC center that they understood the request and that they will comply with it.

For departure/oceanic clearances there are ACK/REFUSE, and REFUSE has a trap. Per FCOM DSC-46-10-40-20:

REFUSE — [...] to refuse a departure/oceanic clearance. The message CONTACT ATC BY VOICE - REFUSE NOT SUPPORTED - BY DATALINK appears [...] to inform the flight crew that they must use voice radio communication to refuse the clearance.

[!warning]- You can accept a clearance by datalink, but you must refuse it by voice You may acknowledge (ACK) a DCL/OCL clearance by datalink, but you cannot refuse (REFUSE) it by datalink — pressing REFUSE prompts CONTACT ATC BY VOICE. Why? Refusing a clearance usually means a problem or a negotiation, and that clarification is beyond datalink (a concrete case of article 1's "revert to voice on doubt"). Remember: a clearance can be accepted by datalink; refusal must be by voice.

5. Function keys — LOAD / MODIFY / CLOSE / RECALL / SEND

The DCDU function keys are auto-assigned by message type. The key ones (per FCOM DSC-46-10-40-20 FUNCTION KEYS, each verbatim):

• LOAD — loads an ATC flight plan or a parameter time-constraint into the secondary flight plan (like the article-7 AOC re-route: load the secondary, not the active);
• MODIFY — opens the MESSAGE MODIFY or POSITION REPORT page on the MCDU to edit an FMGES-proposed message (articles 3–4);
• CLOSE — erases a sent/answered message from the DCDU and stores it in the MSG RECORD (article 9); not available while an answer is on STBY;
• RECALL — recalls the most recently closed message if closed within the last 5 min; otherwise RECALL EMPTY / CONSULT MSG RECORD;
• SEND — sends a message or answer prepared with the other function keys (WILCO/ROGER/AFFIRM/STBY…).

[!note]- Answering is a two-step "prepare then send" The DCDU does not fire the moment you press WILCO — it is select (prepare) WILCO, then press SEND — a two-step giving you a review window. LOAD/MODIFY stitch datalink to the FMS: an ATC-uplinked route is loaded into the secondary flight plan, and edited via MODIFY on the MCDU. CLOSE files a finished message into the MSG RECORD, recallable within 5 minutes.

Self-test

[!note]- Q1. When does the ATC MSG pb flash, how is it cancelled, and why is a message received during take-off/landing "auto-rejected"? Any exception? On a new datalink or reminder message; pressing an ATC MSG pb or DCDU key cancels it. During inhibition (take-off/landing) a received message is auto-answered to ATC as rejected; A623 messages are the exception.

[!note]- Q2. What does the DCDU default screen show? Active ATC, next ATC, ADS-C status/connected count, and NO ATC DLK when the connection is lost.

[!note]- Q3. What do uplink white→green and a magenta parameter mean? Downlink cyan→green background? Uplink: white (received) → green (answered); magenta = FMS-monitored → green (attained)/amber (failed). Downlink: cyan (not sent) → green (sent).

[!note]- Q4. What do WILCO/UNABLE/ROGER/STBY mean, and what is OPEN? WILCO: will comply; UNABLE: cannot comply; ROGER: received/understood; STBY: need time. OPEN: the message requires a response and stays until answered.

[!note]- Q5. Why can a DCL/OCL be accepted (ACK) by datalink but not refused (REFUSE)? Refusal usually needs clarification/negotiation beyond datalink; REFUSE prompts CONTACT ATC BY VOICE.

[!note]- Q6. What do LOAD, MODIFY, CLOSE, RECALL do, and what is the "two-step" answer? LOAD → secondary flight plan; MODIFY → MCDU edit; CLOSE → store in MSG RECORD; RECALL → last closed within 5 min. Answering is prepare (select) then SEND.

Key takeaways

References

• FCOM DSC-46-10-40-10 — ATC MSG pb flash/cancel, take-off/landing inhibit and auto-rejection (A623 exception).
• FCOM DSC-46-10-40-20 — DCDU default screen, message-area colours, answer keys (message status), ACK/REFUSE (refuse by voice), function keys (LOAD→secondary FPLN / MODIFY / CLOSE→MSG RECORD / RECALL 5 min / SEND).

Independent study material, not an Airbus publication and not endorsed by the manufacturer. Always defer to the current operator FCOM, FCTM, and QRH for operational use.