臺灣高等法院99年度重上更㈠字第159號

臺灣高等法院民事判決　　　　　　 99年度重上更㈠字第159號

上訴人

即被上訴人

台灣洛克希德股份有限公司

法定代理人

魏斯邁

訴訟代理人

陳長文律師

複代理人

林耀琳律師

訴訟代理人

李念祖律師

訴訟代理人

馮博生律師

複代理人

楊東晏律師

複代理人

黃聖棻律師

複代理人

胡淑莉

被上訴人

交通部民用航空局

法定代理人

沈 啟

訴訟代理人

林庭宇律師

訴訟代理人

林雅芬律師

訴訟代理人

陳鵬光律師

訴訟代理人

王龍寬律師

被上訴人

即上訴人

臺灣銀行股份有限公司

法定代理人

蕭長瑞

訴訟代理人

劉景榮

複代理人

林雅芬律師

複代理人

陳鵬光律師

上列當事人間請求損害賠償事件，上訴人對於民國89年12月8日臺灣臺北地方法院80年度重訴字第506號第一審判決提起上訴，經最高法院發回更審後，本院於103年7月29日言詞辯論終結，判決如下：

主文

事實及理由

甲、程序方面

壹、中央信託局（下稱中信局）業於本院訴訟進行中之96年7月1日與臺灣銀行股份有限公司（下稱台灣銀行）合併，台灣銀行為存續公司，有行政院金融監督管理委員會95年12月29日金管銀㈡字第00000000000號函、台灣銀行董事會96年6月1日銀人乙字第00000000000號通知及台灣銀行章程可稽（見本院前審卷4167至170頁），茲據台灣銀行具狀聲明承受訴訟（見本院前審卷4163頁），核無不合。

貳、台灣洛克希德股份有限公司（下稱洛克希德公司）之法定代理人原為吉伯特，已於本院前審訴訟進行中之97年1月14日變更為魏斯邁；又台灣銀行之法定代理人原為羅澤成，亦已於本院訴訟進行中之98年7月23日變更為蔡富吉；嗣再變更為張明道、邱月琴、蕭長瑞（見本院第24卷103年8月18日聲明承受訴訟狀）；另交通部民用航空局（下稱民航局）之法定代理人原為張有恆，亦已於本院訴訟進行中之97年7月14日變更為李龍文，有公司變更登記表、台灣銀行98年7月22日銀人資字第00000000000號函及行政院97年7月14日院授人力字第0000000000號令可稽（見本院前審卷5第119、120、208至210頁；卷7第104頁），茲據彼等具狀聲明承受訴訟（見同上卷5第117、204、205頁；卷7第101頁），嗣又變更為尹承篷、沈啟(見本院第12卷第157頁)，亦核無不合。

參、洛克希德公司起訴時，原係請求中信局及民航局連帶給付美金3057萬8753元【包括系爭航管契約所定工程(下稱約內工程)已完成部分損害賠償美金1342萬572元、約外工程(詳如後述)已完成部分損害賠償美金1267萬4254元、履約保證金美金210萬2866元、預付款保證金美金238萬1061元見原審卷1第437頁】本息。原審判命中信局應給付洛克希德公司美金448萬3927元本息(即履約保證金美金210萬2866元＋預付款保證金美金238萬1061元)，而駁回洛克希德公司其餘之請求。洛克希德公司就其敗訴部分聲明不服提起上訴後，減縮並追加先位上訴聲明如下：先位上訴聲明：

㈠原判決不利洛克希德公司部分廢棄。㈡上開廢棄部分，台灣銀行應再給付洛克希德公司美金1455萬4274元及新台幣1億6721萬5435元及自78年4月21日起至清償日止，按年息百分之五計算之利息，台灣銀行應給付洛克希德公司履約保證美金158萬3359.20元、新台幣1484萬2299元、預付款保證金美金181萬3618.75元、新台幣1634萬6222元，及自78年4月1日起至清償日止，按年息百分之五計算之利息；民航局應給付洛克希德公司美金1455萬4274及新台幣1億6721萬5435元及自78年4月21日起至清償日止，按年息百分之五計算之利息，上開給付，與原判決所命台灣銀行之給付，如其中任一人已為給付，於其給付範圍內，另一人免給付義務(見本院前審第7卷第123頁、本院卷22第244頁、245頁、本院第23卷第43頁)。備位上訴聲明：

㈠原判決不利洛克希德公司部分廢棄。㈡上開廢棄部分，台灣銀行應再給付洛克希德公司美金1712萬1000元及自78年4月21日起至清償日止，按年息百分之五計算之利息，民航局應給付洛克希德公司美金1712萬1000元及自78年4月21日起至清償日止，按年息百分之五計算之利息，上開給付，與原判決所命台灣銀行之給付，如其中任一人已為給付，於其給付範圍內，另一人免給付義務。上開上訴聲明部分核屬減縮，另追加應受判決事項之聲明，係幣別不同，請求基礎事實同一，合於民事訴訟法第446條第1項但書、第255條第1項第2款、第3款之規定，應予准許(見101年11月9日筆錄，本院卷16)。

乙、實體方面：

壹、洛克希德公司起訴主張：

一、民航局為汰換老舊半自動式雷達管制系統，於72年6月間委託中央信託局（下稱中信局，已為台灣銀行合併，並經其於原審承受訴訟，惟如為呈現原來事實，仍以中信局稱之）代其招標航空管制自動化系統工程（下稱系爭航管工程）。嗣由訴外人美商洛克希德電子股份有限公司（下稱美商洛克希德公司，已由洛克希德馬汀股份有限公司所合併）得標，雙方並約定以訴外人香港商洛克希德飛機國際有限公司（下稱香港商洛克希德公司）為系爭航管工程之承攬人。嗣民航局、中信局、美商洛克希德公司及香港商洛克希德公司於72年12月20日共同簽訂航空管制自動化系統契約（下稱系爭航管契約），約定契約總價為美金3906萬2649元，美金付款為3155萬1914元，新台幣付款為3億0223萬2000元。系爭航管契約包括台北地區管制中心系統（下稱TACC系統）及終端管制中心系統（下稱TCC系統）兩大部分，而TCC系統包括台北（中正（桃園）國際機場）、台中及高雄三地機場塔台及進場管制系統。系爭航管契約於簽訂後，迭經六次修正，並於74年8月8日第四次修正時，將完工期限變更為TACC系統76年8月30日、台北TCC系統76年11月30日、高雄TCC系統77年2月29日、台中TCC系統77年5月30日，復於76年9月10日第六次修正時，修正契約總價為美金3904萬4071元，其中美金付款3166萬7184元，新台幣付款2億9684萬5974元。

二、系爭航管工程進行後，發現民航局有下列所示4大項共36小項之違約情事，致施工進度不斷被迫延後，美商（香港商）洛克希德公司乃數度請求中信局及民航局依系爭航管契約附件即「系爭航管契約條款闡明（下稱系爭闡明條款）第4.2條約定，修改系爭航管契約，增加契約價金(即4大項36小項約外工程價款)及延長完工期限。

三、詎民航局竟於76年12月1日透過中信局向香港商洛克希德公司發出違約通知，復於77年6月25日發函通知香港商洛克希德公司終止系爭航管契約，並先後於同年7月28日及8月16日沒收香港商洛克希德公司委託美商信孚銀行台北分行（下稱信孚銀行）提供之履約保證金210萬2866元及預付款保證金238萬1061元。

四、惟按係爭闡明條款第5.3.1條第a項第（i）款、第（ii）款所約定之終止事由，均須經美商（港商）洛克希德公司催告而未補正時，始得適用。且香港商洛克希德公司於收受中信局76年12月1日通知函後，已於77年1月15日向民航局提交完工計畫，並由民航局航管顧問即美國邁特公司先後於同年1月27日及6月22日提出評估報告認為可行，香港商洛克希德公司已依約採取適當之補救措施。又系爭航管工程進度落後，具有系爭闡明條款第4.2條約定可宥恕事由，復經國立成功大學航空太空工程研究所（下稱成大航太所）鑑定，認民航局應負45.38%遲延責任，美商（香港商）洛克希德公司負54.62%遲延責任，另依同條款第4.1條及第4.2條約定，完工期限應按上開可歸責於民航局之責任比例自動展延，即依上開完工計畫預估航管工程尚須39個月工期計算，完工日期當自動展延18個月，將原訂最後完工日期77年5月30日延至78年11月30日。美商（香港商）洛克希德公司未在原訂工期內完成，亦無給付遲延可言。況美商（香港商）洛克希德公司業將系爭航管工程硬體設備裝設完成，並將大部分軟體交付或提供民航局，尤無遲延情事。

五、成大航太所鑑定報告既認民航局應就系爭航管工程進度延後負45.38%責任，民航局及中信局自不得以美商（香港商）洛克希德公司違約為由，終止系爭航管契約，彼等於77年6月25日終止系爭航管契約，屬系爭闡明條款第5.2條約定之任意終止，依同條款第5.2條第d項、第e項約定及民法第511條規定，民航局及中信局自應賠償美商（香港商）洛克希德公司所受損害。系爭航管工程既有系爭闡明條款第4.2條所約定可宥恕事由存在，香港商洛克希德公司於系爭航管契約終止時，無給付遲延情事，依同條款第5.3.1條第d項約定及民法第511條規定，香港商洛克希德公司可請求損害賠償。

六、中信局於77年6月25日發函終止系爭航管契約既不合法，上開沒收之履約保證金及預付款保證金應併予返還。

七、香港商洛克希德公司、美商洛克希德公司各於77年10月10日及78年8月14日，將依系爭航管契約所得享有權利，及因中信局、民航局違約及任意終止契約所得主張之權利讓與伊，並經伊先後以訴狀繕本及79年1月9日準備書狀繕本之送達，對中信局及民航局為債權讓與之通知。

八、中信局等應給付洛克希德公司：㈠4大項36小項約外工程之金額。㈡約定工程報酬、損害賠償金額。㈢返還履約保證金及頭期款保證金。

九、中信局等應就伊所受損害負賠償之責任等情，爰依系爭闡明條款第4.1條、第5.2條第d項、第e項、第5.3.1條第d項約定，與民法第176條、第179條及第511條等規定，上訴聲明求為：

㈠先位聲明：⒈原判決不利洛克希德公司部分廢棄。⒉上開廢棄部分，台灣銀行應再給付洛克希德公司美金1455萬4274元及新台幣1億6721萬5435元及自78年4月21日起至清償日止，按年息百分之五計算之利息，台灣銀行應給付洛克希德公司履約保證美金158萬3359.20元、新台幣1484萬2299元、預付款保證金美金181萬3618.75元、新台幣1634萬6222元，及自78年4月21日起至清償日止，按年息百分之五計算之利息，民航局應給付台灣洛克希德公司美金1455萬4274及新台幣1億6721萬5435元及自78年4月21日起至清償日止，按年息百分之五計算之利息，上開給付，與原判決所命台灣銀行之給付，如其中任一人已為給付，於其給付範圍內，另一被上訴人免給付義務。⒊上訴人願以現金或等值銀行可轉讓定期存單供擔保請准宣告假執行。(見本院前審卷7第123頁)

㈡備位上訴聲明：⒈原判決不利洛克希德公司部分廢棄。⒉上開廢棄部分，台灣銀行應再給付洛克希德公司美金1712萬1000元及自78年4月21日起至清償日止，按年息百分之五計算之利息，民航局應給付洛克希德公司美金1712萬1000元及自78年4月21日起至清償日止，按年息百分之五計算之利息，上開給付，與原判決所命台灣銀行之給付，如其中任一被上訴人已為給付，於其給付範圍內，另一被上訴人免給付義務，付義務。⒊上訴人願以現金或等值銀行可轉讓定期存單供擔保請准宣告假執行。答辯聲明：台灣銀行之上訴駁回。（逾上開請求金額部分，經第一審判決洛克希德公司敗訴後，未據其聲明不服，因未繫屬本院，不予贅列。）。

貳、被上訴人台灣銀行、民航局(下稱民航局等，如一人逕記載名稱)則以：

一、本件航管系統係以整套輸出設備契約為基礎，依國際貿易慣例，系爭航管契約性質為買賣而非承攬。

二、依系爭航管契約首頁「招標、投標及契約」所示，締約當事人為中信局及美商洛克希德公司，香港商洛克希德公司並非契約當事人，僅係承受美商洛克希德公司基於系爭航管契約所生之義務，自無任何契約權利得讓與洛克希德公司，美商（香港商）洛克希德公司債權讓與契約非屬真正，其並未合法受讓取得系爭航管契約權利。

三、系爭闡明條款第5.3.1條第a項所定解除事由，包括無法如期交付設備、履行服務、其他約定或進度遲延致危及契約履行，及無法於六十日內補正兩種。香港商洛克希德公司因有給付遲延，經中信局通知補正後，僅於77年1月15日提出追加鉅額款項而違債務本旨之完工計畫，與未提出補正無異，屬拒絕給付，並害及系爭航管契約之實現，該違約事由已符係爭闡明條款第5.3.1條第a項約定，中信局即有權利解除系爭航管契約，並沒收履約保證金及預付款保證金。

四、又香港商洛克希德公司既係美商洛克希德公司履行契約之代理人，則中信局對香港商洛克希德公司解除系爭航管契約之通知，應已合法解除。

五、洛克希德公司所指如下述四大項三十六小項之違約事由，係其隨意分類，與系爭闡明條款第4.2條所定可宥恕事由不符。

六、縱認香港商洛克希德公司就系爭航管契約履行具有系爭闡明條款第4.2條所定可宥恕事由，但依同條款第5.3.1條第d項第（ii）款、第（iii）款約定，不論貨品或服務，賣方均須完成始得請求損害賠償。香港商洛克希德公司僅將履行契約所需設備存放民航局提供之場所，迄未交付，且屬未完工半成品，不符系爭招標單所約定之合約精神，亦不得請求損害賠償。其以工作項目及價金給付時程作為計算約內工程賠償方法，殊乏依據，更與上開約定不符。另依同條款第4.3條約定，任何約外工程皆須由民航局書面要求，並經締約雙方同意始生效力。其未提出相關書面文件，以證明雙方就約外工程有何約定，伊就約外工程無賠償義務。

七、成大航太所鑑定報告、補充鑑定報告及賠償鑑定報告，違反系爭航管契約所定之損害賠償計算方法，且未逐一勘驗、盤點係爭航管工程之硬、軟體設備及相關文件，不足為憑。再成大航太所林清一教授不具備航管、會計專業，該所委由其個人獨自鑑定不具證據能力。反觀另案伊等與香港商洛克希德公司等間返還價金事件，囑託國防部軍備局中山科學研究院（下稱中科院）鑑定，認伊等就係爭航管工程所提需求多屬合理，且非約外要求，香港商洛克希德公司即應依約履行義務，其給付遲延，並無系爭闡明條款第4.2條所定之可宥恕事由，應負違約責任。

八、又中科院鑑定報告固認民航局就系爭航管工程遲延應負13.40%管理責任，惟伊等就系爭航管工程執行，除於招標時期，即提供詳盡技術規格文件外，並聘請美國邁特公司為專案技術顧問，復於簽訂系爭航管契約後，多次與得標廠商開會研商，並提供協助，甚至修改契約，延長完工期限長達十七個月，乃香港商洛克希德公司仍無力履約，伊等始表示解除契約，伊等於履約管理上盡最大之努力，已無須就航管工程遲延負何責任等語，資為抗辯。爰上訴聲明：㈠原判決不利台灣銀行部分廢棄。㈡上開廢棄部分，洛克希德公司第一審之訴及假執行之聲請均駁回。答辯聲明：㈠洛克希德公司上訴、追加、變更之訴均駁回。㈡如受不利之判決，願供擔保請准宣告免假執行。

參、本件經原審判決中信局應給付洛克希德公司美金448萬3927元及自78年4月21日起至清償日止，按週年利率百分之5計算之利息，駁回洛克希德公司其餘之請求。洛克希德公司不服原審判決，提起部分上訴，經本院前審駁回上訴，洛克希德公司不服上訴，經最高法院廢棄發回，洛克希德公司追加先位之上訴、備位上訴如前述所載。洛克希德公司於103年6月12日狀上訴聲明記載台灣銀行或應給付美金1712萬1000元及新台幣1億9840萬3957元(見本院卷22第244頁、245頁)，故其就履約保證金、預付款保證金請求台灣銀行應給付美金及新台幣至明。其嗣雖於103年7月9日70狀(見本院卷23第13、15頁)，於聲明臺灣銀行部分漏未記載上開保證金請求，惟其於理由內記載有關履約保證金部分，原審判命台灣銀行應返還美金部分，若分拆為先位上訴聲明為美金..元及新台幣...，預付款保證金部分分拆為美金及新台幣...並無減縮之記載，另言詞辯論意旨狀(見本院卷23第44、47頁背面、167頁)雖聲明相同，惟其理由內亦敘明原審命台灣銀行應返還履約保證金美金部分，若分拆為美金及新台幣，美金158萬3359.20元、新台幣1484萬2299元、預付款保證金美金181萬3618.75元、新台幣1634萬6222元(同上卷第49頁)，則其漏未記載履約、預付款保證金部份，係就上訴並追加先位聲明之記載方式或理解有誤，已臻明確，而原審判命中信局應給付洛克希德公司美金勝訴部分，分拆美金、新台幣之爭點亦據民航局所知悉而為充分答辯，並無違其程序之保障，附此敘明。

肆、系爭航管工程為民航局於72年6月間委託中信局招標，由美商洛克希德公司得標，並於72年12月20日簽訂系爭航管契約，約定由香港商洛克希德公司承攬系爭航管工程。系爭航管契約內容涵括TACC系統及TCC系統兩大部分，而TCC系統又包括台北TCC系統、台中TCC系統及高雄TCC系統。系爭航管契約所約定之完工期限原為：①TACC系統為75年4月5日、②台北TCC系統為76年8月5日、③高雄TCC系統為77年2月5日、④台中TCC系統為77年8月5日。系爭航管契約於簽訂後，迭經73年5月31日、73年6月27日、74年3月12日、74年8月8日、75年8月30日及76年9月10日六次修正，並於74年8月8日第四次修正時，將完工期限變更為：①TACC系統為76年8月30日、②台北TCC系統為76年11月30日、③高雄TCC系統為77年2月29日、④台中TCC系統為77年5月30日，復於76年9月10日第六次修正時，將契約總價修正為美金付款部分為3166萬7184元，新台幣付款部分為2億9684萬5974元（洛克希德公司於前審將新台幣換算為美金總計為美金3904萬4071元，契約價格之美金對新台幣匯率均以1比40.024計算）。系爭航管工程進行後，因施工進度落後，中信局乃於76年12月1日以香港商洛克希德公司未遵守工程期限，顯可預見系爭航管工程無法如期完工為由，通知該公司於60日內予以補正，香港商洛克希德公司即於77年1月15日函復中信局，並檢附「完工計畫」，嗣中信局於77年6月25日發函通知香港商洛克希德公司terminate系爭契約，並先後於77年7月28日、同年8月16日通知香港商洛克希德公司所委託之信孚銀行給付履約保證金美金210萬2866元及預付款保證金美金238萬1061元之事實，為兩造所不爭執(見本院卷1第218、222至224頁)，並有系爭航管契約暨六次修正契約、中信局76年12月1日函文、77年6月25日函文、77年7月28日函文及77年8月16日函文、及香港商洛克希德公司77年1月15日函文可稽（見外放合約文件㈠、㈡、㈢；外放原證1號、原證2號、原證3號、原證4號、原證6號、原證7號暨中譯本），自堪信為真實。洛克希德公司雖主張中信局、民航局與美商洛克希德公司、香港商洛克希德公司均為系爭航管契約之締約當事人，因中信局及民航局任意終止系爭航管契約，致美商(香港商)洛克希德公司受有損害，應負債務不履行之損害賠償責任，並返還上開業經被沒收之履約保證金及預付款保證金云云。惟台灣銀行及民航局則予以否認，並以前揭情詞置辯；兩造係就四大項三十六小項約外事項、約內事項、保證金(履約保證金、預付款保證金)而有如下之爭執，爰就上開事項分述如下：

一、約外事項部分:

㈠第一大項第一小項關於洛克希德公司主張「航路之約外要求」，即民航局要求之偏好航路（Preferential Route），是否為航路之約外要求部分？

A.洛克希德公司主張：

⒈TACC規格書僅有規定、要求對標準航路(SID及STAR航路)之飛航資料處理，而未要求偏好航路(Preferential Route)飛航資料處理，民航局於1984年8月6日之PDR會議始要求將「偏好航路」加入飛航資料處理系統之設計中，並自承「偏好航路」之飛航資料處理乃約外要求，且中信局於1987年1月8日提出變更指令指示洛克希德公司完成該約外要求之設計。

⒉洛克希德公司之投標文件既非招標文件，無由亦不得更易招標文件所列之需求。且系爭航管契約附件B業已就合約文件之適用明定其順序，「招標文件」之適用順位應優先於洛克希德公司「投標文件」，此乃系爭航管契約所明定之事項，況最高法院發回意旨明揭既「基本需求規章」列為招標文件之一，雙方應以該文件作為行使權利及履行義務之鵠的；再則系爭航管工程係屬固定價格、範圍之工程，系爭闡明條款第4.1條乃明定，招標文件(主要為基本需求規章)係決定系爭航管工程所有契約工作項目及技術要求，且為系爭航管工程唯一之技術需求實體規範，故判定某一要求是否屬約內要求，須依招標文件(主要為基本需求規章)決定之，任何非招標文件所規定之要求，均係約外要求。

⒊1984年8月6日TACC初期設計審核會議紀錄中，並無如民航局等送中科院資通所鑑定證物附件31號下方所載：「041 CLOSEDAnswer,"Yes"」等文字，回答此一問題應為民航局；再者，倘該1984年8月6日會議中洛克希德公司若已同意偏好航路非屬約外要求，則洛克希德公司為何需以函文多次告知民航局表示該等新功能已逾越基本需求規章規定？又民航局為何未執該1984年8月6日PDR會議紀錄，主張洛克希德公司已同意偏好航路非屬約外要求，反而於1985年5月30日函文中要求洛克希德公司提出該約外要求之影響預估？況民航局於其1985年8月29日函文指示洛克希德公司執行使用中跑道(Runways in Use)之約外要求，嗣民航局終而指示中信局以1987年1月8日函文為變更指令，表示將依系爭航管契約第4.1條、第4.3條規定，進行系爭航管契約價格及時程調整。由上開函文均足堪證明中科院判認「洛克希德公司」已於1984年8月6日PDR會議中同意偏好航路非屬約外要求，要無可採。

B.民航局等則以：

⒈系爭航管自動化系統應具備偏好航路之處理功能，此項功能目的乃為因應航管作業環境之改變而提供作業上公認之偏好航線，且此等功能於73年以前即已是美國NAS系統之標準現貨功能，不論TACC規格書是否就此已有明文規範，「偏好航路」之功能均非謂之約外要求，況TACC規格書第3.7.3.2.1.46節(Select Adapted Route Options)亦明訂，系爭航管自動化系統應具備按通常可預見之操作改變，以選取合適航路(adaptedroute options，即此處之偏好航路)之功能，在文義上即已含括PARs,PDRs,PDA Rs等航路處理功能；甚者，民航局於95年之飛航管理計畫(ATM)採購案時，含洛克希德公司在內之5家參與投標廠商，均於投標文件中強調其系統具備偏好航路(Preferential Route)之基本功能，可知洛克希德公司主張偏好航路之功能性需求即為約外要求云云，顯與事實不符。

⒉洛克希德公司之投標文件本屬系爭契約文件，「偏好航路」之功能亦為TACC規格書第3.7.3.2.1.46節所含括，且依系爭契約FORM B之規定，洛克希德公司應遵守包括投標文件在內之一切契約文件，進行相關之分析作業，以建置系爭航管自動化系統，故投標文件本屬判斷洛克希德公司工作範圍之標準之一，以上業經洛克希德公司自認。

⒊1984年8月6日之PDR會議關於偏好航路，是否為必須項目，會議結論為"YES"，洛克希德公司之主張顯悖於證據資料；縱如洛克希德公司所稱回答"YES"者為民航局，而非洛克希德公司與其次供應商OAO云云，則何以洛克希德公司與其次供應商OAO未當場異議，益徵洛克希德公司之主張，顯為臨訟卸責之詞等語，資為抗辯。經查：

⒈按所謂偏好航路(Preferntial Route)包括偏好離場航路(PDRs,Preferntial Departure Routes)、偏好到場航路((PARs,Preferntial Arrival Routes)及偏好離到場航路(PDARs,Preferntial Departure/ Arrival Routes)等可預先定義在系統中供航管選擇使用之航路，其功能目的乃為因應航管作業環境之改變(例如：更換使用跑道、噪音管制時段等)而提供作業上公認之偏好航線(Preferntial Route)，況73年以前偏好航路已是美國NAS系統之標準現貨功能，業據民航局提出美國1984年版NAS系統規格書(NAS-MD-31,1,1984)附卷可按（詳上證57號，見本院卷3第774至786頁），可見此等功能應為系爭航管自動化系統之重要基本功能，合先敘明。

⒉洛克希德公司主張TACC規格書僅有規定、要求對標準航路（SID及STAR航路）之飛航資料處理，而未要求航路飛航資料處理云云，此為民航局所否認。經查：洛克希德公司投標文件(LEC Proposal)第2冊第3-19頁明確指出，在建置系爭航管自動化系統之飛航資料處理系統時，其供應商OAO將援用NAS演算法(algorithms)為TACC軟體設計之標準(詳上證58號，見本院卷3第787至788頁)，而美國NAS系統在73年前即已具備偏好航路之功能(詳上證57號，見本院卷3第774至786頁)，是偏好航路之功能自始即由洛克希德公司承諾納入系爭契約所預定之應有功能（投標文件效力詳如後述⒋）。又系爭航管自動化系統之設計，依洛克希德公司提出之投標文件第2冊第3-136頁所載，應採如下之建置過程：藉由系統分析(System Analysis)掌握訂購者之需求，並透過「軟體設計」將訂購者之需求轉化為最終之軟體系統，而「軟體設計」又可區分為「轉換需求為資料及軟體架構」之初步設計(Preliminary Design)及「導出軟體細節資料結構和演算法則」之細部設計；在初步設計及細部設計中，則分別借重正規技術審核中之初步設計審核(PDR)及細部設計審核(CDR)，以確定使用者之需求能確實反映並落實於軟體之具體設計。從而，在將訂購者(即民航局)之需求轉換為可行之設計藍圖之過程中，可藉由PDR或CDR，民航局就功能性之需求提出說明或澄清，並對於洛克希德公司之設計為審核及指正，不問是否稱之為「細部需求」，應認為均不屬於提出約外要求。

⒊另依TACC規格書第3.7.3.2.1.46節(Select Adapted RouteOptions)亦明訂，系爭航管自動化系統應具備按通常可預見之操作改變，以選取「合適」航路(adapted route options，即此處之偏好航路)之功能(詳民航局等100年5月12日上訴暨答辯理由(5)狀第8至10頁，見本院卷2第368頁背面至369頁背面)，在文義上即已含括選取偏好航路處理功能。另參諸民航局於95年中辦理「飛航管理計畫(ATM)」採購案時，含洛克希德公司在內之5家參與投標廠商，均於投標文件中強調其系統具備偏好航路(Preferential Route)之基本功能，其中洛克希德公司對於描述此一功能所用之專有名詞確已詳實記載於系爭投標文件(詳上證63號，見本院卷3第796頁)，該採購案雖在本件採購案之後，惟偏好航路(Preferential Route)乃飛航安全所必須具備之基本功能已如前述，仍非不可斟酌。綜上所述，洛克希德公司主張民航局未於TACC規格書中列明所謂「偏好航路」之用語，偏好航路之功能性需求即為約外要求等情，顯與事實不符，應屬無據。

⒋再則洛克希德公司雖主張系爭航管契約附件B (Attachment toForm B,Contract Documents)業已就合約文件之適用明定其順序，其中第5順位文件為招標文件(RFP Documents)，第8順位文件始為洛克希德公司投標文件(LEC Proposal)；意即「招標文件」（即基本需求規章）之適用順位應優先於「洛克希德投標文件」，而「招標文件」中並未規定、要求偏好航路之飛航資料處理，民航局及中信局等竟捨基本需求規章而不論，援引順位在後之洛克希德投標文件，洵屬違誤而不可取云云。惟查：雖系爭契約附件FORM B已就合約文件之適用明訂順序，唯若無礙系爭契約目的之達成，而有相輔相成之效，且為洛克希德公司投標時明示可達成，則各項契約文件均非不可併為適用；且依系爭契約附件FORM B之規定，洛克希德公司應遵守包括投標文件在內之一切契約文件，而負責就載有本件系統功能性需求之契約文件(包含但不限於民航局之招標文件(RFP)、洛克希德公司投標文件、相關軍事規範、兩造所舉行歷次技術澄清會議之書面會議紀錄、闡明摘要及洛克希德公司就自己投標文件所為之闡明等文件)，進行相關之分析作業，以建置系爭航管自動化系統，故洛克希德公司之投標文件本屬判斷洛克希德公司工作範圍之標準之一，參諸洛克希德公司於書狀中自承「第按，洛克希德公司於投標文件中，提出、建議TACC系統、TCC系統之狀況顯示器及塔台數位顯示器之『目錄至多可容納64個符號』……是以，狀況顯示器之規格至多僅為64個」(詳洛克希德公司101年1月6日上訴暨答辯理由(10)狀「第二大項第二小項」第2頁至第3頁，見本院卷5第238頁）。是以洛克希德公司既已於系爭契約內承諾應遵守包括投標文件內之一切契約，復以前述理由主張其僅需遵守「招標文件」中之約定，難認其主張合於契約精神，應屬無據。

⒌況於73年8月6日之PDR會議中，關於TACC之PDR待決工作項目第41項，民航局詢問洛克希德公司PARs與PDRs等是否為飛航計畫處理系統所應要求之功能(FPP(Flight Plan Processing)Function)時，洛克希德公司亦回答「是」(Yes)(詳上證59號，見本院卷3第789頁)，洛克希德公司自應受該PDR會議結論所拘束；雖洛克希德公司主張於該PDR會議回答YES者為民航局云云，惟參諸該PDR會議記載「041,”CLOSED”Answer,"YES"」，應認為係洛克希德公司同意而為終結，且洛克希德公司並未即時於該次PDR會議表示異議或反對意見，該PDR會議記載「041,CLOSED Answer,"YES"」，應認為雙方已於該次PDR會議達成共識，則偏好航路之要求自非屬約外要求，縱洛克希德公司日後多次以函文方式表明該功能已逾越基本需求規章，亦不影響該次PDR會議之效力；另洛克希德公司復主張，民航局業已「自承」偏好航路之功能為所謂之約外要求云云。惟查：該記載「"out-of-scope"」items，民航局抗辯以雙引號方式標示所謂「out-of-scope items」之用語，可知使用雙引號「"」來強調所謂之「約外需求」不過為洛克希德公司之單方主張而已，此觀諸民航局等於其後之74年5月30日函文中進一步說明：「…民航局要求『使用中跑道』之資訊應以下列方式處理：…若貴公司認為此係約外需求，則請依相關程序敘明理由辦理，並提出影響預估」(詳洛克希德公司100年9月21日上訴暨答辯理由(6)狀附件「第一大項第一小項」附件1-(1)-12，見本院卷3第628頁)等語，益徵明確，顯見洛克希德公司對前揭函文之真意尚有誤解，其主張並不足採。

⒍洛克希德公司主張民航局藉由TACC PDR待辦事項第51號提出本鑑定項目「航路之約外要求」之約外要求，而大量新增額外軟體及硬體功能，致基本需求規章原訂之顯示器韌體不能與該等額外新增之軟體及硬體功能相容，民航局乃指示中信局提出1987年1月8日變更指令，就民航局於上開TACC PDR待辦事項所提出之約外要求所涉新增之軟體及硬體功能云云，惟73年8月6日之PDR會議已就偏好航路是否為必須項目達成共識（詳如前述㈠⒋），故其主張尚無足採。

⒎洛克希德公司雖主張最高法院發回意旨明揭既「基本需求規章」列為招標文件之一，雙方應以該文件作為行使權利及履行義務之鵠的云云；惟查，最高法院發回意旨並未就本爭點為指摘，而係就第一大項第四小項爭點發回意旨指稱：「…且中信局將「基本需求規章」列為招標文件之一，更應以之作為雙方行使權利及履行義務之鵠的。」，而認為招標文件(主要為基本需求規章)係決定系爭航管工程所有契約工作項目及技術要求，且為系爭航管工程唯一之技術需求實體規範，故判定某一要求是否屬約內要求，須依招標文件(主要為基本需求規章)決定之。惟查，兩造既就系爭航管工程之需求規章逐條討論做成共計104項之澄清會議記錄，且與工作說明書等其他招標文件，同列為契約文件之一（詳見前述㈠⒋說明及下述㈣之說明），則某項工作是否屬於契約約定之範圍內，自應綜觀契約各項文件，包括投標文件、PRD會議記錄等資料為綜合判斷，洛克希德公司主張僅以TACC、TCC及RDE規格書之內容決之，容有誤會。

⒏至於國立成功大學航太系93年2月1日補充鑑定報告（該補充鑑定報告係以原民國88年8月18日鑑定報告為基礎，除補充原鑑定報告不足之處及更正錯誤外，其餘部分鑑定結果均和原鑑定報告相同，合先敘明。下稱成大鑑定報告），就該爭點僅稱「缺乏證據資料」，未就系爭契約相關各項文件，包括投標文件、PRD會議記錄等資料為綜合判斷，而遽謂兩造所提證物薄弱，尚難認為具參考價值；另中山科學研究院之鑑定報告（下稱中科院鑑定報告）說明基本規章係說明系統之基本功能需求，至於詳細之系統需求，兩造須在後續的PDR、CDR中研討後確定，並參酌73年8月6日之PDR會議記錄資料，認為洛克希德公司與民航局已就該次會議中達成共識，進而認定偏好航路等需求並非屬於約外要求，此結論與兩造所提供之證據資料及本院認定之事實相符，揆諸前述論斷，應屬可採。惟本爭點係屬歸責於洛克希德公司，並應負完全責任，不可歸責民航局，過失比例部分尚無庸參考，併予敘明。

⒐關於洛克希德公司於102年8月6日民事調查證據聲請狀中，請求成大航太所補充說明之詢問事項，已於上開㈠⒉、⒊、⒋、⒌、⒍部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

㈡第一大項第二小項關於洛克希德公司主張「空軍航管中心介面連接之定義」共四部分：A.洛克希德公司主張：

⒈依1984年2月9日待辦事項會議紀錄，雙方同意系爭航管系統電腦系統之內部及外部通訊，應符合「CCITT X.25LAP-B」（即國際電報電話諮詢委員會第25節聯結存取程序B版）之高階資料聯結控制規則(1980年8月版)。嗣於1984年6月28日會議中，中華民國空軍提出CCITT X.25LAP-B介面規則與AACC系統不相容，要求應併適用非標準化之交換資訊規則，且民航局與空軍雙方遲遲未能就此系爭航管系統與AACC系統相互銜接設計相容之問題達成協議；民航局復以1985年9月26日函文，以不予核准介面控制文件相脅，要求洛克希德公司將符合CCITT X.25LAP-B規格之一位元組(1 byte)閒置字元(idle character)，更改為二位元(2 bits)。然依CCITT X.25LAP-B規則，閒置字元乃為一位元組(1 byte)，民航局提出之二位元(2 bits)之閒置字元顯係變更雙方1984年2月9日達成之協議(即符合CCITTX.25 LAP-B規格之一位元組)，該變更自屬約外要求。

⒉查基本需求規章並未規定、要求長程資訊終端機(RemoteData Terminal)之系統設計中應包括區分方位計畫(Sectorization Plan)。惟中華民國空軍於1984年8月15日會議中提出於長程資訊終端機之系統設計中加入區分方位計畫之要求，然洛克希德公司當時即表明立場，認為加入區分方位計畫之要求僅供參考而已，洛克希德公司並未同意，故雙方就此並未達成協議。民航局嗣雖主張雙方有達成協議，先後於1985年9月26日、1986年3月21日以函文方式要求洛克希德公司於長程資訊終端機之系統設計中加入區分方位計畫，嗣民航局於其1986年8月5日函文就介面控制文件修訂版所要求解決之事項中，則未列入前開區分方位計畫之約外要求，由此可證民航局於1986年8月5日函文自承其先前提出之要求係屬約外。

⒊初期介面控制文件第1.2節「範圍(Scope)」規定，所謂資料傳送，包含「交換雙方之作業資料，含TACC系統與空軍戰管中心之飛航資料及航跡資料，惟該第1.2節僅規定、要求在正常作業情況下，TACC系統與AACC系統間資料之傳送，並不包含當系統啟動或重新啟動之情形，民航局卻於1985年9月26日函文提出「當空軍戰管中心之軟體啟動/重新啟動，空軍戰管中心系統即須發出要求飛行計畫之訊息予TACC系統，以要求所有當時及尚未提出(pending)之飛行計畫之資訊，均由TACC系統送出」之要求，然初期介面控制文件就此既未有規定或要求，民航局提出該要求自屬約外要求。嗣洛克希德公司於1985年10月7日、8日會議中，表示「重新啟動之資料轉移」係屬約外要求，民航局始指示洛克希德公司無需新增該功能，乃自承其先前所提此等要求已逾系爭航管契約(初期介面控制文件)之規定而屬約外要求。

⒋民航局於1984年6月28日每月介面會議時，以手寫修改方式，針對其1983年1月初期介面控制文件提出草擬變更版本。依該草擬變更版本，其中附表5-4並未規定、要求TACC系統傳送至空軍戰管中心之訊息中，應包括「在指出訊息中對完整資料欄之回應(response to FDB request in"Point-out")、衝突警訊(conflict alert)、地形障礙意外與領空保護(TOHAP)及緊急訊號(emergency)」等訊息，惟民航局竟於洛克希德公司依照初期介面控制文件草擬變更版本，於1985年1月10日提出介面控制文件之後八個月，突於其1985年9月26日函文，要求洛克希德公司新增「在指出訊息中對完整資料欄之回應(response to FDB request in"Point-out")及衝突警訊(conflictalert)、地形障礙意外與領空保護(TOHAP)及緊急訊號(emergency)等訊息」，並以不予核准介面控制文件相脅，該等要求顯已逾系爭航管契約(初期介面控制文件草擬變更版本)而屬約外要求。

B.民航局等則以：

⒈兩造雖於73年2月9日改採CCITT X.25標準及其LAP-B介面規則，但並不代表無庸與ADC系統相容，此經我國空軍於73年6月28日開會反應後，自應由提議改採CCITT X.25標準及LAP-B介面規則之洛克希德公司負責解決相容性技術問題，並非約外要求；且該問題發生於74年8月8日兩造間第四次契約變更延長交期前，洛克希德公司在契約變更時，自得且應已將之納為延長交期之考量，而不復為本件遲延之宥恕事由。況LAP-B規則(1位元組)既非介面控制文件所規定之標準，亦非民航局所提出之標準，而係洛克希德公司提議採行之，自應由其解決與空軍戰管中心（Air Defense Center，簡稱ADC）相容性之技術問題，應非屬約外要求。

⒉TACC／ADC間介面功能所應具之「(長程資訊終端)分區計畫功能」(sectorizationplan，亦稱「空域劃分計畫」功能)，其目的在使系爭航管自動化系統能與空軍戰管中心ADC，彼此交換管制空域(Sector)中關於禁航區範圍之資訊及功能相互協調，協助管制員得以事先規劃、妥為實施航空管制作為，且為TACC規格書第6.3節及圖表6-6所定之功能性需求(詳上證164號)，並非約外要求，若系爭航管自動化系統不具備此一功能，管制員將無從了解軍方因演習、訓練或防空等因素所劃定之禁航區範圍，恐衍生重大飛安事故與外交糾紛。

⒊民航局於74年9月26日對上開兩系統介面之功能，表示：「當ADC之軟體啟動，ADC即需發出要求飛行計畫之訊息予TACC，要求所有當時及待傳(Pending)之飛行計畫資訊，均由TACC提出」等語，旨在確保透過該介面可互相交換兩系統之作業資料，蓋以若該介面不具備此項功能，將無法保證ADC系統在重新啟動後，能收到所有之(含尚未提出)飛行計畫訊息，將嚴重影響飛航安全，故民航局之上開表示，無非就系爭航管自動化系統依介面控制文件第1.2條等所應具備之功能進行闡述，並無任何提出約外要求可言。且洛克希德公司自始至終並未將此功能納入其設計中，卻一再以本項爭議為其遲延之辯解。

⒋按介面控制文件第5.2.2.1.1節規定：「(指出訊息)2.相關航跡之完整資料欄應能以『指出訊息』互相傳送。3.對相關航跡之完整資料欄之要求，亦應能以『指出訊息』互相傳送」，第5.2.2.2節則規定：「因飛航意外、地形及障礙意外、領空侵入及緊急情形等，由TACC系統發出之警示訊息，應能傳輸至ADC系統」。民航局於74年9月26日就TACC與ADC間之資料傳輸，表示：「在TACC傳送訊息至ADC時，應能在指出訊息下回覆完整資料欄，且應包括衝突警訊(Conflict Alert)、地形/障礙及領空保護功能(TOHAP，Terrain and obstacle hazardand airspace protection )與緊急訊息(Emergency)」等語，無非在闡述介面控制文件第5.2.2.1.1節、第5.2.2.2節與第1.2條等之內容，以確保兩系統間之資料傳輸之及時性與充分性而已，非提出約外要求等語，資為抗辯。經查：

⒈洛克希德公司主張民航局於系爭航管工程執行中，提出「修改一位元組(1 byte)之閒置字元(idle character)為二位元(2bits)」乃約外要求。惟查：兩造雖於民國73年2月9日會議後改採國際電報電話諮詢委員會（CCITT）X.25中聯結存取程序B版即（CCITT X.25 LAP-B）之高階資料聯結控制規則，惟基於飛航管理之正確性、時效性及安全性，仍應與ADC系統相容，此於73年6月28日開會後，自應由提議改採CCITT X.25標準及LAP-B介面規則之洛克希德公司負責解決其與ADC系統間之相容性技術問題，尚不得以民航局與軍方迄未達成協議云云卸責。另參諸系爭契約文件中之「招標文件」（效力詳如㈠⒋之說明）CAA-E-IC-001, Rev.2「航路與防空自動化系統之銜接控制文件」(下稱介面控制文件)第1.2條規定：「本文件定義了台北區管中心(TACC)與戰管中心(ADC)間及時、充分之資料傳遞所必須之軟硬體特性及操作諸元。『資料傳輸』包含自ADC傳輸長程雷達資料至TACC，及含飛行資料與航跡資料在內之操作資料交換」，第1.3條亦規定：「TACC與ADC間介面之功能，應受介面之基本目標所限制：1.介面之設計，應在符合介面要求之前提下，將成本上之衝擊降至最低。2.既存之標準應在建置介面要求時，盡量援用」(詳上證78號，見本院卷4第599至601頁)。且此部分經送中科院鑑定結果，亦認為於基本需求規章中提及有涉及軍方之介面時，應盡可能使用當時已使用之標準，故民航局於73年6月28日會議記錄中所要求CCITTX.25介面規則應與空軍戰管中心系統相容及使用128位元之訊息格式，並未超出台北區管中心基本需求規章介面控制文件之範圍，且LAP-B規格並非民航局所提出，亦未獲民航局之同意（見外放之中科院鑑定報告第11頁），故洛克希德公司主張此部分屬約外需求，應非可採。況上開問題發生於74年8月8日兩造間第四次契約變更延長交期前，洛克希德公司在契約變更時，自應將之納為延長交期之考量，而不復為本件遲延之宥恕事由。另成大鑑定報告就此部分未及斟酌本院上開認定，尚無可採。

⒉洛克希德公司主張基本需求規章並未規定或要求長程資訊終端機之系統設計中應包括區分方位計畫，故此部分亦應屬約外要求云云。惟查：系爭契約空防介面控制文件中，固無提及長程資訊終端之區分方位計畫，然其目的在使系爭航管自動化系統能與空軍戰管中心ADC，彼此交換管制空域中關於禁航區範圍之資訊及功能相互協調，並為TACC規格書第6.3節及圖表6-6所訂之功能性需求（詳上證164號，見本院卷15第61至63頁），對於飛航安全至關重要。且該系統之建置係藉由系統分析掌握民航局之需求，並透過軟體之初步設計與細部設計將需求轉化為最終之軟體系統，則細部設計本難期於初步設計完成前或簽約時即可全部確定，細部設定如未超逾系統原預定之功能，不得以其未於簽約當時提出即謂約外需求。而本件經送中科院鑑定結果，亦認「民航局於本項所要求之介面功能屬細部功能，細部功能需求之作為在細部設計中須經雙方研討後確定，必須再進一步於PDR階段再加以定義方能明確，所以在基本需求規章對於細部功能需求有說明不足之情形係屬正常」、「依據上述鑑定說明，民航局74年9月26日所要求之「長程資訊終端之區分方位計畫」並無超出台北區管中心基本需求規章之契約範圍」（見外放之中科院鑑定報告第8、9頁），雖洛克希德公司稱於73年8月15日會議中已主張加入區分方位計畫之要求僅供「參考」而已，惟洛克希德公司乃專業廠商，細部功能需求之作為在細部設計中須經雙方研討後確定，必須再進一步於PDR、CDR會議再加以定義方能明確，已如前中科院鑑定內容所述，故洛克希德公司主張該「區分方位計畫」屬約外要求，應非可採。至於成大鑑定報告就此部分未及斟酌本院上開認定，尚無可採。

⒊洛克希德公司主張民航局於系爭航管工程執行中，提出系爭航管契約(初期介面控制文件)未規定、要求之「當空軍戰管中心之軟體啟動/重新啟動，空軍戰管中心系統即須發出要求飛行計畫之訊息予TACC系統，以要求所有當時及尚未提出(pending) 之飛行計畫之資訊，均由TACC系統送出」(以下稱「重新啟動之資料轉移」)之約外要求，且民航局於73年10月7日、8日會議始指示洛克希德公司無需新增該功能，乃自承其先前所提此等要求已逾系爭航管契約云云。惟查：介面控制文件第1.2條規定TACC與ADC間應能及時且充分地傳遞相關資訊(詳上證78號，見本院卷4第599至601頁)，則在ADC重新啟動後，如無法及時收到所有之(含尚未提出)飛行計畫訊息，將不能充分掌握航空管制之實況而嚴重影響飛航安全，故系爭航管自動化系統應具備在ADC重新啟動而要求提供資訊時，送出所有(含尚未提出即Pending)飛行計畫之功能，且中科院之鑑定報告亦說明TACC及AACC之介面資料，確有包含TACC接收長程雷達信號，以及互相交換雙方作業資料之需求項目，若無此全部資訊傳送之功能，將無法保證AACC收到所有當時及尚未提出之飛行計畫訊息，進而影響飛航安全（見外放之中科院鑑定報告第7至8頁）。況民航局於73年10月7日、8日會議指示洛克希德公司無需「新增」該功能，乃為契約時程之故，尚難謂該功能自始即為約外要求，故洛克希德公司之主張，自非可採。至於成大鑑定報告就此部分未及斟酌本院上開認定，而遽以兩造皆未能持續處理該項爭議為由，逕認兩造應各負一半之過失比例，尚屬可議；再者，洛克希德公司主張重新啟動功能屬約外事項因民航局要求增加該等功能使系爭航管工程進度遲延云云，惟洛克希德公司自始未將該功能納入設計中，尚難認為其有因該項爭議而延遲工程進度之可能性，然成大鑑定報告並未斟酌此一事實，故其鑑定結論應不可採。

⒋按介面控制文件第5.2.2.1.1節規定：「(指出訊息)2.相關航跡之完整資料欄應能以『指出訊息』互相傳送。3.對相關航跡之完整資料欄之要求，亦應能以『指出訊息』互相傳送」，第5.2.2.2節則規定：「因飛航意外、地形及障礙意外、領空侵入及緊急情形等，由TACC系統發出之警示訊息，應能傳輸至ADC系統」(詳上證81號。見本院卷4第607至612頁)，故該等功能應屬基於飛航安全之基本要求，則民航局要求洛克希德公司「在指出訊息中對完整資料欄之回應(response to FDBrequest in"Point-out")及衝突警訊(conflict alert)、地形障礙意外與領空保護(TOHAP)及緊急訊號(emergency)等訊息」非屬約外要求。雖洛克希德公司該等功能並未於規定於系爭航管契約(初期介面控制文件草擬變更版本)而屬約外要求，惟系爭契約之目的乃建構一完善之航空管理系統，而航空管理系統之建構應以飛航安全為目的及最基本考量。系爭航管系統未能就飛航意外、地形及障礙意外、領空侵入及其他緊急情形等，由TACC發出警示訊息傳輸至ADC系統，則尚難認為合於飛航安全，有違系爭契約之目的。況成大及中科院之鑑定報告皆認為該等功能皆於系爭契約之基本需求規章有明確、詳細之說明，故應認為該等功能非屬約外要求，洛克希德公司之主張應非可採。

⒌另成大及中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開㈡⒈、⒉、⒊、⒋所述），就過失比例部分尚無庸參考，併予敘明。

⒍關於洛克希德公司於103年5月2日民事調查證據聲請續㈡狀中，請求成大航太所補充說明之詢問事項A、B、C，已分別於上開㈡⒉、⒊、⒈部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

㈢第一大項第三小項關於洛克希德公司主張「狀況顯示器列表曖昧不明及擴張」共三部分：A.洛克希德公司主張：

⒈系爭航管契約附件GFE開宗明義規定：「以下列表為應由民航局提出，以支援TACC以及TCC航管系統發展及執行之項目」，由該定義可知，凡列於GFE下之項目，均為應由民航局提出之項目，以支援系爭航管工程之發展與完成。另按TACC規格書就狀況顯示器列表之格式及內容之說明，未有規定或極為有限，以「海岸/暫止列表」為例，在TACC規格書附表3-2「狀況顯示器操縱台內容表」中，沒有任何格式及內容之說明，因此，GFE前言、GFE第18條第C項規定，該等項目應由民航局於系爭航管契約訂立後2個月內(即1984年2月20日)透過顯示器設計會議進行定義，並於3個月內(即1984年3月20日)提出。然民航局遲至1984年3月6日至9日始舉行第1次顯示器設計會議，且未提出任何列表之格式及內容予洛克希德，嗣於1984年5月3日至5日之第2次顯示器設計會議中，僅就「起飛列表」、「降落列表」、「暫時控制列表」及海岸/暫止列表」提出有限、不完整之資訊，就「地形/障礙意外及領空保護列表」及「飛航意外列表」則仍未提出任何資訊。由前揭2次會議紀錄可知，民航局確未依GFE前言、GFE第18條第C項規定，於1984年3月20日前提出狀況顯示器列表之格式及內容，已違反其於GFE項下之義務。

⒉基本需求規章並未規定、要求起飛列表、降落列表、海岸/暫止列表等項應附加入口符號。惟民航局於其1984年10月18日函文有關TACC PDR待辦事項第36號之意見中，提出於「起飛列表、降落列表、海岸/暫止列表等項附加入口符號」之約外要求，嗣經洛克希德公司於1984年11月9日函文提出立場說明書，表示TACC規格書僅規定、要求起飛列表、降落列表、海岸/暫止列表List)等項須有「定位入口符號」，然並未規定、要求該等列表應附加入口符號，民航局所為上開要求與TACC規格書不符後，民航局始以1984年12月8日函文有關TACCPDR待辦事項第36號之意見通知洛克希德公司，表示同意洛克希德公司所為僅有「定位入口符號」之設計，由此可證民航局因其先前所為此等要求已逾TACC規格書之規定而屬約外要求，故而同意該等設計。

⒊TACC規格書附表3-2載明「降落列表」為4個次列表，然民航局於其1985年1月11日函文有關TACC PDR待辦事項第36號之意見中，提出在「降落列表列出6到7個次列表」之要求，該等要求已逾越TACC規格書之範圍而屬約外要求。洛克希德公司嗣以1985年7月10日、1985年9月5日等函文多次拒絕民航局「降落列表列出6到7個次列表」之約外要求，惟民航局仍以1985年9月12日函文強行要求洛克希德公司在降落列表列出6到7個次列表。按洛克希德公司本已基於顯示器設計會議結論，進行狀況顯示器韌體之設計，民航局要求洛克希德公司在降落列表列出6到7個次列表，勢將影響洛克希德公司就狀況顯示器所為之韌體設計；且為避免系爭航管工程延宕，洛克希德公司於該1985年10月8日函文表示將於民航局明確指示降落列表列出6個以上次列表之要求是否為約外要求、以及是否新增該約外要求，並依系爭航管契約之相關規定辦理工程變更後，始於降落列表之設計中，列出較多之次列表。經雙方多次長期、反覆澄清、討論，民航局始承認此係約外要求，並指示中信局提出1987年1月8日變更指令中，表明TACC PDR待辦事項第36號有關顯示器列表之約外要求(包含6個以上次列表)，應適用系爭闡明條款第4.1條(約外要求)之規定。

B.民航局等則以：

⒈按系爭合約文件GFE第18條規定，狀況顯示器格式之定義，應在簽約後二個月由民航局、洛克希德公司及其供應商舉行會議律定，而洛克希德公司之投標文件第二冊第2-50頁亦明定，顯示器之最終格式應於PDR中定案，是關於狀況顯示器之具體功能與最終格式，依約本待兩造於PDR中共同確定。

⒉民航局於73年10月18日表示，關於起飛、降落及海岸/暫止等各類列表均應附加入口符號，且該入口符號應列為上述列表之第一次序等語，不過重申TACC規格書第3.7.3.3.4.6.5.5.1以下之規定而已，並未提出任何約外要求，就此，中科院亦認定民航局之說明為合理，並未超出基本需求規章之範圍，且本項爭議發生後，民航局已即刻與洛克希德公司進行確認、釐清，與本件遲延間並無因果關係，洛克希得公司不得據以主張適用闡明條款第4.1條或第4.2條各款宥恕事由。

⒊民航局於74年1月11日以函文，針對PDR會議之待辦事項36，表示狀況顯示器之降落列表應列出6至7個次列表等語，洛克希德公司已回函表示同意，是降落列表應具備6至7個次列表，均已由兩造合意變更，而無所謂約外要求之問題，更經中科院鑑定報告認定在案，且依系爭契約GFE第18項及洛克希德公司投標文件相關規定，SD降落列表之格式應由兩造於PDR中共同確定，故不論TACC規格書就SD降落列表之次列表數量如何規定，均應由洛克希德公司負責於PDR階段掌握、分析及理清民航局就航空管制之業務需求等因素後，由兩造共同確定SD降落列表之次列表數量，而無所謂約外要求或變更設計之問題，是民航局於74年1月11日以函文之目的無非在使洛克希德公司了解實際之民航作業需求，並協助其進行設計規劃，並不構成約外要求，況本件爭議係發生於74年8月8日之前，洛克希德公司自得且應將之納為第四次契約變更延長18個月交期之考量，而不復為本件遲延之宥恕事由等語，資為抗辯。經查：

⒈民航局是否未依GFE前言、GFE第18條第C項規定，如期提出狀況顯示器列表之格式及內容？

⑴洛克希德公司主張基本需求規章中關於狀況顯示器列表之需求及降落、暫時控制、起飛等等規定，缺乏對於列表格式及功能處理之說明、或說明不足、模糊致其無法或難以從事電腦程式之發展，且民航局未依GFE前言、GFE第18條第C項規定，如期提出狀況顯示器列表之格式及內容，違反其於GFE項下之義務云云。

⑵經查：按系爭航管自動化系統應採由上而下之建置方式，並藉由PDR與CDR會議，將民航局對系爭航管自動化系統之需求轉換為具體可行之設計藍圖，故基本需求規章所定義的項目多為原則性的功能，並非詳列功能所需之詳細格式與處理方法，相關詳細格式與處理方法應於後續PDR、CDR階段工作中加以定義，是故基本需求規章如有抽象、說明不足或模糊之情形，應屬正常狀況。

⑶且系爭合約文件GFE第18條規定，狀況顯示器格式之定義，應在簽約後二個月由民航局、洛克希德公司及其供應商舉行會議確定(詳上證82號，見本院卷4第613至614頁)，而洛克希德公司之投標文件第二冊第2-50頁亦明定，顯示器之最終格式應於PDR中定案(詳上證83號，本院卷4第614-1至615頁)，是關於狀況顯示器之具體功能與最終格式，應待兩造於PDR中共同確定。況系爭航管契約曾於74年8月8日第四次修正延長完工期限，而上開顯示器格式之疑義早在締約之初即已存在，上開疑義確有致生工程延宕之虞，洛克希德公司應可於延長工期事項中將之列入考量，而不應為本件遲延之宥恕事由。

⑷再者，成大及中科院之鑑定報告亦認為洛克希德公司為專業廠商，就該項爭議，對於民航局之詳細需求，應負有主動溝通、澄清之責任（見外放之成大鑑定報告第15頁、中科院鑑定報告第15頁）。綜上所述，應認為該項爭議非屬約外要求，洛克希德公司之主張顯無足採。

⒉民航局於系爭航管工程執行中，提出「起飛列表、降落列表、海岸/暫止列表等項附加入口符號，是否為約外要求？

⑴洛克希德公司主張基本需求規章並未規定起飛列表、降落列表、海岸/暫止列表等項應附加入口符號，民航局於73年10月18日函文始提出上開列表附加入口符號，應屬約外要求云云。

⑵經查：TACC規格書第3.7.3.3.4.6.5.5節、第3.7.3.3.4.6.5.5.1節雖未有「入口符號（Entry Symbols）」之記載，惟在執行PDR、CDR程序以確定並落實使用者需求之契約特性下，不得僅以細部需求未於規格書中詳列即屬約外要求。民航局抗辯其於73年10月18日函表示關於起飛、降落及海岸／暫止等各類列表均應附加入口符號，不過重申TACC規格書第3.7.3.3.4.6.5.5.1以下之規定而已，並非提出約外要求，非無可取。

⑶且成大之鑑定報告認為「起飛列表」為合約中之基本項目，至於列表之內容與多寡為合約執行之細節問題（見外放之成大鑑定報告第17頁），中科院鑑定報告亦認為基本需求規章係說明系統之基本功能需求，詳細之系統需求則須在後續的PDR、CDR中經雙方研討後確定，且洛克希德公司在投標書中亦有說明系統顯示功能在PDR時才做最後確認（如前㈢⒈⑶所述），因此有關該項爭議並無超出基本需求規章之契約範圍（見外放之中科院鑑定報告第17頁）。綜上所述，尚難認為該項爭議為約外需求，洛克希德公司之主張應非可採。

⒊民航局於於系爭航管工程執行中，提出「降落列表中應列出六至七個次列表」，是否為約外要求？

⑴洛克希德公司主張TACC規格書附表3-2載明「降落列表」為4個次列表，民航局於74年1月11日函文中要求在降落列表中應列出6至7個次列表，已超逾TACC規格書之範圍，而屬約外要求云云。

⑵經查：系爭航管自動化系統之建置係藉由系統分析掌握民航局之需求，基本需求規章多屬原則性的功能，細部功能必須於後續PDR、CDR階段加以確定，已如前㈢⒈⑵所述，且洛克希德公司於74年10月8日函覆民航局同意將「降落列表」之次列表數量增加為6項，並於開庭時經本院確認在案（詳100年11月25日筆錄，見本院卷4第631頁)，洛克希德公司空言民航局已承認此係約外要求，然並未舉證以實其說，洵屬無據，故就此部分尚難認係約外要求。

⑶況就此部分中科院鑑定報告認為詳細需求應在後續之PDR、CDR階段中予以澄清律定，因此民航局回函所要求在降落列表應列出6至7個次列表，雖與台北區管中心基本需求規章範圍不一致（只訂定4個次列表），但仍屬合理。且洛克希德公司於民國74年10月8日去函民航局，表示同意接受將降落列表增加成6個次列表，既然洛克希德公司同意接受此項需求，則民航局提出此一需求沒有超出基本需求規章之契約範圍（見外放之中科院鑑定報告第17至18頁），成大鑑定報告亦認為「起飛列表」為合約中的基本項目，至於列表內容與多寡，為合約執行之細節問題等語（見外放鑑定報告第17頁）。綜上所述，應認為洛克希德公司之主張尚無足取，該爭議非屬約外要求。

⒋另成大及中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開㈢⒈、⒉、⒊、所述），就過失比例部分尚無庸參考，併予敘明。

⒌關於洛克希德公司於102年8月6日民事調查證據聲請狀中，請求成大航太所補充說明之詢問事項，已於上開㈢⒊部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

㈣第一大項第四小項關於洛克希德公司主張「雷達資訊關連之需求曖昧不明及矛盾」部分：A.洛克希德公司主張：

⒈TACC規格書中雖有針對「關連處理」、「最佳關連」、「延遲時間」作出說明及訂定相關規定，然於前揭規格書第3.2.1.2.2節規定TACC系統接收到長程雷達所偵測到之航機資訊後，須於1秒內完成該筆航機資訊處理(其中包括選取「最佳關連」之處理)並顯示於管制員席位之顯示器，此為技術上不可能達成之要求，且洛克希德公司持續致力於解決TACC規格書關於「最佳關連」與「延遲時間」之規定曖昧不明及矛盾。經兩造費時澄清、討論TACC規格書有關雷達資料關連需求之曖昧不明及矛盾，民航局及其顧問邁特公司終而同意放寬「延遲時間」之限制，並承認該一秒之延遲時間之要求，於技術上不可能達成，故同意取得雷達資料及進行最佳關連之處理時間不予計入。再者，民航局核准之TACC-1040文件第5.5.6節，亦規定「關連優先次序之擴張」、「額外關連之可能性」等迥異於TACC規格書之規格，基此亦足徵TACC規格書有關「最佳關連」與「延遲時間」之規格，確有相互矛盾之情形，而應修改。

⒉查TACC規格書並未規定、要求「臺北飛行情報區軍機滯空待命航線」列入TACC-1040文件，詎民航局於核准1986年9月23日TACC-1040文件11個月後，突然改弦易轍於其1987年8月20日函文中提出「附件2為應納入文件第7節作為表格之臺北飛行情報區軍機滯空待命航線之影本」，指示洛克希德公司將「臺北飛行情報區軍機滯空待命航線」列入TACC-1040文件，民航局之要求已逾越TACC規格書而屬約外要求。

B.民航局等則以：

⒈按系爭航管自動化系統應採由上而下之建置方式，在PDR與CDR中，將買受人對系爭航管自動化系統之需求轉換為具體可行之設計藍圖，是就雷達資訊關連需求之基本需求規章具抽象性乙節，實為正常狀況，並非需求曖昧不明，且民航局等所為具體說明澄清亦不構成約外要求，洛克希德公司更有義務主動於後續之PDR與CDR會議中積極澄清。另按TACC規格書規定雷達(LRR)在取得目標位置之資訊後，應於一秒內顯示於管制員之席位(下稱資料顯示功能)，次按TACC規格書就「最佳關連」之處理程序(下稱關連程序)規定在主要監視雷達及次級監視雷達均獲得同一航空器之資訊時，雖形式上產生二筆以上之不同航跡資料，但實質上卻均指涉同一航空器，故須就各該不同之資料進行比較、修正，以決定作為顯示目標物航跡之最適資料為何，管制員方能依據該「最佳關連」之航跡資料實施航空管制作為，故TACC規格書之關連程序功能，係指系爭航管自動化系統「處理複數航跡資料，並從中選取最適於顯示之航跡資料」之功能(下稱資料處理功能)。資料處理功能係指系爭航管自動化系統處理複數航跡資料，並從中決定最適顯示之航跡資料而言，而在相關航跡資料經過關連程序之處理後，則有顯示於管制員席位之需求即資料顯示功能，是資料處理功能與資料顯示功能間，不但互相獨立而無任何曖昧矛盾或不能成立之問題，更為相輔相成之兩項功能，因為顯示於管制員席位之相關航跡，必須為經關連程序處理後之最佳航跡，而非未經任何處理之原始雷達資料，方足使管制員據以實施航空管制作為，是系爭航管自動化系統在接收LRR資料至顯示目標物航跡之一秒內，必須進行關連程序之處理，可堪認定，此業經中科院鑑定認定此二者為截然不同的需求，故並無矛盾而無法達成之處」，而成大鑑定報告更認定「最佳關連」與「延遲時間」兩者係技術建構上所需相輔相成的需求。為達到「最佳關連」可能在電腦作業上會導致「延遲時間」較長，但是技術上的問題應由承包之工程技術人員予以解決，故TACC規格書關於資料處理功能與資料顯示功能之相關規定，實無任何互相抵觸或無法達成之問題。

⒉系爭航管自動化系統之資料庫應納入台北飛航情報區內各種航管資料，為兩造不爭執，而TACC規格書第3.1.1.1節進一步明定：系爭系統須能就TACC所轄空域內之民用航空器與軍用航空器提供下述之飛航服務，可知系爭系統除民航機以外，亦應將軍用航空器之相關資訊納入處理，以利事先規劃及實施航空管制措施，惟洛克希德公司卻疏未將之納入設計，民航局為協助進行設計，乃依洛克希德公司所請，蒐集國內有關軍機滯空待命航線之相關資料並提醒洛克希德公司應將之納入TACC/1040文件，於76年8月20日去函表示應將台北飛航情報區軍機滯空待命航線列入TACC/1040文件中等語，徵諸前揭說明，實無涉所謂約外要求等語，資為抗辯。經查：

⒈TACC基本規格需求中關於「最佳關連」與「延遲時間」之規定，是否曖昧不明及相互矛盾？

⑴按雷達資料關連，係指多數雷達資料間之比較，以確定何者得以最精確地偵測、預測航機之位置。而「關連處理」依TACC規格書第3.7.3.3.3.3節之規定，係指將初始偵測雷達及次位偵測雷達所偵測出之特定航機之位置進行比較，以確定何資訊最能精確顯示、偵測、預測該航機之最新航路，而「最佳關連」依TACC規格書第3.7.3.3.3.3.5節規定，係指「關連處理」應藉由建立航跡的預測位置搜尋範圍、使得預測時掃瞄到之數據報告落入其中一個搜尋範圍，以取得一個與時間數據配合之「最佳關連」（見外放TACC規格書第3-290頁），簡言之，「關連處理」即從眾多雷達資料中，選擇並決定那一個雷達資料為「最佳關連」、最能精準辨識出一航機位置之過程，亦即假設有好幾個雷達，當一個飛機飛過去之後，上開數個雷達皆會捕捉到，若兩個雷達即會捕捉到兩個航機的訊號，然事實上只有一架而已，那對管制員來說，他只要知道這一個航空器是什麼，在那裡就可以，所以必須把這兩個航機訊號，做一個比較，選取最適於顯示的航機顯示出來，這就是「最佳關連」（詳本院100年3月4日準備程序筆錄第4頁，民航局之陳述，見本院卷1第235頁背面）。另所謂「延遲時間」，係指收到雷達數據資料到資料傳送到顯示器上之時間，依TACC規格書第3.2.1.2.2節規定，TACC系統於接收數位長程雷達資料和定位符號在10浬範圍外，自長程雷達傳送至顯示器上之延遲時間不得有重大延遲（少於1秒）」（見外放TACC規格書第3-27頁），亦即它與「最佳關連」是一個相輔相成的功能，因為處理資料之後若不立即顯示出來，那處理這個資料就無意義了，管制人員就是要在這個螢幕上看到這個航機移動才能進行管制，否則飛機飛行那麼快，若處理完後不立刻顯示即會影響飛航安全（詳本院100年3月4日準備程序筆錄第4頁，見本院卷1第235頁背面）。綜上所陳，可知「最佳關連」與「延遲時間」均為數據轉換與傳送之技術問題，惟兩者所對應之需求並不相同，於此合先敘明。

⑵洛克希德公司主張TACC規格書於第3.7.3.3.3.3節、第3.7.3.3.3.3.5節雖規定需選取航跡之「最佳關連」，然於第3.2.1.2.2節關於「遲延時間」則規定TACC系統接收到長程雷達所偵測到之航機資訊後，須於1秒內完成該筆航機資訊處理並顯示於管制員席位之顯示器，此為技術上不可能達成之要求，故TACC基本規格需求上開關於「最佳關連」與「延遲時間」之規定，曖昧不明及相互矛盾云云。經查：此部分根據中科院鑑定結果，認「最佳關連」與「延遲時間」為截然不同的需求，故並無矛盾而無法達成之處，而雷達所測飛機資料，其航跡符號應於一秒鐘內顯示在雷達顯示幕上，此需求與最佳關聯之需求，並未相牴觸，故並無矛盾而無法達成之處（見外放之中科院鑑定報告第22頁）。而成大航太鑑定報告，亦認為「最佳關連」與「延遲時間」之間的問題在技術上的發展，兩者均為數據轉換與傳送上所需訂定的需求規範，在軟體上延遲時間僅唯一個單一指令的修改即可達成的，「最佳關連」與「延遲時間」的訂定並不衝突（見外放之成大鑑定報告第20頁），故洛克希德公司主張TACC基本規格需求中關於「最佳關連」與「延遲時間」之規定，曖昧不明及相互矛盾，並無足取。

⑶另洛克希德公司雖以成大鑑定報告認「航空中長程雷達之技術，雷達訊息之更新率為5秒至7秒之時間」等語，主張基本需求規章規定在只有一個最佳關連下遲延時間應少於1秒之要求，為技術上不可能達成之要求云云。惟成大鑑定報告既稱5秒至7秒為「更新率」之時間，則其所說明應者為雷達之目標獲取時間，亦即雷達旋轉360度以獲取飛行標的之時間間隔，與TACC系統要求之雷達接受資訊後最佳關連遲延時間，乃資料處理之時間，應屬二事，就此洛克希德公司容有誤解；況洛克希德公司於投標文件第二冊第1.5節已表明其能完全履行TACC規格書所定之執行需求，而該等需求業經列明於表格1-6至1-9。而細繹其表格1-8之內容，明載TACC規格書第3.2.1.2.2節第1點「接收LRR資料以至顯示航跡之位置符號」之功能性需求僅需時一秒（見外放投標文件第二冊第1-33頁）。洛克希德公司於投標文件第二冊第1.5.1節亦表明其電腦運作效能須足以使系爭系統在一秒甚至一秒以內，完成接收雷達資料並顯示關連航跡之需求（見外放投標文件第二冊第1-30頁）。且於投標文件第二冊第3.8.1節「執行時間分析」中詳列接收LRR資料、處理完畢及顯示航跡之位置符號所需各階段及執行時間，而依洛克希德公司分析結果，完成關連程序約需0.001秒（即1000usec）（見外放投標文件第3-149頁），另依投標文件第二冊第3-153頁記載完整執行接收LRR資料、處理完畢及示航跡之全部時間為0.734秒，洛克希德公司更於投標文件第二冊第3.8.1.1.2節表示依其分析結果，其達成執行之時間得小於一秒；嗣於73年8月30日PDR會議中，更以手繪表格之方式，說明其得於0.677秒內完成接收、處理及顯示航空器雷達資料（詳上證30號，見本院卷1第540至550頁），則其主張1秒之遲延時間為技術上不可能達成之要求，並以此主張、TACC基本規格需求中關於「最佳關連」與「延遲時間」之規定曖昧不明及相互矛盾，其得依闡明條款第4.2條第1項第4、6款規定，調整完工期限，應非可取。

⒉民航局於要求在TACC/1040文件第7段中列入「台北飛行情報區軍機滯空待命航線」是否為約外要求？

⑴洛克希德公司主張民航局於75年9月23日核准其所提編號TACC-1040之作業電腦程式功能規格文件後，又於76年8月20日要求將基本需求規章未規定之「台北飛行情報區軍機滯空待命航線」列入TACC-1040文件，應屬約外要求云云。

⑵經查：基於飛航安全之目的，TACC系統自應與ADC系統相容，已詳如前㈡（即「空軍航管中心介面連接之定義」爭議部分）

⒈所述。況此部分中科院鑑定報告，認「洛克希德公司原證34號內所顯示之內容，與『在台北飛航情報區內實施為軍事飛機暫時控制方式』之陳述並無涉及，應無約外要求之情事。根據原證124號資料顯示，民航局所提供之資料係屬『台北飛航情報區軍機滯空待命航線』資料庫之補充說明資料，非屬約外需求。依據上述鑑定說明，民航局於76年8月20日發函給洛克希德公司要求在TACC/1040文件第七段中列入『在台北飛航情報區內實施為軍事飛機暫時控制方式』並非約外需求。」（見外放之中科院鑑定報告第24頁）。另成大航太所補充鑑定報告亦認「滯空待命航線應納入原規章中」（見外放之成大補充鑑定報告第22頁），故洛克希德公司之主張，應無足取。

⒊另成大及中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開㈣⒈、⒉所述），就過失比例部分尚無庸參考，併予敘明。

⒋關於洛克希德公司於103年5月2日民事調查續㈡狀中，請求成大航太所補充說明之詢問事項，已於上開㈣⒈部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

⒌最高法院就該部分發回意旨雖指出：「關於附表一編號一之㈣「雷達資訊關連之需求曖昧不明及矛盾」部分，查系爭航管契約係承攬性質，既為原審所確定之事實（原判決二七頁），則系爭航管工程，必有賴於民航局先提出詳盡之系統基本需求規章，上訴人始得據以設計、開發及執行，民航局依民法第五百零七條第一項規定，對承攬人即負有定作人主給付義務以外為「指示」此部分雷達資訊關連需求之協力義務，且中信局將「基本需求規章」列為招標文件之一，更應以之作為雙方行使權利及履行義務之鵠的。原審未遑詳究民航局所提此項需求規章有無不明及矛盾情形？僅以美商（港商）洛克公司於簽約前與民航局舉行二十七次澄清會議，未就此不明及矛盾提出討論或質疑，遽認民航局未有系爭闡明條款第4.2條第1項第④款所定之可宥恕事由，不免速斷。...」，惟按，系爭航管自動化系統應採由上而下之建置方式，並藉由PDR與CDR會議，將民航局對系爭航管自動化系統之需求轉換為具體可行之設計藍圖，故基本需求規章所定義的項目多為原則性的功能，並非詳列功能所需之詳細格式與處理方法，相關詳細格式與處理方法應於後續PDR、CDR階段工作中加以定義，是故基本需求規章如有抽象、說明不足或模糊之情形，應屬正常狀況，此已於前述㈢⒈⑵說明；況系爭航管契約內容除招標文件外，依系爭契約附件FORM B之規定，洛克希德公司應遵守包括投標文件在內之一切契約文件(包含但不限於上訴人之招標文件(RFP)、洛克希德公司投標文件、相關軍事規範、兩造所舉行歷次技術澄清會議之書面會議紀錄、闡明摘要及洛克希德公司就自己投標文件所為之闡明等文件)，負責進行相關之分析作業，以建置系爭航管自動化系統，業已於前開㈠⒋說明之，故若招標文件有不完備之處，仍可以其他契約文件補充之；另前開㈣⒈亦已說明「最佳關連」與「延遲時間」之定義，兩者乃不同之需求，故該部份應無任何曖昧不明或互相矛盾之處，併此敘明。

㈤第一大項第五小項關於洛克希德公司主張「完整資料欄之變更需求」共九部分：A.洛克希德公司主張：

⒈TACC規格書所規定之TACC系統完整資料欄與TCC規格書所規定之TCC系統完整資料欄之格式與內容有顯著差異。洛克希德公司於1984年3月顯示器設計會議時，已依TACC規格書、TCC規格書之規定，提出TACC系統及TCC系統之完整資料欄格式，並進行設計工作，然民航局於其1984年11月8日資料文件，要求TCC系統完整資料欄之格式須與TACC系統完整資料欄之格式一致，此一要求顯已違反TCC規格書之規定而屬約外要求。

⒉TACC規格書第3.7.3.3.4.6.4.2.1節「字母與數字構成之完整資料欄格式規定，完整資料欄C欄顯示內容為「據報高度或Ｃ模式高度」、D欄顯示內容則為「地面速度/電腦識別」；惟民航局於1984年11月8日資料文件，要求洛克希德公司將C欄顯示內容變更為「地面速度/電腦識別」，D欄顯示內容則變更為「指定高度」，民航局上開要求，顯與TACC 規格書之規定不符，而屬約外要求。

⒊TACC規格書第3.7.3.3.4.6.4.2.1節「字母與數字構成之完整資料欄格式」規定「完整資料欄之字母數字部分需依下列方式顯示之…字母數字資料之第1行應包含6個以上之字元，第2行則應包含8個以上字元…」，由上開規定可知，TACC規格書規定、要求完整資料欄第2行(按即飛機識別欄）以字母數字顯示之；惟民航局於其1984年12月6日函文，表示飛機識別欄之第一個字元應為字母，其後尾隨使用之字元(至多達6個)應為字母數字或符號「-」，然該符號「-」顯非字母或數字，是民航局之要求已逾越TACC規格書而屬約外要求。洛克希德為基於合作精神，方於1985年1月18日函文同意民航局前開約外要求。

⒋TACC規格書中關於有限資料欄（Limited Data Block）之顯示條件規格曖昧不明甚而相互矛盾，例如有限資料欄應由電腦軟體系統主動(自動)產生，或應於航管人員發出指令時(亦即被動)始產生？就此，TACC規格書第3.7.3.3.4.5.1.3節「依管制疆域選擇資料欄」第4點、第3.7.3.3.4.6.4.3.3節「有限資料欄之顯示條件及路徑」第1點與第3.7.3.3.4.6.4.3.3節第2點乃互相矛盾，TCC規格書第3.7.3.3.4.3.1.3節第4點「依管制疆域選擇資料欄」、第3.7.3.3.4.4.4.3.3節「有限資料欄之顯示條件及路徑」第1點亦與第2點互相矛盾，迺民航局未及時澄清該等矛盾處究應以何者為準，而依系爭闡明條款第4.1條、第4.2條、及第4.3條等規定，以變更指令指示洛克希德公司變更工程(變更TACC規格書及TCC規格書之規定)，並於其1985年7月8日函文，逕自提出、要求如管制席位之識別編號與席位識別編號不相符時，則應自動顯示有限資料欄，致洛克希德公司無所適從。況自技術觀點言，有限資料欄之顯示涉及軟體及韌體之設計，故民航局就有限資料欄之新增要求，不僅為約外要求，且勢須變更原有電腦軟體及韌體之設計，關於本項目洛克希德公司確已依民航局約外要求，指示顯示器製造商美商Magnovox公司施作且變更原有電腦軟體及韌體之設計。

⒌TACC規格書第3.7.3.3.4.6.4.2.2.(3)a規定：「若A欄向左對齊，B欄之內容亦應在B欄內向左對齊之」；第3.7.3.3.4.6.4.2.2.(3)b規定：「若A欄向右對齊，B欄之內容亦應在資料欄第三行之字元位置內向右對齊之」，由該等規定可知，完整資料欄之格式得左右位移。惟民航局於1985年7月8日會議中，片面提出「完整資料欄不得左右位移」之約外要求，要求在完整資料欄中所包含之資料不得在其格式內右移或左移，民航局該等不得左右位移之要求，業已違反TACC規格書、TCC規格書關於完整資料欄之格式得左右位移之規定，而屬約外要求。是以，洛克希德公司於1985年8月16日函文拒絕民航局前開約外要求，迺民航局仍於1985年10月22日函文堅持要求變更設計，洛克希德公司本諸合作之精神及為使工程順利進行，不得已以1985年11月29日函文同意民航局前開約外要求。然僅就本工作項目而論，即已延宕4個月餘(自1985年7月至1985年11月)，該等延宕自已該當系爭闡明條款第4.2條第4款「民航局未能依約及時完成於系爭航管契約下之任何其他義務」、第6款「因任何超出洛克希德公司及／或其等所指定之主要次承包商合理控制範圍外之事件所致之任何遲延」等可宥恕事由。

⒍TACC規格書並未規定、要求完整資料欄中之D欄、E欄、Z欄應有時間分配功能，TCC規格書亦未規定。民航局於1986年9月5日函文核准TACC系統最後重要設計審核(CDR)後，洛克希德公司乃依據經民航局核准之TACC系統設計文件，施作、發展TACC系統軟體、韌體工程，暨設計TCC系統完整資料欄，包括TCC系統完整資料欄中之D欄、E欄、Z欄等，民航局並要求TCC系統完整資料欄之格式應與TACC系統完整資料欄之格式一致，故TCC系統完整資料欄中之D欄、E欄、Z欄亦未設計時間分配功能。嗣洛克希德公司於1986年12月12日會議中，附條件同意民航局有關TCC系統完整資料欄之格式應與TACC系統完整資料欄之格式一致之要求，亦即民航局應於4週內提出詳細資料，並不得增加新資料及範圍為條件。詎民航局於1987年1月16日函文，竟仍提出新資料及約外要求，乃不符合洛克希德公司於1986年12月12日會議中提出之不得增加新資料及範圍之條件，且民航局更於1987年7月30日函文提出關於「TCC系統完整資料欄中之D欄、E欄、Z欄增加時間分配功能」之新的約外要求，此時距離TACC系統完工期限(1987年8月30日)僅剩一個月左右，此等影響TACC系統資料顯示欄設計之約外要求，迫使洛克希德公司原依1986年9月5日TACC系統設計審核通過所進行TACC系統發展及軟韌體工程勢須因此更改，並增加額外成本及時間，衡諸經驗法則，民航局在TACC系統完工期限前一個月始提出約外要求，勢將造成TACC系統工程之遲延。

⒎TACC規格書並未規定、要求E欄顯示資料之優先次序；而TCC規格書則並未規定、要求E欄，遑論該E欄顯示資料應有優先次序之功能詎料，民航局於其1987年7月30日函文要求變更TCC系統E欄顯示資料之優先次序為：「海岸(Coast)」、「放棄(Handoff)」及「暫止(Hold)」，民航局變更其先前所為TCC系統完整資料欄格式應與TACC系統完整資料欄格式一致之指示，顯屬約外要求。嗣因臺北TCC系統之完工期限(1987年11月30日)即將屆至，洛克希德為避免工程延滯，且慮及倘民航局不同意洛克希德公司所為之設計，將導致工程無法經其驗收核可，遂被迫以1987年12月10日函文，同意將TCC系統E欄顯示資料優先次序由原先設計之「暫止」、「海岸」及「放棄」變更為民航局要求之「海岸」、「放棄」及「暫止」。按系爭航管系統係由硬體、軟體及韌體所構成，該硬體、軟體及韌體間須相容始能配合運作，中信局1987年1月8日變更指令非僅涉及顯示器之韌體，並包括、涉及顯示器新增之軟體及硬體功能，致洛克希德公司須一再重新設計，造成額外成本及時間之支出。嗣經雙方長期、反覆討論，民航局終承認其就TACC PDR待辦事項第13號所提出之相關要求係屬約外要求，並指示中信局於1987年1月8日提出變更指令，指示洛克希德公司為執行包括TACCPDR待辦事項第13號相關約外要求之最終版本，洛克希德公司應進行必要之顯示器韌體升級。又，因民航局藉由待辦事項提出大量約外要求，嗣中信局提出1987年1月8日變更指令，洛克希德公司乃與顯示器製造商美商Magnavox公司於擬定、修改「顯示器設計變更之工作說明；1987年1月19日第3次變更版」，以納入並執行民航局之韌體變更、追加等約外要求抑有進者，顯示器軟體及韌體乃系爭航管工程之工程要徑(Critical Path)，故該等屬工程要徑之顯示器韌體工程事項之延誤，必然會立即影響整體系爭航管工程之工期，故系爭航管工程完工時程自有系爭闡明條款第4.2條(可宥恕遲延)之適用，系爭航管工程整體工期應予展延。

⒏TACC規格書及TCC規格書，並未規定、要求完整資料欄內需顯示軌跡(Track)之平滑數據(Smoothed Data)。惟1985年7月8日雷達顯示器符號會議時，民航局於會議中提出需於完整資料欄內顯示軌跡之平滑數據之約外要求。洛克希德公司於會議中表示TACC規格書並未要求顯示軌跡之平滑數據，民航局之要求係屬約外要求。民航局於其1985年9月7日函文，再度堅持並要求完整資料欄內需顯示軌跡之平滑數據，洛克希德公司於1985年11月29日函文，表明洛克希德公司關於雷達資料符號之立場，並重申民航局要求顯示軌跡之平滑數據係屬TACC規格書所未規定之約外要求，但本於合作精神及為使工程順利進行，勉強接受民航局要求顯示軌跡之平滑數據之約外要求。然僅就本工作項目而論，即已延宕4個月餘(自1985年7月至1985年11月)，該等延宕自已該當系爭闡明條款第4.2條第4款、第6款等可宥恕事由。

⒐TACC規格書附圖3-4規定、要求狀況顯示器符號組合中ICON樣本組為25個符號，民航局對於招標文件之闡明摘要則對TACC規格書予以修正，其中附圖3-4規定、要求ICON樣本為26個符號。惟民航局竟於1985年10月22日函文提出將26個符號增加為39個。按當時係在進行TACC最後重要設計審核，民航局突然提出此項要求，勢必導致洛克希德公司必須放棄已進行之狀況顯示器符號組合之原有設計，而予以重新設計，並需針對擴充之新增符號另外耗費額外之成本及時間費時設計。惟本於合作精神及為使工程順利進行，洛克希德公司別無他法，遂僅得於1985年11月29日函文同意勉強施作民航局此一約外要求。

B.民航局等則以：

⒈TCC系統之軟體設計與產製，原則上應盡量以既存之電腦程式設計為基礎，以節省成本並兼顧各系統間之整合與界接。查TCC與TACC兩系統之顯示器均由洛克希德公司之次供應商Magnavox公司統一製作，鑑於設計1個顯示器之時間較設計2個顯示器之時間為短，為縮短設計時間，避免耽誤系爭航管自動化系統建置之時程，民航局等乃於75年12月11日至12日之TCC系統PDR會議中，表示可將TCC系統之FDB格式，設計為與TACC系統之FDB格式一致等語，並經洛克希德公司及Magnavox公司同意在案，洛克希德公司甚至表明不增加額外費用，民航局等乃於76年1月16日去函說明TCC系統之FDB格式應適用TACC系統之FDB格式等語，無非在闡述兩造之前開共識與TCC規格書第3.3.2節及投標文件相關規定而已並非提出約外需求。且關於TCC系統FDB之設計問題，早在73年3月召開TACC系統之顯示器設計會議時，洛克希德公司即明白表示將與TACC系統之FDB一併進行設計作業，其中關於TCC系統之FDB應具備E欄之顯示欄位之問題，更於同年11月8日經提出討論，若「TCC系統之FDB應具備E欄之功能性需求」果為約外要求，或可能因此展延交貨時程，何以洛克希德公司當時或事後，未予以嚴正駁斥，並藉此索取價金或交期之額外利益？何以兩年後之75年12月11日至12日之TCC系統PDR會議中，洛克希德公司甚至表明就此不增加額外費用？益徵洛克希德公司之主張，顯為臨訟卸責之詞。況「TCC系統之FDB應具備E欄之功能性需求」，乃涉及GFE第18項所定之SD具體顯示格式之問題，而關於SD之顯示格式問題，業經兩造於74年8月8日第4次契約變更中確認在案，此觀諸第4次契約變更之附件3關於「GFE第18項」之欄位，明白記載「已收訖，顯示器會議業於1984年3月終結」等語即明，是此項發生於74年8月8日第4次契約變更以前之爭議，洛克希德公司自得且應已納入延長交期之考量，不得再事後翻異主張就此適用闡明條款所定之宥恕事由，民航局等更不致於在76年1月16日去函說明此事，即屬提出約外要求，甚至構成遲延之原因。

⒉洛克希德公司所提出證據係關於TCC系統之FDB設計資訊，既無涉TACC系統之FDB，更無隻字片語敘及民航局變更TACC系統FDB之C欄與D欄且關於此項爭議，於送請成功大學與中科院進行鑑定時，洛克希德公司均未就本項爭議提出任何資料以實其說，後經中科院函請其補正，亦未補正，而係遲至起訴後20餘年，始第一次提出無法與其主張互相勾稽之資料，該等資料顯屬逾時提出之攻擊防禦方法，應依民事訴訟法第196條等規定逕予駁回。

⒊按系爭契約文件中之招標文件「飛航資訊服務系統介面控制文件」(下稱IC-004文件)第5.4條明確規定，TACC系統應使用附表5-3之字元(Character)與編碼(coding)，而附表5-3亦將「-」列為得使用之字元，是民航局等表示FDB內之飛機識別欄應加入「-」之符號，不過在說明基本需求規章之內容而已，並非提出約外要求。且TACC規格書第2.4頁(即第2.6節)就相關文件之適用優先順序予以規範，係以各該文件彼此間互為抵觸為前提，若各該文件彼此間並無抵觸，或係立於補充適用之關係時，即無TACC規格書第2.6節之適用。查「-」不但為IC-004文件所定之符號洛克希德公司所自認，更為TACC規格書所明定得使用之符號，可知「-」符號之使用，實為TACC規格書與IC-004文件所共同明定在案，自非所謂之約外要求。況FDB屬狀況顯示器上所應顯示之項目，不但有TACC規格書附表3.2可稽，其更規定系爭系統須於得顯示之所有區域內，統一(uniformly)顯示相關資訊，故只要「-」為狀況顯示器所得使用之符號，「-」即得顯示於狀況顯示器之顯示項目FDB之內，而為FDB所得使用之符號，則民航局就此提出說明，自不構成約外要求。

⒋按系爭航管自動化系統為能有效掌握每一飛機之航跡，以確保飛航管制之實效與安全，對每一飛機在顯示器上之航跡，須依疆界或高度等管制之需求，在顯示器上自動標示或切換其完整資料或有限資料以利追蹤，屬系爭航管自動化系統之基本功能，是上訴人對此提出說明，表示顯示器關於每一飛機追蹤航跡須自動顯示資料欄，或為完整資料欄FDB，或為有限資料欄LDB等語，並非提出約外要求。又關於FDB之顯示功能與路徑，TACC規格書第3.7.3.3.4.6.4.2.3節與TCC規格書第3.7.3.3.4.4.4.2.3節分別規定，在相關航跡經認定出現於特定管制空域內時，TACC系統與TCC系統應顯示該航跡之FDB(第1項)，且在飛航器跨越管制空域時，在接手管制之席位上，應在接手時自動顯示FDB(第3項)。另關於LDB之顯示功能與路徑，TACC規格書第3.7.3.3.4.6.4.3.3節第2項與TCC規格書第3.7.3.3.4.4.4.3.3節第2項分別規定，當相關SSR或PSR雷達資訊上之航跡穿越管制空域之疆界及高度限制時，TACC系統與TCC系統應自動顯示該航跡之LDB於原管制席位。故關於航空器航跡之相關資料，究應在狀況顯示器上表現為完整資料欄FDB或有限資料欄LDB，依前揭TACC規格書與TCC規格書之規定，將取決於該航跡之位置，亦即為使航跡位置(所在區域)之管制席位能精確掌握該管制區域範圍內之該航跡相關資訊，TACC系統與TCC系統應顯示該航跡之完整資料欄FDB，否則顯示於有限資料欄LDB即為已足，且在該航跡因移動而跨至另一席位所管制之空域時，接手管制之席位為能確實掌握該航跡之資料，其狀況顯示器應自動顯示該航跡之完整資料欄FDB，至於原管制席位之狀況顯示器，則因該航跡已脫離原管制空域，故無繼續顯示完整資料欄FDB進行管制之必要，是TACC規格書及TCC規格書乃規定狀況顯示器應由完整資料欄FDB自動顯示為有限資料欄LDB，以因應航管作業之變化與實需。民航局於74年7月8日去函無非在說明上述航跡移動時應如何在狀況顯示器上顯示完整資料欄FDB或有限資料欄LDB，重申TACC規格書與TCC規格書關於完整資料欄FDB有限資料欄LDB之顯示要件及時機而已，完全無涉所謂約外要求。

⒌將FDB之資料格式固定，即無須在設計過程中，考量航路資料所在位置而移動相關資料，可降低設計難度，有助防免系爭航管自動化系統建置時程之延誤。且關於FDB無須左右位移等節，業經洛克希德公司於74年11月29日函文表示同意，是關於FDB無須左右位移之功能性需求，實已經兩造於PDR會議中達成共識而確定在案，而為系爭航管自動化系統之應具功能。況基本需求規章中之TACC規格書僅係就功能性需求進行上位性及概念性之描述，並未就系爭系統之規格為具體之確定，故於締約後之規格確定作業或設計審核會議中，兩造當然得確認釐清相關之功能性需求，根本無所謂約外需求或變更設計之可言，故不論TACC規格書就FDB之左右位移功能如何描述，兩造既於設計審核會議中達成無須左右位移之合意，該合意即成為基本需求規章之一部分，洛克希德公司自須從速據以進行設計，不容無故藉詞延宕。

⒍按TCC系統關於FDB之D、E及Z欄所顯示之資訊均不只一種，以D欄位為例，其需在一定時間內，顯示起飛、降落之型態與跑道指定等數項資訊，是為釐清各項資訊顯示之優先順序與時間分配，民航局等於TCC系統之PDR或CDR階段，去函說明FDB中D、E及Z欄之時間分配，並敘明E欄所預定顯示複數資訊間之優先順序等語，並非提出約外要求。

⒎洛克希德公司主張民航局要求「更改TCC系統完整資料欄中之E欄顯示資料之優先次序」為約外要求，無非以「TACC系統FDB之E欄業已訂有顯示優先順序」為其論據，惟其不但全未舉證以實其說，更與其在本件本院前審程序之主張相互矛盾，因為洛克希德公司於鈞院前審就此曾主張TACC系統FDB之E欄未訂有顯示優先順序云云，可見關於TACC系統FDB之E欄是否曾訂有所謂之顯示優先順序，洛克希德公司竟前後為相異且矛盾之主張，洵無可採。另細繹洛克希德公司主張為證之相關函文，僅表示TCC系統之FDB欄應與TACC一致而據以進行設計等語，未有隻字片語敘及TACC系統FDB之E欄具體顯示優先順序內容為何，實則不論TACC系統FDB之E欄是否已定有顯示資料之優先順序，民航局等於TCC系統之PDR或CDR階段，自得且應依TCC(異於TACC)之系統功能、管制任務及實際需求而進行設計，始符專業要求，是民航局等就此提出說明，實與提出所謂「約外要求」無關，且民航局76年1月16日函至多僅在表明TCC系統之FDB應以TACC系統之FDB為建置基礎而進行後續設計框架而已，並未排除或限制於TCC系統之PDR階段，基於TCC系統之應具功能、管制任務及實際需求等因素，適度為與TACC不同之具體設計及調整，故去函說明TCC系統狀況顯示器FDB之E欄內相關資訊之顯示優先順序，並不構成提出約外要求。

⒏當主要監視雷達及次級監視雷達均獲得同一航空器之資訊時，雖將出現2筆以上之不同航跡資料，但卻指涉同一航空器，故須就各該不同之航跡資料進行比較、修正及選取而調校後，始能決定作為顯示目標物航跡、位置及速度之最佳資料，故系爭契約關於「航跡」之顯示，明訂須以經「調校」(smoothed。按：洛克希德公司譯為「平滑」)後之資料為準，俾利管制員據以實施航空管制作為，此觀諸洛克希德公司投標文件第二冊第3-54頁記載：「調校(Smoothing)」包括使用關連之雷達資料，以調整、校正航跡之預測位置及速率，俾能符合雷達所管制飛航器之實際情形等旨即明。且關於系爭系統須能顯示軌跡之調校資料(smoothed Data)乙節，業經洛克希德公司於74年11月29日函文同意接受在案，亦為該公司所不爭執。況關於本項爭議，洛克希德公司於聲請鑑定時，並未提出任何說明與資料林清一報告與中科院鑑定亦因此而未為任何判斷與認定，迺洛克希德公司竟於本件起訴後20餘年之鈞院程序，始第一次提出主張，顯屬逾時提出攻擊防禦方法，應依民事訴訟法第196條等規定逕予駁回。

⒐按TACC系統規格書第3.7.2.2.1.2.9.12節明定，在設計系統符號產生時，應納入模組以容納額外之符號，可知TACC規格書已預留符號單元擴充之功能需求，是民航局於74年10月22日去函所為擴充符號單元之說明，並非約外需求，洛克希德公司亦明知此事，並旋於同年11月29日回函表示同意納入TACC之系統設計，是關於TACC系統之符號單元擴充，實無涉約外要求等語，資為抗辯。經查：

⒈民航局要求「TCC系統完整資料欄之格式應與TACC系統完整資料欄之格式一致」，是否為約外要求？

⑴洛克希德公司主張TACC規格書與TCC規格書就完整資料欄之格式及內容有顯著差異，洛克希德公司於73年3月顯示器設計會議時，已依TACC及TCC規格書之規定，提出TACC及TCC系統之完整資料欄格式，並進行設計工作，然民航局於73年11月8日要求TCC系統完整資料欄之格式需與TACC系統完整資料欄之格式一致，違反TCC規格書之規定而屬約外要求云云。

⑵經查，完整資料欄係顯示在台北飛航情報區內所有管制之飛機之相關資料，TACC規格書第3.7.3.3.4.6.4.2.1節規定TACC系統完整資料欄包含四行字母與數字構成之資訊（見外放TACC規格書第3-315頁），而TCC規格書第3.7.3.3.4.4.4.2.1節則規定TCC系統完整資料欄包含三行字母與數字構成之資訊（見外放TCC規格書第3-298頁），兩者所定義之完整資料欄的格式確不一致，惟TCC規格書第3.3.2節已表明系統軟體應充分利用既存之電腦程式設計與編碼，以滿足功能性需求，若自系統產製與維持等觀點，可認新程式編碼將使電腦程式最經濟地滿足基本需求規章之功能性需求時，則不在此限（見外放TCC規格書第3-64頁），可知關於TCC系統之軟體設計與產制，原則上應盡量以既存之電腦程式設計為基礎，以節省成本並兼顧各系統間之整合。洛克希德公司投標文件第二冊TCC部分第1.1.2節就TCC系統之發展時程亦認TCC操作程式之修正，多數為在TCC之PDR前即已建置完成之TACC操作程式之直接複製（見外放投標文件第二冊TCC部分第1-19頁）。洛克希德公司雖已於73年3月8日顯示器設計會議中，提出狀況顯示器之報告時序及FDB完整資料欄，惟民航局係於75年12月11日至12日之TCC系統PDR會議中要求TCC系統之完整資料欄之格式採用與TACC系統一致之完整資料欄之格式，斯時TCC之PDR尚未結束，且TCC與TACC兩系統之顯示器均由洛克希德公司之次供應商Magnavox公司統一製作，為兩造所不爭，則採用TACC之規格去設計TCC的完整資料欄，應較分別設計二不同規格之完整資料欄所需時程短，對洛克希德公司而言，將會減少系統設計之時間及成本支出，且民航局提出此項要求後，洛克希德公司及Magnavox公司均表同意（詳原證179；另詳本院100年5月31日準備程序筆錄，見本院卷2第390至391頁），洛克希德公司甚至表明不增加額外費用（詳上證33號，見本院卷1第556至557頁），故民航局抗辯其係為縮短設計時間，避免耽誤系爭航管自動化系統建置之時程，而提出上開要求，應屬有據。

⑶中科院鑑定報告認為雖TACC及TCC工程基本需求規章所載，兩者定義完整資料欄（FDB）的格式的確不一致，惟76年1月份TCC的PDR尚未結束，故民航局提出將TCC之資料欄位格式盡量與TACC之資料欄位格式一致之需求，依據MIL-STD-1521A軟體設計審查與稽核規範，並未超出合約範圍(見外放之中科院鑑定報告第27至28頁)；另成大鑑定報告亦認為洛克希德公司具備國際間數項飛航管制系統發展之經驗，理應了解相關規範之定義，對FDB所提之要求似乎過於挑剔民航局的規範訂定上之缺陷（見外放之成大鑑定報告第24至25頁），故洛克希德公司主張此部分為約外要求，應非可取。

⒉民航局要求「變更TACC系統完整資料欄之C欄與D欄」，是否為約外要求？

⑴洛克希德公司主張TACC規格書第3.7.3.3.4.6.4.2.1節規定完整資料欄Ｃ欄顯示內容為「據報高度或Ｃ模式高度」，Ｄ欄顯示內容為「地面速度/電腦識別」，惟民航局於73年11月8日資料文件，要求洛克希德公司將Ｃ欄顯示內容變更為「地面速度/電腦識別」，Ｄ欄顯示內容變更為「指定高度」，與TACC規格書不符，為屬約外要求云云。

⑵經查，洛克希德公司所提民航局73年11月8日之資料文件，係民航局對於「TCC」之完整資料欄FDB所為要求，洛克希德公司持此主張民航局要求變更「TACC」系統完整資料欄之C欄與D欄之記載，已屬無據；再者，依上開附件之內容觀之C欄與D欄之間僅為內容互換，且有足夠之空間置換位元，此觀洛克希德公司所提出之民事上訴暨答辯理由二狀之附件1⑸-5(見本院證物卷1第329、330頁)自明，並非困難且不合理之要求，尚難認為此部分屬約外要求。

⑶此部分送中科院鑑定時，因洛克希德公司未檢附相關資料，然此部分是否屬於約外要求，非經航空、通訊、資訊專業人員，以其專業依契約及相關往來文件研析，無法判斷（見外放之中科院鑑定報告第27頁），故洛克希德公司主張此部分為約外要求，尚屬無法證明，且成大鑑定報告亦認洛克希德公司此部分主張為吹毛求疵，故應認為洛克希德公司此部分之主張，實屬無據。

⒊民航局要求「TACC系統完整資料欄中之飛機識別欄增加特別連接符號」，是否為約外要求？

⑴洛克希德公司主張依TACC規格書第3.7.3.3.4.6.4.2.1節「字母與數字構成之完整資料欄格式」規定，完整資料欄第2行即飛機識別欄係以字母數字顯示之，惟民航局於73年12月6日函文要求飛機識別欄第一個字元應為字母，其後使用之字元應為字母數字或「-」符號，因符號「-」非屬字母數字，且「-」為招標文件CAA-E-1C-004文件所明定之符號，依TACC規格書第2.4頁相關規定，其效力劣後於TACC規格書，故此部分為屬約外要求云云。

⑵查TACC規格書第3.7.3.3.4.6.4.2.1節「字母與數字構成之完整資料欄格式」固規定「完整資料欄之字母數字部分需依下列方式顯示……字母數字資料之第1行應包括6個以上之字元，第2行則應包括8個以上字元」（見外放TACC規格書第3-315頁），惟招標文件CAA-E-1C-004「飛行資訊系統介面控制文件」第5.4條已明定TACC系統應使用附表5-3之字元及編碼，而附表5-3所示之ITA-5之字元碼，除0-9之數字及a-z之英文字母大小寫外，尚包括連接「-」符號內之一些常用符號(見外放飛航資訊系統介面控制文件第5-22、5-23頁），蓋TACC規格書第2.4頁(即第2.6節)就相關文件之適用優先順序予以規範，係以各該文件彼此間互為抵觸為前提(詳上證73號，見本院卷4第567至568頁)，若各該文件彼此間並無抵觸，或係立於補充適用之關係時，即無TACC規格書第2.6節之適用。且民航局於73年12月6日發函要求於飛機識別欄增加特別連接符號後，洛克希德公司既於74年1月18日函覆民航局表示同意（見外放前審證物卷原證131號、第240號；另詳洛克希德公司民事上訴暨答辯理由二狀附件1（5）-7，見本院證物卷1第333至334頁），足見民航局所為要求，並未溢出系統介面控制文件約定之範圍。故民航局於73年12月6日函文要求TACC完整資料欄之飛機識別欄增加連接符號「-」，應非屬約外要求。

⑶中科院鑑定認為「-」字元方式呈現，係屬微小設計變動且易於執行，民航局於73年12月6日函中要求台北區管中心之完整資料欄之飛機識別欄加入特別之連接符號並無超出基本需求規章之規定（見外放之中科院鑑定報告第28、29頁）；另成大鑑定報告亦認國際民航組織(ICAO)公約附件10之文字與數字顯示之規範，指定根據ITA-5之字型碼編譯資料，除數字及英文字母大小寫外，另包括一些常用的符號。文字及數字組合之數據欄為ICAO行之多年之基本定義，在技術層面上，洛克希德公司人員應對本問題有所了解」（見外放之成大鑑定報告第26頁），故洛克希德公司主張此部分為約外要求，應非可取。

⑷另洛克希德公司雖以依TACC規格書第2.6節第3點規定，主張國際民航組織文件應無適用餘地云云。經查，招標文件CAA-E-1C-004介面控制文件第5.4節既指定根據國際民航組織之ITA-5之字型碼編譯資料，洛克希德公司主張國際民航組織文件應無適用餘地，尚無可取。

⒋民航局要求顯示器上自動顯示之資料欄或係「完整資料欄」（FDB） 或「有限資料欄」（LDB），是否為約外要求？

⑴洛克希德公司主張依TACC規格書第3.7.3.3.4.6.4.3.3節及TCC規格書第3.7.3.3.4.4.4.3.3節規定，有限資料欄係依請求而顯示，且有限資料欄係因關聯之偵測雷達及非控制緊急資料而強迫顯示，惟民航局於74年7月8日函要求如管制席位之識別編號與席位識別編號不相符時，應自動顯示有限資料欄，且該等顯示規格曖昧不明甚至互相矛盾，例如有限資料欄應主動或被動產生，定義不明，互相矛盾，顯與上開約定不符，應屬約外要求，且勢須變更原有電腦軟體及韌體之設計云云。

⑵按系爭航管自動化系統為能有效掌握每一飛機之航跡，以確保飛航管制之實效與安全，對每一飛機在顯示器上之航跡，須依疆界或高度等管制之需求，在顯示器上自動標示或切換其完整資料或有限資料以利追蹤，屬系爭航管自動化系統之基本功能。經查，TACC規格書第3.7.3.3.4.6.4.3.3節及TCC規格書第3.7.3.3.4.4.4.3.3節「有限資料欄之顯示功能及路徑」規定「1.有限資料欄應依據任何選出之關連初始偵測雷達或次位偵測雷達之請求顯示。2.有限資料欄應於關連初始偵測雷達或次位偵測雷達資料穿越制席位系統彊域或管制高度時顯示之。3.有限資料欄應於顯示操作台顯示非控制緊急資料」（詳上證179，見本院卷17第262至266頁）。另參諸TACC規格書第3.7.3.3.4.6.4.2.3節及TCC規格書第3.7.3.3.4.4.4.2.3節「1.在相關航跡經認定出現於特定管制空域內時，應顯示該航跡之完整資料欄。……3.在飛航器跨越管制空域時，在接手管制之席位上，應在接手時自動顯示完整資料欄……」（詳上證178，見本院卷17第258至261頁），可知關於航空器航跡之相關資料，究應在狀況顯示器上表現為完整資料欄或有限資料欄，依前揭TACC與TCC規格書之相關規定，係取決於該航跡之位置。亦即為使航跡位置（所在區域）之管制席位能精確掌握該管制區域範圍內之該航跡相關資訊，TACC系統與TCC系統應顯示該航跡之完整資料欄FDB，否則顯示有限資料欄LDB即為已足，且在該航跡因移動而跨至另一席位所管制之空域時，為使接手管制之席位能確實掌握該航跡之資料，其狀況顯示器應自動顯示該航跡之完整資料欄FDB，至於原管制席位之狀況顯示器，則因該航跡已脫離原管制空域，故無繼續顯示完整資料欄FDB進行管制之必要。故而TACC規格書及TCC規格書乃規定狀況顯示器應由完整資料欄自動顯示為有限資料欄，以因應航管作業之變化與實際需求。

⑶據此，民航局74年7月8日函係在說明航跡移動時應如何在狀況顯示器上顯示完整資料欄或有限資料欄，其中「若航跡資料中被界定之管制空域與管制空域內之航跡識別相符」，即指「該航跡經認定出現於特定管制空域」之意，另「否則即顯示有限資料欄」則指係「某航跡穿越至另一管制空域後，原管制空域所對應席位之狀況顯示器，應由完整資料欄自動顯示為有限資料欄」之意，不過在重申、闡述TACC與TCC規格書有關完整資料欄之顯示要件及有限資料欄之顯示時機而已，應屬有據。

⑷中科院鑑定認為在特定條件下自動顯示LDB之要求，為航空管制系統必須具備之基本功能，故民航局要求顯示器之每一飛機追蹤航跡必須自動地顯示資料欄，或為「完整資料欄」，抑或為「有限資料欄」並無超出台北區管中心基本需求規章及終端管制中心基本需求規章之規定（見外放之中科院鑑定報告第29、30頁）；另成大鑑定報告雖認LDB自動顯示可以在軟體中以特定規格制定，但無法設計為可以隨意調整輸入，惟亦認民航局74年7月8日函並未強烈涉及對顯示器之特別要求，僅對所有新出現之軌跡必須自動傳送之相關管制席位之要求，且雙方爭議在於為LDB之顯示無法由基本規章定義具體說明，各有主張及定義（見外放之成大鑑定報告第27頁），據此，仍難認締約雙方對此部分基本需求規章解釋上之爭議，為民航局之約外要求。故洛克希德此部份之主張，應不足採。

⒌民航局要求「TACC系統完整資料欄不得左右位移」，是否為約外要求？

⑴洛克希德公司主張依TACC規格書第3.7.3.3.4.6.4.2.2(3)a及b規定，完整資料欄之格式得左右位移，但民航局於74年7月8日會議中片面要求完整資料欄不得左右位移，應屬約外要求云云。

⑵查TACC規格書第3.7.3.3.4.6.4.2.2(3)a及b固約定：「如果Ａ欄向左對齊，Ｂ欄之內容亦應向左對齊」、「如果Ａ欄向右對齊，Ｂ欄之內容亦應在資料欄第三行之字元位置內向右對齊」（見外放TACC規格書第3-317頁）。而民航局固亦有於74年7月8日雷達顯示符號會議中，提出第12、13、14項要求，要求完整資料欄所包含之資料不得在其格式內左移或右移，以及由此而生之移至鄰接空白區域之資料不得產生之限制（詳洛克希德公司民事上訴暨答辯理由二狀附件1（5）-20，見本院證物卷1第379至384頁）。惟將完整資料欄中之資料格式固定，則洛克希德公司於設計時，即無須考量航路資料所在位置而移動相關資料，並可免除資料能左右位移功能之設計，衡情其設計難度應為降低而非增加，且應屬細部設計部分，況洛克希德公司已於74年11月29日之函文表示同意（詳洛克希德公司民事上訴暨答辯理由二狀附件1（5）-13，見本院證物卷1第360至365頁），實可認為兩造於PDR會議中達成共識而確定在案，故民航局於雷達顯示符號會議中提出，尚難認係屬約外要求。

⑶中科院鑑定亦認民航局於74年7月8日會議中提出此項要求，洛克希德公司已於同年11月29日函表示願意接受此修改意見，故此部份無超出或改變台北區管中心基本需求規章之規定（見外放之中科院鑑定報告第31頁），而成大鑑定報告並未斟酌洛克希德公司同意接受民航局修改意見之事實（見外放之成大鑑定報告第29頁），故其鑑定結果實不足採。綜上所述，此部份並非約外要求，洛克希德公司之主張應非可採。

⒍民航局要求「TCC系統完整資料欄中之D欄、E欄、Z欄增加時間分配（time sharing）」，是否為約外要求？

⑴洛克希德公司主張TACC及TCC規格書均未要求完整資料欄中之D欄、E欄、Z欄應有時間分配功能，民航局於73年11月8日要求TCC系統完整資料欄之格式應與TACC系統完整資料欄格式一致；75年9月5日核准之TACC系統最後重要設計審核（CDR）TACC系統完整資料欄之D欄、E欄、Z欄亦無時間分配功能，民航局於76年1月16日函再次重申TCC系統完整資料欄之格式應與TACC系統完整資料欄格式一致，卻於76年7月30日函文變更其先前所為指示，要求在TCC系統完整資料欄之D欄、E欄、Z欄增加時間分配功能，應屬約外要求。

⑵經查：依TACC規格書第3.7.3.3.4.6.4.2.1節規定，TACC完整資料欄之D欄顯示之資訊為「Ground Speed/ComputerIdentification」，E欄所顯示之資訊為「AircraftStatus/scratch pad」，所顯示之資訊均不只一種，Z欄則顯示警告資訊（見外放TACC規格書第3-316頁）。而民航局76年1月16日函，至多僅在表明TCC系統之FDB應以TACC系統之FDB為建置基礎而進行後續設計框架而已，並未排除或限制於TCC系統之PDR階段，基於TCC系統之應具功能、管制任務及實際需求等因素，適度為與TACC不同之具體設計及調整（詳洛克希德公司民事上訴暨答辯理由⑵狀附件1⑸-15，見本院證物卷1第368至369頁）；又民航局76年7月30日函僅在敘明於D及E同一欄位顯示不同資訊之時間分配，及同時有二個以上警告訊號時，於Z欄位之顯示方式，此於一欄位處理、顯示一個以上資訊時，必須有之設計，TACC完整資料欄既規定於D、E、Z欄處理、顯示一個以上資訊（詳洛克希德公司民事上訴暨答辯理由⑵狀附件1⑸-16，見本院證物卷1第370至372頁），可知民航局上開信函應僅在說明其時間分配，縱無此民航局函，洛克希德公司於設計時仍須處理如何於同一欄位顯示一個以上資訊之問題，況此部份之爭議應屬設計之細節部分，難以在簽訂契約之初即能掌握，須於PDR或CDR方能釐清，就此民航局自非提出約外要求。

⑶中科院鑑定認為民航局於76年1月16日函指示終端管制中心之完整資料欄應與台北區管中心相同之要求，係為一原則上指示，系統於細部設計時，TACC及TCC各有不同管制任務，其中對FDB各欄位的顯示需求也會因實際情況有所不同，故民航局於76年7月30日函中提出終端管制中心完整資料欄中之D、E、Z欄有關時間分配之需求係為合理，並未與終端管制中心基本需求規章規定及76年1月16日函件要求相牴觸（見外放之中科院鑑定報告第32頁）；另成大鑑定報告亦認本項內容牽涉完整資料欄FDB中如何劃分數據進出的時間分享問題，基本上與系統軟體發展有極重要關係，兩造在合約中均未詳細定義此一細節必須於執行中由雙方共同討論訂定，或由任何一方提出具體方法，且本項於合約基本規章中並未有具體的定義，兩造更未就此達成協議，因此洛克希德公司應可依據最精簡的規範進行設計（見外放之成大鑑定報告第31頁），故洛克希德公司主張民航局76年7月30日函為提出約外要求，應非可取。

⒎民航局要求「更改TCC系統完整資料欄中之E欄顯示資料之優先次序」，是否為約外要求？

⑴洛克希德公司主張TACC規格書並未要求完整資料欄E欄顯示資料之優先順序，TCC規格書則未規定、要求E欄，民航局於73年11月8日要求TCC系統完整資料欄之格式應與TACC系統完整資料欄格式一致，洛克希德公司因而設計TACC系統E欄顯示資料之優先次序為「Hold」、「Coast」及「Handoff」，並經民航局於TACC系統最後重要設計審核（CDR）核准，民航局於76年1月16日函再次重申TCC系統完整資料欄之格式應與TACC系統完整資料欄格式一致，卻於76年7月30日函文要求變更TCC系統完整資料欄E欄顯示資料之優先次序為「Coast」、「Handoff」、「Hold」，應屬約外要求；又顯示器軟體及韌體設計乃系爭航管系統之工程要徑(Critical Path)，故該等屬工程要徑之顯示器韌體工程事項之延誤，系爭航管工程整體工期應予展延云云。

⑵經查，TACC規格書並未要求完整資料欄E欄顯示資料之優先順序，且民航局於73年11月8日函僅要求TCC系統完整資料欄之格式應與TACC系統完整資料欄「格式」一致，則關於完整資料欄E欄「顯示資料之優先順序」，自應由締約雙方於系爭航管自動化系統中之設計執行中就此細節共同討論訂定，或由任何一方提出具體方法，且TCC系統之發展多數為TACC操作程式之直接複製已如前㈤⒈⑵所述，洛克希德公司並未舉證於E欄顯示優先順序有何時間或金錢上之耗費及設計上之困難，故就此部分尚難認為約外要求。另洛克希德公司雖主張顯示器軟體及韌體設計乃系爭航管系統之工程要徑，惟洛克希德公司從未於訴訟程序中提出系爭航管系統之工程要徑圖，亦未舉證設計E欄顯示優先順序有何延誤工期之情以實其說，故其主張尚難採信。

⑶中科院鑑定認為本項欄位顯示資料的改變乃依據MIL-STD-1521A軟體設計審查與稽核系統發展之規範，民航局依據實際系統使用需求，於終端管制中心初期設計審核會議中提出更改變更狀況顯示器之顯示次序為：「海岸」（Coast）、「放棄」（Handoff）「暫停」（Hold），不超出終端管制中心基本需求規章之契約範圍，並不屬約外要求（見外放之中科院鑑定報告第36頁）；另成大鑑定報告亦認「TCC及TACC之合約內容，對所有時間分享軟體發展均未明定完整資料欄之需求或詳細優先順序，故依據軟體發展技術之一般規範，應為雙方於執行時依據需求由購方提出，或依據技術條件由承包商提出建議方案」（見外放之成大鑑定報告第32頁），故此部份並非約外要求，洛克希德公司之主張應非可採。

⒏民航局要求「顯示軌跡之平滑數據」，是否為約外要求？

⑴洛克希德公司主張TACC及TCC之規格書並未規定要求完整資料欄內需顯示軌跡（Track）之平滑數據（Smoothed Data），惟民航局於74年7月8日雷達顯示符號會議提出完整資料欄欄內需顯示軌跡之平滑數據之約外要求，於74年9月7日函文中再度為上開要求，洛克希德公司於74年11月29日函文重申此部分為約外要求，但本於合作精神及為使工程順利進行，方勉強同意云云。

⑵按系爭契約之目的乃建構一完善之航空管理系統，而航空管理系統之建構應以飛航安全為目的及最基本考量，已如前㈡⒋所述。經查，主要監視雷達及次級監視雷達均獲得同一航空器之資訊時，將出現2筆以上之不同航跡資料，故本應就各該不同之航跡資料進行比較、修正及選取而調校後，始能決定作為顯示目標物航跡、位置及速度之最佳資料，故系爭契約關於「航跡」(track)之顯示，明訂須以經「調校」(smoothed。按：洛克希德公司將之譯為「平滑」)後之資料(即smoothed Data)為準，俾利管制員據以實施航空管制作為，以維飛航安全，此觀諸洛克希德公司投標文件第二冊第3-54頁記載：「調校(Smoothing)」包括使用關連之雷達資料，以調整、校正航跡之預測位置及速率，俾能符合雷達所管制飛航器之實際情形等旨即明(詳上證180-1號，見本院卷17第268至272頁)。且揆諸洛克希德公司前開主張於74年11月29日之函文表示同意民航局之修改意見（詳洛克希德公司民事上訴暨答辯理由⑵狀附件1.⑸-13，見本院證物卷1第360至365頁），故此部份尚難認為屬約外要求。

⑶關於本項爭議，洛克希德公司於聲請鑑定時，並未提出任何說明與資料(詳外放洛克希德公司「對『航空管制自動化系統』鑑定事項之說明」第41至43頁所列各鑑定事項)，成大與中科院之鑑定報告因此而未為任何判斷與認定。準此，洛克希德公司主張此部分為約外要求尚屬無法證明，其主張自無可取。

⒐民航局要求「TACC規格書規定之26個符號單元擴充為39個」，是否為約外要求？

⑴洛克希德公司主張TACC規格書規定狀況顯示器符號組合中ICON樣本組為25個符號，民航局於招標文件中修正為26個符號，惟又於74年10月22日函文中要求增加為39個，民航局此項請求為屬約外要求云云。

⑵經查，TACC規格書第3.7.2.2.1.2.9.12節，已明定在設計系統符號產生時，應納入模組以容納額外之符號（詳上證100號，見本院卷5第437至457頁，另見外放TACC格書第3-125至3-126頁），足見TACC規格書已預留符號單元擴充之功能需求，且民航局於74年10月22日提出此項要求後，洛克希德公司即於74年11月29日去函民航局表示同意(詳洛克希德公司民事上訴暨答辯理由⑵狀附件1⑸-13，即原證139，見本院證物卷1第360至365頁)，復未據洛克希德公司就此表示任何異議或原有設計將延誤工程進行之意見，故其主張此部份為約外要求，亦非可取。

⑶中科院鑑定認為TACC基本需求規章已預留擴充的需求，故民航局於74年10月22日函件中，提出擴充需求並非約外要求，且依原證139號因洛克希德公司於74年11月29日信函業已表示願接受此一修改意見，則民航局提出此一要求即非為約外要求（見外放之中科院鑑定報告第31至32頁）；另成大鑑定報告認定系爭系統須採「模組化設計」，以便與其他符號結合使用，卻又於該報告說明認定基本規章之定義模糊，為本件爭議之原因云云（見外放之成大鑑定報告第27頁），前後顯然互相矛盾，此部份洵不可採。故洛克希德公司主張此部分為約外要求，應非可採。

⒑另成大及中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開㈤⒈至⒑所述），就過失比例部分尚無庸參考，併予敘明。

⒒關於洛克希德公司於103年5月2日民事調查續（二）狀中，請求成大航太所補充說明之詢問事項A、B、C，已分別於上開㈤⒎、⒉、⒊部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

⒓最高法院就該部分發回意旨雖指出：「關於附表一編號一之(五)「完整資料欄之變更需求（更改TCC系統「完整資料欄」E欄狀況顯示器優先次序）」部分，原審固以TCC系統基本需求規章，未明定此項優先順序，民航局發函要求顯示資料優先順序，並無變更系統基本需求規章，難認其有可宥恕事由。然上訴人迭於事實審指稱：依原證一四四、一四六、一五二～一五八號證所載，民航局於簽約三年半後，於契約所定TCC系統完工期限即七十六年八月三十日之前三十日（同年七月三十日）仍提出新的約外要求及指示更改此欄優先次序需求，且本應於七十四年初即可確定者，卻遲滯未決，延至七十六年十二月十日始告確定等語（一審卷(二)三三～三七頁、原審卷(八)三七頁及原審卷(九)五○頁），該主張是否全無足採？與系爭航管工程之工期遲延是否無關，上訴人就此有無可歸責之事由，攸關其得否依約展延工期，原審未予斟酌，並有可議。...」，惟前開㈤⒎⑵中已說明TACC系統及TCC系統之完整資料欄E欄「顯示資料之優先順序」，自應由締約雙方於系爭航管自動化系統中之設計執行中就此細節應於CDR及PDR會議共同討論訂定，或由任何一方提出具體方法，此並非約外要求，亦無遲延之問題。且民航局76年7月30日函僅在敘明於D及E同一欄位顯示不同資訊之時間分配，縱無此民航局函，洛克希德公司於設計時仍須處理如何於同一欄位顯示一個以上資訊之問題，故此部份之爭議應屬設計之細節部分，難以在簽訂契約之初即能掌握，須於PDR或CDR會議方能釐清，就此民航局自非提出約外要求，業已於前開㈤⒍⑵及㈤⒍⑶所述，況洛克希德公司亦自承於其76年12月10日函同意將TCC系統E欄顯示資料優先次序由原先設計之「暫止(Hold)」、「海岸(Coast)」及「放棄(Handoff)」變更為民航局要求之「海岸(Coast)」、「放棄(Handoff)」及「暫止(Hold)」（詳洛克希德公司民事上訴暨答辯理由二狀附件1（5）-19，見本院證物卷1第377至378頁），就此而言尚難認為該部份屬約外要求。又TCC系統之發展多數為TACC操作程式之直接複製，對洛克希德公司而言，應會減少系統設計之時間及成本支出，況洛克希德公司並未舉證設計E欄顯示優先順序有何延誤工期之情以實其說，亦已如前開㈤⒈⑵所述，併此敘明。

㈥第一大項第六小項關於洛克希德公司主張「指定跑道/使用中跑道之約外要求」部分，即民航局要求於TACC、TCC系統完整資料欄新增使用中跑道（Runways in Use）之功能，是否為約外要求？

A.洛克希德公司主張：

⒈TACC規格書、TCC規格書均未規定、要求民航局所主張之使用中跑道(Runways in Use)之功能，然民航局於1984年9月21日待辦事項會議中，要求洛克希德公司於TACC系統及TCC系統完整資料欄新增使用中跑道之功能，此與TCC規格書所要求完整資料欄之指定跑道(Assigned Runway)迥然不同。TACC規格書中，僅有選取跑道之功能要求；TCC規格書則僅規定、要求指定跑道(Assigned Runway)之功能，由於系爭航管工程係屬固定價格、範圍之工程，民航局要求具有使用中跑道功能之要求，顯已逾基本需求規章(TACC規格書及TCC規格書)，而屬約外要求。

⒉且於洛克希德公司1985年1月28日致邁特公司之函文中，說明民航局應捨棄使用中跑道之約外要求。並於1985年5月20日，再次函告民航局，表示新增使用中跑道功能之要求已逾越契約及基本需求規章之範圍。民航局終而於其1985年5月21日函文，自承使用中跑道功能之要求係屬「約外要求」項目，並於1985年5月30日函文中，表示若洛克希德公司認其要求係屬約外，則應提出該等約外要求之影響預估，亦即要求洛克希德公司依系爭闡明條款第4.1條及第4.3條，提出關於時程/成本影響之建議。

⒊另1985年8月29日民航局於其函文指示洛克希德公司執行使用中跑道之約外要求，洛克希德公司旋於1985年9月4日函文，表示民航局1985年8月29日函文之指示應係依系爭闡明條款第4.3條所為之「變更指令」，而依該條規定，若民航局變更工程，則洛克希德公司即得請求追加工程款及延展工期。

⒋再者，系爭航管系統係由硬體、軟體及韌體所構成，該硬體、軟體及韌體間須相容始能配合運作，惟因民航局藉由TACCPDR待辦事項第51號提出本鑑定項目「使用中跑道之功能」之約外要求，而大量新增額外軟體及硬體功能，致基本需求規章原訂之顯示器韌體不能與該等額外新增之軟體及硬體功能相容，民航局乃指示中信局提出1987年1月8日變更指令不僅涉及顯示器之韌體，並包括顯示器之軟體及硬體功能。民航局1987年1月22日函文亦自承：「顯示器韌體必須能夠支援(民航局)依TACC PDR待辦事項第51、52、61及一般待辦事項第72號所提出之要求」，益徵民航局上開待辦事項之約外要求，係包含擴增系爭航管系統顯示器之軟體、韌體之功能，且並應新增之韌體功能，期能支援該等新增之軟體功能(即TACC PDR待辦事項第51號所提出之新增軟體功能要求)。

⒌抑有進者，顯示器韌體乃系爭航管工程之工程要徑(Critical Path)，故該等屬工程要徑之顯示器韌體工程事項之延誤，必然會立即影響整體系爭航管工程之工期，故系爭航管工程完工時程自有系爭闡明條款第4.2條(可宥恕遲延)之適用，系爭航管工程整體工期應予展延。再者，民航局上開待辦事項之約外要求，係包含擴增系爭航管系統顯示器之軟體、韌體之功能，且並應新增之韌體功能，期能支援該等新增之軟體功能致TACC系統及TCC系統之飛航資料處理及顯示器完整資料欄之設計進度及工程執行因費時反覆澄清，而生遲延。

B.民航局等則以：

⒈選取適當航路/跑道之選項之功能，確為系爭航管自動化系統之基本功能，亦在TACC規格書與TCC規格書之範圍內，此業經中科院鑑定認定在卷。

⒉為因應環境(如：風向)等操作條件之異動，必須變更原定之航路/跑道(下同)而另行選取適當之航路，故洛克希德公司自行提出投標文件第2冊第3.2.2.6節關於「環境資料庫維持子系統」，明確規定：「在更新資料庫檔案後，領空/系統參數程式須在飛航計畫資料庫中掃瞄動態飛行計畫(active flightplan)，並針對業經SARO（即因應環境等操作條件之異動，而變更並選取適當航路/跑道之功能，TACC規格書第3.7.3.2.1.46節將之稱為"Select Adapted Route Options"，以下簡稱為SARO）功能功能修正之飛行計畫，傳送更正之訊息至飛航計畫處理子系統」，可知為因應風向等操作環境之異動，變更並另行選取適當航路之SARO功能乃系爭航管自動化系統應具備之基本功能，並由「環境資料庫維持子系統」(EnvironmentalData Base Maintenance Subsystem，下稱EDBM)將該SARO功能執行後之結果再行傳送至子系統，SARO功能並非約外要求，此再觀諸洛克希德公司投標文件第2冊附表3-5亦明訂「變更適當航路」(即SARO功能)為EDBM中「領空/系統參數」項下之子功能等情，益徵明確。

⒊SARO功能不但為TACC規格書等明訂之功能性需求，更經洛克希德公司投標文件明訂其執行細節與系統定位，故民航局就此提出說明，僅在闡述TACC規格書、TCC規格書與洛克希德公司投標文件之內容，並重申系爭航管自動化系統之基本功能而已。

⒋洛克希德公司雖主張，本件爭議在於「完整資料欄(FDB)是否應有使用中跑道」之功能，而非「SARO功能是否為約外需求」，兩者彼此間全無關連云云，實無理由，蓋以本項爭議即係SARO功能是否屬於約外要求，而SARO功能必須將經處理並選取之相關航路/跑道資訊，顯示至管制席(CSU)之顯示器之FDB上，方能使管制人員及時知悉而妥為實施航管作為，故「FDB應具備SARO之顯示功能」及「SARO乃TACC規格書第3.7.3.2.1.46節與洛克希德公司投標文件所載之功能性需求」，實屬一體兩面之功能性需求。

⒌洛克希德公司復主張其已依民航局等要求，於TACC-1100設計文件中納入「變更設計」之使用中跑道，並執為本件遲延之原因，洵屬無據，蓋以細繹其主張為證之TACC-1100文件，於第136.1節之「目的」(purpose)中明示SO訊息之目的，在使TACC與TCC之系統人員，能通知FDP(飛航資料處理系統)關於選定機場之使用中跑道有所異動(changes)之資訊，不但未有任何隻字片語提及所謂之「變更設計」，於該文件第136.2目之「需求來源」(Requirements Sources)，更載明係以TACC規格書第3.7.3.2.1.46節為執行依據，可知洛克希德公司所稱設計不過係依TACC規格書相關規定進行而已，並無任何將所謂「約外需求」納為「變更設計」之可言，民航局等更未就此提出任何約外需求，不得以此執為遲延之藉口。

⒍74年5月21日函文，其記載「"out-of-scope"」items，以雙引號方式標示所謂「out-of-scope items」之用語，可知民航局等不但未曾自承此為約外要求，反而使用雙引號「"」來強調所謂之「約外要求」不過為洛克希德公司之單方主張而已，此觀諸民航局等於其後之74年5月30日函文中進一步說明：「…民航局要求『使用中跑道』之資訊應以下列方式處理：…若貴公司認為此係約外需求，則請依相關程序敘明理由辦理，並提出影響預估」等語，益徵明確，洛克希德公司竟對前揭函文斷章取義認民航局已自承使用中跑道功能為約外要求，顯無足採。

⒎洛克希德公司主張，民航局等已自承涉及SARO功能之TACC系統PDR待辦事項第51項為約外要求，並指示中信局於76年1月8日依闡明條款第4.1條及第4.3條規定，提出變更指令，更屬無據，蓋以細繹前揭中信局函文，並無依闡明條款第4.3條規定就前揭待辦事項本身核發變更指令之意思，更無隻字片語敘及民航局等自承TACC系統PDR待辦事項第51項本身已構成所謂之約外要求。

⒏查洛克希德公司1985年9月4日函之內容略以：「洛克希德公司已收受Reference 2.所示之函文，並認為應依闡明條款第4.3條之變更指令辦理。洛克希德公司正等候民航局關於前揭Reference 3.所示函文之回覆，該函文係指合併PDR待辦事項第51、52及61項而言」，而PDR待辦事項第51項(Action Item51，下稱AI51)係指「使用中跑道」(SARO功能)而言，業經洛克希德公司自承在案。洛克希德公司雖主張，其已於1985年9月4日函中建議AI51涉及闡明條款第4.3條之變更指令，故應展延系爭航管自動化系統之交貨期限，其就本件遲延為不可歸責云云，惟細繹該函所引用之洛克希德公司1985年7月2日函，其就AI51明白記載：「洛克希德公司很榮幸能告知民航局...此對未來契約所預定之交期並無任何影響」，可知洛克希德公司已自承AI51對系爭航管自動化系統之交貨日期並無任何影響，與本件遲延間自無任何因果關係。

⒐洛克希德公司主張「使用中跑道」為約外要求，惟其基於所謂合作之精神，故將之列入系統設計，而為本件遲延之原因云云，與事實不符，蓋以細繹洛克希德公司提出之證據，與其主張俱無關連，洵屬無據，況此部分涉及洛克希德公司提出修約提案書所列PDR待辦事項第51項，業經第四次契約變更書吸收處理完畢，故不論此部分之爭議是否構成約外要求，洛克希德公司均不得再執為本件遲延之宥恕事由等語，資為抗辯。經查：

⒈洛克希德公司主張TACC規格書、TCC規格書均未規定完整資料欄內應有使用中跑道之功能，TACC規格書僅有選取跑道功能之功能要求，TCC規格書則僅規定指定跑道之功能，民航局於73年9月21日待辦事項會議中，要求TACC系統及TCC系統完整資料欄新增使用中跑道之功能，為屬約外要求云云。

⒉按TACC規格書第3.7.3.2.1.46節，規定TACC系統應具備選取適當航路／跑道之選項，具備適應性的選擇能力，以因應可預見之操作變更（詳上證11號、12號，見本院卷1第161至164頁,另見TACC規格書第3-197頁）；又TCC規格書第3.7.3.3.4.3.4.3節Run-wayor Approach Assignment Read out亦規定TCC系統應使雷建控制者能在選取之完整資料欄內要求／除去關於跑道或起飛之相關資訊（詳原證161號，另見TCC規格書第3-290頁），是TACC及TCC系統應具備要求、選取適合航路與跑道等資訊之選項功能，以因應航空管制之實際需求。參諸洛克希德投標文件第二冊第2-50頁明確同意多項細節將於PDR中決定（見外放洛克希德公司投標文件第二冊），民航局主張TACC與TCC系統應具備要求、選取適合航路與跑道等資訊之選項之功能，以因應航空管制之實際要求，選取適當航路／跑道之選項功能，為系爭航管自動化系統之基本功能，其多次去函表示該項功能應具備顯示使用中跑道之功能，以確保系統操作者知悉究竟尚有何等跑道可供選取，無非在闡釋TACC及TCC規格書之內容，尚非無據。

⒊洛克希德公司雖主張民航局於1985年5月21日函文中自承使用中跑道之功能要求為約外要求云云，惟查民航局於74年5月21日函稱「Attached, are copies of the 'final ver-sions'of PDR Action Items 51(dated 85-04-25) and 52(dated85-05-15).These have been updated to reflect theagreements reached in our discussions on 'out-ofscope'item.（附件係PRD待辦事項第51及52號之最後確定版本。這些版本業已依雙方討論約外要求項目時之結論予以更新）」（詳洛克希德公司民事上訴暨答辯理由⑶狀附件1⑹-12，見本院卷1第353至358頁），依其文意係表示函中所述第51及52項為雙方於關於約外事項之討論中達成合意之項目，並未表示此二項即為兩造合意之約外事項。且民航局於74年5月30日並函稱「CAA'request that the "Runways in Use"Informationbe handled in the following mananer:.....If you feelthat any part of this process is out-of-scops,thenyoushould follow the procedure agreed to in Plainfielddocument your reason for your position and provideanestimate of the cost to implement the out-of-scopeelement」，言明如洛克希德公司認此「使用中跑道」為約外要求，則應依相關程序說明理由並提出成本評估（詳洛克希德公司民事上訴暨答辯理由⑶狀附件1⑹-13，見本院卷1第359至360頁），可認締約雙方於民航局74年5月21日函所稱之會議中並未達成「使用中跑道」為約外需求之合意，民航局亦無以74年5月21日函表示同意「使用中跑道」為約外要求，否則即無於74年5月30日函中告知洛克希德公司，”如”洛克希德公司認此部分為約外需求時應如何辦理。洛克希德公司據此主張民航局已於74年5月21日函承認「使用中跑道」為約外要求，應無可取。

⒋洛克希德公司雖據民航局74年5月30日函告知洛克希德公司認係約外要求，應提出關於時程／成本影響之預估之表示，主張民航局已承認使用中跑道為約外要求云云，惟民航局74年5月30日函文僅係表示"如"洛克希德公司認使用中跑道功能為約外要求，請依相關程序敘明理由辦理，並提出影響評估，並無任何承認使用中跑道為約外需求之表示，該主張即非可採，況洛克希德公司雖將使用中跑道功能列入TACC-1100之作業電腦程式功能規格文件中，然並未舉證究竟耗費多少時間或金錢於該項設計中，亦無法證明於何時完成該項設計，更不能遽以主張協商時間即屬該項工程之延誤時間，故尚難認為洛克希德公司因此蒙受損失，洛克希德公司持上開理由主張此部分為約外要求，並無足取。

⒌又洛克希德公司主張其於1985年9月4日函文表明民航局1985年8月29日函文關於PDR待辦事項第51項(Action Item 51，下稱AI51，即指「使用中跑道」）指示涉及闡明條款第4.3條之變更指令，故應展延系爭航管系統之交貨期限及追加工程款云云。經查，前揭1985年9月4日之函文所引用之洛克希德公司1985年7月2日函（按：該函文係合併PDR代辦事項第51、52、61項），其就AI51明白記載：「洛克希德公司很榮幸能告知民航局...此對未來契約所預定之交期並無任何影響」(詳原證177號第2段：「Lockheed is pleased to advise the CAA that,…there will be no impact on scheduled completion dates.，另見本院卷23第479頁)，可知洛克希德公司已自承AI51對系爭航管自動化系統之交貨日期並無任何影響，與本件遲延間自無任何因果關係，是故洛克希德公司該項主張顯無理由。

⒍另洛克希德公司雖主張顯示器軟體及韌體設計乃系爭航管系統之工程要徑，惟洛克希德公司從未於訴訟程序中提出系爭航管系統之工程要徑圖，亦未舉證設計顯示器韌體工程事項有何延誤工期之情以實其說，故其主張尚難採信。

⒎中科院鑑定認為依據TACC規格書第3.7.3.2.1.46節SelectAdapted Route Options中即在說明飛機路徑/跑道改變之處理方式之功能需求，其中Select Adapted Route Option的功能須提供一適合航路及跑道選項，依據MIL-STD-1521A軟體設計審查與稽核系統發展規範，民航局對此提出系統細部需求，係屬合理，故此項要求並非約外要求（見外放之中科院鑑定報告第39、40頁）；另成大鑑定報告亦認洛克希德公司所提證物內容與所控違約事實內容不符，洛克希德公司聲請鑑定說明中所指之會議記錄未見於證物中（見外放之成大鑑定報告第34頁），故洛克希德公司主張此部分為約外要求，應無可取。

⒏另成大及中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開㈥⒌所述），就過失比例部分尚無庸參考，併予敘明。

⒐關於洛克希德公司於102年8月6日民事調查證據聲請狀中，請求成大航太所補充說明之詢問事項，已於上開㈥⒈、⒉、⒊、⒋、⒌、⒍部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

⒑最高法院就該部分發回意旨雖指出：「關於附表一編號一之(六)「指定跑道／使用中跑道約外要求」部分，上訴人曾於第一審具狀主張：民航局於七十四年五月十四日致函洛克希德（原證一七二），就使用中跑道提出顯示器資訊（約外PAR、PER等），並於接獲洛克希德提出之建議（原證一七七），即於同年八月二十九日發函（原證一七九）指示洛克希德進行工作待辦項目第一五一項最終結論，洛克希德則於同年九月四日函復（原證一八○），表示已接獲民航局上開指示，並依契約第四．三節工程變更規定（原證一七八）提出建議（原證一七六、一七七）。雖嗣後洛克希德與民航局就建議內容之價格及工程期限協商無顯著成效，然洛克希德基於合作精神於接續二年半內將「使用中跑道」功能特徵列入TACC及TCC系統設計內（原證一八一～一八三）云云（一審卷(二)七○～七二頁），似見上訴人與民航局於七十四年九月四日就此部分工程期限僅是協商而未達成協議。且依上訴人於第一審提出之原證一八一所載，TACC-1100文件之自動化電腦程式功能規格136.1目的說明，似可證明上訴人業依民航局要求變更設計為使用中跑道。果爾，則能否以「美商（港商）洛克公司於七十四年八月八日系爭航管契約第四次修正時，豈有可能未將之列入延長工期之考量」、「上訴人亦未舉證證明美商（港商）洛克公司已依民航局之上開要求變更設計，自難認系爭航管工程之遲延完工，與民航局所提出上開要求變更設計間，具有相當因果關係存在」等由，逕認上訴人不具有系爭闡明條款第4.2條第1項第④款所定之可宥恕事由，尤滋疑問。...」，惟，前開㈥⒌已說明洛克希德公司於第四次修正後之1985年9月4日之函文所引用之洛克希德公司1985年7月2日函，其就待辦事項51明白記載：「洛克希公司德很榮幸能告知民航局...此對未來契約所預定之交期並無任何影響」，可知洛克希德公司已自承AI51對系爭航管自動化系統之交貨日期並無任何影響，與本件遲延間自無任何因果關係，是故洛克希德公司該項主張顯無理由，併此敘明。

㈦第一大項第七小項關於洛克希德公司主張「國際民航組織之程序變更之約外要求」部分，即民航局於74年10月22日函指示洛克希德公司修改TACC及TCC系統之設計，以符合國際民航組織文件第12版之規定，是否為屬約外要求？

A.洛克希德公司主張：

⒈TACC與TCC規格書明確清楚規定、要求TACC與TCC之系統設計工作依國際民航組織第10版，TACC航路處理之輸入資料則依第11版文件進行設計，民航局突於系爭航管工程執行中，要求洛克希德公司依據國際民航組織第12版文件變更已完成之部分設計，已屬約外要求。

⒉洛克希德公司於接獲民航局指示後，立即就國際民航組織文件版本之變動，對於TACC及TCC系統設計所造成之影響，進行廣泛評估。民航局係於1985年10月22日，突然提出依國際民航組織第12版文件修改設計之約外要求，此距雙方簽署系爭航管契約之時(1983年12月20日），已近有二年之久，如民航局認應依第12版文件進行設計，其自應於1984年6月間立即提出變更要求，俾免後續設計之人力、時間之浪擲，並影響工程時程。惟民航局竟於國際民航組織第12版文件公布一年四個月後，率爾要求洛克希德依國際民航組織第12版文件進行修改，此不僅嚴重影響、變更基本需求規章之原訂技術需求，且洛克希德公司耗費數十月之人力、資源所進行之設計，亦恐將付諸流水。

⒊民航局上述約外要求影響系爭航管工程(TACC系統及TCC系統)之整體設計，範圍甚廣，洛克希德公司於接獲民航局之指示後，被迫暫停進行中之相關設計工作，積極投入國際民航組織第12版文件之研究工作，以詳細檢視、模擬應進行變更設計之範圍，以及該等變更設計所需之額外費用、時間。相關人力投入之研究，以及暫停進行中之設計、開發工作，已影響且延後相關人員進行系爭航管工程設計工作之時程。

Ａ.民航局等則以：

⒈按航管系統與國際航管系統有密切關連，為能與國際航管系統接軌，在國際民航組織相關文件改版時，航管系統之設計自需配合調整，方能確保航空管制之實效性與安全性，此並有中科院鑑定報告可稽。為配合國際民航組織(ICAO)第4444-RAC/501文件改版為第12版，民航局乃於74年10月22日去函請求洛克希德公司配合辦理該項改版事宜，惟洛克希德公司旋於同月24日表示此可能增加時程與成本，民航局為縮短系爭航管自動化系統之交付時程，隨即於74年11月11日雙方舉行之會議中，表示取消上開要求，並於同月29日再次以正式函文通知洛克希德公司，是關於系爭航管自動化系統配合改版之設計爭議，縱令曾有亦已不復存在。

⒉實則，系爭航管自動化系統之設計，應配合ICAO（國際民航組織)相關文件之改版或調整，方能與國際航管系統接軌，以避免衍生飛安事故或外交爭端等後遺，此觀諸洛克希德公司投標文件第2冊亦規定：洛克希德公司於從事設計工作時，針對特定技術標準與ICAO操作標準之變動，必須顧及並納入考量等語即明。

⒊何況，洛克希德公司並未接受民航局所為之說明，且未舉證證明其已依民航局之說明變更設計，自難認本件遲延與上訴人前揭說明間有相當因果關係，洛克希德公司自不得主張闡明條款所定之宥恕事由。經查：

⒈洛克希德公司主張TACC及TCC規格書第2.4節「其他文件」均明定以國際民航組織文件第10版為系爭航管系統之規範文件，另TACC規格書第3.7.3.2.11.2節航路處理之輸入資料，則規定採用國際民航組織文件第11版，惟民航局卻於74年10月22日函中指示洛克希德修改TACC及TCC系統之設計，以符合國際民航組織文件第12版之規定，為屬約外要求云云。

⒉按航管系統與國際航管系統有密切關連，為能與國際航管系統接軌，在國際民航組織相關文件改版時，航管系統之設計自需配合調整，方能確保航空管制之實效性與安全性，合先敘明。

⒊查民航局確於74年10月22日去函指示洛克希德公司修改TACC及TCC系統之設計，以符合國際民航組織文件第12版之規定（詳洛克希德公司民事上訴暨答辯理由⑻狀附件1⑺-3，見本院卷4第328至329頁），惟洛克希德公司於接獲民航局指示後，即於74年10月24日去函民航局告知改版將會對系爭航管自動化系統工程之成本及工期造成影響（詳洛克希德公司民事上訴暨答辯理由⑻狀附件1⑺-4，見本院卷4第330至331頁），民航局旋於74年11月29日撤回該項指示（詳洛克希德公司民事上訴暨答辯理由⑻狀附件1⑺-6，見本院卷4第337至338頁），此項指示既經民航局撤回而不復存在，洛克希德公司雖主張其於接獲民航局74年10月22日指示後，即暫停相關設計工作，投入第12版文件之研究，惟洛克希德公司尚在等待民航局確定是否要修改設計，是否有進行相關設計，尚非無疑，且其於本院開庭審理時已自承從民航局提出該要求至撤回之間僅18天（詳本院100年11月25日準備程序筆錄，見本院卷4第633頁第11行），甚難想像洛克希德公司於該18天內即已進行系爭航管系統之修改設計，況其仍未舉證其已有實際從事此項指示之相關研究設計工作，故其以民航局有此部分之約外要求，主張其得依闡明條款第4.1條調整工程期限，並無足取。

⒋中科院鑑定認為民航局配合國際民航組織的文件變更，提出執行改版設計分析，係屬合理，且民航局在短時間內予以撤銷改版需求，並未超出契約範圍，並非約外要求（見外放之中科院鑑定報告第41、42頁）；另成大鑑定報告亦認民航局從提議到撤銷修改總計22天（自74年10月22日至同年11月12日），對洛克希德公司所造成之影響應極為有限（見外放之成大鑑定報告第37頁），故洛克希德公司主張此部分為約外要求，應無可取。

⒌另成大及中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開㈦⒋所述），就過失比例部分尚無庸參考，併予敘明。

㈧第一大項第八小項關於洛克希德公司主張「顯示時間間隔之曖昧不明及擴張之約外要求」部分，即民航局於73年9月20日提出顯示時間間隔第一版規格時，要求「Clearance Processing」(註：洛克希德公司譯為「淨空處理」，民航局等則主張係「許可處理)及「Transfer Alert Porcessing」(註：洛克希德公司譯為「移轉警示處理」，民航局等則主張係「交管警示處理」），是否為約外要求？

A.洛克希德公司主張：

⒈TACC規格書關於顯示時間間隔之規格，付之闕如；且TACC規格書並未規定、要求「淨空處理」(Clearance Processing)及「移轉警示處理」(Transfer Alert Processing)等功能需求。

⒉民航局於1984年9月20日提出顯示時間間隔第一版規格時，不僅未清楚、明確定義時間間隔之顯示規格，且增加「淨空處理」(Clearance Processing)及「移轉警示處理」(Transfer Alert Processing)兩項要求。然TACC規格書第3.7.3.2.12節並未規定或要求「淨空處理」(ClearanceProcessing)及「移轉警示處理」(Transfer AlertProcessing)，故此兩項要求自屬約外要求。嗣後民航局於1984年9月21日初期設計審查待辦事項會議中，要求進一步協商。民航局之後再於1984年10月3日，就顯示時間間隔提出第二版之規格，但仍未能清楚、具體定義顯示時間間隔之規格，且仍保留上述兩項約外要求。為避免系爭航管工程延宕，洛克希德公司於1984年11月9日致函民航局，明確告知上述要求已逾越TACC規格書範圍，並檢附關於待辦事項第19項與第61號之立場說明書(Position Paper)及待辦事項第51項與第61號之立場說明書，說明「淨空處理(Clearance Processing)」與「移轉警示處理(Transfer Alert Processing)」均為約外要求。

⒊民航局以1985年8月29日函文，要求洛克希德公司執行TACCPDR待辦事項第61號(包含「淨空處理(Clearance Processing)」及「移轉警示處理(Transfer Alert Processing)」等二項約外要求)之顯示時間間隔最終版本規格。洛克希德公司於1985年9月4日函覆民航局，告知已收訖要求執行最終版本之指示，並表示民航局之約外要求係涉及系爭闡明條款第4.3條之變更指令，要求民航局依系爭闡明條款第4.3條規定之程序辦理追加價款及延展工期。雖民航局怠於依第4.3條之規定辦理延展工期及追加工程價款，惟洛克希德公司為避免延誤工程，即依TACC PDR待辦事項第61號之顯示時間間隔最終版本規格進行設計、開發，並提出TACC-1140與TACC-1110之作業電腦程式功能規格(Operational Computer Program FunctionalSpecification，下稱「TACC-1140文件」予「TACC-1110文件」)等設計文件予民航局審核，民航局並分別於1986年8月16日、1986年9月11日核准該TACC-1140文件及TACC-1110文件。依上開民航局已核准之TACC-1140文件第5.2節所示：「飛航顯示資料次功能，雖並未規範於TACC規格書(CAA-E-SS-001)，但將滿足依據PDR待辦事項第61號之決議所提出之需求，此有關顯示資料將於何時顯示，以及何種移轉警示將被傳送」，民航局既已核准上開文字，足徵民航局已承認其於PDR待辦事項第61號所提出「淨空處理(Clearance Processing)」及「移轉警示處理(Transfer Alert Processing)」要求，確屬約外要求，且洛克希德公司已設計、施作該二項約外要求，灼然甚明。

⒋民航局復要求於TCC系統增加TCC規格書所未規定、要求之顯示時間間隔，並要求重複審核民航局「已核准」之TACC-1140文件，致TACC系統之設計無從確定，影響系爭航管系統之工程進度。

B.民航局等則以：

⒈按TACC規格書第3.7.3.2.12節規定TACC系統應能產生並輸出歸航協調(inbound coordination)等五種不同類型之飛航資料，並於該節中規定各類飛航資料輸出之時間間隔，在規格書中係以可變參數表示，且就TACC系統所應產生並輸出之飛航資訊，在TACC規格書中尚有第3.7.3.2.1.10節之「現行飛行計畫」(Current Flight Plan)資訊，與第3.7.3.2.16.1節之「跨越飛航情報區(FIR)之位置/時間決定」資訊(FlightInformation Region Boundary CrossingFix/ TimeDetermination)二者。因「現行飛行計畫」之資訊係指飛行計畫在經管制中心許可後，TACC應能將已經許可之航空器意圖(actual cleared flight intent)等資訊適時傳輸至TCC等系統，是關於航空器已經許可(Clearance)之資料，亦屬TACC系統所應處理之飛航資訊(下稱「許可處理」功能)；而所謂「交管警示處理功能」(Transfer Alert Processing)，係指TACC規格書第3.7.3.2.16.1節所定之「跨越飛航情報區(FIR)之位置/時間決定」及「更新傳遞功能」等資訊處理功能，即「在飛越台北飛航情報區之過程中，飛航器於進入台北飛航情報區時，應由前個飛航情報區估算其時間並將該資料傳送至台北飛航情報區，而該飛航器離開台北飛航情報區之時間與位置，則應在預估飛越之時間前，於特定時間間隔下，傳送至該飛航器即將進入之下個飛航情報區，且在預估飛越時間與實際飛越時間可能不一致時，須更行傳遞更新之相關資訊，以隨時掌握該飛航器之航跡」之功能，是Transfer Alert之主要目的，在將飛航器預計交管給下一個接管單位或席位之一定前置時間內，對管制員提出警示功能，使飛航管制作業予以自動化，輔助管制員作業，兼顧降低管制員工作量、提升工作效率及保障飛航安全等目的，此為系爭航管自動化系統建置之主要目的之一。綜上可知，「許可處理」與「交管警示處理」等二項功能，不但有TACC規格書之明文依據，更為航管作業系統之基本及必備之功能，則民航局對此提出說明，根本無涉提出所謂約外要求。

⒉按TACC規格書第3.7.3.2.12節規定飛航資料有顯示時間間隔，且TACC規格書第3.7.3.2.1.10節與第3.7.3.2.16.1節等規定，「現行飛行計畫」與「跨越飛航情報區(FIR)之位置/時間決定」等飛航資料，同有應適時傳輸(as appropriate)或顯示時間間隔(a specified interval)之要求，是民航局於73年10月3日去函洛克希德公司，除提出顯示時間之間隔說明外，一併於該函中說明「許可處理」(Clearance Processing)與「交管警示處理」(Transfer Alert Processing)等飛航資料亦有時間間隔之要求存在，提醒洛克希德公司於設計時應納入考量，根本無涉約外要求。

⒊「許可處理」與「交管警示處理」分屬洛克希德公司依TACC規格書第3.7.3.2.1.10節與第3.7.3.2.16.1節等規定所應提供之功能，並經中科院鑑定予以認定在案，是民航局多次去函洛克希德公司說明本件系統基於前揭規定應具備「適時傳輸(as appropriate)」或「於特定時間間隔(as pecifiedinterval)傳輸」之需求，不外重申系爭航管自動化系統之基本功能而已，從未承認此一功能為所謂「約外要求」，並已於73年11月23日去函向洛克希德公司澄清。

⒋洛克希德公司又主張民航局於75年8月16日所核准之TACC-1140文件表示民航局自承「許可處理」與「交管警示處理」為所謂約外要求云云。惟細繹前揭TACC-1140文件，不僅看不出有所謂民航局之自承，且其所處理者為PDR待辦事項第61項(Action Item 61；AI61)，於5.1「目的」(purpose)處揭示AI61所示FDP子功能之目的在瀏覽飛航顯示資料並選擇何者適於立即顯示，並於附件A明定AI61之功能為「飛航顯示之週期性瀏覽」(Flight Posting Periodic scan)，不惟如此，民航局更於嗣後核准之TACC-1110文件中，說明AI61之重點在於「適當之顯示間隔」(adapted Posting Intervals)，是前揭TACC-1140文件係指「許可處理」與「交管警示處理」之功能性需求，在TACC規格書中僅有「應適時傳輸」或「於特定時間間隔傳輸」之概括性描述，尚未落實於具體設計作為而言。

⒌洛克希德公司雖主張，其已於1985年9月4日函中表示PDR待辦事項第61項(Action Item 61，下稱AI61，係指「許可處理」與「交管警示處理」等飛航資料顯示之時間間隔），涉及闡明條款第4.3條之變更指令，故應調整系爭航管自動化系統之交貨期限，其就本件遲延為不可歸責云云，惟細繹該函所引用之洛克希德公司1985年7月2日函，其就AI61明白記載：「洛克希德很榮幸能告知民航局...此對未來契約所預定之交期並無任何影響」，可知不論AI61是否為約外需求，洛克希德公司已自承AI61對系爭航管自動化系統之交貨日期並無任何影響，與本件遲延間亦無任何因果關係等語，資為抗辯。經查：

⒈洛克希德公司主張TACC規格書第3.7.3.2.12節「Flight DataPosting Determination」中無關於顯示時間間隔（PostingTime Interval）之規格參數，且增加「ClearanceProcessing」及「Transfer Alert Porcessing」兩項TACC規格書第3.7.3.2.12節未規定之要求，為屬約外要求云云。

⒉查，TACC規格書第3.7.3.2.12節規定TACC系統應能產生並輸出歸航協調、起飛協調、抵達協調、主動航路及終端區域領空飛越五種不同類型之飛航資料，並規定各類飛航資料輸出之時間間隔（Time Interval）。由TACC系統所應產生並輸出之飛航資訊(見外放TACC規格書第3-250至3-253頁）及TACC規格書第3.7.3.2.1.10節「現行飛行計畫」相關規定，可知TACC規格書所定現行飛行計畫之資訊，係指飛行計畫經管制中心許可後，TACC應能將已經許可之航空器意圖等資訊適時傳輸至TCC系統，故關於航空器已經許可之資料，應亦屬TACC系統所處理之飛航資訊（見外放TACC規格書第3-180至3-181頁）；另從TACC規格書第3.7.3.2.16.1節「跨越飛航情報區之之位置/時間決定」相關規定（見外放TACC規格書第3-262頁），可知該規定係指飛航器飛越台北飛航情報區之過程中，在進入台北飛航情報區時，應由前個飛航情報區估算其時間並將資料傳送到台北飛航情報區，該飛航器離開台北飛航情報區之時間及位置，則應在預估飛越之時間前，於特定時間間隔下，傳送至其即將進入之下一個飛航情報區，故關於「跨越飛航情報區之位置／時間決定」及與之相關之更新傳遞功能，亦屬TACC系統所應處理之飛航資訊。TACC規格書第3.7.3.2.12節「飛航資料顯示」既規定飛航資料有顯示時間間隔，TACC規格書第3.7.3.2.1.10節「現行飛行計畫」與第3.7.3.2.16.1節「跨越飛航情報區之位置/時間決定」亦有應適時傳輸或顯示時間間隔之要求。則民航局於73年9月20日提出顯示時間間隔規格時，一併說明Clearance Processing及Transfer Alert Porcessing等亦有時間間隔之要求存在，提醒洛克希德公司於設計時應納入考量，並非提出約外要求；退步言之，縱TACC規格書針對上開部分定義不清，兩造仍可於PDR或CDR會議中討論，且該等事項皆屬確保飛航安全之必要功能，本為系爭契約約定之目的功能，故就此部份尚難認為屬約外要求。

⒊洛克希德公司另主張民航局於1985年8月29日要求執行Clearance Processing及Transfer Alert Porcessing之顯示時間最終版規格，洛克希德公司於1985年9月4日覆函表示此涉及闡明條款4.3條之變更指令，民航局未予否認，應認已承認而為約外要求云云。查，洛克希德公司固於74年9月4日函表示此部分涉及闡明條款4.3條之變更指令，要求民航局依闡明條款第4.3條規定之程序辦理（詳洛克希德公司民事上訴暨答辯理由10狀附件1⑻-14，見本院卷4第328至329頁），民航局固未就洛克希德公司之上開函文為回應，惟默示之意思表示與單純之沉默有別，單純之沉默除經法律明定視為已有某種意思表示外，不得即認係表示行為，洛克希德公司復未舉證民航局嗣有依闡明條款第4.3條規定之程序辦理，其以此主張民航局已承認此部分為約外需求，應非可取；況前揭洛克希德公司1985年9月4日之函文所引用之洛克希德公司1985年7月2日函（按：該函文係合併PDR代辦事項第51、52、61項），其就PDR代辦事項第61項（ActionItem 61，下稱AI61，即「Clearance Processing」及「Transfer Alert Porcessing」）明白記載：「洛克希德公司很榮幸能告知民航局...此對未來契約所預定之交期並無任何影響」(詳原證177號第2段，另見本院卷23第479頁)，可知洛克希德公司已自承AI61對系爭航管自動化系統之交貨日期並無任何影響，與本件遲延間自無任何因果關係。

⒋洛克希德公司雖又以其嗣已將顯示時間間隔之最終規格版本納入電腦程式功能設計文件，即TACC-1140與TACC-1110之作業電腦程式功能規格文件，民航局於75年8月16日核准上開TACC-1110文件，而該文件第5.2節表示「飛航顯示資料次功能，雖並未規範於TACC規格書(CAA-E-SS-001)，但將滿足依據PDR待辦事項第61號之決議所提出之需求，此有關顯示資料將於何時顯示，以及何種移轉警示將被傳送(The FDP subfunction,while not required by CAA-E-SS-001, will satisfyarequirement derived from the resolution of PDRAction Item 61 as its relates to the time at whichpostings are to be displayed, and at which TransferAlerts are to be transmitted)」，故民航局已承認此部分為屬約外要求云云。惟查，TACC-1140文件第5.1條「PURPOSE（目的）」揭示PDR待辦事項第61項所示FDP子功能之目的在瀏覽飛航顯示資料並選擇何者適於立即顯示，並於附件Ａ明定待辦理事項第61項之功能為「飛航顯示之週期性瀏覽」（詳上證第92號，見本院卷5第417至421頁）。民航局嗣於核准TACC-1110文件中，說明待辦事項第61項之重點在於「適當之顯示間隔」（詳洛克希德公司附件1-⑻-16，見本院卷5第174頁,7.5倒數第2行），足見TACC-1140文件「The FDP subfunction,while not requiredbyCAA-E-SS-001,will satisfy……」之意，係指「ClearanceProcessing」及「Transfer Alert Processing」之功能性需求，在TACC規格書中僅有「應適時傳輸」或「於特定時間間隔傳輸」之概括性描述，尚未落實於具體設計而言，況從前揭文字中尚難認為民航局有自承該部分爭議為約外要求之意，或有任何「承認」之字句，故尚難以此認民航局承認此部分為約外要求。

⒌中科院鑑定報告認為顯示時間的間隔係以建成系統建置目的為主要的考量依據，而設定顯示間隔可降低系統設計的複雜度，關於Clearance Processing及Transfer Alert Porcessing之需求，實為TACC基本需求規章之細部設計說明，並非約外要求（見外放之中科院鑑定報告第42至43頁），與本院見解相符，故洛克希德公司主張此部分為約外要求，應無可取。

⒍另中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如１-⒌所述），就過失比例部分尚無庸參考，併予敘明。

⒎關於洛克希德公司於102年8月30日民事調查證據聲請續狀中，請求成大航太所補充說明之詢問事項，已於上開㈧⒉、⒊部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

㈨第一大項第九小項關於洛克希德公司主張「有限資料欄（Limited Data Block）之使用定義不明及矛盾」部分）：A.洛克希德公司主張：

⒈洛克希德公司進行LDB（有限資料欄）設計所需之下列五項必要需求：㈠LDB應為主動或被動顯示？㈡當一個LDB產生時，該LDB應包含全部或單一航跡？㈢是否僅限於某航管人員管制彊域內之航跡，始應顯示LDB，或全部航跡均需以LDB之方式，顯示於每位航管人員之狀況顯示器內？㈣是否僅非管制航跡始顯示LDB？或管制航跡亦須顯示LDB？㈤是否僅相關連的航跡始須顯示LDB？或非相關連之航跡均須顯示LDB？等上列五項資訊。但TACC規格書關於有限資料欄之顯示條件規格不明及相互矛盾，致洛克希德公司無法據以進行設計。

⒉洛克希德公司於1984年7月31日TACC之PDR會議中，已就此部分其認為矛盾及曖昧不明之處，與民航局討論，嗣又於1985年7月8日會議中請民航局提出澄清說明，民航局於1985年7月8日函中自承現行文件（即TACC規格書）並未清楚定義狀況顯示器資料欄之顯示，洛克希德公司乃於1986年1月14日依雙方多次討論之意見，撰寫有限資料欄之設計說明，經民航局於1986年2月20日函覆始告確定，亦於該函自承即TACC規格書並未清楚定義狀況顯示器資料欄之顯示，嚴重延誤系爭航管工程之進度，而有闡明條款第4.2條第1項第4、6款之適用。

⒊民航局為更正上開TACC規格書中有限資料欄顯示條件規格曖昧不明及矛盾之處，乃委託邁特公司備置一套TACC規格書變更頁稿(Draft TACC Spec. Change Pages)，並於1987年7月8日提供予洛克希德公司，足證有限資料欄(LDB)之原訂規格確有矛盾，且依系爭闡明條款第4.3條「變更指令」(ChangeOrder)規定，若符合第4.2條「可宥恕之遲延(ExcusableDelays)」各款不可歸責於洛克希德公司之事由時，洛克希德公司即得請求延展工期。

⒋民航局1986年7月23日函文檢附之ATC-914航管系統顯示器韌體需求規格表明有限資料欄(LDB)之規格矛盾及曖昧不明涉及ATC-914航管系統顯示器韌體需求規格(FirmwareRequirement Specification, ATC Displays)。民航局之工程技術顧問邁特公司於1988年1月15日之評估報告亦指明顯示器韌體(display firmware)」乃系爭航管工程之要徑(criticalpath)。因TACC規格書內有限資料欄之規格矛盾及曖昧不明，致屬系爭航管系統要徑(critical path)之顯示器韌體(display firmware)相關設計、開發窒礙難行，並致影響「整體系爭航管工程」之工期。而洛克希德公司於1985年7月8日會議中指明TACC規格書內關於有限資料欄(LDB)之規格矛盾及曖昧不明，迄至系爭航管契約於1988年6月25日終止時，民航局仍未就該TACC規格書內關於有限資料欄(LDB)之規格提出變更指令(change orders)，此致屬於工程要徑之顯示器韌體(display firmware)相關設計、開發窒礙難行，並致影響整體系爭航管工程之工期，故整體系爭航管工程因TACC規格書內關於有限資料欄(LDB)之規格矛盾及曖昧不明之因素，至少因而延誤2年11個月。

B.民航局等則以：

⒈按系爭航管自動化系統應採由上而下之建置方式，由洛克希德公司負責將買受人對系爭航管自動化系統之需求轉換為具體可行之設計藍圖，是不問關於LDB之基本需求規章是否具抽象性，均不構成需求曖昧不明，且民航局對需求所為之具體說明亦不致構成約外要求，洛克希德公司更有義務主動於後續之PDR與CDR會議中積極瞭解買受人之需求，而非一味主張基本需求規章之說明不足致無法及時進行軟體設計，其就本件遲延為不可歸責云云，此亦有中科院鑑定相同可稽。

⒉洛克希德公司主張民航局委請邁特公司備置TACC規格書變更頁稿，而修正TACC規格書第3.7.3.3.4.5.1.3節第4點規定，可知LDB之顯示規格曖昧不明云云，實屬無據。蓋以細繹該函文之內容，僅係將兩造於TACC系統之PDR階段及CDR階段曾經達成之各項相關協議，納為TACC規格書之變更頁稿而已，並非民航局單方提出之資料，是不論TACC規格書第3.7.3.3.4.5.1.3節第4點如何規定，該項規定既經兩造於TACC之PDR與CDR階段共同確認在案，洛克希德公司自應據以從速進行設計，不應又藉口規定曖昧不明而延宕系爭航管自動化系統之建置時程，洛克希德公司就本件遲延為可歸責無疑。

⒊洛克希德公司又主張民航局業於74年7月8日函文自承LDB之定義不明，並執為本件遲延之原因云云，與事實不符，蓋以細繹該函文內容係記載「現行文件(The current availabledocumentation)未清楚定義SD之資料欄顯示」等語，係指當時洛克希德公司提出之設計文件未能清楚說明SD上之LDB顯示情形，並非指基本需求規章不明等語，資為抗辯。經查：

⒈洛克希德公司主張其進行有限資料欄（LDB）之設計，但TACC規格書關於有限資料欄之顯示條件規格不明及相互矛盾，致洛克希德公司無法據以進行設計云云。

⒉按系爭航管自動化系統應採由上而下之建置方式，由洛克希德公司負責將買受人對系爭航管自動化系統之需求轉換為具體可行之設計藍圖，是不問關於LDB之基本需求規章是否具抽象性，均不構成需求曖昧不明，且民航局對需求所為之具體說明亦不致構成約外要求，洛克希德公司更有義務主動於後續之PDR與CDR會議中積極瞭解買受人之需求，而非一味主張基本需求規章之說明不足致無法及時進行軟體設計，況前揭基本需求規章之「管制」或「非管制」等用語實為航管領域之基本定義與常見術語，並無任何語意不明或內涵不清之問題，此觀諸「飛航服務相關規範名詞定義」就「管制區域」(Controlledarea)、「管制地帶」(Control zone)及「管制空域」(Controlledairspace)等常見用語，均訂有基本內涵之詮釋等情即明(詳上證38號，見本院卷1第581頁)，是不論民航局是否詳細說明"Controlled"或"Uncontrolled"之內涵，洛克希德公司既然身為系爭航管自動化系統之出賣人及建置者，應有義務主動、及時於後續之PDR與CDR會議中，積極掌握並落實民航局對基本需求規章之澄清及說明，尚難認有何闡明條款第4.2條第1項第6款所定「任何超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之任何遲延」之情形，洛克希德公司主張其可依闡明條款第4.2條第1項第6款展延完工期限，並無可取。

⒊又依TACC規格書第3.7.3.3.4.6.4.3.3節第2點規定，有限資料欄自動顯示之時機，為航空器航跡脫離特定席位管制空域時，而依TACC規格書第3.7.3.3.4.5.1.3節第2點之規定（見外放TACC規格書第3-300至3-301頁），完全資料欄原則上於航空器航跡位於特定席位管制空域時自動顯示，但如經管理員之請求，即將已顯示之特定航跡完全資料欄變更為有限資料欄。亦即TACC規格書第3.7.3.3.4.6.4.3.3節第2點係規定有限資料欄自動顯示之時點，其第1點及第3.7.3.3.4.5.1.3節第4點則係規定有限資料欄被動顯示之時點，核屬就不同需求所為個別之規範，亦無互相矛盾或曖昧之情形。

⒋又TACC規格書第3.7.3.3.節為規範說明雷達資料處理電達席位所使用的雷達狀況顯示器（Situation Display，簡稱SD）功能之章節，第3.7.3.3.4.6.4.3.3節為其中之一小節，洛克希德公司之投標文件亦載「狀況顯示器前之雷達控制員，得在顯示器上進入並控制顯示器資料之數量……」（見本院卷16第23頁）。而航管人員管制區域內（In-sector）之顯示器係指規定於TACC規格書第3.7.2節之計劃管制席位（PlanningController Position）使用之列表顯示器（Insectortabular display），兩者為不同席位功能，洛克希德公司投標文件除上開SD功能外，亦另設有「tabular and informationDisplay」章節（見本院卷17第30頁），且於洛克希德公司投標文件上此二者亦各有其不同之顯示器圖示（見本院卷16第31至33頁），並無所謂適用關聯問題。

⒌洛克希德公司主張其於1984年7月31日TACC之PDR會議中，已就此部分其認為矛盾及曖昧不明之處，與民航局討論，嗣又於1985年7月8日會議中請民航局提出澄清說明，民航局於1985年7月8日函中自承現行文件（即TACC規格書）並未清楚定義狀況顯示器資料欄之顯示，洛克希德公司乃於1986年1月14日依雙方多次討論之意見，撰寫有限資料欄之設計說明，經民航局於1986年2月20日函覆始告確定，嚴重延誤系爭航管工程之進度，而有闡明條款第4.2條第1項第4、6款之適用云云。經查，細繹1985年7月8日該函文內容係記載「現行文件(Thecurrent available documentation)未清楚定義SD之資料欄顯示」等語(見本院卷1第411-416頁，即原證133，洛克希德公司上訴暨答辯理由⑶狀附件1-⑼-3)，係指當時洛克希德公司提出之設計文件未能清楚說明SD上之LDB顯示情形，並非自承基本需求規章不明，洛克希德公司於1986年1月14日依雙方討論之意見，撰寫有限資料欄之設計說明後，民航局即於同年2月20日函覆意見而告確定，應無未即時完成依契約所負義務之情形。而該函明確記載：...CAA並未變更洛克希德公司之原始文件(...We have not change the intent of yourorigalpaper)，然而，文件中某些原有定義非常不明，而需予調整(見本院卷1第431至436頁，即原證141，洛克希德公司上訴暨答辯理由⑶狀附件1-⑼-6)，可知該段「定義」並非LDB基本需求規章之定義，而係洛克希德公司之設計文件有定義不明之缺陷。至於1984年7月31日洛克希德公司提出問題起至洛克希德公司提出設計說明前之期間，既經洛克希德公司與民航局多次討論，亦未舉證民航局有如何故意拖延，或不依約為協力，亦難認自洛克希德公司提出討論，迄其完成設計說明期間，民航局有何未能依約及時完成於系爭契約應盡之義務之情形，且討論期間非等同本部分可得主張之期間，復未能舉證證明以實其說，洛克希德公司主張其得依闡明條款第4.2條第1項第4款展延完工期限，並無可取。

⒍洛克希德公司復主張民航局為更正上開TACC規格書中有限資料欄顯示條件規格曖昧不明及矛盾之處，乃委託邁特公司備置一套TACC規格書變更頁稿(Draft TACC Spec. Change Pages) ，並於1987年7月8日提供予洛克希德公司，足證有限資料欄(LDB)之原訂規格確有矛盾，且依系爭闡明條款第4.3條「變更指令」(Change Order)規定，若符合第4.2條「可宥恕之遲延(Excusable Delays)」各款不可歸責於洛克希德公司之事由時，洛克希德公司即得請求延展工期云云。然，民航局委請邁特公司備置TACC規格書變更頁稿，而修正TACC規格書第3.7.3.3.4.5.1.3節第4點規定，惟該函文之內容，僅係將兩造於TACC系統之PDR階段及CDR階段曾經達成之各項相關協議，納為TACC規格書之變更頁稿而已，並非民航局單方提出之資料。縱邁特公司於1988年1月27日就洛克希德完工計畫，做出評估報告指明民航局應變更指令，惟該時間點已距兩造解約之1988年6月25日甚近，民航局為解決系爭工程上之爭議方請邁特公司”備置”上開變更稿頁(尚非同意)，尚不得遽以該文件即認定民航局於訂約之初即有任意變更指令之意，況洛克希德公司並未舉證於該部分設計究竟花費多少人力、物力及時間？亦不得遽認兩造討論之時間即為工程延宕之時間，另，洛克希德公司主張邁特公司於1988年1月15日之評估報告亦指明顯示器韌體(display firmware)」乃系爭航管工程之要徑(critical path)。因TACC規格書內有限資料欄之規格矛盾及曖昧不明，致屬系爭航管系統要徑(critical path)之顯示器韌體(display firmware)相關設計、開發窒礙難行，並致影響「整體系爭航管工程」之2年11個工期云云。惟查，此部分業據敘明理由於前述㈤第一大項第五小項⒎⑵，故該部分應認洛克希德公司之主張應非可採。

⒎就此部分中科院鑑定認為台北區管中心基本需求規章第3.7.3.3.4.5.1.3節第4項已明確說明應涵蓋顯示雷達管制員地區轄區及高度範圍內每一Untrolled Track 之有限資料欄，此項要求並未明顯違反顯示慣例及有限資料欄使用的時機且無明顯的予盾，該部分並無模糊不明而達一般包商無法據以完成設計之程度」（見外放之中科院鑑定報告第44至45頁），而成大鑑定結論依據國際技術水準，有限資料欄為民航局自訂的規範需求，應明確提供洛克希德公司而需求規格規劃云云(第41頁)，並未斟酌本項2之說明，故洛克希德公司該部分之主張，並無足取。

⒏另中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開㈨⒎所述），就過失比例部分尚無庸參考，併予敘明。

⒐關於洛克希德公司於102年8月30日民事調查證據聲請續狀中，請求成大航太所補充說明之詢問事項，已於上開㈨⒉、⒊及後述⒋（即韌體變更部分，非屬約外要求）部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

⒑最高法院就該部分發回意旨雖指出：「關於附表一編號一之(九)「有限資料欄之使用定義不明及矛盾」部分，上訴人業於上開第一審書狀表明：伊於七十五年一月十四日致民航局之信函中，將美商（港商）洛克公司彙整民航局所有對關於雷達符號之書面及口頭意見予以精簡併列，並要求民航局以書面表明對洛克希德設計之同意（原證一四○），民航局於同年二月二十日回覆（原證一四一號），自稱：「已重寫洛克希德提出之文件，俾更正一項錯誤及澄清某些定義，其中某些原有定義相當不明，而須予以更改」（同上卷(二)五八頁）云云，原審對上訴人此項重要之攻擊方法，未予斟酌，即認上訴人此部分之主張，未舉證以實其說，更有認定事實不憑卷內所存資料暨不備理由之違法。...」，惟，民航局75年2月20號之回函（詳洛克希德公司上訴暨答辯理由⑶狀附件1-⑼-6，見本院卷1第431至436頁)乃在指正或調整洛克希德公司關於雷達符號設計資訊之定義，並有指摘洛克希德公司之設計文件有定義不明缺陷之情，再觀諸該函文之標題(詳洛克希德公司附件1-(9)-6)載明係回覆洛克希德公司LILT/JBG/2178號函（即原證140號)，而該函文(詳原證141號）即洛克希德公司附件1-(9)-6)之附件列舉共20項定義，均為糾正或調整洛克希德公司關於雷達符號設計資訊之定義，並非如洛克希德公司公司所稱民航局以該函文自認關於LDB之基本需求規章不明，併此敘明。

㈩第一大項第十小項關於洛克希德公司主張「飛機識別欄之定義不明」部分：A.洛克希德公司主張：

⒈民航局於1984年12月6日要求TACC系統完整資料欄中「飛機識別欄」格式，增加連接符號「-」之約外要求，且民航局與洛克希德公司於1984年12月20日之介面控制會議已達協議，飛機識別欄（Air craft Identificati on）第一個字元應為字母，詎民航局於1985年7月19日要求飛機識別欄第一個字元亦可為字母、數字或符號「-」，1987年7月3日要求飛機識別欄第一個字元應包括字母、數字，違反雙方1984年12月20日之協議，為屬約外要求，且TACC規格書第2.6節規定該規格書之效力優先其他本規格書所引用之所有文件，故TACC規格書之效力係優先於TACC/FISS介面控制文件；TACC規格書既已規定飛機識別欄之字元格式應為字母或數字(alphanumeric)，而不包含符號「-」，則TACC/FISS介面控制文件縱規定飛機識別欄可使用符號「-」，亦因TACC規格書效力優先而無適用餘地。

⒉TACC規格書第3.7.3.3.4.6.4.2.2節規定：「Ａ欄（即飛機識別欄）應由8個字元組成……字元位置自Ａ1到Ａ7應為飛機識別欄/呼號；字元位置Ａ8應為該航空器型別之指示」，故飛機識別欄應由7個字元組成，民航局於1985年3月20日要求變更為5個字元，應屬約外要求。

B.民航局等則以：

⒈飛機識別欄之第一字得為字母、數字或「-」等符號，為TACC規格書第2.4節、TACC/FISS界面文件第2.1節、第5.4節及國際民航組織相關文件ICAO-Doc-4444-RAC/501/10等合約文件所明訂，且關於完整資料欄(FDB)中「飛機識別欄」之格式問題，民航局於73年12月6日去函洛克希德公司，說明飛機識別欄「…在第一個符號部分，包含(contains)了英文字母；另於第一個符號之後，則應容納1至6個字母、數字(alphanumerics)及(或)『-』等特殊符號」，核屬對FDB之飛機識別欄格式與該欄第一字「包含(但不限於)英文字母」等節進行說明而已，並未提出任何約外需求。且兩造並未於73年12月20日就「飛機識別欄第一字應為英文字母」乙事達成共識，洛克希德公司就此主張為證之74年1月18日函文，為洛克希德公司單方作成，內容是否有誤解？況民航局對此於74年7月3日去函表示「飛機識別欄第一字得為數字(digit)」以為澄清，更於同年月19日再度去函重申(redirect)，可知關於「飛機識別欄第一字包含(但不限於)英文字母」與系爭契約規定一致，並無任何變更可言。

⒉洛克希德公司建置系爭航管自動化系統時，應使其與空軍之ADC系統相容，則民航局表示空軍ADC系統僅能接受5個字元數之「飛機識別欄」，「飛機識別欄應刪減7個呼號之規格為5個呼號，以配合空軍戰管中心(ADC)之系統」等語之說明，符合系爭合約之規定，並請洛克希德公司納入設計之考量，以利戰管中心之電腦處理，自不構成提出約外要求，而洛克希德公司對民航局此一說明，亦已於74年4月15日回函表示同意接受，自業經兩造確認且再次達成共識在案，不構成約外要求。況TACC規格書第3.7.3.3.4.6.4.2.1節規定，完整資料欄之A欄位所含之字母數字，最多以八個字元為限(the second line upto eight characters），是在顧及系爭航管自動化系統與ADC系統間之整合下，民航局說明完整資料欄中之飛機識別欄(即A欄位)應刪減7個呼號之規格為5個呼號，符合系爭契約之規定，並非提出約外要求等語，資為抗辯。經查:

⒈民航局指示飛機識別欄第一個字元亦可為字母、數字或符號「-」，是否為約外要求？

⑴洛克希德公司主張民航局增加連接符號「-」之約外要求，且於74年7月19日違背協議增加要求飛機識別欄第一個字元亦可為字母、數字或符號「-」，76年7月3日復要求飛機識別欄第一個字元應包括字母、數字，違反雙方73年12月20日之協議，為屬約外要求云云。

⑵惟飛機識別欄之第一字得為字母、數字或「-」等符號，為TACC規格書第2.4節、TACC/FISS界面文件第2.1節、第5.4節及國際民航組織相關文件ICAO-Doc-4444-RAC/501/10等合約文件所明訂(詳上證94號、上證95號、民航局100年11月23日上訴暨答辯理由⑼狀第16頁，見本院卷5第424至429頁、卷4第524頁背面)，而該文件附錄二關於飛機識別之資料，則舉例「EIAKO」、「4XBCD」及「N2567GA」（見本院卷16第38至39頁），其中「4XBCD」即係以數字為第一個字元，且民航局於73年12月6日要求TACC系統完整資料欄中「飛機識別欄」格式，增加連接符號「-」，並非約外要求，另參諸招標文件CAA-E-IC-004,Rev.1「飛行資訊系統介面控制文件」第5.4條已明定TACC系統應使用「Table 5-3」所示之ITA-5字型碼交換訊息，「Table 5-3」所列之ITA-5字型碼除0至9的10個數字及A到Z之英文字母外，尚包括連接符號「-」等常用符號，已如前㈤⒊所述。故民航局主張指示飛機識別欄的第一個字可以為數字，應非屬約外要求。

⑶洛克希德公司雖主張雙方於1984年12月20日之介面控制會議時已達成飛機識別欄第一個字元必為字母，接續之字元應為字母、數字或連接符號（即「-」之共識，惟民航局以洛克希德公司該項主張乃單方作成即內容有物等語抗辯。經查，洛克希德公司74年1月18日函固稱「Further,it has been agreedthatthe firmst character must bealpha(A-Z )……The foregoing information is in con- firmation of that givenverbally to CAA at a joint meeting on 20 December1984.」等語（詳洛克希德公司上訴暨答辯理由10狀附件1⑽-3，見本院卷5第203至204頁），此僅為洛克希德公司單方製作之文書，洛克希德公司復未提出1984年12月20日之會議紀錄佐證，自難逕以此認雙方已達成飛機識別欄第一個字元確定為字母之協議。又民航局1984年12月6日函固稱「the CAA's formatforthis field contains analpha character in the firstcharacter followed by one tosix characters that arealphanumeric and/or the special character"-"」（詳洛克希德公司上訴暨答辯理由10狀附件1⑽-2，見本院卷5第201至202頁），惟此係民航局於介面控制會議前表達之意見，尚難認定雙方是否確於介面控制會議中討論已達成共識，故洛克希德公司之主張，尚無足採。

⑷另洛克希德公司主張TACC規格書第2.6節規定該規格書之效力優先其他本規格書所引用之所有文件，故TACC規格書之效力係優先於TACC/FISS介面控制文件；TACC規格書既已規定飛機識別欄之字元格式應為字母或數字(alphanumeric)，而不包含符號「-」，則TACC/FISS介面控制文件縱規定飛機識別欄可使用符號「-」，亦因TACC規格書效力優先而無適用餘地云云。惟查，TACC規格書第2.4頁(即第2.6節)就相關文件之適用優先順序予以規範，係以各該文件彼此間互為抵觸為前提，若各該文件彼此間並無抵觸，或係立於補充適用之關係時，即無TACC規格書第2.6節之適用，已如前㈤⒊所述，故洛克希德公司該部分之主張自無足取。

⑸此部分經中科院鑑定認為依據台北區管中心基本需求規章有關字母數字完整資料欄之格式，已說明FDB顯示其內容由字母數字組成，故民航局於其74年7月3日函中指示飛機識別欄第一字亦可為數字乙節，非屬約外要求（見外放之中科院鑑定報告第47頁）；另成大鑑定報告亦認為文數格式之排列，應為程式設計技巧上的問題，與基本規章3.7.3.3.4.6.4.2.1節之敘述無關，國際間對於相關技巧的規範明確，且有範例可依循，合約基本規章已經做明確說明，並提供航管與戰管間的差異，技術深度與所需工時均非困難（見外放之成大鑑定報告第43至44頁）。故洛克希德公司主張此部分為約外要求，並主張其等依闡明條款第4.1條規定調整工期，應非可取。

⒉民航局於74年3月20日函要求刪減電腦訊息格式由7個字元變更為5個字元，是否為約外要求？

⑴洛克希德公司主張TACC規格書第3.7.3.3.4.6.4.2.2節規定：「Ａ欄（即飛機識別欄）應由8個字元組成……字元位置自Ａ1到Ａ7應為飛機識別欄/呼號；字元位置Ａ8應為該航空器型別之指示」，故飛機識別欄應由7個字元組成，要求變更為5個字元，應屬約外要求云云。

⑵經查，TACC規格書第3.7.3.3.4.6.4.2.1節「Format of Alphanumeric Full Block」規定「……The numeric subscript indicates the character position in the field.The firstline of alphanumeric data shall contain up to six char- acters, the second line up to eight characters....」，就完整資料欄格式所組成之字元數，第一行不超過6個（Z1-Z6），第二行不超過8個（A1-A8）之規定（見本院卷15第149頁，另見TACC規格書第3-315頁），完整資料欄之Ａ欄所含字母數字，最多既以8個為限，則不問Field A之飛機識別欄之字元為5個或7個，應均未逾TACC規格書之約定。且招標文件CAA-E-IC-001,Rev.2「航路與防空自動化系統之銜接控制文件，下稱空防介面控制文件）第1.3條規定「TACC與空軍之系統間介面之功能，應受介面之基本目標所限制：1.介面之設計，應在符合介面要求之前提下，將成本上之衝擊降至最低。2.既存之標準應在建置介面要求時，盡量援用」（見外放空防介面控制文件第1-2頁），可知洛克希德公司在建置系爭航管自動化系統時，應使其與空軍之系統相容。而空軍之ADC系統，於兩造簽訂爭航管自動化系統建置契約前，早已為運作中之系統，則民航局於74年3月20日函中表示ADC系統僅能接受5個字元數之飛機識別欄，請洛克希德公司列入設計考量，應不屬約外之要求。況洛克希德公司復於其1985年4月15日所發之函文自承同意民航局該項要求（詳洛克希德公司上訴暨答辯理由10狀附件1⑽-10，見本院卷5第223至226頁），故洛克希德公司主張該部分為約外要求，實無足取。

⑶中科院鑑定認為依合約文件TACC/ADC ICD（IDC-00 1)中規定，空軍戰管中心（ADC）與區管中心(TACC)交換資料格式時，應遵照空軍戰管中心之格式，即戰管系統為既有之系統，新系統必須與既有系統相合，此為合約Ａ規之必要條件，故民航局此一主張係合乎合約規定，故民航局要求洛克希德公司刪減7個呼號之規格為5個呼號以配合空軍戰管中心乙節，並無超出基本需求規章範圍」（見外放之中科院鑑定報告書第48頁）。故洛克希德公司主張此部分為約外要求，並主張其等依闡明條款第4.1條規定調整工期，應非可取。

⒊另中科院及成大之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，成大鑑定結論認洛克希德公司對民航局增加「-」之技術深度與所需工時均非如所陳述之困難，應做之修改與提升對本系統原合約中戰管與航管協調具效益有積極意義，洛克希德公司自己理解。本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開㈩⒈⑸及㈩⒉⑶所述），就過失比例部分尚無庸參考，併予敘明。

第一大項第十一小項關於洛克希德公司主張「單機飛航操作說明之約外要求」部分：A.洛克希德公司主張：

⒈系爭航管系統工作說明書（SOW）第5.7節規定，洛克希德公司應提供文件，以Contract Data Requirements List（契約文件清單規範，下稱「CDRL」）所規定者為限，而CDRL並未將「single-thread operation description」（洛克希德公司譯為單機飛航操作說明）列為洛克希德公司應提供之文件，民航局於1984年3月9日提出「single-thread operationdescription」（民航局譯為航管作業流程，下稱STOD）之第一版，要求洛克希德公司增列於洛克希德公司ATC-1000設計文件，為屬約外要求，且民航局自1984年3月9日至1988年6月25日先後提出7個版本，其中並包含多項約外要求，而有闡明條款第4.1條、第4.2條第1項第4、6款之適用。

⒉按單機飛航操作說明為TACC PDR待辦事項第13號，此經雙方長期、反覆討論，民航局終而承認其就TACC PDR待辦事項第13號所提出之單機飛航操作說明，係屬約外要求，並因而指示中信局於1987年1月8日提出變更指令，指示洛克希德公司為執行包括TACC PDR待辦事項第13號(按即單機飛航操作說明)及第36、51、52、61及72號之最終版本，洛克希德公司應進行必要之顯示器韌體升級。中信局並表示施作上開待辦事項，將依系爭航管契約第4.1條(按即約外要求)及4.3條(按即變更指令)，進行系爭航管契約之價格及時程之調整，是民航局/中信局業自認其於TACC PDR待辦事項第13號所提出之單機飛航操作說明，確屬約外要求。

B.民航局等則以：

⒈「航管作業流程」（STOD）係指航班起降時(departureand arrival)管制標準作業流程之概稱，明訂飛機起降之程序、時機、與塔台間交換之資訊、塔台應提供之服務或下達之指令等涉及飛航管制之程序或細節，乃系爭航管自動化系統設計時所應參酌之重要事項，倘洛克希德公司若未依航管作業流程建置系爭航管自動化系統，該系統之運作勢難符合航管作業之實況，而無法達成系爭契約將航管作業程序自動化之目的。

⒉洛克希德公司明知STOD等「航管作業流程」文件乃CDRL 010所明訂應由洛克希德公司提出，並交民航局等審核通過之文件，此觀諸洛克希德公司自行提交之1984年12月13日STOD設計文件「ATC-1000」，於首頁明文註記係以「CDRL 010」為執行依據，並於內文第6-1頁記載「…後述表格包含系爭航管自動化系統之二大操作CPCIs(按：即CDRL 010文件)，即FDP與RDP。相關操作性敘述係假設系統正常開機、啟動並運作…」等語，益徵明確，可知「民航局等提出予洛克希德公司進行設計之STOD為CDRL 010之相關文件」乙節，為洛克希德公司明知同意；且洛克希德公司僅籠統主張「民航局等變更STOD版本為本件遲延之原因」云云，惟關於版本之變更是否為因應航管實況或技術進步等需求而有必要？版本之變更與本件遲延間有無因果關係等節，未舉證以實其說。

⒊洛克希德公司就相關之STOD文件內容何以為約外要求？與本件遲延間有何關連等節，未具體主張，亦未舉證以實其說。STOD文件實係民航局等善意提供協助代洛克希德公司撰寫，民航局等甚至陸續提出最新版本供洛克希德公司參考，卻反遭誣指提出所謂約外要求等語，資為抗辯。經查：

⒈洛克希德公司主張CDRL並未將STOD列為洛克希德公司應提供之文件，而民航局於第一版，要求洛克希德公司增列ATC-1000設計文件，為屬約外要求，嗣先後更提出7個版本，包含多項約外要求，而有闡明條款第4.1條、第4.2條第1項第4、6款之適用云云。

⒉經查，STOD係指航班起降時(departure and arrival)管制標準作業流程之概稱，明確律訂飛機起降之程序、時機、與塔台間交換之資訊、塔台應提供之服務或下達之指令等涉及飛航管制之程序或細節，乃系爭航管自動化系統設計時所應參酌之重要事項，若未依STOD建置系爭航管自動化系統，該系統之運作勢難符合航管作業之實況，而無法達成系爭契約將航管作業程序自動化之目的，甚至衍生重大之飛安或外交等問題，本應有提出操作說明之義務，故尚難認為該部分之設計乃屬約外要求。

⒊又該部分雖非約外要求，然民航局73年3月9日至77年6月25日先後提出7個版本要求洛克希德公司修改，亦有違工程實務之常情，洛克希德公司若因此消耗人力物力等成本，民航局尚非不得給予補償，惟第一次（1984年3月9日）及第二次（1984年3月28日）修改之時間點相當接近，本於契約雙方合作之精神，仍在合理範圍內，自不得主張時程延宕；第三次（1984年11月16日）重新製作至1984年12月23日即交給民航局審查，第四次（1985年7月8日）洛克希德公司於1985年9月4日即發函文予民航局，表示該部分設計已逾越基本規章，第五次（1986年11月19日）於1986年12月1日旋與民航局進行討論，上開三次工作及修改期間甚短皆不滿兩個月(且尚需扣除製函文收受或送達時間等，製作時間更短)，尚難以認定洛克希德公司有何特別費用，如人員加班(抑或正常時間內完成，並無加班)等支出；且亦未舉證以實其說，第六次（1987年2月19日）雖民航局就STOD提出多處修改，惟洛克希德公司並未舉證其有何人力物力上之支出，尚不得僅以民航局要求修改STOD部分設計即遽認洛克希德公司有何特別費用支出；第七次（1987年5月21日）雖洛克希德公司於1987年12月18日函文予民航局提出修改方案，惟洛克希德公司並未舉證其有何人力物力上之支出，亦同上所述，尚不得僅以提出修改STOD設計方案即遽認洛克希德公司有何特別費用支出，或遽認兩造就該爭議之討論時間即為設計系爭航管系統之時間，洛克希德公司就該部分尚不得向民航局請求任何費用。退萬步言，前述民航局之修改時間均在1988年6月25日終止系爭航管契約之前，仍無礙前述及後述之其他可歸責洛克希德公司之各項事由，民航局自得依約對洛克希德公司終止系爭航管契約。

⒋中科院鑑定認為民航局與洛克希德公司對於「Single ThreadOperational Description」（即STOD）一詞所為翻譯，以民航局譯為「航管作業流程說明」較貼切，且該文件本質為一輔助說明，用意在於描述航管作業系統流程，俾使雙方更能確認彼此對作業流程的認知，故並非為約外要求；另洛克希德公司在73年3月7日於Magnavox公司簡報航管作業流程時，民航局認為與實際作業相差太大，於是代為撰寫此項作業流程說明。民航局進一步提出說明，認為此文件應為洛克希德公司負責提報，並交以民航局審查。依據ATC-1000設計文件（Airtrafficcontrol system description，73年12月13日）第6節之6-1頁中有顯示STOD。洛克希德公司同意列在ATC-1000設計文件，因此本項不屬約外要求（見外放之中科院鑑定報告第50至51頁）。洛克希德公司主張此部分為約外要求，並主張其等依闡明條款第4.1條規定調整工期，應非可取。另成大鑑定結果認洛克希德公司未提出本項相關證物，本項爭議民航局應可獲得洛克希德公司承諾並達成協議，亦非認約外要求。

⒌另中科院及成大之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例(即97/3、90/10)，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開⒋所述），就過失比例部分尚無庸參考，併予敘明。

⒍關於洛克希德公司於102年8月30日民事調查證據聲請續狀中，請求成大航太所補充說明之詢問事項，已於上開⒉⒊部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

⒎最高法院就該部分發回意旨雖指出：「原審就附表一編號一之(十一)「單機飛航操作說明約外要求」部分，既於判決第五十三頁謂「嗣民航局迭於七十三年十月二十九日、七十四年七月八日及七十六年二月十九日提供其最新修正之航管作業流程說明版本予上訴人參考，美商（港商）洛克公司並曾於七十三年十二月間配合修正上開ATC-1000文件（外放原證二五三號～原證二五六號）」，並經上訴人於第一審具狀提出「補充鑑定之說明」，並於其中關於(一)、11「單機飛航操作說明約外要求」部分，表明第五次單機飛航操作說明修正版（原證二五六號）民航局係於七十六年二月十九日始提出（一審卷(三)一二○～一二五頁及外放附件一），該次單機飛航操作說明修正，與七十四年八月八日系爭航管契約第四次修正，似已相隔逾一年半。果爾，則能否以「美商（港商）洛克公司在進行上開契約修正時，豈有可能未將之列入延長工期之考量」，臆認上訴人不具有系爭闡明條款第4.2條第1項第④款所定之可宥恕事由，亦值推敲。...」，惟前開⒊已說明該部份並非約外要求，而民航局多次要求洛克希德公司修改確有違工程實務之常情，然洛克希德公司並無法舉證因此有何人力物力上支出，併此敘明。

第二大項第一小項關於洛克希德公司「臺北地區管制中心最後重要設計審核遲延」部分：A.洛克希德公司主張：

⒈民航局要求洛克希德公司就電腦程式結構項目發展規格(CPCI)，提出超越新CDRL 010所明定設計文件格式、範圍之額外之說明資料。復要求除提供關於功能性需求「為何(What)」，並應說明「如何(How)」執行該等功能性需求之資訊，且要求逐行審核臺北地區管制中心最後重要設計審核(TACC CDR)中之設計文件。民航局上開要求，均屬約外要求，並嚴重延宕TACC最後重要設計審核(CDR)。

⒉民航局要求對TACC及TCC已核准之設計文件反覆審查，致民航局已核准之TACC及TCC設計文件內容，仍無法確定，導致洛克希德公司無從進行後續工程之硬、軟及韌體施作。

⒊民航局於臺北地區管制中心最後重要設計審核(CDR)進行中，提出多項基本需求規章所無之約外要求，且因基本需求規章有曖昧不明及矛盾之處，而民航局未盡其應及時澄清之義務，致臺北地區管制中心最後重要設計審核(CDR)程序延宕。甚者，多項民航局之約外要求及基本需求規章有曖昧不明及矛盾之處而待民航局澄清之爭議，於1986年9月TACC CDR結束後，仍懸而未決，影響系爭航管工程之時程。

⒋洛克希德公司依據民航局招標文件之闡明摘要(Clarifications)之新CDRL 010所明定之CPCI文件之種類、範圍、格式及內容，於1985年1月開始陸續提出TACC之設計文件予民航局審核。惟民航局突又於1985年1月29日函文，提出其自行撰寫之電腦程式功能規格(CPFS)之新格式及內容。該民航局提供之電腦程式功能規格(CPFS)新格式及內容，其內容極為繁複，遠逾新CDRL 010之格式範圍，而屬約外要求；且民航局於系爭航管契約簽訂13個月後，始提出其片面製作之電腦程式功能規格(CPFS)新格式及內容，致洛克希德公司為備具關於TACC電腦程式功能規格(CPFS)設計文件已耗費之人力、資源及時程，均付諸流水，另民航局並於其1985年5月10日函文，要求洛克希德公司須重新撰寫(rewrite)現行文件以滿足民航局提供之新(new)標準(…rewrite the "current"documentation tosatisfy the new standards)，導致TACC設計文件之撰寫時程被迫延後。

B.民航局等則以：

⒈系爭航管系統既涉及飛航管制及自動化，攸關生命、身體、健康及財產等安全至鉅，實有必要採取嚴格之標準化規範，一般商用規範之產品縱加強保固，亦無法在品質規範上達到軍規之耐用標準，故軍事規範被普遍應用於航空、飛機、通訊與軍事等領域之系統開發，是軍事規範確為洛克希德公司建置系爭航管自動化系統之實體規範，乃確保系爭航管自動化系統之安全性、穩定度與耐受度所不可或缺之重要標準，系爭契約即採用軍規MIL-STD-1521A及MIL-STD-490作為規範系統建置之實體基準，其中工作說明書第5.3節規定系統工程管理應依MIL-STD-1521A標準進行技術審核與系統，可知關於基本需求規章所訂之功能性需求，就其中具有某程度抽象性之部分，尚須依MIL-STD-490及MIL-STD-1521A等軍事規範所訂之執行方式與審核程序，進一步於PDR或CDR等階段，確定各相關功能性需求之細部需求，故該部分並非約外要求。

⒉關於民航局採行之審查方式究使何項設計文件之審核時程發生延宕？各項設計文件之審核時程發生延宕，是否係因民航局採行之審查方式所致，或係因洛克希德公司之設計文件有瑕疵或不完備所致等節，洛克希德公司迄未仍能具體主張甚至舉證證明，且要求逐行審閱並敘明功能性需求之內容與執行方法，不過在闡述實務上軟體審閱程序之常規而已，根本無涉所謂約外要求。

⒊蓋以MIL-STD-1521A就相關設計資訊(design information)之審核方式明白舉例指出，應充分且詳細地(in sufficientdetail)使買受人能自使用者之觀點，評估相關設計之妥適性，並使設計人員知悉需求「為何」(what is required)，且讓測試人員能據以準備測試證明「如何」（how）執行等語，是民航局就洛克希德公司所提設計文件之審核方式，說明「應逐行審閱TACC系統之CDR相關設計文件」與「應說明功能性需求『為何』及『如何』執行」等語，無非在闡述前揭MIL-STD-1521A相關規定之內容與實務上軟體審閱程序之常規而已，並不構成約外要求等語，資為抗辯。經查：

⒈按查軟體系統之建置，首需分析各種需求，再將相關之需求規格透過設計(Design)轉換為實際之軟體，並審核該設計是否充份且完整反應需求規格。由於軟體系統之產生均起源於相當模糊之功能性需求，因此軟體發展人員必須負責藉由系統分析(System Analysis)瞭解掌握訂購者之需求，並藉由「軟體設計」將訂購者之需求轉化為最終之軟體系統。是以軟體系統發展必有功能性需求轉換為具體設計藍圖之階段，而PDR及CDR即為軟體設計實務中確認前者是否充分且完整落實於後者之重要機制，系爭航管系統之功能性需求及採上下建置之方式建構，已如前述，合先敘明。

⒉洛克希德公司主張民航局要求就電腦程式結構項目發展規格(CPCI)，提出超越新CDRL 010所明定設計文件格式、範圍之額外之說明資料，乃屬約外要求云云。經查，系爭航管系統既涉及飛航管制及自動化，攸關生命、身體、健康及財產等安全至鉅，實有必要採取嚴格之標準化規範，系爭契約即採用軍規MIL-STD-1521A及MIL-STD-490作為規範系統建置之實體基準，其中工作說明書第5.3節規定系統工程管理應依MIL-STD-1521A標準進行技術審核與系統、設備及電腦程式之查核(詳上證14號，見本院卷1第166至167頁)；民航局對招標文件之闡明摘要，規定TACC規格書應以MIL-STD-490為程式發展之軟體文件製作標準(詳上證15號，見本院卷1第168至170頁)。由此可知，MIL-STD-1521A及MIL-STD-490均為系爭契約文件(詳外放合約文件㈠第2頁，於第6項明文例示軍規Mil-Specification為系爭契約之一部)，且該等規範內容包括系爭航管自動化系統建置之實體標準。另MIL-STD-490於第3節「需求」(Requirements)中規定：「依本規範所備置之規格，將預定使用於設計、組態項目(configuration item)、電腦程式…」(第3.1節)、「Type A：系統規格－A規乃就整體系統，規範其技術需求及任務需求……。本規格(初版)係用於建立系爭系統之一般特性(general nature)，並應據以於……系統建置或契約所訂之設計階段為進一步之定義(further defined)……」(第3.1.3.1節)(詳上證45號，見本院卷3第743至748頁)，而MIL-STD-1521A則於第5節進一步規定，就「細部需求」(Detailed Requirements)之內容，應依序於PDR或CDR等階段逐步進行審核或查核(詳上證46號，見本院卷3第749至750頁)，可知關於基本需求規章所訂之功能性需求，就其中具有某程度抽象性之部分，尚須依MIL-STD-490及MIL-STD-1521A等軍事規範所訂之執行方式與審核程序，進一步於PDR或CDR等階段，確定各相關功能性需求之細部需求。綜上可知，民航局就該部分爭議之要求，仍在功能性建置下範疇之內，尚難認為乃約外要求，洛克希德公司之主張尚無足採。

⒊洛克希德公司主張除要求提供關於功能性需求「為何(What)」，並應說明「如何(How)」執行該等功能性需求之資訊，且要求逐行審核臺北地區管制中心最後重要設計審核(TACC CDR)中之設計文件，應屬約外要求，並嚴重延宕TACC最後重要設計審核（CDR）云云。經查，MIL-STD-1521A就相關設計資訊(design information)之審核方式明白舉例指出，應充分且詳細地(insufficientdetail)使買受人能自使用者之觀點，評估相關設計之妥適性，並使設計人員知悉需求「為何」(what is required)，且讓測試人員能據以準備測試證明「如何」（how）執行等語(詳上證48號，見本院卷3第753至756頁)，是民航局就洛克希德公司所提設計文件之審核方式，說明「應逐行審閱TACC系統之CDR相關設計文件」和「應說明功能性需求『為何』及『如何』執行」等語，無非在闡述前揭MIL-STD-1521A相關規定之內容與實務上軟體審閱程序之常規而已，應非屬約外需求，且迄未仍能舉出相關因而延宕之事證，故此部分主張尚無足採。

⒋洛克希德公司主張民航局要求對TACC及TCC已核准之設計文件反覆審查，致民航局已核准之TACC及TCC設計文件內容，仍無法確定，導致洛克希德公司無從進行後續工程之硬、軟及韌體施作云云。惟，民航局反覆審查應屬落實契約目的之必要方式，且洛克希德公司迄今仍未能舉出相關因而延宕之具體事證，已如前述，故此部分主張尚無足採。

⒌洛克希德公司主張民航局於CDR進行中，提出多項基本需求規章所無之約外要求，且因基本需求規章有曖昧不明及矛盾之處，而民航局未盡其應及時澄清之義務致CDR程序延宕。甚者，多項民航局之約外要求及基本需求規章有曖昧不明及矛盾之處而待民航局澄清之爭議，於1986年9月TACC CDR結束後，仍懸而未決，影響系爭航管工程之時程云云。惟查，洛克希德公司所主張之約外要求，並無足採，已如前述及後述理由，於此不再贅述，且洛克希德公司迄今仍未能舉出相關因而延宕之具體事證，故主張尚無足採。

⒍洛克希德公司復主張其於1985年1月開始陸續提出TACC之設計文件予民航局審核。惟民航局突又於1985年1月29日函文，提出其自行撰寫之電腦程式功能規格(CPFS)之新格式及內容。屬約外要求；且民航局於系爭航管契約簽訂13個月後，始提出其片面製作之電腦程式功能規格(CPFS)新格式及內容，原已耗費之人力、資源及時程付諸流水，另於1985年5月10日函文，要求須重新撰寫(rewrite)現行文件以滿足民航局提供之新(new)標準(…rewrite the"current"documentation to satisfythe new standards)，導致TACC設計文件之撰寫時程被迫延後云云。惟，洛克希德公司並未舉證其究竟耗費多少人力、資源及時程，並不能遽以函文往返時間即屬工程延宕之時間，或另有如人員加班費等特別費用支出，況洛克希德公司已自承於其1985年8月10日之函文接受民航局之要求（詳洛克希德公司上訴暨答辯理由⑸狀附件2⑴-10，見本院卷3第89至90頁)，尚難認為該部分為約外要求，故無足採。

⒎中科院鑑定認為民航局要求電腦程式功能規格及結構項目，均在系統需求中詳細列出；而民航局所增列之部分乃為系爭系統設計過程中功能需求之詳細說明；且逐行審查設計及如何文件皆乃實務執行面，均非約外要求（見外放之中科院鑑定報告第53至54頁），成大鑑定總結係認基本規章不甚明確，洛克希德公司人員應該自行了解如何建立技術細節，民航局應協助提供必要的指導，更必須澄清各種疑問，然未盡此協力義務，致許多協商不了了之，應各負50%責任，惟此部分未審酌本院認定理由，故洛克希德公司主張此部分為約外要求，應無可取。

⒏另中科院、成大鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開⒎所述），就過失比例部分尚無庸參考，併予敘明。

⒐關於洛克希德公司於102年8月30日民事調查證據聲請續狀中，請求成大航太所補充說明之詢問事項1，已於上開⒉、⒍部分說明；詢問事項2已於上開⒌部分說明；詢問事項3已於上開⒉部分說明；詢問事項4已於上開⒊部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

⒑最高法院就該部分發回意旨雖指出：「原審就附表一編號二之(一)「台北地區管制中心最後重要設計審核遲延」部分，固以工作說明書第5.3.3節關於電腦程式設計審核部分，僅明定初期設計審核及最後重要設計審核二階段暨其審核內容，因認其未明定審核方式，但MIL-STD-1521A文件（原證二五六之一號）似為基本需求規章有關審查程序之一般性、程序性規範，系爭航管工程之審查程序及方法，即均應按MIL-STD-1521A進行，逾該MIL-STD-1521A文件所定者是否未超出基本需求規章以外之範圍，而非屬約外之要求？即有待進一步推求。...（下略）」，惟，前開⒊已說明民航局就洛克希德公司所提設計文件之審核方式，說明「應逐行審閱TACC系統之CDR相關設計文件」和「應說明功能性需求『為何』及『如何』執行」等語，無非在闡述前揭MIL-STD-1521A相關規定之內容與實務上軟體審閱程序之常規而已，並無逾上開規定，非屬約外要求，且洛克希德公司迄未仍能舉出相關因而延宕之事證。併此敘明。

第二大項第二小項關於洛克希德公司主張「顯示字元組之定義之審核遲延及約外要求」部分：A.洛克希德公司主張：

⒈洛克希德公司於投標文件中，提出、建議TACC系統、TCC系統之狀況顯示器及塔台數位顯示器之「目錄至多可容納64個符號(A repertoire of up to 64 symbols is accommodated.)」，民航局既已審閱投標文件建議之規格，並與中信局共同審定由洛克希德公司得標，則民航局確已核准洛克希德公司提出之「狀況顯示器至多僅有64個顯示字元組」之建議規格，是以，狀況顯示器之規格至多僅為64個。詎於1986年8月15日至19日之TCC初期設計審核會議中，民航局再次要求洛克希德公司將TACC及TCC之顯示字元組之數量無償增加至140個。該等要求雖已逾系爭航管契約之規定並延宕系爭航管工程，然基於合作之精神，洛克希德公司乃同意民航局前開增加至140個顯示字元組之要求。前開會議紀錄於1986年11月6日作成後，洛克希德公司於翌日旋即簽署，然民航局竟遲至1986年11月27日方簽署該等會議紀錄，民航局遲延簽署及核准會議紀錄，以確定顯示字元組數量需求。歷經長達近3年後，民航局仍未如期定義、確定顯示字元組格式及內容，為促使民航局儘速定義、確定，以避免系爭航管工程進一步延宕，洛克希德公司乃於1987年2月12日函文，告知「於民航局未有任何進一步意見之情形下，為減少對交付時程之影響，洛克希德公司建議逕行指示本公司之次承包商，依TACC系統之字元，進行塔台數位顯示器之設計，TACC系統之字元有150個」。TACC系統、TCC系統及塔台數位顯示器字元組，最終確定各為150個字元組，較諸TACC規格書及TCC規格書所規定之64個，遠多出86個。按因應該等新增加之顯示字元組，勢將增加設計、開發顯示字元產生器記憶體(the memory of display's character generators)所需之人力、成本及時間，系爭航管工程因民航局屢次提出約外要求、要求新增顯示字元組數量，致影響系爭航管工程顯示器之軟體、韌體之設計及開發、遲延簽署及核准會議紀錄等原因，導致系爭航管工程進度之遲延。

⒉復依GFE第18條第C項規定，民航局應於系爭航管契約訂立後2個月內(即1984年2月20日)，透過顯示器設計會議，討論顯示字元組格式及內容之需求，並於3個月內定義、確定顯示字元組之需求，且將該等需求提供予洛克希德公司，俾得據以進行顯示器之軟體、韌體之設計及開發。然民航局遲至1984年3月6日至9日始舉行第1次顯示器設計會議，且未遵期於1984年3月20日前定義、確定顯示字元組格式及內容之需求，可證民航局確未依GFE第18條第C項規定，於1984年3月20日前定義、確定顯示字元組格式及內容之需求，已違反其於GFE項下之義務。

B.民航局等則以：

⒈關於TACC系統與TCC系統狀況顯示器(Situation Display，下稱SD)之電腦指令表(Repertoire)之字元產生及顯示需求，TACC規格書及TCC規格書規定，SD之「符號產生設計」包括但不限於TACC規格書與TCC規格書之表格3-4所列字元組(symbolset)，且需同時預留「符號變更」與「額外符號」之空間與需求，另系爭合約文件「民航局應提供支援之項目」(GFE ToBeProvided by CAA，下稱GFE)第18條規定，SD格式之定義應在簽約後二個月由洛克希德公司及其供應商舉行會議律定，而其投標文件第二冊第2-50頁亦明定，SD之最終格式應於PDR中定案，是關於SD之具體功能與最終格式，依約本待兩造於PDR中共同確定，是民航局於PDR中就SD之功能與格式提出說明或澄清，並對於其設計為審核及指正，不問是否稱之為「細部需求」，均不屬於提出約外要求。

⒉查洛克希德公司主張顯示字元組定義之審核遲延云云，惟其並未具體主張及舉證顯示字元組之審核流程為何？時程為何？依據何在？上開主張自不可採。

⒊又洛克希德公司主張，SD之顯示字元組至多僅得容納64個符號，惟民航局竟約外要求無償增加字元組至140個，致其投入大量成本修改設計，為本件遲延之原因云云，惟以前揭規格書已明定SD應預留「符號變更」與「額外符號」之空間與需求，則民航局進行相關說明，無非就系爭航管自動化系統依TACC規格書第3.7.2.2.1.2.9.12節第2點與TCC規格書第3.7.2.2.1.2.10.12節第2點規定等之應具功能進行闡述或澄清，並非提出約外要求，更不致於因字元組之數目、形式或種類之變動或增加而導致本件遲延，何況，關於SD之顯示字元組，兩造業已合意確定為至少140個字元組，且不增加任何費用，益明SD之顯示字元組計140組非約外要求；另洛克希德公司事後為補救本件遲延，更主動提議將SD之顯示字元組由至少140組提高到可至150個字元組(上證102號)，並經民航局核准在案，可知SD之顯示字元組之變動或增加，不但為系爭航管自動化系統之應具功能，更不致於因此推遲系爭航管自動化系統之交期，而與本件遲延無相當因果關係等語，資為抗辯。經查：

⒈洛克希德公司主張民航局應於系爭航管契約訂立後2個月內（即1984年2月20日前），透過顯示器設計會議，進行關於顯示器顯示字元組格式及內容之需求之討論，並於系爭航管契約訂立後3個月內定義、確定顯示字元組格式及內容之需求，惟民航局並未如期舉行，且屢次提出要求新增顯示字元組個數之約外要求，甚至延遲簽署及核准會議記錄，影響顯示器之軟體、韌體之設計及開發，導致系爭航管工程進度之遲延云云。

⒉按兩造第4次契約變更書之附件3關於「GFE第18項」之欄位，明白記載「已收訖，顯示設計會議業於1984年3月召開完畢」等語(詳上證22號，見本院卷1第210至229頁)，可知民航局業已依GFE第18項C款規定之期程，於73年3月召開顯示設計會議共同確定SD之設計問題，尚難認為其未如期舉行第一次顯示器設計會議；且關於SD之顯示字元組部分，洛克希德公司已於1986年8月15日至19日之TCC初期設計審核會議同意確定為至少140個字元組，且不增加任何費用(詳上證101號，見本院卷5第458至459頁)，而前開會議記錄於1986年11月6日做成後，洛克希德公司於翌日旋即簽署（詳洛克希德公司上訴暨答辯理由10狀附件2⑵-9，"見本院卷5第304至310頁），故SD之顯示字元組計140組應非屬約外要求，至於SD之顯示字元組部分150字為洛克希德公司建議（詳洛克希德公司上訴暨答辯理由10狀第5頁，見本院卷5第241頁），亦難認此部分乃約外要求；另洛克希德公司主張前開會議紀錄於1986年11月6日作成後，民航局竟遲至1986年11月27日方簽署該等會議紀錄，民航局遲延簽署及核准會議紀錄，已影響系爭航管工程顯示器之軟體、韌體之設計及開發，而導致系爭航管工程進度之遲延云云。惟查，在兩造確定顯示字元組數量需求後，應認為已可立即著手進行設計，至於會議記錄之簽署，僅具有形式上之意義，簽約三個月後方簽署會議記錄，並不影響工作時程，尚難認為足以構成遲延工作之原因，故洛克希德公司之主張，尚無足取。

⒊成大鑑定報告亦認為洛克希德公司於76年11月同意接受民航局顯示字元需達140字之要求，且依據合約規定，洛克希德公司應可據此提出延長計畫時程之要求卻未提出，應可全部歸責洛克希德公司（見外放之成大鑑定報告第55頁），此部份與本院上開見解相同，故洛克希德公司主張此部份屬約外要求，尚非可採。

第二大項第三小項關於洛克希德公司主張「終端管制中心（TCC)初期設計審核(PDR)遲延」部分：A.洛克希德公司主張：

⒈TCC軟體PDR遲延開始係因：⑴由於民航局遲延臺北地區管制中心(TACC)最後重要設計審核(CDR)；⑵民航局提出五個TCCPDR審查步驟，並說明其人力不足，無法確保可以及時參與會議討論、進行文件審查等；⑶民航局甚而要求延後開始進行TCC軟體PDR，且須等到TACC軟體CDR完成後才開始進行，並要求洛克希德公司應俟民航局核准TACC CDR軟體設計文件後，始能提出TCC PDR相關軟體設計文件等，上開因素導致TCC軟體PDR遲延至1986年9月間開始(原訂於1986年1月3日開始)。

⒉民航局於TCC PDR進行中，提出多項約外要求，且未及時澄清或承認該等要求為約外要求，以變更指令(Change Orders)指示更工程，俾得及時據以執行系爭航管工程，導致TCCPDR程序延宕至1987年3月始完成(原訂於1986年3月完成)。

B.民航局等則以：

⒈洛克希德公司能力不足，欠缺有經驗且具航管專長之設計人力，光是處理TACC系統之設計工作即已無能為力，只能一再延後TCC系統之PDR時程，遲至75年10月14日，才來函邀請民航局派員參加11月初於美國平原市(PLAINFIELD,N.J.,U.S.A)舉行之TCC系統PDR會議，並陸續提交相關設計文件供審核，距系爭契約第四次修正後之預定時程，已遲延近一年之久，洛克希德公司就其遲延自屬可歸責無疑；另洛克希德公司雖主張TCC系統之PDR遲延，係因TACC系統之CDR遲延所致，而TACC系統之CDR遲延，係因民航局提出諸多約外要求所致云云，惟查洛克希德公司始終無法舉證證明民航局就TACC系統有提出任何約外要求。

⒉TCC系統之PDR已因可歸責於洛克希德公司之事由，導致TACC之CDR設計等遲延而延後進行，洛克希德公司乃於民國75年7月間主動告知民航局，擬將TCC系統之軟體設計工作更改轉由美國平原市之洛克希德電子公司(LEC)進行設計，以解決其設計人力不足之問題，造成TCC系統之PDR會議亦將於美國而非契約履行地之台灣召開，致民航局需派員遠赴美國參與審核討論，額外衍生大量之經費負擔、時間浪費與人力調度等問題，為此民航局方於75年7月31日以函說明「…在認知洛克希德公司未選擇台北，而以選擇美國平原市進行TCC系統之PDR後……我方顧慮者係有無足夠人力，以有效方式執行並出席文件提報、準備、審核與評論，及討論、評價與吸收相關之評論」等語，迺洛克希德公司竟倒果為因，曲解前開函文之意，稱民航局於該函自承無足夠人力進行TCC系統之PDR審查云云應非足取。

⒊系爭契約明訂系爭航管自動化系統之發展期程，係待TACC系統結束CDR審核後，再進行TCC系統之PDR程序，此觀諸洛克希德公司投標文件就TCC系統之發展計畫記載：「TCC操作程式之修正，多數為在TCC之PDR前即已建置完成之TACC操作程式之直接複製…」等語，益徵明確，而關於洛克希德公司提交之TACC與TCC之設計文件，民航局於PDR或CDR階段中具備核准(APPROVAL)之權限，此亦有系爭契約工作說明書第5.3.3節等規定可稽，是以TCC系統PDR階段之開啟，原則上須以TACC系統之CDR結束或經民航局核准相關CDR文件為前提等語，資為抗辯。經查：

⒈洛克希德公司主張TCC軟體PDR部分，由於民航局遲延臺北地區管制中心(TACC)最後重要設計審核(CDR)，且提出五個TCC PDR審查步驟，因人力不足要求延後開始進行TCC軟體PDR，且須等到TACC軟體CDR完成後才開始進行，並要求應俟核准TACC CDR軟體設計文件後，始能提出TCC PDR相關軟體設計文件等，導致TCC軟體PDR遲延至1986年9月間開始(原訂於1986年1月3日開始)；並於TCC PDR進行中，提出多項約外要求，導致TCC PDR程序延宕至1987年3月始完成(原訂於1986年3月完成)云云。

⒉按TCC（終端管制中心）之PDR（初期設計審核）本應俟TACC（臺北地區管制中心）之CDR（最後重要設計審核）結束，方得進行之，兩者間有次序性，合先敘明。經查，有關臺北地區管制中心(TACC)最後重要設計審核(CDR)部分，民航局並未有延遲或其他可歸責事由，已如前所述（參見前述即第二大項第一小項理由），故洛克希德公司主張其終端管制中心（TCC)初期設計審核(PDR)之遲延乃肇因於民航局遲延臺北地區管制中心(TACC)最後重要設計審核(CDR)，顯屬無據；再者，TCC系統之PDR會議並非於契約履行地之台灣召開，乃於美國舉行，若民航局派員遠赴美國參與該PDR會議，勢必造成民航局經費、人力、時間上之額外負擔，故該PDR會議延後舉行自不可歸責給民航局；況依系爭契約工作說明書第5.3.3節約定，民航局於PDR及CDR階段，對於洛克希德公司所提交TACC及TCC之設計文件，本有核准（APPROVAL）之權限（詳上證32號，見本案卷1第553至555頁），故洛克希德公司尚非得據此作為遲延之理由。綜上所述，洛克希德公司該部分主張，尚非可採。

⒊中科院鑑定認為終端管制中心(TCC)初期設計審核(PDR)之延遲，其原因係大部分可歸責於洛克希德公司文件延遲提交以及人力不足，不能全歸咎於民航局（見外放之中科院鑑定報告第55至56頁）；另成大鑑定報告亦認洛克希德公司雖主張因民航局行為所致之延遲，但所提各項資料均無法證明其於提出CDRL前曾遭受設計規格之延誤或其他延誤（見外放之成大鑑定報告第56頁），本院亦判斷該部分之遲延應可歸責於洛克希德公司，故洛克希德公司該部分之主張，應非可採。

⒋另成大及中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD、CDR會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開⒊所述），就過失比例部分尚無庸參考，併予敘明。

⒌洛克希德公司於103年5月2日民事調查證據聲請續（二）狀中，請求成大航太所補充說明之詢問事項１，關於「高層設計說明」是否應提供於民航局審核部分，已於後述⒉⒊部分說明非屬約外要求；詢問事項２已於上開⒉說明；詢問事項３中關於待辦事項52、53、54、55、56，以分別於前述、後述、（待辦事項54和55同於該部分說明之）、說明非約外要求，而待辦事項63「TCC重新分區」並非洛克希德公司所主張「四大項三十六小項」之約外要求事項，僅是洛克希德公司舉例說明該事項可能為延遲TCC PDR之事項之一，且TCC PDR之延遲並非可歸責於民航局已如前⒉所述，故本院認無再請鑑定機關補充說明之必要及實益，併予敘明。

第二大項第四小項關於洛克希德公司主張「終端管制中心（TCC）最後重要設計審核（CDR）遲延」部分：A.洛克希德公司主張：

⒈TACC CDR（即第二大項第一小項之爭點）及TCC軟體PDR（即第二大項第三小項之爭點）遲延完成，導致TCC軟體CDR遲延至1987年5月間開始(原訂於1986年6月1日開始)。

⒉民航局在TCC軟體PDR階段，所提關於TCC軟體之約外要求尚未解決，以及在TCC軟體CDR階段又提出「E欄顯示資料之優先次序」之新的約外要求，延誤TCC軟體CDR時程。

⒊民航局違反MIL-STD-1521A所定之審查方式，要求洛克希德公司除提供關於功能性需求「為何(What)」，並應說明「如何(How)」執行之資訊，且要求逐行審核－極為耗時之審查方式－TCC系統設計文件。民航局上開要求，均屬約外要求，並嚴重延宕TCC軟體CDR時程。

⒋民航局嗣後於1987年12月21日之函文中自承其所提出之要求為約外要求，惟仍拒絕履行關於從速審核洛克希德公司所為TCC軟體CDR設計文件之定作人協力義務。

⒌洛克希德公司於1988年3月15日以電話方式、同年3月31日及4月19日以函文方式屢次請求民航局儘速繼續TCC軟體CDR程序，惟民航局拒絕繼續TCC軟體CDR審查程序，終致TCC軟體CDR於1988年6月25日終止系爭航管契約時，仍無法完成。

B.民航局等則以：

⒈系爭契約經74年8月8日第四次修正後，將TCC系統之軟體CDR時程延後至75年6月1日至同年7月31日，且TCC系統之CDR應根據TCC系統之PDR結果而執行，TCC系統之PDR因可歸責於洛克希德公司之事由，遲至75年11月間才召開，早已逾越系爭契約修正後所延長之CDR開始時程，則因此所致之TCC系統CDR遲延，自屬可歸責於洛克希德公司之事由所致。

⒉民航局於76年12月21日函文，僅在說明系爭系統之發展流程，並澄清TCC之CDR遲延主因在洛克希德公司不瞭解航管系統及所提交之設計文件有不完備、不充分等瑕疵，且民航局從未提出約外需求而已，無自承提出約外要求之意思，反而益徵系爭航管自動化系統之遲延，係肇因於洛克希德公司欠缺建置系爭系統之能力，洛克希德公司自不得主張適用闡明條款第4.1條或第4.2條各款之宥恕事由。

⒊TCC系統之CDR遲延主因在於洛克希德公司欠缺建置系爭系統之專業與能力，致提交之設計文件具有諸多瑕疵，而無法通過審核所致。

⒋系爭航管自動化系統之基本需求規章並無任何曖昧不明或矛盾錯誤之問題，洛克希德公司更有義務主動、及時於後續之PDR與CDR會議中，積極掌握並落實民航局對基本需求規章之澄清及說明等語，資為抗辯。經查：

⒈洛克希德公司主張因TACC CDR及TCC軟體PDR遲延完成，導致TCC軟體CDR遲延至1987年5月間開始(原訂於1986年6月1日開始)云云。經查，TACC CDR以及TCC PDR之遲延，皆非可歸責於民航局，已如前述（詳見第二大項第一小項爭點及第二大項第三小項爭點），則TCC CDR因洛克希德公司之遲延而致延期開始，應歸責於洛克希德公司，故本項主張，實非可採。

⒉洛克希德公司復主張民航局在TCC軟體PDR階段，所提關於TCC軟體之約外要求尚未解決，在TCC軟體CDR階段又提出「E欄顯示資料之優先次序」之新的約外要求，延誤TCC軟體CDR時程云云。經查，民航局提出「E欄顯示資料之優先次序」之要求，並非約外要求，亦已如前述（詳見㈤第一大項第五小項爭點），故洛克希德公司以此作為TCC CDR延遲之理由，並非可採。

⒊洛克希德公司另主張民航局違反MIL-STD-1521A所定之審查方式，要求洛克希德公司除提供關於功能性需求「為何(What)」，並應說明「如何(How)」執行之資訊，且要求逐行審核－極為耗時之審查方式－TCC系統設計文件，民航局上開要求，均屬約外要求，並嚴重延宕TCC軟體CDR時程，況本件最高法院判決明揭「逾該MIL-STD-1521A文件所定者是否未超出基本需求規章以外之範圍，而非屬約外之要求？即有待進一步推求。」，故民航局之上述要求非屬MIL-STD-1521A附件D所規範之審查程序要求，自屬約外要求云云。經查，民航局上開之要求皆非約外要求，已如前述（詳見第二大項第一小項爭點），故洛克希德公司以此作為TCC CDR延遲之理由，亦非可採。

⒋洛克希德公司又主張民航局嗣後於1987年12月21日之函文中自承其所提出之要求為約外要求，惟仍拒絕履行關於從速審核洛克希德公司所為TCC軟體CDR設計文件之定作人協力義務云云；經查，細譯該函文內容（詳上證107號，見本院卷7第435至438頁），並無自承提出約外要求之文字，民航局亦否認該函文有自承其所提出之要求乃約外要求之意，與該函文內容，包括民航局對洛克希德公司提出能順利進行TCC系統CDR審查之條件有二，即「出賣人瞭解系爭系統之需求」與「買受人理解系爭系統之設計」(詳上證107號第2頁第1段第5至9行，見本院卷7第436頁)，及為確保相關設計文件之完備性與妥適度，民航局擬對洛克希德公司提交之設計文件進行廣泛且全面之審查(詳上證107號第3頁第1段，見本院卷7第437頁)等核無不合，再審就前開文字之文意，尚難認定民航局於該函文有自承提出約外要求之意，況洛克希德公司未提出其他證據證明民航局已自承其所提出之要求為約外要求，故洛克希德公司該項主張，實不足採。

⒌洛克希德公司主張其屢次請求民航局儘速繼續TCC軟體CDR程序，惟民航局拒絕繼續TCC軟體CDR審查程序等因素，終致TCC軟體CDR於1988年6月25日終止系爭航管契約時，仍無法完成云云。經查，依系爭航管契約，民航局本就TCC系統設計文件有核准之權限，洛克希德公司所設計之TCC系統文件無法通過民航局審核，尚難遽以認定民航局有拒絕TCC軟體CDR審查程序之意，況洛克希德公司未提出其他證據證明民航局有拒絕審查之意，故洛克希德公司該項主張，尚非足採。

⒍中科院鑑定報告認為洛克希德公司因終端管制中心(TCC)初期設計審核(PDR)之延遲，直接延誤了TCC之CDR作業，故民航局並無洛克希德公司所稱審核延遲情形（見外放之中科院鑑定報告第56至57頁）；另成大鑑定報告亦認洛克希德公司於1987年3月始要求審查TCC之CDR，所謂的「延遲」事由早已發生，對本計畫之時程已生極大影響（見外放之成大鑑定報告第57頁），皆與前述本院判斷相同，故洛克希德公司該部分之主張，應非可採。

⒎另成大及中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD、CDR會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開⒍所述），就過失比例部分尚無庸參考，併予敘明。

⒏關於洛克希德公司於102年8月30日民事調查證據聲請續狀中，請求成大航太所補充說明之詢問事項，已於上開⒊部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

第二大項第五小項關於洛克希德公司主張民航局就「資訊通訊網路設計文件之核准遲延」部分：A.洛克希德公司主張：

⒈民航局提出由洛克希德公司評估「微波頻道資料傳輸速率到達19200位元/秒之可能性」、及進行「微波頻道品質測試」之約外要求，並以不核准TCC-917設計文件要脅之，而遲延核准TCC-917設計文件。蓋依據系爭航管契約第四次修正GFE第14條第d項規定：「民航局應負責提供TACC、TCC…間之品質合格之通訊連結....要求期限：契約簽署後27個月，亦即1986年3月20日前(Quality communication links toTACC,TCC…shallbe a responsibility of CAA.…Date Required:27 MAC MAR1986)」。依此，民航局應提供品質合格之通訊連結，倘若通訊連結不合乎品質標準，則民航局即屬違反其契約義務。

⒉民航局提出「TCC-917設計文件需與尚未採購之馬公終端雷達系統相容」之約外要求，並以不核准TCC-917設計文件相脅，而遲延核准TCC-917設計文件，經雙方澄清、討論後，民航局始而承認並撤回其約外要求。為符合民航局「TCC-917設計文件需與尚未採購之馬公終端雷達系統相容」之約外要求，洛克希德公司需重新設計、修改目前已經民航局核准之設計基準文件、相關文件等，此將會導致大幅增加系爭航管工程成本及工期。洛克希德公司並要求倘若民航局仍堅持執行該約外要求，需依系爭航管契約第4.1條及第4.3條，以變更指令(ChangeOrders)指示洛克希德公司變更工程。

B.民航局等則以：

⒈按TCC規格書第3.7.5.1節規定TCC系統之資料傳輸速率，最低為2400位元/秒，最高不得超過9600位元/秒，惟洛克希德公司在TCC系統之硬體PDR會議中，卻表示TCC系統與塔台間之數據傳輸速率需達19.2KB(相當於19200位元/秒)云云，洛克希德公司此項傳輸速率，已然違反TCC規格書之明文規定。另民航局出於協助之立場，乃於75年1月9日去函說明洛克希德公司可先試用松山塔台與中正終端管制中心間已經設置之微波通道(CHANNEL)，視其可否滿足洛克希德公司所提出增加至19.2KB之需求，洛克希德公司於同年3月19日回函表示如可提供微波通道4路，則其將認為可行，民航局旋於同年5月5日表示可提供微波通道6路，並請其評估相關之可行性，惟洛克希德公司一再拖延該評估，遲至半年後即75年11月4日才進行測試，距離民航局針對洛克希德公司提出之解決建議已長達十個月之久。實則，關於可行性測試之工作極為簡單，只需由洛克希德公司提供一部數據機(MODEM)即可，此觀諸測試成功報告僅簡略記載「使用微波通路可達19.2KB/S之資訊傳輸，並無問題」等語，益徵明確。

⒉按TCC規格書第3.7.6節規定，TCC系統之雷達目標擷取器(RADAR TARGET EXTRACTOR)應符合民航局現有及規劃中之雷達，而馬公雷達在當時為規劃中之雷達，是民航局去函說明資訊通訊網路設計文件應能與馬公雷達銜接，不過重申TCC規格書第3.7.6節規定而已，並非提出任何約外要求，中科院鑑定認定在案。另民航局撤回前項說明之原因，在於決定將已納入TCC設計之嘉義雷達遷移，而該遷移並建置於馬公之既有嘉義雷達，將取代原規劃新購買之馬公雷達，因無再要求TCC系統之資通文件應與原規劃新購之馬公雷達相容之實益，乃撤回先前關此之說明，是民航局關於TCC系統資通文件之說明與撤回，實與所謂約外要求無涉，反而係減少洛克希德公司原合約應執行事項等語，資為抗辯。經查：

⒈洛克希德公司主張民航局提出由其評估「微波頻道資料傳輸速率到達19200位元/秒之可能性」，及由其進行「微波頻道品質測試」之約外要求，並以不核准TCC-917設計文件要脅洛克希德公司，而遲延核准TCC-917設計文件，造成工程進度之遲延云云。惟洛克希德公司於74年（即1985年）10月28日之硬體PDR會議中，提出TCC系統之資料傳輸速率需達19.2KBPS（即19200位元/秒）之要求（詳民航局民事上訴暨答辯理由16狀，見本院卷10第338頁），此有74年10月28日硬體PDR會議紀錄可稽（詳上證136，見本院卷10第355、356頁）。上開硬體PDR會議之召開時間，顯早於民航局於1986年1月9日及同年5月5日回覆洛克希德公司建議、評估「增加傳輸速率至19200位元/秒」之可能性之函文，可知提出「TCC系統之資料傳輸速率需達19200位元/秒」並非民航局單方要求，反係洛克希德公司先提出之要求或建議方案。再者，洛克希德公司已於1986年5月15日以函文方式，自承本於合作精神，同意使用在松山塔台及臺北終端管制中心間之微波頻道以供資料傳輸，並說明重新設計將納入4個傳輸速率為19200位元/秒之微波頻道（詳洛克希德公司上訴暨答辯理由14狀附件2⑸-5，見本院卷7第288至289頁），並以1986年11月4日函文，確認微波頻道測試結果可達19200位元/秒傳輸速率（詳洛克希德公司上訴暨答辯理由14狀附件2⑸-12，見本院卷7第315至316頁），並於1986年11月18日函文（詳洛克希德公司上訴暨答辯理由14狀附件2⑸-13，見本院卷7第317至318頁），提出TCC-917設計文件修訂版本予民航局審核，文件中有關微波頻道傳輸速率之設計為民航局所要求19200位元/秒。綜上，洛克希德公司既已基於合作精神同意民航局之要求，即不得再據前述理由主張因可歸責民航局之事由，造成系爭航管工程之遲延，故洛克希德公司該項主張，實非足採。

⒉另洛克希德公司主張民航局提出「TCC-917設計文件需與尚未採購之馬公終端雷達系統相容」之約外要求，並以不核准TCC-917設計文件相脅，而遲延核准TCC-917設計文件，經雙方澄清、討論後，民航局始終而承認並撤回其約外要求。為符合民航局「TCC-917設計文件需與尚未採購之馬公終端雷達系統相容」之約外要求，洛克希德公司需重新設計、修改目前已經民航局核准之設計基準文件、相關文件等，此將會導致大幅增加系爭航管工程成本及工期云云。經查，民航局於76年1月6日之函文表示其未來即將採購新的終端雷達系統並安置於澎湖馬公，要求洛克希德公司必須修改TCC-917設計文件，以使系爭航管系統能與未來即將採購之馬公終端雷達系統相容（詳洛克希德公司上訴暨答辯理由14狀附件2⑸-18，見本院卷7第327至328頁），洛克希德公司乃於76年7月29日以函文告知民航局強調馬公雷達抽讀器與系爭航管契約之雷達抽讀器之介面有重大差異，嗣因民航局決定將已納入TCC設計之嘉義雷達遷移(RELOCATE)至馬公，而該遷移並建置於馬公之既有嘉義雷達，將取代原規劃新購買之馬公雷達，因無再要求TCC系統之資通文件應與原規劃新購之馬公雷達相容之實益，故於76年8月31日以函文方式撤回該項要求（詳洛克希德公司上訴暨答辯理由14狀附件2⑸-22，見本院卷7第336至338頁），民航局撤回該要求與洛克希德公司之上開回覆函文之間隔期間並非甚長，尚難以認定洛克希德公司於短短數日間，即受此影響而增加系爭航管工程成本及工期，況洛克希德公司亦未提出其他證據證明系爭航管工程成本及工期受此影響，洛克希德公司尚不得以民航局未核准審查TCC-917設計文件，即遽認定民航局有威脅洛克希德公司接受約外要求之意，故洛克希德公司之該項主張，實無足採。

⒊中科院鑑定認為洛克希德公司違反系統規格在先，且民航局基於確保通信電路之可用性，應由洛克希德公司為主動執行通訊品質之測試，而洛克希德公司延宕11個月，遲至75年11月4日方進行測試，故此項目之遲延，應由洛克希德公司負大部分之責任（見外放之中科院鑑定報告第57至58頁），與本院前述判斷大致相符，故洛克希德公司該部分之主張，應非可採。另成大鑑定報告未斟酌上情而認定之，與本院調查之結果有違，非可採納。

⒋另中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD、CDR會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開⒊所述），就過失比例部分尚無庸參考，併予敘明。

第二大項第六小項關於洛克希德公司主張「系統測試計畫及程序審查之遲延」：A.洛克希德公司主張：民航局應為TACC系統測試文件之審核遲延負責。蓋因：

⒈因民航局延誤TACC CDR，導致洛克希德公司應備置TACC系統測試文件之時程亦受到相應影響。

⒉民航局於TACC系統測試文件審查中，提出、要求TACC系統測試文件(CDRL 021)應依「CDRL 020測試計畫之格式及內容標準」撰寫之約外要求。

⒊民航局遲延進行TACC系統測試文件「共同審閱(walk-through)」會議，違反其定作人及時審核文件之協力義務。

B.民航局等則以：

⒈系爭航管自動化系統之設計因可歸責於洛克希德公司之事由而嚴重遲延，影響所及，關於系統測試計畫及程序審查亦延後進行，是該遲延顯亦可歸責於洛克希德公司，洛克希德公司自不得主張就此適用闡明條款所定之宥恕事由。

⒉依系爭契約之工作說明書第5.5.1節將「電腦程式結構項目」(CPCI)及「系統整合與執行」(System integration/SystemPerformance)並列為應一併測試之子項目(5.5.1.3節、5.5.1.8節與5.5.1.9節）等情，可知「系統測試計畫及程序審查」本即包含「軟體程式測試計畫」(規範CPCI測試之CDRL020文件及「系統整合及功能測試計畫」(規範系統整合與執行測試之CDRL 021文件)等二者，並不侷限於CDRL 021文件而已，亦即系統測試計畫兼含「電腦程式結構項目CPCI」及「系統整合與執行」等二項測試項目，洛克希德公司自應依各自對應之CDRL020與CDRL 021文件進行撰寫並提交審查。

⒊洛克希德公司並未具體主張及舉證所謂「共同審閱」(walk-through)之開始要件、程序內涵與主導成員為何等節，是洛克希德公司據以籠統主張違反協力義務云云，洵屬無據。況"walk-through"係指「逐步審查」，乃在一定要件下，由軟體之作者主導召集，並進行系統驗證(verification)之程序，是民航局並無任何違反協力義務之可言，反係洛克希德公司未履行其主導召開進行walk-through審查之義務等語，資為抗辯。經查：

⒈洛克希德公司主張因民航局延誤TACC（台北地區管制中心）之CDR（最後重要設計審核），導致洛克希德公司應備置TACC系統測試文件之時程亦受到相應影響，故民航局應為TACC系統測試文件之審核遲延負責云云。惟TACC之CDR遲延非可歸責於民航局，已如前述（詳參前述第二大項第一小項爭點），故該部分洛克希德公司之主張，應非可採。

⒉洛克希德公司另主張提出予民航局審核之TACC系統測試文件係屬CDRL 021資料項目中之文件，惟民航局要求應適用「CDRL020測試計畫之格式及內容標準(Format and Content Guidefor the Preparation of CDRL 020)」，乃屬規範CDRL 020資料項目中之文件，CDRL 020資料項目為「電腦程式測試計畫及程序(Test Plan/Procedures (Computer Programs))」，與CDRL 021係屬完全不同之資料項目，且遍查招標文件，並未規定、要求屬於CDRL 021之TACC系統測試文件應依「測試計畫之格式及內容標準」(CDRL 020)撰寫，民航局提出之要求已逾越招標文件之要求而屬約外要求，且民航局遲延進行TACC系統測試文件「共同審閱(walk-through)」會議，違反其定作人及時審核文件之協力義務，故民航局應為TACC系統測試文件之審核遲延負責云云。經查，依系爭契約之工作說明書第5.5.1節將「電腦程式結構項目」(CPCI)及「系統整合與執行」(Systemintegration/System Performance)並列為應一併測試之子項目(5.5.1.3節、5.5.1.8節與5.5.1.9節，詳上證17號，見本院卷1第174至179頁)，可知「系統測試計畫及程序審查」應包含「軟體程式測試計畫」(規範CPCI測試之CDRL 020文件，詳上證19號，見本院卷1第185至186頁)及「系統整合及功能測試計畫」(規範系統整合與執行測試之CDRL 021文件，詳上證20號，"見本院卷1第187至188頁)等二者。「電腦程式結構項目」(CPCI)及「系統整合與執行」(System integration/SystemPerformance)於系爭契約之工作說明書中既約定「一併測試」，即應著重兩者於作業時之協調性，尚難認為民航局要求CDRL021之TACC系統測試文件應依「測試計畫之格式及內容標準」(CDRL 020)撰寫，已逾越招標文件之要求而屬約外要求；再者，系爭契約承攬人洛克希德公司乃屬專業公司，應有義務說明並澄清系爭工作契約中有爭議及窒礙難行之部分，雖洛克希德公司已以函文建議民航局進行「共同審閱(walk-through)」會議解決該部分爭議，惟民航局已於77年6月4日以函文方式指示於同年6月15日進行「共同審閱(walk-through)」會議（詳洛克希德公司上訴暨答辯理由⑸狀附件2⑹-13，見本院卷3第246至247頁），然洛克希德公司工作人員於前述期間在美國不克出席(見本院卷3第167頁、洛克希德公司上訴暨答辯理由⑸狀，證物見本院卷3第248-249頁)，應屬自身因素無法參與會議，尚難認為民航局違反定作人之協力義務，故洛克希德公司該部分之主張，實無足採。

⒊中科院鑑定報告認為洛克希德公司自承「未依規定按部就班先進行單元測試，以致系統有多項缺失」。因此，不能完全歸咎於民航局部分重要設計問題未解決，致使系統基本設計無法完成，計畫及程式無從擬具。故洛克希德公司就該部分應負大部分責任（見外放之中科院鑑定報告第58至59頁）；另成大鑑定報告亦認洛克希德公司人員對於許多懸而未決的項目，未曾積極盡責協調，且洛克希德公司駐台主管人員似乎沒有認知所屬人員對飛航管制系統不了解、技術能力不足所造成的影響，硬撐著不適任的組織架構進行高技術層次的技術性研發工作，導致拖延的事件一再重複演出，應負多數的責任（見外放之成大鑑定報告第58頁），與前述本院判斷大致相符，故洛克希德公司該部分之主張，應非可採。

⒋另成大與中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD、CDR會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開⒊所述），就過失比例部分尚無庸參考，併予敘明。

⒌關於洛克希德公司於102年8月30日民事調查證據聲請續狀中，請求成大航太所補充說明之詢問事項，已於上開⒉部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

⒍最高法院就該部分發回意旨雖指出：「關於附表一編號二之(六)「系統測試計畫及程序審查遲延」部分，依上訴人第一審提出之原證十六號工程發展簡圖第9號及第14號所載，與此部分爭議有關者似為CDRL 021文件（判斷此部分爭議之證據資料），而被上訴人提供予成大航太所之「鑑定說明資料128」，似為與「軟體程序測試計畫及程序」有關之該簡圖第9號CDRL020文件。原審未遑探明該二文件是否有誤以及被上訴人所提CDRL 020文件與美商（港商）洛克公司遲至七十四年十一月二十六日始提出之「系統測試計畫格式及內容指南」有無關連？逕以上訴人不能舉證證明民航局就此部分有何「未按時批准資料文件」之可宥恕事由，亦難昭折服。...」，惟上開⒉已說明「系統測試計畫及程序審查」應包含「軟體程式測試計畫」及「系統整合及功能測試計畫」等二者。「電腦程式結構項目」(CPCI)及「系統整合與執行」(System integration/System Performance)於系爭契約之工作說明書中既約定「一併測試」，即應著重兩者於作業時之協調性，尚難認為民航局要求CDRL 021之TACC系統測試文件應依「測試計畫之格式及內容標準」(CDRL 020)撰寫，已逾越招標文件之要求而屬約外要求，併此敘明。

第三大項第一小項關於洛克希德公司主張「長程雷達訊號介面定義未提供」部分：A.洛克希德公司主張：

⒈民航局違反系爭航管契約GFE第12條第a項之規定，未於1984年5月20日前提供最終之長程雷達訊息資料格式，致洛克希德公司無法及時進行TACC系統與空軍戰管中心系統間介面之計畫、設計及開發。

⒉民航局未提供最終之長程雷達訊息資料格式，已屬違約；迺其未依約記錄、取得並提供予洛克希德公司「真實」長程雷達訊息資料，反而提出由洛克希德公司自行前往中華民國空軍基地，記錄真實長程雷達訊息資料之約外要求，以確認、驗證民航局提供之長程雷達訊息資料格式係明確及特定之最終格式，以及洛克希德公司根據民航局提供之長程雷達訊息資料格式所計畫、設計及開發之軟體及介面係切實可行。

⒊系爭航管工程進度因民航局未依系爭航管契約GFE規定，提供最終之長程雷達訊息資料格式而遲延。

B.民航局等則以：

⒈關於民航局已如期提供LRR訊號之資料格式，嗣經兩造於74年8月8日第4次契約變更中確認在案，此觀諸第4次契約變更之附件3關於「GFE第12項a款」之欄位，明白記載「已收迄」(Received)等語即明，迺洛克希德公司竟臨訟主張民航局未提供LRR訊號格式，更執為遲延之口實，殊違誠信，要無可採。

⒉依GFE第12項規定，民航局僅需提供初步(版)(Preliminary)之LRR訊號格式版本予洛克希德公司進行設計即可，對此中科院鑑定亦認定：「依慣例承包商依據使用者提供初版之界面文件後，若買方無法更進一步提供較細部界面資料時，礙於合約時間壓力，應就既有文件進行設計，是洛克希德公司之主張，顯然不具系爭契約與軟體實務之依據，益徵其欠缺建置系爭航管自動化系統之能力，就本件遲延為可歸責無疑。

⒊此項爭議既為74年8月8日第4次契約變更以前所發生者，復經第4次契約變更所明文確定在案，可知洛克希德公司自得且應已將之納為延長交期之考量，而不得事後翻異主張此為適用闡明條款所定之宥恕事由，另關於民航局所提供之相關資料究有何不明確或不特定之處？是否因此致洛克希德公司無從完成介面之設計發展？與本件遲延間有何關係等節？洛克希德公司未具體主張，更未舉證以實其說。

⒋「真實長程雷達資料」之提供原則上應依GFE第13項d款第4目等規定辦理(中科院鑑定第三大項第2小項)，與GFE第12項a款之LRR介面定義提供(中科院鑑定第三大項第1小項)，二者不同，此不但業經洛克希德公司於另件訴訟(案號：本院93年度重上字第119號)自認在案，且民航局更已表示可選擇接受洛克希德公司使用模擬之雷達資料進行軟體發展及系統測試，洛克希德公司自不得以民航局未提供真實之雷達資料或所提供雷達資料之品質不佳為由，就其遲延主張適用闡明條款第4.1條或第4.2條之宥恕事由等語，資為抗辯。經查：

⒈洛克希德公司主張民航局違反系爭航管契約GFE第12條第a項之規定，而未於系爭契約訂立後5個月內（即1984年5月20日）提供「最終」之長程雷達訊息資料格式，僅於1984年1月提供長程雷達訊息初步資料格式，致洛克希德公司無法及時進行TACC系統與空軍戰管中心系統間介面之計畫、設計及開發，復令洛克希德公司自行前往中華民國空軍基地，記錄真實長程雷達訊息資料之約外要求；復未依系爭航管契約GFE規定，提供最終之長程雷達訊息資料格式而遲延云云。

⒉民航局已提供LRR訊號之資料格式，嗣經兩造於74年8月8日第4次變更契約中確認在案，此觀諸兩造第4次變更契約之附件3關於「GFE第12項a款」之欄位，明白記載「已收訖」（Received）等語即明（詳民航上證22號附件3第5頁，見本院卷1第210至229頁)，縱民航局未能依系爭航管契約GFE第12條第a項之規定於1984年5月20日前提供「最終」之長程雷達訊息資料格式，惟洛克希德公司仍得依民航局先前提供之初步格式資料進行設計（詳洛克希德公司上訴暨答辯理由19狀附件3⑴-7，見本院卷8第54至55頁），此觀諸其於1984年10月19日函文自承民航局未能提供確定之長程雷達訊息資料格式最終版本，故洛克希德公司無法於1984年11月1日提出介面控制文件，並說明洛克希德公司「別無其他選擇，僅得依據現有之資料繼續完成介面控制文件」(見本院卷10第50、51頁)等語自明；另民航局縱有遲延提交最終資料格式，而向洛克希德公司提出自行前往中華民國空軍要求提供真實長程雷達資料之情，惟屬兩造約定之事項（約內事項）並未如期完成而生之應變或處理方式，仍非屬約外之要求；且洛克希德公司亦自承本於合作精神及避免工作延宕，遂同意派遣人員自行前往中華民國空軍基地記錄真實長程雷達資料，故該部分尚難認屬約外要求；況洛克希德公司並未舉證該部分設計必須花多少時間，洛克希德公司尚非得以民航局延遲提供該資料格式之時間，即謂洛克希德公司延遲工期之時間，洛克希德公司仍須舉證其因民航局遲延提交最終資料格式而遲延工期。綜上所述，洛克希德公司該部分之主張，實難足採。另應提供真實(非模擬)長程雷達資料，為下開第三大項第二小項(即，見民航局101年4月25日15狀，本院卷10第295頁背面)之內容，詳見下述。

⒊中科院鑑定報告認為洛克希德公司所提佐證資料，並無確切說明該公司為何認為民航局所提供資料不夠明確完整，因此無從認定會導致無法如期完工等情事。依慣例承包商依據使用者提供初版之界面文件後，若業主無法更進一步提供較細部界面資料時，礙於合約時間壓力，應就既有文件進行設計（見外放之中科院鑑定報告第61頁）；另成大鑑定報告亦認洛克希德公司技術人員人力不足，且未主動完成所欠缺的資料，應負大部分責任（見外放之成大鑑定報告第64頁），與前述本院判斷大致相符，故洛克希德公司該部分之主張，應非可採。

⒋另成大與中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD、CDR會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開⒊所述），就過失比例部分尚無庸參考，併予敘明。

⒌關於洛克希德公司於103年5月2日民事調查續㈡狀中，請求成大航太所補充說明之詢問事項，已於上開⒉部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

第三大項第二小項關於洛克希德公司主張「長程雷達介面測試支援不足」部分：A.洛克希德公司主張：

⒈民航局應依系爭航管契約第四次修正之GFE、TACC規格書及測試原則之規定，於1986年2月至4月間，提供符合品質、數量(10個)之真實長程雷達資料。

⒉民航局未依系爭航管契約第四次修正之GFE、TACC規格書及測試原則之規定，提供符合品質、數量(10個)之真實長程雷達資料，反而提出由洛克希德公司使用模擬之長程雷達資料，執行介面測試之約外要求。

B.民航局等則以：

⒈系爭契約文件之投標文件第3冊第3章第1節「測試程式計畫」(Testing Program Plan)則規定，若無法取得真實之雷達資料(live radar data)，得使用模擬及錄製之雷達資料(simulated and recorded data)，可知關於LRR之測試支援，若無法取得真實之雷達資料時，兩造約定得使用模擬之雷達資料進行測試，以驗證系爭航管自動化系統關於LRR之相關功能。

⒉民航局於76年1月22日去函洛克希德公司，除表示依當時狀況洛克希德公司須使用模擬而非真實之雷達資料外，並說明民航局將接受未經真實雷達資料所充分驗證之系統等語，其後又於77年2月25日去函洛克希德公司重申，若正式測試系爭航管自動化系統而雷達資料仍未能滿足特定之執行標準時，民航局將接受經模擬資料驗證之系統等語，兩造已預見並約定真實之雷達資料或將提供，且民航局可選擇接受洛克希德公司使用模擬之雷達資料進行軟體發展及系統測試，故實不能再認為民航局有任何不依約提供資料之情事，洛克希德公司自不得以民航局未提供真實之雷達資料或所提供雷達資料之品質不佳為由，就其遲延主張適用闡明條款第4.1條或第4.2條所定各款之宥恕事由。

⒊況以模擬資料進行測試，有助於簡化測試作業，為有利於洛克希德公司之事項，蓋以與在真實環境中進行測試相較，模擬資料可某程度去除相關變數與突發事件，降低驗收不合格之風險，且模擬器係由洛克希德公司開發備置，洛克希德公司對模擬器與系爭航管自動化系統乃至於周邊系統間之配合度與整合性等問題，當更能事先掌握，故以模擬資料進行測試，實有助於完成測試驗收，對洛克希德公司至為有利，對此中科院鑑定亦認定使用模擬器來執行驗收測試的風險將比連接真正的周邊系統來得低，對洛克希德公司至為有利。是洛克希德公司主張雷達訊號質量不足致其無法進行整合測試云云，不僅不實，更有違誠信，要無可採等語，資為抗辯。經查：

⒈洛克希德公司主張民航局未依系爭航管契約第四次修正之GFE、TACC規格書及測試原則之規定，提供符合品質、數量(10個)之真實長程雷達資料，反而提出使用模擬之長程雷達資料，執行介面測試之約外要求云云。

⒉按以模擬資料進行測試，有助於簡化測試作業，與在真實環境中進行測試相較，模擬資料可某程度去除相關變數與突發事件，降低驗收不合格之風險，故以模擬資料進行測試，實有助於完成測試驗收，對洛克希德公司應較為有利。經查，民航局於民國76年1月22日去函洛克希德公司，除表示依當時狀況洛克希德公司須使用模擬而非真實之雷達資料外，並說明民航局將接受未經真實雷達資料所充分驗證之系統等語（詳上證126號，見本院卷10第319-320頁），其後又於77年2月25日去函洛克希德公司重申，若正式測試系爭航管自動化系統而雷達資料仍未能滿足特定之執行標準時，民航局將接受經模擬資料驗證之系統等語（詳上證127號，見本院卷10第321-322頁），是民航局已同意洛克希德公司可使用模擬之雷達資料取代真實之長程雷達資料進行軟體發展及系統測試，換言之，民航局欲豁免洛克希德公司提供真實長程雷達資料之測試義務，豈有不准定作人減輕或變換承攬人契約義務之理？況縱認為該豁免或變換契約義務，以模擬之雷達資料取代真實之長程雷達資料進行軟體發展及系統測試為「約外」要求，則原契約義務是否仍存在？原契約義務與變換後之契約義務兩者僅需擇一履行即可，僅以模擬方式替代或減輕原約定之測試方式，並無所謂約外之情形，故洛克希德公司該部分之主張，實無足採。

⒊中科院鑑定報告認為本件鑑定項目之焦點應著重於如何完成此項測試，民航局既然同意採用模擬雷達信號來執行測試，故洛克希德公司認為雷達訊號質不佳量不足之問題，將致使洛克希德公司無法進行整合與測試，並不合理（見外放之中科院鑑定報告第61至62頁），此與前述本院判斷大致相符，故洛克希德公司該部分之主張，應非可採。另成大鑑定報告未斟酌上情而認定之，與本院調查之結果有違，非可採納。

⒋另中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD、CDR會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開⒊所述），就過失比例部分尚無庸參考，併予敘明。

⒌關於洛克希德公司於103年5月2日民事調查續㈡狀中，請求成大航太所補充說明之詢問事項，已於上開⒊部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

第三大項第三小項關於洛克希德公司主張「飛航資訊服務系統介面定義延遲提供」部分：A.洛克希德公司主張：

⒈民航局於系爭航管工程執行中，遲延提供飛航資訊服務系統(Flight Information Service System，下稱「FISS」)之介面定義，復一再變更FISS介面定義；且因TACC規格書內有關FISS介面之規定曖昧不明，致雙方須費時反覆澄清、討論，TACC系統之軟體及韌體設計並因此而一再變更、重新施作而遲延，並進一步影響TACC系統之設計及施作。

⒉民航局招標文件之闡明摘要(Clarifications)附表3-3「訊息來源資格」明定，TACC系統應與8項系統交換訊息。民航局要求將8項系統擴增為11項系統，乃超越基本需求規章之規範，而屬約外要求。此外，附表3-3明定TACC系統與FISS系統應交換之訊息類型為24種，民航局要求新增12種訊息類型，而將附表3-3規定之24種訊息類型擴充為36種，民航局此要求係屬約外要求。

⒊民航局於其1985年10月22日函文中，指示洛克希德公司修改TACC系統及TCC系統之設計(其中涉及TACC/FISS介面設計)，以符合新版之國際民航組織文件4444-RAC/501/12(即第12版)之規定。為配合民航局該變更國際民航組織文件版本之要求，TACC/FISS系統介面須進行變更設計，以使TACC系統得與AIMS(FISS)系統交換國際民航組織文件第12版所定義之ATS訊息。民航局該要求，顯屬約外要求。洛克希德公司於接獲民航局之指示後，被迫暫停已進行之相關設計工作，積極投入國際民航組織第12版文件之研究工作，以詳細檢視、模擬應進行變更設計之範圍(包含TACC/FISS介面設計)，以及該等變更設計所需之額外費用、時間。民航局先則要求變更版本，事後雖又撤回該約外要求，然已影響系爭航管工程之設計工作，進而延宕系爭航管工程整體時程。

B.民航局等則以：

⒈依系爭契約於GFE第12項e款規定，民航局等於72年12月20日簽訂系爭契約後5個月內提供FISS之介面定義予洛克希德公司，以進行介面之設計即可(見外放合約文件㈠36頁)，而民航局等已於73年3月3日以前，將含FISS介面定義在內之GFE第12項所定文件全數交付洛克希德公司，並經洛克希德公司簽收在案，此觀民航局73年10月29日函文記載民航局等已於1984年3月3日以前遞交所有GFE第12項所定之資料，有洛克希德公司簽發之收據為憑等語即明，可知民航局等確已如期交付全數之FISS介面定義文件，並無任何遲延可言。

⒉洛克希德公司在另案(案號：本院93年度重上字第119號)並不爭執洛克希德公司已受領民航局等提出之FISS界面定義文件(，於本件卻一再爭執並未收受FISS界面定義文件，所言前後矛盾。況不論民航局等是否已提出最終之FISS界面定義，兩造既不爭執洛克希德公司已受領民航局等提出之FISS界面定義文件(按：洛克希德公司僅主張並非「最終」版本)，洛克希德公司自應就民航局等所提供之該項文件進行設計，不應動輒擱置，甚至執為本件遲延之口實，此並經中科院鑑定認定在案。

⒊按航管系統與國際航管系統有密切關連，為能與國際航管系統接軌，在國際民航組織相關文件改版時，航管系統之設計自需配合調整，方能確保航空管制之實效性與安全性，此並有中科院鑑定報告可稽。惟洛克希德公司旋於77年10月24日表示此可能增加時程與成本，民航局等為縮短系爭航管自動化系統之交付時程，遂即於74年11月11日雙方舉行之會議中，表示取消上開要求，並於同月29日再次以正式函文通知洛克希德公司，是關於系爭航管自動化系統配合改版之設計爭議，縱令曾有亦已不復存在等語，資為抗辯。經查：

⒈洛克希德公司主張民航局於系爭航管工程執行中，遲延提供「FISS」)之介面定義，復一再變更FISS介面定義；且因TACC規格書內有關FISS介面之規定曖昧不明，致雙方須費時反覆澄清、討論，TACC系統之軟體及韌體設計因此一再變更、重新施作而遲延，進一步影響TACC系統之設計及施作；且民航局要求將8項系統擴增為11項系統，超越基本需求規章之規範，另民航局要求新增12種訊息類型增列於ICD-004文件中，而將附表3-3規定之24種訊息類型擴充為36種，均屬約外要求。另民航局於其1985年10月22日函文中，指示洛克希德公司修改TACC系統及TCC系統之設計(其中涉及TACC/FISS介面設計)，以符合新版之國際民航組織文件4444-RAC/501/12(即第12版)之規定，事後又撤回該約外要求，已影響系爭航管工程之設計工作，進而延宕系爭航管工程整體時程云云。

⒉洛克希德公司於74年6月11日函覆同意民航局對於FISS介面定義之修正說明或變更（詳洛克希德公司上訴暨答辯理由5狀附件3（3）-15，見本院卷3第357頁至360），後亦於75年8月5日函文，同意將民航局75年5月8日函文中新增之要求納入ICD-004文件（詳洛克希德公司上訴暨答辯理由5狀附件3⑶-32，見本院卷3第349-1至350-1頁），尚難認為民航局前開要求為約外要求；且揆諸民航局雖於74年7月10日函文洛克希德公司仍進一步要求變更FISS介面定義並修改ICD-004文件之內容（詳洛克希德公司上訴暨答辯理由5狀附件3⑶-16，見本院卷3第361至362頁），惟洛克希德公司旋於20日內，即同年7月30日製作第2版ICD-004文件，並以函文提出予民航局審閱（詳洛克希德公司上訴暨答辯理由5狀5狀附件3⑶-17，見本院卷3第363至365頁）等情，尚難認定洛克希德公司得於該20日內進行複雜之設計，況乎耗費多少時間、成本？洛克希德公司並未舉證該部分設計必須花多少時間及成本，洛克希德公司尚非得主張以民航局延遲提供最終FISS介面定義之時間，即謂洛克希德公司延遲工期之時間，洛克希德公司仍須舉證其因民航局遲延提交最終FISS介面定義而遲延工期。另揆諸民航局雖於其74年10月22日函文中，指示洛克希德公司修改TACC系統及TCC系統之設計(其中涉及TACC/FISS介面設計)，惟洛克希德公司旋於同年10月24日即函覆告知民航局成本與時程之影響（詳洛克希德公司上訴暨答辯理由5狀附件3⑶-21，見本院卷3第382至383頁），民航局即於同年11月11、12日之審查會議表示取消上開要求（詳洛克希德公司上訴暨答辯理由5狀附件3⑶-24，見本院卷3第390至393頁），又於同年11月29日以函文通知洛克希德公司撤回上開變更設計之指示（詳洛克希德公司上訴暨答辯理由5狀附件3⑶-17，見本院卷3第363至365頁）等情，可知洛克希德公司於2日內旋即函覆民航局，尚難以認定洛克希德公司俟民航局於上開審查會以前之時間即從事並完成檢視、模擬變更設計之範圍以及TACC/FISS介面設計等工作，況民航局於20日內即表示取消要求，洛克希德公司亦須舉證因前開事實而花費多少時間、人力、費用以及因而延宕系爭航管工程整體時程；嗣後民航局雖又於75年3月5日以函文方式提出新的TACC/FISS介面定義（詳見洛克希德公司上訴暨答辯理由5狀附件3⑶-27，見本院卷3第398至399頁），惟洛克希德公司於同年4月11日函文立即提出第3版之ICD-004文件予民航局（詳洛克希德公司上訴暨答辯理由5狀附件3⑶-29，見本院卷3第342-1至344-1頁），扣除簽核、函稿送達等時間，實際從事設計時間甚短，可知該部分之設計應為契約約內事項，且洛克希德公司並未舉證因前開事實而多花費時間、人力、費用以及因而延宕系爭航管工程整體時程，尚非得以民航局延遲提供該資料格式之時間，即謂等同洛克希德公司延遲工期之時間；況洛克希德公司於75年8月5日以函文方式同意將民航局75年5月8日函文中新增之要求納入ICD-004文件，已如前述，尚不得再以此為由主張民航局遲誤提交TACC/FISS介面定義以致系爭工程進度遲延，故洛克希德公司該部分之主張，實無足採。

⒊至於本件最高法院就該部分發回意旨指出：「關於附表一編號三之㈢「飛航資訊服務系統介面定義提供遲延」部分，依民航局七十三年十月二十九日函文（民航局所提鑑定資料說明附件132）所載，其中「all the available interface dataasspecified in GFE Item 12」一語，其涵意為何，究係收到「GFE第12項a至f款之全數文件」，或僅「該項其中某些款之部分文件」，該「available」代表之意義何指？有無包括此部分文件？似有不明。原審徒以民航局上開函文逕認其於七十三年一月至三月間業將GFE第12項所約定之全部文件交付上訴人，自待詳予釐清。...」經查，民航局已於73年3月3日以前，將含FISS介面定義在內之GFE第12項所定文件全數交付洛克希德公司，並經洛克希德公司簽收在案，此觀民航局73年10月29日函文記載上訴人等已於1984年3月3日以前遞交「全部」GFE第12項所定之資料，有洛克希德公司簽發之收據可稽(「all」the available interface data as specified inGFEItem 12.Attachment A through C are copies of LILT'ssigned receipt，見外放之鑑定說明資料附件132第1頁第6行以下)。雖洛克希德公司主張民航局73年10月29日函文所載「a11 the available interface data as specified in GFEItem 12」，至多僅能認為民航局曾提出GFE第12.a項及12.b項部分文件資料，而無從證明民航局已提供GFE第12項a至f款之全數文件，惟洛克希德公司乃研發航管系統之專業廠商，基於承攬人之地位，應有向定作人（即民航局）說明、澄清之義務，民航局認為已交付系爭航管契約所約定應交付之全部文件，且洛克希德公司簽收時未附保留，即可認為已盡契約義務完成，洛克希德公司若認為該等資料有不完足之處，應本於專業技術向民航局盡說明及澄清之義務，請其再提供完整之資料，而非僅以民航局未交付GFE完整文件為由作為系爭航管工程延宕之原因，況始於本審方為爭執簽名之真正，均無足採。故洛克希德公司該部分之主張，洵屬無據，併予敘明。

⒋中科院鑑定報告認為民航局已於73年1月18日將GFE第12項e款飛航資訊服務系統介面定義提供洛克希德公司，係屬於契約規定期日前完成此項工作，此部分並無延遲交之情事。另於民航局變更要求期間，洛克希德公司所稱投入大量人力設計，無相關佐證資料認定（見外放之中科院鑑定報告第63至64頁），此與前述本院判斷大致相符，故洛克希德公司該部分之主張，應非可採。另成大鑑定報告未斟酌上情而認定之，與本院調查之結果有違，非可採納。

⒌另中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD、CDR會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開⒊所述），就過失比例部分尚無庸參考，併予敘明。

⒍關於洛克希德公司於102年8月30日民事調查證據聲請續狀中，請求成大航太所補充說明之詢問事項1、2，皆已於上開⒉部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

第三大項第四小項關於洛克希德公司主張「飛航資訊服務系統介面連接測試支援中斷及不足」部分：A.洛克希德公司主張：

⒈民航局違反系爭航管契約第四次修正GFE第13d(4)項及工作說明(SOW)規定，未於1986年2月至4月間備置一功能完整之FISS系統，致洛克希德公司無從進行系爭航管工程各階段之介面測試工作。

⒉民航局延宕至1987年6月始採購一套模擬FISS系統，惟該模擬FISS系統不能提供測試原則有關實際情況(realisticconditions)及真實飛行計畫(live flight plan)之測試環境要求，而為一有缺陷之系統。因該瑕疵之模擬FISS系統欠缺完整功能，洛克希德公司相關測試工作因而窒礙難行且需耗費大量人力、時間進行反覆測試及校正、偵錯，並導致系爭航管工程進度之遲延。

B.民航局等則以：

⒈為驗證TACC系統與FISS系統間之整合性，在TACC系統進行整合測試期間內，將以可與TACC系統進行整合測試之FISS系統，驗證洛克希德公司所建置之系爭航管自動化系統能否符合實際需求，且系爭契約於74年8月8日修正時，將TACC系統之「正式電腦程式結構項目信心測試(Formal CPCI Testing，下稱信心測試)」與「正式整合與執行測試(Formal Integration &Performance Testing，下稱整合測試)」期程，各延至76年2月至6月與同年6月至9月，而在與FISS系統進行整合測試前，需先通過信心測試，惟洛克希德公司連最基本的信心測試也無法通過，更遑論進行後續與FISS系統之整合測試，但於76年7月27日之整合測試期間內，民航局等仍提出可供驗證TACC系統而由Unitech公司發展之完全擬真FISS系統，是民航局等並無任何測試支援中斷或不足之問題，迺洛克希德公司竟為相反之主張，並藉詞遲不進行整合測試，洵屬無據。

⒉洛克希德公司就該擬真之FISS系統究有何等瑕疵？為何因此不能進行整合測試？等節，俱未舉證以實其說，民航局等否認之。實則，洛克希德公司既無法通過整合測試前階段之信心測試，即無法進行後續之整合測試，其無法完成整合測試，顯與民航局等是否提供FISS系統乙事間無相當因果關係，中科院鑑定亦認定民航局等提供之擬真FISS系統雖為過渡性系統，但係用以協助洛克希德公司進行整合測試之補救措施，洛克希德公司以該擬真FISS系統不符實需為藉口，不但欠缺佐證資料，且洛克希德公司立於賣方之立場，在買方提供擬真FISS系統進行測試時，並無異議之理由，洛克希德公司不能以「FISS系統為模擬系統」為推遲整合測試之原因等語，資為抗辯。經查：

⒈洛克希德公司主張民航局違反系爭航管契約第四次修正GFE第13d(4)項及工作說明(SOW)規定，未於1986年2月至4月間備置FISS系統，致無從進行系爭航管工程各階段之介面測試工作；且民航局延宕至1987年6月始採購一套模擬FISS系統，惟該模擬FISS系統不能提供測試原則有關實際情況及真實飛行計畫之測試環境要求，係有缺陷之系統，致洛克希德公司進行相關測試工作窒礙難行且需耗費大量人力、時間進行反覆測試及校正、偵錯，並導致系爭航管工程進度之遲延云云。

⒉按，系爭航管系統應為定作人即民航局之實際需求而進行設計，故民航局應有變更測試原則之權限，民航局既已同意洛克希德公司可使用模擬之FISS系統進行TACC系統之測試，應無不准定作人變換或減輕承攬人契約義務之理。經查，系爭航管契約第四次修正之「臺北區域管制中心測試時程表(TACC TestSchedule)」，正式整合及功能測試(Formal Integration &Performance Testing)已修正延至76年6月1日至9月1日間進行（見外放之鑑定說明資料附件144），而為驗證TACC系統與FISS系統間之整合性，在TACC系統進行整合測試期間內，將以可與TACC系統進行整合測試之FISS系統，驗證洛克希德公司所建置之系爭航管自動化系統能否符合實際需求，則民航局於76年6月間提供洛克希德公司一套模擬之FISS系統，尚難認有遲誤之情。故洛克希德公司雖主張民航局違反系爭航管契約第四次修正GFE第13d(4)項及工作說明(SOW)規定，未於75年2月至4月間備置一功能完整之FISS系統，惟非可採，已如前述，且該部分是否屬系爭航管系統之工程要徑，系爭航管系統工程是否會因民航局未於75年2月至4月間提供FISS系統而遲延進度，洛克希德公司皆未舉證以實其說。而民航局既已提供模擬之FISS系統予洛克希德公司進行TACC系統進行整合測試，洛克希德公司自得以該模擬之FISS系統進行測試，縱測試之結果與真實之情況有所出入或無法確保完整之介面功能測試，亦非可歸責於洛克希德公司，而為民航局變換或減輕洛克希德公司契約義務之結果，洛克希德公司並非得以無法確保完整之介面功能測試為由，進而遲延系爭航管工程之進度，況洛克希德公司並未具體舉證其為進行相關測試工作，耗費多少人力、時間進行測試及校正、偵錯以致遲延工作進度，故洛克希德公司之主張，應非足採。最高法院就該部分發回意旨指出：「關於附表一編號三之(四)「飛航資訊服務系統介面連接測試支援中斷及不足」部分，查七十二年二月二十日簽訂之系爭航管契約及七十四年八月八日第四次修正GFE第13項，已明訂民航局依約應提供並維持航管飛航資訊服務系統介面連接測試支援服務之期限為「簽訂契約後之26-28月／1986年2月至4月」（被上訴人提出合約文件(三)中華民國政府應提供之設備及服務清單一四頁），原審以民航局七十七年七月二十七日函文認該局於七十六年六月至九月間（合約所定測試修正時間內提出）提出飛航資訊服務系統供美商（港商）洛克公司測試，顯逾上開期限達十四月之久，原審未予深究，已有未合。且原審於此部分認定「系爭航管契約於七十四年八月八日第四次修正時，已將系統整合測試時間修正為自七十六年六月一日起至同年九月一日止」，顯將「系統整合測試時間」誤認為此項「飛航資訊服務系統介面連接測試支援服務之期限」，進而謂民航局業於合約所定之測試時間內提出飛航資訊服務系統，並有認定事實不憑卷內所存資料之違法。...」皆已於前開論述中說明，併此敘明。

⒊雖民航局稱「信心測試」（Formal Computer Program Configuration Item Testing；簡稱CPCI Testing」；即「正式電腦程式結構測試」)依測試原則第7.1.2.1.2節（第7-7頁）規定於信心測試階段，僅須以「模擬之輸入資料」(simulated inputs)驗證相關顯示功能及FISS系統輸入功能即可(詳上證69號，見本院卷4第536至544頁)，然民航局所援引之測試原則第7-7頁，係指工廠測試(in-plant test)；此與第7-8頁所規範之FISS系統介面測試(interface test，詳洛克希德公司上訴暨答辯理由⑹狀附件3⑷-5：測試原則第7.2節、第7.1.2節、第7.3節及第7.4節，見本院卷3第459至479頁)，二者截然不同，民航局所引資料有誤，應非可採；惟民航局既已同意洛克希德公司可使用模擬之FISS系統進行TACC系統之測試，若洛克希德公司以模擬之FISS系統取代真實情況進行TACC系統測試，則原契約義務仍未履行，蓋原契約義務與變換後之契約義務兩者僅需擇一履行即可，以模擬方式替代或減輕原約定之測試方式並非不可，已如前述，洛克希德公司尚非得以民航局提供模擬之FISS系統進行信心測試即屬違約，故洛克希德公司該部分之主張，實無足採。

⒋此部分中科院鑑定報告認為民航局同意以其所提供之模擬FISS系統進行測試，洛克希德公司應無意義之理由（見外放之中科院鑑定報告第64至66頁），此與前述本院判斷大致相符，故洛克希德公司該部分之主張，應非可採。另成大鑑定報告未斟酌上情而認定之，與本院調查之結果有違，非可採納。

⒌另中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD、CDR會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開⒊所述），就過失比例部分尚無庸參考，併予敘明。

第三大項第五小項關於洛克希德公司主張「民航局未提供空軍航管中心電腦介面連接之定義」部分：A.洛克希德公司主張：

⒈依系爭航管契約GFF第12條第b項規定，民航局應於簽約後即提供初步之空軍戰管中心電腦訊息資料格式(Need Preliminarydata as soon after Contract Award)，其中包括定義訊號位階規則(Message Level Protocol)；並應於契約訂立後5個月內(即1984年5月20日以前)，提供最終之空軍戰管中心電腦訊息資料格式(包括定義訊號位階規則(Message LevelProtocol)。然民航局竟未依上開規定，定義TACC系統與空軍戰管中心間電腦介面連接中之訊號位階規則(Message LevelProtocol)，反而將該等義務轉嫁予洛克希德公司。

⒉洛克希德公司依據CCITTX.25 LAP-B規則而定義訊號位階規則(按依該CCITTX.25 LAP-B規則，閒置字元(idle character)為一位元組(1 byte))，並經雙方討論、合意使用該CCITTX.25 LAP-B規則後，民航局復提出「將一位元組(1byte)之閒置字元(idle character)修改、變更為二位元(2bits)」之約外要求。

B.民航局等則以：為便利洛克希德公司設計系爭航管自動化系統，民航局於73年1月18日即提供ADC電腦訊號格式予洛克希德公司，並經洛克希德公司簽收在案，其後民航局更於同年3月3日以前將GFE第12項所定文件全數交付洛克希德公司(詳上證120號)，此亦有洛克希德公司於同年3月9日之顯示設計會議之會議紀錄可稽，是民航局已如期提供關於ADC電腦訊號格式之資料予洛克希德公司，更經兩造於74年8月8日第4次契約變更中確認在案，此可觀諸第4次契約變更之附件3關於「GFE第12項b款」之欄位，明白記載「已收迄」(Received)等語即明等語，資為抗辯。經查：

⒈洛克希德公司主張民航局依約則應提供空軍戰管中心電腦訊息資料格式(ADC computer message data formats)(即有關電腦介面連接之定義)，若缺少此格式，洛克希德公司將無法進行並完成介面之計畫、設計、及開發，然民航局竟未依系爭航管契約GFF第12條第b項規定，定義TACC系統與空軍戰管中心間電腦介面連接中之訊號位階規則(Message Level Protocol)，反而將該等義務轉嫁予洛克希德公司云云。而民航局於73年1月18日即提供ADC電腦訊號格式予洛克希德公司，並經洛克希德公司簽收在案(詳上證119號，見本院卷10第306至307頁)，其後民航局更於同年3月3日以前將GFE第12項所定文件全數交付洛克希德公司(詳上證120號，見本院卷10第308至309頁)，此亦有洛克希德公司於同年3月9日之顯示設計會議之會議紀錄可稽，是民航局已如期提供關於ADC電腦訊號格式之資料予洛克希德公司，更經兩造於74年8月8日第4次契約變更中確認在案，此可觀諸第4次契約變更之附件3關於「GFE第12項b款」之欄位，明白記載「已收迄」(Received)等語(詳上證22號附件3第5頁，見本院卷1第222頁)即明，揆諸上述等情可知縱民航局未能於契約訂立後5個月內（即73年5月20日前）提出「最終」之空軍戰管中心電腦訊息資料格式，惟定作人民航局於本院審理時既已就其認可用（available）之全部資料交付，則承攬人洛克希德公司基於其專業能力，自應就上開資料如何不足之處說明，仍應向定作人民航局要求之，況其已提出Lap-B之提議（詳如下述⒉）。最高法院發回意旨雖認為「....依民航局七十三年十月二十九日函文(民航局所提鑑定資料說明附件132)所載，其中『allthe available interface data asspecified in GFE Item12』一語，其涵意為何，究係收到『GFE第12項a至f款之全數文件』，或僅『該項其中某些款之部分文件』，該『available』代表之意義何指？有無包括此部分文件？似有不明。...（下略）」，惟承攬人洛克希德公司基於其專業能力，自應就民航局所提供之資料如何不足之處說明之，而再向民航局要求，已如前述，民航局既已就其可用（available）之全部資料交付與予洛克希德公司，尚難認為民航局未提供ADC電腦資料予洛克希德公司以致系爭工程遲延，故洛克希德公司該部分之主張，實無足採。

⒉另洛克希德公司依其專業意見提出依據CCITTX.25 LAP-B規則而定義訊號位階規則(按依該CCITTX.25 LAP-B規則，閒置字元(idle character)為一位元組(1 byte)，並經雙方討論、合意使用該CCITTX.25 LAP-B規則後，民航局嗣後方提出「將一位元組(1 byte)之閒置字元(idle character)修改、變更為二位元(2 bits)」之要求。雖雙方已就閒置字元(idle character)為一位元組(1 byte)達成合意，惟CCITTX.25 LAP-B介面規則與中華民國空軍戰管中心系統不相容，而洛克希德公司乃設計航管系統之專業公司，設計符合飛航安全之航管系統乃契約基本精神，民航局要求洛克希德公司「將一位元組(1 byte)之閒置字元(idle character)修改、變更為二位元(2 bits)」以相容於中華民國空軍戰管中心系統，亦難認為屬約外要求，否則系爭航管系統設計之初衷即喪失殆盡，故洛克希德公司該部分之主張，實無理由。

⒊本部分爭點，成大航太系及中科院皆未提出鑑定報告，故本院於該部分爭點未就鑑定報告加以論述，併予敘明。

⒋關於洛克希德公司於102年8月30日民事調查證據聲請續狀中，請求成大航太所補充說明之詢問事項，已於上開⒈、⒉部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

第三大項第六小項關於洛克希德公司主張「民航局未提供空軍戰管系統介面連接測試支援」部分：A.洛克希德公司主張：

⒈依系爭航管工程之工作說明(SOW)第4條「民航局之責任(Civil Aeronautics Administration Responsibility)」第4點及系爭航管契約1985年8月8日第四次修正中之「中華民國政府應提供之設備及服務(List of ROC Furnished Equipmentand Services，下稱「GFE」)」第13條第d⑷項規定，民航局應於1986年2月至4月間，提供空軍戰管中心系統電腦(ADCcomputer)與TACC系統等二系統間之介面連接，且應維持該介面連接，俾供洛克希德公司得以進行系爭航管工程之各階段測試工作。惟民航局要求採用之TACC系統介面與空軍戰管中心系統介面不相容，故民航局未於1986年2月至4月間備妥、提供並維持空軍戰管中心系統與TACC系統等二系統間之介面連接，違反系爭航管契約第四次修正中之GFE第13d⑷項規定，致洛克希德公司無從進行TACC系統與戰管中心系統之介面測試工作。

⒉甚且，迨至系爭航管契約於1988年6月25日終止，民航局仍未能解決上開介面之軟體不相容之狀況而未依約提供上述介面連接。洛克希德公司為避免測試工作延宕並基於合作精神，僅得採用一套模擬系統，以進行介面測試。

B.民航局等則以：

⒈兩造乃於74年6月10日簽訂「雷達訊號分離器及前置處理器(Signal Splitter/Preprocessor)」契約文件，明文規定洛克希德公司應提供雷達訊號分離器及前置處理器，以使TACC與ADC系統間具備相關資料之傳輸功能，另洛克希德公司撰寫之設計文件ICD-001第1.3.3節亦記載：「洛克希德提供之訊號轉換器及雷達訊號分離器，包括交換TACC與AACC間操作資料之精密數位電路」，可知系爭航管自動化系統與ADC系統間之連接界面，屬洛克希德公司應負責設計及建置之界面，必須在洛克希德公司先依約如期建置完成，其後方能據以進行後續之系統測試，迺洛克希德公司竟倒果為因，空言主張民航局未能提供ADC電腦界面之連接測試支援，甚至執為本件遲延之卸詞，顯無可採。

⒉按ADC於系爭航管自動化系統招標時已為運作中之系統，為避免彼此資料欠缺一致性而影響飛航管理之正確性與時效性，將衍生後續之外交困擾及飛安問題，系爭航管自動化系統在涉及ADC之介面時，應能與ADC系統相容，且能及時交換傳輸彼此之資料，故系爭介面控制文件第1.2節與TACC規格書第3.1.3.2節分別規定：「本文件定義了台北區管中心(TACC)與戰管中心(ADC，亦稱作AACC，詳中科院鑑定第85頁對照表)間及時、充分之資料傳遞所必須之軟硬體特性及操作諸元。『資料傳輸』包含自ADC傳輸長程雷達資料至TACC，及含飛行資料與航跡資料在內之操作資料交換」、「TACC系統應具備與ADC電腦介接之功能，以與ADC電腦相容(coordination)並交換飛航資料與航跡資料」。依前揭系爭介面控制文件第1.2節及TACC規格書第3.1.3.2節規定，洛克希德公司有義務解決兩系統間之相容性問題，具備該等條文所定二系統間之相容性與資料交換等功能，迺其竟倒果為因，誣指民航局無法解決兩系統間不相容之問題，致其無法完成測試，甚至執為本件遲延之口實，益徵洛克希德公司欠缺建置系爭系統之能力，就本件遲延為可歸責無疑等語，資為抗辯。經查：

⒈洛克希德公司主張民航局未於1986年2月至4月間備妥、提供並維持空軍戰管中心系統與TACC系統等二系統間之介面連接，致洛克希德公司無從進行TACC系統與戰管中心系統之介面測試工作。洛克希德公司為避免測試工作延宕並基於合作精神，僅得採用一套模擬系統，以進行介面測試云云。

⒉按系爭航管系統應為定作人即民航局之實際需求而進行設計，故民航局應有變更測試原則之權限，民航局既已同意洛克希德公司可使用模擬介面進行測試（詳上證126、127，見本院卷10第319至322頁），應無不准定作人變換或減輕承攬人契約義務之理；且洛克希德公司自承基於合作之精神並避免工程延宕，乃於1986年2月24日函文，提議由民航局採購一台IBM電腦做為模擬系統(詳洛克希德公司上訴暨答辯理由19狀附件3⑹-9，見本院卷10第228至231頁)，以進行部分介面測試，嗣後洛克希德公司於1986年4月17、18日即完成TACC系統及空軍戰管系統介面連接所需之硬體(包含Signal Splitter(分訊器)及Preprocessor(前置處理器)等)，故洛克希德公司尚非得以模擬系統僅得產生模擬資料而不能產生真實航跡(Live track)，而無法完成相容性測試(Compatibility testing)為由，主張相關介面測試遲延並延宕系爭航管工程進度，乃可歸責於民航局，洛克希德公司該部分之主張，實無理由。

⒊本部分之爭點成大航太系及中科院皆未提出鑑定報告，故本院於該部分爭點未就鑑定報告加以論述，併予敘明。

⒋關於洛克希德公司於102年8月30日民事調查證據聲請續狀中，請求成大航太所補充說明之詢問事項，已於上開⒉部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

第三大項第七小項關於洛克希德公司主張「民航局所提供GFE之設施遲延及品質不良」部分：A.洛克希德公司主張：依系爭航管契約第四次修正中之「中華民國政府應提供之設備及服務(List of ROC Furnished Equipment and Services，下稱「GFE」)」第2條至第11條之規定，民航局應於1986年11月以前提供系爭航管工程各站建築物及場地，以供洛克希德公司安裝及測試系爭航管工程之各項系統及設備，並應提供電流(AC power)、儀器接地網路(instrument grounding network)、照明設備(lighting)等硬體設施，且該等場地及硬體設施應於系爭航管工程各設備開始安裝前完成。惟民航局遲延提供該等場地及硬體設施，且其提供之場地、硬體設施品質不良，致延宕系爭航管工程之安裝及測試。

B.民航局等則以：

⒈關於該等GFE設施究竟有何遲延提供之情事？有何品質不良之情事？與本件遲延之關係？是否因此致洛克希德公司無從完成設計發展？洛克希德公司不但未具體主張，復未舉證以實其說。細繹洛克希德公司主張為證之相關函文，未有隻字片語敘及該等函文內所稱之「電力設備」，即為GFE第2(a)項所定之「電力設備」，洛克希德公司應就該等函文所稱之「電力設備」即為GFE第2(a)項之「電力設備」乙節，負舉證責任。

⒉民航局76年2月12日函文更明確表示，與「保護硬體之必要性」相關之電力設備，乃洛克希德公司之義務等語，可知該等爭議項目之電力設備，無涉所謂之安裝測試，非GFE第2(a)項所定之電力設備，迺洛克希德公司竟曲解系爭函文及GFE第2(a)項之明確文義，執為本件遲延之口實，要無可採。

⒊實則，須待TACC系統之軟體CDR結束後，方有進行後續TACC系統安裝之必要與實益，此觀諸系爭契約第4次修正之時程表，將TACC系統之自動化設備安裝期程，訂於TACC系統CDR結束後二個月內完成即可等情即明，故民航局縱使未於74年9月以前提供GFE規定中之設備，徵諸同條規定之附記，實與本件遲延間無因果關係，亦無違反GFE規定之可言等語，資為抗辯。經查：

⒈洛克希德公司主張依系爭航管契約第四次修正中GFE第2條至第11條之規定，民航局應於1986年11月以前提供系爭航管工程各站建築物及場地，以供安裝及測試各項系統及設備，並應提供電流(AC power)、儀器接地網路(instrument groundingnetwork)、照明設備(lighting)等硬體設施，惟其遲延未提供，致延宕系爭航管工程之安裝及測試云云。

⒉雖系爭契約約定民航局應於75年11月以前提供系爭航管工程各站建築物及場地，並應提供電流(AC power)、儀器接地網路(instrument grounding network)、照明設備(lighting)等硬體設施，以供洛克希德公司安裝及測試系爭航管工程之各項系統及設備，惟GFE第2(a)項又特別明文該等項目之提供時程，於自動化設備安裝前完成即可(All installations ofthe above items…must be complete before start ofautomation equipment installation，詳上證22號附件3第2頁倒數第5至3行，見本院卷1第219頁），而台北TCC系統原訂驗收測試之完工期限為76年11月30日（詳洛克希德公司上訴暨答辯理由35狀第7頁，見本院卷17第73頁），此為兩造所不爭執（詳本院102年8月9日準備程序筆錄，見本院卷19第203頁），洛克希德公司亦自承於77年3月18日方開始進行台北TCC系統雷達資料抽讀器之設備安裝（詳洛克希德公司上訴暨答辯理由21狀第4頁，見本院卷11第6頁），已超過原訂完工期限，由上述可知縱民航局已如約定時間於75年11月前內提供上述硬體設施，洛克希德公司亦無可能於原訂完工期限內完成台北TCC系統，洛克希德公司雖稱完工計畫延長時間為79年11月30日，然此尚未經核准，所稱尚無足採，故其主張民航局前開延遲預估期限云云，均無足採；另民航局之顧問邁特公司乃基於協調雙方之立場，其意見通常以婉轉之文字來和諧雙方關係，且多以說明為主，邁特公司並非基於仲裁者之立場，故不得以其意見作為有利於洛克希德公司之認定，故洛克希德公司非得以民航局遲延提供該等場地及硬體設施，及其提供之場地、硬體設施品質不良為由，主張因可歸責於民航局之事由致延宕系爭航管工程之安裝及測試，洛克希德公司該部分之主張，實無足採。

⒊本部分爭點，成大航太系及中科院皆未提出鑑定報告，故本院於該部分爭點未就鑑定報告加以論述，併予敘明。

⒋關於洛克希德公司於102年8月30日民事調查證據聲請續狀中，請求成大航太所補充說明之詢問事項，已於上開⒉部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

第四大項第一小項關於洛克希德公司主張「塔台飛航資料顯示器之分割螢幕」部分：A.洛克希德公司主張：

⒈依TCC規格書第3.7.2.6.2.4節及第3.7.2.6.2.3節之規定，塔台飛航資料顯示器(TCFDD)當中有關表格顯示(TabularDisplay)及資訊顯示(Information Display)之容量設計皆各為1欄，每欄24行、每行80字元。洛克希德公司於1986年2月28日提出TCC-9 11之結構項目發展規格(Configuration ItemDevelopment Specification)-塔台飛航資料顯示器子系統(Tower Cab Flight Data Display Subsystem)文件(下稱「TCC-911文件」)予民航局審核，民航局先於1986年5月8日函文同意洛克希德公司有關表格顯示及資訊顯示為每欄24行之設計，惟民航局遲延審核TCC-911文件。

⒉民航局於1987年1、2月間提出違反TCC規格書要求、規定之「塔台飛航資料顯示器分割螢幕」之約外要求，要求將塔台飛航資料顯示器(TCFDD)更改分為20行之資訊顯示區(Information Display area)及28行之飛航資料顯示區(FDEDisplay area，即Tabular Display表格顯示)，並進而要求將飛航資料顯示區分割為左右兩欄，左欄為每行38字元，右欄則為每行41字元，致雙方需就此費時澄清，以致影響、延宕TCC系統相關軟體、硬體及韌體之設計、開發工作，民航局自應就TCC系統之遲延負責。

B.民航局等則以：

1.關於民航局就TCFDD究竟提出如何之約外要求？與本件遲延之關係？是否因此致洛克希德公司遲延或無從完成設計發展？等節，洛克希德公司不但未具體主張，更未舉證以實其說，洛克希德公司上開主張自不可採。且關於TCFDD子系統之列表顯示器設計問題，業經76年4月27日之PDR會議確認定案，洛克希德公司自得且應據以續行TCFDD之建置，而無所謂遲至系爭契約解除前仍未確定，致無從建置TCFDD之問題。

2.基本需求規章包含工作說明書與投標文件等與建置系爭航管動化系統與有關之功能需求描述，而各該功能需求描述，則應依投標文件與工作說明書等所律定之建置理念及PDR、CDR階段，將「功能需求描述」具體化為「系統設計作為」，並在各該階段中，一一審核後者能否真正達成前者之要求，以決定是否尚須調整、修正或再確認相關之設計作為，是民航局於PDR會議中就TCFDD之顯示需求提出說明，據以指正、調整或審核洛克希德公司之設計文件是否符合基本需求規章之功能性描述，並非提出約外要求。經查：

⒈洛克希德公司主張其於1986年2月28日提出TCC-911文件予民航局審核，民航局先於1986年5月8日函文同意有關表格顯示及資訊顯示為每欄24行之設計，惟遲延審核TCC-911文件，嗣後又於1987年1、2月間提出違反TCC規格書要求、規定之「塔台飛航資料顯示器分割螢幕」之約外要求，要求將塔台飛航資料顯示器(TCFDD)更改分為20行之資訊顯示區及28行之飛航資料顯示區)，並進而要求將飛航資料顯示區分割為左右兩欄，左欄為每行38字元，右欄則為每行41字元，民航局自應就TCC系統之遲延負責云云。

⒉關於TCFDD子系統之列表顯示器(tabular display)需求，TCC規格書第3.7.2.6.2.4節第2點規定，該列表顯示器應能容納「至少」24行，每行「至少」80字元符號之顯示需求(詳上證137號，見本院卷10第370至373頁)，顯然並未具體確定，惟關於該顯示需求之具體化作業，則留待兩造於PDR中共同確定，洛克希德公司投標文件第2冊第2章第2.2.1.4節明文規定，關於TCFDD之設計與建置，應依第2.2.1.2節關於「列表及資訊顯示」(Tabular and information display)之方式進行，由兩造於PDR中共同律定顯示之細節等語(詳上證138號，見本院卷10第374至379頁)，益徵明確，則關於TCFDD子系統之列表顯示器設計問題，依上開系爭契約工作說明書及洛克希德公司「投標文件」相關規定，應留待兩造於PDR中共同確定，而兩造就此業於76年4月27日之PDR會議確認定案（詳上證140號，見本院卷10第384頁），雖系爭契約附件FORM B已就合約文件之適用明訂順序，唯若無礙系爭契約目的之達成，而有相輔相成之效，且為洛克希德公司投標時明示可達成，則各項契約文件均非不可併為適用，故洛克希德公司之投標文件本屬判斷洛克希德公司工作範圍之標準之一，已如前述（詳參㈠第一大項第一小項爭點），故在此PDR會議定案前，所有提案都有可能變動或更改，換言之，關於TCFDD子系統之列表顯示器設計問題，在該PDR會議之前，所有提案與建議皆屬事前討論或前置作業而已，尚難認為屬已確定之事項。經查，洛克希德公司稱民航局先於75年5月8日，同意洛克希德公司有關表格顯示及資訊顯示為每欄24行之設計，嗣後又於76年1、2月間提出「塔台飛航資料顯示器分割螢幕」之約外要求，要求將塔台飛航資料顯示器(TCFDD)更改分為20行之資訊顯示區(Information Displayarea)及28行之飛航資料顯示區(FDE Display area，即Tabular Display表格顯示)，並進而要求將飛航資料顯示區分割為左右兩欄，左欄為每行38字元，右欄則為每行41字元，惟民航局前述之建議或要求皆於76年4月27日之PDR會議前所提出，尚難認為民航局提出前述建議或要求為約外要求，洛克希德公司基於契約義務及其專業，本應解決定作人民航局之問題及需求，故該部分洛克希德公司之主張，顯無足採。

⒊成大鑑定報告認為洛克希德公司必須就技術專業面的需求，解決發展上的問題，顯示螢幕分割之問題出在洛克希德公司之次合約商，若因此無法滿足需求，洛克希德公司仍應負擔技術發展的責任。顯示器螢幕分割為基本合約規章所可以要求的範圍，本項不屬於約外要求，此部分應全部歸責於洛克希德公司（見外放之成大鑑定報告第72頁），此與前述本院判斷相符，故洛克希德公司該部分之主張，應非可採。另中科院就該部分之爭點未予鑑定，併予敘明。

⒋關於洛克希德公司於102年8月30日民事調查證據聲請續狀中，請求成大航太所補充說明之詢問事項，已於上開⒉部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

第四大項第二小項關於洛克希德公司主張「塔台數位顯示器之控制版」部分：A.洛克希德公司主張：塔台數位顯示器(Tower Cab DigitalDisplay；簡稱「TCDD」)係安裝於各TCC系統下之各機場控制塔台。依據TCC規格書第3.8.7.3節及TCC規格書附圖6-4等規定，機場控制塔台區域管制席位之塔台數位顯示器為1個、且係安裝在可於地面移動之操縱台，該操縱台得因應跑道方向之變換而移動其位置。民航局於1983年系爭航管契約簽訂前所舉行之澄清會議中，亦確認塔台數位顯示器為1個、且係安裝在可於地面移動之操縱台。迺民航局竟於系爭航管工程執行中，提出洛克希德公司應於中正機場塔台免費提供「具有雙顯示器之塔台數位顯示器(dual display-heads)」、及包括控制板在內之2套塔台數位顯示器之輸入設備之約外要求，嗣復又變更該等約外要求，要求塔台數位顯示器應安裝於塔台天花板滑輪軌道。因民航局提出之該等約外要求，致洛克希德公司必須費時與民航局討論、予以澄清，並進而導致洛克希德公司與其次承包商Magnavox公司於該爭議未獲一致結論前，無法執行或繼續塔台數位顯示器之相關軟體、硬體、及韌體之設計、開發工作，致系爭航管工程時程遲延。

B.民航局等則以：洛克希德公司所提供之產品，均不符合前揭規格，蓋以洛克希德公司所提供之影像管內徑僅60英吋，且TCDD之遠端控制台(Remote Control Panel)不具備"center"與"decenter"之選擇鍵，在重量上更無法達到低於75磅之要求)，為此洛克希德公司乃於75年8月19日之會議中提議變更設計，可知關於TCC系統之TCDD規格變更問題，乃源於洛克希德公司無法履行TCC規格書之需求，而由洛克希德公司提出變更設計之要求，其後洛克希德公司又遲延提出變更設計提案之相關文件，致TCDD之硬體變更設計懸而未決並延宕多時，迺洛克希德公司竟臨訟杜撰民航局提出TCDD之約外要求等語資為抗辯。經查：

⒈洛克希德公司主張依據TCC規格書第3.8.7.3節及TCC規格書附圖6-4等規定，機場控制塔台區域管制席位之塔台數位顯示器為1個、且係安裝在可於地面移動之操縱台。迺民航局竟於系爭航管工程執行中，提出洛克希德公司應於中正機場塔台免費提供「具有雙顯示器之塔台數位顯示器、及包括控制板在內之2套塔台數位顯示器之輸入設備之約外要求，嗣復變更要求塔台數位顯示器應安裝於塔台天花板滑輪軌道等約外要求云云。

⒉雙方於75年8月19日同意變更設計（詳本院101年6月8日準備程序筆錄第3頁，見本院卷12第29頁，另詳上證142號第2頁第2行，見本院卷10第390頁），嗣後民航局又於77年1月28日函文簽署76年11月18日會議紀錄（詳洛克希德公司上訴暨答辯理由(21)狀附件4(2)-37，見本院卷11第366至367頁)，確認塔台數位顯示器之設計係採用於天花板架設滑輪軌道(Trolley)系統之方案，換言之，洛克希德公司既已同意民航局之變更設計要求，尚難認為屬約外要求，則該會議前之變更設計或免費設計等要求應認為屬事前討論而已；另關於TCC系統之TCDD規格，TCC規格書第3.7.2.6.1節規定，TCDD之影像管內徑至少需達135英吋(第3.7.2.6.1.1節第2點)，其重量不得超過75磅(第3.7.2.6.1.2節第3點)，且在控制板上需具備"center"與"decenter"之選擇鍵(第3.7.2.6.1.13節第1點)(詳上證141號，見本院卷10第385至388頁)，惟洛克希德公司所提供之產品，均不符合前揭規格，蓋以洛克希德公司所提供之影像管內徑僅60英吋，且TCDD之遠端控制台(Remote Control Panel)不具備"center"與"decenter"之選擇鍵，在重量上更無法達到低於75磅之要求(詳上證142號，見本院卷10第389至391頁)，而洛克希德公司至76年5月間方補提相關資料供核(詳上證144號，見本院卷10第394頁)，故數位顯示器方案於76年11月18日方確認完畢，距76年5月雖約有6個月時間，惟洛克希德公司並未舉證該部分設計必須花多少時間，洛克希德公司尚非得以該部分需與民航局費時討論、澄清之時間，即謂係洛克希德公司延遲工期之時間，洛克希德公司仍須舉證其因與民航局費時討論、澄清格式及補件而實際施作為要徑之遲延工期，故此部分主張，應非足採。

⒊成大鑑定報告認為本項控制板之變更係洛克希德公司無法滿足各項規格細節所致，民航局同意其變更，並接受部分交換條件。控制板之變更出自於規格不符所衍生的問題，附件資料明確顯示雙方之協商及結論。本項顯示器控制板之變更屬於履行合約之範圍，應不屬於約外要求（見外放之成大鑑定報告第73頁），故洛克希德公司該部分之主張，應非可採。另中科院就該部分之爭點未予鑑定，併予敘明。

⒋關於洛克希德公司於102年8月30日民事調查證據聲請續狀中，請求成大航太所補充說明之詢問事項，已於上開⒉部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

第四大項第三小項關於洛克希德公司主張「狀況顯示器之迷你一覽表(Mini Menu)」部分：A.洛克希德公司主張：

⒈TACC規格書及TCC規格書均未規定、要求狀況顯示器(Situation Display)應配置迷你一覽表(Mini Menu)。洛克希德公司之次承包商Magnavox公司雖曾於系爭航管契約簽訂前，建議民航局可額外選購並裝置迷你一覽表(Mini Menu)於狀況顯示器上，惟嗣民航局與洛克希德公司於系爭航管契約簽訂時，並未就該迷你一覽表達成任何協議，因之，迷你一覽表並未列入民航局對於招標文件之闡明摘要(CAA Summary ofClarifications to the RFP Documents；以下簡稱「Clarifications」)、基本需求規章或其他契約文件，而非屬系爭航管契約或基本需求規章所規定、要求之約內功能。

⒉民航局於系爭航管契約簽訂後之1986年8月14日要求洛克希德公司於狀況顯示器增加迷你一覽表，自屬約外要求。洛克希德公司雖基於「合作精神」而同意於狀況顯示器增加迷你一覽表，並進行相關之硬體、韌體及軟體之設計研發工作。惟民航局於1987年5月至7月間之TACC CDR待辦事項解決會議(TACCCDR Resolution Meeting)期間，先則表示迷你一覽表係屬約內要求並要求擴充迷你一覽表(Mini Menu)之內容，經雙方反覆討論、澄清，民航局始於1987年7月14日之TACC CDR待辦事項解決會議，自承該迷你一覽表非基本需求規章所規定、要求，屬約外要求，然卻於同日會議反而指示洛克希德公司「勿於」狀況顯示器增加迷你一覽表，致洛克希德公司原依民航局1986年8月14日指示，「新增」迷你一覽表之相關設計須因而放棄，且須因應「移除」該迷你一覽表，而重新進行大幅度之變更、修正狀況顯示器相關硬體、韌體及軟體之設計，造成額外成本、人力及時間之支出、並延宕系爭航管工程。

B.民航局等則以：

⒈關於「SD螢幕應具備一『表列區域』之功能」，雙方於簽約前之72年9月29日第7次技術澄清會議中，要求洛克希德公司提供SD之相關資料，並列為待辦事項第50項，其後洛克希德公司於同年11月7日就SD相關問題提出說明，表示在顯示器之螢幕上，將存在某一可顯示快速鍵(QAK)之表列區域(list area)，並說明將以觸控螢幕之方式(the touch on main screen)取代追蹤球(trackball)進行操作，可知關於SD應具備一「表列區域」之功能，於簽約前已經兩造確認並達成共識在案；嗣後於簽約後再次於73年3月8日召開顯示器設計會議，達成共識在案，而為兩造共同理解認知屬系爭航管自動化系統之應有功能無誤。

⒉洛克希德公司在遞交韌體需求規格書ATC-914時，未將「(迷你)一覽表」之功能置於設計文件中，為此民航局等乃要求洛克希德公司應於設計文件之相關章節中敘明，並於75年8月14日再次去函重申SD應具備一覽表之功能，不過在闡述基本需求規章及系爭契約之內容，並提醒洛克希德公司注意以納入設計文件而已，根本無涉所謂約外要求，且中科院鑑定亦認定SD之迷你一覽表之功能業經兩造協議為系爭航管自動化系統之應具功能，並非約外要求資為抗辯。經查：

⒈洛克希德公司主張TACC規格書及TCC規格書均未規定、要求狀況顯示器應配置迷你一覽表，故嗣於簽約後要求增加迷你一覽表，自屬約外要求。民航局始於1987年7月14日之TACC CDR待辦事項解決會議，自承該迷你一覽表非基本需求規章所規定、要求，屬約外要求，惟又指示勿增加迷你一覽表，致原依民航局日指示新增迷你一覽表之相關設計須因而放棄，且須因應移除該迷你一覽表，並重新進行大幅度之變更、修正狀況顯示器相關硬體、韌體及軟體之設計，延宕系爭航管工程云云。

⒉就「SD螢幕應具備一『表列區域』之功能」，於簽約前之72年9月29日第7次技術澄清會議中，民航局要求洛克希德公司提供SD之相關資料，並列為待辦事項第50項，其後洛克希德公司於同年11月7日就SD相關問題提出說明，表示在顯示器之螢幕上，將存在某一可顯示快速鍵(QAK)之表列區域，並說明將以觸控螢幕之方式取代追蹤球進行操作，可知關於SD應具備一「表列區域」之功能，於簽約前已經兩造確認並達成共識在案；嗣後於簽約後再次於73年3月8日召開顯示器設計會議，達成共識在案，而為兩造共同理解認知屬系爭航管自動化系統之應有功能無誤；況洛克希德公司自承「基於合作精神」，依民航局1986年8月14日之指示，於1986年12月3日函覆民航局將迷你一覽表(Mini Menu)增加於狀況顯示器之設計（詳洛克希德公司上訴暨答辯理由(6)狀附件4(3)-8，見本院卷3第553至554頁），既洛克希德公司同意該項民航局要求，則民航局嗣後於1987年7月14日之TACC CDR待辦事項解決會議指示洛克希德公司勿於狀況顯示器增加迷你一覽表，僅為將原來約內施作之設計放棄(見本院卷3第571-572頁)，應無不可之理；雖洛克希德公司主張民航局於1986年8月14日函文係指示要求洛克希德公司云云，惟此為民航局否認，且觀諸函文僅記載「我們瞭解Magnavox可提供該迷你一覽表...」，並無指示要求之記載(見本院卷3第552、566頁)，雖自洛克希德公司1986年12月3日函覆民航局，至民航局於1987年7月14日之TACC CDR待辦事項解決會議放棄該項設計約有8個月，惟洛克希德公司自稱基於合作精神施作，自不得主張花費時間、費用等，況洛克希德公司並未舉證該部分設計必須花多少時間，尚非得以前開8個月之時間，即謂洛克希德公司延宕工期之時間，亦非得空言耗費額外成本、人力及時間之支出，洛克希德公司仍須舉證因上開事由而延宕工期及耗費額外成本、人力及時間之支出，故該部分洛克希德公司之主張，應非足採。

⒊中科院鑑定認為本工程案簽約協議書中，經雙方同意之協議，係為合約之一部分，故本項功能確實未超出基本需求規章範圍，故狀況顯示器附加迷你一覽表係經雙方協議同意，非約外要求（見外放之中科院鑑定報告第67至68頁），故洛克希德公司該部分之主張，應非可取。另成大鑑定報告未就系爭契約相關各項文件，包括投標文件、PRD會議記錄等資料為綜合判斷，與本院認定不同，故不予採納，併予敘明。

⒋另中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開⒊所述），就過失比例部分尚無庸參考，併予敘明。

⒌最高法院就該部分發回意旨雖指出：「關於附表一編號四之(三)「狀況顯示器之迷你一覽表」部分，原審以兩造於七十二年九月二十九日簽訂系爭航管契約前之第七次澄清會議，曾對狀況顯示器顯示事項澄清，及於七十三年三月八日顯示器設計會議，討論狀況顯示器之觸控功能，並提及以表列方式提供一覽表之功能項目，然何以認定美商（港商）洛克公司於簽訂系爭航管契約前，已知悉民航局就狀況顯示器設置迷你一覽表部分有所需求，並認締約雙方已就此一需求達成協議，顯未說明其所憑以判定之依據。究竟該二會議僅係互為「討論」，或已達「協議」？亦待澄清。...（下略）」，惟前開⒉已說明洛克希德公司自承「基於合作精神」，而依民航局1986年8月14日之指示，於1986年12月3日函覆民航局將迷你一覽表增加於狀況顯示器之設計，自屬達成協議，併此敘明。

第四大項第四小項關於洛克希德公司主張「擴充訊號表之約外要求」部分：A.洛克希德公司主張：

⒈民航局招標文件之闡明摘要(CAA Summary ofClarifications to the RFP Documents)之附表3-3「訊號來源資格(Message Source Eligibility)」(下稱「附表3-3」)係將TACC規格書中關於「訊號來源資格(Message SourceEligibility)」之規定予以修訂，以明定TACC系統應與8項系統連接，以交換70種訊號類型。民航局於系爭航管工程執行中，一再要求擴增附表3-3，以使TACC系統連接額外新增之系統及交換額外新增之訊號類型，致TACC系統該附表3-3原訂之8項系統擴增為15項系統，附表3-3原訂之70種訊號類型擴增為222種。

⒉嗣於中信局1987年1月8日變更指令中，乃明示本鑑定項目所涉待辦事項第51號應適用系爭闡明條款第4.1條(約外要求)之規定。由於民航局一再提出擴增附表3-3之約外要求，致雙方需費時澄清、協商，TACC系統之軟體及韌體設計亦因而一再變更而遲延，系爭航管工程並因此延宕。

B.民航局等則以：

⒈系爭航管自動化系統之訊號表應得容納約170個訊號類型，為TACC規格書第3.7.3.2.10.6節與TCC規格書第3.7.3.2.8.5節所明定，民航局從未提出「訊號表擴充」之要求，但洛克希德公司能力不足，無法妥善處理TACC之系統控制、管理維修、離線研發支援作業及其與TCC、FISS、ADC等系統間之資訊傳遞功能，竟衍生高達307個訊號類型，遠逾基本需求規章所定之數目，造成系統極端複雜而不易操作，迺洛克希德公司竟倒果為因，臨訟指摘民航局提出所謂「訊號表擴充」之約外要求，與事實不符，林清一報告亦認定，民航局並未要求擴充訊號表，洛克希德公司所提之307個訊號表，乃洛克希德公司自行發展需求所增加者。

⒉民航局雖於73年8月21日之PDR會議中提出手繪之TACC規格書附表3-3，但僅供作為會議中討論之用，此觀諸該日之會議紀錄記載：「附件E至附件J係由CAA提出供交換意見用。預定將就該等附件作進一步討論」等語即明，而同年10月29日之函文所載之「TACC規格書附表3-3業經放寬(extended)」等語，則僅在說明前揭本在供討論用之附件F內容，與原TACC規格書附表3-3有所不同而已，無自承提出約外要求之意思，更無要求據以納入設計之意思。

⒊民航局73年10月29日函文本文記載：「附件係民航局就洛克希德公司關於PDR待辦事項第26項之回應」等語即明，亦即73年10月29日函文，係在回應並評論「洛克希德公司自行擴充PDR待辦事項第26項所示之訊號類型」等節，並非民航局要求擴充TACC規格書之附表3-3。

⒋另「使用中跑道」為TACC規格書第3.7.3.2.1.46節與TCC規格書第3.7.3.3.4.3.4.3節所定之功能性需求，故關於「使用中跑道」之顯示訊號類型，並不屬於約外要求，至為顯然；抑有進者，關於「使用中跑道」(Runway in use)之TXT、ACK及NAK等12種訊號類型，經列為AI 51，洛克希德公司旋於1985年7月2日發函表示：「洛克希德很榮幸能告知民航局...此對未來契約所預定之交期並無任何影響」，可知不論AI51是否為約外要求，洛克希德公司已自承AI51對系爭航管自動化系統之交貨日期並無任何影響，與本件遲延間並無任何因果關係，至為明確。經查：

⒈洛克希德公司主張民航局招標文件之闡明摘要附表3-3係將TACC規格書中關於訊號來源資格規定予以修訂，以明定TACC系統應與8項系統連接，以交換70種訊號類型。惟民航局一再要求擴增，致附表3-3原訂之70種訊號類型擴增為222種。嗣於中信局1987年1月8日變更指令中，乃明示應適用系爭闡明條款第4.1條(約外要求)之規定且致工程延宕云云。

⒉對此民航局否認有要求擴充訊號類型，其雖於73年8月21日之PDR會議中提出手繪之TACC規格書附表3-3（詳洛克希德公司上訴暨答辯理由(21)狀附件4(4)-3，見本院卷11第409至416頁），並於同年10月29日函文表示要求進一步擴張附表3-3，惟變更附表之內容，不等同變更指令，僅是將TACC規格書之內容及規格明確化等討論而已，俾利依此後續之工程，就此而言尚難屬約外要求；洛克希德公司復自承本於合作精神及為使工程順利進行，基於雙方歷次會議討論結果，於74年4月2日函文提交ICD-1000設計文件附錄D訊號表予民航局審核（詳洛克希德公司上訴暨答辯理由16狀附件4(4）-6，見本院卷11第431至444頁），該ICD-1000文件附錄D訊號表係依據民航局之指示，將附表3-3原訂之8項系統擴增為15項系統(按即新增7項訊號來源)，並將附表3-3原訂之70種訊號類型擴增為168種(按即新增98種訊號類型)，則該部分經洛克希德公司同意，自難認屬約外要求。

⒊洛克希德公司雖主張依民航局歷次會議或函文要求，於76年2月16日提出ICD -001介面控制文件正式基線版本(BaselineIssue)之附件D訊號表予民航局審核，將附表3-3原訂之70種訊號類型擴增為222種(按即新增152種訊號類型)，另將TACC規格書附表3-3原訂之8項系統擴增為15項系統(按即新增7項訊號來源)，惟民航局否認之，而前開ICD -001介面控制文件正式基線版本(Baseline Issue)之附件D訊號表乃洛克希德公司自行提出予民航局，且揆諸洛克希德公司所提之上訴及答辯理由（21）狀附件4(4)-7、4(4)-10、4(4)-14內容，即洛克希德公司單方於74年5月20日、75年4月10日及76年2月16日提出之ICD-001介面控制文件正式基線版本(Baseline Issue)之附件D訊號表，皆未能證實係民航局欲變更內容之意（見本院卷11第445頁、464頁及483頁），洛克希德公司並未舉證以實其說。另洛克希德公司雖主張中信局乃提出1987年1月8日變更指令，指示為執行包括待辦事項第13、36、51、52、61及72號之最終版本，洛克希德公司應進行必要之顯示器韌體升級，惟韌體與本部分爭點無涉，實無討論之必要，故洛克希德公司該部分主張均無足採。

⒋洛克希德公司復主張民航局提出關於「使用中跑道」(Runwayin use)之顯示訊號類型，如TXT、ACK及NAK等12種訊號類型(經列為PDR待辦事項第51項，下稱AI51)，構成約外需求，而為本件遲延之原因云云。經查，「使用中跑道」為TACC規格書第3.7.3.2.1.46節與TCC規格書第3.7.3.3.4.3.4.3節所定之功能性需求(詳民航局100年1月19日㈠狀第22至24頁、100年5月12日㈤狀第8至13頁及100年11月23日㈨狀第16至18頁，各見本院卷1第93頁背面至94頁背面、卷2第368頁背面至371頁、卷4第524頁背面至525頁背面)，故關於「使用中跑道」之顯示訊號類型，並不屬於約外需求；況關於「使用中跑道」(Runwayin use)之TXT、ACK及NAK等12種訊號類型，經列為AI51，洛克希德公司旋於1985年7月2日發函表示：「洛克希德很榮幸能告知民航局...此對未來契約所預定之交期並無任何影響」(詳原證177號，另見本院卷23第479頁)，可知洛克希德公司已自承AI 51對系爭航管自動化系統之交貨日期並無任何影響，亦未請求任何費用，與本件遲延間並無任何因果關係，至為明確，故該部分洛克希德公司之主張實無足採。

⒌成大鑑定報告認為該部分之307個訊號表係由洛克希德公司自行發展需求所增加的，民航局並未提出要求，兩造對訊號表之擴充均無相關佐證資料，故本項應不屬於約外要求，該部分之責任應可歸責於洛克希德公司（見外放之成大鑑定報告第75頁），此與本院之見解相符，故洛克希德公司該部分之主張，應非可採。另中科院就該部分之爭點未予鑑定，併予敘明。

⒍關於洛克希德公司於102年8月30日民事調查證據聲請續狀中，請求成大航太所補充說明之詢問事項，已於上開⒉、⒊、⒋部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

第四大項第五小項關於洛克希德公司主張「代辦之工作項目對於電腦作業程式之影響」部分：A.洛克希德公司主張：

⒈依系爭航管契約「中華民國政府應提供之設備及服務(Listof ROC Furnished Equipment and Services，下稱「GFE」)」第18條規定，民航局應於1984年3月20日前提出顯示器格式定義(display formats to be delivered to LILTby CAA)，惟民航局遲誤該1984年3月20日期限而未提出。該等顯示器格式定義遂於TACC PDR期間(即1984年7、8月間)列為TACCPDR待辦事項第13、36、51、52、61及72號，而責由民航局儘速於TACC PDR會議後提出。

⒉民航局雖於1984年10月至1985年7月間，就上述各待辦事項提出相關之顯示器格式定義，惟民航局所提出之顯示器格式定義之文件(按即上述TACC PDR待辦事項第13、36、51、52、61及72號)中，包含大量逾越基本需求規章之約外要求，致洛克希德公司被迫與民航局進行多次、長期之反覆澄清及討論。嗣後，民航局終而指示中信局於1987年1月8日提出變更指令，表明就該等TACC PDR待辦事項第13、36、51、52、61及72號等約外要求，將依系爭闡明條款第4.1條(民航局要求額外的設備、服務；按即約外要求)辦理契約修正，足見TACC PDR待辦事項第13、36、51、52、61及72號確屬約外要求。因民航局該等諸多約外要求，致與顯示器相關之作業電腦程式亦須配合變更、修改。相關作業電腦程式變更及修改設計非僅耗費洛克希德公司大量人力、資源，且影響、延宕系爭航管系統之設計及開發。

B.民航局等則以：

⒈系爭合約文件GFE第18條亦規定，狀況顯示器格式之定義，應在簽約後二個月由民航局、洛克希德公司及其供應商舉行會議律定，而洛克希德公司之投標文件第二冊第2-50頁更明定，顯示器之最終格式應於PDR中定案，是關於狀況顯示器之具體功能與最終格式，依約本待兩造於PDR會議中共同確定，此更經中科院鑑定認定在案。

⒉蓋以狀況顯示器之具體功能與最終格式，依約本待兩造於PDR會議中確定，且兩造亦已如期確定顯示器，而經兩造於74年8月8日第4次契約變更中確認在案，此觀諸第4次契約變更之附件3關於「GFE第18項」之欄位，明白記載「已收訖，顯示器會議業已結束」(Received，Display ConferenceCompleted)等語即明，可知兩造合意確認並解決顯示器會議是否如期召開之爭議，洛克希德公司自不得事後再為翻異，甚至主張就此適用闡明條款所定之宥恕事由。

⒊TACC PDR待辦事項(Action Item)第13、36、51、52、61及72號皆非約外要求與變更設計，其中第13號已於爭點1-1、第36號已於爭點1-3、第51號已於爭點1-6、第61號已於爭點1-8討論過，不再贅述；第52號即為後述4-6爭點，亦非為約外要求，詳如後述；第72號即為本項爭點，洛克希德公司就74年6月11日函文之內容何以構成約外要求、原本合約之內容為何、與本件遲延間之關連等節，俱未具體主張並舉證以實其說，民航局前揭函文僅在檢送兩造關於待辦事項第72號之相關討論意見而已，並非提出約外要求等語，資為抗辯。經查：

⒈洛克希德公司主張依系爭航管契約GFE第18條規定，民航局應於1984年3月20日前提出顯示器格式定義，惟遲誤該1984年3月20日期限而未提出。民航局雖於1984年10月至1985年7月間，就上述各待辦事項提出相關之顯示器格式定義，惟所提出之顯示器格式定義之文件(即TACC PDR待辦事項第13、36、51、52、61及72號)中，包含大量逾越基本需求規章之約外要求，致洛克希德公司被迫與民航局進行多次、長期之反覆澄清及討論，致顯示器相關之作業電腦程式亦須配合變更、修改。影響、延宕系爭航管系統之設計及開發云云。

⒉按系爭航管自動化系統應採由上而下之建置方式，在PDR與CDR中，洛克希德公司應將民航局對系爭航管自動化系統之需求轉換為具體可行之設計藍圖，是關於狀況顯示器列表之基本需求規章縱具抽象性，亦為正常狀況，非需求曖昧不明，且民航局所為具體說明亦不致構成約外要求，另於後續之PDR與CDR會議中，洛克希德公司更有義務主動積極掌握落實民航局之澄清說明，系爭航管契約GFE表第18項約定：「民航局應於簽約兩個月（即民國73年2月）後，提供狀況顯示器格式定義，由民航局、洛克希德公司及顯示器承包商召開顯示器會議，並由民航局定義顯示器格式，再轉交給洛克希德公司」，且洛克希德公司之投標文件第二冊第2-50頁亦明定顯示器之最終格式應於PDR中定案(詳上證83號，見本院卷4第614-1至615頁)，是關於狀況顯示器之具體功能與最終格式，依系爭契約本待兩造於PDR會議中共同確定甚明。經查，洛克希德公司於73年3月6日至9日第1次顯示器設計會議、同年5月3日至5日第2次顯示器設計會議及同年7、8月TACC PDR期間皆未向民航局表示其提出之需求為約外要求，而於同年12月17日方去函民航局表示系爭航管契約為一固定價格之契約，民航局於各待辦事項所提出基本需求規章所未規定、要求之眾多約外要求，將影響系爭航管工程之施工費用及時程，可知兩造仍就顯示器格式定義處於討論階段，尚難遽認民航局有提出約外要求之意，且兩造亦已如期確定顯示器，而經兩造於74年8月8日第4次契約變更中確認在案，此觀諸第4次契約變更之附件3關於「GFE第18項」之欄位，明白記載「已收訖，顯示器會議業已結束」(Received，Display Conference Completed)等語即明(詳上證22號倒數第2頁，見本院卷1第228頁)，可知兩造合意確認並解決顯示器會議是否如期召開之爭議，洛克希德公司自不得事後再為翻異。另洛克希德公司主張PDR待辦事項第13號之「單機飛航操作說明」（詳洛克希德公司100年5月6日上訴暨答辯理由㈣狀附件--第一大項第十一小項：單機飛航操作說明之約外要求，見本院卷第19至53頁）為民航局所新增之約外要求，惟該部分經本院認定非屬約外要求，已如前所述（詳參第一大項第十一小項爭點），併此敘明。

⒊雖洛克希德公司復主張系爭航管契約附件B (Attachment toForm B, Contract Documents)明定，第2順位文件之GFE之適用順序優先於第8順位之美商洛克希德公司之投標文件(LECProposal)。GFE第18條既明訂民航局應於簽約後3個月內(即1984年3月20日前)提出顯示器格式定義，民航局遲延提出，自構成違約，民航局援引順位在後之洛克希德公司投標文件(LECProposal)置辯，應不可取云云。經查，雖系爭契約附件FORMB已就合約文件之適用明訂順序，唯若無礙系爭契約目的之達成，而有相輔相成之效，且為洛克希德公司投標時明示可達成，則各項契約文件均非不可併為適用；且依系爭契約附件FORMB之規定，洛克希德公司應遵守包括投標文件在內之一切契約文件，而負責就載有本件系統功能性需求之契約文件(包含但不限於上訴人之招標文件(RFP)、洛克希德公司投標文件、相關軍事規範、兩造所舉行歷次技術澄清會議之書面會議紀錄、闡明摘要及洛克希德公司就自己投標文件所為之闡明等文件)，進行相關之分析作業，以建置系爭航管自動化系統，故洛克希德公司之投標文件本屬判斷洛克希德公司工作範圍之標準之一，已如前㈠所述（詳參第一大項第一小項爭點），故洛克希德公司該部分之主張，實無足採。

⒋中科院鑑定報告認為顯示器格式提供之責任及時間，並非由民航局單方面提出，且合約規定之時間，為開始召開會議的時間，並非結束時間。因此洛克希德公司指控民航局強要求其提出顯示器格式資料，應為不當（見外放之中科院鑑定報告第68至69頁），此與前述本院判斷大致相符，故洛克希德公司該部分之主張，應非可採。另成大鑑定報告未斟酌上情而認定之，與本院調查之結果有違，非可採納，併此敘明。

⒌另中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD、CDR會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開⒋所述），就過失比例部分尚無庸參考，併予敘明。

第四大項第六小項關於洛克希德公司主張「台北區域管制中心計畫控制顯示器之歸航資料」部分：A.洛克希德公司主張：

⒈民航局於其1985年5月21日函文中，就TACC PDR待辦事項第51、52號提出約外要求，要求將上開顯示內容擴張並區分為獨立的4個警報區域(Alert Area)及1個要求區域(Requested Area)，且於各警報區域(Alert Area)及要求區域(Requested Area)中新增大量上述規格書所未要求、規定之顯示內容，此等要求已逾越TACC規格書，屬約外要求。

⒉經雙方為此約外要求費時討論、釐清，中信局始於1987年1月8日提出變更指令，表明就施作該等TACC PDR待辦事項第51、52號之約外要求，將依系爭闡明條款第4.1條(民航局要求額外的設備、服務；按即約外要求)辦理契約工期及價格修正、調整。因上開顯示器之約外要求，洛克希德公司耗費大量人力、時間，修改、變更顯示器相關之韌體及軟體、而延宕系爭航管系統之設計及開發。

B.民航局等則以：

⒈按系爭航管自動化系統應採由上而下之建置方式，在PDR與CDR中，洛克希德公司應將民航局對系爭航管自動化系統之需求轉換為具體可行之設計藍圖，是關於狀況顯示器列表之基本需求規章縱具抽象性，亦為正常狀況，非需求曖昧不明，且民航局所為具體說明亦不致構成約外要求，另於後續之PDR與CDR會議中，洛克希德公司更有義務主動積極掌握落實民航局之澄清說明，而非一味主張基本需求規章之規定不明致其無法及時進行軟體設計，或籠統主張民航局之澄清說明構成所謂之約外要求。

⒉TACC規格書第3.7.2節規定，計畫管制席(Planningcontroller position)應具備「飛航列表顯示子系統」(Flight tabular display subsystem)，該子系統並包含「管制中資訊列表顯示器」(In-sector Tabular Display)及「進管資訊列表顯示器」(Inbound Tabular Display)，而應能顯示各種天氣資訊與飛航資訊。其次，洛克希德公司投標文件第2冊第2.2.1.2節就資訊列表顯示器更進一步規定，其應能顯示高達24行之資料及高達48行之飛航列表資訊，而該等應顯示之相關資訊則包含飛航資料(又細分為警報Alert等五項資料)、氣象資料、禁航區資料(Restricted Area informative Data)、管制員公告資料及時間資料等五大類資料；「資訊列表顯示器」之最終格式定義，依投標文件第2冊第2.2.1.2節規定，應於PDR中確定。查74年5月21日PDR期間，民航局去函洛克希德公司，說明資訊列表顯示器關於「警報Alert」之相關資訊應分為四大類別，並分別敘明各類別Alert資訊之具體內涵，無非在重申基本需求規章之內容，提醒納入設計而已，非約外要求。

⒊實則，資訊列表顯示器在設計上既容許顯示高達24行之資料及高達48行之飛航列表資訊，而應顯示之資訊，卻僅大別為五類資料，即表示各大類資料之個別細項與具體內容，應待兩造於PDR會議中進一步律定，以符合民航局之實需與本件系統之建置模式，此觀諸洛克希德公司投標文件第2冊第2.2.1.2節明定，應於PDR中確定資訊列表顯示器之最終格式定義至明。經查：

⒈洛克希德公司主張民航局於其1985年5月21日函文中，就TACCPDR待辦事項第51、52號提出約外要求，並將上開顯示內容擴張並區分為獨立的4個警報區域及1個要求區域新增大量上述規格書所未要求、規定之顯示內容，民航局此等要求已逾越TACC規格書，而屬約外要求云云。

⒉按系爭航管自動化系統應採由上而下之建置方式，在PDR與CDR中，洛克希德公司應將民航局對系爭航管自動化系統之需求轉換為具體可行之設計藍圖，是關於狀況顯示器列表之基本需求規章縱具抽象性，亦為正常狀況，非需求曖昧不明，且民航局所為具體說明亦不致構成約外要求，另於後續之PDR與CDR會議中，洛克希德公司更有義務主動積極掌握落實民航局之澄清說明，洛克希德公司之投標文件第二冊第2-50頁亦明定顯示器之最終格式應於PDR中定案(詳上證83號，見本院卷4第614-1至615頁)，是關於狀況顯示器之具體功能與最終格式，依系爭契約約本待兩造於PDR會議中共同確定，已如前所述（詳參第四大項第五小項爭點），故該部分爭議兩造本可於PDR或CDR會議討論，故難認此部分為約外要求。

⒊另，民航局於75年7月23日函文仍要求洛克希德公司應將待辦事項51、52號新增於系爭航管系統，洛克希德公司始依民航局有關待辦事項51、52號之要求，於同年10月16日TACC-1120設計文件中，增加額外警示訊號(Alert Messages)及要求訊號(Requested Messages)於狀況顯示器之設計(詳洛克希德公司上訴暨答辯理由(24)狀附件4(6)-10，見本院卷9第191至217頁)，洛克希德公司雖據此主張因此耗費大量人力、時間，修改、變更顯示器相關之韌體及軟體、而延宕系爭航管系統之設計及開發，惟揆諸上開⒉之說明,該部分本非約外要求,且民航局於75年7月23日函文距洛克希德公司於同年10月16日提出前開TACC-1120設計文件僅不到3個月之時間，尚難認定洛克希德公司得於不到3個月時間內進行複雜之設計，況乎耗費多少時間、成本？洛克希德公司並未舉證該部分設計必須花多少時間、人力及成本，故其該部分之主張，實非足採。

⒋另洛克希德公司雖主張民航局要求洛克希德公司將警報(Alert)擴張及區分為獨立的4個警報區域(Alert Area)，及增加額外警示訊號(Alert Messages)及要求訊號(Requested Messages)於狀況顯示器之設計，應屬約外要求。經查，系爭航管系統乃將飛航安全視為最優先考量，警報系統設計完善應符合契約核心價值及精神，而民航局前開Alert Area仍屬警報(Alert)之一部分，警示訊號(Alert Messages)亦屬之，皆屬該部分設計之細節部分，尚難認屬約外要求，故此部分主張，尚無足採。

⒌中科院鑑定報告認為民航局之此項顯示功能要求，應屬顯示之細部功能，洛克希德公司若有疑義應主動積極向民航局澄清，最好在PDR進行前獲得一致結果。且洛克希德公司之投標書有說明「本系統之顯示功能在PDR時才作最後確認」，亦即說明本項顯示功能在PDR時才作確認，故非屬約外要求（見外放之中科院鑑定報告第69至70頁），此與前述本院判斷大致相符，故洛克希德公司該部分之主張，應非可採。另成大鑑定報告未斟酌上情而認定之，與本院調查之結果有違，非可採納，併此敘明。

⒍另中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD、CDR會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開⒌所述），就過失比例部分尚無庸參考，併予敘明。

第四大項第七小項關於洛克希德公司主張「民航局提出高層設計審核之約外要求」部分：A.洛克希德公司主張：

⒈依系爭航管工程之工作說明(Statement of Work；下稱「SOW」)第5.3.3.1節及5.3.3.2節規定，系爭航管工程之軟體設計審核，應採用美國軍規MIL-STD-1521A之初期設計審核(Preliminary Design Review；下稱「PDR」)及最後重要設計審核(Critical Design Review；下稱「CDR」)所制訂之標準程序為之。另依「民航局招標文件之闡明摘要中之合約資料需求清冊(CDRL)資料項目010(下稱「CDRL010」)之規定，洛克希德公司所製作之軟體設計文件中，僅航空管制系統說明(ATCSystem Description;ATCSD)，應提供有關系爭航管系統之高層設計說明予民航局審核。關於飛航管制系統說明(ATCSD)，洛克希德公司業依約於1984年6月20日提出ATCSD高層設計說明之ATC-1000文件予民航局審核，民航局經審核該ATC-1000及其他設計文件無誤後，於1984年8月30日核發TACC系統初期設計審核(PDR)之完工證明予洛克希德公司。

⒉惟民航局嗣後分別於1984年11月及1986年7月，要求洛克希德公司於TACC最後重要設計審核(CDR)及TCC初期設計審核(PDR)開始前，就TACC系統、顯示器韌體及TCC系統亦提供額外之高層設計說明予民航局審核。為提供該等額外之高層設計說明，洛克希德公司須耗費額外人力、時間備置相關文件，且因民航局要求於該等額外之高層審核程序完成後，始可進行TACC最後重要設計審核(CDR)及TCC初期設計審核(PDR)，致TACC最後重要設計審核(CDR)及TCC初期設計審核(PDR)因此遲延開始，延宕系爭航管工程之設計及工程執行。

B.民航局等則以：

⒈依系爭契約文件之「工作說明書(SOW)」與洛克希德公司投標文件等相關規定，洛克希德公司須採用「由上而下」之方式，進行系爭航管自動化系統之軟體程式設計，由洛克希德公司負責主動了解掌握民航局之需求，且將其轉換為可行之設計藍圖，並由民航局於PDR或CDR等階段審核洛克希德公司之設計文件，以建置滿足民航局需求之系爭航管自動化系統，此有TACC規格書第3.3.2.1節、TCC規格書第3.3.2.1節、洛克希德公司投標文件第二冊「工程」第3.6.1節就「系統需求」及「功能軟體設計」(TACC部分)、洛克希德公司投標文件第2冊「工程」第3.6.1節就「系統需求」及「功能軟體設計」(TCC部分)等文件可稽。

⒉依上開TCC規格書第3.3.2.1節及洛克希德公司投標文件第2冊「工程」第3.6.1節等規定，洛克希德公司應負責提出TCC系統之上層或高層結構之設計文件，並經民航局核准後，方得據以續行設計低階功能等，此更經成大鑑定。，故民航局75年7月31日函文不過重申系爭契約之前揭規定而已，自不構成約外要求；且依CDRL 010之規定，可知TACC系統及TCC系統之設計文件，均為ATCSD文件之一部，同樣應以高層展示之方式撰擬，故民航局陸續以73年11月20日函文、73年11月26日函文及75年7月31日函文，提醒洛克希德公司應就TACC系統及TCC系統提出高層設計等旨，不外重申CDRL010相關規定而已，自非約外要求；況關於民航局75年7月31日函文所提及，洛克希德公司應就TCC系統之PDR等設計文件提出高層設計，並遵循相關之文件審核方式乙節，嗣後更經洛克希德公司以75年8月14日函文回覆同意接受在案，故關於洛克希德公司依約應提出TCC系統之高層設計等節，業經兩造再次共同確認在案，並非所謂之約外要求。經查：

⒈洛克希德公司主張業依約於1984年6月20日提出航空管制系統說明(ATCSD)高層設計說明之ATC-1000文件予民航局審核，於同年年8月30日核發TACC系統初期設計審核(PDR)之完工證明。惟復分別於1984年11月及1986年7月，要求就TACC系統、顯示器韌體及TCC系統亦提供額外之高層設計說明予民航局審核，需耗費額外人力、時間備置相關文件，且於該等額外之高層審核程序完成後，始可進行TACC最後重要設計審核(CDR)及TCC初期設計審核(PDR)，致TACC CDR及TCC PDR因此遲延開始，延宕工程設計、執行云云。

⒉依系爭契約文件之工作說明書(SOW)相關規定，洛克希德公司須採用「由上而下」之方式，進行系爭航管自動化系統之軟體程式設計，由洛克希德公司負責主動了解掌握民航局之需求，且將其轉換為可行之設計藍圖，並由民航局於PDR或CDR等階段審核洛克希德公司之設計文件，以建置滿足民航局需求之系爭航管自動化系統，此有TACC規格書第3.3.2.1節、TCC規格書第3.3.2.1節等文件可稽（詳上證131號、132號，見本院卷10第340至344頁)。是關於狀況顯示器列表之基本需求規章縱具抽象性，亦為正常狀況，非需求曖昧不明，須另於後續之PDR與CDR會議中討論澄清，洛克希德公司更有義務主動積極掌握落實民航局之澄清說明，而非得籠統主張民航局之澄清說明構成所謂之約外要求。

⒊另按洛克希德公司之投標文件若無礙系爭契約目的之達成，而有相輔相成之效，且為洛克希德公司投標時明示可達成，則包含投標文件在內之各項契約文件均非不可併為適用，故洛克希德公司之投標文件本屬判斷洛克希德公司工作範圍之標準之一，已如前㈠所述（詳參第一大項第一小項爭點）。而洛克希德公司投標文件第二冊「工程」第3.6.1節就「系統需求」及「功能軟體設計」(TACC部分)、洛克希德公司投標文件第2冊「工程」第3.6.1節就「系統需求」及「功能軟體設計」(TCC部分)，亦規定洛克希德公司須採用「由上而下」之方式，進行系爭航管自動化系統之軟體程式設計（詳上證6號、133號，各見本院卷1第145至147頁、卷10第345至347頁），故洛克希德公司自應受該投標文件規定所拘束，系爭航管系統相關設計文件之撰擬原則上自應符合「高層設計」之結構與方式，是民航局於73年11月及75年7月間以函文方式通知洛克希德公司應就TACC系統及TCC系統提出「高層設計」，尚難認為屬約外要求，況洛克希德公司亦自承本於合作精神，遂於75年8月14日函文同意提供TCC系統之高層設計說明予民航局審核（詳101年7月27日洛克希德公司上訴暨答辯理由（27）狀爭點4-7第6頁及附件4（7）-10，各見本院卷9第228頁背面、第261至263頁），故洛克希德公司事後再為爭執，實無足採。

⒋成大鑑定報告認為系爭契約基本規章採用「由上而下」的設計理念，因此高層設計的必要性極為重要，洛克希德公司經過協商瞭解後，於1985年11月26日簽署同意進行高層設計，已解決所發生的問題和困難，且本項爭議契約基本規章中並無排斥性條款，雙方已經達成協議，本項應不屬於約外要求（見外放之成大鑑定報告第78頁）。此與前述本院判斷相符，故洛克希德公司該部分之主張，應非可採。另中科院並未就此部份進行鑑定，併予敘明。

⒌關於洛克希德公司於102年8月30日民事調查證據聲請續狀中，請求成大航太所補充說明之詢問事項，已於上開⒉、⒊部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

第四大項第八小項關於洛克希德公司主張「緊急碼之擴充」部分：A.洛克希德公司主張：TACC規格書第3.7.3.3.4.6.4.2.2節「字母數字之完整資料欄內容(Contents of Alphanumeric FullData Block)」及TCC規格書第3.7.3.3.4.4.4.2.2節「字母數字之完整資料欄格式(Format of Alphanumeric Full DataBlock)」均規定，完整資料欄應包含：劫機(Hijack，HIJK)，編碼為7500；無線電通訊中斷(RDOF；Radio Off)，編碼為7600；一般警報(EMRG；Emergency)，編碼為7700等3種緊急碼。惟民航局於其1985年9月5日函文要求將緊急碼擴充為75XX、76XX及77XX等編碼。民航局該等要求係逾越TACC及TCC規格書，而屬約外要求。為配合民航局擴充緊急碼之約外要求，洛克希德公司原已依TACC及TCC規格書上述規定進行之韌體、軟體設計，須因此而修改、變更，致進一步影響系爭航管系統之設計及施作。

B.民航局等則以：

⒈按TACC規格書第3.7.3.3.4.6.4.2.2節與TCC規格書第3.7.3.3.4.4.4.2.2節規定劫機、訊息中斷與緊急資訊之緊急碼分別為7500、7600及7700，洛克希德公司亦以此為前提進行設計，而對洛克希德公司依前揭規定製作關於「緊急碼」之設計文件，民航局於74年8月5日表示接受(acceptable)，並未強要洛克希德公司修改為75XX、76XX及77XX，僅附帶提醒洛克希德公司，在實務上相關之緊急碼亦有75XX、76XX及77XX等型態，未被侷限於7500、7600及7700等三種固定型態而已，從未要求洛克希德公司進行修改或有任何不核准之行為，更與提出約外要求無涉。經中科院鑑定認定在案。

⒉民航局更未要求洛克希德公司修改韌體，洛克希德公司對其是否因此修改韌體致遲延交付系爭航管自動化系統等節，完全未舉證以實其說。更何況，不論民航局是否就此提出約外要求，從軟體發展之觀點來看，將7500、7600及7700修改為75XX、76XX及77XX，根本不會影響顯示器韌體，此亦經中科院鑑定認定在案，是其主張益徵其欠缺設計系爭航管自動化系統之能力，就本件遲延為可歸責無疑等語，資為抗辯。經查：

⒈洛克希德公司主張：TACC規格書第3.7.3.3.4.6.4.2.2節「字母數字之完整資料欄內容及TCC規格書第3.7.3.3.4.4.4.2.2節「字母數字之完整資料欄格式均規定，完整資料欄應包含：劫機(Hijack，HIJK)，編碼為7500；無線電通訊中斷(RDOF；Radio Off)，編碼為7600；一般警報(EMRG；Emergency)，編碼為7700等3種緊急碼。惟民航局於其1985年9月5日函文要求將緊急碼擴充為75XX、76XX及77XX等編碼。此等要求係逾越TACC及TCC規格書，屬約外要求；且原已依TACC及TCC規格書上述規定進行之韌體、軟體設計，須因此而修改、變更云云。

⒉查，細譯民航局於74年8月5日函文(見上證149，本院第12卷第55頁背面、第64頁)係表示”the approach outlined isacceptable"表示接受洛克希德公司所提交之設計文件，僅附帶提醒洛克希德公司，在實務上相關之緊急碼亦有75XX、76XX、77XX等編碼型態，並無不予核准之意，且洛克希德公司並未反對，雖民航局嗣於74年9月5日之函文中，將洛克希德公司緊急碼7500、7600、7700之塗改為75XX、76XX、77XX等編碼（詳洛克希德公司上訴暨答辯理由（24）狀附件4⑻-4，見本院第9卷第287-289頁），惟上開9月5日之函文係回應同年7月30日函文(見subject)，而在上開8月5日函文既未為反對，故其始於9月5日對7月30日函文為塗改更正，而洛克希德公司旋於同年11月20日將擴充之緊急碼納入TACC-1000設計文件(按TACC-1000係有關雷達資料處理程式應處理之訊息種類之設計文件，詳洛克希德公司上訴暨答辯理由（24）狀附件4⑻-5，見本院卷9第290至293頁)，自民航局至洛克希德公司提出設計文件之時間甚短，扣除函文往返、內部簽核流程等時間，洛克希德公司實際能從事設計之時間甚短，並參諸中科院下開鑑定認定該項需求時程影響極小，前開事實互核一致，洛克希德公司無法證明其利用原訂契約工時以外之時間從事設計工作，其所提出之工時單亦無法證明是否有人員加班等額外成本、時間之耗費，已如前所述（詳參第一大項第十一小項爭點）。縱該部分民航局之要求屬約外要求，惟揆諸洛克希德公司僅花極少時間即設計完成，可知其影響工程進度甚微，洛克希德公司並未舉證其有何人力、物力上之支出以實其說，尚難認為民航局該部分之要求對於系爭航管系統設計工程有何重大影響或延宕工期之情事，故洛克希德公司該部分之主張，實無足採。

⒊中科院鑑定報告認為此項需求增加對其設計及時程影響極小，判斷及顯示7500、7600、7700及75XX、76XX、77XX是一樣的動作，不會影響到顯示器韌體，故非如洛克希德公司所述因顯示器韌體須配合修改而延遲進度。又民航局於CDR之前函請洛克希德公司「考量」納入此要求，並無強制性，且洛克希德公司針對此要求沒有任何回應及反彈，故非約外要求（見外放之中科院鑑定報告第70至71頁）。此與前述本院判斷大致相符，故洛克希德公司該部分之主張，應非可採。另成大鑑定報告未斟酌上情而認定之，與本院調查之結果有違，非可採納，併此敘明。

⒋另中科院之鑑定報告，未就系爭契約相關各項文件，包括投標文件、PRD、CDR會議記錄等資料為綜合判斷，而遽為認定兩造之過失比例，本院雖斟酌部分鑑定意見，惟業已判斷不可歸責民航局（詳如上開⒊所述），就過失比例部分尚無庸參考，併予敘明。

第四大項第九小項關於洛克希德公司主張「顯示器之待辦工作項目」部分：A.洛克希德公司主張：

⒈依系爭航管契約「中華民國政府應提供之設備及服務(ListofROC Furnished Equipment and Services，下稱「GFE」)」第18條規定，民航局應於1984年3月20日前提出顯示器格式定義(display formats to be delivered to LILT by CAA)，惟民航局遲誤該1984年3月20日期限而未提出。該等顯示器格式定義遂於TACC初期設計審核(PDR)期間(即1984年7、8月間)列為TACC PDR待辦事項(TACC PDR Action Item)第13、36、51、52、61號及一般待辦事項(General Action Item)第72號，而由民航局儘速於TACC PDR會議後提出。民航局雖於1984年10月至1985年7月間，依上述各待辦事項，提出相關之顯示器格式定義文件，惟民航局所提出之顯示器格式定義文件中，包含大量逾越基本需求規章之約外要求，致洛克希德公司被迫與民航局進行多次、長期之反覆澄清及討論，其相關爭議並延續至1985年2月至1986年9月間之TACC最後重要設計審核(CDR)及1986年9月間始之TCC PDR。

⒉民航局業指示中信局提出1987年1月8日變更指令，表明就該等TACC PDR待辦事項第13、36、51、52、61及72號等要求，將依系爭闡明條款第4.1條(民航局要求額外的設備、服務；按即約外要求)辦理契約修正，足見TACC PDR待辦事項第13、36、51、52、61及72號確屬出約外要求。故依系爭闡明條款第4.1條及第4.2條「可宥恕之遲延(Excusable Delays)」，民航局等就該等約外要求，即有義務展延工期並追加工程價款。迺無視已自認提出約外要求及系爭闡明條款第4.1條及4.2條之規定，竟於1988年6月25日率爾終止系爭航管契約，自不生合法終止之效力。

B.民航局等則以：

⒈按系爭航管自動化系統應採由上而下之建置方式，在PDR與CDR中，應將民航局對系爭航管自動化系統之需求轉換為具體可行之設計藍圖，是關於狀況顯示器列表之基本需求規章縱具抽象性，亦為正常狀況，並非需求曖昧不明，而民航局所為具體說明亦不致構成約外需求，另於後續之PDR與CDR會議中，洛克希德公司更有義務主動積極掌握落實民航局之澄清說明，而非一味主張基本需求規章之規定不明，或籠統主張民航局之澄清說明構成所謂之約外要求，並執為本件遲延為不可歸責之藉口，此亦有中科院鑑定可稽。

⒉系爭合約文件GFE第18條亦規定，狀況顯示器格式之定義，應在簽約後二個月由民航局、洛克希德公司及其供應商舉行會議律定(詳上證82號)，而洛克希德公司之投標文件第二冊第2-50頁更明定，顯示器之最終格式應於PDR中定案，是關於狀況顯示器之具體功能與最終格式，依約本待兩造於PDR會議中共同確定，更經中科院鑑定認定在案，洛克希德公司主張實屬曲解GFE第18條暨其投標文件之明文規定。且狀況顯示器之具體功能與最終格式，依約本待兩造於PDR會議中確定，且兩造亦已如期確定顯示器，而經兩造於74年8月8日第4次契約變更中確認在案，此觀諸第4次契約變更之附件3關於「GFE第18項」之欄位，明白記載「已收訖，顯示器會議業已結束」(Received，Display ConferenceCo mpleted)等語即明，可知兩造已合意確認並解決顯示器會議是否如期召開之爭議，洛克希德公司自不得事後翻異，甚或主張適用闡明條款所定之宥恕事由。

⒊關於待辦事項第13號(AI 13)，即鈞院前審判決附表1編號1之(11)所謂「單機飛航操作說明(STOD)之約外要求」部分；關於待辦事項第36號(AI 36)，即鈞院前審判決附表1編號1之(3)所謂「狀況顯示器列表之曖昧不明及矛盾」部分；關於待辦事項第51號(AI51)，即鈞院前審判決附表1編號1之(6)所謂「指定跑道/使用中跑道約外要求」部分；關於待辦事項第52號(AI52)，即鈞院前審判決附表1編號4之(6)所謂「台北地區管制中心計畫控制顯示器之歸航資料」部分；關於待辦事項第61號(AI61)，即鈞院前審判決附表1編號1之(8)所謂「顯示時間間隔之約外要求」部分；關於待辦事項第72號(AI72)，即鈞院前審判決附表1編號4之(5)「待辦之工作項目對於電腦作業程式之影響」皆非約外要求，已如前述。且洛克希德公司業已於74年7月2日函文自認TACC系統PDR待辦事項第51、52及61項並不影響系爭契約之交期，故與本件遲延間亦無任何因果關係。

⒋民航局1987年1月8日變更指令，於主旨記載係就系爭系統之「顯示器韌體升級」事項(Display Firmware Upgrade)所核發，內容則進一步記載係就TACC系統之PDR第13、36、51、52、61項及一般事項第72項其中所涉之顯示器韌體升級事項，應辦理契約變更等語，可知該變更指令係在處理各項目中所謂顯示器之韌體升級問題，惟洛克希德公司主張之所謂四大項36小項遲延事由，全部非韌體升級問題，更非顯示器之韌體升級問題造成洛克希德公司履約遲延，故民航局1987年1月8日變更指令，根本與洛克希德公司主張之所謂四大項36小項遲延事由毫無關係。

⒌依系爭合約文件GFE第18條及洛克希德公司投標文件第二冊第2-50頁等規定，顯示器格式之定義，應在簽約後二個月由民航局、洛克希德公司及其供應商舉行會議律定，而關於計畫控制顯示器(Insector and inbound PCD，下稱PCD)之設計部分，關於PCD之「資料顯示一般格式」與「警示(Alerts)資料之處理及顯示」民航局業於73年8月21日提出關於AI51及AI52之資料，更於同年9月19日討論後2日內即9月21日再次補充；關於PCD之「顯示時間間隔」之問題，經列為PDR待辦事項第61項，對此民航局業已提供詳盡之評論(detailed write up)予洛克希德公司參考；關於PCD之「符號及/或明亮顯示」之問題，經列為PDR待辦事項第72項，於73年8月9日之會議上，洛克希德公司之次供應商Magnovox表示將提交相關文件供民航局審核參考，可見相關資料均已於PDR中提出相關文件供洛克希德公司進行設計，並無任何遲延提供之情事，成大鑑定報告亦認定，洛克希德公司之主張不甚具體明確，且其次供應商與民航局對問題之見解相同，更接受上訴人之意見進行設計，是民航局關於PCD之設計，並未提出約外要求等語，資為抗辯。經查：

⒈洛克希德公司主張民航局未於1984年3月20日之期限內提出顯示器格式定義民航局雖於1984年10月至1985年7月間，依上述各待辦事項，提出相關之顯示器格式定義文件，惟民航局所提出之顯示器格式定義文件中，包含大量逾越基本需求規章之約外要求，嗣後民航局業指示中信局提出1987年1月8日變更指令，表明就該等TACC PDR待辦事項第13、36、51、52、61及72號等要求，將依系爭闡明條款第4.1條辦理契約修正云云。

⒉按，狀況顯示器之具體功能與最終格式，依系爭契約及洛克希德公司投標文件等相關契約文件規定，本待兩造於PDR會議中共同確定，已如前、所述（詳參爭點第四大項第五小項及第六小項），且兩造於74年8月8日第4次契約變更中確認在案，此觀諸第4次契約變更之附件3關於「GFE第18項」之欄位，明白記載「已收訖，顯示器會議業已結束」(Received，Display Conference Completed)等語即明(詳上證22號倒數2頁，見本院卷1第228頁)，可知兩造已合意確認並解決顯示器會議是否如期召開之爭議，洛克希德公司自不得事後再為翻異，民航局並未遲延提出顯示器格式定義，已如前、所述（詳參爭點第二大項第二小項及第四大項第五小項）；另洛克希德公司主張民航局於提出TACC PDR待辦事項（Action Item，下稱AI）第13、36、51、52、61號及第72號相關之顯示器格式定義文件時，包含大量逾越基本需求規章之約外要求，致洛克希德公司被迫與民航局進行多次、長期之反覆澄清及討論而延遲工期，惟前開待辦事項，包括第13號即「單機飛航操作說明之約外要求」、第36號即「狀況顯示器列表曖昧不明及擴張」、第51號即「指定跑道/使用中跑道之約外要求」、第52號即「台北區域管制中心計畫控制顯示器之歸航資料」、第61號即「顯示時間間隔之曖昧不明及擴張之約外要求」及第72號即「代辦之工作項目對於電腦作業程式之影響」，皆非可歸責於民航局，已如前、㈢、㈥、、㈧、所述（依序詳參爭點第一大項第十一小項、第一大項第三小項、第一大項第六小項、第四大項第六小項、第一大項第八小項、第四大項第五小項），故該部分洛克希德公司之主張，均無足採。

⒊另查洛克希德公司1985年9月4日函(詳民原證180號，"見本院卷第頁")之內容略以：「洛克希德公司已收受Reference 2.所示之民航局1985年8月29日函（詳原證179號，另見本院卷5第163至164頁)，並認為應依闡明條款第4.3條之變更指令辦理。洛克希德公司正等候民航局關於前揭Reference3.所示之函文之洛克希德公司74年7月2日函（詳原證177號)之回覆，該函文係指合併PDR待辦事項第51、52及61項而言」，而關於前揭PDR待辦事項第51、52及61項之洛克希德公司74年7月2日函文則記載：「洛克希德很榮幸能告知民航局...此對未來契約所預定之交期並無任何影響」(詳民原證177號第2段：Lockheed ispleased toadvise the CAA that,……therewill be noimpact on scheduled completion dates，另見本院卷23第479頁)，雖洛克希德公司陳稱1985年7月2日之函文中有關不影響工期之增加價格提案，係希民航局依系爭闡明條款第4.1條、4.3條規定，將新增功能納入契約之範疇，以「民航局等當時(1985年7月2日)能及時提出變更指令並追加價款，使洛克希德公司能即時就民航局之約外要求，利用追加之工程款項進行趕工，期能不影響整體工程交期云云(見洛克希德公司言詞辯論意旨狀，本院第23卷第479頁)，惟查，民航局於其時尚無回應洛克希德之請求，嗣兩造隨即於74年8月8日第4次契約變更中確認在案而洛克希德公司未為保留，可知不論PDR待辦事項第51、52及61項是否為約外要求，洛克希德公司既對系爭航管自動化系統之交貨日期未為保留，應認為與本件遲延間亦無任何因果關係，故洛克希德自不得再為相反之主張。

⒋洛克希德公司主張民航局於76年1月8日指示變更指令已自承前揭待辦事項為約外要求云云。經查，該變更指令於主旨記載係就系爭系統之「顯示器韌體升級」事項(Display Firm wareUpgrade)所核發，內容則進一步記載係就TACC系統之PDR第13、36、51、52、61項及一般事項第72項其中所涉之顯示器「韌體升級事項」，應辦理契約變更等語(詳上證115號，見本院卷7第458頁)，可知該變更指令係在處理各項目中所謂顯示器之「韌體升級」問題，而洛克希德公司主張之所謂四大項36小項遲延事由皆非韌體升級問題，更非顯示器之韌體升級問題造成洛克希德公司履約遲延，故民航局於76年1月8日變更指令，根本與洛克希德公司主張之所謂四大項36小項遲延事由毫無關係；且系爭航管契約之主要契約義務為軟體設計，而韌體為依附於硬體用於驅動軟體之程式，為便利軟體之使用，且系爭航管系統之軟體設計並非約外要求，已如前開各項所論述，故洛克希德公司自有設計韌體之義務，就此而言，韌體之設計尚難認為約外要求，況洛克希德公司亦無舉證韌體設計部分是否完成或完成若干，故該部分洛克希德公司之主張，實無足採。

⒌成大鑑定報告認為民航局對洛克希德公司曾提出待辦要求，並且也獲得次承包約商美格福斯(Magnovox)公司之回應，顯然對問題之見解相同，且接受民航局之意見配合修改，故本項應不屬於約外要求（見外放之成大鑑定報告第80頁），此與前述本院判斷結果大致相符，故洛克希德公司該部分之主張，應非可採。另中科院並未就此部份進行鑑定，併予敘明。

⒍關於洛克希德公司於102年8月30日民事調查證據聲請續狀中，請求成大航太所補充說明之詢問事項，已於上開⒉、⒋部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

⒎另洛克希德公司主張最高法院發回意旨(見本院第23卷第478頁背面)指出「單機飛航操作說明為約外要求...」，可徵民航局辯稱顯示器格式定義已於1985年8月8日第4次修約時定案云云，惟查，「單機飛航操作說明為約外要求...」業已於約外要求(即第一大項第十一小項)說明洛克希德公司主張為不可採，併予敘明。

第四大項第十小項關於洛克希德公司主張「軟體標準及實施手冊ATC-1200文件」部分：A.洛克希德公司主張：

⒈民航局招標文件之闡明摘要「Clarifications」)之合約資料需求清冊資料項目(CDRL DataItem)010(以下稱「新CDRL010」)，已明訂系爭航管系統工程之各種電腦程式結構項目發展規格(Computer Program Configuration Item DevelopmentSpecification )(即軟體設計文件；下稱CPCI文件)」文件之種類、範圍、格式及內容。惟民航局於1984年10月29日之CDRL010之重組計畫(CDRL 010 RESTRUCTURING)，要求洛克希德公司製作一額外而非新CDRL 010所要求、規定之軟體標準及實施手冊(即編號為ATC-1200文件)，供民航局參考，以作為各種電腦程式結構項目發展規格(CPCI文件)之製作準則。

⒉民航局復於1985年1月18日及1985年1月29日函文，片面擴張CPCI文件內容及格式，致洛克希德公司必須反覆與民航局討論、澄清。嗣民航局雖於1985年3月20日函文自認該ATC-1200文件係屬約外要求，惟仍要求洛克希德公司改寫CPCI文件，以符合民航局上開片面提出之新內容及格式，致洛克希德公司先前為備具關於CPCI文件已耗費之人力、資源及時程，均成徒然、白費，並導致系爭航管工程進度之遲延。

B.民航局等則以：

⒈按「程式設計規格」(Program Design Specification，下稱PDS文件)為洛克希德公司投標文件第2冊第3.4.3.1節所定應由洛克希德公司撰寫並提出之軟體文件，更為CDRL 010所定應由民航局審核之文件，乃確保電腦程式功能規格(ComputerProgram Functional Specifications，CPFS)能轉換為系爭航管自動化系統之程式設計所需之技術文件，須經民航局審閱並核准後，方能據以進行後續之程式撰寫，是PDS文件乃洛克希德公司依投標文件與CDRL 010所應提出由民航局進行審核之文件至明。查洛克希德公司於73年10月29日來函說明，其將重組CDRL 010文件，且將屬於CDRL 010中PDS文件一部之軟體發展標準(Software DevelopmentStandards)重新編號(renumbering)為ATC-1200文件，是ATC-1200文件實屬PDS文件之一部分，為洛克希德公司依其投標文件與CDRL 010所應提出之文件，非約外要求，成大鑑定報告亦認定，ATC-1200文件為洛克希德公司依基本需求規章所應提交之軟體說明文件，非約外要求。

⒉另按系爭航管自動化系統之軟體開發，依系爭契約工作說明書(SOW)及投標文件之相關記載，必須採取由上而下之方式進行設計，而在建置過程中，則需先分析買受人之需求，並將之轉換、落實至為具體之設計作為(下稱「分析與設計階段」)。故出賣人須在審視專案性質、規模、成本、時間及人員素質等因素後，決定採用何種方法論以進行系統建置、軟體開發及設計文件之撰擬，並接受買受人之審核，以確保所建置之系統真能符合買受人之需求。洛克希德公司採用未能滿足建置系爭系統全部需求之「優頓方法論」，對此民航局乃基於工作說明書SOW之文件審核權限，在不延誤交期之考量下，去函說明洛克希德公司若擬採取「優頓方法論」，仍須補充提供更充份之資訊以供審核，且民航局亦將相應緩和並放寬審核之標準，期能補救因洛克希德公司能力不足所致之遲延，迺其竟為相反之主張，甚至曲解相關函文之明確文義，本件遲延可歸責於洛克希德公司。

⒊依系爭契約文件之「工作說明書(SOW)」第5.3.3.1節及第5.3.3.2節等規定，民航局得就洛克希德公司提出之相關PDR及CDR設計文件，行使審核、確認、調整或修正等審查權限，以確保洛克希德公司之設計，確能符合系爭契約之功能性需求，並非約外要求。民航局74年5月10日函文係委婉告知洛克希德公司所提文件之內容不備，無法通過審核，並本於合作之精神，重申民航局基於SOW有權審查相關設計文件之立場及可能之解決辦法而已，不但未提出任何約外要求，亦未強要洛克希德公司重寫設計文件，洛克希德公司自應就本件遲延負全部之責任等語，資為抗辯。經查：

⒈洛克希德公司主張民航局於1984年10月29日之CDRL 010之重組計畫，要求洛克希德公司製作一額外而非新CDRL 010所要求、規定之軟體標準及實施手冊(即編號為ATC-1200文件)，供民航局參考，以作為各種電腦程式結構項目發展規格(CPCI文件)之製作準則；另民航局復於1985年1月18日及1985年1月29日函文，片面擴張CPCI文件內容及格式，嗣民航局雖於1985年3月20日函文自認該ATC-1200文件係屬約外要求，惟仍要求洛克希德公司改寫CPCI文件，致先前為備具關於CPCI文件已耗費之人力、資源及時程，形成白費，導致系爭航管工程進度之遲延云云。

⒉經查，民航局否認74年3月20日函文有自認該ATC-1200文件係屬約外要求之情，且揆諸該函文之內容，係表示：「洛克希德公司撰擬之ATC-1200文件，並非契約需求，惟依民航局所建議之方式撰寫並提出ATC-1200文件，則為契約之需求」、「所謂以優頓方法論撰寫設計文件，可滿足契約需求云云之說法，並不正確。因為優頓方法論在程式設計上之定義，具有不完整且不明確之缺陷，其既不能滿足民航局之CPDS標準，亦不能滿足洛克希德公司對CPDS之摘要說明」等語(詳洛克希德公司上訴暨答辯理由(26)狀附件4(10)-11，該函文第1頁第1段第1至4行；第2頁第10至15行，見本院卷9第513至514頁)，民航局並未有任何自承為約外要求之意，故洛克希德公司該部分之主張，實無可採。

⒊另按雖系爭契約附件FORM B已就合約文件之適用明訂順序，唯若無礙系爭契約目的之達成，而有相輔相成之效，且為洛克希德公司投標時明示可達成，則各項契約文件均非不可併為適用；且依系爭契約附件FORM B之規定，洛克希德公司應遵守包括投標文件在內之一切契約文件，而負責就載有本件系統功能性需求之契約文件(包含但不限於民航局之招標文件(RFP)、洛克希德公司投標文件、相關軍事規範、兩造所舉行歷次技術澄清會議之書面會議紀錄、闡明摘要及洛克希德公司就自己投標文件所為之闡明等文件)，進行相關之分析作業，以建置系爭航管自動化系統，故洛克希德公司之「投標文件」本屬判斷洛克希德公司工作範圍之標準之一，已如前㈠所述（詳參第一大詳第一小項爭點）。經查，程式設計規格(PDS)不但為洛克希德公司投標文件第2冊第3.4.3.1節所定應由洛克希德公司撰寫並提出之軟體文件(詳上證154號，見本院卷12第134至138頁)，更為CDRL 010所定應由民航局審核之文件(詳上證134號，見本院卷10第348至351頁)，乃確保電腦程式功能規格(ComputerProgram Functional Specifications，CPFS)能轉換為系爭航管自動化系統之程式設計所需之技術文件，須經民航局審閱並核准後，方能據以進行後續之程式撰寫(詳上證154號即洛克希德公司投標文件第3.7.4節及第3.4.3節之說明，及上證134號，各見本院卷12第134至138頁、本院卷10第348至351頁)，是PDS文件乃洛克希德公司依投標文件與CDRL 010所應提出由民航局進行審核之文件，而查洛克希德公司於73年10月29日來函說明，其將重組CDRL 010文件，且將屬於CDRL 010中PDS文件一部之軟體發展標準(Software DevelopmentStandards)重新編號(renumbering)為ATC-1200文件(詳上證155號，見本院卷12第139至146頁)，故ATC-1200文件實屬PDS文件之一部分，而洛克希德公司自應依其投標文件與CDRL 010規定，提出該ATC-1200文件予民航局。

⒋況工作手冊及操作說明書等依一般情形及工程慣例本屬完成工程時必要之說明文件，否則定作人無從依循操作，縱承攬人於系爭航管系統完成時已將系爭航管系統之操作及使用方式口頭告知定作人，惟定作人時有人員更替，承攬人亦同，若無工作手冊或操作說明書等文件，則難以完成交接工作，系爭航管系統設計再完善亦可能因人員操作不當而無法發揮應有之功能及效用，就此而言，若洛克希德公司未提供軟體標準及實施手冊即ATC-1200文件，尚難認為洛克希德公司已依債之本旨而為給付，故該部分並非約外要求，洛克希德公司之主張實無可採。

⒌成大鑑定報告認為飛航管制自動化系統主合約基本規章依慣例必須完成軟硬體之說明文件，計畫完成之驗收程序中，所發展之軟硬體說明文件為必須的條件，依據基本合約規章，本系統應繳付之必要文件應包括軟體說明，故本項應不屬於約外要求（見外放之成大鑑定報告第81頁），此與前述本院判斷結果相符，故洛克希德公司該部分之主張，應非可採。另中科院並未就此部份進行鑑定，併予敘明。

⒍關於洛克希德公司於103年5月2日民事調查續㈡狀中，請求成大航太所補充說明之詢問事項，已於上開⒉、⒊、⒋部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

第四大項第十一小項關於洛克希德公司主張「臺北區域管制中心及終端區域管制中心軟體結構說明」部分：A.洛克希德公司主張：

⒈經民航局詳細審閱美商洛克希德電子公司投標文件第二冊第3.7節所建議之各種CPCI文件之種類、範圍、格式及內容後，認與最佳商業慣例相符。雙方乃協議以該投標文件第二冊第3.7節之CPCI文件相關製作建議，取代原合約資料需求清冊項目(CDRL)010，並明訂於民航局招標文件之闡明摘要合約資料需求清冊資料項目(CDRL Data Item)010(亦即新CDRL 010)。準此，系爭航管系統工程之CPCI文件之種類、範圍、格式及內容，即應以新CDRL 010為唯一準據，且該新CDRL 010所規範之CPCI文件種類、範圍、格式及內容，係符合最佳商業慣例。

⒉上開「新CDRL 010」已明訂系爭航管系統工程之各種電腦程式結構項目發展規格(CPCI文件」文件之種類、範圍、格式及內容。該CPCI文件其中之總體電腦程式說明(OverallComputer Program Description；「OCPD」)文件內容，係就電腦軟體之功能，提供總體、概觀說明。惟民航局於1984年10月29日之CDRL 010重組計畫中，提出變更總體電腦程式說明(OCPD)文件之階層位置之約外要求。民航局復於1985年6月10日函文，要求捨棄新CDRL 010之總體電腦程式說明(OCPD)原訂文件格式及內容(就電腦軟體之功能提供總體、概觀說明)，而要求變更為提供軟體文件結構說明。民航局上開變更總體電腦程式說明(OCPD)之階層位置及格式、內容之要求，與新CDRL010不符，係屬約外要求。

B.民航局等則以：

⒈按「軟體結構說明」(OCPD文件)為洛克希德公司投標文件第2冊第3.7.2節(TACC部分)與第3.7.1節(TCC部分)所定之軟體文件，其內容包含系爭航管自動化系統之功能性能力、設備組態(equipmentconfiguration)與變異及各功能區域等之描述，且為CDRL 010所定應提交供民航局審核之文件之一，是OCPD文件乃洛克希德公司依投標文件與CDRL 010所應提出由民航局進行審核之文件至明。查洛克希德公司於73年10月29日來函說明，其將重組CDRL 010文件，且將屬於CDRL010中之OCPD文件重新編號為TACC-2000等（按：TACC、TCC相關軟體之2000系列為系統整體概述；3000系列為設計規格；4000系列為資料庫，5000系列為程式碼)，是TACC-2000等文件實為OCPD文件，乃洛克希德公司依投標文件與CDRL 010所應提出之軟體設計文件，成大鑑定亦認定TACC 2000等文件為洛克希德公司依基本需求規章及CDRL 010所應提交之軟體文件，並非約外要求。

⒉洛克希德公司主張民航局以74年6月10日函文，要求洛克希德公司捨棄OCPD文件，並要求其另提出CDRL 010所未要求之高層軟體設計說明(top-level software design information)，構成約外要求及變更設計云云，蓋以前揭函文係表示：兩造於平原市之會議上業已同意就OCPD文件之發佈(publication)進行評估，關此CAA認為OCPD文件之價值雖然不大，但高層軟體設計說明之介紹仍有必要，故建議可將之置於OCPD文件內等旨，徵諸OCPD文件及高層設計均屬洛克希德公司依CDRL 010等規定所應提交審核之文件等情，民航局前揭函文實未有任何提出約外要求或變更設計之可言，更未要求廢棄OCPD文件，其曲解前揭函文之明確文義等語，資為抗辯。經查：

⒈洛克希德公司主張雙方協議投標文件第二冊第3.7節之CPCI文件相關製作建議，取代原合約資料需求清冊項目(CDRL)010，並明訂於民航局招標文件之闡明摘要合約資料需求清冊資料項目(CDRL Data Item)010(亦即新CDRL 010)，而該「新CDRL010」已明訂系爭航管系統工程之各種電腦程式結構項目發展規格(CPCI文件)，惟民航局於1984年10月29日之CDRL 010重組計畫中(CDRL 010 RESTRUCTURING)，提出變更總體電腦程式說明(OCPD)文件之階層位置之約外要求。民航局復於1985年6月10日函文，要求捨棄新CDRL 010之總體電腦程式說明(OCPD)原訂文件格式及內容，要求變更為提供軟體文件結構說明，與新CDRL 010不符，係屬約外要求云云。

⒉雙方雖協議以洛克希德公司投標文件第二冊第3.7節之CPCI文件相關製作建議為藍本，重新訂定CDRL 010及其中之CPCI文件之種類、範圍、內容、格式，惟於73年7月20日之TACC PDR會議中，民航局之技術顧問邁特公司提案要求就新CDRL 010所規範之CPCI文件種類、範圍、格式及內容，進行重組結構(restructure)及重定格式(reformat)，民航局遂將該提案列為TACC PDR待辦事項第1號(詳洛克希德公司上訴暨答辯理由(26)狀附件4(11)-6，見本院卷9第570至571頁），而洛克希德公司自承本於合作精神，與民航局和邁特公司討論後，基於討論結果，於73年10月29日函文提出CDRL 010之重組計畫(CDRL010 RESTRUCTURING)，原編號為TACC-1000之TACC系統總體電腦程式說明(OCPD)，遂變更為TACC-2000（詳洛克希德公司上訴暨答辯理由(26)狀附件4(11)-7，見本院卷9第572至583頁），就此而言，民航局上述要求既與洛克希德公司合作共同討論，雙方已達成合意，非屬約外要求；且PDR會議之功能在於雙方就基本規章及其他契約文件有不完備或不明之處進行討論，洛克希德公司本有義務主動積極掌握落實民航局之澄清說明，而非一味主張基本需求規章之規定不明致其無法及時進行軟體設計而延宕系爭航管工程進度，或籠統主張民航局之澄清說明構成所謂之約外要求，故該部分洛克希德公司之主張，應非可採。

⒊另民航局雖於74年6月10日要求洛克希德公司提出「軟體文件結構說明」（按：即OCPD文件，屬高層軟體設計說明)，民航局並提出其所建議之軟體文件結構說明文件格式，要求洛克希德公司配合修改表示該軟體文件結構說明應可放置於現成之TACC-2000文件（即重新編號之OCPD文件）內（詳洛克希德公司上訴暨答辯理由(26)狀附件4(11)-8：民航局1985年6月10日函文，見本院卷9第584至594頁），惟「軟體結構說明」為洛克希德公司投標文件第2冊第3.7.2節(TACC部分)與第3.7.1節(TCC部分)所定之軟體文件，其內容包含系爭航管自動化系統之功能性能力、設備組態(equipment configuration)與變異及各功能區域等之描述(詳民上證156號、上證154號，各見本院卷12第147至154頁、第134至138頁)，且為CDRL 010所定應提交供民航局審核之文件之一(詳上證134號第1頁，見本院卷10第348至351頁)，是OCPD文件乃洛克希德公司依投標文件與CDRL 010所應提出由民航局進行審核之文件；且OCPD文件本為CPCI文件內容之一部份，而民航局本有編整與修訂CPCI文件之內容、種類、範圍、格式之權限，則民航局自亦得編整與修訂OCPD之內容、種類、範圍、格式；況民航局上開之要求，僅是要求承攬人即洛克希德公司針對軟體結構設計部分而為說明，故定作人即民航局自有審核該文件之權力，並非洛克希德公司一經提出其製作之文件即為已足，若民航局認為洛克希德公司所提之OCPD文件不夠完備或過於抽象，自可要求再提供更為完備、具體之OCPD文件，就此而言尚難謂民航局之要求屬約外要求；另洛克希德公司亦自承其基於合作精神並避免工程延宕，故同意依民航局所要求之新格式、內容，重新製作該TACC-2000文件，並於民國75年1月21日函文提供TACC-2000文件予民航局審閱（詳洛克希德公司上訴暨答辯理由(26)狀附件4(11)-9，見本院卷9第595至597頁），嗣後並依循民航局指定之新格式、內容，製作TCC-2000文件，並於1986年8月27日送交民航局審閱(詳洛克希德公司上訴暨答辯理由(26)狀附件4(11)-10，見本院卷9第598至599頁)，故洛克希德公司應不得再主張該部分為約外要求，且洛克希德公司並未具體舉證其為進行相關設計工作，耗費多少額外人力、時間以致遲延工作進度，故洛克希德公司之主張，實非足採。

⒋成大鑑定報告認為CDRL-010既為合約規章中所明訂之必要文件，其中編整與修訂可以依據實務需求調整，故本項應不屬於約外要求（見外放之成大鑑定報告第82頁），此與前述本院判斷結果相符，故洛克希德公司該部分之主張，應非可採。另中科院並未就此部份進行鑑定，併予敘明。

⒌關於洛克希德公司於103年5月2日民事調查續（二）狀中，請求成大航太所補充說明之詢問事項，已於上開⒉、⒊部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。

第四大項第十二小項關於洛克希德公司主張「飛航計畫之數目」部分：A.洛克希德公司主張：按TACC規格書第3.2.1.1節第8項規定，飛航資料處理系統每小時應能接受及處理至少300個飛航計畫，並未規定、要求該等飛航計畫(flight plan)須限於「動態(active)」，迺民航局於系爭航管工程執行中，提出、要求該等飛航計畫應全部限於動態(active)之飛航計畫，且於其1985年5月15日有關待辦事項第61號之回覆說明中，說明有關動態飛航計畫之概念。如飛航資料處理系統應能接受並處理至少300個動態(active)飛航計畫，則整個飛航資料處理系統之處理速率、包括電腦容量及速度，即須符合更高標準，此將影響洛克希德對於系爭航管工程之軟體、硬體之設計及開發。民航局之要求已逾越TACC規格書而屬約外要求，由於民航局提出約外要求，洛克希德公司因而需增加設計、開發狀況顯示器之軟體、硬體及韌體所需之人力、成本及時間，致系爭航管工程時程因而遲延。

B.民航局等則以：

⒈按「飛航計畫」(Flight Plan)係指向飛航服務單位提供關於航空器擬飛航或部份飛航之特定資料，而為使航管單位能妥善實施航空管制作為，一般之固定飛航計畫(ScheduledFlight Plan，又稱為「長期班表」)與非固定飛航計畫(Non-Scheduled Flight Plan)均須事先提交航管單位知悉，以利預先掌握航空器之相關資訊，為此TACC規格書第3.2.1節第9項乃規定，系爭航管自動化系統應能同時儲存至少1,500筆固定飛航計畫及300筆非固定飛航計畫，以確保民航局能事前知悉航空器之相關飛航資料，並據該等儲存於資料庫中之飛航計畫資料，預先制訂、調整、修正或實施相關航空管制措施。其次，在實施航空管制之過程中，關於即將或已經成為航管單位掌握之飛航器資料，亦即「動態」(active)之飛航計畫(如：起飛、鄰區交管或空中申請之飛行計畫)，須能由系爭航管自動化系統之資料庫中提出或進行相關處理，以核實進行航管措施，為此TACC規格書第3.2.1節第8項乃規定，系爭航管自動化系統至少應能接受及處理每小時300筆之飛航計畫，及在尖峰時刻每分鐘10筆飛航計畫，以確保航管單位能即刻掌握動態之航空器飛航資料，並據以及時進行航管作為，是TACC規格書第3.2.1節第8項所規定之「飛航計畫」，係指「動態」(active)之飛行計畫，目的在使航管單位能同步或即時實施航管作為，有別於同節第9項之「飛航計畫」係指「非動態」(inactive)之飛航計畫。洛克希德公司曲解TACC規格書第3.2.1節第8項規定之原因，在於系統設計初始，洛克希德公司錯估系統使用容量(太小)，致系統反應時間(Response Time)太慢之故，而為解決系統反應時間太慢之問題，即不得不從飛航計畫數量上進行限縮，而將動態及非動態之飛航計畫數量，均限制在TACC規格書第3.2.1節第8項所定之300個，是以洛克希德公司之主張，並無任何規格書或航管實務可供佐證，並無可採，另成大鑑定報告亦認定，依據飛航管制系統之結構，處理中(Processing)之飛航計畫即為動態飛航計畫(active flightplan)之一部份，所有非動態之飛航計畫全部進入儲存的空間中，即為後述之1500個及300個飛航計畫，洛克希德公司宜瞭解航管系統之通用名稱，以免誤解內容，故民航局之說明並非約外要求。

⒉本項爭議雖曾列為TACC之PDR待辦事項第61項(下稱AI 61)，惟關於AI 61，業經洛克希德公司於74年7月1日提出所謂改進方案、請求修正系爭契約云云，關此兩造已於74年8月8日辦理契約變更而延長交期16個月，故不論AI 61是否為約外要求，關於AI 61之一切爭議，均已經雙方第4次契約變更所明文解決在案，可知洛克希德公司自得且應已將之納為延長交期之考量，而不得事後翻異主張就AI 61應適用闡明條款所定之宥恕事由，且洛克希德公司1985年9月4日函之內容略以：「洛克希德公司已收受Reference 2.所示之函文(按：民航局1985年8月29日函)，並認為應依闡明條款第4.3條之變更指令辦理。洛克希德公司正等候民航局關於前揭Reference 3.所示函文(按：洛克希德公司1985年7月2日函)之回覆，該函文係指合併PDR待辦事項第51、52及61項而言」，而關於AI 61之洛克希德公司1985年7月2日函文則記載：「洛克希德很榮幸能告知民航局...此對未來契約所預定之交期並無任何影響」(Lockheed ispleased to advise the CAA that,……there will beno impact on scheduled completion dates)，可知不論AI61是否為約外要求，洛克希德公司業已自承對系爭航管自動化系統之交貨日期並無任何影響，與本件遲延間亦無任何因果關係。

⒊民航局1987年1月8日變更指令之內容，係針對系爭系統之「顯示器韌體升級」事項所核發，完全無涉洛克希德公司主張之所謂四大項36小項遲延事由，等語資為抗辯。經查：

⒈洛克希德公司主張TACC規格書第3.2.1.1節「第8項」規定，飛航資料處理系統每小時應能接受及處理至少300個飛航計畫，並未規定、要求該等飛航計畫(flight plan)須限於「動態(active)」，惟民航局於系爭航管工程執行中，提出、要求該等飛航計畫應全部限於動態(active)之飛航計畫云云。

⒉按TACC規格書第3.2.1.1節「第9項」規定系爭航管自動化系統應能同時「儲存」至少1500筆靜態飛航計畫及300筆動態飛航計畫，而「第8項」規定飛航資料處理系統每小時應能「接受及處理」至少300個飛航計畫(詳上證157號，見本院卷12第156頁)，由系爭航管契約之目的及飛航安全等角度觀之，系爭航管契約並無限縮上開第8項「300筆飛航計畫」僅為「靜態飛航計畫」之意；且揆諸上開第9項規定特別將「動態」及「靜態」分別規定，亦可知上開第8項規定並無區分「動態」及「靜態」之意；況基於飛航安全之目的，接受及處理「動態」之飛航計畫本屬系爭航管系統應具備之功能，否則該航管系統即喪失其建構之功能及目的，就此而言該部分民航局之要求尚難謂約外要求，且洛克希德公司並未具體舉證其為進行相關設計工作，耗費多少額外人力、時間以致遲延工作進度，故洛克希德公司該部分之主張，實無理由。另洛克希德公司主張該部分與TACC CDR待辦事項第61號（即AI 61）相關，惟AI 61部分已於前所述（詳參爭點第四大項第十小項），非屬約外要求，併此敘明。

⒊成大鑑定報告認為依據飛航管制系統之結構，處理中(Processing)之飛航計畫即為動態飛航計畫(active flight plan)之一部份。本項所稱之動態飛航計畫即為進行處理中之飛航計畫（見外放之成大鑑定報告第83頁），此與前述本院判斷結果相符，故洛克希德公司該部分之主張，應非可採。另中科院並未就此部份進行鑑定，併予敘明。

⒋關於洛克希德公司於102年8月30日民事調查證據聲請續狀中，請求成大航太所補充說明之詢問事項，已於上開⒉部分說明，故本院認無再請鑑定機關補充說明之必要，併予敘明。綜上，洛克希德公司依系爭闡明條款5.2條等、5.3.1.d、民法第511條規定、不當得利、無因管理等請求民航局等給付上開約外款項，非有理由，本院自無從依民事訴訟法第222條、第282條之1第1項規定，審酌約外之報酬金額等；再者，系爭契約第1頁後段之合約欄出名表示承諾，且簽署契約之人均係中信局，又招標單上係由中信局簽名出面招標(詳見附件41，見本院第21卷第20頁背面、第30頁)，民航局在場簽名見證開標之事實，價金均係由中信局交付，雖依系爭航管契約之附件「第1.0條 付款條件(Payment Terms)」(參原證1號)中，明文約定民航局及中信局應依系爭航管契約規定給付價金(Payments by CTC/CAAto LAIL under the Contract shallbe made in accordance with the payment schedules shownin Table3,4and5.)；第1.3條規定：信用狀應由民航局及中信局開立(An irrevocable Letter of Credit (L/C)…shallbe issued by CTC/CAA)，惟根據民航局於本院準備程序所陳述「付錢的是中信局，技術部分是民航局。合約事項都是中信局處理，只有中信局才是契約當事人。」、「只有中信局給付價金。」、「當時採購規定，要透過中信局，技術部分由民航局，真正訂約應是中信局」，及洛克希德公司所陳述「合約付款是並列，民航局與中信局。實際上付款應該是中信局，我們會進一步再瞭解。」等語，可知系爭航管契約之專業技術由民航局負責驗收而已，故實際付款人則為中信局，為兩造所不爭執（詳本院102年12月27日準備程序筆錄，見本院卷21第215頁背面），再參諸係由中信局發函向香港商洛克希德公司解除契約(本院認係終止契約，詳如後述)，中信局並對之沒收保證金(詳述如後)故解釋契約真意，應係中信局付款之當事人，故洛克希德公司逕向民航局請求給付報酬，亦非有理由，附此敘明。

民航局於本案進入原審法院審理時，逕自拆除拍賣系爭設備，並於79年7月6日庭期表示：「(系爭設備)現已在拆除中」，原審法院以系爭航管系統設備之施作程度，為本案損害賠償價值之計算基礎之重要證據方法，且情況急迫，乃當庭裁定：「本件系爭裝備被告(按即民航局等)應保持原狀，未拆除部分暫不得繼續拆除。」(詳更上證189號：原審法院79年7月6日言詞辯論筆錄，見本院卷20第81至83頁)，原審法院嗣並作成書面裁定，禁止民航局等拆除、移置及毀損系爭航管設備(詳更上證141號：台北地方法院79年10月5日79年度聲字第1200號裁定，見本院卷17第201至202頁)，而民航局仍拆卸該等已安裝之全部設備。嗣於本案進行損害賠償鑑定時，本院前審為調查系爭航管設備已施作完成情形及價值，乃於96年11月27日發函指示兩造會同法院、成大航太系所至臺北區域管制中心(TACC系統)及桃園、台中、高雄(3組TCC系統)等進行現場勘驗(詳更上證139號，見本院卷17第191至199頁)，惟本院前審履勘臺北區域管制中心(TACC系統)相關設備後，發現相關設備全部已遭拆除、破壞、移置。又，系爭航管系統之軟體乃裝載於硬體上，需透過硬體開機始能讀取、執行該等軟體功能；然因現場硬體設備原狀已遭破壞，致無從為航管設備(包含硬體、軟體)原狀之價格鑑定(詳更上證139號，97年1月3日勘驗筆錄及照片，見本院卷17第191至199頁)。另嗣成大航太系所完成本案損害賠償鑑定，於賠償鑑定報告說明文件標號1000第1頁第3點表示「洛克希德公司所交付之軟硬體，其中硬體部分已經無法依據清單檢視，更因主電腦已經不在原地，軟體更不可考。因此無法建立清單、逐項清單」。本院前審復以98年5月8日之函文(詳更上證142號，見本院卷17第203頁)詢問成大航太系所相關鑑定依據，成功大學以98年7月13日成大工院字第0000000000號函第伍點表明「目前細項逐一盤點有實質上的困難」（詳更上證143號，見本院卷17第209頁)，綜上可知相關事證已多數無法還原系爭航管工程進行時之原貌，且已逾時提出攻擊防禦方法，故應不予准許再為鑑定，此於二、約內報酬、三、保證金部分均相同，併此敘明。

民航局抗辯香港商洛克希德公司於另案(即本院93年度重上字第119號)請求損害賠償，故未將本件之權利讓與洛克希德公司，其不得請求云云，惟查另案標的係中信局已給付之款項，本件係應付尚未付(約外、約內)之款項，兩者標的不同，民航局抗辯非屬可採，附此敘明。

二、兩造關於約內工程部份之爭執：

㈠洛克希德公司主張：

⒈按兩造於1983年12月20日簽訂系爭航管契約時，其固定總價為美金3906萬2649元(包括美金部分：3155萬1914元及新台幣部分：3億0223萬2000元；以美金對新台幣1:40.024匯率折算)。其後迭經六次修正，分別為1984年5月31日、1984年6月27日、1985年3月12日、1985年8月8日、1986年8月30日及1986年9月10日。第六次修正時，修正契約總價為美金3904萬4071元(包括美金部分：3166萬7184元及新台幣部分：2億9684萬5974元)。因系爭航管工程進度因諸多可歸責民航局之事由，而致實際已完成進度遲延，而難以「主要工程進度表」之時程判斷實際工程進度。故於判斷本件TACC系統及TCC系統相關約內工程已完成進度時，需進一步檢視各項硬體、及軟體(包含轉包予硬體、軟體次承包商承作之項目)之完成比例。洛克希德公司爰於鈞院前審提出93年3月29日民事請求鑑定狀，將約內工程分成九大項工程，提出工程項目及完成進度及計算之各工程項目價值如附表一所示（另詳洛克希德公司上訴暨答辯理由53狀，見本院卷20第247頁、洛克希德公司言詞辯論意旨狀第189頁以下，見本院卷23第137頁、下開⒍之後所附）。

⒉因大型航管系統涉及硬體、軟體、人力投入(測試、訓練、文件製作)等諸多項目，且因工程之完成現狀經民航局拆除而不復存在，致本件損害賠償鑑定委實複雜困難，耗時共4年4個月。實則，成功大學98年7月13日成大工院字第0000000000號函前提說明2亦表明：經過20幾年，所有當事人均已離開當時的職位，或已退休，舉證與諮詢十分困難。各項資料保存或有瑕疵，或凌亂不齊、已經無法僅依據文件之判斷，需要將當時本案所產生問題的技術層面以及國際大型工程執行慣例作為必要之考量。從而，成大航太系所經耗時4年4個月，綜合上開文件審閱、檢視工程現場、訪談民航局人員、參考國際大型工程執行慣例之調查結果，基於成大航太系所之航管專業等特別學識經驗進行評估而作成之損害賠償鑑定報告，自屬客觀可信。

⒊因民航局等支付價款時，並未區分其係為支付何項約內工程項目而給付；換言之，民航局等係依整體工程進度給付。故於計算民航局等應給給付洛克希德公司之金額時，應採下列步驟：步驟一、九項約內工程之契約價值。步驟二、評估洛克希德公司各約內工程項目已完成之百分比。步驟三、計算出各約內工程項目已完成之價值。換言之，依項目之契約預定價值乘上該約內工程項目已完工比例即可得出洛克希德公司該約內工程項目已完成工作之價值。步驟四、加總上開各約內工程項目已完成之價值，可合計得出整體航管系統已完成部分之總價值，於扣除民航局等已付款之美金1742萬2428元後，即可得出民航局等就約內工程項目已完成部分應再給付之金額云云。

㈡民航局等則以：

⒈按系爭航管契約1986年9月10日第6次修正之價金摘要（PriceProposal Summary）僅就系爭航管系統之備件、文件、運輸、保險及訓練列舉大項給付金額如附表二所述，而並非以個別之軟、硬體計價。關此洛克希德公司亦自陳系爭契約之價金摘要「僅就備件、文件、運輸、保險、訓練等列舉大項金額」，而TACC及各TCC系統所需之軟、硬體，「僅於系爭航管契約之『主要工程進度表』(Mater Program Schedule)列有各硬體及軟體工作項目之進度規劃」。洛克希德公司自行將系爭契約區分如附表一等9大項，各該大項並分別有其所謂對應之金額云云，執以作為計算其所謂「約內已完成部分」或「約內工程」金額之基礎，惟該9大項係自系爭航管契約何處劃分？與系爭契約前述所列舉TACC及TCC系統之備件、文件、運輸、保險及訓練等如何勾稽？又該9大項分別對應所謂之「預定價值」又是從何而來？俱未見洛克希德公司舉證說明，該所謂9大項及所謂對應金額係洛克希德公司自行定義，欠缺契約及法律上之依據，不足作為計算洛克希德公司所謂「約內已完成部分」之基礎。

⒉上開9大項「約內工程」所主張之完成金額，完全不可採，茲以第2項「陰極射線管顯像器」及第9項「文件」為例：洛克希德公司主張此項「陰極射線管顯像器」係以Magnavox公司為供貨商，惟由邁特公司之評估報告可知，邁特公司已一再直指Magnavox顯示器係缺陷最嚴重(most significant deficiencies)，且為「最嚴重之設備問題」(most significant problem)，在「硬體」與「韌體」等方面均有瑕疵，例如：韌體的版本有許多內在問題，有些問題尚未解決，且相關韌體之功能甚至無法達成洛克希德公司自己之要求，遑論洛克希德公司之要求遠低於CAA（即民航局）。洛克希德公司竟主張其有完成「陰極射線管顯像器」並執以請求價金云云，自無理由；另洛克希德公司與其供貨商Magnavox公司之訂約內容、價金若干，實由洛克希德公司與Magnavox公司間自行處理，屬洛克希德公司與該供貨商間之內部法律關係，並不拘束上訴人，更與系爭契約無涉，何況洛克希德公司亦未提出其與Magnavox公司之合約，則其以所謂與Magnavox間之合約金額，計算系爭契約「陰極射線管顯像器」之價值，自屬無據。又洛克希德公司所謂之「管理費」及「利潤」，其計算依據為何，完全未見其敘明，由此更足證其主張以供貨商間之合約金額，加計管理費及利潤，計算系爭契約「陰極射線管顯像器」之價值，洵不可採。且洛克希德公司所提出之「約內工程價值說明」檢附之附件2-1-36-1至附件2-1-36-19文件，根本不足證明其所完成契約價值；洛克希德公司以1988年6月1日第54版管理報告書，主張其有完成「陰極射線管顯像器」之比例達98%云云，惟其未對此提出任何契約上之出處或依據，充其量僅為洛克希德公司主張之作業內容，與目前洛克希德公司之訴訟上主張無異，更屬無據，中信局1988年11月10日函文亦不足認定洛克希德公司所謂之其有完成「陰極射線管顯像器」，其中「CAA's COMMENTS」欄位並未註明洛克希德公司確認或同意洛克希德公司之設備清單，且洛克希德公司對其品質及數量等更已表示保留，更不足證明有所謂完成比例達98%，洛克希德公司以邁特公司1988年6月22日第二次評估報告，主張其有「陰極射線管顯像器」98%之完成云云，亦屬無理，蓋依邁特公司之評估報告，反而足證洛克希德公司不僅未完成相關硬體設備，且其始終有諸多嚴重缺失未解決；而成大鑑定報告欠缺專業性、客觀性與中立性，實無從據此認定洛克希德公司有完成所謂「約內工程」等語，資為抗辯。

㈢經查，洛克希德公司就約內工程款所主張之請求權基礎為系爭航管契約闡明條款5.2.d,e及民法第511條之損害賠償請求權（見本院卷22第266頁）。惟系爭航管契約闡明條款5.2.d,e及民法第511條之損害賠償請求權適用之前提皆為「定作人任意終止契約」，而洛克希德公司於工程施作期間確有延誤工期之情事，已如前述約外工程部分說明，為民航局依法終止系爭航管契約，而應適用系爭航管契約明條款5.3相關規定，故洛克希德公司主張得依系爭航管契約闡明條款5.2.d.e及民法第511條向民航局等請求損害賠償云云，應無理由。

㈣又，洛克希德公司復主張依適用系爭航管契約明條款5.3.1.d規定請求合理報酬云云(見本院卷22第266頁)，惟查，洛克希德公司自行將「約內工程」區分如附表一之「9大項工程」，與契約約定付款方式規定不同，自欠缺契約及法律上之依據。按系爭契約之價金摘要（Price Proposal Summary）僅就系爭航管系統之備件、文件、運輸、保險及訓練列舉大項金額如附表二，而並非以個別之軟、硬體計價。關此洛克希德公司亦自陳系爭契約之價金摘要「僅就備件、文件、運輸、保險、訓練等列舉大項金額」，而TACC及各TCC系統所需之軟、硬體，「僅於系爭航管契約之『主要工程進度表』(Mater ProgramSchedule)列有各硬體及軟體工作項目之進度規劃」（詳洛克希德公司102年10月25日上訴暨答辯理由53狀第2至3頁，見本院卷20第246頁背面至247頁）。洛克希德公司自行將系爭契約區分為如附表一等9大項，並主張各該大項並分別有其所謂對應之金額云云，執以作為計算其所謂「約內已完成部分」或「約內工程」金額之基礎，惟該9大項劃分之依據為何？與系爭航管契約前述所列舉TACC及TCC系統之備件、文件、運輸、保險及訓練等項目應如何勾稽？又該9大項分別對應所謂之「預定價值」又是如何計算得出？俱未見洛克希德公司舉證說明，況該附表一之分類及金額係洛克希德公司自行定義，欠缺契約及法律上之依據，不足作為計算洛克希德公司所謂「約內已完成部分」之基礎。

㈤另洛克希德公司所主張之9大項約工程事項，其中雖有「文件、訓練、備件」和契約系爭契約之價金摘要（Price ProposalSummary）項目相同（詳洛克希德公司102年10月25日上訴暨答辯理由53狀第2至3頁，見本院卷20第246頁背面至247頁），惟洛克希德公司就上開部分請求非有理由，說明如下：

⒈文件部分：鑑定人成大航太系之「賠償鑑定報告」文件(Documention)部分，已說明「無相關資料可以估算」，僅依「約內工程價額證明附件903」(附件903為軟體權重分析計算表，為洛克希德公司自行製作之私文書，)中之資料「加權計算評估」得出「軟體總完成比例」為59.08148%，而「假設」「文件交付比率」與「軟體總完成比例」相當，故「評估」文件交付達成比率應為59.08148%（見外放之成大航太系「賠償鑑定報告」說明第10頁），顯見上開文件完成比例之計算，未經鑑定人實證，僅依私文書所載之計算式假設之方式推算，實非可採，亦未見洛克希德公司就該部分提出其他相關證明以實其說，故此部分請求非有理由。

⒉訓練部分：鑑定人成大航太系依洛克希德公司所提出之「訓練證明文件」（詳外放之約內工程價額證明附件總說明第四冊，附件8）進行鑑定，並計算出完成比例為35％（見外放之成大航太系「賠償鑑定報告」第9頁）。惟查上述附件8之資料僅係「訓練計畫」私文書，且計劃仍需待實現，故無法證明洛克希德公司已對民航局員工實施任何訓練措施或課程，洛克希德公司僅以其製作之「訓練計畫」作為已完成民航局員工訓練之佐證，自不可採，且成大航太所之鑑定報告僅用「假設」之「軟體權重值」方式計算完成比例（見外放之成大航太系「賠償鑑定報告」說明⑺部分），並未就洛克希德公司是否確有訓練作為等事實一併考量，應非可採，此部分請求亦非有理由。

⒊備件部分：鑑定人成大航太系依洛克希德公司指出備件並無佐證資料，洛克希德公司僅依據一般工程建置計畫為合理假設，且工程上系統備件屬於「後勤維護之需求」，在契約終止前所準備之器材不應視為備件，只能認定為施工中之「備用器材」。且洛克希德公司未就該項目另提出任何證據以實其說，故本項目之請求應無理由。

⒋本件因洛克希德公司未能舉證以實其說，故本院尚無從依民事訴訟法第222條、第282條之1第1項規定，審酌約內之價額等。

㈥綜上，洛克希德公司尚無法舉證約內工程施作之價值，自不得依系爭闡明條款5.2條等、5.3.1.d、民法第511條規定、不當得利、無因管理等主張民航局等已付款之美金17,422,428元為不足，再向民航局等請求不足之系爭約內工程款或損害賠償金額。再者，根據上開約外事項第所述，可知系爭航管契約之專業技術由民航局負責驗收而已，故實際付款人則為中信局，為兩造所不爭執（詳本院102年12月27日準備程序筆錄，見本院卷21第215頁背面），再參諸係由中信局發函向香港商洛克希德公司解除契約(本院認係終止契約，詳如後述)，中信局並對之沒收保證金(詳述如後)，故解釋契約真意，應係中信局付款之當事人，故洛克希德公司逕向民航局請求給付報酬，亦非有理由，附此敘明。