川大主用ATC系統維護筆記(八)
1、這裡顯示的選擇高度,和用於SFL告警的SelectedAltitude發現有時候是來自ADS-B的,有時候是來自S模式雷達(精度更高)的,需要改成只要S模式雷達有采用S模式雷達的,只有在S模式雷達沒有該值時,才用來自ADS-B的。因為發現有的機型(川航A320)來自ADS-B的和來自S模式雷達的SelectedAltitude值不一樣,有時差30多米(3600-3566=34米),管制是以S模式雷達為準。
2、2021年5月16號升級後fdoagent主備程式幾乎每天后半夜分別異常退出,並自動重啟,且不產生core檔案。gdb ./fdoagent.linux跟蹤發現有個處理字串複製函式有些不太好,最佳化了一下,另外其它傳送網路包的地方也最佳化了一下, 6月2號更換後OK。
3、自動分配SSR限制ZGSZ問題:完善fdp.linux,限制落地機場,排在第一個的能限制,後面由於程式邏輯問題限制未生效。已解決。fdp.linux:MD5: 502346C4F24873E65A6C6DD54C53DBE1
4、用"mii-tool -v bond0"命令檢視到bond0的速率是10M,是因為bond0是邏輯裝置用"mii-tool"命令是無法準確輸出其資訊的; 千兆的使用ethtool。( 實驗室FDP-1主機使用WinSCP複製檔案特別 慢(20-300k/s),在vSphere Web Client 關閉Fault Tolerance後正常 (40M/s),另將FT輔助虛擬機器遷移到 與主態同型號CPU<Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz遷移到Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz>主機開始也正常,後測試又不正常了?還得是要關閉FT!)
[root@FDP-1 ~]# mii-tool bond0
bond0: 10 Mbit, half duplex, link ok
[root@FDP-1 ~]# ethtool bond0
Settings for bond0:
Speed: 10000Mb/s
Duplex: Full
Auto-negotiation: off
Link detected: yes
5、gdb除錯
[root@FDP-1 bin]# gdb fdp.linux core.102090
(gdb) bt // backtrace: 檢視函式呼叫資訊(堆疊)
(gdb) f 1 // frame: 檢視棧幀 f n 切換到編號為n的棧
(gdb) p this-> 按2次鍵tab<即補全提示> // print: 列印變數資訊
(gdb) r // run: 執行程式,在斷點處停止
(gdb) q // quit: 退出GDB
6、系統當前執行模式為StandBy時,藍色預啟用標牌,右鍵選擇F-CTL,不會變成管制狀態,當前模式切換為Master後可以。(川大設計如此, 當系統為備用系統模式時,系統不再主動設定控制扇等操作,以主用系統資料為準。)
7、 Receiver錄取程式重啟後,之前記錄的資料就沒了,已改成追加方式:dFile = open(self.filePath+dpath+fn,'ab'),檔案開啟模式a:以只追加可寫模式開啟檔案,並將檔案指標指向檔案尾部;如果檔案不存在則建立;b讀寫二進位制檔案(預設是t,表示文字),需要與上面幾種模式搭配使用,如ab,wb。
8、FUTION(=MRT+ADS MRT)時,sdp.ini檔案的[MARDP]段增加引數SelectedAltRadarKeeping,雷達訊號多少秒鐘未更新SelectedAltitude、SelectedQNH,如果ADS-B的SelectedAltitude或SelectedQNH不為空,以ADS-B的更新。但是對於SFL告警,MRT以從S模式雷達獲取的 SelectedAltitude為準進行告警判斷; ADS MRT以從 ADS-B獲取的 SelectedAltitude為準進行告警判斷;當“ MRT ”或“ADS MRT ”任一有 SFL告警時, FUTION就有 SFL告警(由於 ADS MRT重新整理快,這裡 FUTION實際是以 ADS MRT產生的 SFL告警為準 )。假如實現 FUTION只有在 沒有S模式雷達 SelectedAltitude時,才採用 ADS MRT的 SFL告警,實現時邏輯上會引入其它問題。
9、點跡增加選擇高度、選擇QNH的解析。( 更新rdp/adp)
10、假如計劃邊界點沒有實際過點時間(只有預計過點時間),說明目標繞飛從別的“點”出區域,則增加判斷飛出該“點”5分鐘後才會結束。解決由於雷雨繞飛,出太原管制扇區位置(計劃中顯示為座標點)不在邊界點,該座標點飛行距離邊界點計算達到5分鐘,該目標一出管制區立即去相關的問題。
11、更新fadp/frdp/smpc程式,解決SMPC抑制告警後還變紅問題(抑制的雷達通道不管其狀態的變化)。
12、aidc.ini中[AFTN] [AIDC3]
ATCCode= ZBAA與 AIDCRcvAddress= ZBACADCT 需一致(ATCCode= ZBAC;AIDCRcvAddress= ZBACADCT),否者出現不自動回覆ACP報等問題。
13、系統當前模式:StandBy時,可以進行移交( 包括C移交,可操作,但是狀態不對),TAG/D-TAG,分扇,放大縮小,分配跑道,選擇地圖、危險區、限制區等操作,只是收到從Master態系統來的相關同步資料時會覆蓋修改,即以最近修改為準。另, StandBy時,不會進行計劃的預推“RTE”,接收 Master態的計劃預推資料,假如“不同步計劃時”導致SDD上相關計劃的管制狀態有問題。需增加離線引數,設定為不同步計劃時, StandBy狀態下也進行計劃狀態預推計算。
* 14、收到SITA-PLN-CNL報修改(fdoagent 程式完成) 計劃“狀態”為“取消"( “原則”: SITA報不修改“管制狀態” ,所以就不影響 自動分配SSR,也不會釋放SSR); 收到AFTN-CNL報 修改 (fdp程式完成)“ 管制狀態”為“ CNL”, 管制狀態為“CNL”才會釋放SSR,且不會自動分配SSR。目前假如某航班只收到 SITA-PLN-CNL報,沒有 收到AFTN-CNL報,不會修改 “管制狀態”為 “CNL”,此時,只能在SDD上人工修改(如在FDO上右鍵選單 增加 手動 CNL功能,人為責任?)——這裡需要 重點區 分“ 管制狀態”和 “狀態”的不同 。 fdp程式只有某計劃的 “管制狀態”欄位,沒有“狀態”欄位(所以fdp只能按照”管制狀態“資訊進行SSR分配邏輯判斷) 。
——主要SITA報不是空管部門認可的AFTN報,直接拿來改自動化系統的計劃動態有風險,要是能保證只要有SITA格式的CNL報,就一定有AFTN格式的CNL報,那就不成問題了。
15、 在FDD上 “ 管制狀態 ”為“CNL”或“FIN”狀態的航班計劃還會顯示之前分配的SSR ,只是作為參考(不能作為重複分配SSR的判斷依據),實際此航班這裡顯示的SSR已釋放,也不會再自動分配。
16、SSR自動重複分配2次的問題。
1)fdp程式定期(20-30秒)清理回收SSR功能,檢查處於已分配佔用狀態的SSR,遍歷計劃列表(不含FIN狀態的計劃),如果找不到計劃, 認為SSR分配狀態是Invalid的, 需將該SSR強制置“ Force Release”,並將 Assign count is置為[0],假如原先是 [2],也置為 [0],這裡 還會引起重複分配問題( 只有這個 回收SSR功能函式 才會往日誌記錄 Force...Invalid關鍵字)為未分配狀態,FDP日誌記錄“Force Release Invalid SSR:[A0055]”。
2)動態計劃飛出區域5分鐘後,將計劃置為" FIN"狀態,隨後( 間隔時間 可能達數秒)執行 釋放SSR操作,日誌記錄”Release SSR:[A0055] for Plan:[202107100325CCA4593ZBYCZGGG], Assign count is:[0]“
3)假如在 計劃置為"FIN"狀態,但還沒有執行釋放SSR操作期間,定期清理SSR函式開始 遍歷計劃列表( 不含FIN狀態的計劃),而該計劃此時已經置為“FIN”狀態,找不到計劃,所以認為該SSR狀態是 Invalid的,執行 “ Force Release ”操作“ Force Release Invalid SSR:[A0055]”( 找不到計劃 Invalid 所以 日誌記錄沒有航班號),由於SSR資源緊張,釋放後立即自動分配給另一預啟用狀態的計劃“Set SSR:[A0055] for Plan:[202107100405CGZ7228ZBYNZUYB], Assign count is: [1]”
——然後置為"FIN"狀態的計劃,執行釋放SSR操作“Release SSR:[A0055] for Plan:[202107100325CCA4593ZBYCZGGG], Assign count is: [0]”(這裡 日誌記錄就有航班號 ),這次釋放後也會再次 自動分配給另一預啟用狀態的計劃,這樣導致短期內該SSR同時分配給 2個航班計劃,但在fdp日誌中卻記錄“ Assign count is: [1]”,體現不出分配了2次的問題現狀。
4) 動態計劃飛出區域5分鐘後,如先 執行 釋放SSR 操作,再 將計劃置為" FIN" 狀態,可避免該問題。
17、在FDO上執行過“回收SSR”操作的計劃,再手動 進行 “分配SSR”——“ 自動分配”會提示“ ACCESS_DENIED”(沒有滿足條件的可用SSR也是該提示)。
18、使用電報模糊匹配計劃,採用時間引數(DepTimeRange預設240分鐘在fdp.ini中),限制的電報種類有如下電報:PLN/FPL/DEP/CHG/EST/RTN/COR/CDN/ACP/RQP/RQS/SPL/ALR/OVF/ABI/ADS/MAC/AOC/PAC/REJ/TOC/TRU。
——假如報文中 沒有DOF項,計算 ” FPL/CHG收報日期時分—(當天日期+預起時間)“ 大於2小時,則按照(次日日期+預起時間)模糊匹配計劃,否則按照 (當天日期+預起時間)匹配計劃。對於跨日情況需要注意該處理機制。( 以前CHG報沒有DOF項就按” 當天日期+預起時間“匹配計劃,2021/07/23改為和FPL一致,按如上機制考慮了跨日問題)
19、 SDD席位隨機去相關問題(20210722,20210917):
pTag->ChkNum=30, pTag->EndFlag=0 //校驗未完標誌0
pTag->ChkNum=3, pTag->EndFlag=1 //一輪校驗已完標誌1 , 備態FDP去掉校驗一致的計劃的已校驗標記,以便於進行下一輪校驗)
pTag->EndFlag=1, process normally.
pTag->ChkNum=30, pTag->EndFlag=2 // 一輪校驗已完,重新定位到第一條計劃, 開始下輪校驗標誌2(SDD需要,備態FDP不用)
SDD日誌:
ACC4/5(FDP1[Standby])分別刪除了1190/1172(1221,每次校驗30條檢驗了21次後發了檢驗完成標誌,導致只保留620條計劃,其它大概1200條全刪除了)條計劃,SDD根據
FDP_PLANCHKSUM
誤認為FDP2[Active]上沒有這些計劃。
ACC4:
[SDD:Net] 20210722 11:32:18 Recv FDP_PLAN mid[202107221100CCA8375ZBADZLLL] stat[5] ssr[A3001] atd[1104] ctrlsec[PSEC01] nextsec[] HandCommSec[] CommSec[PSEC01]
[SDD:Net] 20210722 11:32:18 202107220815OTC7314ZGKLZBCZ Already Not Exist In Active_FDP,Delete From StandBy_FDP
......
[SDD:Net] 20210722 11:32:19 202107221540CES2794ZBHHZSCG Already Not Exist In Active_FDP,Delete From StandBy_FDP
[SDD:Net] 20210722 11:32:19 Recv FDP_PLANCHKSUM
ACC5:
[SDD:Net] 20210722 11:32:18 Recv FDP_PLAN mid[202107221100CCA8375ZBADZLLL] stat[5] ssr[A3001] atd[1104] ctrlsec[PSEC01] nextsec[] HandCommSec[] CommSec[PSEC01]
[SDD:Net] 20210722 11:32:19 202107220815OTC7314ZGKLZBCZ Already Not Exist In Active_FDP,Delete From StandBy_FDP
......
[SDD:Net] 20210722 11:32:20 202107221445THY6077RKSILTFM Already Not Exist In Active_FDP,Delete From StandBy_FDP
[SDD:Net] 20210722 11:32:20 Recv FDP_PLANCHKSUM
備態FDP1:
(共21條,之前和之後正常都是62條:62x30-21x30=1210,即刪除了大概1230條)
<Warn>: 20210722113219 Plan:[202107220815OTC7314ZGKLZBCZ] Already Not Exist In Active_FDP,Delete From StandBy_FDP
<Info>: 20210722113219 plan will be deleted ,it's mid is [202107220815OTC7314ZGKLZBCZ]!
<Info>: 20210722113219 Fdoagent will delete the plan , it's mid is [202107220815OTC7314ZGKLZBCZ]!
20、20210727: --------fdp修改內容:
1)、解決SSR重複分配問題;參見16項,釋放SSR和FIN同時完成。(又發現“取消”後沒有立即釋放SSR會出現和 "FIN"狀態沒有執行釋放SSR操作期間,定期清理SSR函式導致的 SSR重複分配問題,20210824完善解決)
2)、CHG報與計劃查詢和匹配;參見18項,沒有DOF項跨日判斷同FPL。
3)、SDD席位隨機去相關; 參見19項
—— 20210727:主態FDP程式 每次校驗30條【校驗包內容:校驗計劃個數=30條;資料結構=30條“計劃MID<—>校驗和”記錄; EndFlag=0/1/2】,並在計劃佇列中對應第30條計劃上打 標記,假如該計劃被別的函式刪除,會造成程式直接定位到計劃佇列的最後一條,導致SDD、備態FDP刪除未校驗的計劃;透過 完善計劃校驗操作,假如被 標記第30條計劃被刪除的話,遍歷完“計劃佇列找不到標記”,就重新從第一條開始校驗(部分計劃重複校驗不會有問題),解決該問題。
——20210922(與 20210727日現象一樣的原因,當時修改不完備導致再次出現):此次 又增加這個保護: FDP動態維護的計劃列表總數是計劃列表中實時(值實時變化“ 2000...1999..1998...”)的計劃個數,(2000條計劃,則記錄校驗包個數67:2000/30>=66); 已完成 一輪校驗, 標記在 計劃佇列最後一條時,檢查本次校驗計劃 累積計數個數(增加本地臨時變數)需大於等於 動態維護的計劃列表總數記錄的值 “ 2000...1999..1998...”,則 置標誌EndFlag=1,否則 就重新從第一條開始校驗(部分計劃重複校驗不會有問題)或者從最後一條校驗的計劃往後繼續校驗;日誌如下,滿足校驗累積計數m_iChkedPlanNum(累積過程中遇到已校驗的計劃被別的函式刪除,該計數也減1)大於等於動態維護的計劃個數PlanTotalNum條件,主態Active_Fdp才會輸出”pack.EndFlag=1“ (收到EndFlag=1後,刪除未打校驗標誌的計劃時,檢查該計劃相關狀態,處於相關狀態不刪除,不相關的可以刪除:” 備態FDP加了這個判斷保護 /SDD程式沒有加“)
4)、FDP異常退出;由上述問題3)導致fdp異常退出。
5)、增加了SSR席位操作的日誌記錄:
<Warn>: 20210728064815 主機編號為[13]的席位指定計劃[202107272330CSN6348ZJSYZYTX] 分配SSR: [A0064].( 在FDO上點選“分配SSR”——“ 指定分配 ”會記錄該日誌,具體分配成功與否,需要看後續日誌記錄)
<Warn>: 20210728064853 主機編號為 [13fdoagent]的席位指定計劃[202107272330CSZ9114ZBAAZGSZ] 請求自動分配SSR.( 在FDO上點選 “分配SSR”——“ 自動分配 ”就會記錄該日誌,具體分配成功與否,需要看後續日誌記錄)
<Warn>: 20210728065127 主機編號為[13]的席位指定計劃[202107280145CSC8415ZBYNZYYJ] 釋放SSR: [A5165].( FDO上點選 “回收SSR”, 會記錄該日誌)
<Warn>: 20210728064604 主機編號為[13]的席位 遮蔽SSR: [A4176]. ( FDO上“ SSR管理”勾選 “是否遮蔽”,會記錄該日誌)
<Warn>: 20210728064610 主機編號為[13]的席位 去遮蔽SSR: [A4176]. ( FDO上 “ SSR管理”去掉勾選 “是否遮蔽” ,會記錄該日誌)
<Info>: 20210729010019 席位修改計劃[202107290005CHH7575ZLXYZBTJ]資料項號為[17] . (17指SSR)
<Info>: 20210729010019 The strip don't print for SSR = [], CallSign = [CHH7575].
<Warn>: 20210729010019 主機編號為[170]的席位修改計劃: [202107290005CHH7575ZLXYZBTJ]. (席位程式碼ACC3對應主機號170)
* 6)、修改fdp程式,“管制狀態”為CNL的計劃不顯示SSR,修改後出現剛Release SSR又立即Set SSR/AutoAssign SSRd的問題,原因——> fdp.ini中引數AutoAssignSSRTime=不為0,會呼叫新(2020-12)函式 , 功能是按引數AutoAssignSSRTime檢查自動分配SSR,但是 新增定時檢查自動分配SSR的功能沒有限定計劃狀態,導致取消狀態也參與自動分配,20210909完善FDP程式,限定計劃狀態為 CNL/FIN 的航班 不檢查 自動分配SSR。順便也解決了FIN狀態異常分配SSR的問題。
--------fdoagent修改內容:
1)、次日計劃重複傳送新增計劃包給FDP;
—— 最佳化fdoagent程式,避免頻繁”重複“向fdp傳送建立計劃請求(由於已建立,回應失敗也佔用處理時間,影響到處理移交等的響應效率)。
2)、SITA報取消計劃時將管制狀態取消;參見14項
—— 針對本文第 14項問題,修改為只要FDD上的 計劃“狀態”為“取消",就透過fdp程式將“ 管制狀態”改為“CNL”( 放棄 “原則”: SITA報不修改“管制狀態”),這樣管制狀態為“CNL”就會釋放SSR,且不會自動分配SSR。
* ——另,釋放SSR後在FDD的”SSR“一欄原先顯示之前分配的SSR,因為實際上 該航班取消 未執行,這裡改成置空SSR;而對於”FIN“狀態的航班(因為該航班實際 已執行)則顯示 之前分配使用但目前釋放的SSR。
21、fdp日誌記錄:" Plan:[......CDG8522......]:exceed speed,Speed = 3606", 計劃速度大於1994時因為SDD上顯示不全,所以在日誌裡記錄當時的實際數值。某一計劃錯誤手動相關,然後又手動去相關,該 計劃航跡就可能出現速度 計算異常的情況。
22、針對《...維護筆記(七)》,第17項11條,原先S模式雷達資料中有Garble(被干擾)標識,會被過濾,但是實際執行中,導致雷達 預推現象較多(對比推測,二所繫統不過濾 有Garble標誌的資料包),分析發現大多 有Garble標誌的S模式雷達資料包,雷達資料是正常的,2021-08-13修改frdp,rdp,為避免實際執行中 Garble標誌導致預推或單雷達目標被過濾、SDD出現單雷達目標丟失的現象, 不過濾 有Garble標誌的雷達資料包。
23、DPR上“ 即時生效”功能是透過 RDM發訊息給FDP,SDD, FDPTEL等程式,假如“對應程式”識別來自RD M的該訊息即會 線上讀取引數並生效。
24、20210926修改:增加QT版權宣告;解決Setup視窗中Map亮度調整第二、第三視窗不能實時變動,需改變視窗大小才會變動問題;按石家莊需求,本場飛本場的航班自動列印程式單由進港格式改為出港格式;傳送EndFlag=1時,FDP增加與計劃列表總數判斷條件;switch.linux:每臺交換機起始埠號可配置。
25、SDD上臨時告警抑制區高度範圍的單位是10米,為標壓高度,如果在QNH區域內,使用飛機修正後的高度來判斷是否在告警抑制區範圍內。
26、站調FDO昨日曆史沒有“延誤原因”一欄,需要在使用者設定-欄目設定-“動態計劃”中新增。
27、 ftpserver.ini中分發配置
檔案9名稱=/sdd
檔案9型別=應用程式
檔案9目的路徑=/home/atc/zzzz
會將..\INSTALL\sdd\下所有“檔案及子目錄”分發到“ 檔案9目的路徑”,但是“空資料夾”不會分發建立,所以空資料夾下需建一個檔案,比如sdd\bin\playback_data\這個資料夾下有一個內容為空的檔案1.txt,是為了保證分發時會自動建立 playback_data資料夾;否者sdd被動回放,由於沒有 playback_data資料夾從記錄儀傳回來的景象檔案放在了上一級bin\目錄下,導致sdd報錯提示找不到檔案。
28、主態fdp程式異常宕掉問題(20211102)原因:sdd重啟或在計劃列表視窗中按refresh按鈕向fdp請求計劃,fdp程式碼有點問題,計劃列表刪除了,但請求列表中該計劃的地址還存在,這樣向sdd傳送該計劃時訪問計劃列表中該計劃出錯。
29、fdp.ini增加(20210709)引數ShieldRunMode,預設值為0;
——增加一個是否遮蔽部分備用系統功能的引數;
——在備用系統模式和遮蔽部分備用系統功能下,可以自動推算控制扇區,可以自動變控制。(避免備用模式,大多數目標是非管制綠色狀態的情況,導致切為主態時影響使用)
——在備用系統模式下,不再自動關閉自動發dep/arr報,自動分配ssr,AIDC功能,這幾個功能可由系統本身 線上控制。
30、(20211104)修改(完善:原來管制狀態為空的計劃存在的問題)fdoagent:將取消的計劃生成到fdp時將管制狀態設為CNL,原來為FUTR。
31、處理接收的CHG報,航路串過長截斷的問題,修改fdptel程式解決( 欄位長改為1024),應該是fdptel程式會按欄位解析報文,航路串欄位大小設定的小了。(fdp報沒有出現該問題,分別兩條處理流程)
32、航班的trackID號未改變(例如,經停航班不關應答機——電門沒有打在STBY位),會出現例如區調席位針對前序航班的標牌手動遮蔽操作在後序航班上仍然生效,而由於手動label off的優先順序最高,故在處於協調狀態前不能透過其它開關組合顯示手動遮蔽的標牌資訊,造成此類航班只有區調的席位不能正常顯示。
33、在fdp日誌裡,記錄 TrackNo[205]和計劃DKH1787相關:
——對應SDD上FPL LIST: TrackID [205] TrackNo [162] TrackindesAdsb [1466]
對應"網上雷達資料接收程式":
——“綜合系統航跡”日誌中, TrackID=162 TrackNo=162 TrackNoA=65535 ( MRT時 TrackID和 TrackNo取值一樣?)
——“單雷達航跡02”(四創)日誌中, TrackID=1019 TrackNo=1019 TrackNoA=65535
——“選擇性融合ADSB航跡”日誌中, TrackID=205 TrackNo=162 TrackNoA=1466 ( 這裡和SDD上顯示的一致)
*FUSION出來的系統航跡號為 205,用它來與計劃相關,ADS-B融合航跡號為 1466,MRT多雷達融合航跡號為 162。 注意這裡fdp日誌和SDD上 TrackID和 TrackNo名稱定義反了 。
34、五邊進場到ADS-B遮蔽區時管制反映偶有航跡分裂、掉相關問題:
——“雷達頭髮過來的資料兩個不同目標在同一時段原始航跡號相同”(原因待查),MRDP融合航跡保持時導致分裂(因為航跡保持時只要單雷達原始航跡號不變,就直接參與融合,但是由於有某單個雷達兩個不同目標在同一時段原始航跡號相同的現象,導致航跡號相同的另一不同目標直接參與了融合,s sr/位置等偏差導致目標分裂,掉相關)該現象在有ADS-B時,在SDD上體現不出來。
-----------------------------------
***、遺留問題:
*a)從ADS-B和S模式雷達獲取SelectedAltitude時,判斷來源:管制許可高度對應Source是FCU/MCP。
b) SDD 非S模式是否顯示“N”不穩定,有時候起飛降落階段時有時無。
c)對於SFL告警,MRT以從S模式雷達獲取的 SelectedAltitude為準進行告警判斷; ADS MRT以從 ADS-B獲取的 SelectedAltitude為準進行告警判斷;當“ MRT ”或“ADS MRT ”任一有 SFL告警時, FUTION就有 SFL告警(由於 ADS MRT重新整理快,這裡 FUTION實際是以 ADS MRT產生的 SFL告警為準 )。假如實現 FUTION只有在 沒有S模式雷達 SelectedAltitude時,才採用 ADS MRT的 SFL告警,實現時邏輯上會引入其它問題。
d)實驗室執行模式StandBy時(以實現從轉發平臺同步計劃),出現SDD上所有標牌掉相關情況(FPL LIST WONDOW顯示couple為0),此時可以手動相關,掛簡標牌,分扇等:(同步計劃資料量太大導致)
-
1)重啟某個SDD後,couple數還是為0;
-
2)關閉fd_sdig.linux程式後,正常,couple數快速增加為50;
-
3)執行模式從StandBy切換為Master後,正常;
-
4)主備fdp.linux程式切換後,正常。
e )free狀態(未登入)席位可以掛TAG/DTAG簡標牌。
f ) 執行模式StandBy時,在SDD上不能進行移交接收等操作。
g )
h )、
i )
j )
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7970627/viewspace-2774506/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 川大主用ATC系統維護筆記(三)筆記
- 川大主用ATC系統維護筆記(四)筆記
- 川大主用ATC系統維護筆記(五)筆記
- 川大主用ATC系統維護筆記(六)筆記
- 川大主用ATC系統維護筆記(二)筆記
- AirNet備用ATC系統維護筆記(四)AI筆記
- AirNet備用ATC系統維護筆記(三)AI筆記
- AirNet備用ATC系統維護筆記(二)AI筆記
- 主用ATC系統執行狀態筆記(一)筆記
- ATC系統QNH高度修正(AirNet&川大)AI
- 雙指標維護筆記指標筆記
- 川大ATC實驗室從轉發平臺同步計劃
- 作業系統筆記(八)程式同步附加篇作業系統筆記
- UPS系統維護方法
- Fortinet運用前沿IT思維,保護OT系統
- 系統維護工具;System Toolkit 中文啟用版
- 川崎機器人平時的維護機器人
- 【筆記】線段維護單調棧筆記
- ATC系統跟蹤事項
- 管理與維護Linux系統Linux
- 系統維護工具:TinkerTool System for MacMac
- System Toolkit Mac系統維護工具Mac
- 長期迭代的系統如何管理維護測試用例?
- 實用的系統維護工具:System Toolkit for Mac中文版Mac
- win10怎麼關閉系統維護_win10系統維護的關閉方法Win10
- System Toolkit for mac(系統維護軟體)Mac
- System Toolkit for Mac(Mac系統維護工具)Mac
- 系統清理維護工具MacBooster 8 macMac
- TinkerTool System for mac(系統深度維護工具)Mac
- System Toolkit Mac(Mac系統維護工具)Mac
- Linux系統運維筆記(五) 使用者的操作Linux運維筆記
- 「筆記」對頂堆動態維護中位數筆記
- TinkerTool System 6 for Mac(系統維護工具) v6.97啟用版Mac
- TinkerTool System 6 for Mac(系統維護工具) v6.96啟用版Mac
- System Toolkit for Mac(mac系統維護軟體)Mac
- FREQUENTIS3020X 內話系統維護S3
- mac系統清理維護工具MacBooster Mac版Mac
- nginx 重定向到系統維護頁面Nginx