唐佔文頓了頓，話峰一轉道:“關於殲轟七A飛控軟件開發，我想還是請六一八所的高明同志來說一說吧，因為這套飛控系統是由兩所共同合作完成，除了控制律軟件外，基本上是由他們主要負責的。”

　　這時候大家夥兒都把目光投向了一名中年人，六一八所的飛控專家高明。

　　在殲轟七A的設計研製當中，六一八所負責了飛控系統的大部分研製開發工作，作為中國航空工業集產品設計、開發、生產、服務於一體的導航、製導與控制技術研發中心，涉及多個行業和國防科技領域，產品橫向覆蓋多類飛行器，縱向貫穿從零部件製造到系統集成的全過程。

　　無論是殲八二飛機的電傳系統研製，還是殲十戰鬥機的飛控系統開發，都有它的身影，也就是說，整個國內戰機的飛控軟件編寫，都是六一八所負責完成。

　　高明便是經驗非常豐富的飛軟系統專家，參與了多型飛機的飛控系統開發工作，在殲轟七A項目中，高明便是飛控軟件開發總體負責人。

　　高明沉聲道:“各位領導，專家，下面我就從飛控的角度說一說這一次試飛事故的原因分析，關於飛控系統硬件的研製和軟件的程序編寫，是由我所完成，由我本人總體負責，因為我們對這次試飛事故，也進行了認真的分析。關於飛控軟件，剛才唐總師說了，采用了容錯技術，發生錯誤的概率基本上沒有，大家也都清楚，飛控軟件缺陷發生的概率在千萬小時分之一以上，也就是說咱們的殲轟七A戰機，飛行時間累積一千萬小時，可能會出現一次錯誤，大家想想這是不可能出現的。”

　　“而且這套軟件，雖然是由我所負責編寫，但也是由主機所進行了檢查，然後共同安裝檢測，當時的評審會上，專家組也明確表示非常好。所以在飛控軟件上的缺陷，是不可能有的。兩所共同對飛控系統可靠性進行對比分析結果顯示，這套系統表現良好，我們攻克了飛控系統余度配置、同步算法、余度通道間信息交換與共享、電磁兼容、故障檢測隔離與重構、機內自檢測等一系列關鍵技術。而這一次飛機姿態失控，我們認為與飛控系統無關，應是外界因素導致。”高明說完了，便不再多作解釋。

　　這下子，會議就陷入了僵局，如果說飛控系統也沒有問題，試飛員的操作更是沒有問題，那問題出在哪兒呢?

　　今天這個事故分析會，怕是分析不出個結果了。

　　只有林鵬才知道，事故的真正原因，就是軟件代碼上的一個隱形錯誤導致的。

　　但是他作為整個會議室裡資歷最淺的人，也不可能站起來說啊，再者他要站起來說了，恐怕也沒有人會相信他的。

　　更重要的是六一八所的專家自己都說了，飛控軟件不可能有問題，他這時候要是站起來說有問題，那不是打別人的臉嗎?當然這也是打六零三所，打一飛院，打唐總師的臉啊！

　　可是這個問題怎麽才能解決呢?

　　林鵬也陷入了糾結當中，怎麽樣才能讓大家知道問題出在哪兒，然後去解決它，但是又不能傷了和氣和臉面，更不能讓人知道他是怎麽知道飛控軟件代碼有問題的。

　　這個林鵬還真是犯難了。

　　此時會議室裡的專家們也是議論紛紛，交頭接耳，現在誰都知道，出了這麽大的問題，恐怕大家都不想問題出在自己身上。

　　唐佔文總師也不知道該說什麽好了，因為飛控軟件的確是兩家合作的，

當然設備和軟件都是六一八所主導的，六零三所只是負責飛行控制律方面的工作。　　這套飛控系統，也是經過了嚴格的測試的，當時表現良好，專家評審一致認為達到了國內領先的水平。

　　甚至是軟件的編碼，都是組織了專家進行評審的，對這套飛控系統的模塊測試，綜合測試和硬件軟件的集成測試，結果都是非常好的。

　　唯一欠缺的可能是沒有進行鐵鳥台的飛行測試，因為當時就沒有條件搞鐵鳥台，在國內鐵鳥台還是一個很難突破的技術，六一一所在研製殲十這樣的三代戰鬥機過程中，才逐步摸索搞出來了。

　　但是就算沒有鐵鳥台，也在綜合測試和飛行測試中表明，這套三軸三余度數模飛控系統還是很可靠的。

　　但是如果不是飛控的問題，那這次事故發生的原因是什麽呢?總不能不了了之吧?這肯定是不被允許的，也過不了上級那一關。

　　就在這時候唐佔文忽然感覺口袋裡的手機， 震動了幾下，開會的時候他的手機的確是調到了靜音的。

　　唐佔文心想這時候是誰發了短信過來?唐佔文拿出手機一看，發短信給他的人，是林鵬。

　　當他看到短信內容的時候，也是震驚了。

　　林鵬發給他的短信內容不長，就提到了兩個關鍵詞，優先級與反轉，1997年M國火星探路者事件。

　　看到林鵬這個提示，唐佔文總師隻覺得腦袋裡面，似乎都嗡的響了一下，好像問題出在哪兒，他找到了！但這也只是林鵬的揣測，到底是不是，也不是憑猜測和嘴巴說就能證明的。

　　但不管怎麽樣，今天這個事故分析會，必須要有個結果啊，所以唐佔文決定哪怕是丟了面子，也要講出來。作為總師，他對飛行控制系統還是非常了解的，雖然他不會編寫那些代碼，但基本的原理和架構，他非常清楚。

　　而火星控路者事件，是怎麽一回事呢?一九九七年，M國炎星探路者著陸火星後第十天，就開始犯傻，它開始無規律的重啟，每次啟動都會造成數據丟失。

　　當時NASA的解釋是火星探路者的計算機試圖同時完成太多任務造成故障。

　　在當時的分析會上，開發火星控路者自動控制軟件系統的公司，就給出了一個很有意思的說法，這就是優先級與反轉。

　　火星探路者的氣象任務，這是一個低優先級的任務，在寫總線的時候，一個中斷的發生導致了通信任務被調度並就緒，最後由於通信任務運行時間稍長了，總線管理任務等待超時，返回錯誤。結果就是系統重啟。