守護天空的隱形人

許可頒發進入數位時代.... 
玩過"ぼくは航空管制官"系列的朋友應該都對於離場航機出發前的"出發承認"感到非常頭大吧！ 每一架IFR離場的飛機在開車後推前，必須要向塔台申請儀器飛航許可(其實也就是PDC，但是PDC在飛行員中比較常指令一個意涵，後面會提到)，塔台必須依照該機場的相關流程申請並頒發。 最複雜的標準程序是由塔台先向巡航高度的單位申請航路許可，該單位確認高度可用之後，轉頒給相關起飛機場的近場台，然後近場台加上離場程序和起飛初始高度限制後頒發給塔台，再由塔台頒發給飛行員，而且要確認整個覆誦是正確的，有時申請和頒發外加糾正飛行員，整個頒發過程可能要耗時5分鐘以上。

這個繁複的程序在許多機場都會經過簡化，但是最後使用語音頒發時，仍然非常會花超過2分鐘的時間，
大家可以參考下面嵌入的影片聽聽看許可頒發時，每一架飛機要給予多少的資料。




隨著時代進步，在部分國家運用了無線電數據傳輸的方式，使用PRE DEPARTURE CLEARANCE(這是飛行員比較常提到的PDC的意思)相關裝備來頒發文字許可給飛行員。 Ming本身並未對詳細的背後工作方式深做研究，但是從我看過的資料，PDC乃是透過航空公司的ACARS系統，經過航空公司自己的電腦傳送到塔台並回傳到該電腦後，再透過ACARS傳送到飛機上。 也就是飛行員和管制員並非直接連結的。

而現在世界上則慢慢推行另一種直接以數據鏈路連結飛行員和管制員的許可頒發系統- Data Link Departure clearance，簡稱DCL，雖然中間仍需要透過類似網路服務提供者的數據傳輸服務(如大家常知的SITA)，但飛行員是直接和航管系統連結的。

台北飛航情報區飛航指南的航空公報(AIC)01/2014上有詳細寫著完整的過程，但事實上管制員跟飛行員都是各自在各自的電腦或飛航管理系統上操作的。 下面跟大家簡介塔台DCL的流程

AIC描述的流程：

a.航機下傳RCD

範例

RCD ABC123-RCTP-GATE A5-VHHH ATIS A -TYP/B744 -RMK/R340 (註)

註：駕駛員可依需求於此欄位輸入申請高度「Rxxx」

b.飛航管理系統自動上傳FSM

範例

FSM ABC123 RCD RECEIVED REQUEST BEING PROCESSED STANDBY

在這個流程後，塔台會在螢幕上看到航機的申請 (但圖中COOR的位置會顯示 PREA，此為飛行計畫生命周期的代號，這裡就不詳述了)：

這時候管制員就可以從航機呼號點開下面的視窗，並且輸入相關的資料許可。
RCD recieved就是來自飛行員的。
接著ATC就要再CLD composition中去編輯要給飛行員的資料。
其實裡面的許多資料是跟電子管制條連動的，例如SID、跑道、跟雷達識別碼。
而航管可以手動編輯的就是圖中看到淺色字的 NEXT FREQ，也就是要飛行員下一個跟誰連絡，通常是地面管制席，但也可能因為流量管制中，需要安排順序，而會請飛行員跟許可頒發席報到加入排序行列。
ATIS則是輸入現在最新的ATIS編號
RMK則依照AIC所說明的輸入SID後的航路跟保持高度，這些都是選單式的，但也可以自行鍵入需要的其他資料。
完成後就按下send message
如果ATC因為有任何問題需要飛行員以口頭申請，則會使用R/T，這時候系統就會踢退這筆資料，而這是一個不可回復的動作。 也就是下次開始飛行員都要用口頭來申請許可了。

而航管螢幕在最上面DCL LIST WINDOW看到的列表就會出現 －＞　的箭頭，表示傳送中。
成功送達飛機的系統並獲得飛行員確認後，也會回傳航管系統，接著就是這個流程

e.飛航管理系統自動上傳FSM

範例

FSM ABC123 CDA RECEIVED CLEARANCE CONFIRMED

而這時候，螢幕上就會顯示勾勾，表示整個流程成功了。